Re: Difference between DISP=NEW and MOD for a PDS member?

[Linda Mooney]

Yes, that would be the same.  So, how about  if you preallocated a sequential 
file, then used IEBCOPY (with or without replace - as might be appropriate for 
your product) to copy the new file into the pds or pdse member?  



I am curious as to why a pds or pds/e is needed .  In my shop, we use 
individual sequential , or GDG for ftp datasets. 



Linda 


- Original Message - 
From: "Charles Mills"  
To: IBM-MAIN@bama.ua.edu 
Sent: Sunday, March 6, 2011 6:51:01 AM 
Subject: Re: Difference between DISP=NEW and MOD for a PDS member? 

Linda - 

Thanks, yes, I am pre-creating (hope that's what you meant) the dataset. I get 
into trouble if it's DSN(MEMBER),DISP=NEW/MOD because you can't do that twice. 

Charles 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Linda Mooney 
Sent: Saturday, March 05, 2011 8:32 PM 
To: IBM-MAIN@bama.ua.edu 
Subject: Re: Difference between DISP=NEW and MOD for a PDS member? 

Hi Charles, 



I have read through the thread with some interest, though I do not know you or 
which product you are working on. 



Would it be possible for your code to preallocate the receiving 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 

--
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: Maybe off topic

[Jim Mulder]

> I was reading some article today about IBM & DB2 today.
> I think it said something like DB2 was IBM's real first try into 
relational 
> databases.
> My memory is foggy here something in the back of my mind says that 
> is not quite correct.
> Back in the 70's (?) I vaguely remember IBM having a FDP(?) that 
> claimed to do relational database.
> By slim memory says it may have been VM based. I do remember it had a 4 
page 
> white sales type paper(IUP?). No name comes up.
> Can anyone supply me with a product name?
> I do recall something like this as we were looking at a product and the 
show 
> stopper was that it needed VM.

http://portal.acm.org/citation.cfm?id=320457

http://en.wikipedia.org/wiki/IBM_System_R

http://www.sigmod.org/publications/dblp/db/systems/r.html


Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
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

Maybe off topic

[Ed Gould]

I was reading some article today about IBM & DB2 today.
I think it said something like DB2 was IBM's real first try into relational 
databases.
My memory is foggy here something in the back of my mind says that is not quite 
correct.
Back in the 70's (?) I vaguely remember IBM having a FDP(?) that claimed to do 
relational database.
By slim memory says it may have been VM based. I do remember it had a 4 page 
white sales type paper(IUP?). No name comes up.
Can anyone supply me with a product name?
I do recall something like this as we were looking at a product and the show 
stopper was that it needed VM.
Anyone?

Ed



--
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
  

Jose Alberto Victorino is out of the office.

[Jose Alberto Victorino]

I will be out of the office starting  07-03-2011 and will not return until
09-03-2011.

I will respond to your message when I return.

--
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

RACF and Tivoli zSecure Training in Sydney and Melbourne, Australia (April-June 2011)

[Steve Talbot-Walsh]

RSM Technology, with over thirty years of experience in serving users of IBM 
mainframe and Enterprise computing platforms, offers and runs the largest 
number of top-quality specialist z/OS and mainframe-related courses in the UK 
and Europe. As RSM's Authorized Training Partner within the Asia Pacific region 
and the centre of competence for IBM System z Security, Tardis have scheduled 
the following RACF and Tivoli zSecure courses:
 
Melbourne (April/May)
 
Tivoli zSecure CARLA Fundamentals3 days
Tivoli zSecure Overview  1 day
RACF Administration & Auditing   4 days
RACF for Auditors3 days
RACF Overview1 day


Sydney (May/June)
 
RACF Administration & Auditing   4 days
RACF Advanced Topics 2 days
RACF for Auditors3 days
RACF for z/OS System Programmers 3 days
RACF Overview1 day
 
If you are interested in attending any of the above courses and require further 
information, please contact Sharon McNamara at shar...@tardis.com.au




__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

--
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: Difference between D ISP=NEW an d MOD for a PDS memb er?

[Shmuel Metz (Seymour J.)]

In , on 03/06/2011
   at 04:15 PM, john gilmore  said:

>This is not the case.

Not only is it the case, it has been for decades.

>Worse, he has been admonished about this error repeatedly.

Before you admonish him again, RYFM.

>The Inquisition would almost certainly labelled him as not just a
>heretic but an obdurate one,

Putting him on the side of the angels.

>AS I and others have already noted that the question whether a
>PDS[E] member named  exists is 1) moot until the question
>whether that PDS[E] itself exists is resolved and 2) 

Is highly relevant to what happens if the PDS does exists, both in
practice and according to the SRL.

>DISP=MOD goes back to OS/PCP.

ITYM OS/360.

>something like

The Devil is in the details. "Something like" doesn't cut it. An
actual quote would be more relevant, e.g., 

   12.23.7  Disposition of Partitioned Data Sets (PDSs and PDSEs)

 When you specify DISP=MOD or DISP=NEW for a partitioned data
 set (PDS) or partitioned data set extended (PDSE), and you
 also specify a member name in the DSNAME parameter, the
 member name must not already exist.  If the member name
 already exists, the system terminates the job.

 When you specify DISP=OLD for a PDS or a PDSE, and you also
 specify a member name in the DSNAME parameter, the data set
 must already exist.  If the member name already exists and
 the data set is opened for output, the system replaces the
 existing member with the new member.  If the member name does
 not already exist and the data set is opened for output, the
 system adds the member to the data set.

Admittedly early versions of the documentation were sketchy, but
that's been fixed for lo these many years. Also, the quoted text is
admittedly wrong if you OPEN with DSORG and do your own STOW.

>and what anyway is all of this pother about?

Perhaps the OP prefers that his code work correctly?

 
-- 
 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: Difference between DISP=NEW and MOD for a PDS member?

[Shmuel Metz (Seymour J.)]

In <4d71708d.3000...@bremultibank.com.pl>, on 03/05/2011
   at 12:06 AM, "R.S."  said:

>DISP is always for dataset, not for member.

Not only is that false, but it contracdicts the remaindeer of your
message. DISP is for both the DS and the member.
 
-- 
 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: Difference between DISP=NEW and MOD for a PDS member?

[Shmuel Metz (Seymour J.)]

In <02c601cbdae7$d9103650$8b30a2f0$@net>, on 03/04/2011
   at 07:46 PM, Gerhard Adam  said:

>I personally can't see any reason for
>coding DISP=MOD or DISP=NEW when maintaining PDS members.

Avoiding an ABEND is a good reason.

>My point about poor coding practice, is that the DISP is used to
>reflect the state of an entire data set and not individual members. 

Perhaps in some other OS. In z/OS it's used for both. Poor design,
perhaps, but it's not likely to change.

>So while DISP=NEW and DISP=MOD are supported, there's no 
>practical reason for their use

Not if you don't care aboput the ABEND.
 
-- 
 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: Difference between DISP=NEW and MOD for a PDS member?

[R.S.]

W dniu 2011-03-06 17:19, Chris Mason pisze:

Radoslaw


Yes, DISP=NEW fails if the PDS already exists. Even if nonexistent member is

specified.

I'm assuming that what you mean to say is the following

[...]
Chris,
You used many words, citations, quotations, etc. but IMHO you should 
just say "I was wrong".
I really don't care what's in the manual, what somebody said, etc. DISP 
in JCL is always for dataset, not the member, DISP=NEW always end with 
JCL error when PDS(E) exist, and it it completely irrelevant whether you 
specify member name or not or specified member exists or not.


The only (not mentioned) case when DISP=NEW works (does not cause error) 
for existing dataset is ...

(I think it wasn't mentioned here yet)
GDG.

GDG dataset with "deferred roll in" (proper name can be slightly 
different, wrote from my poor memory) is simply rolled it when DISP=NEW 
is used. But it is very specific case, which precludes usage of PDSE and 
membername of PDS. And was (no longer is) unsupported by IBM for PDS.





I want the discussion to stay technical one, not - let's say - 
political, like USS meaning or Toronto airports.

Regards
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 16.07.2010 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.248.328 zotych. 


--
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: Difference between DISP=NEW and MOD for a PDS member?

[Chris Mason]

Don

It turns out there is some amazing sophistry which can explain the grin on the 
non-existent Cheshire Cat!

The copper-bottomed line is that, indeed, all suboperands of DISP relate to 
the data set and, in that case where the DSNAME specifies a member, none of 
the suboperands of DISP relate to the member.

That confusing paragraph which implied that a data set could exist already 
with DISP=NEW - or why was the existence or otherwise of the member 
pertinent - can be explained as follows:

- Let us say the program wants to open and close the data set N times and at 
least the first time one or more records (blocks) are written.

-- If DISP=OLD or DISP=SHR is specified and the data set (pds) exists already, 
this is fine.

-- If DISP=NEW is specified and the data set didn't exist already, the 
first "open and close" will work, but the second open causes a failure since 
now the member exists.

-- If DISP=MOD is specified and the data set didn't exist already, the 
first "open and close" will work, but the second open causes a failure since 
now the member exists.

-- If DISP=MOD is specified and the data set existed already but the member 
didn't exist, the first "open and close" will work, but the second open causes 
a 
failure since now the member exists.

-- If DISP=MOD is specified, the data set existed already and the member 
existed already, the first open causes a failure since the member exists.

For convenience, here's that pesky paragraph again:



When you specify DISP=MOD or DISP=NEW for a partitioned data set (PDS) or 
partitioned data set extended (PDSE), and you also specify a member name in 
the DSNAME parameter, the member name must not already exist. If the 
member name already exists, the system terminates the job. 



Charles Mills did hint at this earlier but I'm afraid I missed his point.

Of course, why this should be a problem is not clear - or not to me anyhow - 
and when something like this isn't clear it behoves the developers to explain 
themselves - and sometimes they do, sometimes they don't!

Chris Mason

On Sun, 6 Mar 2011 09:49:03 -0500, Don Williams  
wrote:

>When I replied with my "simple" answer, I had not seen the part of thread
>referring to product being written. Over the years, I have had to restore
>many PDSes when a naïve user coded DISP=(MOD,DELETE). Sorry, I'm biased 
with
>trying to make sure that most people view, in general, DISP as a dataset
>level parameter. However, in this case the nuances of the DISP parameter are
>important.
>
>Don
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
Behalf
>Of Chris Mason
>Sent: Saturday, March 05, 2011 11:44 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: Difference between DISP=NEW and MOD for a PDS member?
>
>Don
>
>> The simple answer:
>
>This is not a topic for people who need "simple answers"!
>
>When I said
>
>>...> DISP=NEW/MOD insists that the member does not exist irrespective of
>whether or not a partitioned data set exists
>
>obviously I was concentrating on the only on first suboperand of the DISP
>operand.
>
>It seems we must take a different perspective according to whether we are
>dealing with the first suboperand or the second and third suboperands - not
>at
>all "simple"!
>
>> The DISP parameter is for the data set/library and not members.
>
>Apparently not so in the case of the first suboperand.
>
>If a member name is specified, the first suboperand relates to the member
>and
>appears not to care about the data set. Otherwise why make a fuss about
>whether a member exists or not in a data set that can't be there to contain
>the member - which may or may not be there - if the data set is not 
supposed
>
>to exist - in the case of DISP=NEW anyhow. There's something of the
>Cheshire Cat about this!
>
>Here, once again for your delectation, is the first paragraph of the
>section "12.19.8 Disposition of Partitioned Data Sets (PDSs and PDSEs)" from
>
>the z/OS V1R12 MVS JCL Reference manual:
>
>http://publibz.boulder.ibm.com/cgi-
>bin/bookmgr_OS390/BOOKS/IEA2B6A0/12.19.8
>
>
>
>When you specify DISP=MOD or DISP=NEW for a partitioned data set (PDS) or
>partitioned data set extended (PDSE), and you also specify a member name in
>the DSNAME parameter, the member name must not already exist. If the
>member name already exists, the system terminates the job.
>
>
>
>If you can explain this away, I'll accept your "simple" contention also
>regarding
>the first suboperand.
>
>> For example, DSN=MY.LIBRARY(MYMEM),DISP=(OLD,DELETE) deletes the
>library and not just the member.
>
>Assuming you verified your example rather than just composing it in order to
>
>illustrate your point, it appears that the normal and abnormal termination
>disposition suboperands do indeed apply to the data set irrespective of
>whether or not a member name is specified. I checked the z/OS V1R12 MVS
>JCL Reference manual to try to be sure and there is certainly no mention of
>any variation base

Re: Difference between DISP=NEW and MOD for a PDS member?

[Chris Mason]

Radoslaw

> Yes, DISP=NEW fails if the PDS already exists. Even if nonexistent member is 
specified.

I'm assuming that what you mean to say is the following:

"Yes, DISP=NEW fails if the PDS already exists and a member name is 
specified, even if a non-existent member is specified."

In fact, the post to which you are actually responding 

- had the virtue of brevity so could appeal to short attention spans - and I'm 
not accusing you of that - it's just that I've tried to make the point in a few 
posts and been ignored

- has the vice of not being properly hedged with the qualification "if what is 
implied by the manual is to be believed" but then, to have ameliorated that 
vice, would have impinged on the virtue!

Anyhow thanks very much for having demonstrated that what is implied in the 
manual is *not* to be believed with a test.

I hope you noted in an earlier post that I tried to take your route but 
committed the heinous crime of actually believing what the manual implied. Will 
I ever learn? Unfortunately I don't have a "sandbox" these days so these 
suspect documents are all I have to try to clarify these sorts of matters. 

What this indicates is that the section of the manual to which Gerhard Adam 
directed us is fatally wrong.

Which could be used as an answer to Gerhard's question:

>...> Has it occurred to anyone to just look at the JCL Reference manual?

Maybe "Yes, but I don't trust what the JCL Reference manual tells me so I'm 
asking for help from someone who really knows."

I propose a rewriting as follows:



When you specify DISP=MOD or DISP=NEW for a partitioned data set (PDS) or 
partitioned data set extended (PDSE), and you also specify a member name in 
the DSNAME parameter, the member name must not already exist. If the 
member name already exists, the system terminates the job. 

When you specify DISP=OLD for a PDS or a PDSE, and you also specify a 
member name in the DSNAME parameter, the data set must already exist. If 
the member name already exists and the data set is opened for output, the 
system replaces the existing member with the new member. If the member 
name does not already exist and the data set is opened for output, the 
system adds the member to the data set. 

When you specify DISP=MOD for a PDS or a PDSE, and you do not specify a 
member name, the system positions the read/write mechanism at the end of 
the data set. The system does not make an automatic entry into the 
directory. 

When you specify DISP=MOD for a PDS or a PDSE, and you do specify a 
member name, the system positions the read/write mechanism at the end of 
the data set. If the member name already exists, the system terminates the 
job. 





When you specify DISP=NEW for a partitioned data set (PDS) or partitioned 
data set extended (PDSE) and you also specify a member name in the 
DSNAME parameter, naturally neither the data set nor the member exist.[1] If 
the data set is opened for output, the system adds the member to the data 
set. 

When you specify DISP=MOD for a PDS or PDSE and you also specify a 
member name in the DSNAME parameter, the data set may exist but, if the 
data set already exists, the member must not already exist. (If the member 
already exists, the system terminates the job.) If the data set is opened for 
output, the system adds the member to the data set. 

When you specify DISP=MOD for a PDS or a PDSE, the system positions the 
read/write mechanism at the end of the data set.

When you specify DISP=MOD for a PDS or a PDSE, and you do not specify a 
member name in the DSNAME parameter and the data set exists, the system 
does not make an automatic entry into the directory.

When you specify DISP=OLD for a PDS or a PDSE and you also specify a 
member name in the DSNAME parameter, the data set must already exist. If 
the member name already exists and the data set is opened for output, the 
system replaces the existing member with the new member. If the member 
name does not already exist and the data set is opened for output, the 
system adds the member to the data set. 

[1] Initially. However, if, during execution, a data set is created thereby 
creating a member having the specified name and then there is an attempt to 
create another data which would, if allowed to proceed create a member 
replacing the previous member, that attempt will fail.



I've fixed up not only the first paragraph, the one that is so ridiculously 
wrong, 
but also the rest in order to be just a bit clearer and I have tried to 
maintain a 
pattern which should provide assurance that the description is more 
comprehensive.

The sentence regarding the "automatic entry" is a bit of a mystery since I find 
no other reference to something like this anywhere else in either of the JCL 
manuals.

Also I'm not sure that the "read/write mechanism" comment belongs here. I've 
a suspicion that the manual author was asked to slip in a comment like this 
wherever DISP=MOD was mentioned in the manual.

Not

Difference between D ISP=NEW an d MOD for a PDS memb er?‏

[john gilmore]

Charles Mills wrote:
 
"DISP=" -- which includes the current status of the dataset -- NEW, MOD, OLD -- 
is for both the dataset AND the member.
 
This is not the case.  Worse, he has been admonished about this error 
repeatedly.  In the past he would have been in great danger.  The Inquisition 
would almost certainly labelled him as not just a heretic but an obdurate one, 
and things would not have gone well for him.
 
AS I and others have already noted that the question whether a PDS[E] member 
named  exists is 1) moot until the question whether that PDS[E] itself 
exists is resolved and 2) need not be reached to explain the behavior that has 
been dsecribed here.
 
DISP=MOD goes back to OS/PCP.  In those days it was usual to explain the 
difference between DISP=NEW and DISP=MOD to novices by saying something like
 
o DISP=NEW means create  it, then use it; and
 
o DISP=MOD means create it is it does not exist, then use it.
 
Novices usually encountered DISP=MOD first in cataloged procedures.   A common 
sequence of job steps was
 
o compile A, writing the object module produced to SYSLIN,
 
o compile B, writing the object module produced to SYSLIN, etc.,
 
o link these object modules to obtain a load module, and
 
o execute this load module briefly, i.e., until the first fatal error occurred.
 
In these circumstances both SYSLIN and SYSLMOD were often temporary data sets, 
and DISP=MOD was used in cataloged procedures that defined them in order to 
permit compiles and, less commonly, link edits and executions to be to be 
stacked up in separate successive steps of the same job.
 
In the first job step, that for A above, SYSLIN did not exist; and it was thus 
both created and used; in the second jobstep it did exist and was used, etc., 
etc.  The same cataloged procedure could ber and was used for both.
 
Conceptually similar schemes still have uses; the contextual distinction 
between DISP=MOD and DISP=NEW remains useful; and what anyway is all of this 
pother about?   

--
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: Difference between DISP=NEW and MOD for a PDS member?

[Charles Mills]

"DISP is always for the dataset and not the member"

The problem is that DISP means different things. If you are a JCL coder,
then DISP is a parameter that indicates the current status of the dataset
and what is to become of it after the jobstep completes: DISP=(NEW,CATLG).

If you are using SVC 99 or looking at JFCBs then disposition means only the
latter of those two things, what is to become of the dataset. The current
status is called -- drum roll please -- status.

I think it is safe to say that "disposition" -- what happens after the
jobstep completes -- DELETE, CATLG, etc. -- is always for the dataset and
not the member. "DISP=" -- which includes the current status of the dataset
-- NEW, MOD, OLD -- is for both the dataset AND the member.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of R.S.
Sent: Sunday, March 06, 2011 2:16 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Difference between DISP=NEW and MOD for a PDS member?

W dniu 2011-03-06 05:41, Chris Mason pisze:
> Charles
>
> The bottom line lacks copper.
>
>> DISP=NEW fails if the PDS already exists
>
> Not if the name of a non-existent member is specified.

Yes, DISP=NEW fails if the PDS already exists. Even if nonexistent 
member is specified.
At least my poor z/OS claims so. (Read: I just tested it).

And I dare to repeat: DISP is always for dataset, not for the member. 
That's what we observe everyday: DELETE deletes PDS(E), NEW requires 
SPACE and creates new PDS(E) on disk.

--
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: Difference between DISP=NEW and MOD for a PDS member?

[Charles Mills]

> The FTP LRECL default is 256 for both client and server.
> The FTP RECFM default is VB for both client and server.

That's nice. I just tested

//TESTDD   DD  DSN=userid.FOO.BAR,DISP=(NEW,CATLG),UNIT=SYSDA, 
//  SPACE=(TRK,(1,1))  

GET   TCC.CTNL(IEFBR14) //DD:TESTDD

And got

userid.FOO.BAR  
 --RECFM-LRECL-BLKSIZE-DSORG 
   U **6144PS

> If your problem concerns the way z/OS Communications Server FTP behaves

It does not. It concerns the difference between DISP=NEW and DISP=MOD for a
PDS member.

"Did somebody say" was a figure of speech.  

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Chris Mason
Sent: Saturday, March 05, 2011 8:52 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Difference between DISP=NEW and MOD for a PDS member?

Charles

> The underlying problem is that FTP has the world's worst RECFM and LRECL 
defaults, something like RECFM=U, LRECL=1024 (LRECL from recollection).

The FTP LRECL default is 256 for both client and server.

http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/F1A1B4A0/18.77

The FTP RECFM default is VB for both client and server.

http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/F1A1B4A0/18.100

> Did somebody say use LOCSITE? Unfortunately LOCSITE is not effective 
with //DD:

Not unless you have been receiving private communications which the rest of 
us have not seen or it's a contributor whose post hasn't appeared in the
IBM-
MAIN archives.

-

If your problem concerns the way z/OS Communications Server FTP behaves, 
you may find the expertise you need in the IBMTCP-L list.

--
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: Difference between DISP=NEW and MOD for a PDS member?

[Charles Mills]

>> DISP=NEW fails if the PDS already exists

> Not if the name of a non-existent member is specified.

Nay! I just tested exactly that and got
IEF253I TCC00114 BR14 FOO - DUPLICATE NAME ON DIRECT ACCESS VOLUME

The same DD executes if I specify DISP=MOD (but would presumably fail on the
CLOSE).

> I'm still waiting for an explanation of how a member can exist in a
partitioned 
> data set that cannot exist - possibly I'm in the wrong universe!

If you're still waiting you didn't read what you quoted below!

"this can only happen if the program creates the member during execution
(OPEN, PUT, CLOSE, OPEN, PUT, CLOSE) because after all the PDS must be brand
new"

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Chris Mason
Sent: Saturday, March 05, 2011 8:41 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Difference between DISP=NEW and MOD for a PDS member?

Charles

The bottom line lacks copper.

> DISP=NEW fails if the PDS already exists

Not if the name of a non-existent member is specified.

> DISP=NEW and MOD both fail if the member already exists.

I'm still waiting for an explanation of how a member can exist in a
partitioned 
data set that cannot exist - possibly I'm in the wrong universe!

Chris Mason

On Sat, 5 Mar 2011 11:28:40 -0800, Charles Mills  
wrote:

>And I guess the bottom line on the original technical question is:
>
>- DISP=NEW fails if the PDS already exists (or, if you will, "may be used
to
>make certain that the PDS does not already exist"); DISP=MOD is good either
>way.
>- DISP=NEW and MOD both fail if the member already exists but fail
>differently: NEW fails on the CLOSE with SB14-04 -- this can only happen if
>the program creates the member during execution (OPEN, PUT, CLOSE, OPEN,
>PUT, CLOSE) because after all the PDS must be brand new; MOD fails on the
>OPEN but I am not sure of the exact error.
>
>Comments?
>
>Charles
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
Behalf
>Of Charles Mills
>Sent: Saturday, March 05, 2011 7:26 AM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: Difference between DISP=NEW and MOD for a PDS member?
>
>A lot of replies. Thanks all. Let me try to address various comments in a
>single response.

--
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: Difference between DISP=NEW and MOD for a PDS member?

[Charles Mills]

Linda -

Thanks, yes, I am pre-creating (hope that's what you meant) the dataset. I get 
into trouble if it's DSN(MEMBER),DISP=NEW/MOD because you can't do that twice.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Linda Mooney
Sent: Saturday, March 05, 2011 8:32 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Difference between DISP=NEW and MOD for a PDS member?

Hi Charles, 



I have read through the thread with some interest, though I do not know you or 
which product you are working on. 



Would it be possible for your code to preallocate the receiving 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: Difference between DISP=NEW and MOD for a PDS member?

[Don Williams]

When I replied with my "simple" answer, I had not seen the part of thread
referring to product being written. Over the years, I have had to restore
many PDSes when a naïve user coded DISP=(MOD,DELETE). Sorry, I'm biased with
trying to make sure that most people view, in general, DISP as a dataset
level parameter. However, in this case the nuances of the DISP parameter are
important. 

Don

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Chris Mason
Sent: Saturday, March 05, 2011 11:44 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Difference between DISP=NEW and MOD for a PDS member?

Don

> The simple answer:

This is not a topic for people who need "simple answers"!

When I said

>...> DISP=NEW/MOD insists that the member does not exist irrespective of 
whether or not a partitioned data set exists

obviously I was concentrating on the only on first suboperand of the DISP 
operand.

It seems we must take a different perspective according to whether we are 
dealing with the first suboperand or the second and third suboperands - not
at 
all "simple"!

> The DISP parameter is for the data set/library and not members.

Apparently not so in the case of the first suboperand.

If a member name is specified, the first suboperand relates to the member
and 
appears not to care about the data set. Otherwise why make a fuss about 
whether a member exists or not in a data set that can't be there to contain 
the member - which may or may not be there - if the data set is not supposed

to exist - in the case of DISP=NEW anyhow. There's something of the 
Cheshire Cat about this!

Here, once again for your delectation, is the first paragraph of the 
section "12.19.8 Disposition of Partitioned Data Sets (PDSs and PDSEs)" from

the z/OS V1R12 MVS JCL Reference manual:

http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/IEA2B6A0/12.19.8



When you specify DISP=MOD or DISP=NEW for a partitioned data set (PDS) or 
partitioned data set extended (PDSE), and you also specify a member name in 
the DSNAME parameter, the member name must not already exist. If the 
member name already exists, the system terminates the job. 



If you can explain this away, I'll accept your "simple" contention also
regarding 
the first suboperand.

> For example, DSN=MY.LIBRARY(MYMEM),DISP=(OLD,DELETE) deletes the 
library and not just the member.

Assuming you verified your example rather than just composing it in order to

illustrate your point, it appears that the normal and abnormal termination 
disposition suboperands do indeed apply to the data set irrespective of 
whether or not a member name is specified. I checked the z/OS V1R12 MVS 
JCL Reference manual to try to be sure and there is certainly no mention of 
any variation based on whether or not a member name is specified so I guess 
an actual test would have been superfluous.

http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/IEA2B6A0/12.19.2.2
http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/IEA2B6A0/12.19.2.3

Indeed, it's all getting a bit complex and the poor systems programmer who 
tried to delete a member using the DISP second suboperand can be forgiven - 
well by those who were not desperately relying on the partitioned data set, 
that is![1]

-

A modification to my previous post with the diagrams:

In the case of a DISP=NEW data set or dataset(member) - and DISP=MOD if 
the entity has had no existence hitherto - it is an error not to write 
something. This makes my "error or immediate EOF" simply "error". 
An "immediate EOF" would be possible only if the data set - or a member I 
guess - had deliberately been created - "written to" - with 0 records. 
Alternatively I'll be happy to be corrected.

-

Chris Mason

[1] This reminds me of an occasion when I keyed up a SCRATCH statement 
that was supposed to be coded as 

SCRATCH VTOC,VOL=2314=MYVOLM,SYS

After that traumatic event, I resolved always to use the order

SCRATCH VTOC,SYS,VOL=2314=MYVOLM

because it turns out you can't always be sure that where you intended to key

a comma, a comma actually got keyed!

I remember even better because it was New Year's Eve and the was someone 
from north of the border in the overworked team.


On Sat, 5 Mar 2011 15:12:41 -0500, Don Williams  
wrote:

>The simple answer: The DISP parameter is for the data set/library and not
>members.
>
>For example, DSN=MY.LIBRARY(MYMEM),DISP=(OLD,DELETE) deletes the 
library and
>not just the member.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
Behalf
>Of Charles Mills
>Sent: Friday, March 04, 2011 3:03 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Difference between DISP=NEW and MOD for a PDS member?
>
>What is the difference between DISP=NEW and DISP=MOD for a PDS member
>(member name specified on the DD statement)?
>
>Both disallow duplicate member names. Are there any differences? What?
>
>Charles

---

Re: Differ ence betwe en DISP=NE W and MOD for a PDS member?‏

[john gilmore]

I looked at this long-running thread for the first time this morning to see 
what was going on.  
 
An obvious point that is perhaps worth making anyway is:
 
A necessary precondition that a  PDS[E] member having some specified name 
 already exist is that the PDS[E] in question itself already exist.
 
As others have already noted, DISP is about data sets, not about PDS[E] members.

John Gilmore Ashland, MA 01721-1817 USA

  

--
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: Difference between DISP=NEW and MOD for a PDS member?

[R.S.]

W dniu 2011-03-06 05:41, Chris Mason pisze:

Charles

The bottom line lacks copper.


DISP=NEW fails if the PDS already exists


Not if the name of a non-existent member is specified.


Yes, DISP=NEW fails if the PDS already exists. Even if nonexistent 
member is specified.

At least my poor z/OS claims so. (Read: I just tested it).

And I dare to repeat: DISP is always for dataset, not for the member. 
That's what we observe everyday: DELETE deletes PDS(E), NEW requires 
SPACE and creates new PDS(E) on disk.

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 16.07.2010 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.248.328 zotych. 


--
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