Can forked/spawned address spaces be identified as such?

[Support, DUNNIT SYSTEMS LTD.]

Are there any control block fields or flags within these address spaces that 
indentify them as being started by a fork or spawn action? Are there different 
indicators for forked versus spawned address spaces?

TIA,
Jerry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Support, DUNNIT SYSTEMS LTD.]

Anyone?

In the meantime, I've found these in the ASSB:

ASSBWMF1 DSXL1 WLM flags
*  SERIALIZATION: none  
ASSBWINI EQU   X'80'   WLM Managed Batch initiator  
ASSBFSAS EQU   X'40'   WLM Managed OE Forked/Spawned

Now, are all forked/spawned address spaces managed by WLM? If not, what 
else would indicate a forked/spawned address space?

What precisely is the difference between the 2 equates above? Are they 
mutually exclusive? Can there be forked/spawned address spaces with both 
indicators off?

Jerry

On Wed, 19 Mar 2008 04:11:10 -0500, Support, DUNNIT SYSTEMS LTD. 
<[EMAIL PROTECTED]> wrote:

>Are there any control block fields or flags within these address spaces that
>indentify them as being started by a fork or spawn action? Are there different
>indicators for forked versus spawned address spaces?
>
>TIA,
>Jerry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Wayne Driscoll]

Jerry,
In the distant past, forked address spaces where managed via APPC address
spaces (when OE was first introduced).  So that is probably the reason for
the WLM managed indicator.  As for Batch Inits, that is probably to indicate
a JES class that is defined with WLM inits rather than JES inits, so my
guess is that yes, they are mutually exclusive.

Wayne Driscoll
Product Developer
NOTE:  All opinions are strictly my own.




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Support, DUNNIT SYSTEMS LTD.
Sent: Wednesday, March 19, 2008 3:28 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Can forked/spawned address spaces be identified as such?

Anyone?

In the meantime, I've found these in the ASSB:

ASSBWMF1 DSXL1 WLM flags
*  SERIALIZATION: none  
ASSBWINI EQU   X'80'   WLM Managed Batch initiator  
ASSBFSAS EQU   X'40'   WLM Managed OE Forked/Spawned

Now, are all forked/spawned address spaces managed by WLM? If not, what 
else would indicate a forked/spawned address space?

What precisely is the difference between the 2 equates above? Are they 
mutually exclusive? Can there be forked/spawned address spaces with both 
indicators off?

Jerry

On Wed, 19 Mar 2008 04:11:10 -0500, Support, DUNNIT SYSTEMS LTD. 
<[EMAIL PROTECTED]> wrote:

>Are there any control block fields or flags within these address spaces
that
>indentify them as being started by a fork or spawn action? Are there
different
>indicators for forked versus spawned address spaces?
>
>TIA,
>Jerry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Tony Harminc]

On 19/03/2008, Support, DUNNIT SYSTEMS LTD. <[EMAIL PROTECTED]> wrote:
> Are there any control block fields or flags within these address spaces that
>  indentify them as being started by a fork or spawn action? Are there 
> different
>  indicators for forked versus spawned address spaces?

There are various flags with names that include "fork" and "spawn" in
the OAPB, OTCB, and THLI blocks, but they are certainly not
Programming Interfaces. You could poke around at these to see if there
is any reliable correlation.

There are UNIX exits, including a post-process initiation exit, that
you can install with CSVDYNEX et al, and that are passed a PEDB, which
seems to contain the information you want at the time of process
creation. If you are in a position to install such an exit (requires
suitable authorization, of course) then you could capture what you
need, and stash it away somewhere. This is described in the UNIX
System Services Planning book. The PEDB is, of course, in Assembler
Callable Services, and macro BPXYPEDB.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Paul Schuster]

On Wed, 19 Mar 2008 04:11:10 -0500, Support, DUNNIT SYSTEMS LTD.
<[EMAIL PROTECTED]> wrote:

TMASSBWMF1,ASSBFSAS

has worked for me for several years.

HTH.

>Are there any control block fields or flags within these address spaces that
>indentify them as being started by a fork or spawn action? Are there different
>indicators for forked versus spawned address spaces?
>
>TIA,
>Jerry
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Peter Relson]

As the ASSB fields mentioned are not programming interfaces, no additional
information will be provided as to their meaning and use.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Support, DUNNIT 
> SYSTEMS LTD.
> Sent: Wednesday, March 19, 2008 4:11 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Can forked/spawned address spaces be identified as such?
> 
> 
> Are there any control block fields or flags within these 
> address spaces that 
> indentify them as being started by a fork or spawn action? 
> Are there different 
> indicators for forked versus spawned address spaces?
> 
> TIA,
> Jerry

Nobody else has asked, so I will. Why do you want to do this? I'm just
curious.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Support, DUNNIT SYSTEMS LTD.]

It's the Blue Meanies!!!

:-)

On Thu, 20 Mar 2008 07:39:05 -0400, Peter Relson <[EMAIL PROTECTED]> 
wrote:

>As the ASSB fields mentioned are not programming interfaces, no additional
>information will be provided as to their meaning and use.
>
>Peter Relson
>z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Support, DUNNIT SYSTEMS LTD.]

John,

<[EMAIL PROTECTED]> wrote:
>Nobody else has asked, so I will. Why do you want to do this? I'm just
>curious.

I could tell you but I would have to kill you.

;)

Actually, I need to be able to determine what the original job name is.

Is the rule correct that every case - with no exceptions - of a 
forked/spawned address space has a single digit from 1 to 9 appended to the 
job name? If so, what happens after 9 such spawns?

In addition, in my case, I have a spawned Java job. I'm finding that the JBNI 
and JBNS fields of both the ASCB and the ASSB point to the following names:

JBNI. TESTJOB1 JBNS. BPXAS

Now my question is can I rely and JBNS=BPXAS to determine the parent 
address space's name is equal to the child address space's name minus the 
child's last job name character?

For those not familiar with BPXAS, here's a little copy and past from what I 
found:

Beginning with OS/390 Version 2 Release 4, OS/390 UNIX System Services 
changed from usingAPPC initiators to Workload Manager (WLM) controlled 
initiators. The initiator address space name isBPXAS instead of ASCHINT. 
BPXAS is a special initiator with special interfaces to WLM and UNIXSystem 
Services.Fork and spawn use a WLM service to get an address space to 
process a request. The WLM servicechecks its queue to see if there is an idle 
address space from a free pool of BPXAS address spacesthat are waiting for 
work. If there are no idle BPXAS address spaces, WLM determines whether a 
newone can be created based on system load. If the free pool is empty, an 
ASCRE is done using thename BPXAS as the procedure to start a new one. 
When a BPXAS address space is finished, theaddress space goes back into the 
free pool. After 30 minutes of being idle, the address space isterminated.The 
spawn service is another way to create a new process. It looks like fork(), 
except that the newprocess is not a copy of the parent process. The child 
process inherits file and socket descriptors, aswith the fork(). With a spawn, 
the child process can be created in the parent address space.


TIA,
Jerry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Ted MacNEIL]

>Is the rule correct that every case - with no exceptions - of a forked/spawned 
>address space has a single digit from 1 to 9 appended to the 
job name?

No. Eight character jobnames are truncated to 7, and then the digit is added.

>If so, what happens after 9 such spawns?

We go alphabetic - A, B, C, ...

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Shane]

I wouldn't have included the smiley.
Why aren't things like this exposed ???. And if they are, why aren't
they (publicly/freely) documented.

Shane ...

On Thu, 2008-03-20 at 15:25 -0500, Support, DUNNIT SYSTEMS LTD. wrote:
> It's the Blue Meanies!!!
> 
> :-)
> 
> On Thu, 20 Mar 2008 07:39:05 -0400, Peter Relson <[EMAIL PROTECTED]> 
> wrote:
> 
> >As the ASSB fields mentioned are not programming interfaces, no additional
> >information will be provided as to their meaning and use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[David Day]

Take a look at the SMF exits.  The description that follows is a cut and 
paste for the parameter descriptins for IEFUJI.  Word 5.


Hope this helps

   -Dave Day




.21.7.2 Parameter Descriptions

Register 1 points to the following list of addresses:


 Word 1
 Address of the common exit parameter area. For details on the parameter 
area, see Table 3 in topic 2.16.7.3.


 Word 2
 Address of a 20-byte area containing the programmer's name (in EBCDIC) 
from the JOB statement. This area is aligned left and padded with blanks if 
necessary.


 Word 3
 Address of a one-byte area indicating (in binary) the requested job 
selection priority. The value of this field equals the user-assigned 
priority of 0 to 14 (taken from the PRTY parameter on the JOB statement).


 Word 4
 Address of an area containing the accounting information from the JOB 
statement. (See "Accounting Information" in topic 2.16.7.4.)


 Word 5
 Address of a 4-character area that contains the name of the subsystem for 
the job being processed. Examples:


   a.. ASCH, JES2, or JES3 -- indicates the name of the subsystem that 
selected the job


   b.. OMVS -- indicates a forked or spawned address space

   c.. STC -- indicates a started task

   d.. TSO -- indicates a time sharing option task

   e.. The jobname -- used if it is four or fewer characters and none of 
the above apply




Note: The high-order bit is set in the address of the last parameter to 
indicate the end of the parameter list.
- Original Message - 
From: "Support, DUNNIT SYSTEMS LTD." <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Thursday, March 20, 2008 3:49 PM
Subject: Re: Can forked/spawned address spaces be identified as such?



John,

<[EMAIL PROTECTED]> wrote:

Nobody else has asked, so I will. Why do you want to do this? I'm just
curious.


I could tell you but I would have to kill you.

;)

Actually, I need to be able to determine what the original job name is.

Is the rule correct that every case - with no exceptions - of a
forked/spawned address space has a single digit from 1 to 9 appended to 
the

job name? If so, what happens after 9 such spawns?

In addition, in my case, I have a spawned Java job. I'm finding that the 
JBNI
and JBNS fields of both the ASCB and the ASSB point to the following 
names:


JBNI. TESTJOB1 JBNS. BPXAS

Now my question is can I rely and JBNS=BPXAS to determine the parent
address space's name is equal to the child address space's name minus the
child's last job name character?

For those not familiar with BPXAS, here's a little copy and past from what 
I

found:

Beginning with OS/390 Version 2 Release 4, OS/390 UNIX System Services
changed from usingAPPC initiators to Workload Manager (WLM) controlled
initiators. The initiator address space name isBPXAS instead of ASCHINT.
BPXAS is a special initiator with special interfaces to WLM and UNIXSystem
Services.Fork and spawn use a WLM service to get an address space to
process a request. The WLM servicechecks its queue to see if there is an 
idle

address space from a free pool of BPXAS address spacesthat are waiting for
work. If there are no idle BPXAS address spaces, WLM determines whether a
newone can be created based on system load. If the free pool is empty, an
ASCRE is done using thename BPXAS as the procedure to start a new one.
When a BPXAS address space is finished, theaddress space goes back into 
the
free pool. After 30 minutes of being idle, the address space 
isterminated.The
spawn service is another way to create a new process. It looks like 
fork(),

except that the newprocess is not a copy of the parent process. The child
process inherits file and socket descriptors, aswith the fork(). With a 
spawn,

the child process can be created in the parent address space.


TIA,
Jerry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Support, DUNNIT SYSTEMS LTD.]

All you need is love.

On Fri, 21 Mar 2008 07:08:28 +1000, Shane <[EMAIL PROTECTED]> wrote:
>I wouldn't have included the smiley.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Support, DUNNIT SYSTEMS LTD.]

So is there any way to determine the original parent address space's name 
from within the child's address space?

TIA,
Jerry

On Thu, 20 Mar 2008 22:04:44 +, Ted MacNEIL <[EMAIL PROTECTED]> 
wrote:

>>Is the rule correct that every case - with no exceptions - of a 
forked/spawned address space has a single digit from 1 to 9 appended to the
>job name?
>
>No. Eight character jobnames are truncated to 7, and then the digit is added.
>
>>If so, what happens after 9 such spawns?
>
>We go alphabetic - A, B, C, ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Ted MacNEIL]

>So is there any way to determine the original parent address space's name from 
>within the child's address space?

I have not been able to do it.
I have asked in the past and gotten no reliable answer.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Edward Jaffe]

Support, DUNNIT SYSTEMS LTD. wrote:
So is there any way to determine the original parent address space's name 
from within the child's address space?
  


BPXEKDA returns the structure mapped by BPXZODMV. OdmvPPID is the 
parent's Process ID.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Support, DUNNIT SYSTEMS LTD.]

Edward,

Thanks. Will have to look into that method.

Jerry

On Thu, 20 Mar 2008 15:04:41 -0700, Edward Jaffe 
<[EMAIL PROTECTED]> wrote:

>Support, DUNNIT SYSTEMS LTD. wrote:
>> So is there any way to determine the original parent address space's name
>> from within the child's address space?
>>
>
>BPXEKDA returns the structure mapped by BPXZODMV. OdmvPPID is the
>parent's Process ID.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Tony Harminc]

On 20/03/2008, Support, DUNNIT SYSTEMS LTD. <[EMAIL PROTECTED]> wrote:

>  Actually, I need to be able to determine what the original job name is.

Keep in mind that UNIX allows the parent process to go away without
the child ending. In that case there will be no parent jobname. (Well
obviously there *was* one at one time, but its control blocks may be
long gone, and the address space reused.

>  In addition, in my case, I have a spawned Java job. I'm finding that the JBNI
>  and JBNS fields of both the ASCB and the ASSB point to the following names:
>
>  JBNI. TESTJOB1 JBNS. BPXAS
>
>  Now my question is can I rely and JBNS=BPXAS to determine the parent
>  address space's name is equal to the child address space's name minus the
>  child's last job name character?

I wouldn't muck with that stuff. IBM has changed the algorithm in the
past, and may do so again.

What is it you are really trying to accomplish? Why is it useful to
know the parent's jobname?

One thing you could do is call BPX1GPP to get the parent's PID, and
then use that to call BPX1GTH, which among other things can return the
jobname for that process. These are supported things to do.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Lindy Mayfield]

Perhaps this sequence of steps (from a colleague of mine) might work to
get you the original job name.

As long as you are not in a system exit, like IEFUTL, you should be able
to do the following:

1.  Check to see if the address space is properly dubbed 
2.  Uset getppid() to get the parent's pid
3.  Use w_getpsent() call to get information about jobname, username,
and so on.  
4.  Is the ppid 1?  Then I think you've arrived at the address space you
are looking for.  This I think is the one that used to be BPXAS.
5.  Check to see if w_getpsent() returned a UNIX process.  If so loop to
#2.  

I'm not sure that is exactly correct, but perhaps it is in the ballpark?

There is some new documentation in the z/OS 1.9 book that says you
cannot issue "nested" callable services.  And most importantly
concerning system exits: "...if a z/OS UNIX callable service invokes an
exit during the processing of the callable service, invoking z/OS UNIX
callable services from the exit program is not supported."



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Support, DUNNIT SYSTEMS LTD.
Sent: 19. maaliskuuta 2008 11:11
To: IBM-MAIN@bama.ua.edu
Subject: Can forked/spawned address spaces be identified as such?

Are there any control block fields or flags within these address spaces
that 
indentify them as being started by a fork or spawn action? Are there
different 
indicators for forked versus spawned address spaces?

TIA,
Jerry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Support, DUNNIT SYSTEMS LTD.]

Tony,

>Keep in mind that UNIX allows the parent process to go away without
>the child ending. In that case there will be no parent jobname. (Well
>obviously there *was* one at one time, but its control blocks may be
>long gone, and the address space reused.

I don't need the parent around any longer. I just need to know the parent's 
job name.

>I wouldn't muck with that stuff. IBM has changed the algorithm in the
>past, and may do so again.

I had that intuitive feeling, too.

>What is it you are really trying to accomplish? Why is it useful to
>know the parent's jobname?

The program I'm working on sometimes depends on job name matching for its 
logic.

>One thing you could do is call BPX1GPP to get the parent's PID

Can't go there. The program may receive control in a task above the initial job 
step task (JST).

And now that I've had time to review yesterday's suggestion of BPXEKDA, I'm 
uncertain that anything asking me for a megabyte output buffer is just what 
the doctor ordered. Or can I obtain a much smaller buffer when the 
BPXZODMV macro's input parms specifies "OdmvAsids"? (Anyone have a coding 
example of setting up BPXZODMV for such a call?)

Even there, I will only get back the parent's PID and may not always be able 
to translate that to the parent's job name. Well, at least such and invocation 
can retrieve the current process's USERID. Is that correct? If so, curious: 
what's the difference between these 2:

ODMVRUID DSF Process Real User Id 
ODMVEUID DSF Process Effective User Id

Any other ideas? Or should I just assume that I can never GUARANTEE 
knowing the parent job name for EVERY such process?

Jerry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Walt Farrell]

On Fri, 21 Mar 2008 02:19:27 -0500, Support, DUNNIT SYSTEMS LTD.
<[EMAIL PROTECTED]> wrote:

>...snipped...
>>What is it you are really trying to accomplish? Why is it useful to
>>know the parent's jobname?
>
>The program I'm working on sometimes depends on job name matching for its
>logic.
>
>>One thing you could do is call BPX1GPP to get the parent's PID
>
>Can't go there. The program may receive control in a task above the initial job
>step task (JST).

Without knowing more about what you're doing it's hard to be sure, but I
think you may want to rethink your dependency on job names.  For one thing,
don't forget that job names don't have to be unique.  You could have
multiple STCs with the same job name active at the same time, for example,
or a TSO user and a batch job of the same name.  

So, trying to do anything across address spaces based on only the job name
has a strong likelihood of getting you into trouble sometime, somewhere.

Add that to the fact that you're running in an unusual part of the task
structure (above the job step task) and the likelihood of problems gets even
higher, I think.

>... snipped...
>Even there, I will only get back the parent's PID and may not always be able
>to translate that to the parent's job name. Well, at least such and invocation
>can retrieve the current process's USERID. Is that correct? If so, curious:
>what's the difference between these 2:
>
>ODMVRUID DSF Process Real User Id
>ODMVEUID DSF Process Effective User Id
>

First, are you wanting the MVS user ID (8 byte character string) or the UNIX
UID (4 byte number)?  You've just found the UNIX UIDs for the process there,
or two of them at least.

As for the difference, you may want to do some reading on UNIX if you have
to ask that question, but a process starts with a UID that is both it's
"real" UID and "effective" UIDs. The effective UID is used for most UNIX
access checking decisions. While running  it can make a temporary change to
a different UID.  That UID becomes its new effective UID, and is used for
UNIX purposes until the process switches back to its real UID.

By the way, I suggest using the MVS-OE mailing list rather than IBM-MAIN if
you have detailed z/OS UNIX questions.

-- 
  Walt Farrell, CISSP
  IBM STSM, z/OS Security Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Support, DUNNIT SYSTEMS LTD.]

Thanks, Walt. After receiving all responses here, at the end of the day, it 
looks like we cannot rely on obtaining the parent's jobname anyway. 
Referencing the RACF user ID through conventional methods looks like the way 
to go.

More lessons learned. Thanks all!

Jerry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Mark Zelden]

On Fri, 21 Mar 2008 05:33:47 -0500, Walt Farrell <[EMAIL PROTECTED]> wrote:

> You could have
>multiple STCs with the same job name active at the same time, for example,
>or a TSO user and a batch job of the same name.
>

You can have multiple batch jobs with the same name running also with JES2 
since OS/390 2.6 (JOBDEF DUPL_JOB=NODELAY setting).  The same is
true with JES3 (DUPJOBNM=YES).  I don't know how long that support has
been there with JES3 though.  I'm sure Ed does.  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
> Sent: Thursday, March 20, 2008 5:05 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Can forked/spawned address spaces be identified as such?
> 
> 
> Support, DUNNIT SYSTEMS LTD. wrote:
> > So is there any way to determine the original parent 
> address space's name 
> > from within the child's address space?
> >   
> 
> BPXEKDA returns the structure mapped by BPXZODMV. OdmvPPID is the 
> parent's Process ID.
> 
> -- 
> Edward E Jaffe

But the original parent process may have terminated, in which case the
current parent process is PID(1), which I think is BPXOINIT.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Peter Relson]

>Why aren't things like this exposed ???. And if they are, why aren't
>they (publicly/freely) documented.

If you want a programming interface for something, then you ought to
formally ask for it. The "action", if the request is accepted, might be to
create something new or might be to identify as a programming interface the
field you already knew about.

You have no way of knowing what intricate ramifications there might be for
bits that are not programming interfaces that you happen to think do what
you want.  And we have no reason to avoid making changes in such areas when
such changes are appropriate to the product, including in service, and such
changes might invalidate your assumptions.

Even when something is a programming interface, you might not be given
enough information. But that in general is unintentional, and further
detail would be provided (and added to the documentation). Making an
assumption about something that is unstated is almost always a bad thing to
do.

Most non-programming interface fields are created for the operating
system's use. And that is all that can and should be said about them
externally. If we wanted you to write code to rely on such things, we would
have identified them as interfaces. To use non-interface fields is to put
your system at risk. You are welcome to take that risk if it is your
system.

So let's take ASSBFSAS for example, since that is being bandied about.
There can be no controversy about what its line comment is: WLM Managed OE
Forked/Spawned address space. After all, only Bill Clinton quibbles about
what "is" means. Now as to what it "means", here are some questions I'd
have:
-- Is it on for a forked/spawned address space if the space is not WLM
managed?
-- Is it on regardless of WLM's processing mode?
-- Does "WLM managed" even refer to the address sapce itself or some WLM
management of fork/spawn?
-- Is it turned on before the "child" starts running?
-- Is it ever turned off?
I don't happen to know the answer to any of these questions. And I don't
propose to find out.

If I had a choice and needed to know something about fork/spawn attributes,
I would prefer looking at an indicator set/owned by USS rather than one set
by WLM.

Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden
> Sent: Friday, March 21, 2008 8:16 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Can forked/spawned address spaces be identified as such?
> 
> 
> On Fri, 21 Mar 2008 05:33:47 -0500, Walt Farrell 
> <[EMAIL PROTECTED]> wrote:
> 
> > You could have
> >multiple STCs with the same job name active at the same 
> time, for example,
> >or a TSO user and a batch job of the same name.
> >
> 
> You can have multiple batch jobs with the same name running 
> also with JES2 
> since OS/390 2.6 (JOBDEF DUPL_JOB=NODELAY setting).  The same is
> true with JES3 (DUPJOBNM=YES).  I don't know how long that support has
> been there with JES3 though.  I'm sure Ed does.  
> 
> Mark
> --

And just to update, at least in z/OS 1.8 JES2, the DUPL_JOB can be set
YES/NO by job class!

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Gregory Pinkowski]

I don't want to instigate or contest in any public online "flaming" war, nor 
to be picking apart the appreciated response you took thoughtful time to 
compose; but I'm still a bit touchy on subjects with even tangents brushing 
upon Object Code Only (OCO) policy.  This is a tangent off the original 
subject, so please take this in the congenial respectful spirit in which 
it's intended, and do not mis-interpret my long-winded but heartfelt reply 
as mere rant.  I'm sitting here with the day off for Good Friday and having 
a drink relaxing...beating a dead horse to pass the time in digital 
conversation with colleagues rather than formulating a professional reaction 
and stance.  I hitched my career (and thus the prosperity of my family) to 
IBM's OS architecture, and IMHO OCO is one reason for its decline in the 
marketplace.  I don't understand how IBM can simultaneously embrace open 
source LINUX and OCO z/OS without some cataclysmic schism tearing the very 
fabric of time/space but I'm not sure I want it explained to me either LOL! 
I prefer to be collegial and inoffensive, but this IBM internal doublethink 
seems to me to have become so ingrained that even now after years of what I 
see as evidence from the marketplace OCO remains in IBM's corporate culture 
nearly unchallenged, with a common and practiced reply.  OCO is a policy 
which takes something away from their customers and the world, and 
especially from the z/OS enthusiast, which includes most of us on-list 
though I speak only for myself.  OCO is non-supportive of academic and 
theoretical computer science, and ultimately it restricts our ability to 
investigate.  I can only conjecture how OCO policy was originally influenced 
by legal implications and lawsuits at the time, proprietary copyright 
insecurity, or controlling and supporting customer sysmods across 
migrations; but regardless IMHO OCO policy was and remains a serious 
mistake.  When IBM talks down to me implying "source??...you can't handle 
source", as an operating systems internals specialist I find that a little 
limiting, occasionally problematic, maybe the word is "demeaning", and in 
the marketspace ultimately self-fulfilling (practically speaking, would I 
need a PL/S compiler or would a C compiler now often suffice LOL?).  Back in 
the 1970's I learned much of what I knew about VM from source code, and 
perhaps I never quite got over my deep concern and disappointment when IBM 
announced its OCO policy back then.  Today's young nerds DO have a reaction 
when exposed to LINUX source in school, even if they never use it...it just 
is "cool" to peruse the real thing, just in appreciation if nothing else.



You have no way of knowing what intricate
ramifications there might be for
bits that are not programming interfaces
that you happen to think do what you want."
Though I obviously can't predict with certainty what IBM may do with a field 
in the future, within a defined environment that statement is unfortunately 
true primarily because IBM does not share source.  IBM's developers are able 
to function with the source and doc they have internally but I'm not holding 
my breath to see full release of the same, even to an "IBM Partner" much 
less a customer.  I greatly appreciate IBM's diligent demarcation of the 
lines of their commitments and responsibilities, and agree it's important to 
recognize those distinctions between what is and is not an external 
programming interface.  IBM's reputation for upward compatibility is 
undeniably unsurpassed, and their distinction and definition of supported 
interfaces is a big reason for that success and resultant longevity.  I'm 
occasionally willing to evaluate my use of a particular field to the extent 
possible.  Even commercial system management software is still full of 
dependencies on internal and unsupported fields and interfaces, not that 
anyone prefers that.



I don't happen to know the answer to any of these questions.
And I don't propose to find out.
I would not want to ask you to.  But maybe I'd like to someday...or not. 
Whether a field should be used for my particular purpose...I'd occasionally 
like to be able to investigate that, and would appreciate any help toward 
those ends.  I've had marketing types come to me and say thinks like "we 
don't know whether this is possible, but we want..." and ultimately with 
source nearly anything is "possible".  Would I really want to thoroughly 
investigate source for this particular question?  Probably not.  I do 
understand your point too.  Like I said, I'm just a bit touchy on the 
subject...  Best regards and please enjoy the weekend. 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Kirk Wolf]

Gregory,

I hesitate responding to your post - its mass might otherwise tend to kill
this thread, which IMO would be a good thing :-)

I agree with most of what you've written.  IBM needs to transition from
worrying about protecting z/OS source code to worrying that nobody will want
to see it.

I have a different view of Peter Relson's posts - I think that he is only
trying to explain which parts of control blocks are meant to be interfaces
and which are not.   This distinction has no analog in modern operating
systems, where interfaces are expressed *entirely* by APIs and service
routines, and not by skipping through PSA->ASCB->etc.etc.

In any case, I appreciate Mr. Relson's (and other IBMers) contributions to
IBM-MAIN, even if I don't always like what they say.

Kirk Wolf
Dovetailed Technologies

PS> A sore point with me is always "submit a requirement", but that's
another topic.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Shane]

On Fri, 2008-03-21 at 17:20 -0500, Kirk Wolf wrote:

> I have a different view of Peter Relson's posts - I think that he is only
> trying to explain which parts of control blocks are meant to be interfaces
> and which are not.   This distinction has no analog in modern operating
> systems, where interfaces are expressed *entirely* by APIs and service
> routines, and not by skipping through PSA->ASCB->etc.etc.

I take it then you've not taken a stroll down task_list on a Linux
system. Meandering off from (any) task_struct is remarkably familiar.
Having the code is, of course, the key here.

> In any case, I appreciate Mr. Relson's (and other IBMers) contributions to
> IBM-MAIN, even if I don't always like what they say.

Likewise. My beef is with the corporate dictate.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Alan Altmark]

On Fri, 21 Mar 2008 17:20:24 -0500, Kirk Wolf <[EMAIL PROTECTED]> wrote:
>I hesitate responding to your post - its mass might otherwise tend to kill
>this thread, which IMO would be a good thing :-)

I'm with you on that point... however    ;-)

>I agree with most of what you've written.  IBM needs to transition from
>worrying about protecting z/OS source code to worrying that nobody will
>want to see it.

Having done development in the Linux kernel (for System z) and in z/VM (a 
mix of source and OCO), having source code is of limited use.  If you don't 
know *why* it works the way it does, the source is meaningless.  Over time 
you can certainly teach yourself *how*, but not *why*.

One of the most difficult problems I faced writing the original IUCV support 
for 
Linux was the complete lack of professional high-level and low-level design 
materials, not the lack of source code.  And that source code is in C, where 
the "how" is more obvious than in my native language (assembler).  It just 
didn't help.  And, sure enough, there were later changes in the 
internal "interfaces" that I unknowingly misused.   Nuances I had missed.  It 
worked, but it wasn't pretty and ultimately to be re-written.

Don't read the above as being anti-Source; it isn't, and I'm not.  I just I 
hope 
it illustrates that source code is not a panacea.  For some things it is 
necessary, but not sufficient.

>I have a different view of Peter Relson's posts - I think that he is only
>trying to explain which parts of control blocks are meant to be interfaces
>and which are not.   This distinction has no analog in modern operating
>systems, where interfaces are expressed *entirely* by APIs and service
>routines, and not by skipping through PSA->ASCB->etc.etc.

Control blocks aren't the problem.  Understanding the why's and wherefore's 
of the values in them is the problem.   They're in the same control block, so 
they have a relationship, but what is it?

I think Peter's most important point was that of stability.  The more you use 
with things the author didn't intend you to use, the more risk you add to your 
system.

I think that the clear delineation and respect for "application 
interfaces", "product-specific system interfaces", and "non-interfaces", has in 
no small part contributed to the longevity of the platform.  Compatibility is 
not 
an accident.

>In any case, I appreciate Mr. Relson's (and other IBMers) contributions to
>IBM-MAIN, even if I don't always like what they say.

Glad to hear it!  "Intelligent minds may differ."

>A sore point with me is always "submit a requirement", but that's
>another topic.

When you feel up to it, please start another thread and let's find out why.  
It's 
not the first time I've heard that.

Alan Altmark
z/VM Development (25+ years)
IBM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Wolf
> Sent: Friday, March 21, 2008 5:20 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Can forked/spawned address spaces be identified as such?
> 

[snip]

> 
> Kirk Wolf
> Dovetailed Technologies
> 
> PS> A sore point with me is always "submit a requirement", but that's
> another topic.
> 

I don't know that I agree with you on that one. My job is justified, in
part, by Service Request Tickets and how fast I can respond to them.
They are a management-easy way to show that I am doing something that
somebody actually wanted, not just something that I dreamt up myself. Of
course, very simple things are done via email. But if I think that
something is going to take a few hours, rather than off-the-cuff, then I
want a ticket. Programmers sometimes have the same reaction that
yourself, and others, have of thinking it is a waste of time and effort.
Not to me it isn't!

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 03/21/2008
   at 09:26 AM, Peter Relson <[EMAIL PROTECTED]> said:

>You have no way of knowing what intricate ramifications there might be
>for bits that are not programming interfaces that you happen to think do
>what you want.  And we have no reason to avoid making changes in such
>areas when such changes are appropriate to the product, including in
>service, and such changes might invalidate your assumptions.

The flip side is that I've seen some unsupported interfaces remain usable
for far longer than some documented interfaces. In at least one case the
documented a documented interface only lasted for one incremental release.

That said, I agree that it's best to formally request a supported
interface.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
03/21/2008
   at 05:20 PM, Kirk Wolf <[EMAIL PROTECTED]> said:

>This distinction has no analog in modern operating
>systems, where interfaces are expressed *entirely* by APIs and service
>routines, and not by skipping through PSA->ASCB->etc.etc.

That's certainly the preference in *ix systems, but it's not always what
happens. Take tool for manipulating file systems. Or look at standard
services routines that take structure arguments, typically via pointers.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Kirk Wolf]

Service routines that take structure pointers aren't a problem so long as
the structure is part of the interface and not the actual kernel
implementation structure.


On Tue, Mar 25, 2008 at 7:35 AM, Shmuel Metz (Seymour J.) <
[EMAIL PROTECTED]> wrote:

> In <[EMAIL PROTECTED]>, on
> 03/21/2008
>at 05:20 PM, Kirk Wolf <[EMAIL PROTECTED]> said:
>
> >This distinction has no analog in modern operating
> >systems, where interfaces are expressed *entirely* by APIs and service
> >routines, and not by skipping through PSA->ASCB->etc.etc.
>
> That's certainly the preference in *ix systems, but it's not always what
> happens. Take tool for manipulating file systems. Or look at standard
> services routines that take structure arguments, typically via pointers.
>
> --
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
> 
> >
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Can forked/spawned address spaces be identified as such?

[Peter Hunkeler]

On Thu, 20 Mar 2008 22:04:44 +, Ted MacNEIL <[EMAIL PROTECTED]> 
wrote:

>>Is the rule correct that every case - with no exceptions - of a 
forked/spawned address space has a single digit from 1 to 9 appended to the
>job name?
>
>No. Eight character jobnames are truncated to 7, and then the digit is added.
>
>>If so, what happens after 9 such spawns?
>
>We go alphabetic - A, B, C, ...

Not true! 

See chapter 21.8 Generating jobnames for OMVS address spaces in the "z/OS 
UNIX System Services Plannig" manual for the details.

In summary, a single digit is added to jobnames shorter than 8 characters. 
After 9 has been used the digit wraps back top 1. Eight character jobnames 
stay unchanged. In some cases a new, completely unrelated jobname may be 
used.

-- 
Peter Hunkeler
Credit Suisse

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

OCO, Requirements, etc. (was: Can forked/spawned address spaces be identified as such?)

[Patrick O'Keefe]

On Fri, 21 Mar 2008 17:20:24 -0500, Kirk Wolf <[EMAIL PROTECTED]> 
wrote:

>...
>  IBM needs to transition from
>worrying about protecting z/OS source code to worrying that 
>nobody will want  to see it.
>...

One of IBM's originally stated reasons for moving to OCO was to 
help stop overburdening support teams with PMRs for "bugs" that 
were actually code that was poorly modified by customers.  I don't
know if that was every actually much of a problem, but it certainly 
would be now with IBM's reduced support staff.

I've always felt that one of the worst parts of the OCO move was 
elimination of PLM.   IBM could have continued providing them and 
still achieved everything they claimed OCO was supposed to do.

>...
>PS> A sore point with me is always "submit a requirement", but that's
>another topic.
>...

Sometimes  that's just a put-off, but sometimes it's an real request;
they need to show justification for working on something.

Pat O'Keefe 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html