Re: tso racf
On Thu, 25 Oct 2007 00:38:17 -0500 Tom Schmidt [EMAIL PROTECTED] wrote: :On Wed, 24 Oct 2007 22:38:03 -0400, Binyamin Dissen wrote: :What PCF did well was protect APF authorized CPs. :You could not circumvent PCF unless you had the ability to write into an APF :library, which if you can - you can do whatever you want anyway. :Oh yes I could (and did)! I could run any APF or non-APF command processor :on the system where I had no write access to their APF libraries. :That's why it was a joke. I don't understand. Did you have the ability to update the APF libraries? If yes, security isn't going to be able to constrain you. If no, but you have access from another system - ditto. If not at all, it would not help you to copy the APF-program to another library as it will not be APF when you execute it. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
TSO runs from an APF Library itself. The TSO command CALL *(PROGRAM) can run an APF service directly as TSO is already an Authorized Product. Only a CALL statement from a program whose load member is not in an APF library is blocked from calling one that is in an APF library. In other wards, any non APF program running under TSO can access an APF routine by changing CALL statements with the above TSO command, and invoking the command from the program using TSOLINK. Darren -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Binyamin Dissen Sent: Thursday, October 25, 2007 9:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf On Thu, 25 Oct 2007 00:38:17 -0500 Tom Schmidt [EMAIL PROTECTED] wrote: :On Wed, 24 Oct 2007 22:38:03 -0400, Binyamin Dissen wrote: :What PCF did well was protect APF authorized CPs. :You could not circumvent PCF unless you had the ability to write into an APF :library, which if you can - you can do whatever you want anyway. :Oh yes I could (and did)! I could run any APF or non-APF command processor :on the system where I had no write access to their APF libraries. :That's why it was a joke. I don't understand. Did you have the ability to update the APF libraries? If yes, security isn't going to be able to constrain you. If no, but you have access from another system - ditto. If not at all, it would not help you to copy the APF-program to another library as it will not be APF when you execute it. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Thu, 25 Oct 2007 09:35:51 -0700 GAVIN Darren * OPS EAS [EMAIL PROTECTED] wrote: :TSO runs from an APF Library itself. True. :The TSO command CALL *(PROGRAM) can run an APF service directly as TSO :is already an Authorized Product. It will only be authorized if: 1. The program is defined as authorized in IKJTSO/AUTHPGM (or IKJEFTE2/E8 - I forget which was commands and which was programs) 2. It comes from an authorized library. 3. It has AC=1 Missing any of those it will not run authorized. :Only a CALL statement from a program whose load member is not in an APF :library is blocked from calling one that is in an APF library. It can, by using the TSO service to invoke the parallel TMP. :In other wards, any non APF program running under TSO can access an APF :routine by changing CALL statements with the above TSO command, and :invoking the command from the program using TSOLINK. Only if the three clauses above apply. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
George Fogg wrote: BTW, does the ISPF exits run authorized? I read the manual but not quite sure if they do. No. AC=00 by default. These exits must be re-usable, preferably reentrant, because they are loaded once during logon. AMODE=31, RMODE=ANY. HTH! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, October 23, 2007 5:26 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf That way you know the user was safely tucked into ISPF. Why do we care? What problem are we solving by restricting access to the READY prompt? I've already asked this question; received no response. - Why? IT is here to serve! We aren't here to ask questions such as why?. That's management's job. And given some managers that I've had the misfortune to work with, the answer is most likely because I said so, damn it! sysprog type=frustrated/ -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
i never said i liked the approach i was asked to do. as a matter of fact i dont. but, i kind of like to eat.etc... so , i am trying to do what my boss has asked me to do. we all have little quirks, so this isnt no big deal. i really do appreciate all of your comments and suggjestions. i will put a 'logoff' command at the end of the logon clist. Thank you Bill Carroll -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Wednesday, October 24, 2007 9:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, October 23, 2007 5:26 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf That way you know the user was safely tucked into ISPF. Why do we care? What problem are we solving by restricting access to the READY prompt? I've already asked this question; received no response. - Why? IT is here to serve! We aren't here to ask questions such as why?. That's management's job. And given some managers that I've had the misfortune to work with, the answer is most likely because I said so, damn it! sysprog type=frustrated/ -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html EMAIL DISCLAIMER: The information contained in this message may be privileged or confidential and is protected from disclosure. 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, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, October 23, 2007 5:26 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf That way you know the user was safely tucked into ISPF. Why do we care? What problem are we solving by restricting access to the READY prompt? I've already asked this question; received no response. SNIP PHB Syndrome -- Opinions are my own -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
Ted MacNEIL wrote: That way you know the user was safely tucked into ISPF. Why do we care? What problem are we solving by restricting access to the READY prompt? I've already asked this question; received no response. Perhaps the users targeted for this behavior don't know how to type LOGOFF at the READY prompt. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Wed, 2007-10-24 at 09:55 -0700, Edward Jaffe wrote: Perhaps the users targeted for this behavior don't know how to type LOGOFF at the READY prompt. Harumph. MY users generally just click the little 'X' on the top right corner of the emulator screen and let LOSTERM sort it out. Makes me nuts. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 17:04:56 -0700, George Fogg wrote: BTW, does the ISPF exits run authorized? I read the manual but not quite sure if they do. George, It doesn't matter (much) whether the exits are authorized or not if all you do is issue a WTO to alert your automation package that it is safe (but not necessarily required) to issue the STOP command to the source TSO address space now. -- Tom Schmidt Madison, WI (The difference between authorized or not is whether or not the + prefixes the WTO in the display; you'll learn which right after the 1st WTO.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 20:11:33 -0500 Tom Schmidt [EMAIL PROTECTED] wrote: :I well understood what PCF's goal was, but my point was that it was FAR too :easy to circumvent the command 'control' portion. As long as you (or a friend) :had program access to ANY library that you could execute from (without using :TSO TEST) you could install your own command processor (same name, :different purpose) that could then trivially circumvent PCF. There were other :means of bypassing PCF, too, but I usually used that, my favorite mechanism. :(Dance with the one that brought you.) What PCF did well was protect APF authorized CPs. You could not circumvent PCF unless you had the ability to write into an APF library, which if you can - you can do whatever you want anyway. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 17:04:56 -0700, George Fogg wrote: BTW, does the ISPF exits run authorized? I read the manual but not quite sure if they do. George, It doesn't matter (much) whether the exits are authorized or not if all you do is issue a WTO to alert your automation package that it is safe (but not necessarily required) to issue the STOP command to the source TSO address space now. Tom: I was thiking I would let the ISPF exit deal with the P userid command so I would build a trusted token and pass that in the MGCRE call, which of course, requires authorization of some type to do these calls. The trusted token would bypass the authorization check to issue the P userid command. That is, if I want to do such a thing. George Fogg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Wed, 24 Oct 2007 22:38:03 -0400, Binyamin Dissen wrote: What PCF did well was protect APF authorized CPs. You could not circumvent PCF unless you had the ability to write into an APF library, which if you can - you can do whatever you want anyway. Oh yes I could (and did)! I could run any APF or non-APF command processor on the system where I had no write access to their APF libraries. That's why it was a joke. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 12:21 PM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or anyother method. Thank You Bill Carroll If you mean stop them from issuing a specific command, then yes. If you mean stop them from issuing any command at all, then I don't think so. Why? Well, if you could, then what would the user do? They'd get the READY prompt, but not be able to start up ISPF or anything else. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 13:20:59 -0400, Carroll, William wrote: is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or anyother method. This sounds more like a management problem than a technical problem. While you can sometimes address management problems by technical means, the overall satisfaction rate isn't as high as most folks might expect. Maybe it would help us help you if you could describe your problem a little better? -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 1:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll I would guess that you actually invoke some sort of start up CLIST or REXX program. If so, then after the line which invokes ISPF, put in the LOGOFF command. You would also need to capture any attention exits. In CLIST, you could put the lines: ATTN + DO LOGOFF END At the top of the startup CLIST. In REXX, I think that you'd SIGNAL ON HALT ... HALT: LOGOFF This doesn't do anything for disabling ISPF option 6, or keep the person from doing a TSO somecmd on almost any screen to invoke somecmd while in ISPF. So, the general answer is still NO. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
The parm that you are passing could be a CLIST, constructed along these lines: PROC 0 do some allocates and stuff start ISPF LOGOFF As soon as the user leaves ISPF it should log them off Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 2:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
Hi William. On the last question you could easily do it this way. Just add the command 'LOGOFF' within thier TSO segment of RACF. Works every time. HTH Claude Richbourg -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 2:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll EMAIL DISCLAIMER: The information contained in this message may be privileged or confidential and is protected from disclosure. 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, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 1:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. SNIP Do your programmers use any tools, such as TSO TEST that can't be run under ISPF? Do you programmers do any panel development? If so, then (re)starting ISPF with the TEST option (or the use of some other parm) will become problematic. Systems programmers are not the only ones that sometimes need TSO READY prompts. Loss of such functionality may become quite painful. It is something for consideration. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Richbourg, Claude Sent: Tuesday, October 23, 2007 1:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf Hi William. On the last question you could easily do it this way. Just add the command 'LOGOFF' within thier TSO segment of RACF. Works every time. HTH Claude Richbourg Couldn't the user just blank that out on the TSO logon screen? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
yes they can, that is why i need to go after it another way. such as updating the startup clist. Bill Carroll -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, October 23, 2007 2:46 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Richbourg, Claude Sent: Tuesday, October 23, 2007 1:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf Hi William. On the last question you could easily do it this way. Just add the command 'LOGOFF' within thier TSO segment of RACF. Works every time. HTH Claude Richbourg Couldn't the user just blank that out on the TSO logon screen? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html EMAIL DISCLAIMER: The information contained in this message may be privileged or confidential and is protected from disclosure. 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, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
yes they can, that is why i need to go after it another way. Since people can enter almost all TSO commands under ISPF, I am trying to figure out your need. What problem are you trying to solve? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Oct 23, 2007, at 1:28 PM, Carroll, William wrote: is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll Bill, I do not know if IBM still sells it but at one time there was a product called PCF. It was cheap IIRC and it worked quite well. I was responsible for it for over 20 years and I never had an issue with it. Just to give you an idea there is a table which has all TSO commands in it and a level that you must have before the command will be executed. The level is kept in UADS (or RACF IIRC). There is also a table that restricts where a user can allocate new datasets. a lot of the function of it has been doled out to other products (SMS RACF etc) but I believe this product is a lot easier to implement and you don't have to fool around with RACF to get a clean yes/no answer to the question am I allowed to do this command. BTW PCF = Program Control Facility Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
Don, Could I create a CLIST/REXX called LOGOFF that would bypass this process so long as my CLIST/REXX called LOGOFF is at the top of the concatenation of the SYSPROC or EXEC DD Statement? Lizette The parm that you are passing could be a CLIST, constructed along these lines: PROC 0 do some allocates and stuff start ISPF LOGOFF As soon as the user leaves ISPF it should log them off Don Imbriale -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
Being an applications programmer, I can say that doing such a thing would prevent me from doing certain aspects of my job. Which includes setting up or modifying personal command tables, non ISPF Clist's, REXX utilities, mainframe FTP, receiving notices issued by send commands, unpacking XMIT'd PDS libraries, etc... I'd want to have a serious talk to any manager that thought I shouldn't have access to TSO Ready Prompt. If they wouldn't change their minds about it, it would be time to find another Job. TSO Ready Prompt is too useful of a tool for any programmer (systems or application) to put up with that sort of foolish and uninformed decision. Darren -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Tuesday, October 23, 2007 11:28 AM To: IBM-MAIN@BAMA.UA.EDU Subject: tso racf is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
To invoke your LOGOFF, the command would need to be entered as %LOGOFF to force search of SYSPROC/SYSEXEC before the usual order which will find the standard command. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Tuesday, October 23, 2007 3:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: tso racf Don, Could I create a CLIST/REXX called LOGOFF that would bypass this process so long as my CLIST/REXX called LOGOFF is at the top of the concatenation of the SYSPROC or EXEC DD Statement? Lizette The parm that you are passing could be a CLIST, constructed along these lines: PROC 0 do some allocates and stuff start ISPF LOGOFF As soon as the user leaves ISPF it should log them off Don Imbriale *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 12:30:34 -0700, GAVIN Darren * OPS EAS [EMAIL PROTECTED] wrote: Being an applications programmer, I can say that doing such a thing would prevent me from doing certain aspects of my job. Which includes setting up or modifying personal command tables, non ISPF Clist's, REXX utilities, mainframe FTP, receiving notices issued by send commands, unpacking XMIT'd PDS libraries, etc... I'd want to have a serious talk to any manager that thought I shouldn't have access to TSO Ready Prompt. If they wouldn't change their minds about it, it would be time to find another Job. TSO Ready Prompt is too useful of a tool for any programmer (systems or application) to put up with that sort of foolish and uninformed decision. I agree with for any programmer. I have seen shops implement such things for other users. There are usually ways around it if you try hard enough... but without at least the attn exits (CLIST or REXX), it is very easy to get around. One way around it (even with trapping attn) is to make ISPF abend. Exactly how to do that is left as an exercise to the reader. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
TSO Ready Prompt is too useful of a tool for any programmer (systems or application) to put up with that sort of foolish and uninformed decision. I agree with you, especially since you can do almost everything under ISPF that you can do with the READY prompt. TSOEXEC makes that possible. Not that I use READY very much anymore. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
McKown, John wrote: snip This doesn't do anything for disabling ISPF option 6, or keep the person from doing a TSO somecmd on almost any screen to invoke somecmd while in ISPF. So, the general answer is still NO. snip I think ISPF Exit 5 (its TSO Command Exit) can restrict that, though. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
We have a CLIST that is invoked by putting the following at the front of any CLIST/EXEC that needs protecting. It checks an ISPF table, by userid, for authorization. EdP * Top of Data ** PROC 0 /**/ /**/ /* CONTROL CONLIST SYMLIST LIST /** /* CHECK AUTHORIZATION /** %AUTH DBLOG ISPEXEC VGET (AUTH) IF AUTH = STR(N) THEN EXIT /** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 14:20:10 -0500, Ed Gould wrote: I do not know if IBM still sells it but at one time there was a product called PCF. It was cheap IIRC and it worked quite well. I was responsible for it for over 20 years and I never had an issue with it. Just to give you an idea there is a table which has all TSO commands in it and a level that you must have before the command will be executed. The level is kept in UADS (or RACF IIRC). There is also a table that restricts where a user can allocate new datasets. a lot of the function of it has been doled out to other products (SMS RACF etc) but I believe this product is a lot easier to implement and you don't have to fool around with RACF to get a clean yes/no answer to the question am I allowed to do this command. BTW PCF = Program Control Facility PCF was a joke as far as 'TSO security' was concerned. As long as you understood how TSO's command processors work and a quick understanding of PCF's working storage it can be a matter of minutes before you can build a working prototype to bypass PCF. (At least it was for me about 20 years ago.) I would not recommend it on that basis. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 14:40:40 -0400, Imbriale, Donald wrote: The parm that you are passing could be a CLIST, constructed along these lines: PROC 0 do some allocates and stuff start ISPF LOGOFF As soon as the user leaves ISPF it should log them off If you are an applications programmer bent on actually doing your job (in spite of spiteful managers elsewhere): To defeat Don's mechanism you need to clear the TSO command stack prior to leaving ISPF. Read the TSO publications to find out how to do that. It isn't particularly hard and is a worthwhile exercise in programming by itself. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
I worked with a shop some years ago that had a similar requirement. For a certain class of user, management wanted this: 1. LOGON 2. Be placed immediately into ISPF 3. Exit ISPF 4. LOGOFF In other words, these users were not allowed to sit at Ready. Don't remember why. Doesn't matter. There turned out to be a simple solution. The 'moment' the user gets logged on and enters ISPF, issue this MVS command: P userid . It's not documented well (or maybe at all), but a TSO user in the 'stopping state' (my term), can continue the 'current operation' but will be logged off at the conclusion of that operation. ISPF is treated as one long continuous operation. The moment you exit ISPF, you are logged off. You can try this for yourself. We tried to break the sequence with abend and Attention keys, but the result was always the same: once ISPF ends, you're gone. The mechanism for issuing the P command is left as an exercise for a sysprog more highly motivated than this one. ;-) . . 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] Carroll, William [EMAIL PROTECTED] To NSURANCE.COM IBM-MAIN@BAMA.UA.EDU Sent by: IBM cc Mainframe Discussion List Subject [EMAIL PROTECTED] tso racf .EDU 10/23/2007 11:28 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU is there anyway to block or ignore or stop somebody from entering a command on the command prompt through RACF, or any other method. i know i can put a command on the 'proc' execute, passing it as a parm, during the logon process. my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. I apologize for not giving a more accurate picture to begin with. TIA Bill Carroll -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
I worked with a shop some years ago that had a similar requirement. For a certain class of user, management wanted this: 1. LOGON 2. Be placed immediately into ISPF 3. Exit ISPF 4. LOGOFF In other words, these users were not allowed to sit at Ready. Don't remember why. Doesn't matter. There turned out to be a simple solution. The 'moment' the user gets logged on and enters ISPF, issue this MVS command: P userid . It's not documented well (or maybe at all), but a TSO user in the 'stopping state' (my term), can continue the 'current operation' but will be logged off at the conclusion of that operation. ISPF is treated as one long continuous operation. The moment you exit ISPF, you are logged off. Skip: Seems to work OK. Now you need a bulletproof solution to force those users to be placed in ISPF at logon and find a way to issue the P userid command. I think it can be done in RACF's post-processing exit. George Fogg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
Carroll, William wrote: ... my management wants to know if i can block the command prompt for non-system programmer folks. so when they exit ispf, they get logged off of tso as well. What's wrong with giving users access to the READY prompt? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 14:58:23 -0700, George Fogg wrote: I worked with a shop some years ago that had a similar requirement. For a certain class of user, management wanted this: 1. LOGON 2. Be placed immediately into ISPF 3. Exit ISPF 4. LOGOFF In other words, these users were not allowed to sit at Ready. Don't remember why. Doesn't matter. There turned out to be a simple solution. The 'moment' the user gets logged on and enters ISPF, issue this MVS command: P userid . It's not documented well (or maybe at all), but a TSO user in the 'stopping state' (my term), can continue the 'current operation' but will be logged off at the conclusion of that operation. ISPF is treated as one long continuous operation. The moment you exit ISPF, you are logged off. Skip: Seems to work OK. Now you need a bulletproof solution to force those users to be placed in ISPF at logon and find a way to issue the P userid command. I think it can be done in RACF's post-processing exit. George, That might be too early - under some odd timing conditions you might succeed (FSVO 'succeed') in logoff prior to ISPF (which would frustrate the end users and waste the company's resources... who's the bad guy then?) I would suggest pushing out an operator message in an ISPF initialization exit and letting automated operations issue the STOP command. That way you know the user was safely tucked into ISPF. I would also suggest that it should be mandatory that this 'feature' be verified documented as an intended interface by IBM before using it. (I've used it in the dim past for a few things but none were particularly long-term. It worked for me, for example, when running a CLIST in a started task doing TSO RECEIVE (as in XMIT/RECEIVE) processing many years ago. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
That way you know the user was safely tucked into ISPF. Why do we care? What problem are we solving by restricting access to the READY prompt? I've already asked this question; received no response. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 14:58:23 -0700, George Fogg wrote: I worked with a shop some years ago that had a similar requirement. For a certain class of user, management wanted this: 1. LOGON 2. Be placed immediately into ISPF 3. Exit ISPF 4. LOGOFF In other words, these users were not allowed to sit at Ready. Don't remember why. Doesn't matter. There turned out to be a simple solution. The 'moment' the user gets logged on and enters ISPF, issue this MVS command: P userid . It's not documented well (or maybe at all), but a TSO user in the 'stopping state' (my term), can continue the 'current operation' but will be logged off at the conclusion of that operation. ISPF is treated as one long continuous operation. The moment you exit ISPF, you are logged off. Skip: Seems to work OK. Now you need a bulletproof solution to force those users to be placed in ISPF at logon and find a way to issue the P userid command. I think it can be done in RACF's post-processing exit. George, That might be too early - under some odd timing conditions you might succeed (FSVO 'succeed') in logoff prior to ISPF (which would frustrate the end users and waste the company's resources... who's the bad guy then?) It is too early in the process as I just found out. I issued a P userid after the READY prompt and before the userid went into ISPF so when the user tried to get into ISPF then boom, the user was forced to logon or logoff. The RACF post-processing is not a choice. Messages I got at READY prompt when entering ISPF : IKJ56620I MVS STOP command encountered. TSO/E session is terminated. IKJ56470I USR000 LOGGED OFF TSO AT 15:26:27 ON OCTOBER 23, 2007 IKJ56400A ENTER LOGON OR LOGOFF- George Fogg I would suggest pushing out an operator message in an ISPF initialization exit and letting automated operations issue the STOP command. That way you know the user was safely tucked into ISPF. Does the I would also suggest that it should be mandatory that this 'feature' be verified documented as an intended interface by IBM before using it. (I've used it in the dim past for a few things but none were particularly long-term. It worked for me, for example, when running a CLIST in a started task doing TSO RECEIVE (as in XMIT/RECEIVE) processing many years ago. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Oct 23, 2007, at 3:17 PM, Tom Schmidt wrote: PCF was a joke as far as 'TSO security' was concerned. As long as you understood how TSO's command processors work and a quick understanding of PCF's working storage it can be a matter of minutes before you can build a working prototype to bypass PCF. (At least it was for me about 20 years ago.) I would not recommend it on that basis. The issue is command control NOT anything else. If you had access to the library then you could bypass all command checking by running the the command under test library(asm) cp but we nave gave out access to the library where commands where. But you are correct about dataset security it was easily bypassable. In fact if you get access to where the 2 byte security key was (read only protected storage) if I remember correctly you could do anything. Its the same story with RACF though if you are authorized you can bypass any security package. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
Ted Macneil said: Why do we care? Edward Jaffe said: What's wrong with giving users access to the READY prompt? Ted and Ed. In my case, I'm just curious if it can be done--not that I would suggest that we do this in our shop. BTW, does the ISPF exits run authorized? I read the manual but not quite sure if they do. George Fogg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 17:53:05 -0500, Ed Gould wrote: On Oct 23, 2007, at 3:17 PM, Tom Schmidt wrote: PCF was a joke as far as 'TSO security' was concerned. As long as you understood how TSO's command processors work and a quick understanding of PCF's working storage it can be a matter of minutes before you can build a working prototype to bypass PCF. (At least it was for me about 20 years ago.) I would not recommend it on that basis. The issue is command control NOT anything else. If you had access to the library then you could bypass all command checking by running the the command under test library(asm) cp but we nave gave out access to the library where commands where. But you are correct about dataset security it was easily bypassable. In fact if you get access to where the 2 byte security key was (read only protected storage) if I remember correctly you could do anything. Its the same story with RACF though if you are authorized you can bypass any security package. Ed, I well understood what PCF's goal was, but my point was that it was FAR too easy to circumvent the command 'control' portion. As long as you (or a friend) had program access to ANY library that you could execute from (without using TSO TEST) you could install your own command processor (same name, different purpose) that could then trivially circumvent PCF. There were other means of bypassing PCF, too, but I usually used that, my favorite mechanism. (Dance with the one that brought you.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Oct 23, 2007, at 8:11 PM, Tom Schmidt wrote: Ed, I well understood what PCF's goal was, but my point was that it was FAR too easy to circumvent the command 'control' portion. As long as you (or a friend) had program access to ANY library that you could execute from (without using TSO TEST) you could install your own command processor (same name, different purpose) that could then trivially circumvent PCF. There were other means of bypassing PCF, too, but I usually used that, my favorite mechanism. (Dance with the one that brought you.) -- Tom, One of the hidden benefits of PCF was that it gave you a little performance boost when executing commands as it assumed that all TSO commands were in LPALIST. I thought that this was a nice feature as well. This was before LLA so I am not sure if it would be that much of a buyback. I basically took every command and divided them into two groups sysprogs and applications that did make life easier. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
