> I'm puzzled. I haven't installed an ADCD for a while, but the layout
> used to be explicitly designed for z/OS migration, with a clear split
> between the volumes that would be expected to be replaced in a
> migration, and those that wouldn't.
I disagree. It is set up so that you can customize it properly (by dividing 
your customization from what the system does), provided you know how to do 
that. When I got my hands on the 1.10 system, I first had to clean it up 
severely (get all of our datasets out of the master catalog into a user 
catalog) and then hope and pray that I have found all places someone (using 
IBMUSER) had changed the SMPE-maintained libraries instead of copying to USER.* 
libraries (before my time). It takes some knowledge about migration to be able 
to customize correctly.

When switching to the new system, we lost the RACF database and the master 
catalog and were forced onto the new ones. I had to make sure that I had all of 
our own RACF definitions copied to the new system. Someone had in the past 
activated SMS to contain more than the minimum config ADCD comes with. 
Unfortunately (never having been a space admin before), I didn't know that I 
also had to copy over the SMS CDSs. That caused all kinds of problems. Maybe it 
is just our provider (who had apparently done something to the bare ADCD 
system), but we were not given the chance to 'just replace' the system volumes 
(as one would do in a 'normal' migration to a new release). Instead, we were 
thrown into a new, vanilla ADCD system (and no documentation to speak of) and 
forced to copy over all of our user data. The (old) volumes could get attached 
under VM to the new z/OS system, so that removed the necessity of ADRDSSU 
dumping, FTPing and restoring everything.

Never mind that FTP apparently was broken. An ADRDSSU dump taken in the 1.10 
system and FTP'd (in my case via IND$FILE) to 1.13 resulted in ADRDSSU in 1.13 
telling me that this was not an ADRDSSU dump. When we ftp'd the transport copy 
of our user catalog, something else broke and I was unable to import connect 
the user catalog. When we ADRDSSU dumped the old usercat and restored it, we 
got abend0C4 in some catalog module or other. Eventually I first amatersed any 
catalog or ADRDSSU dump on the old system, ftp'd the amatersed copy to 1.13, 
and untersed it. *Then* it was recognized as a valid copy. I did not debug what 
went wrong, my assumption was lack of toleration maintenance for the new 
release.

The other thing an ADCD system is not set up for is applying maintenance (never 
mind that we cannot order any via ShopZ because our provider has the ADCD 
licence. No customer number, no ShopZ). There is no extra set of system 
residences that can be used for SMPE, so everything would go directly into the 
live system. With all the problems like linklist libraries going into extents 
that would entail. So even installing toleration maintenance would be a pain.

I was told by my predecessor that in the past they *always* had to ADRDSSU dump 
their own data, ftp them somehow to the new ADCD system and restore there. They 
went through P/390, FLEX/ES, with a stint of Hercules to ADCD at our current 
provider.

Barbara

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to