On Tue, 2 Sep 2025 14:55:54 +0000, Lennie Bradshaw <[email protected]> wrote:
>Will the 'S' line always follow immediately after the 'N' line? (i.e. could >another line come between them? >That does address my concerns. This means my code works as well, which is >nice😊. It would be extremely unlikely that the S and N line would be separated, it is not a 100% guarantee. Additionally, I don't believe an 'S' line will occur if everything fits into th first line. I don't know SDSF log, but you should find the SDSF manual that documents these characters. I would expect similar characters to the hardcopy log that is documented in the first MVS manual https://www.ibm.com/docs/en/zos/2.1.0?topic=format-messages-sent-hardcopy-log-in-jes2-system If SDSF log solves your problem, then stick with it. However, it does have some quirks that you may not have considered (e.g. S, N, ...). All log messages originate from the SSI. Like all other products using messages from the SSI, information about the message will be lost or substituted with user friendly values (e.g. S, N, ...). I believe log stream provides a mirror copy of each message directly from the SSI. I'm not recommending it but only making you aware, and why it exists. It will be more involved than your current solution but it has all information about each message. I don't know what you need but you might consider your automation software which handles messages in a more coherent manner. MLWTO's can be tough to handle outside the SSI. Consider 3 commands from the same EMCS console id at the same time. Associating each response to the issuing command is not as simple as using the console id. Instead, MLWTO's are associated to the primary message which probably is not available through SDSF. >(o) ehere will only be a single "S" as we split on 73 bytes of message text >and 2x73 > maximum single WTO text length. A primary message can be larger than 73 bytes but will always be shorter than 2x73. 126 comes to mind but I'm not sure why. MLWTO secondary messages are much shorter. I suspect less than 73 bytes. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
