0
Gilly400 
23625 pts. | May 29 2009 3:31PM GMT
Hi,
If it’s a non-ILE CL program maybe it’s an idea to do a RTVCLSRC to make sure the source matches the object. Quite often programmers (myself included) code an interactive call and a submitted call in their program to help while debugging. Maybe the interactive call is still in the program?
Are you sure that a job gets submitted? Try changing the logging level of your job and check the joblog.
Regards,
Martin Gilbert.
Gilly400 23625 pts. | May 29 2009 3:32PM GMT
Hi,
Just another thought - can you post the (CL) code here? Maybe there’s something else that we haven’t thought of.
Regards,
Martin Gilbert.
Mccsteven 30 pts. | May 29 2009 4:15PM GMT
To answer Philip, thanks for your answer. I have checked the code itself and the calling methods, debug shows the RPG stepping through to *INLR.
To Gilly, thank you also, It is a non-ILE cl program, I have renamed the program, compiled it to create a new object, and still had the screen hang up during the batch processing. We were told to get out of the system for upgrades until 1 p.m. so i won’t be able to post the code until 1:30ish.
Thank you both. I will upload the code about 1.5 hours from now. I really think IBM has an OS error here, I will post the question to IBM this afternoon also.
Steve
Yorkshireman 3200 pts. | Jun 1 2009 11:28AM GMT
You say the RPG is getting to *INLR ?
is this in the calling or submitted job?
from your question, I’m supposing something like the following outline.
or is the subfile program doing the SBMJOB?
There is no bug in the operating system. This isn’t a PC.
- - - - - - - - - - -
PGM
start:
CALL subfile pgm
IF return = option 99
SBMJOB Call ABCDE JOBD(*JOBD) blah blah
endif
IF return = option 45
blah blah
endif
If return = Option F03
goto exit
endif
GOTO start
exit:
endpgm
Mccsteven 30 pts. | Jun 2 2009 7:08PM GMT
the user takes menu option which calls interactively…
CALL CUCYFLSWG PARM(&SCREENVALUE)
PGM PARM(&SCREENVALUE)
DCL VAR(&ENV) TYPE(*CHAR) LEN(1)
DCL VAR(&SCREENVALUE) TYPE(*CHAR) LEN(1)
DCLF FILE(CUPYFLSER) RCDFMT(CURYFLSER)
RTVJOBA JOB(&JOB) USER(&USER) TYPE(&ENV)
/*******************************************************/
/* INTERACTIVE PROCESSING (&ENV = ‘1′) */
/*******************************************************/
IF COND(&ENV *EQ ‘1′) THEN(DO)
CALL PGM(CUGYFLSWG) PARM(&SCREENVALUE) << this rpg subfile pgm builds
file CUPYFLSER, returns a ‘Y”
the sbmjob runs
the batch process runs thru the
file CUPYFLSER creatng reports
the screen from the rpg hangsup
the CUPY file is manually opened
and closed in the RPG.
IF COND(&SCREENVALUE *NE ‘Y’) THEN(DO)
GOTO CMDLBL(ENDPGM)
ENDDO
SBMJOB CMD(CALL PGM(CUCYFLSWG) +
PARM(&SCREENVALUE)) JOB(FLS_WAGE)
ENDDO
/**************************************************/
/* BATCH PROCESSING (&ENV = ‘0′) */
/**************************************************/
IF COND(&ENV *EQ ‘0′) THEN(DO)
LOOP: RCVF RCDFMT(CURYFLSER)
MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(ENDREAD))
/* Monitor for End-Of-File */
RUNQRY QRY(REPORT)
GOTO CMDLBL(LOOP)
ENDREAD: ENDDO
ENDPGM
Pdraebel 785 pts. | Jun 4 2009 9:06AM GMT
I suspect some file locking in Your RPG subfile program to be the culprit. Check if the file in RPG is defined as U(pdate). Maybe the last record displayed on the subfile is causing the lock.
Vatchy 650 pts. | Jun 4 2009 3:38PM GMT
Just my $.02 but I would change the following code:
IF COND(&SCREENVALUE *NE ‘Y’) THEN(DO) GOTO CMDLBL(ENDPGM) ENDDO SBMJOB CMD(CALL PGM(CUCYFLSWG) + PARM(&SCREENVALUE)) JOB(FLS_WAGE) ENDDO
to this:
IF COND(&SCREENVALUE *EQ ‘Y’) THEN(DO) SBMJOB CMD(CALL PGM(CUCYFLSWG) + PARM(&SCREENVALUE)) JOB(FLS_WAGE) ENDDO GOTO CMDLBL(ENDPGM) ENDDO
IMHO, positive checks (*EQ) are better, and easier to read, than negative checks (*NE). Also, this positively ends your program after submitting the job (assuming that there is no processing going on between the ENDPGM label and the ENDPGM command. However, you might try putting a RCLRSC in-between the ENDPGM label and the ENDPGM command.
