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