Re: QUSRJOBI value for JOBI0600 Format not resetting

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.