Submit an Import Run to Batch

Submit an Import Run to Batch

When the Import objects into this partition option is selected on the Housekeeping Menu a prompt screen like this will be displayed:

This import run confirmation screen requests that details of the actual import job (which will run in batch) be specified. The details required to successfully run the import job are:

Submit batch Import or Print Contents

This field may have a value of YES, NO or PRT.

Enter YES to submit a job to batch to import details from the Save file or device file into this partition.

Enter PRT to submit a job to batch to print a report which lists the contents of the Save file or device file. The file specified must have been created by a LANSA export. This may be used to check the contents of a Save file or device file before importing.

Enter NO to cancel the job submission.

Using Job Name

Job Description

Job Queue

Output Queue

Allow Long Name Changes

The value must be YES or NO.

The default value is NO, which indicates that any long name changes in the import will cause the import to fail.

If YES is specified, then long name changes in the import will be allowed.

Allow Type Changes

The value must be YES or NO.

The default value is NO, which indicates that any field or component type changes  in the import will cause the import to fail.

If YES is specified, then field or component type changes in the import will be allowed.

Import from Tape or Optical Device Named

Use this field when you want to import objects from optical device or magnetic tape.

Specify the name of the actual optical or tape device. For instance, names like OPT01 and TAP01 are commonly used.

Using File Sequence Number/Optical file name

This field is used with the tape or optical device name to specify the file sequence number/optical file name to be used for the import of objects from tape or optical device. The default tape file sequence number is *SEARCH. The optical device name can be up to 80 characters long.

Or Import from Save File Named

Use this field if you want to import objects from a save file.

A save file is an object created and maintained by the operating system and it can be treated as if were a magnetic tape that is actually stored on disk. Refer to the operating system command CRTSAVF (create save file) in the IBM supplied manual for details about creating and manipulating save files.

Save files are commonly used in the following situations:

• When you are exporting/importing between LANSA systems that are resident on the same CPU.

• When you wish to transfer the exported objects via a communications link to another machine.

Send Messages and Inquiries to Message Queue

Specifies where any inquires or messages issued by the batch import job should be sent. The default value is the message queue associated with the workstation from which the job is being submitted. Any other valid message queue name can be specified.

Source System Type

Specifies the type of system from which the data on the CD-ROM, disk, magnetic tape or save file was originally exported. The default value is the same type of system as the one being used to import the objects. Allowable value is AS/400.

The value specified here tells the import job in what format the data on the CD-ROM, tape or disk is to be processed.

Assign New Internal Names

The value you specify here must be YES or NO.

The default value is YES, which indicates the internal object and help text pointer names associated with objects being imported should be re-assigned to prevent any possible conflict with existing internal object names within the current partition.

If the data set you are importing from was prepared on a LANSA system earlier than Version  4.0, program change (PC) level D4, you should always use the default YES option.

If your organization did not prepare the import data set, or it has been given to you by any other organization outside of your own control, you should also use the default YES option.

Use the NO option only if you had control over the preparation of the import data set, and fully understand the implications and processing changes that using this option causes.

Use of the NO option provides 3 significant benefits:

1.  The import run will execute slightly more quickly.

2.  All objects will have the same names as they did in the partition that exported them. This makes problem tracing from a production partition back to a development partition slightly easier.

3.  Processes that have been exported in compiled form can be fully imported in compiled form, ready to run. This removes the need to recompile the processes after the import run has completed (even though this is actually done automatically for you). This means that importing LANSA systems can run fully compiled processes, rather than interpretive mode processes, without having to have an RPG compiler present.

It is important that you understand what is involved in internal object naming used by LANSA, and why it can cause a conflict when the NO option is used.

Whenever an 'object' is created within a partition an 'internal' object name is assigned and allocated to it.

The final form of the name has varying prefixes and suffixes, depending upon the object type, but the name always contains a component that has a format like this:

unnnnnn

where 'u' is the 'unique prefix' assigned to the partition and 'nnnnnn' is a unique number assigned from within the partition.

This explains why you are requested to ensure that every single partition created within your organization has a different 'unique prefix'. This means that no matter which partition you choose to create an object in, you will generate a unique object name (within your organization). Thus you can probably use the NO option here without causing any problems.

Note that when you assign a 'unique prefix' to partitions in your organization you should include partitions within the same LANSA system, partitions within different LANSA systems on the same CPU, and partitions within LANSA systems located on different CPUs.

You can probably see now why you should not use the NO option when you did not prepare the import data set from within your organization. This is because the import data set might contain internal object names that duplicate the names of objects that already exist in your partition.

Once you have imported using YES, you can then export again and use NO in other partitions within your network, because the new exported data set will use internal object names that are now okay for use within all your partitions.

Important Note: If you have previously imported a process in an import run using the YES option (or before this facility was available, which is equivalent to using the YES option), and you are now going to (re)import it using the NO option, ensure that all of its associated RDML functions are also (re)imported in the same run. If you fail to do this you will find that the (re)imported compiled process may attempt to access objects by an internal name that is not correct. If this problem occurs it can be simply overcome by either recompiling the process, or by running the import run again so that all functions associated with the process are imported correctly.

This problem should only occur if your organization switches over from using the YES option to using the NO option and you forget to export all functions associated with a process.

Once you have decided on an internal organization value of YES or NO for this option, you should stick to the chosen value and avoid swapping back and forward between the values. Continual swapping will result in having to recompile processes so that they 'lock in' to the correct set of internal names for their associated functions.

Delete $$ files

The value must be YES or NO.

The default value is NO, which indicates that a $$ version of a file being imported is not automatically deleted. During import, the current version of a file to be imported is renamed to a $$ version of that file. If a $$ version already exists, a message will be issued requesting the action to be taken. A 'y' for yes, reply will delete the $$ version and complete the import of the file. A 'n', for no, reply will retain the old $$ version and not import the new file version.

A YES value for this option will automatically delete the $$ version of a file encountered in importing without issuing the message which requires a response. This option may be used if you wish to run import jobs in an unattended mode.

Where 9 and 10 character file names are not unique in their first 8 characters, a $$ version for the different file may erroneously be found to exist. It must still be deleted.

Omit Frameworks and Groups from imported data

Use this field to indicate if Frameworks and Groups for all objects in this import list are to be included or omitted from the imported data.

The default is NO.

If NO is entered, the Frameworks and Groups will be included in the imported data. In this case, the Frameworks and Groups will be available after this list is imported into a LANSA partition.

If YES is entered, the Frameworks and Groups will be omitted from the imported data. In this case, the Frameworks and Groups for all objects in the import list will not be included in the import, and will therefore not be available after this list is imported into a LANSA partition.

Default Language

This option will only appear if the current partition is a multilingual partition.

Use this field to indicate which language should be used as the default language when importing data from a non-multilingual partition. The default is the current language.

Import All Languages in Exported Data

This option will only appear if the current partition is a multilingual partition.

Use this field to indicate that all the languages that are included in the exported data are to be imported into this multilingual partition. The default is NO.

If YES is entered:

• Each language that is included in the exported data that is not currently defined in this partition will have its language definition added to this partition definition from the exported data.

• Each language that is included in the exported data that is already defined in this partition will not have its definition updated.

• Language details for all imported objects (field, files, processes, functions, etc.) will be imported for each language included in the exported data.

If YES is entered, then languages cannot be selected for the option Select Languages to be Imported or *ALL.

Select Languages to be Imported or *ALL

This option will only appear if the current partition is a multilingual partition.

Use this field to indicate which of the partition languages in the exported data should be included in the imported data. The default is *ALL.

If *ALL is entered, then all of the partition languages (which appear in the list below) will be included in the imported data if that language is included in the exported data.

If this field is left blank, then you can select the required partition languages to be included in the imported data from the list of partition languages below.

If languages are selected using this option, then YES cannot be entered for the option Import All Languages in Exported Data.

F16=Settings: displays the system setting relevant to the export and import. For details, refer to Export and Import settings. You will only be able to change these settings if you have access to the Administration Menu - Review System Settings.