One small nit : >> "First, a PC routine executable is in the STC and can't be seen by the >> caller" This may be true for PC-ss, however PC-cp routines are in "common" storage.
Personally I am a BIG fan of PC routines providing authorized services for unauthorized callers (provided they are written correctly), however they do need "someone" to own the linkage index and setup the ETEs. These days having some sort of resource owning address space to facilitate this is a sensible choice, however in the 1980/90s there was pushback from customers about having "another address space" on their system so you can (sort of) understand some ISV choices to implement AUTHPGM/TSF solutions back then. Would they make the same choice now? I doubt it. Rob Scott Rocket Software ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Jon Perryman <[email protected]> Sent: Monday, June 23, 2025 5:22 AM To: [email protected] <[email protected]> Subject: Re: AUTHCMD/AUTHPGM (was Re: In IBM-land, AFP means...) EXTERNAL EMAIL On Sun, 22 Jun 2025 00:54:15 -0700, Leonard D Woren <[email protected]> wrote: Out of curiosity, I asked Gemini to see what AI thinks about this (https://gemini.google.com/app/24656a95c1c0a7e9<https://gemini.google.com/app/24656a95c1c0a7e9>). Surprisingly it came close to my understanding and saves me from some typing. >Jon Perryman wrote on 6/21/2025 1:42 PM: >>Why would you want to write your own TMP? >Oh: Gemini says: TMP (Terminal Monitor Program): The TMP is a crucial service routine within TSO/E. Its primary function is to: Gemini says: Writing a TSO TMP" can be a bit of a misnomer, or at least, needs clarification. Gemini says: It's an IBM-supplied component (e.g., IKJEFT01, IKJEFT1A, IKJEFT1B). You generally do not "write" a new TMP from scratch to replace IBM's. You are far more likely to find what you need using "service routine" instead of TMP. Writing these is not difficult with today's TSO using various implementations. Requirements and design are the real problem. >1. Command Recall, but this can be done (clumsily) in TSO Session Manager. TSO command recall is not difficult but how do you exclude commands issued from a REXX exec (command ISPEXEC is useless for recall). How do you exclude ISPEXEC SELECT CMD()? How do you exclude commands from CALLTSSR? Intercepting the command is the simple part. Everything you need exists but you need to set requirements and design. It's messy no matter how you want to do it. >2. Environment variables. Everything needed for env variables exists. Automation products have implementations of environment variables. AutoOperator does it within a TSO environment. There is nothing stopping you from implementing them except the time needed to change every program. Unlike a Unix process, TSO has multiple concurrent activities (e.g. multiple unique ISPF screens. >3. More scripting languages, such as Perl. Scripting languages designed for a Unix process are very different to z/OS with address spaces. With enough time & money, IBM create z/OS Unix. With the same investment, it's likely a possibility but at what cost. I realize you are blueskying this but the answer is what has to change in the scripting language versus environmental changes (e.g. CICS, IMS, TSO, ISPF, SDSF, Tivoli and more). >>> (To be clear, >>> I mean the ability to write your own TMP that does that is not documented.) > >Well, it used to be. > > TSO_Extensions_Guide_to_Writing_a_Terminal_Monitor_Program_or_a_Command_Processor.SC28-1136-5.pdf Everything I've needed has been documented. How much has been renamed to service routines versus removed is the question. >> AUTHPGM >Deep? Nope. Maybe obscure. >https://www.ibm.com/docs/en/zos/3.1.0?topic=ikjeftsr-parameter-list<https://www.ibm.com/docs/en/zos/3.1.0?topic=ikjeftsr-parameter-list> >See Parameter 1, byte 4, x'02'. I had no doubt that I could find it but I've never had the need. PC routines accessing the STC much more useful than AUTHPGM. >> Using AUTHPGM is extremely dangerous because you are passing pointers >> instead of documented command text. > >I don't see it as dangerous, if the programmer understands and >rigorously follows the rules for doing it safely. In particular, if >you don't know the rules to do it safely, don't use this. How many times did they say this about SVC's only to have it cause security exposure? >> For me, PC routines have been sufficient. Realize that the TSO parser can be >> used without TSO. > >A PC routine done wrong can be just as dangerous as you think AUTHPGM >might be. Pick your poison. PC routines greatly reduce the risk. First, a PC routine executable is in the STC and can't be seen by the caller. Second, PC routines have function codes that associates each function to a unique program eliminating the use of a single program for multiple functions. Its much easier to spot security exposures when each function is clear, well defined and small. Third, very few people will attempt to use it because of the complexity. Fourth, logging possible abuses to know when someone is attempting break security. A simple call allows easy access by anyone to an AUTHPGM with pointers and data that is easily copied, modified and manipulated. Even AUTHCMD is safer than AUTHPGM. Commands are passed as command strings and responses are messages. No pointers and data to manipulate. Unlike most other address spaces, TSO has authorized and unauthorized programs running in the same address space. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ================================ Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
