The following things about importing should be noted before attempting to import objects into another system:
A Report Is Produced Which Details Each Step of the Import Job
The report takes the form of a series of messages that are listed on the report. Each message has a unique identifying number, a type (completion, warning or fatal) and a line of text that describes what event took place.
At the end of the report a summary of the number of completion, warning and fatal messages issued during the import job is printed on the report.
If any fatal message is issued the imported data may be unusable. In this case, investigate the fatal messages on the report, correct the cause and attempt the import operation again.
An example of fatal error would be an error on tape drive that occurred while attempting to read from the tape.
When one or more fatal messages are issued the import job will end abnormally (as indicated by the operating system message sent back to the submitting workstation).
If any warning message is issued the imported data is usable, but may not be in exactly the form you expected. In this case, investigate all warning messages on the report and decide whether you have to correct a problem and run the import job again.
When one or more warning messages are issued the import job will still end normally (as indicated by the operating system message sent back to the submitting workstation).
When the Import Job Is Submitted From a Workstation
When the import job is submitted from a workstation, a summary message will be sent back to the workstation at job completion indicating the number of completion, warning and fatal messages issued by the job (as per the summary lines at the end of the import report).
Mounting of Tapes and CD-ROMs before Importing
It is advisable to mount any tapes or CD-ROMs to be used before commencing the import job. The most common import problems involve tape or CD-ROM handling.
Replying to Inquiry Messages
The person who prepared the data being imported may have set it up so that a number of questions must be answered just after the import job commences execution (refer to Define Substitution Variables Used in a List for details).
These questions are sent to the message queue nominated when the import job was submitted as a series of inquiry messages.
When one arrives it has to be answered within one hour of arrival. Until an answer is given the import job is suspended and may hold up other jobs waiting to execute. If an import job appears to be suspended (i.e. it is doing nothing and not using any system resources) then it is probably waiting for a reply to an inquiry.
These inquiry messages take two forms (depending upon how the exporter set them up):
1. Some messages have a default reply that the exporter thought might be correct in most situations. The default reply is shown to you in the message text, and by replying with an (asterisk) you can indicate that the default reply should be used. Otherwise you can override the default with a specific reply of your own.
2. Other messages do not have a default reply. In this case you must provided a specific reply of your own.
Whenever you are making a specific reply of your own, check what you have replied very carefully before pressing the enter key. Almost no effective validation of your reply can be done by LANSA. An incorrect reply can completely ruin an import run and require that it be run again.
All replies are automatically converted to uppercase before being processed by LANSA, so it does not matter whether your reply is in uppercase or lowercase, or a mixture of both.
If you are unsure of exactly what to reply to an inquiry, contact someone who does know before entering any reply.
Having to reply to inquiry messages may not be necessary.
Refer to Avoid Large Export Lists in Exporting Objects - Tips and Techniques for details of how import messages can be avoided by having the person who prepares the export lists pre-define the answers.
Minimize Operating System Security Interference
The LANSA export and import facilities make use of IBM i operating system features to save and restore data.
This area of the operating system is subject to a large number of operating system security checks. The continual interference of such checks in your export/import job may confuse you and seem to indicate that the LANSA export/import facilities are not working correctly.
To avoid this situation, it is recommended that you run all export and import jobs under a user profile that is the operating system security officer QSECOFR, or, part of the system security officer group, or at the very least, has special authority *SAVSYS allowed.
The Result Area DC@RESLT In QTEMP Is Set By an Import Job
This data area, which is created after some LANSA operations complete, can be accessed by other programs to test the result of the attempted import operation.
Refer to the DC@RESLT Data Area for details of this data area and what it contains.
If Export Run Used 'Omit RDML Code' Proceed With Caution
If the export run used to prepare the data set that you are about to import from used the 'Omit RDML Code' option, proceed with extreme caution.
New functions will be imported with no associated RDML source code. Replacement versions of existing functions will also be imported with no source code. Any existing RDML source code will be deleted during the import run (to maintain compatibility).
Using this feature presents a major recovery hazard unless proper system backups are kept.
Use the NO Answer for 'Assign New Internal Names' with Caution
Only use the NO answer to the 'Assign new internal names' option on the import prompt (or direct call interface) if you understand the complete implications of this feature. Refer to Assign New Internal Names for details.
Importing of Export Lists - Resetting of entries
When an export list is imported into a partition, LANSA will check if the object referenced on each list entry exists in the partition. If the object is found, the library field of the entry will be reset to reflect the current partition and a warning message is printed on the Import run listing.
CCSID Data Conversion
On systems that have QCCSID (Coded Character Set Identifier) and QLANGID (Language) parameters set to non-standard (not default) values, imported data will be converted according to the default CCSID of the QLANGID parameter and not the QCCSID of the system.
QCCSID = 00500 (international code page)
QLANGID = CAT (Catalan)
The default CCSID for CAT (Catalan) is 00284. Therefore, all data will be converted to code page 284 and not code page 500, the QCCID value.
Multilingual Considerations for WAMs and Weblets
WAMs and Weblets have published documents. These documents are published for each Technology Service and partition language combination. If the export doesn't have published documents for the importing partition's default language, then the import program will copy (if available) the published documents from the export's default language into the importing partition's default language.
For example, if your exporting partition has language ENG as the default language and your importing partition has language FRA as the default language, if the export doesn't include language FRA, then the ENG documents are copied into documents for language FRA. This ensures that you have published documents for your partition's default language. The FRA documents are then copied to populate the other importing partition's languages for which published documents are not available.
When IFS Objects are imported, the current job user will be changed to the system owner and once the IFS Objects processing is complete the current user will be re-instated.
If for the authority reasons, the current user cannot be changed to the system owner, the IFS Object's owner will be the current job user. If this is not correct you might have to change the owner of these to the system owner or to whatever owner required.