You are here: LANSA for i User Guide > 9. Developer Services > 9.9 Import Developer Messages > 9.9.1 Steps Required to Import Developer Messages

9.9.1 Steps Required to Import Developer Messages

The basic requirements to ensure an IMPORTMSGS job completes normally is that the two import developer message files that contain the developer message header and text details are resident in the import library on the system where the IMPORTMSGS job will execute.

These examples provide some examples on how to ensure the import developer messages files are resident in the import library before the IMPORTMSGS is executed:

Example 1

If the import developer message files are to be restored using a tape or diskette device, perform the following IBM i Control Language command:

RSTOBJ OBJ(AAAAAAAAAA BBBBBBBBBB)

       LIB(CCCCCCCCCC) DEV(DDDDDDDDDD) 

       OBJTYPE(*FILE) RSTLIB(EEEEEEEEEE)

replacing:

'AAAAAAAAAA' with the name of the file which contains developer message header details were saved.

'BBBBBBBBBB' with the name of the file which contains developer message text details were saved.

'CCCCCCCCCC' with the name of the library where the developer message files were saved.

'DDDDDDDDDD' with the name of the device where the developer message files will be restored from.

'EEEEEEEEEE' with the name of the library where the developer message files are to be restored.

Example 2

If the developer message files have been sent from another system using SNADS, you will need to perform the following IBM i Control Language commands so that the developer message files can be received ready for import:

Before the developer message files can be imported a duplicate of two internal LANSA files must be made before the files can be received:

CRTDUPOBJ OBJ(DC@F83) FROMLIB(AAAAAAAAAA) 

          OBJTYPE(*FILE) TOLIB(BBBBBBBBBB) 

          NEWOBJ(CCCCCCCCCC)

replacing:

'AAAAAAAAAA' with the name of the LANSA system data library where DC@F83 is resident. DC@F83 is an internal file within LANSA which stores developer message header LOG records.

'BBBBBBBBBB' with the name of the library where the duplicate of DC@F83 is to be created. The library name specified here should be the name of the import library where the developer message files will reside.

'CCCCCCCCCC' with the name of the file which will contain the imported developer message header detail records to be used in the IMPORTMSGS job.

 

CRTDUPOBJ OBJ(DC@F84) FROMLIB(AAAAAAAAAA) 

          OBJTYPE(*FILE) TOLIB(BBBBBBBBBB) 

          NEWOBJ(CCCCCCCCCC)

Replace:

'AAAAAAAAAA' with the name of the LANSA system data library where DC@F84 is resident. DC@F84 is an internal file within LANSA which stores developer message text LOG records.

'BBBBBBBBBB' with the name of the library where the duplicate of DC@F84 is to be created. The library name specified here should be the name of the import library where the developer message files will reside.

'CCCCCCCCCC' with the name of the file which will contain the imported developer message text detail records to be used in the IMPORTMSGS job.

When duplicates of DC@F83 and DC@F84 have been created, the developer message files can be received:

RCVNETF FROMFILE(AAAAAAAAAA) 

        TOFILE(CCCCCCCCCC/BBBBBBBBBB) 

        MBROPT(*REPLACE)

replace:

'AAAAAAAAAA' with the name of the file which has been sent from an external system containing the developer message header detail records to be imported.

'BBBBBBBBBB' with the name of the file which will receive the developer message header detail records to be imported. The file name specified here should be the name of the import file that will be used in the IMPORTMSGS job containing the developer message header detail records.

'CCCCCCCCCC' with the name of the library where the developer message header file to be used in the IMPORTMSGS job will be resident.

then:

RCVNETF FROMFILE(AAAAAAAAAA)

        TOFILE(CCCCCCCCCC/BBBBBBBBBB) 

        MBROPT(*REPLACE)

replace:

'AAAAAAAAAA' with the name of the file which has been sent from an external system containing the developer message text detail records to be imported.

'BBBBBBBBBB' with the name of the file which will receive the developer message text detail records to be imported. The file name specified here should be the name of the import file that will be used in the IMPORTMSGS job containing the developer message text detail records.

'CCCCCCCCCC' with the name of the library where the developer message text file to be used in the IMPORTMSGS job will be resident.

To Import Developer Messages perform the following command:

LANSA REQUEST(IMPORTMSGS) 

      PARM01(AAAAAAAAAA) 

      PARM02(BBBBBBBBBB) 

      PARM03(CCCCCCCCCC)

Replacing:

'AAAAAAAAAA' in PARM01 with the name of the file that contains the developer message header details to be imported. Use UPPERCASE characters only.

'BBBBBBBBBB' in PARM02 with the name of the file that contains the developer message text details to be imported. Use UPPERCASE characters only.

'CCCCCCCCCC' in PARM03 with the name of the library where the developer message files to be imported are resident. Use UPPERCASE characters only.

 

For example, the following command:

LANSA REQUEST(IMPORTMSGS) PARM01(MSGFIL1)

      PARM02(MSGFIL2) PARM03(IMPLIB)

will result in all the developer messages within the two import developer message files "MSGFIL1" and "MSGFIL2" in library "IMPLIB" being imported/merged into the "real" developer message files in the current LANSA system where the IMPORTMSGS job has taken place.

If a new developer message has been imported/merged into the "real" developer message files and the send message flag for the category code that applies to the developer message is set to "Y", then the developer message will be sent to the user who the message is intended for by the user defined "send developer message" program.

The complete IMPORTMSGS procedure can be performed manually, but it is recommended that this procedure be executed within an IBM i Control Language program.

If LANSA/MESSAGES is being run in a multi-machine environment it is recommended that the IMPORTMSGS job should be executed on a daily basis as part of a start of day/day end procedure.