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.
Subscribe to:
Post Comments (Atom)
4 comments:
useful
Hi,
I tried to replicate the signaature violation error but i didnt although the two different Signature generates. When i am calling the pgm i didnt get any erroe although i dont use Binder language.
Hi,
Useful information. I believe we can hard-code the signature as well using signature parameter during STRPGMEXP, can you please explore that feature as well with the details. Thanks/Rajesh
Thank you , it was useful
Post a Comment