Re: tso session timeout
On Fri, 30 Apr 2010 10:29:02 -0400, zMan zedgarhoo...@gmail.com wrote: Is there a better way? On z/VM I'd do a LOGON HERE. Is there some way to make TSO notice that I'm not there? IKJEFLN2 You can find a version of that in file 183 of the CBT tape. (Thanks again, Gilbert Saint-flour! This one save my ..s numerous times when we were still on that Flex box...) Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
Jan Having checked IKJEFLN2 - TSO Reconnect Exit for the TN3270 Environment http://gsf-soft.com/Products/IKJEFLN2.shtml it appears that this implementation of IKJEFLN2 performs the same function as is provided officially using the logonhere support in z/OS V1R11. I described this in my post LOGONHERE with TSO/E for z/OS V1R11 (Was: tso session timeout) of two days ago in case the needed change of subject unfortunately caused it to be missed. I expect for those who are nervous about introducing unofficial software - no matter how good the best efforts support, the R11 logonhere support will be appreciated. Chris Mason On Mon, 3 May 2010 06:05:10 -0500, Jan MOEYERSONS jan.moeyers...@adelior.be wrote: On Fri, 30 Apr 2010 10:29:02 -0400, zMan zedgarhoo...@gmail.com wrote: Is there a better way? On z/VM I'd do a LOGON HERE. Is there some way to make TSO notice that I'm not there? IKJEFLN2 You can find a version of that in file 183 of the CBT tape. (Thanks again, Gilbert Saint-flour! This one save my ..s numerous times when we were still on that Flex box...) Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
How's your short term memory - can you remember if you're in Sydney for the z Symposium next week ?. Shane ... On Sat, May 1st, 2010 at 3:32 PM, Greg Price wrote: At least, that's the way I remember it... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
LOGONHERE with TSO/E for z/OS V1R11 (Was: tso session timeout)
zMan As John Chase indicated you need to be using z/OS V1R11 or later in order to benefit from so-called logonhere support - just like VM has had for ages and ages. This TSO/E enhancement did get covered thoroughly in a post not so long ago: Re: TSO reconnect (ikjefln2) reject by RACF From: Chris Mason chrisma...@belgacom.net Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Date: Tue, 23 Feb 2010 15:03:06 -0600 Chris Mason On Fri, 30 Apr 2010 10:29:02 -0400, zMan zedgarhoo...@gmail.com wrote: On Fri, Apr 30, 2010 at 9:04 AM, Graeme Gibson gra...@ase.com.au wrote: Does the TSO session timeout get its value from SMFPRM00 JWT(0030) Which reminds me: I work remotely a lot, and if my connectivity burps, I get disconnected. Sometimes TSO notices, and when I reconnect I get reconnected (or it starts my session over, if I don't do it fast enough). Other times, I get ALREADY LOGGED ON and have to wait a while (or logon as another privileged ID and Cancel myself). Is there a better way? On z/VM I'd do a LOGON HERE. Is there some way to make TSO notice that I'm not there? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
tso session timeout
Does the TSO session timeout get its value from SMFPRM00 JWT(0030) Is there a way to allow certain TSO users a longer timeout without having to use an exit. If it has to be an exit, which one is it. Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
Does the TSO session timeout get its value from SMFPRM00 JWT(0030) Yes. Is there a way to allow certain TSO users a longer timeout without having to use an exit. Yes. But, it's an all or nothing proposition, by user. Allow, through your ESM (RACF, ACF2, or Top Secret), the user to specify their CPU time. And, they can specify TIME=1440. Or give them access to a PROC with it (or TIME=NOLIMIT -- I believe that's the newer value). The all or nothing aspect, is they will NEVER time-out due to CPU consumption. Anything else is an exit. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
Does the TSO session timeout get its value from SMFPRM00 JWT(0030) Yes. Is there a way to allow certain TSO users a longer timeout without having to use an exit. No. If it has to be an exit, which one is it. IEFUTL shamelessplug http://www.ase.com.au/ltxf.htm /shamelessplug Cheers to all, Graeme Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
Ted MacNEIL wrote: Allow, through your ESM (RACF, ACF2, or Top Secret), the user to specify their CPU time. Where? I know of the CPU Max in OMVS segment, but can that LIMIT the CPU used by a TSO id? Anything else is an exit. Right. It is the IEFUTL exit. Groete / Greeting Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
On Fri, 30 Apr 2010 12:29:25 +, Ted MacNEIL eamacn...@yahoo.ca wrote: Does the TSO session timeout get its value from SMFPRM00 JWT(0030) Yes. Is there a way to allow certain TSO users a longer timeout without having to use an exit. Yes. But, it's an all or nothing proposition, by user. Allow, through your ESM (RACF, ACF2, or Top Secret), the user to specify their CPU time. And, they can specify TIME=1440. Or give them access to a PROC with it (or TIME=NOLIMIT -- I believe that's the newer value). The all or nothing aspect, is they will NEVER time-out due to CPU consumption. JWT isn't CPU consumption, it is wait time (JWT=Job Wait Time).But you are correct that IEFUTL won't be called for TIME=1440. The init and tuning doesn't say so, but the same applies for TIME=NOLIMIT AFAIK. What has changed from years ago (and I don't know exactly when without research) is that TIME=1440 used to turn off the accounting in SMF records, which is why you'll probably still find TIME=1439 coded in a lot of places . But TIME=1439 won't keep IEFUTL from being called for a wait. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
Mark Zelden wrote: What has changed from years ago (and I don't know exactly when without research) is that TIME=1440 used to turn off the accounting in SMF records, Please explain 'accounting in SMF records'. Does that means some SMF records were not written at all if TIME=1440 is used? Where is that history trivia documented? Just (very and very) curious... ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
On Fri, Apr 30, 2010 at 9:04 AM, Graeme Gibson gra...@ase.com.au wrote: Does the TSO session timeout get its value from SMFPRM00 JWT(0030) Which reminds me: I work remotely a lot, and if my connectivity burps, I get disconnected. Sometimes TSO notices, and when I reconnect I get reconnected (or it starts my session over, if I don't do it fast enough). Other times, I get ALREADY LOGGED ON and have to wait a while (or logon as another privileged ID and Cancel myself). Is there a better way? On z/VM I'd do a LOGON HERE. Is there some way to make TSO notice that I'm not there? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
-Original Message- From: IBM Mainframe Discussion List On Behalf Of zMan On Fri, Apr 30, 2010 at 9:04 AM, Graeme Gibson gra...@ase.com.au wrote: Does the TSO session timeout get its value from SMFPRM00 JWT(0030) Which reminds me: I work remotely a lot, and if my connectivity burps, I get disconnected. Sometimes TSO notices, and when I reconnect I get reconnected (or it starts my session over, if I don't do it fast enough). Other times, I get ALREADY LOGGED ON and have to wait a while (or logon as another privileged ID and Cancel myself). Is there a better way? On z/VM I'd do a LOGON HERE. Is there some way to make TSO notice that I'm not there? Install z/OS 1.11. I couldn't remember whether the logon here equivalent had been implemented in 1.11 or 1.12, but we have a new 1.11 image running in the sandbox so I tried it and it worked. Logged in from one emulator window with one terminal netname; opened another emulator window which got a different netname; performed a normal logon in the second window and got message IKT00300I LOGON RECONNECT SUCCESSFUL, SESSION ESTABLISHED. My old session in the original emulator window got disconnected. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
Please explain 'accounting in SMF records'. Does that means some SMF records were not written at all if TIME=1440 is used? Where is that history trivia documented? Just (very and very) curious... ;-D ISTR that in MVS 3.8 the initiator task checked the time value for 1440 before recording/saving the accumulated CPU time for the job step. I don't believe it works that way any more. It may have been documented or not, but it was at least a fairly well known 'feature'. I don't think the anomoly actually prevented the SMF records from being written. They just didn't show any CPU time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
On Fri, Apr 30, 2010 at 3:47 PM, Chase, John jch...@ussco.com wrote: Install z/OS 1.11. I couldn't remember whether the logon here equivalent had been implemented in 1.11 or 1.12, but we have a new 1.11 image running in the sandbox so I tried it and it worked. Logged in from one emulator window with one terminal netname; opened another emulator window which got a different netname; performed a normal logon in the second window and got message IKT00300I LOGON RECONNECT SUCCESSFUL, SESSION ESTABLISHED. My old session in the original emulator window got disconnected. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Strange, I've just tried the same thing on our z/OS 1.11 system and got - IKJ56425I LOGON rejected, UserId MAINT already logged on to system S0W1 IKJ56400A ENTER LOGON OR LOGOFF- Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
Is there a way to allow certain TSO users a longer timeout without having to use an exit. No. YES. But, it's unlimited. TIME=1440 - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
On Fri, Apr 30, 2010 at 4:01 PM, Jim McAlpine jim.mcalp...@gmail.comwrote: Strange, I've just tried the same thing on our z/OS 1.11 system and got - IKJ56425I LOGON rejected, UserId MAINT already logged on to system S0W1 IKJ56400A ENTER LOGON OR LOGOFF- Jim McAlpine Forget that, I forgot to specify reconnect. When I do it works as you say. Nice. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
Where? I know of the CPU Max in OMVS segment, but can that LIMIT the CPU used by a TSO id? It's got to be in the TSO segment, somewhere. You can specify it on the fullscreen logon. Or: LOGON tso-id TIME(nnn) That option is definitely controlled by ACF2 -- I know because there's a bug in their processing of it. Or, there was circa OS/390 2.10. I assumed that RACF controlled it, as well. But, I've never managed it under RACF. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
On Fri, 30 Apr 2010 09:21:41 -0500, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Mark Zelden wrote: What has changed from years ago (and I don't know exactly when without research) is that TIME=1440 used to turn off the accounting in SMF records, Please explain 'accounting in SMF records'. Does that means some SMF records were not written at all if TIME=1440 is used? Where is that history trivia documented? The records were written, just without (some of?) the CPU related data. I don't recall the specifics but it must have been fields in SMF 30 records and / or their predecessors. (This is where we need the SMF guru - of course I'm referring to Dr. Barry Merrill) Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jim McAlpine On Fri, Apr 30, 2010 at 3:47 PM, Chase, John jch...@ussco.com wrote: Install z/OS 1.11. I couldn't remember whether the logon here equivalent had been implemented in 1.11 or 1.12, but we have a new 1.11 image running in the sandbox so I tried it and it worked. Logged in from one emulator window with one terminal netname; opened another emulator window which got a different netname; performed a normal logon in the second window and got message IKT00300I LOGON RECONNECT SUCCESSFUL, SESSION ESTABLISHED. My old session in the original emulator window got disconnected. Strange, I've just tried the same thing on our z/OS 1.11 system and got - IKJ56425I LOGON rejected, UserId MAINT already logged on to system S0W1 IKJ56400A ENTER LOGON OR LOGOFF- Well, we haven't done any customization yet, and the Migration Guide for z/OS 1.9 - 1.11 says to do nothing to get the new (logon here) behavior. Check your IKJTSOxx member for the presence of LOGONHERE(OFF). -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
The all or nothing aspect, is they will NEVER time-out due to CPU consumption. JWT isn't CPU consumption, it is wait time (JWT=Job Wait Time). Yes, I know that JWT isn't CPU consumption. Perhaps I should have been clearer. TIME=1440/NOLIMIT will cause JWT to be ignored (the exit not being called), BUT it also stops S322 abends (CPU time exceeded). So, if I have a TSO user looping, it will never stop until cancelled. But you are correct that IEFUTL won't be called for TIME=1440. I knew that. What I was trying to say was that you get the added bonus of never abending with an S322. The init and tuning doesn't say so, but the same applies for TIME=NOLIMIT AFAIK. You're correct. I know it's documented somewhere, but I can't find it. What has changed from years ago (and I don't know exactly when without research) is that TIME=1440 used to turn off the accounting in SMF records, which is why you'll probably still find TIME=1439 coded in a lot of places . It was a very long time ago, and I know this because it was an issue for capacity analysts. When I took my first capacity planning course, in 1981, the instructor brought up the issue and said it was addressed in (irrc) the first release of MVS SP, which was called SP1 back then, and was later changed to MVS/SP 1.1. But TIME=1439 won't keep IEFUTL from being called for a wait. Nope. Just 1440 NOLIMIT. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
Please explain 'accounting in SMF records'. Does that means some SMF records were not written at all if TIME=1440 is used? SMF TYPE 30. INTERVAL, Job End, Step End. I believe, also TYPE 4 TYPE 5. It was a big issue, back when I started as a Capacity Analyst 30 years ago. Where is that history trivia documented? Changed in 1981. Doc long gone. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
Thanks to all and every one who replied to my questions and statements. I learned some things. Thanks again. ;-D I really hope the OP got his answers/solutions. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso session timeout
Mark Zelden wrote: The records were written, just without (some of?) the CPU related data. MVS 3.8 had sequential SMF data sets (SYS1.MANX and SYS1.MANY with DCB=(DSORG=PS,RECFM=VBS,LRECL=1000,BLKSIZE=1000) even though some records - from MF/1 for example - could be longer than 1000 bytes). The assumed purpose for recording CPU time seemed to be for chargeback, which may or may not have been the real reason, but it seems aligned with facts such as there were no job-level SMF records written for started tasks, and jobs with TIME=1440 specified were considered to consume CPU free of charge. (Indeed, the Fujitsu clone of MVS showed the word FREE under the CPU time column on the console when an operator command like D A,J was issued for jobs with TIME=1440. Later maintenance removed this, again following IBM's trend.) Also note that messages IEF373I-IEF376I were not issued at all for started tasks. In fact, started tasks did not have SMF control blocks like the TCT at all, so there was no way to count EXCPs at the address space or DD level in the general case. The initiator checked to see if job/step timing limits were in effect and if not, branched over the logic to store the consumed TCB and SRB times. Recently (2007) I submitted a job on my free MVS system with TIME=1440 so it could run as long as it needed to. The next day I checked to see how much CPU it had used. Zero was reported in IEF374I (yes, the message was issued and showed the VIRT and SYS, but the CPU times were zero) and in SMF (yes, the records were there but the CPU time fields were zero), so I could not find out (although I could deduce it from the elasped time and the fact that it was CPU bound). As a result I developed a usermod to zap IEFSD263 to move the code around so that the CPU times are stored before the check about job/step timing limits is made. This allows the CPU times to be reported in IEF374I and IEF376I messages, and recorded in SMF record types 4, 5, 34 and 35. http://www.prycroft6.com.au/vs2mods/zp60019.txt Back in the day, along came MVS/SE2 (a no-charge but licensed enhancement) which introduced VSAM SMF data sets (the sign bit of CVTSMCA can used to test for this), SMF type 30 records, SMF interval recording, full SMF accounting for started tasks, logical swapping for the TI and TO swap reasons, the IEAICSxx member of PARMLIB and the SET ICS=xx operator command, transaction classes (job classes were used purely for scheduling before this), etc. From this time on TIME=1440 no longer suppressed the recording of address space CPU times. At least, that's the way I remember it... Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
