On Sat, 15 Apr 2017 12:51:58 +0100, Jeremy Nicoll <[email protected]> wrote:
>On Fri, 14 Apr 2017, at 18:05, Andrew Metcalfe wrote: ... > >Ages ago I worked in an installation that allowed TSO users to get one >extension to >the timeout provided they themselves locked their screens. The program >that did >it issued a fullscreen TPUT saying it was locked (& named the userid and >SMFID of >the locked session - so that people logged into multiple systems could >unlock the >right one as needed). Password validation was in our case done by ACF2 >and the >lock program also counted failed password uses and forced sessions to >end if some >user was trying to guess someone-else's password. > >At the point where a user's screen was locked by this program, a small >flag block was >hung of the TCBUSER field of the job-step TCB. If that couldn't be set >up in the expected >way the user just got 522ed. Normally the flag block would contain >'TSOLOCK' literals >(so easily found in a dump) and a count field. IEFUTL would look to see >if a user had such >a flag block, and if so if they'd not yet had too many timeout >extensions. If the block was >there and the count low, it'd be incremented and they'd stay logged in. >Otherwise they'd >get 522ed. > > >So... could you in login processing attach a subtask that is a program >that waits until some >external trigger causes it to lock the user's screen? Then when IEFUTL >runs, identifies an >address space as a TSO user, checks some flag (stored off TCBUSER, >maybe, or via name & >token services), to see if they are one of this special class of users, >and if so either post the >ECB or 522 them. I have a very distant memory of a similar LOCK command which IIRC avoided S522 without requiring IEFUTL collusion, by simply waking up often enough. I sort-of recall that it took a bit of care to prevent being able to break out of the locked state by rapidly hitting ATTN. I see a similar command, LOCKTERM in CBT file 183. That also does not require any assistance from IEFUTL because it sets ASCBTOFF (I'm not going to pass judgement as to whether that is a good idea). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
