As nobody else has replied, my guess is that the z/OS USS Rexx implementation required this persistence of the Rexx environment. In USS you create the Rexx environment first with a call to BPXWRBLD which calls IRXINIT under the covers and returns. Then your USS application can do a series of calls to IRXEXEC or IRXJCL to execute Rexx execs .... so the environment can't be cleaned up when going to the equivalent of the USS "Ready" prompt. No idea where this is documented but an understandable consequence of the implementation
On Mon, Nov 9, 2020 at 10:34 AM Binyamin Dissen <bdis...@dissensoftware.com> wrote: > I have a REXX function which adds a host environment (and deletes it as > well). > > If the REXX does not call the DELETE but merely ends (there does not > appear to > be a defined way to dynamically get control at the end of the EXEC) and the > session goes to READY, the next REXX invocation has the residual > environment > defined. > > I would not expect such persistence. Is it defined anywhere? > > I attempted to update MODETABT to specify an EXECTERM (which also appears > to > persist) but that did not get control. > > -- > Binyamin Dissen <bdis...@dissensoftware.com> > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
