This suggestion is the same as I was thinking would work.

The Edit macro command we're referring to is DEFINE - Define a name.

https://www.ibm.com/docs/en/zos/2.5.0?topic=statements-definedefine-name

Let's say you want to track the submit command. You create an exec MYSUBMIT.

In your initial macro:

ISREDIT DEFINE MYSUBMIT MACRO CMD      # this defines MYSUBMIT as a macro
ISREDIT DEFINE SUBMIT ALIAS MYSUBMIT   # this redefines SUBMIT to be an alias 
for your macro

Now when the user types SUBMIT, it will run your MYSUBMIT macro instead.

In your MYSUBMIT macro:

Do what you need to do to record that the user did submit, such as updating a 
variable in the shared or profile pool

ISREDIT BUILTIN SUBMIT   # now you have to actually do the submit, so you tell 
Edit to run the real command


And do the same for CANCEL, SAVE, or END (which is PF3). But note that you can 
distinguish to some degree between CANCEL, SAVE, and END in two ways:

1. The EDIT service ends with RC = 0 if the user ended with saving, and RC = 4 
if nothing was saved.

2. You can record the ISPF statistics of the member you're editing before 
invoking EDIT, and then query again afterwards. If the stats change, then it 
was saved.



For a /really/ advanced method, you can create an Edit Interface (EDIF 
service). When you do that, commands pass through your program. But I wouldn't 
recommend it, creating an Edit Interface is *hard*.


-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of 
salva
Sent: Tuesday, May 5, 2026 12:28 PM
To: [email protected]
Subject: Re: Test for command after Rexx ISREDIT

>At this point the USER has control of edit, and can issue SUBMIT, CANCEL,
SAVE or press PF3 -
So it is at this point I would like to determine which action the user
initiated ...

Your initial Macro should redefine SUBMIT, CANCEL, SAVE... as new Macros.
These Macros can save the event in the profile and then call the Builtin
SUBMIT, CANCEL, SAVE. Finally examine the profile from the first command
exec after the Edit.

Sounds tricky and prone to errors. I think there may be a cleaner solution
if you tell us all the story.

El mar, 5 may 2026, 19:06, [email protected] <[email protected]> escribió:

> Hello MichaelI think you understand this quite well -.1. Before you enter
> the exec that does the EDIT, you're in ISPF (i.e. not in Edit).2. You do
> the command. This starts an ISPF Edit session, but before the user gets
> control...3. You have MACRO(XCHGRUN), so it runs XCHGRUN as an initial
> macro.4. At the end of XCHGRUN, if that macro does *not* issue an ISREDIT
> "END" or "CANCEL" command, then the user gains control of the Edit session.
> If the macro issues END or CANCEL then the Edit session ends and we're back
> in your first exec.5. If the macro didn't end the Edit session, the user
> has control of Edit.
>
> ...............................................................................
> At this point the USER has control of edit, and can issue SUBMIT, CANCEL,
> SAVE or press PF3 -
> So it is at this point I would like to determine which action the user
> initiated ...
>
> thank you
> paul
>
>
> ---------- Original Message ----------
> From: "Schmitt, Michael"              <
> [email protected]>
> To: [email protected]
> Subject: Re: Test for command after Rexx ISREDIT
> Date: Tue, 5 May 2026 15:56:09 +0000
>
> To be clear: when the user gains control of the Edit session, your Edit
> macro XCHGRUN has exited. So the only* active REXX exec is the one that did
> the EDIT command.
>
>
> * and possibly an exec that starts ISPF, if that's allowed by your
> installation
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]> On Behalf
> Of Schmitt, Michael
> Sent: Tuesday, May 5, 2026 10:20 AM
> To: [email protected]
> Subject: Re: Test for command after Rexx ISREDIT
>
> This still isn't clear to me.
>
> 1. Before you enter the exec that does the EDIT, you're in ISPF (i.e. not
> in Edit).
> 2. You do the command. This starts an ISPF Edit session, but before the
> user gets control...
> 3. You have MACRO(XCHGRUN), so it runs XCHGRUN as an initial macro.
> 4. At the end of XCHGRUN, if that macro does *not* issue an ISREDIT "END"
> or "CANCEL" command, then the user gains control of the Edit session. If
> the macro issues END or CANCEL then the Edit session ends and we're back in
> your first exec.
> 5. If the macro didn't end the Edit session, the user has control of Edit.
> Eventually the user ends the Edit session.
> 6. Now we're back in your first exec, after the EDIT command.
> 7. Eventually this exec ends and we're back at ISPF.
>
> So at what point are you trying to determine what command was entered?
>
> Note: I don't /think/ it is possible to tell what command was entered
> without changing the Edit panel.
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]> On Behalf
> Of [email protected]
> Sent: Monday, May 4, 2026 9:52 AM
> To: [email protected]
> Subject: Re: Test for command after Rexx ISREDIT
>
> My apologies,sorry for the confusion  -The original posting was incorrect
> -I do issue   ADDRESS ISPEXEC
>  "EDIT DATASET('" || WORKDSN || "(" || TEMPRUN || ")')
>    MACRO(XCHGRUN) PARM(TEMPRUN)"  .Yes I am still in edit mode - and I
> want to determine if SUBMIT, END, CANCEL, or a PF key was entered ...I
> should be able to determine what action the user performed/entered in
> Rexx..paul
>
> ---------- Original Message ----------
> From: "Schmitt, Michael"              <
> [email protected]>
> To: [email protected]
> Subject: Re: Test for command after Rexx ISREDIT
> Date: Mon, 4 May 2026 14:42:34 +0000
>
> What do you mean by "When the Edit session is returned to the user"?
>
> If you mean when the Edit session ends and the user is back in ISPF, the
> last action had to be something that ends Edit. And that sets a return code.
>
>
> If you mean when the macro is over, then how can you detect anything?
> You're not in a macro anymore.
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]> On Behalf
> Of [email protected]
> Sent: Sunday, May 3, 2026 2:00 PM
> To: [email protected]
> Subject: Test for command after Rexx ISREDIT
>
> I'm not well versed in Rexx -.I do have a simple rexx routine which calls
> another routine to issue a macro as follows:.
> address ISREDIT
>  "macro (PDSMEM) NOPROCESS"
>  "CHANGE '@@@class' '"drgclass"'"
>  "CHANGE '@@@packg' '"drgpackg"'"
>  "CHANGE '@@@envt' '"lenvt"'"
> .
> address ISPEXEC "ISREDIT SAVE "t.I have no issues with the above code
> snipet -It works very well as expected -.When the Edit session is returned
> to the user, I would like to detect the last function the user performed on
> that screen -The user could have entered SUBMIT, CANCEL, simply depressed
> the enter key, or decided to end with PF3 -How can i easily and safely
> determined what the user last performed ?..paul
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to