You might see if the WRITE Statements in the ACS code might be helpful. It can produce statements to SYSLOG in any format with the vars available to SMS.
So you could have IF JOBNAME = "BPXAS" Then DO WRITE END Or something similar. DSN, VOLUME, UNIT, USER, and a few other might be used to do the IF THEN test with. The write statements should go into the task or SYSLOG, but as always, it depends..... I have not tested with USS address spaces, but it might work. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tony Harminc > Sent: Tuesday, May 13, 2014 5:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where are the allocation messages of a USS process? > > On 13 May 2014 17:58, Jon Perryman <jperr...@pacbell.net> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
