Paul Gilmartin wrote:
On Tue, 22 May 2007 08:15:16 -0400, John Eells wrote:
<snip>
I am completely naive of "indirect cataloguing". What book should
I read?
- The parameters for DEFINE NONVSAM in z/OS DFSMS Access Method
Services for Catalogs:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2i250/16.1.1?SHELF=EZ2ZO10h&DT=20060630014839&CASE=
Got it. Thanks. In fact, I had some vague knowledge of the facility, but
not by name, nor how to use it.
How worthwhile is it for an ISV to provide skeleton JCL for the customer
to use in cataloguing with indirect volume references? (And I note that
some vendors' testing resources might be much taxed by validating such
a facility.)
"NONVSAM". Is there comparable support for VSAM, or would customers expect
the CSI to be simply catalogued, with multiple TARGET and DLIB zones referring
to indirectly catalogued libraries? This feels soooo risky: running an
APPLY or ACCEPT job on the wrong system could be disastrous. It would feel
safer if all update jobs made direct references to the output data sets,
and any indirect references were read-only.
<snip>
There is no indirect catalog support for VSAM. The closest you
can come is to place a user catalog on the volume with the VSAM,
have that catalog own all the VSAM data sets on the volume, and
use indirect aliasing to find the catalog. Do a search in the
AMS book for the "SYMBOLICRELATE" keyword of the DEFINE ALIAS
command.
Note also that you cannot indirectly catalog a data set in JCL.
You must use the IDCAMS DEFINE NONVSAM commmand, along these lines:
//STEP EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE -
NONVSAM( -
NAME(data.set.name) -
VOLUMES(&SYSR1) -
DEVT(0000)) -
CATALOG(user.catalog.name.if.needed)
You could also use the IDCAMS ALLOCATE command to allocate the
data sets and set up command return code checking and
conditionally run commands to accommodate restart, etc., as we
did in ServerPac's ALLOCDS job a while ago. This is cleaner--if
more complex--than using IEFBR14, which will have condition code
zero whether or not the data sets got allocated and cataloged (or
not) as you intended. If you go this route, why we use SSAs in
ServerPac will quickly become apparent. ;-)
In my opinion:
- DDDEFs should not point to cataloged data sets on production
systems. Instead, even though the catalog entries for system
residence target volume (sets) should be indirect to allow master
catalog reuse and make migration/backout easier, the DDDEFs
should point to specific volumes (with a unit of SYSALLDA just in
case we ever introduce another device type). Also, the DDDEFs
for the production copy should point to a volume that does not
exist to avoid inadvertantly running APPLY against the active system.
- From a software packaging standpoint, if your software lives on
the sysres target volume set you should provide support for
indirect cataloging using system symbols. People can define
system symbols based on the value of the system-supplied &SYSR1
symbol for the IPL volume to point to data sets on &SYSRn volumes.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
----------------------------------------------------------------------
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
