On Thu, 4 Sep 2025 17:10:49 +0000, Schmitt, Michael <[email protected]> wrote: >Issue address ISPEXEC "CONTROL ERRORS RETURN" before the ISREDIT "MACRO". That >way the error won't stop the exec. You can test the rc from the MACRO command >to see if you're in an environment that supports ISREDIT commands. >-----Original Message----- >From: IBM Mainframe Discussion List <[email protected]> On Behalf Of >Charles Mills >The EDIT macro contains Address ISREDIT "MACRO" . >If the macro is invoked from within the macro-initiated BROWSE I get an error >on the above statement, which is kind of ugly.
I ran into this situation in writing my own execs to switch between EDIT, VIEW, and BROWSE of the same data set. Since I was already detecting (as well as I could) when I was in BROWSE, I could just avoid issuing MACRO in that case. But now I guess I can also look into CONTROL ERRORS RETURN to handle cases where I'm in some other environment. The approach I wound up with to try and detect when I was in BROWSE and identify the data set is simple-minded and I'm sure plenty of circumstances will make it fail, but it was "good enough" for my own use. I start with: Address ISPEXEC 'VGET (ZSCREENI ZSCREENW) SHARED' and then step through the first 3 screen lines looking for one starting with BROWSE, and if the DSN is truncated I do some hunting to see if I can match it uniquely. ¬R ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
