The ability to terminate a TSO user with STOP is not used much, but I once worked with a shop that required, as part of their security/integrity environment, that a user never be allowed to reach 'TSO Ready'. The user was put into ISPF at logon and logged off upon exit from ISPF. Their focus was on preventing a user from busting out of ISPF to Ready, which at that time was a tough requirement.
It turned out that 'P userid' issued at any time during the TSO session would eventually cause immediate logoff upon exit from ISPF regardless of how long the ISPF session lasted. Problem solved. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: "McKown, John" <[email protected]> To: [email protected], Date: 12/05/2012 06:04 AM Subject: Re: Historical question regarding the stop command Sent by: IBM Mainframe Discussion List <[email protected]> To my remembrance, START, STOP, and MODIFY we all original commands in OS/360 (I can be wrong, I don't go back that far). They do not do asynchronous functions like "kill" does. They basically post an ECB. It is up to the program to periodically query this ECB (see the QEDIT macro). That's why entering a STOP command doesn't always STOP a broken STC. You can even STOP a batch job step. If the program is proper set up, it will process the STOP request and terminate. I don't know about today's environment, but in the past, if you did this and the program didn't remove the STOP request from the queue but terminated instead, then the initiator would see the STOP and it would shut down. This was many years ago, so it may not do this anymore. BTW, did you know that a TSO user's address space will honor a STOP command? But ISPF doesn't. So, in the old days, an operator could "P tsoid" and the user's TSO session would terminate when they next went to the READY prompt, usually at the end of a command. Since, to TSO, ISPF is basically a never-ending command, the P doesn't have much effect any more. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Paul Gilmartin > Sent: Wednesday, December 05, 2012 7:37 AM > To: [email protected] > Subject: Re: Historical question regarding the stop command > > On Dec 5, 2012, at 05:32, Martin, Larry D wrote: > > > > I believe the reason for the "Start in order to Stop" process is > required in order to stop Unix Daemons that are running as a part of > the process. I agree that the code to handle STOP and MODIFY commands > is quite simple, but I don't have any experience starting and stopping > Daemons. > > > The UNIX analogue is "kill" which sends any of several signals to a > process. For example, SIGINT tells processes designed to handle it to > prompt or seek additional command information elsewhere. SIGTERM warns > a process of imminent system shutdown; I believe that in the spirit of > POSIX, z/OS shutdown should send SIGTERM to dubbed tasks; others > reading this will feel strongly otherwise. SIGINT and SIGTERM are > fatal if not handled. SIGKILL is unconditionally fatal (think FORCE, > but not so destructive). > SIGHUP (HangUP) tells a process that its controlling terminal has been > disconnected. Etc. A couple signals are reserved for user/ISV > definition in any supplied application; often used for debugging. > > How does STOP work? Is MODIFY similar? Does either schedule an RB to > a task? What happens if that task is not prepared to deal with such an > RB? Which is older, STOP or MODIFY? > > -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
