Re: Where are the allocation messages of a USS process?
Thanks Kirk for the pointer to the doc and others for pointing out the unavoidable complexing situations. One question to possibly avoid the problem of where to write the files with all their considerations: we have a Syslog Deamon running, can I have the messages sent to this place? That would be quite helpful. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Tuesday, May 13, 2014 17:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where are the allocation messages of a USS process? often the answer is nowhere. See this for a solution: http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.bpxb200%2Fjobpro.htm Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, May 13, 2014 at 6:32 AM, Vernooij, CP (SPLXM) - KLM kees.verno...@klm.com wrote: Hello group, We have some dataset problems with USS processes and are looking for the allocation messages. I mean the IGD101I SMS ALLOCATED TO DDNAME (DSNIWK02) DSN (SYS14131.T210019.RA000.XI1DMS1A.R0141149) STORCLAS (SCBATCH) MGMTCLAS () DATACLAS () VOL SER NOS= VIO and similar that you see in the message file of a job or STC or even in Syslog for an STC under MSTR. Where do these and other messages going for a USS process? A BPXAS STC is started for the process, but this only contains the messages for the BPXAS itself. Thanks, Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Where are the allocation messages of a USS process?
Hello group, We have some dataset problems with USS processes and are looking for the allocation messages. I mean the IGD101I SMS ALLOCATED TO DDNAME (DSNIWK02) DSN (SYS14131.T210019.RA000.XI1DMS1A.R0141149) STORCLAS (SCBATCH) MGMTCLAS () DATACLAS () VOL SER NOS= VIO and similar that you see in the message file of a job or STC or even in Syslog for an STC under MSTR. Where do these and other messages going for a USS process? A BPXAS STC is started for the process, but this only contains the messages for the BPXAS itself. Thanks, Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
often the answer is nowhere. See this for a solution: http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.bpxb200%2Fjobpro.htm Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, May 13, 2014 at 6:32 AM, Vernooij, CP (SPLXM) - KLM kees.verno...@klm.com wrote: Hello group, We have some dataset problems with USS processes and are looking for the allocation messages. I mean the IGD101I SMS ALLOCATED TO DDNAME (DSNIWK02) DSN (SYS14131.T210019.RA000.XI1DMS1A.R0141149) STORCLAS (SCBATCH) MGMTCLAS () DATACLAS () VOL SER NOS= VIO and similar that you see in the message file of a job or STC or even in Syslog for an STC under MSTR. Where do these and other messages going for a USS process? A BPXAS STC is started for the process, but this only contains the messages for the BPXAS itself. Thanks, Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
On Tue, 13 May 2014 10:38:41 -0500, Kirk Wolf wrote: often the answer is nowhere. See this for a solution: http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.bpxb200%2Fjobpro.htm Hmmm: o NONE specifies that job log messages are not to be written. This is the default. Ugh! But: user@HOST: export -p | grep BPX export _BPXK_JOBLOG=STDERR user@HOST: user@HOST: cp //'sys1.maclib(splevel)' /dev/null user@HOST: I don't see no allocation messages. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
Perhaps because (at that link which Kirk posted) there is this note: Messages that would normally go to the JESYSMSG data set are captured, but messages that go to JESMSGLG are not captured. Allocation messages go to JESMSGLG, and so it would seem are not captured. One wonders which bit-bucket they disappear into. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, May 13, 2014 12:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where are the allocation messages of a USS process? On Tue, 13 May 2014 10:38:41 -0500, Kirk Wolf wrote: often the answer is nowhere. See this for a solution: http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.bpxb200%2Fjobpro.htm Hmmm: o NONE specifies that job log messages are not to be written. This is the default. Ugh! But: user@HOST: export -p | grep BPX export _BPXK_JOBLOG=STDERR user@HOST: user@HOST: cp //'sys1.maclib(splevel)' /dev/null user@HOST: I don't see no allocation messages. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
On 13 May 2014 12:08, Farley, Peter x23353 peter.far...@broadridge.com wrote: Perhaps because (at that link which Kirk posted) there is this note: Messages that would normally go to the JESYSMSG data set are captured, but messages that go to JESMSGLG are not captured. Allocation messages go to JESMSGLG, and so it would seem are not captured. One wonders which bit-bucket they disappear into. I think this is backwards, at least if using the SDSF terminology. What SDSF calls JESYSMSG contains allocation messages (IGD and IEF), while JESMSGLOG is the JESn-captured extract of WTOs written to the system SYSLOG. JESYSMSG also contains *some* application program WTOs, but I haven't put the effort into figuring out which ones. Maybe it's as simple as those with ROUTCDE 11. I've thought about a WTO exit of one sort or another that would capture WTOs from BPXAS processes, and write them to the JES log of their parent process. Of course the parent may have gone away, and there are various other problems, but it should be doable. At least they are already available in the system-wide SYSLOG, but things like allocation messages do indeed seem to go into a bit-bucket. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
Oops. You are absolutely correct, I got the names backwards. So what it putatively says is that allocation and initiation/termination messages are captured, but WTO's and other console messages are NOT captured? Weird. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Tuesday, May 13, 2014 1:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where are the allocation messages of a USS process? On 13 May 2014 12:08, Farley, Peter x23353 peter.far...@broadridge.com wrote: Perhaps because (at that link which Kirk posted) there is this note: Messages that would normally go to the JESYSMSG data set are captured, but messages that go to JESMSGLG are not captured. Allocation messages go to JESMSGLG, and so it would seem are not captured. One wonders which bit-bucket they disappear into. I think this is backwards, at least if using the SDSF terminology. What SDSF calls JESYSMSG contains allocation messages (IGD and IEF), while JESMSGLOG is the JESn-captured extract of WTOs written to the system SYSLOG. JESYSMSG also contains *some* application program WTOs, but I haven't put the effort into figuring out which ones. Maybe it's as simple as those with ROUTCDE 11. I've thought about a WTO exit of one sort or another that would capture WTOs from BPXAS processes, and write them to the JES log of their parent process. Of course the parent may have gone away, and there are various other problems, but it should be doable. At least they are already available in the system-wide SYSLOG, but things like allocation messages do indeed seem to go into a bit-bucket. Tony H. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
As Tony said, they are all WTO messages. JES decides where it wants to put the message (or not do anything with it). I suspect that some WTO messages are never written in USS as opposed to not being captured. I suspect that IBM disabled them for a reason.UNIX does so much allocation that it could easily flood the SSI (WTO's). I can image that issuing a make command would produce ton's of alloc / dealloc. As for capturing messages USS mesages placing them into the appropriate job, this may be more than you expect. Some of the problems would be: 1. Which parent/grandparent should receive the messages? 2. Will the messages truly be helpful since it will be more difficult to associate messages to issuing process. 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. Maybe a better alternative would be to use BPX_SHAREAS to share the address space with related processes 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. Jon Perryman On Tuesday, May 13, 2014 11:18 AM, Farley, Peter x23353 peter.far...@broadridge.com wrote: Oops. You are absolutely correct, I got the names backwards. So what it putatively says is that allocation and initiation/termination messages are captured, but WTO's and other console messages are NOT captured? Weird. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Tuesday, May 13, 2014 1:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where are the allocation messages of a USS process? On 13 May 2014 12:08, Farley, Peter x23353 peter.far...@broadridge.com wrote: Perhaps because (at that link which Kirk posted) there is this note: Messages that would normally go to the JESYSMSG data set are captured, but messages that go to JESMSGLG are not captured. Allocation messages go to JESMSGLG, and so it would seem are not captured. One wonders which bit-bucket they disappear into. I think this is backwards, at least if using the SDSF terminology. What SDSF calls JESYSMSG contains allocation messages (IGD and IEF), while JESMSGLOG is the JESn-captured extract of WTOs written to the system SYSLOG. JESYSMSG also contains *some* application program WTOs, but I haven't put the effort into figuring out which ones. Maybe it's as simple as those with ROUTCDE 11. I've thought about a WTO exit of one sort or another that would capture WTOs from BPXAS processes, and write them to the JES log of their parent process. Of course the parent may have gone away, and there are various other problems, but it should be doable. At least they are already available in the system-wide SYSLOG, but things like allocation messages do indeed seem to go into a bit-bucket. Tony H. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
On Tue, 13 May 2014 14:58:01 -0700, Jon Perryman wrote: As Tony said, they are all WTO messages. JES decides where it wants to put the message (or not do anything with it). I suspect that some WTO messages are never written in USS as opposed to not being captured. I suspect that IBM disabled them for a reason.UNIX does so much allocation that it could easily flood the SSI (WTO's). I can image that issuing a make command would produce ton's of alloc / dealloc. Indeed. Lately I did a cp of a couple hundred-member PDSE to a UNIX directory. Merely on elapsed time I can suspect that for each member it was doing ALLOCATE; OPEN; copy; CLOSE; FREE. (And catalog search?) As for capturing messages USS mesages placing them into the appropriate job, this may be more than you expect. Some of the problems would be: 1. Which parent/grandparent should receive the messages? 2. Will the messages truly be helpful since it will be more difficult to associate messages to issuing process. 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. This could be a problem with any child process that writes to a descriptor inherited from a parent process. AFAIK, it has been solved; perhaps as simply as by not reusing the address space until all such descriptors are closed. Maybe a better alternative would be to use BPX_SHAREAS to share the address space with related processes 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. Writing such messages to a suitably propagated descriptor might be an effective alternative to S/360-think which appears to be the current approach. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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
Re: Where are the allocation messages of a USS process?
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
