On 13 May 2014 17:58, Jon Perryman <[email protected]> wrote: > As Tony said, they are all WTO messages. JES decides where it wants to put > the message (or not do anything with it).
Well I'm not so sure they're all WTOs. I think there's a PUT (likely RPL-type) interface to the JESYSMSG dataset that allocation writes to, and that those WTOs that do appear there are copied in by some piece of WTO/WTP processing that issues the PUT. In other words the JESYSMSG is primary, and WTOs are just one thing that can be written there. I doubt that JESn captures such messages only through the SSI, though they would presumably go there too. But I'm not current on JES2/3 or allocation/conversion/interpretation. > As for capturing messages USS mesages placing them into the appropriate job, > this may be more than you expect. I've given it some thought over some years. But yes, there are difficulties. > Some of the problems would be: > 1. Which parent/grandparent should receive the messages? The parent process for a process is well defined, though the parent may no longer exist. I think the algorithm would be to work up the ahnentafel until the first process with a job log is found. It might be as simple as the first process whose parent is 1. But even if it's more subtle, I don't think it's very difficult. More tricky is to avoid having two copies of all such messages in the SYSLOG. > 2. Will the messages truly be helpful since it will be more difficult to > associate messages to issuing process. I would insert a prefix containing the process and perhaps even thread ID. Since both IDs can be large, there would be some trouble with line length and wrapping, and even more with multi-line WTOs, but it could be done. > 3. BPXAS can be reused once the processes have terminated. In a busy UNIX > environment, this could either amount to a large number of messages for many > different processes that may or may not be related. The initiator is reused, but not the process ID, at least while it has offspring. IBM has this problem too and must deal with it; what if a process asks the kernel for its parent PID via getppid() and then tries to send it a message or something? I don't know the general UNIX semantics, but it surely wouldn't be acceptable for the message to go to some unrelated process that happened to get the same PID. IBM's scheme seems to have been to split notional 32-bit PIDs into two 16-bit pieces; the left half in some sense qualifies the right. If you issue a D OMVS,A=ALL and convert some of those huge PIDs to hex, you can easily see the split, and that the actual process IDs are quite small numbers. This suggests a limit of 64K active processes, which seems rather small in today's world. > Maybe a better alternative would be to use BPX_SHAREAS to share the address > space with related processes Sure - if it can be done it's probably better all round, and cheaper. But UNIX semantics in some cases require a new address space. > but it still leaves the problem where address space reuse with unrelated > processes. I'm not trying to discourage you > in doing. Just trying to make sure you know about some of the hurdles. Thanks. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
