> On Tue, 23 Oct 2007 14:58:23 -0700, George Fogg wrote: > >>> I worked with a shop some years ago that had a similar requirement. For a >>> certain class of user, management wanted this: >>> >>> 1. LOGON >>> 2. Be placed immediately into ISPF >>> 3. Exit ISPF >>> 4. LOGOFF >>> >>> In other words, these users were not allowed to sit at Ready. Don't >>> remember why. Doesn't matter. >>> >>> There turned out to be a simple solution. The 'moment' the user gets logged >>> on and enters ISPF, issue this MVS command: P userid . It's not >>> documented well (or maybe at all), but a TSO user in the 'stopping state' >>> (my term), can continue the 'current operation' but will be logged off at >>> the conclusion of that operation. ISPF is treated as one long continuous >>> operation. The moment you exit ISPF, you are logged off. >> >>Skip: >>Seems to work OK. >>Now you need a bulletproof solution to force those users to be placed in ISPF >>at logon and find a way to issue the "P userid" command. I think it can be >>done in RACF's post-processing exit. > > George, > > That might be too early - under some odd timing conditions you might succeed > (FSVO 'succeed') in logoff prior to ISPF (which would frustrate the end users > and waste the company's resources... who's the bad guy then?)
It is too early in the process as I just found out. I issued a "P userid" after the READY prompt and before the userid went into ISPF so when the user tried to get into ISPF then boom, the user was forced to logon or logoff. The RACF post-processing is not a choice. Messages I got at READY prompt when entering ISPF : IKJ56620I MVS STOP command encountered. TSO/E session is terminated. IKJ56470I USR000 LOGGED OFF TSO AT 15:26:27 ON OCTOBER 23, 2007 IKJ56400A ENTER LOGON OR LOGOFF- George Fogg > > I would suggest pushing out an operator message in an ISPF initialization exit > and letting automated operations issue the STOP command. That way you > know the user was safely tucked into ISPF. Does the > > I would also suggest that it should be mandatory that this 'feature' be > verified > & documented as an intended interface by IBM before using it. (I've used it > in > the dim past for a few things but none were particularly long-term. It worked > for me, for example, when running a CLIST in a started task doing TSO > RECEIVE (as in XMIT/RECEIVE) processing many years ago. > > -- > Tom Schmidt > Madison, WI > > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- 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
