self-submitting cl pgm doesn’t release screen

30 pts.
CL Program
The interactive code in the CL pgm calls an RPG subfile pgm. The user makes selection, the CL pgm steps to the SBMJOB command, the CL pgm is executing the Batch portion, but the screen is hung up with "X system" displayed until batch job is done. The RPG is turning "ON" *inlr and RETURN is specified. When I create seperate CL programs for the interactive and batch processes, the screen is released. Why doesn't the Self-submitter CL release the interactive screen?

Answer Wiki

Thanks. We'll let you know when a new response is added.

These are quesses.
Perhaps the CL that you think is submitting the batch job is actually calling it.
or perhaps submitted version is also calling the RPG screen program.
or the RPG program is not actually reaching the *INLR command
The first call to the CL should continue processing after it submits the job

Since this cl is called in both the batch and interative mode, I would expect to see code like this
in this CL is:

DCL &TYPE *char 1

RTVJOBA type(&type)

/* only call the RPG Screen program when the type is interactive */
if ( &type = ‘1’ ) then do
Call InterPgm
Sbmjob cmd(call myCl)
goto end
… processing to be done by batch

end: endpgm


Don’t see it either

Which program hangs ?
the unnamed one which issues

You must have shortened this code because it seems like
CUCYFLSWG is missing DCL &USER, DCL &JOB and label ENDPGM:

I suspect that ‘0′ the opening and closing quotes are just another figment of the posting code to the board process.



When the RPG (and input screen) returns control to the CL program, the CL program submits itself.
The CL program CUCYFLSWG should go back to the users menu waiting for Job Completed message.
Instead, while the CL program is running in Batch, the screen goe’s black with “X system” displayed (as if it’s running interactively), when the job is done running in batch, the user now is release back to his menu.

remember the code you posted couldn’t be compiled – so I’m assuming that the code you are running looks about the same.

I think you are saying
1. The interactive version running pgm CUCYFLSWG hangs
2. The interactive version running pgm CUGYFLSWG and it’s screen are locked
We are not back at the menu program??? waiting for the message.

If you were to hold the batch process you could check the interactive processes locks and it has this stuff

If you were to check the open files for the intractive job – it’s still using the display file and other files???? Even after program CUGYFLSWG turned on the *INLR and issued a return.

Program CUGYFLSWG issued a close file on the file CUPYFLSER and didn’t receive an error.

Discuss This Question: 7  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Gilly400
    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.
    23,730 pointsBadges:
  • Gilly400
    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.
    23,730 pointsBadges:
  • Mccsteven
    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
    30 pointsBadges:
  • Yorkshireman
    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
    6,085 pointsBadges:
  • Mccsteven
    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
    30 pointsBadges:
  • pdraebel
    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.
    7,545 pointsBadges:
  • Vatchy
    Just my $.02 but I would change the following code:
    to this:
    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.
    1,415 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: