If you like the benefits of many split screens then have a logon proc (Clist/REXX) create the split screens automagically for you each logon. I have 8 session created behind the scenes.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, June 05, 2018 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Weird thought for ISPF enhancement 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 ______________________________________________________________________ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
