Re: QUSRJOBI value for JOBI0600 Format not resetting

[Arnie Flangehead <arnie.flangehead@xxxxxxxxx>]

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.