1.Message file

Using Message file to display the error message in the 24th line along with the error value entered in the respective field.

In General WRKMBRPDM, when you press an invalid option in front of the member, say 22, you get the error message ‘Option 22 is not valid’. So here the system takes in the wrong value entered and displays it in the message column.

This can be done through message file.

Firstly, create a message file say MSGF1 using the CRTMSGF command.
Now you need to add a message description to this message file.
Use the ADDMSGF command for this.
You need to type a 7-length user-defined MSGID in the Message Identifier parameter
The created message file(MSGF1) and the library name are specified.

Then in the first-level message text, the error message is typed. The error value is denoted by &n where n=1,2,3 and so on. For example, here you can give
‘Option &1 is not valid’.

Optionally a second level message text can also be given which is populated when you press F1 over the first-level error.

This &1 denotes the error variable. This field’s formats need to specified in the ‘Message data field formats’ parameter where you give the datatype, length and field position. The variable which should be picked by the system to show the error and the above-declared field should be of the same datatype and length.
For instance, you declare a name field with a length 10. If someone types a number say 12345 on the name field, the error message should be ‘Option 12345 is not valid’. Here ‘12345’ is referred by &1. So both this field and the name field should be of the same datatype and length.

Now coming to the display file, you need to declare a Program-to-system field. Press F4 from the design screen and you will have a list of variables used in the program and some options to add more variable. Right down at the bottom, just above the function keys, you will have an option to add a Program-to-system field. Give the sequence number, name of the field and the length and create the field.

Now press * before the field from which the value needs to be captured. You will get the ‘Select Field Keywords’ display. Go to ‘Error messages’ option where you get two panes. Go to the bottom pane where there are 5 options to specify the ERRMSGID along with the Message file. Here you need to specify an indicator, the message identifier you created in the message file, the filename and library name and also the name of the field. Note that this name should be equal to the name of the Program-to-system field that was just declared.

The first entry will correspond to &1 in the message file description. The second entry will correspond to &2 and so on.

In the program, the code needs to be written in such a way that the indicator is switched on when a wrong value is typed. And hence the error message is displayed below.

1. Service Programs - Signature Violation Error

This is a brief explanation on how to avoid the Signature Violation Error when you add a new module to an already existing service program that is part of an executable *PGM object.


Suppose you create Modules M1, M2 and M3 with procedures P1, P2 and P3 respectively. A service Program SRVP1 is created combining these three modules. Let the main module M0 call the other three modules independently. A *PGM object with name TESTP1 is created with this main module M0 and service program SRVP1.

When you execute this program TESTP1, it works fine initially.

Now let’s say you add another module M4 and re-create the service program SRVP1 with modules M1 to M4. When you call the program TESTP1, you get this signature violation error since the signature would have changed when you re-created the service program.

To avoid this, we do the following:While you create the service program, there is this parameter EXPORT in the command CRTSRVPGM where the default option we specify is *ALL. So the service program automatically will export the exported procedures in the modules. The signature is based on this exported list of modules. When the service program is re-created with one or more additional module and related procedures, the signature also changes.

So to avoid this problem, we use another source type called the BND where you control the exported list. Create a source member with type BND in the source file say SRC1. This is reference inside the CRTSRVPGM command where the EXPORT parameter is given the value *SRCFILE. The source file, library and the binder source member name are also specified along with this in the CRTSRVPGM command.

The Binder source initially looks something like this:(Assuming that PROC1, PROC2 and PROC3 are the procedures initially that you use in your modules)
STRPGMEXP PGMLVL(*CURRENT)
EXPORT SYMBOL(PROC1)
EXPORT SYMBOL(PROC2)
EXPORT SYMBOL(PROC3)
ENDPGMEXP
Here PGMLVL(*CURRENT) means that the binder source contains the list of procedures that are currently being exported.

After creating this binder source (no need to compile it or anything), the service program is created with the parameters modified as mentioned above.

Now when you add another module and lets say it also contains a procedure PROC4, the binder source is modified as follows:
STRPGMEXP PGMLVL(*CURRENT)
EXPORT SYMBOL(PROC1)
EXPORT SYMBOL(PROC2)
EXPORT SYMBOL(PROC3)
EXPORT SYMBOL(PROC4)
ENDPGMEXP
STRPGMEXP PGMLVL(*PRV)
EXPORT SYMBOL(PROC1)
EXPORT SYMBOL(PROC2)
EXPORT SYMBOL(PROC3)
ENDPGMEXP

So the previous code is appended by just changing the parameter PGMLVL value *CURRENT to *PRV which means that this was the last exported list.And the new one with PGMLVL (*CURRENT) means that this list is the latest and the current list being exported.

After this, its enough to just re-create the service program SRVP1 with the new module added and updation of the *PGM object (TESTP1) is not needed unless you change your code in the main module M0. Now when you call the *PGM object TESTP1, you should not get the signature violation error.

Comments and updates are welcome.

Introduction

I have created this blog in view of sharing the knowledge in AS400 - RPG. Comments and updations of the blogs are most welcome.

Thanks
Mahesh