On Tue, 5 May 2026, at 18:06, [email protected] wrote: > Hello MichaelI think you understand this quite well ...
> ............................................................................... > At this point the USER has control of edit, and can issue SUBMIT, > CANCEL, SAVE or press PF3 - If the process requires the user to edit the file outwith the control of the macro ... which could include zero or more changes & submits then I don't think you can track those at all. (Even if you forced different PF key meanings into effect so that eg PF3 ran code that noted PF3 had been pressed then did the PF3 action) you can't stop the user from just typing commands. OTOH If you're not going to let the user do any manual editing - have the macro display a panel with a choice of submit/save/cancel & have it both do the required actions and note them in a variable. VPUT that var & exit the edit session. Back in the calling exec VGET the var to find out which choices the user made. This whole thing puzzles me though because - back in the day - I used macros to do edits entirely without user intervention. If the result of the edit needed saved the macro would do a save & store the save's rc in a var (& VPUT it) then exit. The calling exec would then VGET that var (& possibly others set by the macro) & be able to tell if the update worked. Back then (& possibly still now) the rc from the invocation of the edit (in the calling exec) only told you if trying to start the edit worked; contention on shared datasets could easily have that fail before the macro did anything. What PRECISELY are you trying to achieve & WHY? -- Jeremy Nicoll - my opinions are my own. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
