Re: PDS Member updating via COBOL Program

[S B]

 Andy 

Be aware of thePDSE solution – if your shop is like mine – Shared DASD between 
two LPARs andnot SYSPlex – PDSE will be your nightmare as it is mine currently 
and it willbe even more when  Enterprise COBOL V4.2goes out of support on 
09/30/2021. Going SYSPlex in our setup is doable but willtake some times – “the 
time we do not have” – good luck 
 Shahnaz 

On Tuesday, October 8, 2019, 06:51:31 PM EDT, Pesce, Andy 
 wrote:  
 
 I am looking for an explanation and this may be one of those "unpredictable 
results" may occur.

I have "JOBA" that executes a COBOL program to update a particular member in a 
PDS.  Within the program, it calls an internal utility that someone
wrote years ago that puts an enqueue on the dataset and its member that it is 
updating.  The dd associated with the parmlib uses DISP=SHR.

I have "JOBB" that executes a COBOL program to do the same thing, but it is a 
different member within the same dataset as "JOBA".    It is coded
to open the dataset as I/O.  After it reads the member, it then does a REWRITE. 
   It doesn't follow the rules as above and use the internal utility.
The dd associated with the parmlib also uses DISP=SHR.

Here is the issue.  Occasionally the member in "JOBA" is becoming "empty", 
while the member in JOBB is always OK.    I have looked at SMF
records and I see these jobs run at the same time.  And it is usually the same 
down to the hundreds of seconds.

My suggestion was that JOBB needs to be fixed to use the "enqueue and dequeue" 
utility, since it is using DISP-SHR.  This parmlib is
used heavily and extensively by applications, and no way to get it DISP=OLD.  
Any thoughts or explanation would truly be appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PDS Member updating via COBOL Program

[Seymour J Metz]

Unless all jobs updating the PDS with DISP=SHR use the same serialization 
protocol, you are going to periodically lose data. I concur with the suggestion 
to use the ISPF convention.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Pesce, Andy 
Sent: Tuesday, October 8, 2019 12:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PDS Member updating via COBOL Program

I am looking for an explanation and this may be one of those "unpredictable 
results" may occur.

I have "JOBA" that executes a COBOL program to update a particular member in a 
PDS.   Within the program, it calls an internal utility that someone
wrote years ago that puts an enqueue on the dataset and its member that it is 
updating.  The dd associated with the parmlib uses DISP=SHR.

I have "JOBB" that executes a COBOL program to do the same thing, but it is a 
different member within the same dataset as "JOBA".It is coded
to open the dataset as I/O.  After it reads the member, it then does a REWRITE. 
   It doesn't follow the rules as above and use the internal utility.
The dd associated with the parmlib also uses DISP=SHR.

Here is the issue.   Occasionally the member in "JOBA" is becoming "empty", 
while the member in JOBB is always OK.I have looked at SMF
records and I see these jobs run at the same time.  And it is usually the same 
down to the hundreds of seconds.

My suggestion was that JOBB needs to be fixed to use the "enqueue and dequeue" 
utility, since it is using DISP-SHR.   This parmlib is
used heavily and extensively by applications, and no way to get it DISP=OLD.  
Any thoughts or explanation would truly be appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PDS Member updating via COBOL Program

[Gibney, Dave]

And a potential solution is just as old. Allocate a zero space "dummy" dataset. 
Pdsname.ENQUEUE. Add a DISP=OLD DD against this to the jobs. This only works it 
the updating job/step is fairly fast, but it will prevent simultaneous 
accesses. 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Don Poitras
> Sent: Tuesday, October 08, 2019 10:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS Member updating via COBOL Program
> 
> In article <2000189509316059.wa.paulgboulderaim@listserv.ua.edu>
> you wrote:
> > On Tue, 8 Oct 2019 16:28:30 +, Jesse 1 Robinson wrote:
> > >This is a classic problem endemic to traditional PDS since the dawn of
> MVS. IBM's solution to this problem is PDSE. If you convert the data set to
> Library (PDSE) you may reduce problem occurrence to negligible. OTOH PDSE
> may introduce its own set of problems, chief of which is the inability to 
> share
> the data set across sysplex boundaries. If that restriction is unacceptable, 
> you
> might try adding in your RYO enqueue program as you suggest. Be aware,
> however, that DISP=SHR is unlikely to provide much if any protection against
> concurrent update.
> > >
> > I have used ISPF LM services for this purpose.  But that requires a
> > TSO environment.  Otherwise, you may simulate the ISPF technique, as in:
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ibm.com_suppo
> > rt_knowledgecenter_en_SSLTBW-
> 5F2.4.0_com.ibm.zos.v2r4.f54pc00_isppcmmn
> > amen.htm=DwIBAg=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw=u9g8
> > rUevBoyCPAdo5sWE9w=-
> UJtuL7ygnoO_jSZKwoqXZkKxYZabHfW2DHliI3IKU8=St_
> > eOtwpm5WRFX6EOtYceBdAAOXHTO-FbL_MpcX4_mQ=
> > Whatever you do, all players must follow the same rules.  Any
> > nonconformists must be re-coded.
> > I have tested using LMPUT to write multiple members concurrently.
> > It works, but only within a single job because ISPF LMPUT reqiuires
> > ENQ EXC on the DSN.
> > -- gil
> 
> If you do the ENQ as shown in the link above, be sure to also issue the
> RESERVE which is documented just before this. (ISPF Data set integrity
> enqueue).
> 
> --
> Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
> sas...@sas.com   (919) 531-5637Cary, NC 27513
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PDS Member updating via COBOL Program

[Don Poitras]

In article <2000189509316059.wa.paulgboulderaim@listserv.ua.edu> you wrote:
> On Tue, 8 Oct 2019 16:28:30 +, Jesse 1 Robinson wrote:
> >This is a classic problem endemic to traditional PDS since the dawn of MVS. 
> >IBM's solution to this problem is PDSE. If you convert the data set to 
> >Library (PDSE) you may reduce problem occurrence to negligible. OTOH PDSE 
> >may introduce its own set of problems, chief of which is the inability to 
> >share the data set across sysplex boundaries. If that restriction is 
> >unacceptable, you might try adding in your RYO enqueue program as you 
> >suggest. Be aware, however, that DISP=SHR is unlikely to provide much if any 
> >protection against concurrent update. 
> > 
> I have used ISPF LM services for this purpose.  But that requires a TSO
> environment.  Otherwise, you may simulate the ISPF technique, as in:
> 
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.f54pc00/isppcmmnamen.htm
> Whatever you do, all players must follow the same rules.  Any
> nonconformists must be re-coded.
> I have tested using LMPUT to write multiple members concurrently.
> It works, but only within a single job because ISPF LMPUT reqiuires
> ENQ EXC on the DSN.
> -- gil

If you do the ENQ as shown in the link above, be sure to also issue the
RESERVE which is documented just before this. (ISPF Data set integrity
enqueue).

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PDS Member updating via COBOL Program

[Paul Gilmartin]

On Tue, 8 Oct 2019 16:28:30 +, Jesse 1 Robinson wrote:

>This is a classic problem endemic to traditional PDS since the dawn of MVS. 
>IBM's solution to this problem is PDSE. If you convert the data set to Library 
>(PDSE) you may reduce problem occurrence to negligible. OTOH PDSE may 
>introduce its own set of problems, chief of which is the inability to share 
>the data set across sysplex boundaries. If that restriction is unacceptable, 
>you might try adding in your RYO enqueue program as you suggest. Be aware, 
>however, that DISP=SHR is unlikely to provide much if any protection against 
>concurrent update. 
> 
I have used ISPF LM services for this purpose.  But that requires a TSO
environment.  Otherwise, you may simulate the ISPF technique, as in:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.f54pc00/isppcmmnamen.htm

Whatever you do, all players must follow the same rules.  Any
nonconformists must be re-coded.

I have tested using LMPUT to write multiple members concurrently.
It works, but only within a single job because ISPF LMPUT reqiuires
ENQ EXC on the DSN.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PDS Member updating via COBOL Program

[Tabari Alexander]

>PDSE data sets and members can be shared. If allocated with DISP=SHR, the
>PDSE directory can be shared by multiple writers and readers, and each PDSE
>member can be shared by a single writer or multiple readers. Any number of
>systems can have the same PDSE open for input. If one system has a PDSE
>open for output (to create or replace members), that PDSE can be opened on
>other systems only if the systems are using the PDSE extended sharing
>protocol. The storage administrator can establish PDSE extended sharing
>protocol by using the PDSESHARING keyword in the IGDSMS*xx* member of
>SYS1.PARMLIB as described in z/OS DFSMSdfp Storage Administration
>
>.

One thing that I might add here is that if JOBA is really updating the member, 
as in opening the member for UPDATE, the PDSE sharing capabilities are 
diminished as opening a member for UPDATE requires the system to have exclusive 
access to the data set even if extended sharing is enabled. With that being 
said, the PDSE can still be shared in this scenario within the same system.

---
Tabari Alexander

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PDS Member updating via COBOL Program

[Tom Marchant]

On Tue, 8 Oct 2019 16:15:38 +, Pesce, Andy wrote:

>I have "JOBA" that executes a COBOL program to update a particular member in a 
>PDS.   Within the program, it calls an internal utility that someone
>wrote years ago that puts an enqueue on the dataset and its member that it is 
>updating.  The dd associated with the parmlib uses DISP=SHR.
>
>I have "JOBB" that executes a COBOL program to do the same thing, but it is a 
>different member within the same dataset as "JOBA".It is coded
>to open the dataset as I/O.  After it reads the member, it then does a 
>REWRITE.It doesn't follow the rules as above and use the internal utility.
>The dd associated with the parmlib also uses DISP=SHR.
>
>Here is the issue.   Occasionally the member in "JOBA" is becoming "empty", 
>while the member in JOBB is always OK.I have looked at SMF
>records and I see these jobs run at the same time.  And it is usually the same 
>down to the hundreds of seconds.
>
>My suggestion was that JOBB needs to be fixed to use the "enqueue and dequeue" 
>utility, since it is using DISP-SHR.   This parmlib is
>used heavily and extensively by applications, and no way to get it DISP=OLD.  
>Any thoughts or explanation would truly be appreciated.

Your ENQ on DSNAME+member will not help you when the two jobs are updating a 
different member.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PDS Member updating via COBOL Program

[John McKown]

On Tue, Oct 8, 2019 at 11:16 AM Pesce, Andy  wrote:

> I am looking for an explanation and this may be one of those
> "unpredictable results" may occur.
>
> I have "JOBA" that executes a COBOL program to update a particular member
> in a PDS.   Within the program, it calls an internal utility that someone
> wrote years ago that puts an enqueue on the dataset and its member that it
> is updating.  The dd associated with the parmlib uses DISP=SHR.
>
> I have "JOBB" that executes a COBOL program to do the same thing, but it
> is a different member within the same dataset as "JOBA".It is coded
> to open the dataset as I/O.  After it reads the member, it then does a
> REWRITE.It doesn't follow the rules as above and use the internal
> utility.
> The dd associated with the parmlib also uses DISP=SHR.
>
> Here is the issue.   Occasionally the member in "JOBA" is becoming
> "empty", while the member in JOBB is always OK.I have looked at SMF
> records and I see these jobs run at the same time.  And it is usually the
> same down to the hundreds of seconds.
>
> My suggestion was that JOBB needs to be fixed to use the "enqueue and
> dequeue" utility, since it is using DISP-SHR.   This parmlib is
> used heavily and extensively by applications, and no way to get it
> DISP=OLD.  Any thoughts or explanation would truly be appreciated.
>
>
I agree. You should use the same ENQs as ISPF just for safety's sake. An
vague possibility, but not as good, is to convert from a PDS to a PDS/E.
ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.idad400/shr.htm

PDSE data sets and members can be shared. If allocated with DISP=SHR, the
PDSE directory can be shared by multiple writers and readers, and each PDSE
member can be shared by a single writer or multiple readers. Any number of
systems can have the same PDSE open for input. If one system has a PDSE
open for output (to create or replace members), that PDSE can be opened on
other systems only if the systems are using the PDSE extended sharing
protocol. The storage administrator can establish PDSE extended sharing
protocol by using the PDSESHARING keyword in the IGDSMS*xx* member of
SYS1.PARMLIB as described in z/OS DFSMSdfp Storage Administration

.

-- 
I find television very educational. The minute somebody turns it on, I go
into the library and read a good book
-- Groucho Marx

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PDS Member updating via COBOL Program

[Jesse 1 Robinson]

This is a classic problem endemic to traditional PDS since the dawn of MVS. 
IBM's solution to this problem is PDSE. If you convert the data set to Library 
(PDSE) you may reduce problem occurrence to negligible. OTOH PDSE may introduce 
its own set of problems, chief of which is the inability to share the data set 
across sysplex boundaries. If that restriction is unacceptable, you might try 
adding in your RYO enqueue program as you suggest. Be aware, however, that 
DISP=SHR is unlikely to provide much if any protection against concurrent 
update. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pesce, Andy
Sent: Tuesday, October 8, 2019 9:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):PDS Member updating via COBOL Program

I am looking for an explanation and this may be one of those "unpredictable 
results" may occur.

I have "JOBA" that executes a COBOL program to update a particular member in a 
PDS.   Within the program, it calls an internal utility that someone
wrote years ago that puts an enqueue on the dataset and its member that it is 
updating.  The dd associated with the parmlib uses DISP=SHR.

I have "JOBB" that executes a COBOL program to do the same thing, but it is a 
different member within the same dataset as "JOBA".It is coded
to open the dataset as I/O.  After it reads the member, it then does a REWRITE. 
   It doesn't follow the rules as above and use the internal utility.
The dd associated with the parmlib also uses DISP=SHR.

Here is the issue.   Occasionally the member in "JOBA" is becoming "empty", 
while the member in JOBB is always OK.I have looked at SMF
records and I see these jobs run at the same time.  And it is usually the same 
down to the hundreds of seconds.

My suggestion was that JOBB needs to be fixed to use the "enqueue and dequeue" 
utility, since it is using DISP-SHR.   This parmlib is
used heavily and extensively by applications, and no way to get it DISP=OLD.  
Any thoughts or explanation would truly be appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN