Re: IEC143I 213-30

[Shmuel Metz (Seymour J.)]

In <45d79eacefba9b428e3d400e924d36b902d16...@iwdubcormsg007.sci.local>, on
12/07/2009
   at 11:30 AM, "Thompson, Steve"  said:

>Meanwhile, I had found an ABEND that happens when two tasks are trying
>to do STOW at the same time.

That's because you didn't have proper serialization. You need to do the
ENQ (RESERVE) before the OPEN and the DEQ after the CLOSE. BPAM does not
support multiple concurrent opens of the same PDS for output.

>During design, we concluded that we had to use the "ISPF EDIT ENQUEUE".

Which ENQ? ISPF uses one to serialize the member and one to serialize the
data set; you need to use both.
 
-- 
 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC143I 213-30

[Shmuel Metz (Seymour J.)]

In
<2121472874-1259961467-cardhu_decombobulator_blackberry.rim.net-17612826...@bda488.bisx.prod.on.blackberry>,
on 12/04/2009
   at 09:17 PM, Ted MacNEIL  said:

>You can't share regular PDS datasets either.

Of course you can. Whether or not you know how to do it safely, others do.
 
-- 
 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC143I 213-30

[Ted MacNEIL]

>I'll grant this is unlikely; I'd prefer not to try to create it.
>Perhaps Ted is thinking of something in addition.

The last time I saw it was in a hmegrown source management system -- not using 
ISPF services.
-
Too busy driving to stop for gas!

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

Re: IEC143I 213-30

[Ted MacNEIL]

>In more detail, last guy to save wins; first guy's changes are lost.

That's what I meant.

>Some might consider this corruption.  But directory integrity is
maintained.

Data integrity is what I meant.

-
Too busy driving to stop for gas!

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

Re: IEC143I 213-30

[Ted MacNEIL]

>This is not true Ted, as we have discussed before.  In fact, the symptom in 
>the title of this thread is the result of IBM closing that exposure.

I thought it was only fixed in a SYSPLEX environment.
I have not worked in a non-SYSPLEX world for over 15 years, so I have not 
shared either kind of partitioned dataset outside that boundary in that same 
period of time.
-
Too busy driving to stop for gas!

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

Re: IEC143I 213-30

[Scott Rowe]

Yes, the 213-13 abend is the solution, if you try to open a DCB for output when 
there is already an output DCB open for a PDS, it will cause the abend.  I 
cannot see how corruption can occur if you can't have two DCBs open for output 
at the same time.  The ENQ is only to avoid getting the abend.

>>> "Thompson, Steve"  12/7/2009 11:30 AM >>>
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Monday, December 07, 2009 9:40 AM
To: IBM-MAIN@bama.ua.edu 
Subject: Re: IEC143I 213-30

On Mon, 7 Dec 2009 09:53:26 -0500, Scott Rowe wrote:

>I don't believe that's true, Gil.  It doesn't make sense given the
changes that were made to the logic, and I can't create it here.  Do you
have a test case that shows this?
>
I believe SPFEDIT mostly protects you.  To show the problem
you'd need to have:

o DSNTYPE=PDS

o DISP=SHR

o Update by a process other than ISPF EDIT, and which doesn't
  respect the SPFEDIT ENQ.

I'll grant this is unlikely; I'd prefer not to try to create it.
Perhaps Ted is thinking of something in addition.



I've not been following this thread closely. But it seems that about
this time last year I started dealing with a related issue. So if this
is not germane to your discussions, just ignore it.

Meanwhile, I had found an ABEND that happens when two tasks are trying
to do STOW at the same time. In my situation, this was a race (or timing
dependant) condition and it could be done within a single LPAR between
two address spaces (and I think I was even able to get it within the
same address space). I did this under z/OS V1R9. Since we did things to
prevent it, I would have to break the code to recreate under z/OS
V1R10/11.

During design, we concluded that we had to use the "ISPF EDIT ENQUEUE".
But during testing we found that if you are doing a STOW for member "X"
while another task is attempting member "Y" at the same time, the "ISPF
EDIT ENQUEUE" does not protect the directory from a simultaneous update
situation, only from two tasks using the same member.

In order to prevent this ABEND situation, we decided to use an ENQUEUE
for the directory updates. The ENQUEUE actually protects from the
problem within one address space or across two -- and only between uses
of the product (which is still underdevelopment) since the ENQUEUE we
came up with is "private".

The STOW situation I ran into did not require a member write, only that
you wish to update the directory entry. In my case, attempting to add
the "ISPF" stats caused the ABEND. And because of race (or timing as you
prefer) conditions I was getting two STOWs being done at the same time
to the same directory. The system detected this and the arbitrary second
updater got the ABEND.

Regards,
Steve Thompson

-- Opinions expressed by this poster may not reflect those of poster's
employer --

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



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


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

Re: IEC143I 213-30

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Monday, December 07, 2009 9:40 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEC143I 213-30

On Mon, 7 Dec 2009 09:53:26 -0500, Scott Rowe wrote:

>I don't believe that's true, Gil.  It doesn't make sense given the
changes that were made to the logic, and I can't create it here.  Do you
have a test case that shows this?
>
I believe SPFEDIT mostly protects you.  To show the problem
you'd need to have:

o DSNTYPE=PDS

o DISP=SHR

o Update by a process other than ISPF EDIT, and which doesn't
  respect the SPFEDIT ENQ.

I'll grant this is unlikely; I'd prefer not to try to create it.
Perhaps Ted is thinking of something in addition.



I've not been following this thread closely. But it seems that about
this time last year I started dealing with a related issue. So if this
is not germane to your discussions, just ignore it.

Meanwhile, I had found an ABEND that happens when two tasks are trying
to do STOW at the same time. In my situation, this was a race (or timing
dependant) condition and it could be done within a single LPAR between
two address spaces (and I think I was even able to get it within the
same address space). I did this under z/OS V1R9. Since we did things to
prevent it, I would have to break the code to recreate under z/OS
V1R10/11.

During design, we concluded that we had to use the "ISPF EDIT ENQUEUE".
But during testing we found that if you are doing a STOW for member "X"
while another task is attempting member "Y" at the same time, the "ISPF
EDIT ENQUEUE" does not protect the directory from a simultaneous update
situation, only from two tasks using the same member.

In order to prevent this ABEND situation, we decided to use an ENQUEUE
for the directory updates. The ENQUEUE actually protects from the
problem within one address space or across two -- and only between uses
of the product (which is still underdevelopment) since the ENQUEUE we
came up with is "private".

The STOW situation I ran into did not require a member write, only that
you wish to update the directory entry. In my case, attempting to add
the "ISPF" stats caused the ABEND. And because of race (or timing as you
prefer) conditions I was getting two STOWs being done at the same time
to the same directory. The system detected this and the arbitrary second
updater got the ABEND.

Regards,
Steve Thompson

-- Opinions expressed by this poster may not reflect those of poster's
employer --

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

Re: IEC143I 213-30

[Paul Gilmartin]

On Mon, 7 Dec 2009 09:53:26 -0500, Scott Rowe wrote:

>I don't believe that's true, Gil.  It doesn't make sense given the changes 
>that were made to the logic, and I can't create it here.  Do you have a test 
>case that shows this?
>
I believe SPFEDIT mostly protects you.  To show the problem
you'd need to have:

o DSNTYPE=PDS

o DISP=SHR

o Update by a process other than ISPF EDIT, and which doesn't
  respect the SPFEDIT ENQ.

I'll grant this is unlikely; I'd prefer not to try to create it.
Perhaps Ted is thinking of something in addition.

 Paul Gilmartin 9:39 AM >>>
>On Mon, 7 Dec 2009 09:31:47 -0500, Scott Rowe wrote:
>
>>This is not true Ted, as we have discussed before.  In fact, the symptom in 
>>the title of this thread is the result of IBM closing that exposure.
>>
>Depends.
>
> Ted MacNEIL 12/6/2009 9:46 PM >>>
>>>Oh?  Even with GRS in place?  Because we are doing this.
>>
>>There are potential corruption issues when two people are editing members on 
>>different swystems.
>>Both read the same offsets.
>>Whoever saves wins!
>>
>In more detail, last guy to save wins; first guy's changes are lost.
>Some might consider this corruption.  But directory integrity is
>maintained.
>
>-- gil
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html 
>
>
>
>CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
>confidential and privileged information intended only for the addressee.  If 
>you are not the intended recipient, please be advised that you have received 
>this material in error and that any forwarding, copying, printing, 
>distribution, use or disclosure of the material is strictly prohibited.  If 
>you have received this material in error, please (i) do not read it, (ii) 
>reply to the sender that you received the message in error, and (iii) erase or 
>destroy the material. Emails are not secure and can be intercepted, amended, 
>lost or destroyed, or contain viruses. You are deemed to have accepted these 
>risks if you communicate with us by email. Thank you.
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC143I 213-30

[Scott Rowe]

I don't believe that's true, Gil.  It doesn't make sense given the changes that 
were made to the logic, and I can't create it here.  Do you have a test case 
that shows this?

>>> Paul Gilmartin  12/7/2009 9:39 AM >>>
On Mon, 7 Dec 2009 09:31:47 -0500, Scott Rowe wrote:

>This is not true Ted, as we have discussed before.  In fact, the symptom in 
>the title of this thread is the result of IBM closing that exposure.
>
Depends.

 Ted MacNEIL 12/6/2009 9:46 PM >>>
>>Oh?  Even with GRS in place?  Because we are doing this.
>
>There are potential corruption issues when two people are editing members on 
>different swystems.
>Both read the same offsets.
>Whoever saves wins!
>
In more detail, last guy to save wins; first guy's changes are lost.
Some might consider this corruption.  But directory integrity is
maintained.

-- gil

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



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


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

Re: IEC143I 213-30

[Paul Gilmartin]

On Mon, 7 Dec 2009 09:31:47 -0500, Scott Rowe wrote:

>This is not true Ted, as we have discussed before.  In fact, the symptom in 
>the title of this thread is the result of IBM closing that exposure.
>
Depends.

 Ted MacNEIL 12/6/2009 9:46 PM >>>
>>Oh?  Even with GRS in place?  Because we are doing this.
>
>There are potential corruption issues when two people are editing members on 
>different swystems.
>Both read the same offsets.
>Whoever saves wins!
>
In more detail, last guy to save wins; first guy's changes are lost.
Some might consider this corruption.  But directory integrity is
maintained.

-- gil

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

Re: IEC143I 213-30

[Scott Rowe]

You can't share them for update, as you have discovered.  I would suggest you 
take this to your sysprogs and tell them you have a requirement they need them 
to satisfy, and you could even suggest that Sysplex is one solution.  If they 
don't listen, take it to management. 

>>> Frank Swarbrick  12/4/2009 7:51 PM >>>
>>> On 12/4/2009 at 2:17 PM, in message
<2121472874-1259961467-cardhu_decombobulator_blackberry.rim.net-17612826...@bda4
8.bisx.prod.on.blackberry>, Ted MacNEIL  wrote:
>> Exactly my point.  Someone asked me why I said we didn't want to use PDSE to 
> solve my issue and I said because we can't share them well, because we're not 
> in a Sysplex.
> 
> You can't share regular PDS datasets either.

Oh?  Even with GRS in place?  Because we are doing this.

Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


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

Re: IEC143I 213-30

[Scott Rowe]

This is not true Ted, as we have discussed before.  In fact, the symptom in the 
title of this thread is the result of IBM closing that exposure.

>>> Ted MacNEIL  12/6/2009 9:46 PM >>>
>Oh?  Even with GRS in place?  Because we are doing this.

There are potential corruption issues when two people are editing members on 
different swystems.
Both read the same offsets.
Whoever saves wins!
-
Too busy driving to stop for gas!

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



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


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

Re: IEC143I 213-30

[Ted MacNEIL]

>Oh?  Even with GRS in place?  Because we are doing this.

There are potential corruption issues when two people are editing members on 
different swystems.
Both read the same offsets.
Whoever saves wins!
-
Too busy driving to stop for gas!

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

Re: IEC143I 213-30

[Frank Swarbrick]

>>> On 12/4/2009 at 2:17 PM, in message
<2121472874-1259961467-cardhu_decombobulator_blackberry.rim.net-17612826...@bda4
8.bisx.prod.on.blackberry>, Ted MacNEIL  wrote:
>> Exactly my point.  Someone asked me why I said we didn't want to use PDSE to 
> solve my issue and I said because we can't share them well, because we're not 
> in a Sysplex.
> 
> You can't share regular PDS datasets either.

Oh?  Even with GRS in place?  Because we are doing this.

Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: IEC143I 213-30

[Ted MacNEIL]

>I think you can since, I think, a RESERVE is issued against the DRIVE 
during the update.

Only during update.
If two people are editing and do saves at different times then there is a 
potential for corruption.
-
Too busy driving to stop for gas!

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

Re: IEC143I 213-30

[Robert A. Rosenberg]

At 21:17 + on 12/04/2009, Ted MacNEIL wrote about Re: IEC143I 213-30:

 >Exactly my point.  Someone asked me why I said we didn't want to 
use PDSE to solve my issue and I said because we can't share them 
well, because we're not in a Sysplex.


You can't share regular PDS datasets either.


I think you can since, I think, a RESERVE is issued against the DRIVE 
during the update.


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

Re: IEC143I 213-30

[Frank Swarbrick]

I think so to, but it is not my decision to make.

Perhaps one of our sysprogs will read this and get that discussion restarted 
amongst themselves.  I have tried to nudge them in that direction in the past, 
but nothing has come of it.
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


On 12/4/2009 at 2:47 PM, in message <4b193d17.8489.00d...@joann.com>, Scott
Rowe  wrote:
> Yes, Ted, I think he's figured that out.
>  
> Frank, as I've mentioned before, I really think you guys need to re-visit the 
> Sysplex question again.  There is really no reason to not be running at least 
> a base Sysplex, it should vastly improve things there.  IIRC, you are running 
> GRS in ring mode without a Base Sysplex, which is a really poor performer.  
> There are many benefits and zero cost in changing to a base Sysplex from 
> there.
> 
 Ted MacNEIL  12/4/2009 4:17 PM >>>
>>Exactly my point.  Someone asked me why I said we didn't want to use PDSE to 
> solve my issue and I said because we can't share them well, because we're not 
> in a Sysplex.
> 
> You can't share regular PDS datasets either.
> 
> 
> -
> Too busy driving to stop for gas!
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html 
> 
> 
> 
> CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
> confidential and privileged information intended only for the addressee.  If 
> you are not the intended recipient, please be advised that you have received 
> this material in error and that any forwarding, copying, printing, 
> distribution, use or disclosure of the material is strictly prohibited.  If 
> you have received this material in error, please (i) do not read it, (ii) 
> reply to the sender that you received the message in error, and (iii) erase 
> or destroy the material. Emails are not secure and can be intercepted, 
> amended, lost or destroyed, or contain viruses. You are deemed to have 
> accepted these risks if you communicate with us by email. Thank you.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: IEC143I 213-30

[Scott Rowe]

Yes, Ted, I think he's figured that out.
 
Frank, as I've mentioned before, I really think you guys need to re-visit the 
Sysplex question again.  There is really no reason to not be running at least a 
base Sysplex, it should vastly improve things there.  IIRC, you are running GRS 
in ring mode without a Base Sysplex, which is a really poor performer.  There 
are many benefits and zero cost in changing to a base Sysplex from there.

>>> Ted MacNEIL  12/4/2009 4:17 PM >>>
>Exactly my point.  Someone asked me why I said we didn't want to use PDSE to 
>solve my issue and I said because we can't share them well, because we're not 
>in a Sysplex.

You can't share regular PDS datasets either.


-
Too busy driving to stop for gas!

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



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


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

Re: IEC143I 213-30

[Ted MacNEIL]

>Exactly my point.  Someone asked me why I said we didn't want to use PDSE to 
>solve my issue and I said because we can't share them well, because we're not 
>in a Sysplex.

You can't share regular PDS datasets either.


-
Too busy driving to stop for gas!

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

Re: IEC143I 213-30

[Frank Swarbrick]

>>> On 12/4/2009 at 12:34 PM, in message
, Tom Marchant
 wrote:
> On Fri, 4 Dec 2009 12:01:29 -0700, Frank Swarbrick wrote:
> 
>>I'm not the sysprog, so I may not have all of the details, but 
>>if I remember correctly these are the issues:
>>
>>We have PDSESHARING(NORMAL) in our IGDSMSxx member, 
>>rather than PDSESHARING(EXTENDED).
>>
>>From
> http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.z 
> os.r9.idad400/pdsesh3.htm
>>
>>"In a multiple-system environment, the system programmer uses 
>>PDSESHARING(EXTENDED) to share PDSEs at the member level. 
>>A system programmer must specify PDSESHARING(EXTENDED) in 
>>the IGDSMSxx member in the SYS1.PARMLIB on each system in 
>>the sysplex. Every system that is sharing a PDSE must be a 
>>member of the sysplex and have the sysplex coupling facility 
>>(XCF) active."
>>
>>We don't have the sysplex, so we're stuck with 
>>PDSESHARING(NORMAL).
>>This causes problems when one system has a PDSE open and 
>>a second system opens it and tries to update it.  Take for 
>>example the following scenario, which I just tested.
>>
> 
> This has been discussed several times.  Please search the archives.  You can
> not share a PDSE outside of a Sysplex.  If you are not in a Sysplex, you can
> not share a PDSE with another system.  If you do so, you can expect the PDSE
> to break.  You quoted the reference. "Every system that is sharing a PDSE
> must be a member of the sysplex and have the sysplex coupling facility (XCF)
> active."

Exactly my point.  Someone asked me why I said we didn't want to use PDSE to 
solve my issue and I said because we can't share them well, because we're not 
in a Sysplex.

Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: IEC143I 213-30

[Tom Marchant]

On Fri, 4 Dec 2009 12:01:29 -0700, Frank Swarbrick wrote:

>I'm not the sysprog, so I may not have all of the details, but 
>if I remember correctly these are the issues:
>
>We have PDSESHARING(NORMAL) in our IGDSMSxx member, 
>rather than PDSESHARING(EXTENDED).
>
>From
http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.idad400/pdsesh3.htm
>
>"In a multiple-system environment, the system programmer uses 
>PDSESHARING(EXTENDED) to share PDSEs at the member level. 
>A system programmer must specify PDSESHARING(EXTENDED) in 
>the IGDSMSxx member in the SYS1.PARMLIB on each system in 
>the sysplex. Every system that is sharing a PDSE must be a 
>member of the sysplex and have the sysplex coupling facility 
>(XCF) active."
>
>We don't have the sysplex, so we're stuck with 
>PDSESHARING(NORMAL).
>This causes problems when one system has a PDSE open and 
>a second system opens it and tries to update it.  Take for 
>example the following scenario, which I just tested.
>

This has been discussed several times.  Please search the archives.  You can
not share a PDSE outside of a Sysplex.  If you are not in a Sysplex, you can
not share a PDSE with another system.  If you do so, you can expect the PDSE
to break.  You quoted the reference. "Every system that is sharing a PDSE
must be a member of the sysplex and have the sysplex coupling facility (XCF)
active."

-- 
Tom Marchant

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

Re: IEC143I 213-30

[Frank Swarbrick]

Thanks for clarifying.

On 12/4/2009 at 8:14 AM, in message
<20091204154243.c72fef58...@smtp.patriot.net>, "Shmuel Metz (Seymour J.)"
 wrote:
> In <4b17e85d.6f0f.008...@efirstbank.com>, on 12/03/2009
>at 04:33 PM, Frank Swarbrick  said:
> 
>>So you are saying that there is no point doing the two step process I
>>mention because it will have the file enqueued for the life of the job no
>>matter what, if DISP=OLD is specified?
> 
> Not quite; the Initiator will release it at the end of the last step that
> has a DD statement for it. So if you can arrange to do all of your work in
> a few short steps at the beginning, you can let other jobs use it after
> that.
>  

>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: IEC143I 213-30

[Frank Swarbrick]

I'm not the sysprog, so I may not have all of the details, but if I remember 
correctly these are the issues:

We have PDSESHARING(NORMAL) in our IGDSMSxx member, rather than 
PDSESHARING(EXTENDED).

>From 
>http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.idad400/pdsesh3.htm

"In a multiple-system environment, the system programmer uses 
PDSESHARING(EXTENDED) to share PDSEs at the member level. A system programmer 
must specify PDSESHARING(EXTENDED) in the IGDSMSxx member in the SYS1.PARMLIB 
on each system in the sysplex. Every system that is sharing a PDSE must be a 
member of the sysplex and have the sysplex coupling facility (XCF) active."

We don't have the sysplex, so we're stuck with PDSESHARING(NORMAL).
This causes problems when one system has a PDSE open and a second system opens 
it and tries to update it.  Take for example the following scenario, which I 
just tested.

On system 1 I open a PDSE with ISPF VIEW.
On system 2 I open the same PDSE with ISPF EDIT.
On system 2 I open a member in that PDSE and attempt to save it.  I get the 
following error:
IEC143I 213-70,IGG0191B,FJS,APPPROG,ISP11523,0469,TSO001,FJS.APPL.COBOL
This means "70 OPEN detected a cross-system share conflict for the PDSE. "

This issue does not occur when I do the same exact thing with a PDS.
Anyway, systems has given us the direction to not use PDSEs.  (Well, we can use 
them for our own personal datasets, but at our own risk.)

Frank
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


On 12/3/2009 at 9:50 PM, in message
<002101ca749d$5fda4cf0$e6f71...@foggybottom>, George Fogg 
wrote:
> I believe the OP mentioned GRS in shared dasd environment and having
> problems with PDSEs. I for one would like to know what the problems were.
> George Fogg 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
> Of Tony B.
> Sent: Thursday, December 03, 2009 6:09 PM
> To: IBM-MAIN@bama.ua.edu 
> Subject: Re: IEC143I 213-30
> 
> Sorry I lost track of most of the interim suggestions toward this thread.
> Did anyone suggest using a PDSE as the target library?  Years ago I cobbled
> together a poor man's scheduling system that used a single PDSE as a
> repository of members that each nightly batch job would add, as they
> completed with CC<5.  Hundreds of jobs updated this PDSE over the course of
> the evening, resulting in thousands of members having been written. .
> 
> Sorry if I've restated someone else's post.
> 
> 
> 
>   
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
> Of Frank Swarbrick
> Sent: Thursday, December 03, 2009 5:34 PM
> To: IBM-MAIN@bama.ua.edu 
> Subject: Re: IEC143I 213-30
> 
>>>> On 12/3/2009 at 6:39 AM, in message
> <20091203184630.1fe42f58...@smtp.patriot.net>, "Shmuel Metz (Seymour J.)"
>  wrote:
>> In <4b1662c2.6f0f.008...@efirstbank.com>, on 12/02/2009
>>at 12:51 PM, Frank Swarbrick  said:
>> 
>>>So perhaps a combination of the two is in order.  Write to a temporary 
>>>PDS during the translate and then use DISP=OLD on the copy from the 
>>>temp PDS in to the actual PDS.
>> 
>> The Initiator does the DISP=OLD ENQ at the beginning of the job. 
> 
> So you are saying that there is no point doing the two step process I
> mention because it will have the file enqueued for the life of the job no
> matter what, if DISP=OLD is specified?  Hmm, oh well.  Thanks for the info.

>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: IEC143I 213-30

[Shmuel Metz (Seymour J.)]

In <4b17e85d.6f0f.008...@efirstbank.com>, on 12/03/2009
   at 04:33 PM, Frank Swarbrick  said:

>So you are saying that there is no point doing the two step process I
>mention because it will have the file enqueued for the life of the job no
>matter what, if DISP=OLD is specified?

Not quite; the Initiator will release it at the end of the last step that
has a DD statement for it. So if you can arrange to do all of your work in
a few short steps at the beginning, you can let other jobs use it after
that.
 
-- 
 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC143I 213-30

[George Fogg]

I believe the OP mentioned GRS in shared dasd environment and having
problems with PDSEs. I for one would like to know what the problems were.
George Fogg 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Tony B.
Sent: Thursday, December 03, 2009 6:09 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEC143I 213-30

Sorry I lost track of most of the interim suggestions toward this thread.
Did anyone suggest using a PDSE as the target library?  Years ago I cobbled
together a poor man's scheduling system that used a single PDSE as a
repository of members that each nightly batch job would add, as they
completed with CC<5.  Hundreds of jobs updated this PDSE over the course of
the evening, resulting in thousands of members having been written. .

Sorry if I've restated someone else's post.



  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Frank Swarbrick
Sent: Thursday, December 03, 2009 5:34 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEC143I 213-30

>>> On 12/3/2009 at 6:39 AM, in message
<20091203184630.1fe42f58...@smtp.patriot.net>, "Shmuel Metz (Seymour J.)"
 wrote:
> In <4b1662c2.6f0f.008...@efirstbank.com>, on 12/02/2009
>at 12:51 PM, Frank Swarbrick  said:
> 
>>So perhaps a combination of the two is in order.  Write to a temporary 
>>PDS during the translate and then use DISP=OLD on the copy from the 
>>temp PDS in to the actual PDS.
> 
> The Initiator does the DISP=OLD ENQ at the beginning of the job. 

So you are saying that there is no point doing the two step process I
mention because it will have the file enqueued for the life of the job no
matter what, if DISP=OLD is specified?  Hmm, oh well.  Thanks for the info.
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development FirstBank Data
Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document
attached hereto or transmitted herewith is confidential and intended for the
exclusive use of the individual or entity named above.  If the reader of
this message is not the intended recipient or the employee or agent
responsible for delivering it to the intended recipient, you are hereby
notified that any examination, use, dissemination, distribution or copying
of this communication or any part thereof is strictly prohibited.  If you
have received this communication in error, please immediately notify the
sender by reply e-mail and destroy this communication.  Thank you.

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

___
No viruses found in this incoming message Scanned by iolo AntiVirus 1.5.8.3
http://www.iolo.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC143I 213-30

[Tony B.]

Sorry I lost track of most of the interim suggestions toward this thread.
Did anyone suggest using a PDSE as the target library?  Years ago I cobbled
together a poor man's scheduling system that used a single PDSE as a
repository of members that each nightly batch job would add, as they
completed with CC<5.  Hundreds of jobs updated this PDSE over the course of
the evening, resulting in thousands of members having been written. .

Sorry if I've restated someone else's post.



  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Frank Swarbrick
Sent: Thursday, December 03, 2009 5:34 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEC143I 213-30

>>> On 12/3/2009 at 6:39 AM, in message
<20091203184630.1fe42f58...@smtp.patriot.net>, "Shmuel Metz (Seymour J.)"
 wrote:
> In <4b1662c2.6f0f.008...@efirstbank.com>, on 12/02/2009
>at 12:51 PM, Frank Swarbrick  said:
> 
>>So perhaps a combination of the two is in order.  Write to a temporary 
>>PDS during the translate and then use DISP=OLD on the copy from the 
>>temp PDS in to the actual PDS.
> 
> The Initiator does the DISP=OLD ENQ at the beginning of the job. 

So you are saying that there is no point doing the two step process I
mention because it will have the file enqueued for the life of the job no
matter what, if DISP=OLD is specified?  Hmm, oh well.  Thanks for the info.
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development FirstBank Data
Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document
attached hereto or transmitted herewith is confidential and intended for the
exclusive use of the individual or entity named above.  If the reader of
this message is not the intended recipient or the employee or agent
responsible for delivering it to the intended recipient, you are hereby
notified that any examination, use, dissemination, distribution or copying
of this communication or any part thereof is strictly prohibited.  If you
have received this communication in error, please immediately notify the
sender by reply e-mail and destroy this communication.  Thank you.

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

___
No viruses found in this incoming message Scanned by iolo AntiVirus 1.5.8.3
http://www.iolo.com

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

Re: IEC143I 213-30

[Frank Swarbrick]

>>> On 12/3/2009 at 6:39 AM, in message
<20091203184630.1fe42f58...@smtp.patriot.net>, "Shmuel Metz (Seymour J.)"
 wrote:
> In <4b1662c2.6f0f.008...@efirstbank.com>, on 12/02/2009
>at 12:51 PM, Frank Swarbrick  said:
> 
>>So perhaps a combination of the two is in order.  Write to a temporary
>>PDS during the translate and then use DISP=OLD on the copy from the temp
>>PDS in to the actual PDS.
> 
> The Initiator does the DISP=OLD ENQ at the beginning of the job. 

So you are saying that there is no point doing the two step process I mention 
because it will have the file enqueued for the life of the job no matter what, 
if DISP=OLD is specified?  Hmm, oh well.  Thanks for the info.
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: IEC143I 213-30

[Shmuel Metz (Seymour J.)]

In <4b1662c2.6f0f.008...@efirstbank.com>, on 12/02/2009
   at 12:51 PM, Frank Swarbrick  said:

>So perhaps a combination of the two is in order.  Write to a temporary
>PDS during the translate and then use DISP=OLD on the copy from the temp
>PDS in to the actual PDS.

The Initiator does the DISP=OLD ENQ at the beginning of the job. 
 
-- 
 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC143I 213-30

[Robert A. Rosenberg]

At 15:33 -0600 on 12/02/2009, Paul Gilmartin wrote about Re: IEC143I 213-30:


It's even worse than you've learned so far.  If you use
static (JCL DD DISP=OLD) allocation, the exclusive ENQ
will be obtained at job initiation and persist through
the last step that mentions the data set, regardless
whether SHR or OLD.


This is because the ENQ support has no way of altering a owned 
EXCLUSIVE ENQ to a SHARED one (you can only [try to] change from 
SHARED to EXCLUSIVE). It would be easy to do since all that is needed 
is to put the share request at the top of the waiting queue and do 
the DEQ processing. The task now has a SHARED ENQ and all the tasks 
waiting for the Exclusive ENQ to get released would fire off. With 
that capability Job Initiation would be able to issue an early 
DISP=OLD DEQ in lieu of its current need to wait for the last step 
referencing the dataset.


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

Re: IEC143I 213-30

[Tony Harminc]

2009/12/2 Paul Gilmartin :

> BTW, I tried:
>
>    /bin/cp /some/file "//'DATA.SET.NAME(MEMBER)'"
>
> It gets an exclusive ENQ on SYSDSN 'DATA.SET.NAME'.  That's
> probably CRTL or LE behavior.

Um, isn't that just a side effect of the DYNALLOC it doubtless does
for the dataset? If you don't want that ENQ, you have to be APF
authorized, iirc.

> NFS server uses ISPF-style ENQ and generates ISPF-style
> timestamps in the directory (but wrong during leap years),
> but I don't believe it runs ISPF proper.

No authorization needed to ENQ on the ISPF name.

Tony H.

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

Re: IEC143I 213-30

[Frank Swarbrick]

>>> On 12/1/2009 at 2:46 PM, in message
<20091202171512.5d106f58...@smtp.patriot.net>, "Shmuel Metz (Seymour J.)"
 wrote:
> In <4b14fd2e.6f0f.008...@efirstbank.com>, on 12/01/2009
>at 11:25 AM, Frank Swarbrick  said:
> 
>>Obviously one solution is to single thread the compiles.  But I'd rather
>>not if I don't have to.  Any other solutions?  If I changed to DISP=OLD
>>would this eliminate the issue by making job 2 wait until job 1 is done
>>with the PDS?
> 
> Yes.
> 
>>Why does the link-edit step seem to not have a similar issue?
> 
> It does an exclusive RESERVE prior to the OPEN.

Thanks.
Would be nice if DB2 did this as well.  Oh well.

Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: IEC143I 213-30

[Paul Gilmartin]

On Wed, 2 Dec 2009 15:21:03 -0500, Don Leahy wrote:

>Does IEBCOPY use the same enqueue strategy as the Binder?
>
I believe IEBCOPY's strategy is, "It's your foot and your gun ..."
Use DISP=OLD if you care.

>On Wed, Dec 2, 2009 at 14:29, Joel C. Ewing wrote:
>> I believe the Binder uses ISPF-style enqueues to allow OPEN for output
>> with SHR access without any problems.  When needing updates with SHR and

Historically, I believe it would be more proper to say that
ISPF uses Linkage editor style ENQs.  Binder ENQs on SYSIEWLP.
ISPF, for RECFM=U ENQs on SYSIEWLP (and SPFEDIT?)  For other
RECFM only on SPFEDIT.

>> utilities that do not support ISPF-style enqueues, our approach has been
>> to change the job step to invoke a front-end program that gets the
>> required "SPFEDIT" enqueue, invokes the utility, and when the utility
>> returns control drop the enqueue.  That way the job may wait, but only
>> for the time when someone else actually has the dataset enqueued for
>> "open for output".
>>
How practical is it to use ISPF itself as the front-end program?
I'm trying to envision ATTACHing the utility from inside ISPF
and redirecting the output to LMPUT/LMCOPY.  But that's UNIX-think;
I can't see how to make it work in the z/OS environment without
a temporary data set.

BTW, I tried:

/bin/cp /some/file "//'DATA.SET.NAME(MEMBER)'"

It gets an exclusive ENQ on SYSDSN 'DATA.SET.NAME'.  That's
probably CRTL or LE behavior.

NFS server uses ISPF-style ENQ and generates ISPF-style
timestamps in the directory (but wrong during leap years),
but I don't believe it runs ISPF proper.

-- gil

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

Re: IEC143I 213-30

[Paul Gilmartin]

On Wed, 2 Dec 2009 12:51:15 -0700, Frank Swarbrick wrote:

>So perhaps a combination of the two is in order.  Write to a temporary PDS 
>during the translate and then use DISP=OLD on the copy from the temp PDS in to 
>the actual PDS.
>
>Yet another frustating issue in going to z/OS.  Oy.
>
It's even worse than you've learned so far.  If you use
static (JCL DD DISP=OLD) allocation, the exclusive ENQ
will be obtained at job initiation and persist through
the last step that mentions the data set, regardless
whether SHR or OLD.  If you attempt dynamic allocation
and the data set is in use, the allocation will fail
unless you ask to wait for DSN, which will fail unless
you're APF-authorized.

-- gil

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

Re: IEC143I 213-30

[Don Leahy]

Does IEBCOPY use the same enqueue strategy as the Binder?

On Wed, Dec 2, 2009 at 14:29, Joel C. Ewing  wrote:
> I believe the Binder uses ISPF-style enqueues to allow OPEN for output
> with SHR access without any problems.  When needing updates with SHR and
> utilities that do not support ISPF-style enqueues, our approach has been
> to change the job step to invoke a front-end program that gets the
> required "SPFEDIT" enqueue, invokes the utility, and when the utility
> returns control drop the enqueue.  That way the job may wait, but only
> for the time when someone else actually has the dataset enqueued for
> "open for output".
>   JC Ewing
>
> On 12/02/2009 09:42 AM, Don Leahy wrote:
>> Good point.  Our process is "working by coincidence".
>>
>> Time to took for a better approach.  Thanks.
>>
>> On Wed, Dec 2, 2009 at 05:23, Big Iron  wrote:
>>
>>> I think that using a later copy step "works" because the time window
>>> involved is shorter and so collisions, two programs having the same PDS
>>> open for output with DISP=SHR, would be less likely but could still occur.
>>> I
>>> have seen that abend happen for link-edit steps.
>>>
>>> Using DISP=OLD will solve this problem since the job would no longer
>>> be updating a dataset allocated with DISP=SHR. Note that the elapsed
>>> time for the jobs will increase because the allocation will be held from
>>> the start of the job until the end of the step that allocates the dataset
>>> with DISP=OLD.
>>>
>>> Bill
>>>
>>> On Tue, 1 Dec 2009 12:04:48 -0700, Frank Swarbrick
>>>  wrote:
>>>
>>>> A later step in the same job?  Does this solve the issue because the copy
>>> uses different serialization than the actual creating of the DBRM member?
>>>>
>>>> I'll give it a shot.  Thanks,
>>>> Frank
>>>> --
>>>>
>>>> Frank Swarbrick
>>>> Applications Architect - Mainframe Applications Development
>>>> FirstBank Data Corporation - Lakewood, CO  USA
>>>> P: 303-235-1403
>>>>
>>>>
>>>> On 12/1/2009 at 11:58 AM, in message
>>>> <6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com>, Don Leahy
>>>>  wrote:
>>>>> This is a perennial problem.
>>>>>
>>>>> Our local solution was to allocate DBRMLIB to a temporary data set.
>>>>>
>>>>> //DBRMLIB  DD  DSN=&DBRMLB(&MR),DISP=(,PASS),
>>>>> //             UNIT=SYSDA,SPACE=(TRK,(15,5,5)),
>>>>> //             DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160)
>>>>>
>>>>> A later step copies the DBRM to a permanent library.
>>>>>
>>>>> On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick
>>>>>  wrote:
>>>>>> For our conversion from VSE to z/OS we have a "mass compile" process
>>> that
>>>>> runs many compiles at the same time.  This has been fine up until when
>>> we
>>>>> added "DB2 compiles" in to the mix.  Now we are getting things like the
>>>>> following for every second or third compile:
>>>>>> 11.02.22 JOB05118  IEC143I
>>>>>
>>> 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM
>>>>> 02)
>>>>>>
>>>>>> "30
>>>>>> An attempt was made to open a partitioned data set (PDS) for
>>>>> OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is
>>>>> already open for output to the data set. The data set might be on the
>>> same
>>>>> system or on another system that is sharing the volume. Access was not
>>>>> serialized before the attempt to open the data set."
>>>>>>
>>>>>> I am guessing that "job 2" is trying to add a member to
>>>>> SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do
>>> the
>>>>> same thing (though a different member).
>>>>>>
>>>>>> Obviously one solution is to single thread the compiles.  But I'd
>>> rather not
>>>>> if I don't have to.  Any other solutions?  If I changed to DISP=OLD
>>> would
>>>>> this eliminate the issue by making job 2 wait until job 1 is done with
>>> the
>>>>> PDS?
>>>>>>
>>>>>> Why does the link-edit step seem to not have a similar issue?  Is it
>>> just
>>>>> that the link-edit step completes so quickly that only one job has the
>>> PDS
>>>>> open at one time?  Or does the link-edit (binder; whatever) have some
>>> special
>>>>> stuff that allows it do deal with this situation?
>>>>>>
>>>>>> Thanks,
>>>>>> Frank
>>>>>> --
>>>>>>
>>>>>> Frank Swarbrick
>>>>>> Applications Architect - Mainframe Applications Development
>>>>>> FirstBank Data Corporation - Lakewood, CO  USA
>>>>>> P: 303-235-1403
>>
> --
> Joel C. Ewing, Fort Smith, AR        jremoveccapsew...@acm.org
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC143I 213-30

[Frank Swarbrick]

So perhaps a combination of the two is in order.  Write to a temporary PDS 
during the translate and then use DISP=OLD on the copy from the temp PDS in to 
the actual PDS.

Yet another frustating issue in going to z/OS.  Oy.

Thanks for the ideas.
Frank

On 12/2/2009 at 3:23 AM, in message
, Big Iron
 wrote:
> I think that using a later copy step "works" because the time window
> involved is shorter and so collisions, two programs having the same PDS
> open for output with DISP=SHR, would be less likely but could still occur. I
> have seen that abend happen for link-edit steps.
> 
> Using DISP=OLD will solve this problem since the job would no longer
> be updating a dataset allocated with DISP=SHR. Note that the elapsed
> time for the jobs will increase because the allocation will be held from
> the start of the job until the end of the step that allocates the dataset
> with DISP=OLD.
> 
> Bill
> 
> On Tue, 1 Dec 2009 12:04:48 -0700, Frank Swarbrick
>  wrote:
> 
>>A later step in the same job?  Does this solve the issue because the copy
> uses different serialization than the actual creating of the DBRM member?
>>
>>I'll give it a shot.  Thanks,
>>Frank
>>--
>>
>>Frank Swarbrick
>>Applications Architect - Mainframe Applications Development
>>FirstBank Data Corporation - Lakewood, CO  USA
>>P: 303-235-1403
>>
>>
>>On 12/1/2009 at 11:58 AM, in message
>><6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com>, Don Leahy
>> wrote:
>>> This is a perennial problem.
>>>
>>> Our local solution was to allocate DBRMLIB to a temporary data set.
>>>
>>> //DBRMLIB  DD  DSN=&DBRMLB(&MR),DISP=(,PASS),
>>> // UNIT=SYSDA,SPACE=(TRK,(15,5,5)),
>>> // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160)
>>>
>>> A later step copies the DBRM to a permanent library.
>>>
>>> On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick
>>>  wrote:
>>>> For our conversion from VSE to z/OS we have a "mass compile" process that
>>> runs many compiles at the same time.  This has been fine up until when we
>>> added "DB2 compiles" in to the mix.  Now we are getting things like the
>>> following for every second or third compile:
>>>> 11.02.22 JOB05118  IEC143I
>>> 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM
>>> 02)
>>>>
>>>> "30
>>>> An attempt was made to open a partitioned data set (PDS) for
>>> OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is
>>> already open for output to the data set. The data set might be on the same
>>> system or on another system that is sharing the volume. Access was not
>>> serialized before the attempt to open the data set."
>>>>
>>>> I am guessing that "job 2" is trying to add a member to
>>> SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do the
>>> same thing (though a different member).
>>>>
>>>> Obviously one solution is to single thread the compiles.  But I'd rather 
>>>> not
>>> if I don't have to.  Any other solutions?  If I changed to DISP=OLD would
>>> this eliminate the issue by making job 2 wait until job 1 is done with the
>>> PDS?
>>>>
>>>> Why does the link-edit step seem to not have a similar issue?  Is it just
>>> that the link-edit step completes so quickly that only one job has the PDS
>>> open at one time?  Or does the link-edit (binder; whatever) have some 
>>> special
>>> stuff that allows it do deal with this situation?
>>>>
>>>> Thanks,
>>>>
>>>> Frank
>>>>
>>>>
>>>> --
>>>>
>>>> Frank Swarbrick
>>>> Applications Architect - Mainframe Applications Development
>>>> FirstBank Data Corporation - Lakewood, CO  USA
>>>> P: 303-235-1403
>>>>
>>>>
>>>>>>>
>>>>
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: IEC143I 213-30

[Joel C. Ewing]

I believe the Binder uses ISPF-style enqueues to allow OPEN for output
with SHR access without any problems.  When needing updates with SHR and
utilities that do not support ISPF-style enqueues, our approach has been
to change the job step to invoke a front-end program that gets the
required "SPFEDIT" enqueue, invokes the utility, and when the utility
returns control drop the enqueue.  That way the job may wait, but only
for the time when someone else actually has the dataset enqueued for
"open for output".
   JC Ewing

On 12/02/2009 09:42 AM, Don Leahy wrote:
> Good point.  Our process is "working by coincidence".
> 
> Time to took for a better approach.  Thanks.
> 
> On Wed, Dec 2, 2009 at 05:23, Big Iron  wrote:
> 
>> I think that using a later copy step "works" because the time window
>> involved is shorter and so collisions, two programs having the same PDS
>> open for output with DISP=SHR, would be less likely but could still occur.
>> I
>> have seen that abend happen for link-edit steps.
>>
>> Using DISP=OLD will solve this problem since the job would no longer
>> be updating a dataset allocated with DISP=SHR. Note that the elapsed
>> time for the jobs will increase because the allocation will be held from
>> the start of the job until the end of the step that allocates the dataset
>> with DISP=OLD.
>>
>> Bill
>>
>> On Tue, 1 Dec 2009 12:04:48 -0700, Frank Swarbrick
>>  wrote:
>>
>>> A later step in the same job?  Does this solve the issue because the copy
>> uses different serialization than the actual creating of the DBRM member?
>>>
>>> I'll give it a shot.  Thanks,
>>> Frank
>>> --
>>>
>>> Frank Swarbrick
>>> Applications Architect - Mainframe Applications Development
>>> FirstBank Data Corporation - Lakewood, CO  USA
>>> P: 303-235-1403
>>>
>>>
>>> On 12/1/2009 at 11:58 AM, in message
>>> <6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com>, Don Leahy
>>>  wrote:
>>>> This is a perennial problem.
>>>>
>>>> Our local solution was to allocate DBRMLIB to a temporary data set.
>>>>
>>>> //DBRMLIB  DD  DSN=&DBRMLB(&MR),DISP=(,PASS),
>>>> // UNIT=SYSDA,SPACE=(TRK,(15,5,5)),
>>>> // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160)
>>>>
>>>> A later step copies the DBRM to a permanent library.
>>>>
>>>> On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick
>>>>  wrote:
>>>>> For our conversion from VSE to z/OS we have a "mass compile" process
>> that
>>>> runs many compiles at the same time.  This has been fine up until when
>> we
>>>> added "DB2 compiles" in to the mix.  Now we are getting things like the
>>>> following for every second or third compile:
>>>>> 11.02.22 JOB05118  IEC143I
>>>>
>> 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM
>>>> 02)
>>>>>
>>>>> "30
>>>>> An attempt was made to open a partitioned data set (PDS) for
>>>> OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is
>>>> already open for output to the data set. The data set might be on the
>> same
>>>> system or on another system that is sharing the volume. Access was not
>>>> serialized before the attempt to open the data set."
>>>>>
>>>>> I am guessing that "job 2" is trying to add a member to
>>>> SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do
>> the
>>>> same thing (though a different member).
>>>>>
>>>>> Obviously one solution is to single thread the compiles.  But I'd
>> rather not
>>>> if I don't have to.  Any other solutions?  If I changed to DISP=OLD
>> would
>>>> this eliminate the issue by making job 2 wait until job 1 is done with
>> the
>>>> PDS?
>>>>>
>>>>> Why does the link-edit step seem to not have a similar issue?  Is it
>> just
>>>> that the link-edit step completes so quickly that only one job has the
>> PDS
>>>> open at one time?  Or does the link-edit (binder; whatever) have some
>> special
>>>> stuff that allows it do deal with this situation?
>>>>>
>>>>> Thanks,
>>>>> Frank
>>>>> --
>>>>>
>>>>> Frank Swarbrick
>>>>> Applications Architect - Mainframe Applications Development
>>>>> FirstBank Data Corporation - Lakewood, CO  USA
>>>>> P: 303-235-1403
>
-- 
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org

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

Re: IEC143I 213-30

[Shmuel Metz (Seymour J.)]

In <4b14fd2e.6f0f.008...@efirstbank.com>, on 12/01/2009
   at 11:25 AM, Frank Swarbrick  said:

>Obviously one solution is to single thread the compiles.  But I'd rather
>not if I don't have to.  Any other solutions?  If I changed to DISP=OLD
>would this eliminate the issue by making job 2 wait until job 1 is done
>with the PDS?

Yes.

>Why does the link-edit step seem to not have a similar issue?

It does an exclusive RESERVE prior to the OPEN.
 
-- 
 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC143I 213-30

[Don Leahy]

Good point.  Our process is "working by coincidence".

Time to took for a better approach.  Thanks.

On Wed, Dec 2, 2009 at 05:23, Big Iron  wrote:

> I think that using a later copy step "works" because the time window
> involved is shorter and so collisions, two programs having the same PDS
> open for output with DISP=SHR, would be less likely but could still occur.
> I
> have seen that abend happen for link-edit steps.
>
> Using DISP=OLD will solve this problem since the job would no longer
> be updating a dataset allocated with DISP=SHR. Note that the elapsed
> time for the jobs will increase because the allocation will be held from
> the start of the job until the end of the step that allocates the dataset
> with DISP=OLD.
>
> Bill
>
> On Tue, 1 Dec 2009 12:04:48 -0700, Frank Swarbrick
>  wrote:
>
> >A later step in the same job?  Does this solve the issue because the copy
> uses different serialization than the actual creating of the DBRM member?
> >
> >I'll give it a shot.  Thanks,
> >Frank
> >--
> >
> >Frank Swarbrick
> >Applications Architect - Mainframe Applications Development
> >FirstBank Data Corporation - Lakewood, CO  USA
> >P: 303-235-1403
> >
> >
> >On 12/1/2009 at 11:58 AM, in message
> ><6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com>, Don Leahy
> > wrote:
> >> This is a perennial problem.
> >>
> >> Our local solution was to allocate DBRMLIB to a temporary data set.
> >>
> >> //DBRMLIB  DD  DSN=&DBRMLB(&MR),DISP=(,PASS),
> >> // UNIT=SYSDA,SPACE=(TRK,(15,5,5)),
> >> // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160)
> >>
> >> A later step copies the DBRM to a permanent library.
> >>
> >> On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick
> >>  wrote:
> >>> For our conversion from VSE to z/OS we have a "mass compile" process
> that
> >> runs many compiles at the same time.  This has been fine up until when
> we
> >> added "DB2 compiles" in to the mix.  Now we are getting things like the
> >> following for every second or third compile:
> >>> 11.02.22 JOB05118  IEC143I
> >>
> 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM
> >> 02)
> >>>
> >>> "30
> >>> An attempt was made to open a partitioned data set (PDS) for
> >> OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is
> >> already open for output to the data set. The data set might be on the
> same
> >> system or on another system that is sharing the volume. Access was not
> >> serialized before the attempt to open the data set."
> >>>
> >>> I am guessing that "job 2" is trying to add a member to
> >> SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do
> the
> >> same thing (though a different member).
> >>>
> >>> Obviously one solution is to single thread the compiles.  But I'd
> rather not
> >> if I don't have to.  Any other solutions?  If I changed to DISP=OLD
> would
> >> this eliminate the issue by making job 2 wait until job 1 is done with
> the
> >> PDS?
> >>>
> >>> Why does the link-edit step seem to not have a similar issue?  Is it
> just
> >> that the link-edit step completes so quickly that only one job has the
> PDS
> >> open at one time?  Or does the link-edit (binder; whatever) have some
> special
> >> stuff that allows it do deal with this situation?
> >>>
> >>> Thanks,
> >>>
> >>> Frank
> >>>
> >>>
> >>> --
> >>>
> >>> Frank Swarbrick
> >>> Applications Architect - Mainframe Applications Development
> >>> FirstBank Data Corporation - Lakewood, CO  USA
> >>> P: 303-235-1403
> >>>
> >>>
> >>>>>>
> >>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC143I 213-30

[Big Iron]

I think that using a later copy step "works" because the time window
involved is shorter and so collisions, two programs having the same PDS
open for output with DISP=SHR, would be less likely but could still occur. I
have seen that abend happen for link-edit steps.

Using DISP=OLD will solve this problem since the job would no longer
be updating a dataset allocated with DISP=SHR. Note that the elapsed
time for the jobs will increase because the allocation will be held from
the start of the job until the end of the step that allocates the dataset
with DISP=OLD.

Bill

On Tue, 1 Dec 2009 12:04:48 -0700, Frank Swarbrick
 wrote:

>A later step in the same job?  Does this solve the issue because the copy
uses different serialization than the actual creating of the DBRM member?
>
>I'll give it a shot.  Thanks,
>Frank
>--
>
>Frank Swarbrick
>Applications Architect - Mainframe Applications Development
>FirstBank Data Corporation - Lakewood, CO  USA
>P: 303-235-1403
>
>
>On 12/1/2009 at 11:58 AM, in message
><6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com>, Don Leahy
> wrote:
>> This is a perennial problem.
>>
>> Our local solution was to allocate DBRMLIB to a temporary data set.
>>
>> //DBRMLIB  DD  DSN=&DBRMLB(&MR),DISP=(,PASS),
>> // UNIT=SYSDA,SPACE=(TRK,(15,5,5)),
>> // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160)
>>
>> A later step copies the DBRM to a permanent library.
>>
>> On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick
>>  wrote:
>>> For our conversion from VSE to z/OS we have a "mass compile" process that
>> runs many compiles at the same time.  This has been fine up until when we
>> added "DB2 compiles" in to the mix.  Now we are getting things like the
>> following for every second or third compile:
>>> 11.02.22 JOB05118  IEC143I
>> 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM
>> 02)
>>>
>>> "30
>>> An attempt was made to open a partitioned data set (PDS) for
>> OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is
>> already open for output to the data set. The data set might be on the same
>> system or on another system that is sharing the volume. Access was not
>> serialized before the attempt to open the data set."
>>>
>>> I am guessing that "job 2" is trying to add a member to
>> SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do the
>> same thing (though a different member).
>>>
>>> Obviously one solution is to single thread the compiles.  But I'd rather not
>> if I don't have to.  Any other solutions?  If I changed to DISP=OLD would
>> this eliminate the issue by making job 2 wait until job 1 is done with the
>> PDS?
>>>
>>> Why does the link-edit step seem to not have a similar issue?  Is it just
>> that the link-edit step completes so quickly that only one job has the PDS
>> open at one time?  Or does the link-edit (binder; whatever) have some special
>> stuff that allows it do deal with this situation?
>>>
>>> Thanks,
>>>
>>> Frank
>>>
>>>
>>> --
>>>
>>> Frank Swarbrick
>>> Applications Architect - Mainframe Applications Development
>>> FirstBank Data Corporation - Lakewood, CO  USA
>>> P: 303-235-1403
>>>
>>>
>>>>>>
>>>

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

Re: IEC143I 213-30

[Paul Gilmartin]

On Tue, 1 Dec 2009 14:46:09 -0500, Don Leahy wrote:

>I am not sure why it works, we did not do any extensive testing but I
>do know that we haven't had any problems for a long time.  We use
>ICEGENER to do the copying.
>
>Caveat: we rarely have more than 2 compiles running at the same time
>(small shop), so your mileage may vary.
>
Sounds risky to me.  A safe technique I use is LMCOPY (but ICEGENER
may be smart enough to use the same ENQ as ISPF).

Or, allocate DRMLIB to a Unix directory.

>On Tue, Dec 1, 2009 at 14:04, Frank Swarbrick wrote:
>> A later step in the same job?  Does this solve the issue because the copy 
>> uses different serialization than the actual creating of the DBRM member?
>>
>> On 12/1/2009 at 11:58 AM, in message
>> <6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com>, Don Leahy
>> wrote:
>>> This is a perennial problem.
>>>
>>> Our local solution was to allocate DBRMLIB to a temporary data set.
>>>
>>> //DBRMLIB  DD  DSN=&DBRMLB(&MR),DISP=(,PASS),
>>> //             UNIT=SYSDA,SPACE=(TRK,(15,5,5)),
>>> //             DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160)
>>>
>>> A later step copies the DBRM to a permanent library.

-- gil

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

Re: IEC143I 213-30

[Don Leahy]

I am not sure why it works, we did not do any extensive testing but I
do know that we haven't had any problems for a long time.  We use
ICEGENER to do the copying.

Caveat: we rarely have more than 2 compiles running at the same time
(small shop), so your mileage may vary.

On Tue, Dec 1, 2009 at 14:04, Frank Swarbrick
 wrote:
> A later step in the same job?  Does this solve the issue because the copy 
> uses different serialization than the actual creating of the DBRM member?
>
> I'll give it a shot.  Thanks,
> Frank
> --
>
> Frank Swarbrick
> Applications Architect - Mainframe Applications Development
> FirstBank Data Corporation - Lakewood, CO  USA
> P: 303-235-1403
>
>
> On 12/1/2009 at 11:58 AM, in message
> <6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com>, Don Leahy
>  wrote:
>> This is a perennial problem.
>>
>> Our local solution was to allocate DBRMLIB to a temporary data set.
>>
>> //DBRMLIB  DD  DSN=&DBRMLB(&MR),DISP=(,PASS),
>> //             UNIT=SYSDA,SPACE=(TRK,(15,5,5)),
>> //             DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160)
>>
>> A later step copies the DBRM to a permanent library.
>>
>> On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick
>>  wrote:
>>> For our conversion from VSE to z/OS we have a "mass compile" process that
>> runs many compiles at the same time.  This has been fine up until when we
>> added "DB2 compiles" in to the mix.  Now we are getting things like the
>> following for every second or third compile:
>>> 11.02.22 JOB05118  IEC143I
>> 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM
>> 02)
>>>
>>> "30
>>> An attempt was made to open a partitioned data set (PDS) for
>> OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is
>> already open for output to the data set. The data set might be on the same
>> system or on another system that is sharing the volume. Access was not
>> serialized before the attempt to open the data set."
>>>
>>> I am guessing that "job 2" is trying to add a member to
>> SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do the
>> same thing (though a different member).
>>>
>>> Obviously one solution is to single thread the compiles.  But I'd rather not
>> if I don't have to.  Any other solutions?  If I changed to DISP=OLD would
>> this eliminate the issue by making job 2 wait until job 1 is done with the
>> PDS?
>>>
>>> Why does the link-edit step seem to not have a similar issue?  Is it just
>> that the link-edit step completes so quickly that only one job has the PDS
>> open at one time?  Or does the link-edit (binder; whatever) have some special
>> stuff that allows it do deal with this situation?
>>>
>>> Thanks,
>>>
>>> Frank
>>>
>>>
>>> --
>>>
>>> Frank Swarbrick
>>> Applications Architect - Mainframe Applications Development
>>> FirstBank Data Corporation - Lakewood, CO  USA
>>> P: 303-235-1403
>>>
>>>
>>>>>>
>>>
>>> The information contained in this electronic communication and any document
>> attached hereto or transmitted herewith is confidential and intended for the
>> exclusive use of the individual or entity named above.  If the reader of this
>> message is not the intended recipient or the employee or agent responsible
>> for delivering it to the intended recipient, you are hereby notified that any
>> examination, use, dissemination, distribution or copying of this
>> communication or any part thereof is strictly prohibited.  If you have
>> received this communication in error, please immediately notify the sender by
>> reply e-mail and destroy this communication.  Thank you.
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>>>>
>
> The information contained in this electronic communication and any document 
> attached hereto 

Re: IEC143I 213-30

[Frank Swarbrick]

A later step in the same job?  Does this solve the issue because the copy uses 
different serialization than the actual creating of the DBRM member?

I'll give it a shot.  Thanks,
Frank
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


On 12/1/2009 at 11:58 AM, in message
<6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com>, Don Leahy
 wrote:
> This is a perennial problem.
> 
> Our local solution was to allocate DBRMLIB to a temporary data set.
> 
> //DBRMLIB  DD  DSN=&DBRMLB(&MR),DISP=(,PASS),
> // UNIT=SYSDA,SPACE=(TRK,(15,5,5)),
> // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160)
> 
> A later step copies the DBRM to a permanent library.
> 
> On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick
>  wrote:
>> For our conversion from VSE to z/OS we have a "mass compile" process that 
> runs many compiles at the same time.  This has been fine up until when we 
> added "DB2 compiles" in to the mix.  Now we are getting things like the 
> following for every second or third compile:
>> 11.02.22 JOB05118  IEC143I 
> 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM
> 02)
>>
>> "30
>> An attempt was made to open a partitioned data set (PDS) for 
> OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is 
> already open for output to the data set. The data set might be on the same 
> system or on another system that is sharing the volume. Access was not 
> serialized before the attempt to open the data set."
>>
>> I am guessing that "job 2" is trying to add a member to 
> SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do the 
> same thing (though a different member).
>>
>> Obviously one solution is to single thread the compiles.  But I'd rather not 
> if I don't have to.  Any other solutions?  If I changed to DISP=OLD would 
> this eliminate the issue by making job 2 wait until job 1 is done with the 
> PDS?
>>
>> Why does the link-edit step seem to not have a similar issue?  Is it just 
> that the link-edit step completes so quickly that only one job has the PDS 
> open at one time?  Or does the link-edit (binder; whatever) have some special 
> stuff that allows it do deal with this situation?
>>
>> Thanks,
>>
>> Frank
>>
>>
>> --
>>
>> Frank Swarbrick
>> Applications Architect - Mainframe Applications Development
>> FirstBank Data Corporation - Lakewood, CO  USA
>> P: 303-235-1403
>>
>>
>>>>>
>>
>> The information contained in this electronic communication and any document 
> attached hereto or transmitted herewith is confidential and intended for the 
> exclusive use of the individual or entity named above.  If the reader of this 
> message is not the intended recipient or the employee or agent responsible 
> for delivering it to the intended recipient, you are hereby notified that any 
> examination, use, dissemination, distribution or copying of this 
> communication or any part thereof is strictly prohibited.  If you have 
> received this communication in error, please immediately notify the sender by 
> reply e-mail and destroy this communication.  Thank you.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: IEC143I 213-30

[Frank Swarbrick]

Wouldn't that be nice...
We aren't in a Sysplex, but we do use GRS for shared DASD, so PDSEs are a no 
go.  (We've tried.  Too many problems.)
Thanks,
Frank
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


On 12/1/2009 at 11:27 AM, in message
,
"Jousma, David"  wrote:
> Make your DBRM lib PDS-E, and that problem goes away.  Linkedit issues a
> GRS enqueue SYSIEWLP to serialize the updates.
> 
> _
> Dave Jousma
> Assistant Vice President, Mainframe Services
> david.jou...@53.com 
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB1G
> p 616.653.8429
> f 616.653.8497
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Frank Swarbrick
> Sent: Tuesday, December 01, 2009 1:26 PM
> To: IBM-MAIN@bama.ua.edu 
> Subject: IEC143I 213-30
> 
> For our conversion from VSE to z/OS we have a "mass compile" process
> that runs many compiles at the same time.  This has been fine up until
> when we added "DB2 compiles" in to the mix.  Now we are getting things
> like the following for every second or third compile:
> 11.02.22 JOB05118  IEC143I
> 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(
> EXAM02)
> 
> "30 
> An attempt was made to open a partitioned data set (PDS) for
> OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is
> already open for output to the data set. The data set might be on the
> same system or on another system that is sharing the volume. Access was
> not serialized before the attempt to open the data set."
> 
> I am guessing that "job 2" is trying to add a member to
> SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do
> the same thing (though a different member).
> 
> Obviously one solution is to single thread the compiles.  But I'd rather
> not if I don't have to.  Any other solutions?  If I changed to DISP=OLD
> would this eliminate the issue by making job 2 wait until job 1 is done
> with the PDS?
> 
> Why does the link-edit step seem to not have a similar issue?  Is it
> just that the link-edit step completes so quickly that only one job has
> the PDS open at one time?  Or does the link-edit (binder; whatever) have
> some special stuff that allows it do deal with this situation?
> 
> Thanks,
> 
> Frank
> 

>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: IEC143I 213-30

[Don Leahy]

This is a perennial problem.

Our local solution was to allocate DBRMLIB to a temporary data set.

//DBRMLIB  DD  DSN=&DBRMLB(&MR),DISP=(,PASS),
// UNIT=SYSDA,SPACE=(TRK,(15,5,5)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160)

A later step copies the DBRM to a permanent library.

On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick
 wrote:
> For our conversion from VSE to z/OS we have a "mass compile" process that 
> runs many compiles at the same time.  This has been fine up until when we 
> added "DB2 compiles" in to the mix.  Now we are getting things like the 
> following for every second or third compile:
> 11.02.22 JOB05118  IEC143I 
> 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM02)
>
> "30
> An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. 
> The PDS is already open in this condition, and a DCB is already open for 
> output to the data set. The data set might be on the same system or on 
> another system that is sharing the volume. Access was not serialized before 
> the attempt to open the data set."
>
> I am guessing that "job 2" is trying to add a member to 
> SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do the 
> same thing (though a different member).
>
> Obviously one solution is to single thread the compiles.  But I'd rather not 
> if I don't have to.  Any other solutions?  If I changed to DISP=OLD would 
> this eliminate the issue by making job 2 wait until job 1 is done with the 
> PDS?
>
> Why does the link-edit step seem to not have a similar issue?  Is it just 
> that the link-edit step completes so quickly that only one job has the PDS 
> open at one time?  Or does the link-edit (binder; whatever) have some special 
> stuff that allows it do deal with this situation?
>
> Thanks,
>
> Frank
>
>
> --
>
> Frank Swarbrick
> Applications Architect - Mainframe Applications Development
> FirstBank Data Corporation - Lakewood, CO  USA
> P: 303-235-1403
>
>
>>>>
>
> The information contained in this electronic communication and any document 
> attached hereto or transmitted herewith is confidential and intended for the 
> exclusive use of the individual or entity named above.  If the reader of this 
> message is not the intended recipient or the employee or agent responsible 
> for delivering it to the intended recipient, you are hereby notified that any 
> examination, use, dissemination, distribution or copying of this 
> communication or any part thereof is strictly prohibited.  If you have 
> received this communication in error, please immediately notify the sender by 
> reply e-mail and destroy this communication.  Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEC143I 213-30

[Jousma, David]

Make your DBRM lib PDS-E, and that problem goes away.  Linkedit issues a
GRS enqueue SYSIEWLP to serialize the updates.

_
Dave Jousma
Assistant Vice President, Mainframe Services
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB1G
p 616.653.8429
f 616.653.8497


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Frank Swarbrick
Sent: Tuesday, December 01, 2009 1:26 PM
To: IBM-MAIN@bama.ua.edu
Subject: IEC143I 213-30

For our conversion from VSE to z/OS we have a "mass compile" process
that runs many compiles at the same time.  This has been fine up until
when we added "DB2 compiles" in to the mix.  Now we are getting things
like the following for every second or third compile:
11.02.22 JOB05118  IEC143I
213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(
EXAM02)

"30 
An attempt was made to open a partitioned data set (PDS) for
OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is
already open for output to the data set. The data set might be on the
same system or on another system that is sharing the volume. Access was
not serialized before the attempt to open the data set."

I am guessing that "job 2" is trying to add a member to
SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do
the same thing (though a different member).

Obviously one solution is to single thread the compiles.  But I'd rather
not if I don't have to.  Any other solutions?  If I changed to DISP=OLD
would this eliminate the issue by making job 2 wait until job 1 is done
with the PDS?

Why does the link-edit step seem to not have a similar issue?  Is it
just that the link-edit step completes so quickly that only one job has
the PDS open at one time?  Or does the link-edit (binder; whatever) have
some special stuff that allows it do deal with this situation?

Thanks,

Frank


-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


>>> 

The information contained in this electronic communication and any
document attached hereto or transmitted herewith is confidential and
intended for the exclusive use of the individual or entity named above.
If the reader of this message is not the intended recipient or the
employee or agent responsible for delivering it to the intended
recipient, you are hereby notified that any examination, use,
dissemination, distribution or copying of this communication or any part
thereof is strictly prohibited.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and
destroy this communication.  Thank you.

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

IEC143I 213-30

[Frank Swarbrick]

For our conversion from VSE to z/OS we have a "mass compile" process that runs 
many compiles at the same time.  This has been fine up until when we added "DB2 
compiles" in to the mix.  Now we are getting things like the following for 
every second or third compile:
11.02.22 JOB05118  IEC143I 
213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM02)

"30 
An attempt was made to open a partitioned data set (PDS) for OUTPUT,DISP=SHR. 
The PDS is already open in this condition, and a DCB is already open for output 
to the data set. The data set might be on the same system or on another system 
that is sharing the volume. Access was not serialized before the attempt to 
open the data set."

I am guessing that "job 2" is trying to add a member to 
SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do the same 
thing (though a different member).

Obviously one solution is to single thread the compiles.  But I'd rather not if 
I don't have to.  Any other solutions?  If I changed to DISP=OLD would this 
eliminate the issue by making job 2 wait until job 1 is done with the PDS?

Why does the link-edit step seem to not have a similar issue?  Is it just that 
the link-edit step completes so quickly that only one job has the PDS open at 
one time?  Or does the link-edit (binder; whatever) have some special stuff 
that allows it do deal with this situation?

Thanks,

Frank


-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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