RE: Directory entries

Will do. I'm working on it now, while I wait for the polyurethane on my
wife's new office doors to dry. :-))

Paul Nelson
Office 512-392-2577
Cell 708-670-6978
nelsonp@xxxxxxxxxxxxx


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Sunday, January 20, 2008 2:28 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Directory entries

Please use ADDDIRE. There may be an existing CLP documented; there
was such a CLP for ADDRDBDIRE to effect migration of its directory
entries. If further interested as to why I suggest...

Wanting 'everything brought over "as is"' seems like the scenario was
supposed to be a system [data] migration. If so, having performed that
would have been the best way to migrate to the new system. Although the
request to CPYF FROMFILE(YourLib/&QAOKname) TOFILE(QUSRSYS/&QAOKname)
FROMMBR(*ALL) TOMBR(*FROMMBR) FMTOP(*MAP *DROP) MBROPT(*ADD) FROMRCD(1)
TORCD(*END) ERRLVL(0) COMPRESS(*YES) for the physical files QAOK* is
probably safe, please consider the following:

The documented migration scenarios exist to generically handle such
concerns across many more than just the QAOK* files. So it is best to
use a documented migration scenario instead of trying to perform some
short cuts or tricks. The documented method to add directory entries is
the ADDDIRE command, and so as Simon suggests with using DSPDIRE
USRID(*ALL) OUTPUT(*OUTFILE) and then run the corresponding ADDIRE from
that information on the other system [e.g. in a CLP doing RCVF on the
restored output file] is _the appropriate method_ to migrate that data,
outside of expected data migration path. And as was alluded [or stated
also], the CPYF FMTOPT(*MAP *DROP) [for the physical files of the
feature] is probably generally safe given the files and code levels
match. Since the function is probably seldom PTFed being support of
long-existing features, that is probably not as much of a concern. A
restore option would be effectively MBROPT(*REPLACE), if even properly
performed; i.e. with ALWOBJDIF(*ALL), the outcome is very possibly going
to effect a situation requiring repair of the database relationships.
For restore to work in such a migration, the documented method is to
start with the empty QUSRSYS and restore the user data from the prior
system, and then install to upgrade [even to the same release] the QUSRSYS.

The *big problem* in performing a copy or restore function versus
supported migration or add, is in the _assumption_ that the action is
going to be valid in the given situation. For example even the decision
of using either MBROPT(*ADD) or MBROPT(*REPLACE) could be either
acceptable or problematic. Without also knowing the consequences to the
code for having performed the copy, and what other files might be
related such that those other files may need to be copied as well, the
action outside of ADDDIRE might be problematic. There are likely not
any files outside of the QAOK*, but what if some QA* files have some
inherent _relationship_ as required by the code, but not defined in the
database itself. For example there are other files that are at least
somewhat related, for which if those files did not similarly exist with
data in such a migration, the system might be considered incomplete or
even in error; e.g. the data missing fro QASN* for SNA/DS are very
directly related to the directory entry files. The unfortunate part for
some customers is that even with an apparent sanity check of the results
of such actions, for example WRKDIRE seems to show data [if even checked
at all, or if even possibly to additionally confirm ADDDIRE does not
appear to fail], the remaining difficulties may only be found later...
after the work was long since completed and little record of what
transpired remains, to assist in its resolution.

Some commands which might be considered at least somewhat related,
for which their own database files or other storage may have an
associated ADD* command that might have value in having a similar CLP to
migrate:
ADDDSTLE ADDDSTQ ADDDSTRTE ADDDSTSYSN ADDNETJOBE

Regards, Chuck