>> Since BPXEKDA doesn't need the OMVS segment for the first 40 bytes of the >> command, why does it need it for the rest of the command? Isn't it just a >> null terminated field that can be fully copied?
My educated guess here is that BPXEKDA is used by the "D OMVS" operator command and provides an interface layer between the z/OS unix control blocks and the display command service, most likely via a PC-ss, and just gathers the required information without going through the dubbing process. Behind the scenes there is probably one or more tables in OMVS private storage describing the current processes. Using this interface also makes sense that operator commands can gather information independently of possible environmental problems that could affect BPX1/4 callable services. Due to console screen real estate, I imagine that the original authors returned only the characters that they needed for the display command response. To get more characters from BPXEKDA, there would have to be an enhancement to that service so that consumers like SDSF could display more data. OR The other alternative is that consumers like SDSF, call BPX(1/4)GTH in some fashion to gather the full text. I know where I would put my money on which could happen faster. As to "why don't you just fix it ?" style questions, we have to consider quite a few compatibility issues across n-2 releases especially when the "fix" requires changes to configuration and security for either (or both of) the SDSF server(s) and client users. Rob Scott Rocket Software -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Jon Perryman Sent: Monday, February 5, 2024 3:44 AM To: [email protected] Subject: Re: SDSF PS Command column EXTERNAL EMAIL On Sat, 3 Feb 2024 09:24:07 +0000, Rob Scott <[email protected]> wrote: >SDSF calls the BPXEKDA service returns truncated command information. Since BPXEKDA doesn't need the OMVS segment for the first 40 bytes of the command, why does it need it for the rest of the command? Isn't it just a null terminated field that can be fully copied? >We have an existing RFE to provide more information. My guess is that the RFE includes more than just the command which probably need dubbing. I would think you could just as easily copy 100 bytes as 40 bytes. > When the PS command was originally written OMVS segments were not > commonplace and the design goal was to provide the data without being > dubbed In the past, dubbing caused some conflicts in some OEM products. For example, I was a developer for an automation product that included multi-tasking & multi-user TSO in the address space (also TCP tasks). You might introduce similar problems in the console address space so you will need more than simple testing. >BPXEKDA is used by the operator command responses which probably explains the >truncation length. I suspect the truncation is by choice. One possibility for the limitation is MLWTO secondary messages having a max length of 80. Another possibility is security.where the user does not have an OMVS segment to restrict access to processes. A third possibility would be TSO CONSOLE & OPER commands where output flooding. Fourth, it might introduce problems with MPF processing & message suppression. It might also be an issue with syslog. It could also introduce bad habits in automation products. ---------------------------------------------------------------------- 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
