<devilsadvocate> Do they really need to lock their TSO screen? Isn't having a windows locktime sufficient?
While this setting was certainly important during the golden age of terminals... how many of us actually use a terminal anymore? In the last 10 years? In the last 20 years? How many have a corporate defined windows screen lock? (I can't comment on Linux.. maybe some others can chime in) What actual security is enhanced by locking a 3270 terminal that is not addressed by locking the medium used to access the 3270 session? (this may be turning into a rant) I haven't actually given this much thought or examined my own reasoning for demanding locked sessions and auto-logoff for 3270.. but is the practice actually providing the security benefit so many time espoused and demanded? </devilsadvocate> Rob Schramm p.s. If I have gone too far afield in this thread.. I can start another one. On Wed, Jun 6, 2018 at 3:23 PM Clark Morris <cfmpub...@ns.sympatico.ca> wrote: > [Default] On 6 Jun 2018 04:53:49 -0700, in bit.listserv.ibm-main > john.archie.mck...@gmail.com (John McKown) wrote: > > >On Tue, Jun 5, 2018 at 4:02 PM Barry Merrill <ba...@mxg.com> wrote: > > > >> I left z/OS as a development platform, going to Windows in 1996 > >> for MXG Software totally because of the loss of everything under > >> TSO if I didn't hit enter every 45 minutes. > >> > > > >?The programmers here had the same complaint. We now have an IEFUTL exit, > >implemented in CA-OPS/MVS REXX, which will extend their wait time between > >06:00 and 18:00 on weekdays. That way they can go to meetings, lunch, and > >bull sessions without losing their place.? > > > They need to be able to lock their screens for this to be viable from > a security point of view. > > Clark Morris > > > >> > >> However, it is still the primary QA test platform, but using > >> batch instead of TSO. > >> > >> > >> Herbert W. "Barry" Merrill, PhD > >> President-Programmer > >> Merrill Consultants > >> MXG Software > >> 10717 Cromwell Drive > >> Dallas, TX 75229 > >> www.mxg.com > >> ba...@mxg.com > >> > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > >> Behalf Of Charles Mills > >> Sent: Tuesday, June 5, 2018 3:40 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Weird thought for ISPF enhancement > >> > >> Thanks. I will give that sort of thing a try. > >> > >> I *still* like John's weird thought. I work from a home office. I tend > to > >> be > >> a little loose with the demarcation between work and not work. > Sometimes I > >> get up from my PC. Sometimes I come back in 20 minutes. Sometimes I do > not. > >> I like that whether I am gone for ten seconds or ten hours, I find > Windows > >> right where I left it. It would be nice if ISPF were right where I left > it. > >> (I understand the resource and security advantages of a forced logoff. > >> John's weird thought would make that logoff more transparent.) > >> > >> Charles > >> > >> > >> -----Original Message----- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > >> Behalf Of Jerry Whitteridge > >> Sent: Tuesday, June 5, 2018 1:04 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Weird thought for ISPF enhancement > >> > >> I use a rexx exec to "script" all my sessions every time I logon. > >> > >> /* REXX */ > >> /* TRACE I */ > >> ADDRESS ISPEXEC > >> "SELECT PGM(ISPSTRT) PARM(SCRNAME SDSF2 PERM; =SDSF; SWAP LAST) " > >> "SELECT PGM(ISPSTRT) PARM(SCRNAME EDIT1 PERM; =2; SWAP LAST)" > >> /*ELECT PGM(ISPSTRT) PARM(SCRNAME EDIT2 PERM; =2; SWAP LAST)" */ "SELECT > >> PGM(ISPSTRT) PARM(SCRNAME MYDS PERM; REFOPEND; SWAP LAST)" > >> "SELECT PGM(ISPSTRT) PARM(SCRNAME BROWSE1 PERM; =1; SWAP LAST)" > >> "SELECT PGM(ISPSTRT) PARM(SCRNAME TSO PERM; =6; SWAP LAST)" > >> "SELECT PGM(ISPSTRT) PARM(SCRNAME DSLIST PERM; =3.4; SWAP LAST)" > >> "SELECT PGM(ISPSTRT) PARM(TSO WORKPL)" > >> EXIT(0) > >> > >> > >> I call this SESSTART and simply do a TSO SESSTART as soon as I am at the > >> Primary option menu after logging on. (In 2.2 or above I believe this > can > >> be > >> done automagically). > >> > >> > >> Jerry Whitteridge > >> Delivery Manager / Mainframe Architect > >> GTS - Safeway Account > >> 602 527 4871 <(602)%20527-4871> Mobile > >> jerry.whitteri...@ibm.com > >> > >> IBM Services > >> > >> IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on > >> 06/05/2018 12:33:59 PM: > >> > >> > From: Charles Mills <charl...@mcn.org> > >> > To: IBM-MAIN@LISTSERV.UA.EDU > >> > Date: 06/05/2018 12:34 PM > >> > Subject: Re: Weird thought for ISPF enhancement Sent by: IBM Mainframe > >> > Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > >> > > >> > I really like it. I have an associate who sets up some elaborate > >> > configuration of SPLITs. He is always selling me on the benefits. I > >> > see the benefits, but one of the reasons I do not follow suit is > >> > because of the need to re-do it on every logon. If I could just have > >> > ISPF automatically restore my previous setup it would be great. > >> > > >> > Charles > >> > > >> > > >> > -----Original Message----- > >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] > >> > On Behalf Of John McKown > >> > Sent: Tuesday, June 5, 2018 11:51 AM > >> > To: IBM-MAIN@LISTSERV.UA.EDU > >> > Subject: Weird thought for ISPF enhancement > >> > > >> > I'm short of sleep ... again. When I came to work this morning, my > >> > Chrome browser was "dead". When I restarted it, it prompted me with a > >> > message asking if I wanted to restore all the pages I had been on. > >> > > >> > So, what occurred to me was, "Wouldn't it be nice if ISPF could do > >> > something like that." Now, ISPF doesn't really die often. But I think > >> > it would be a nice feature if there were a new ISPF command, perhaps > >> > called something like "SAVELEAVE" or HIBERNATE or whatever. This > >> > facility would let you logoff for the day, optionally SAVEing any > >> > changes if you're in EDIT or one or more screens. When you come in the > >> > next day, ISPF would > >> give > >> > you an option to restore all your screens. Yes, there are problems > >> > about restarting an ISPF application, but basically you could only > >> > issue the above command at certain times, just like you can only SWAP > >> > or SPLIT, > >> when > >> > you're in an DISPLAY verb. What I envision for an ISPF application is > >> that > >> > it would get a special RC from the ISPF DISPLAY verb which would > >> > indicate "user wants to leave, checkpoint or abandon your processing". > >> > The application could then only do something like ISPF CHECKPOINT > >> > which would basically return to ISPF and ISPF would terminate the > >> > application. The application would need to save its non-ISPF > >> > environment (close files, > >> etc) > >> > before it issued the CHECKPOINT. When the user gets back into ISPF, > >> > the application is restarted at the next instruction after the > >> > CHECKPOINT. At this point, the application would be responsible to > >> > restore its internal, non-ISPF maintained, status (open files, reload > >> important variable, etc). > >> > This would occur for each active screen which did the ISPF CHECKPOINT. > >> > Well, that's likely getting too detailed for a general, initial, > >> discussion. > >> > > >> > ---------------------------------------------------------------------- > >> > For IBM-MAIN subscribe / signoff / archive access instructions, send > >> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, send > email > >> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, send > email > >> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
