The following things about exporting should be noted before attempting to export objects to another system:
Exporting and Importing between RDML and RDMLX partitions
A Report Is Produced Which Details Each Step of the Export 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 export job is printed on the report.
If any fatal message is issued the exported data is unusable (regardless of whether or not anything was actually written out onto the tape or disk). In this case, investigate the fatal messages on the report, correct the cause and attempt the export operation again.
An example of a fatal error would be an error on the tape drive that occurred while attempting to write to the tape.
When one or more fatal messages are issued the export job will end abnormally (as indicated by the operating system message sent back to the submitting workstation).
If any warning message is issued the exported 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 export job again.
An example of a warning message would be that you requested a certain RDML function be exported in compiled form, but the function is not currently compiled.
When one or more warning messages are issued the export job will still end normally (as indicated by the operating system message sent back to the submitting workstation).
When the Export Job Is Submitted from a Workstation
When the export 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 export report).
The Format of Tapes / Disks
The format of tapes / disks used varies with the source (i.e. exporting) and target (i.e. importing ) system types. Currently only the IBM i is supported for exports via tapes as per the following table:
|
Transfer of Programs in Compiled Form
Some restrictions to the export / import of programs in compiled form apply as shown in the following table. The term 'observable' refers to a program that has all its symbolic debug information intact. In LANSA terms an 'observable' RDML function or I/O module is one that is compiled to be 'debug capable'.
In copying from on RISC system to another, observable or non-observable will be subject to operating system release compatibility.
Clearing/Initializing Tapes and Disks Before Exporting
It is advisable to clear any tapes or disks to be used before commencing the export job. The most common export problems involve un-cleared or uninitialized tapes or disks.
Operating system commands are used to initialize and/or clear tapes and disks. Refer to the commands INZTAP, CLRDKT and INZDKT in the IBM supplied operating system manuals for details.
Re-Running Import Jobs
The need to re-run an import job on a target system is a distinct possibility. Machine failures and incorrect replies to inquiry messages guarantee that from time to time an import job will have to be re-run.
As such, all the logic used by LANSA to import fields, files, processes and functions has been designed so that it can be easily re-run with no specific actions required by the importer other than to start the job executing again.
This factor should be taken into account when adding other / non-LANSA objects to an export list and any accompanying operating system commands to be executed before or after the import run. When taking any action with an operating system command, consider how the command will react if it has already been executed in a previous run of the import job.
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 Export 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 export operation.
Refer to the DC@RESLT Data Area for details of this data area and what it contains.
Use the 'Omit RDML Code' Option with Extreme Caution
Clearly mark all tapes with 'Import will delete source code'.
To reduce the amount of time taken to investigate and re-run an export job in error, limit the size of export lists where ever possible, for example when exporting a whole partition set up a separate export list for each object type opposed to one export list for the whole partition:
|
LIST01 |
All fields in a partition |
|
LIST02 |
All files in a partition |
|
LIST03 |
All processes and functions in a partition |
To avoid large export lists it is recommended that you set up and run numerous medium sized export jobs opposed to 1 very large export job.
This tip has added significance when the target system type is PC. When importing into LANSA, the SQL database does not commit the data until the end of the import operation. Therefore large imports require large amounts of disk storage, and the import may 'crash' if insufficient storage was previously allocated. For example, if you were 1 hour into a large import and the import failed, resulting in all the data being backed out - you would have to run the whole import again.
Multilingual Considerations for WAMs and Weblets
WAMs and Weblets have published documents. These documents are published for each Technology Service and partition language combination. On IBM i, published documents are exported together with the repository details. You should always export the default language, as it is used during import if you are not exporting the importing partition default language.
Example of 'Other' Object Export
Since the LANSA export/import facilities support the transfer of non-LANSA objects between systems, you may specify user defined IBM i operating system commands which can be executed as part of the import job. Typical examples would be the transfer of objects such as message files, non-LANSA created database files and programs.
This is an example of the types of commands that would most likely be executed before and after an import of these non-LANSA objects:
|
The above commands will delete the message file and program and rename the database file before the import, and then copy file the data from the old file to the imported file after the import.
All of the actions are executed automatically for you by Import when dealing with LANSA objects.
Avoiding Inquiry Message to the Operator When Importing
Every export list contains one special substitution variable called $$DTALIB$$ which cannot be deleted. This is the default variable used by LANSA when importing file definitions into any system.
If you don't want the associated 'question' to be asked on import, then you should provide a literal (e.g.: QGPL) or system variable name (e.g.: *PARTDTALIB) as the default value, and set 'Prompt user when Importing' to 'N' for the $$DTALIB$$ substitution variable.
This approach can be applied to any substitution variable that you have defined in an export list.
When the target system for an export is PC the file library details must be provided as follows:
Requests to 'Prompt user when Importing' will be ignored when importing to PC.
