On 19 November 2014 12:18, Paul Gilmartin <[email protected]> wrote: > And if two batch IKJ jobs run concurrently, the final state is > indeterminate, even if they attempt to restore the settings.
Why do you claim that? > 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. Well, in a sense there are distinct commands - PROFILE and LOGOFF. The PROFILE command updates the settings in an in-storage control block (the User Profile Table, mapped by IKJUPT), and it's the logoff processing in the TMP triggered by the LOGOFF command that writes the UPT back to the security system (or UADS). The in-storage UPT is local to each TSO session (address space), so the settings won't conflict. If each session restores everything to the way it was before logoff, there should be no problem. Well of course this looks like a bad design, but it doesn't normally have unpredictable results. > Clearly the TSO designers were ignorant of the requirements of > multiprocessing. Multiprogramming? No matter; the notion of running batch TSO jobs, and for that matter of running multiple TSO sessions under the same userid under any circumstances, long postdates TSO itself (there was no batch-job TSO prior to MVS). It's hardly fair to fault the designers of a Time Sharing Option that had at its core the notion of a single user at an attached terminal for not anticipating these requirements, certainly when there are so many other details to fault them for... Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
