Re: QUSRJOBI value for JOBI0600 Format not resetting

I've received a working solution via a private reply. I will respect that
person's privacy but post the solution here to accompany the original
question:

dcl &chgInfo *char 22
chgvar %bin( &chgInfo 1 4 ) 2 /* Two var-len records follow */
chgvar %bin( &chgInfo 5 4 ) 1 /* Exit key */
chgvar %bin( &chgInfo 9 4 ) 1 /* One byte */
chgvar %sst( &chgInfo 13 1 ) '0' /* Off */
chgvar %bin( &chgInfo 14 4 ) 2 /* Cancel key */
chgvar %bin( &chgInfo 18 4 ) 1 /* One byte */
chgvar %sst( &chgInfo 22 1 ) '0' /* Off */
call QWCCCJOB ( &chgInfo x'0000000000000000' )

(then call your program that could end with F3)

Thank you to the person who took the time to help.

Arnie.

On Thu, Oct 22, 2020 at 4:37 PM Arnie Flangehead <arnie.flangehead@xxxxxxxxx>
wrote:

Using a utility called RTVEXITKEY I found on-line from Bob Cozzi I coded

some CL to check for F3 Exit after an IBM command. It works, but then a
subsequent run of the same program will exit after pressing enter instead
of running.

Worse, calling a different CL program (from a menu) that has the same

utility will cause IT to think F3 has been pressed, and exit instead of
running when enter is pressed.

I debugged it and found the data in &JOBINFO doesn't get reset. Here is

the statement:

CALL PGM(QUSRJOBI) PARM(&JOBINFO &RTNLEN +
'JOBI0600' &JOB &INTJOBID)

After you've pressed F3 in program A and then run program B from the

same menu, &JOBINFO will still have a '1' in position 103, meaning F3 has
been pressed, even though you haven't done so in program B.

I don't know much about API calls. Can I reset that area of storage

somehow? I don't like to clear the whole field as there's loads of data in
there and it might screw something else up.