Date: Archived
Product/Release: LANSA for the AS/400 - All Releases
Abstract: An import finishes with 7 completion messages, no warnings and no fatal errors. However, no object appears to have been imported
Submitted By: LANSA Technical Support


An export and then an import are run, both jobs ending with no fatal errors. However, none of the exported objects can be found in the partition after the import has completed.

This is caused by the presence of a empty file DC@F51 in a library higher in the library list than QTEMP.

This problem usually occurs during the following (or similar) sequence of events:

Export job:

  1. Create DC@F51 in QTEMP.
  2. Write the names of the objects being exported into DC@F51.
  3. Save the objects into tape or SAVF.

Import job:

  1. Restore objects into QTEMP, including DC@F51.
  2. Loop until end of DC@F51
    read DC@F51
    get object name
    create duplicate object from QTEMP into appropriate library
    end loop

Each export creates (among others) a DC@F51 file which contains a list of the objects that are being exported. When the EXPORT runs, those objects, plus DC@F51 (and the other files: DC@F52 and DC@F53) are saved into tape or SAVF. When the IMPORT job is run, the previously saved objects are restored into QTEMP and DC@F51 is read to get the names of the objects to duplicate them in the appropriate library. Once the import has ended the file, having been created in QTEMP, disappears.

The user then looks in the partition and finds that none of the objects have been imported. The import message log is inspected and 7 completion messages are found but no warning or fatal error.

The problem could have been originated under two different scenarios:

  1. An empty DC@F51 was exported because it was found in a library other than QTEMP that was higher in the library list at the time the job was run. The list was written to that file but then QTEMP/DC@F51 was exported into the tape or SAVF with no information.
  2. An empty DC@F51 existed in a library higher in the library list than QTEMP at the time the import was run.

DC@F51 shouldn't exist anywhere at anytime except during exports and imports and ONLY in the QTEMP library (which means it automatically disappears when the LANSA export or import job completes).

If a DC@F51 file exists anywhere on your system then it:

  1. Was put there by an agent other than LANSA (eg: A programmer who manually restored something from an export/import tape and failed to clean up afterwards).
  2. Is very likely to cause a problem on exporting or importing systems (ie: An export picks up the wrong version and exports it or an import picks up the wrong version and tries to import from the object list contained in it).


To correct this problem look for object DC@F51 of type *file in all libraries.

Use the following command:


Delete any occurrences of the file and, when possible, try to determine the reason why the file was there in order to avoid the same thing happening again. To determine whether the problem was introduced by the export or the import, do the following:

When exporting into tape, use the following command:

DSPTAP DEV(<device name>) DATA(*SAVRST)

When exporting into SAVF, use the following command:

DSPSAVF FILE(<library name>/<savefile name>)

If the objects to be exported are there then it would only be necessary to run the import again making sure there is no DC@F51 in any library. Otherwise, please run the export/import again.