On Wed, Nov 19, 2014 at 11:18 AM, Paul Gilmartin < [email protected]> wrote:
> On Wed, 19 Nov 2014 09:58:57 -0700, Lizette Koehler wrote: > > > >If you create a REXX or CLIST to do your batch work, then you can test > the prof to see if MSGID and/or WTPMSG are on or off. Then set them as you > need them. > > > >Any Application that run under TSO or ISPF can reset these entries. And > sometimes they do not set them back. This is strictly a TSO function. But > some ISPF applications will tweak the TSO PROF function. > > > And if two batch IKJ jobs run concurrently, the final state is > indeterminate, even if they attempt to restore the settings. > There ought to be distinct commands to set such options for > the current session and to write them back to the RACF/UADS > data base. Clearly the TSO designers were ignorant of the > requirements of multiprocessing. > I don't think so. What the designers of TSO were was constrained by OS/360 memory, I/O, and CPU concerns. They also "wanted it now" and so problems such as this were not addressed. I don't even know if IKJEFT01 was every really meant to be run in a batch job. And IBM has now basically said that TSO, but not ISPF or SDSF thankfully, is functionally stabilized. Which is one reason why I have embraced using a z/OS UNIX shell so much. I _really_ wish that ISPF could be "ported" to run as a CUA (using curses?) and / or a X application on z/OS, likewise SDSF. What is particularly devastating to me is that until just a few years ago, SDSF came with source code. I remember looking at the terminal I/O code (native vs. ISPF). If I still had it, I could probably fake up a curses interface. > > -- gil > > -- The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
