self-submitting cl pgm doesn’t release screen
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?
Software/Hardware used:
Software/Hardware used:
ASKED:
May 29, 2009 2:22 PM
UPDATED:
June 4, 2009 3:38 PM
Answer Wiki:
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
Phil
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
enddo
... processing to be done by batch
end: endpgm
Phil
//////////////////////////
Don't see it either
Which program hangs ?
the unnamed one which issues
- CALL CUCYFLSWG PARM(&SCREENVALUE)
or
program CUGYFLSWG
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.
Phil
/////////////////////////
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
locked?
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.
To see all answers submitted to the Answer Wiki: View Answer History.
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.
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.
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
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
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
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.
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.