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
