Paul Gilmartin wrote:
In a recent note, Ron Hawkins said:
Date: Wed, 24 Jan 2007 13:22:59 +0800
This conflicts with BLKSIZE=0 being used for SDB. SDB does not work
unless
DSORG can be established. BLKSIZE=0 is a null - SDB requires DSORG and
no
BLKSIZE. Additional DCB depends on the DSORG.
There should be no conflict. SDB also doesn't operate until the DCB
is opened for output. It must, in fact, be deferred until after
the DCB OPEN exit has had an opportunity to supply RECFM and LRECL
(as well as DSORG). Easy enough to verify: allocate a data set with
BLKSIZE=0; verify with DSLIST INFO that BLKSIZE remains 0; OPEN it
for output; verify that BLKSIZE has been defined.
This is something I fight against. Sometimes the dataset is never
opened. For example it is kind of "exception report". In case of no
exceptions the dataset remains "untouched". It cannot be backed up due
to invalid DSORG, so it will *never* be migrated or deleted according to
mgmt class parameters. It occupies the best DASD space.
Obviously you can create report of such datasets, delete them manually,
instruct fokls to specify DSORG, etc.
The above is for HSM customers, AFAIK FDR users have no such problem,
because FDR manages datasets with invalid DSORG.
--
Radoslaw Skorupka
Lodz, Poland
----------------------------------------------------------------------
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
