Re: QUSRJOBI value for JOBI0600 Format not resetting

[Mark Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>]

 Arnie,
See:    https://comp.sys.ibm.as400.misc.narkive.com/d96epTQ4/qusrjobi-determine-if-f3-f12-has-been-pressed-after-runqry-command
This suggests a possible "work-around" for your problem or issue ...  you may be able to insert the following:
    call QWCCCJOB (&chgInfo x'0000000000000000' )
to reset those areas in the system memory so the subsequent calls to the RTVEXITKEY command can reflect accurately any changes since the above call.

The problem seems to center around this Cozzi utility being designed to work with IBM commands, where the IBM commands or the command environment QCMD resets that area automatically between commands, but that might not happen in your custom menu program(s), or with your own applications programs that are not "commands."
Try experimenting with the approach suggested in the above linked post.
All the best,
Mark S. Waterbury

    On Thursday, October 22, 2020, 12:03:54 AM EDT, Arnie Flangehead <arnie.flangehead@xxxxxxxxx> wrote:  
 
 p.s. Something occurred to me just after I pressed enter to send (isn't it
always the way).

The "menu" is not a standard menu object, but rather a program with
displays that look and function like menus.

So when I exit one program and choose another I'm still in a sense in the
same program, so perhaps that's the problem.

Question still stands though: Can I force reset the status in such a way
that it forgets the last F3 but will still register a new one?

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.