In a recent note, Ted MacNEIL said: > Date: Mon, 15 Jan 2007 23:15:34 +0000 > > >Of course, this is just one of many problems that would be alleviated if mu > ltiple concurrent TSO sessions weren't prohibited. > > They aren't. Not since OS/390 2.4 (ish). > I sign on with the same I'd on five different systems. > The problem is the ISPPROF dataset. > When you log on to system 5, can you cancel your comatose TSO session on system 5?
Sorry; I omitted to say "concurrent _on_the_same_system_. > See (written by yours truly): > > 10) November 2006: "Digging Into the Bag of ISPF Tricks" > http://tinyurl.com/yyghzr > > One of the REXX EXECs gets around every session requiring the same ISPPROF > datasets. > . Of course, if the TSO logon PROCs on the same system allocate different DSNs to ISPPROF, there's no problem to begin with. Likewise, when I run ISPF in batch, I allocate ISPPROF to a temporary data set. And if you're using only TSO, not ISPF, the logon proc shouldn't allocate ISPPROF; that should be left to an ISPF startup script. And in our lab, we have MIM configured not to propagate ENQs on the ISPPROF data sets. In my experience, omitting ENQ on ISPPROF solves a serious problem while creating at most a minor one: I've never experienced any. Consider: If each session allocates a separate ISPPROF data set, no changes made in any session are reflected to any of the others; if the ISPPROF ENQ is not propagated, at least changes made in the last session to exit ISPF are propagated. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
