On 19 Dec 2007 07:44:18 -0800, in bit.listserv.ibm-main
(Message-ID:<[EMAIL PROTECTED]>)
[EMAIL PROTECTED] (J Ellis) wrote:
//DD1 DD DSN=app.data,
// DCB=(LRECL=567,BLKSIZE=27783,RECFM=FB),
// SPACE=(CYL,(1,10)),DISP=(,catlg)
later on, they use this data set as output to a syncgener
step as:
//COPY1.SYSUT2 DD DSN=app.data,
// DCB=(LRECL=567,BLKSIZE=27783,RECFM=FB),
// SPACE=(CYL,(300,50)),DISP=OLD,UNIT=(SYSDA,59)
aside from the obvious things you may comment on, when
this data set is
accessed in the second step, allocation wise, isn't the
only thing that gets
a temporary bump the secondary allocation from 10 to 50 ?
The primary will
still be 1, yes ? They had an SB37-04 last night on a
volume that only had 280 free cylinders,
I think they had already hit 16 extents on the data set
not that the primary
couldn't be filled. No way to check since they deleted it
and reallocated it
at (400,100)
I've also seen problems when a UNIT name was
specified for an already-catalogued dataset, as is the case
here.
Note also that the 2nd step specifies up to 59
units. I know that VSAM allocates a primary amount on each
new volume; I can't recall, offhand, if PS does the
same. (Is it PS? No DSORG was specified.)
Final note from me: Since no UNIT was specified in
the original allocation, I wouldn't be surprised if either
SMS or an allocation exit got involved at some point. In
either case, they might be involved at the time of grabbing
another extent.
--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
