OK... Uncle already..
I'm working on a program that gives an error message that says 'Subfile Record Not Found'. All of the research that I've done seems to indicate that this condition is usually caused by misuse of the READC Opcode in RPG. I can find nothing wrong with the way that the READC is coded compared to the way that it is recommended.
So, I began to suspect the way that the SLFNXTCHG was coded. Initially, there were no indicators on it in the DDS, so I tagged an indicator to it, set it off before loading the subfile, and setting it back on on error conditions before update and so forth. This solved the problem of not getting that error, but simply because the program is treating it as though no changes are made to the subfile, and we bail out of the routine. This would suggest that the SFLNXTCHG indicator is not being turned on when a change is made.
So, I took out all of the 'setoffs' of the indicator in the program, and debugged it. No help, still no indicator being turned on. What is puzzling me is how come the indicator is not comming on at all when I make a change to the screen? I have verified this via Debugs.
Here is some of the code to chew on. NOTE: I cannot take blame/credit for it as I'm not the author of this program...I just got tapped to make a simple change to it!
DDS...
A 55 SFLNXTCHG
Again...Originally, there was no indicator here..
RPG...
Probably more code than what is needed, and I removed that Setof of 55 as I just want to confirm that I'm not erroneously turning it off.
Cheers! - BS
I'm working on a program that gives an error message that says 'Subfile Record Not Found'. All of the research that I've done seems to indicate that this condition is usually caused by misuse of the READC Opcode in RPG. I can find nothing wrong with the way that the READC is coded compared to the way that it is recommended.
So, I began to suspect the way that the SLFNXTCHG was coded. Initially, there were no indicators on it in the DDS, so I tagged an indicator to it, set it off before loading the subfile, and setting it back on on error conditions before update and so forth. This solved the problem of not getting that error, but simply because the program is treating it as though no changes are made to the subfile, and we bail out of the routine. This would suggest that the SFLNXTCHG indicator is not being turned on when a change is made.
So, I took out all of the 'setoffs' of the indicator in the program, and debugged it. No help, still no indicator being turned on. What is puzzling me is how come the indicator is not comming on at all when I make a change to the screen? I have verified this via Debugs.
Here is some of the code to chew on. NOTE: I cannot take blame/credit for it as I'm not the author of this program...I just got tapped to make a simple change to it!

DDS...
A 55 SFLNXTCHG
Again...Originally, there was no indicator here..
RPG...
PHP Code:
C NEXTS1 BEGSR
C*
C MOVE *OFF UPFLG
C MOVE *ON *IN40
C RRN1 IFGT *ZEROS
C*
C MOVE *OFF *IN98
C *IN98 DOWEQ *OFF
C *IN03 ANDEQ *OFF
C READC BF607411 98
C *IN98 IFEQ *OFF
C**** eval *in55=*off
C* OPTN1 IFEQ 2
C* OPTN1 OREQ 5
C if (optn1 = 2 and apprv@ <> Approved
C and apprv@ <> SubApproval)
c or optn1 = 5
C MOVE MODE HMODE
C MOVE *IN29 HIN29
C Z-ADD OPTN1 HOPTN1
C Z-ADD *ZEROS OPTN1
C UPDATE BF607411
C HOPTN1 IFEQ 5
C MOVE *ON *IN29
C MOVEL 'Display' MODE
C ENDIF
C EXSR SCRN02
C MOVE HMODE MODE
C MOVE HIN29 *IN29
C ENDIF
C OPTN1 IFEQ 4
C Z-ADD OPTN1 HOPTN1
C Z-ADD *ZEROS OPTN1
C UPDATE BF607411
C* Send a Status Message
C CALL 'MSX081CL'
C PARM '1' MSSTS 1
C PARM MSG(2) MSDTA 132
C EXSR DELETE
C CALL 'MSX081CL'
C PARM '1' MSSTS 1
C PARM MSG(3) MSDTA 132
C ENDIF
C If OPTN1 = 6 and (apprv@ = Approved
C or apprv@ = SubApproval)
C Z-ADD OPTN1 HOPTN1
C EXSR SR_AprvlUpd
C Eval OPTN1 = 0
C UPDATE BF607411
C ENDIF
C*
C ENDIF
C ENDDO
C*
C* Refresh the screen
C UPFLG IFEQ *ON
C EXSR POSTS1
C ENDIF
C*
C ENDIF
C*
C MOVE *OFF DLTFG1
C MOVE *OFF DLTFG2
C ENDSR
Cheers! - BS




In previous efforts, I've tried code to limit the number of READC executions to only be the number of actual records in the subfile. No help.

but i do agree that something has to be unlocking the subfile record prior to the update. it would be much less guesswork if we had the complete source to look at. (my fixed format skills are going out the window as well...after a few years of nothing but free-format i'm spoiled
)
Comment