Discussion:
IEFUTL Woes
(too old to reply)
Andrew Metcalfe
2017-04-14 17:04:27 UTC
Permalink
For reasons best left unspoken, I need to cause a TSO user’s screen to “lock” after the SMF TWT time has expired. The user then has to re-authenticate by supplying their RACF password. If they haven’t unlocked their screen after another TWT interval I need the user to be terminated S522.

The key driver is obviously the IEFUTL exit. However, I can’t “pause” the process and have IEFUTL wait for the response, because I also want to grant an extension to the already consumed wait time and then have the user cancelled at the end of the extension period. This means running IEFUTL to conclusion in order to grant the extension.
I have tried various approaches without complete success:

- Attaching IKJEFT01 as a subtask of the program named in the logon procedure and waiting on ECB posted by IEFUTL. Still pursuing this, just in a mess with the protect key of the ECB which I can overcome.
- Multiple IEFUTL exits – 1st one to set the extension and 2nd one to lock the screen. My testing implies that all the exits at SYSTSO.IEFUTL must complete before the extension is honoured.

Now considering the use of an SRB scheduled out of IEFUTL so that the IEFUTL path completes and grants the extension. However it’s been a while since I messed with SRB and I’m not sure I have the correct environment. More reading required, but the SRB is another unit of work and therefore won’t have access to SYSTSPRT and probably can’t issue TPUT/TGET anyway – I’ve not checked.

I’ve read all I can find in the archives but nothing helps.

Any pointers gratefully received.

Thanks

Andrew

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-04-14 18:15:35 UTC
Permalink
I don't know of any native z/OS facility, but CA-TPX provides this capability. That would be an expensive solution for this problem, but of course you would get a lot of additional function as well.

Maybe another more basic (=cheaper) session manager would be acceptable. I know only this one.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe
Sent: Friday, April 14, 2017 10:05 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):IEFUTL Woes

For reasons best left unspoken, I need to cause a TSO user’s screen to “lock” after the SMF TWT time has expired. The user then has to re-authenticate by supplying their RACF password. If they haven’t unlocked their screen after another TWT interval I need the user to be terminated S522.

The key driver is obviously the IEFUTL exit. However, I can’t “pause” the process and have IEFUTL wait for the response, because I also want to grant an extension to the already consumed wait time and then have the user cancelled at the end of the extension period. This means running IEFUTL to conclusion in order to grant the extension.
I have tried various approaches without complete success:

- Attaching IKJEFT01 as a subtask of the program named in the logon procedure and waiting on ECB posted by IEFUTL. Still pursuing this, just in a mess with the protect key of the ECB which I can overcome.
- Multiple IEFUTL exits – 1st one to set the extension and 2nd one to lock the screen. My testing implies that all the exits at SYSTSO.IEFUTL must complete before the extension is honoured.

Now considering the use of an SRB scheduled out of IEFUTL so that the IEFUTL path completes and grants the extension. However it’s been a while since I messed with SRB and I’m not sure I have the correct environment. More reading required, but the SRB is another unit of work and therefore won’t have access to SYSTSPRT and probably can’t issue TPUT/TGET anyway – I’ve not checked.

I’ve read all I can find in the archives but nothing helps.

Any pointers gratefully received.

Thanks

Andrew


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2017-04-14 18:19:36 UTC
Permalink
Post by Jesse 1 Robinson
I don't know of any native z/OS facility, but CA-TPX provides this capability. That would be an expensive solution for this problem, but of course you would get a lot of additional function as well.
Maybe another more basic (=cheaper) session manager would be acceptable. I know only this one.
Pretty sure session time out is included in all VTAM session managers.

It's been a fundamental part of all three that I have used...
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Cieri, Anthony
2017-04-14 18:52:16 UTC
Permalink
We use CA-TPX in conjunction with the IEFUTL exit to address this issue. CA-TPX provide the "screen lock" requiring the user to re-authenticate and the IEFUTL exit cancels the user after approximately twice the "screen lock" time interval.

Also, we use CA-TSS (Top Secret) as our External Security Manager, and it also provides a terminal lock function. Perhaps the other ESMs provide a similar function!!?

Hth
Tony



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe
Sent: Friday, April 14, 2017 2:20 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: IEFUTL Woes
Post by Jesse 1 Robinson
I don't know of any native z/OS facility, but CA-TPX provides this capability. That would be an expensive solution for this problem, but of course you would get a lot of additional function as well.
Maybe another more basic (=cheaper) session manager would be acceptable. I know only this one.
Pretty sure session time out is included in all VTAM session managers.

It's been a fundamental part of all three that I have used...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Beaver
2017-04-14 19:03:11 UTC
Permalink
All ESM will do what you are asking.

The big issue you will have to overcome are the TSS to ACF2 or RACF which are not insignificant

Steve

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Cieri, Anthony
Sent: Friday, April 14, 2017 1:52 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: IEFUTL Woes


We use CA-TPX in conjunction with the IEFUTL exit to address this issue. CA-TPX provide the "screen lock" requiring the user to re-authenticate and the IEFUTL exit cancels the user after approximately twice the "screen lock" time interval.

Also, we use CA-TSS (Top Secret) as our External Security Manager, and it also provides a terminal lock function. Perhaps the other ESMs provide a similar function!!?

Hth
Tony



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe
Sent: Friday, April 14, 2017 2:20 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: IEFUTL Woes
Post by Jesse 1 Robinson
I don't know of any native z/OS facility, but CA-TPX provides this capability. That would be an expensive solution for this problem, but of course you would get a lot of additional function as well.
Maybe another more basic (=cheaper) session manager would be acceptable. I know only this one.
Pretty sure session time out is included in all VTAM session managers.

It's been a fundamental part of all three that I have used...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Nims,Alva John , Al
2017-04-14 20:18:20 UTC
Permalink
A slightly different answer might be found at CBTTAPE.ORG, file 248. It does not lock the screen, but disconnects and then cancels if not reconnected within a follow-on time period. File 325 from Wells Fargo does something similar.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe
Sent: Friday, April 14, 2017 1:05 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: IEFUTL Woes

For reasons best left unspoken, I need to cause a TSO user’s screen to “lock” after the SMF TWT time has expired. The user then has to re-authenticate by supplying their RACF password. If they haven’t unlocked their screen after another TWT interval I need the user to be terminated S522.

The key driver is obviously the IEFUTL exit. However, I can’t “pause” the process and have IEFUTL wait for the response, because I also want to grant an extension to the already consumed wait time and then have the user cancelled at the end of the extension period. This means running IEFUTL to conclusion in order to grant the extension.
I have tried various approaches without complete success:

- Attaching IKJEFT01 as a subtask of the program named in the logon procedure and waiting on ECB posted by IEFUTL. Still pursuing this, just in a mess with the protect key of the ECB which I can overcome.
- Multiple IEFUTL exits – 1st one to set the extension and 2nd one to lock the screen. My testing implies that all the exits at SYSTSO.IEFUTL must complete before the extension is honoured.

Now considering the use of an SRB scheduled out of IEFUTL so that the IEFUTL path completes and grants the extension. However it’s been a while since I messed with SRB and I’m not sure I have the correct environment. More reading required, but the SRB is another unit of work and therefore won’t have access to SYSTSPRT and probably can’t issue TPUT/TGET anyway – I’ve not checked.

I’ve read all I can find in the archives but nothing helps.

Any pointers gratefully received.

Thanks

Andrew

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-04-14 21:05:57 UTC
Permalink
Post by Nims,Alva John , Al
A slightly different answer might be found at CBTTAPE.ORG, file 248. It does not lock the screen, but disconnects and then cancels if
not reconnected within a follow-on time period. File 325 from Wells Fargo does something similar.
Thanks for the references, Al. That approach was what I was going to suggest, but I wouldn't have been able to provide those pointers.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jeremy Nicoll
2017-04-15 11:51:09 UTC
Permalink
Post by Andrew Metcalfe
For reasons best left unspoken, I need to cause a TSO user’s screen to
“lock” after the SMF TWT time has expired. The user then has to
re-authenticate by supplying their RACF password. If they haven’t
unlocked their screen after another TWT interval I need the user to be
terminated S522.
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.
--
Jeremy Nicoll - my opinions are my own.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andy Wood
2017-04-15 18:46:44 UTC
Permalink
...
Post by Jeremy Nicoll
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bruce Hewson
2017-04-17 09:09:57 UTC
Permalink
Hi Andrew,

used previously - worked very well - check out:-

http://www.ase.com.au/ltxf.htm

Logon Timeout eXtension Facility - MVS, OS/390, z/OS

Australian Systems Engineering Pty. Ltd.
Since 1980 we've made tools for users and managers of MVS, OS/390 and z/OS systems

Regards
Bruce
Post by Andrew Metcalfe
For reasons best left unspoken, I need to cause a TSO user’s screen to “lock” after the SMF TWT time has expired. The user then has to re-authenticate by supplying their RACF password. If they haven’t unlocked their screen after another TWT interval I need the user to be terminated S522.
The key driver is obviously the IEFUTL exit. However, I can’t “pause” the process and have IEFUTL wait for the response, because I also want to grant an extension to the already consumed wait time and then have the user cancelled at the end of the extension period. This means running IEFUTL to conclusion in order to grant the extension.
- Attaching IKJEFT01 as a subtask of the program named in the logon procedure and waiting on ECB posted by IEFUTL. Still pursuing this, just in a mess with the protect key of the ECB which I can overcome.
- Multiple IEFUTL exits – 1st one to set the extension and 2nd one to lock the screen. My testing implies that all the exits at SYSTSO.IEFUTL must complete before the extension is honoured.
Now considering the use of an SRB scheduled out of IEFUTL so that the IEFUTL path completes and grants the extension. However it’s been a while since I messed with SRB and I’m not sure I have the correct environment. More reading required, but the SRB is another unit of work and therefore won’t have access to SYSTSPRT and probably can’t issue TPUT/TGET anyway – I’ve not checked.
I’ve read all I can find in the archives but nothing helps.
Any pointers gratefully received.
Thanks
Andrew
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...