× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.