Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF... ( was: JVMDUMP032I message)
2,351 views
Skip to first unread message
Hunkeler Peter , KIUP 4
Dec 28, 2012, 2:30:58 AM12/28/12
to
>Now STC39500 looks like some sort of started task that began like this:
> BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB FTPD9 RUNNING IN ASID 01C1
Don't get fooled by that stupid message. It may have been introduced for some debugging purposes, I can't tell.
What is an address space called BPXAS? It is an idle initiator waiting for some UNIX work to arrive it can host.
New UNIX processes that result from (non-local) spawn() or fork() function calls need an address space to run in. Because creating as well as destroying an address space is somewhat costly in z/OS and because many UNIX processes are very short living (think of shell commands as an example), BPXAS initiator address spaces were invented back in OS/390 V1.3 (or around that time. Before that APPC initiators have been "missued" for this).
Step 1) When a new process needs an address space, the system looks if it can find an *idle* BPXAS initiator.
Step 1a) If so the process' environment will be built in that existing BPXAS address space and the process can run.
Step 1b) If no idle BPXAS is available (and WLM thinks the system can cope with one more address space), then a new BPXAS is started for this new process, the process' environment will be built in the newly started BPXAS address space and the process can run.
Step 2) When the process finally ends, the address space is no longer needed and could be destroyed. Again, since this is somewhat costly, the BPXAS initiator AS will not immediately end. It will stay around for 30 minutes (this 30 minute period was a hard coded; I believe it still is), and will be available for step 1/1a of another new process. Chances are, a new process will be born in due time (if there is some UNIX work going on on that system).
I don't know when the above message has been introduced (it wasn't always there), but the message is issued *once* when a new BPXAS is started (Step 1/1b above). It documents the jobname and ASID of the *parent* process, i.e. the process that initiated the new process about to be run in this BPXAS. Thereafter, no message is issued when an existing, idle BPXAS is selected to host just another process.
--
Peter Hunkeler
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
> BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB FTPD9 RUNNING IN ASID 01C1
Don't get fooled by that stupid message. It may have been introduced for some debugging purposes, I can't tell.
What is an address space called BPXAS? It is an idle initiator waiting for some UNIX work to arrive it can host.
New UNIX processes that result from (non-local) spawn() or fork() function calls need an address space to run in. Because creating as well as destroying an address space is somewhat costly in z/OS and because many UNIX processes are very short living (think of shell commands as an example), BPXAS initiator address spaces were invented back in OS/390 V1.3 (or around that time. Before that APPC initiators have been "missued" for this).
Step 1) When a new process needs an address space, the system looks if it can find an *idle* BPXAS initiator.
Step 1a) If so the process' environment will be built in that existing BPXAS address space and the process can run.
Step 1b) If no idle BPXAS is available (and WLM thinks the system can cope with one more address space), then a new BPXAS is started for this new process, the process' environment will be built in the newly started BPXAS address space and the process can run.
Step 2) When the process finally ends, the address space is no longer needed and could be destroyed. Again, since this is somewhat costly, the BPXAS initiator AS will not immediately end. It will stay around for 30 minutes (this 30 minute period was a hard coded; I believe it still is), and will be available for step 1/1a of another new process. Chances are, a new process will be born in due time (if there is some UNIX work going on on that system).
I don't know when the above message has been introduced (it wasn't always there), but the message is issued *once* when a new BPXAS is started (Step 1/1b above). It documents the jobname and ASID of the *parent* process, i.e. the process that initiated the new process about to be run in this BPXAS. Thereafter, no message is issued when an existing, idle BPXAS is selected to host just another process.
--
Peter Hunkeler
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
McKown, John
Dec 28, 2012, 8:26:38 AM12/28/12
to
Gee, along with a recent message over on the RACF forum, this is making the BPXAS initiator address space seem like a z/OS UNIX version of a JES XBM (eXecution Batch Monitor) initiator. This had never occurred to me before. And is likely not really of much use or interest to others.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets®
9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john....@healthmarkets.com • www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets®
9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john....@healthmarkets.com • www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
ibmmain
Dec 29, 2012, 1:41:51 AM12/29/12
to
Peter,
> > BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB FTPD9 RUNNING IN ASID 01C1
Barbara
> > BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB FTPD9 RUNNING IN ASID 01C1
> I don't know when the above message has been introduced (it wasn't always there), but the message is issued *once* when a new BPXAS is started (Step 1/1b above). It documents the jobname and ASID of the *parent* process, i.e. the process that initiated the new process about to be run in this BPXAS. Thereafter, no message is issued when an existing, idle BPXAS is selected to host just another process.
I have seen that message citing my own (TSO) userid as jobname. And I had certainly NOT done anything at that time. I had done something in OMVS before, though (like 5 minutes earlier). Is it possible that the jobname/userid somehow somewhere gets stored and reused despite *this* parent process being someone else? I have also seen this happen with IBMUSER, and the colleague doing the ftp swears that he didn't use IBMUSER for his ftp.
Barbara
Walt Farrell
Dec 29, 2012, 8:04:59 AM12/29/12
to
On Sat, 29 Dec 2012 07:42:34 +0100, ibmmain <nitz...@GMX.NET> wrote:
> I have also seen this happen with IBMUSER, and the colleague doing the ftp swears that he didn't use IBMUSER for his ftp.
>
If this was for an inbound FTP session, do you have the FTP server configured to run as IBMUSER?
> I have also seen this happen with IBMUSER, and the colleague doing the ftp swears that he didn't use IBMUSER for his ftp.
>
--
Walt
Peter Hunkeler
Dec 29, 2012, 11:57:03 AM12/29/12
to
It seems I have not been clear enough.
Like a JESx initiator, which, in its lifetime, may serve as a container (address space) for many batch jobs, BPXAS initiators may, in their lifetime, serve as a container (i.e.address space) for many, many processes one after the other.
The message BPXP042I documents only which (parent) process initiated *the creation of this very instance of a BPXAS address space* because it (the parent process) started a new (child) process (via spawn() of fork()). Thereafter, the very same instance of the BPXAS address space may be used again and again and again. Each time a process does a (non-local) spawn() of a fork(), one such BPXAS is needed.
If a BPXAS is sitting around doing nothing, i.e. it is idle, this means it has been hosting one or more processes before. But currently, it is waiting for another process it can host, or, for the 30 minute idle period to expire. You will see message BPXP024I only for the *very first* process is was hosting in its lifetime.
In SDSF, when you see a line saying BPXAS, this is a line showing an *idle* "UNIX process initiator". This is equivalent to JESx initiators. When you see a line saying INIT, this is an idle batch job initiator.
The JESx initiator changes its displayed jobname when it is serving a batch job. Equally, a BPXAS changes its displayed jobname when it is serving a UNIX process.
>I have seen that message citing my own (TSO) userid as jobname. And I had certainly NOT done anything at that time. I had done something in OMVS before, though (like 5 minutes earlier). Is it possible that the jobname/userid somehow somewhere gets stored and reused despite *this* parent process being someone else? I have also seen this happen with IBMUSER, and the colleague doing the ftp swears that he didn't use IBMUSER for his ftp.
Let's assume you start your TSO session (your ID is BARBARA), then do something with Z/OS UNIX that starts a new UNIX *non-local* process. (There are processes that may run in the current address space, called local processes. There are processes that may *not* run in the current address space, called non-local processes.) Since this new non-local process needs an address space to run in, the system looks if it can find an *idle* BPXAS. We assume now, there was none, so a new one was started especially for you, well for your process. The system then writes message BPXP024I to document that your TSO session was the reason this BPXAS was started. (To be exact: The message documents that there is a process running in address space BARBARA that initiated this BPXAS creation. It does not say this is a TSO session.)
At this time (and before the process ends), you can see 2 lines in SDSF: One called BARBARA, a TSU line, representing your TSO session, and a second one called BARBARA1, an STC line, representing your UNIX process. You won't see a line called BPXAS.
Sometime later, your non-local process ends; the BPXAS becomes idle. You can again see it as BPXAS in SDSF and you can read message BPXP024I saying it was started for parent BARBARA.
Let's now assume nothing else happened on the system until 5 minutes later, when your colleage FOO performs the very same steps described above. The BPXAS is still idle and the system will select it to host Foo's UNIX process. Since the BPXAS was already running, *no* BPXP024I message is written.
At this time (before the process ends), you can see 2 lines in SDSF: One called FOO, a TSU line, representing Foo's TSO session, and a second one called FOO1, an STC line, representing Foo's UNIX process. You won't see a line called BPXAS.
Sometime later, Foo's non-local process ends; the BPXAS becomes idle again. You can again see it as BPXAS in SDSF and you can still read message BPXP024I saying it was started for parent BARBARA.
You won't see Foo's process mentioned. Why? Imagine, say, ten UNIX guys are logged into Z/OS UNIX working hardly in their shell environments for 8 hours. You can imagine that thousands and thousands of processes have been started and ended during that working day. Say, a couple of BPXAS address spaces could cope with the work but never got idle long enough (the 30 minutes period) to end. If BPXP024I was written for each and every process, there were thousands and thousands of BPCXP024I messages in those BPXASs filling your spool.
--
Peter Hunkeler
Like a JESx initiator, which, in its lifetime, may serve as a container (address space) for many batch jobs, BPXAS initiators may, in their lifetime, serve as a container (i.e.address space) for many, many processes one after the other.
The message BPXP042I documents only which (parent) process initiated *the creation of this very instance of a BPXAS address space* because it (the parent process) started a new (child) process (via spawn() of fork()). Thereafter, the very same instance of the BPXAS address space may be used again and again and again. Each time a process does a (non-local) spawn() of a fork(), one such BPXAS is needed.
If a BPXAS is sitting around doing nothing, i.e. it is idle, this means it has been hosting one or more processes before. But currently, it is waiting for another process it can host, or, for the 30 minute idle period to expire. You will see message BPXP024I only for the *very first* process is was hosting in its lifetime.
In SDSF, when you see a line saying BPXAS, this is a line showing an *idle* "UNIX process initiator". This is equivalent to JESx initiators. When you see a line saying INIT, this is an idle batch job initiator.
The JESx initiator changes its displayed jobname when it is serving a batch job. Equally, a BPXAS changes its displayed jobname when it is serving a UNIX process.
>I have seen that message citing my own (TSO) userid as jobname. And I had certainly NOT done anything at that time. I had done something in OMVS before, though (like 5 minutes earlier). Is it possible that the jobname/userid somehow somewhere gets stored and reused despite *this* parent process being someone else? I have also seen this happen with IBMUSER, and the colleague doing the ftp swears that he didn't use IBMUSER for his ftp.
Let's assume you start your TSO session (your ID is BARBARA), then do something with Z/OS UNIX that starts a new UNIX *non-local* process. (There are processes that may run in the current address space, called local processes. There are processes that may *not* run in the current address space, called non-local processes.) Since this new non-local process needs an address space to run in, the system looks if it can find an *idle* BPXAS. We assume now, there was none, so a new one was started especially for you, well for your process. The system then writes message BPXP024I to document that your TSO session was the reason this BPXAS was started. (To be exact: The message documents that there is a process running in address space BARBARA that initiated this BPXAS creation. It does not say this is a TSO session.)
At this time (and before the process ends), you can see 2 lines in SDSF: One called BARBARA, a TSU line, representing your TSO session, and a second one called BARBARA1, an STC line, representing your UNIX process. You won't see a line called BPXAS.
Sometime later, your non-local process ends; the BPXAS becomes idle. You can again see it as BPXAS in SDSF and you can read message BPXP024I saying it was started for parent BARBARA.
Let's now assume nothing else happened on the system until 5 minutes later, when your colleage FOO performs the very same steps described above. The BPXAS is still idle and the system will select it to host Foo's UNIX process. Since the BPXAS was already running, *no* BPXP024I message is written.
At this time (before the process ends), you can see 2 lines in SDSF: One called FOO, a TSU line, representing Foo's TSO session, and a second one called FOO1, an STC line, representing Foo's UNIX process. You won't see a line called BPXAS.
Sometime later, Foo's non-local process ends; the BPXAS becomes idle again. You can again see it as BPXAS in SDSF and you can still read message BPXP024I saying it was started for parent BARBARA.
You won't see Foo's process mentioned. Why? Imagine, say, ten UNIX guys are logged into Z/OS UNIX working hardly in their shell environments for 8 hours. You can imagine that thousands and thousands of processes have been started and ended during that working day. Say, a couple of BPXAS address spaces could cope with the work but never got idle long enough (the 30 minutes period) to end. If BPXP024I was written for each and every process, there were thousands and thousands of BPCXP024I messages in those BPXASs filling your spool.
--
Peter Hunkeler
Peter Hunkeler
Dec 29, 2012, 12:19:59 PM12/29/12
to
>> I have also seen this happen with IBMUSER, and the colleague doing the ftp swears that he didn't use IBMUSER for his ftp.
>>
>
>>
>
>If this was for an inbound FTP session, do you have the FTP server configured to run as IBMUSER?
The message documents the *jobname*, not the uid/userid of the parent process. If the message says IBMUSER, then there must have been some address space named IBMUSER initiating the creation of this BPXAS.
Isn't IBMUSER a userid defined on precustomized z/OS systems like the ADCD systems? I bet someone was logged into TSO as IBMUSER, then did some UNIX work. Later that other colleague did an ftp and his process was hosted by the BPXAS that previously has been started on bevalf of IBMUSER.
ibmmain
Dec 31, 2012, 3:13:30 AM12/31/12
to
>If this was for an inbound FTP session, do you have the FTP server configured to run as IBMUSER?
Not that I can see. None of the parms that ftpd is configured with (that I can find) mentions the word IBMUSER. It is possible that something is configured somewhere in an HFS/zFS that I wouldn't have a clue how to find. But on the other hand - chances are that nobody else would have configured that, either. I also hope that IBM does not deliver an ADCD system with IBMUSER configures as default user.
> Let's assume you start your TSO session (your ID is BARBARA), then do something with Z/OS UNIX that starts a new UNIX *non-local* process.
BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB BARBARA RUNNING IN ASID 0030
BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB BARBARA1 RUNNING IN ASID 001E
x'30' is my TSO userid, and asid x'1E' is so short-lived that it is gone (without a trace, no BPXAS, no nothing) at the time I look at the log.
According to what you wrote, I *should* see at least one BPXAS being idle (in asid x'1E'). There is no asid x'1E'. The SDSF ps display shows two processes in asid x'30' - in my TSO asid, one for EXEC and the other for /bin/fomfuish.
> Sometime later, your non-local process ends; the BPXAS becomes idle. You can again see it as BPXAS in SDSF and you can read message BPXP024I saying it was started for parent BARBARA.
Just for fun, I also ftp'd into the system up to providing the password. No message at all, no BPXAS. All I have is now another address space with my TSO userid/jobname (but as an STC) showing up as waiting in /usr/sbin/ftpdns.
Is there a magic command that I am unaware of that would show me idle BPXASs, provided they exist?!?
> Sometime later, Foo's non-local process ends; the BPXAS becomes idle again. You can again see it as BPXAS in SDSF and you can still read message BPXP024I saying it was started for parent BARBARA.
> You can imagine that thousands and thousands of processes have been started and ended during that working day.
I am inclined to write a similar exit just to see when soemthing starts and ends and in which address space. I hate flying blind.
>Isn't IBMUSER a userid defined on precustomized z/OS systems like the ADCD systems? I bet someone was logged into TSO as IBMUSER, then did some UNIX work. Later that other colleague did an ftp and his process was hosted by the BPXAS that previously has been started on behalf of IBMUSER.
Yes, IBMUSER is unfortunately widely used on ADCD systems. According to what you described in your other post, we should *not* see someone else under a BPXP024 message if the BPXAS was idle. So it still doesn't make sense to me. But then, OMVS/Unix never really made sense to me.
Barbara
Tony Harminc
Dec 31, 2012, 2:44:31 PM12/31/12
to
On 31 December 2012 03:14, ibmmain <nitz...@gmx.net> wrote:
>> You can imagine that thousands and thousands of processes have been started and ended during that working day.
> In my old job, we used to have SMF exits (IEFACTRT and IEFUJI) that produced a message when an asid was started and when a jobstep was terminating. On the systems where OMVS work was running we suppressed those messages from hardcopy log for the known 'offenders' - pages and pages of these messages, but no meaningful content in hardcopy log anymore.
>
> I am inclined to write a similar exit just to see when soemthing starts and ends and in which address space. I hate flying blind.
You might also look at the UNIX process start/end exits, documented in
>> You can imagine that thousands and thousands of processes have been started and ended during that working day.
> In my old job, we used to have SMF exits (IEFACTRT and IEFUJI) that produced a message when an asid was started and when a jobstep was terminating. On the systems where OMVS work was running we suppressed those messages from hardcopy log for the known 'offenders' - pages and pages of these messages, but no meaningful content in hardcopy log anymore.
>
> I am inclined to write a similar exit just to see when soemthing starts and ends and in which address space. I hate flying blind.
the UNIX Assembler Callable Services Reference book. You would see the
start and end of all UNIX processes, regardless of whether they run in
a new address space, and could keep stats and issue messages as you
like. And if you don't like UNIX, take heart - you cannot use any UNIX
services in these exits...
Tony H.
ibmmain
Jan 2, 2013, 6:44:51 AM1/2/13
to
Tony,
> You might also look at the UNIX process start/end exits, documented in
> the UNIX Assembler Callable Services Reference book. You would see the
> start and end of all UNIX processes, regardless of whether they run in
> a new address space, and could keep stats and issue messages as you
> like. And if you don't like UNIX, take heart - you cannot use any UNIX
> services in these exits...
:-)
thanks, I'll look into that, too!
Barbara
> You might also look at the UNIX process start/end exits, documented in
> the UNIX Assembler Callable Services Reference book. You would see the
> start and end of all UNIX processes, regardless of whether they run in
> a new address space, and could keep stats and issue messages as you
> like. And if you don't like UNIX, take heart - you cannot use any UNIX
> services in these exits...
thanks, I'll look into that, too!
Barbara
Peter Hunkeler
Jan 2, 2013, 2:20:19 PM1/2/13
to
Happy New Year to everybody.
Barbara, I'm sorry for the delayed response. I've been too busy with the
year end porocessing.
>>Let's assume you start your TSO session (your ID is BARBARA), then do
<>something with Z/OS UNIX that starts a new UNIX *non-local* process.
>A simple 'tso ishell' will start two BPXASs:
>BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB BARBARA RUNNING IN
>ASID 0030
>BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB BARBARA1 RUNNING IN
>ASID 001E
>x'30' is my TSO userid, and asid x'1E' is so short-lived that it is gone
>(without a trace, no BPXAS, no nothing) at the time I look at the log.
>According to what you wrote, I *should* see at least one BPXAS being
>idle (in asid x'1E'). There is no asid x'1E'.
No, the BPXP024I message documents the ASID that caused this BPXAS to be
startet. That ASID may or may not be another BPXAS. Since you mention X'1E'
I'd say this is a system address space started during IPL. One of these that are
starting UNIX work, and thus are initiating BPXAS starts, is BPXOINIT.
>The SDSF ps display shows
>two processes in asid x'30' - in my TSO asid, one for EXEC and the other
>for /bin/fomfuish.
Yes, the first process is the ISHELL REXX and the second one is started
to be able to display time/date values in your timezone, provided there
is one configured in your UNIX shell environment. (The BPXAS that has
been used for a short time is part of this processing.)
>Once I leave ishell, the two processes are gone. No message in syslog.
>No idle BPXAS anywhere. I must be missing something.
No, you're not missing anything. The two processes are *local* processes,
i.e. they run in your TSO address space. You confimed this when you saw
two processes in your ASID X'30' in SDSF's PS display.
No address space terminated just because you quit ishell. Therefore
no end of AS messages are logged.
>Is there a magic command that I am unaware of that would show me idle
>BPXASs, provided they exist?!?
Have you tried "DA ALL" in SDSF or "D A,BPXAS" on the console. SDSF
does not show idle initiators in the DA unless you proivde the "ALL"
parm.
>But then, OMVS/Unix never really made sense to me.
It's not a question of whether it makes sense or not. It is an integral
part of z/OS and even system tasks (TCP/IP, DB2, IMS, etc., etc.)
make use of it. There is no way around it anymore.
--
Peter Hunkeler
Barbara, I'm sorry for the delayed response. I've been too busy with the
year end porocessing.
>>Let's assume you start your TSO session (your ID is BARBARA), then do
<>something with Z/OS UNIX that starts a new UNIX *non-local* process.
>A simple 'tso ishell' will start two BPXASs:
>BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB BARBARA RUNNING IN
>ASID 0030
>BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB BARBARA1 RUNNING IN
>ASID 001E
>x'30' is my TSO userid, and asid x'1E' is so short-lived that it is gone
>(without a trace, no BPXAS, no nothing) at the time I look at the log.
>According to what you wrote, I *should* see at least one BPXAS being
>idle (in asid x'1E'). There is no asid x'1E'.
startet. That ASID may or may not be another BPXAS. Since you mention X'1E'
I'd say this is a system address space started during IPL. One of these that are
starting UNIX work, and thus are initiating BPXAS starts, is BPXOINIT.
>The SDSF ps display shows
>two processes in asid x'30' - in my TSO asid, one for EXEC and the other
>for /bin/fomfuish.
to be able to display time/date values in your timezone, provided there
is one configured in your UNIX shell environment. (The BPXAS that has
been used for a short time is part of this processing.)
>Once I leave ishell, the two processes are gone. No message in syslog.
>No idle BPXAS anywhere. I must be missing something.
i.e. they run in your TSO address space. You confimed this when you saw
two processes in your ASID X'30' in SDSF's PS display.
No address space terminated just because you quit ishell. Therefore
no end of AS messages are logged.
>Is there a magic command that I am unaware of that would show me idle
>BPXASs, provided they exist?!?
does not show idle initiators in the DA unless you proivde the "ALL"
parm.
>But then, OMVS/Unix never really made sense to me.
part of z/OS and even system tasks (TCP/IP, DB2, IMS, etc., etc.)
make use of it. There is no way around it anymore.
--
Peter Hunkeler
ibmmain
Jan 3, 2013, 1:02:09 AM1/3/13
to
Peter,
> Barbara, I'm sorry for the delayed response. I've been too busy with the
> year end porocessing.
well, this is a voluntary list, after all! :-)
> Have you tried "DA ALL" in SDSF or "D A,BPXAS" on the console. SDSF
> does not show idle initiators in the DA unless you proivde the "ALL"
> parm.
DA ALL is the magic command. Now I see them all in all their glory. I didn't know one had to tell SDSF specifically 'ALL', I thought prefix **/owner ** was enough.
> It's not a question of whether it makes sense or not. It is an integral
> part of z/OS and even system tasks (TCP/IP, DB2, IMS, etc., etc.)
> make use of it. There is no way around it anymore.
Don't I know it!
Thanks for your patience with me!
Barbara
> Barbara, I'm sorry for the delayed response. I've been too busy with the
> year end porocessing.
> Have you tried "DA ALL" in SDSF or "D A,BPXAS" on the console. SDSF
> does not show idle initiators in the DA unless you proivde the "ALL"
> parm.
> It's not a question of whether it makes sense or not. It is an integral
> part of z/OS and even system tasks (TCP/IP, DB2, IMS, etc., etc.)
> make use of it. There is no way around it anymore.
Thanks for your patience with me!
Barbara
Elardus Engelbrecht
Jan 3, 2013, 5:53:19 AM1/3/13
to
Barbara Nitz wrote:
>> Barbara, I'm sorry for the delayed response. I've been too busy with the year end porocessing.
>well, this is a voluntary list, after all! :-)
Wow! I'm volunteering to say this is news to me :-D :-D :-D
>> Barbara, I'm sorry for the delayed response. I've been too busy with the year end porocessing.
>well, this is a voluntary list, after all! :-)
>DA ALL is the magic command. Now I see them all in all their glory. I didn't know one had to tell SDSF specifically 'ALL', I thought prefix **/owner ** was enough.
Groete / Greetings
Elardus Engelbrecht
[1] - I don't know if SDSF command SYSNAME is useful in ADCD.
retired mainframer
Jan 3, 2013, 1:46:40 PM1/3/13
to
:>: -----Original Message-----
:>: Sent: Wednesday, January 02, 2013 10:03 PM
:>: To: IBM-...@LISTSERV.UA.EDU
:>: Subject: Re: BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF... ( was:
:>: JVMDUMP032I message)
:>:
:>: Peter,
parms. Most of the sites I have seen (not that many really) have it set to
jobs only.
:>: From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
:>: Behalf Of ibmmain
:>: Sent: Wednesday, January 02, 2013 10:03 PM
:>: To: IBM-...@LISTSERV.UA.EDU
:>: Subject: Re: BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF... ( was:
:>: JVMDUMP032I message)
:>:
:>: Peter,
:>:
:>: > Barbara, I'm sorry for the delayed response. I've been too busy with
:>: the
:>: > year end porocessing.
:>: well, this is a voluntary list, after all! :-)
:>:
:>: > Have you tried "DA ALL" in SDSF or "D A,BPXAS" on the console. SDSF
:>: > does not show idle initiators in the DA unless you proivde the "ALL"
:>: > parm.
:>:
:>: DA ALL is the magic command. Now I see them all in all their glory. I
:>: didn't know one had to tell SDSF specifically 'ALL', I thought prefix
:>: **/owner ** was enough.
The data displayed by an unqualified DA command is controlled by the ISPF
:>: > Barbara, I'm sorry for the delayed response. I've been too busy with
:>: the
:>: > year end porocessing.
:>: well, this is a voluntary list, after all! :-)
:>:
:>: > Have you tried "DA ALL" in SDSF or "D A,BPXAS" on the console. SDSF
:>: > does not show idle initiators in the DA unless you proivde the "ALL"
:>: > parm.
:>:
:>: DA ALL is the magic command. Now I see them all in all their glory. I
:>: didn't know one had to tell SDSF specifically 'ALL', I thought prefix
:>: **/owner ** was enough.
parms. Most of the sites I have seen (not that many really) have it set to
jobs only.
ibmmain
Jan 3, 2013, 2:02:55 PM1/3/13
to
> The data displayed by an unqualified DA command is controlled by the ISPF
> parms. Most of the sites I have seen (not that many really) have it set to
> jobs only.
I am using the default that IBM delivers. I copied that over from one of the ISF libraries.
> parms. Most of the sites I have seen (not that many really) have it set to
> jobs only.
In an ADCD system (which is typically a monoplex) sysname ** doesn't mean much, there weren't any filters, and I don't think DEST has an influence.
Barbara
0 new messages