Forums >> Programming >> RPG Programming >>
Forcing a Signature Error (optional)




Posted:
bvstone

Forcing a Signature Error (optional)

 
Forcing a Signature Error (optional)

This next section will be optional since when we are done, we will end up with the same setup as with the previous post.

The purpose of this is to show you what a signature error will look like when it occurs.  But, in order to do that, we need to first change our binder language and then recreate our service program so that it contains only the latest signature.  In other words, we need to purposely do something wrong (which we'd never do normally).

So, first lets copy the member F.MATH in source physical file QSRVSRC to a new member called F.MATHERR (so we know this binder language will cause an error).  Then, let's remove the reference to the previous signature .  When we're done, the source for our F.MATHERR member should look like this:

             STRPGMEXP  SIGNATURE('v2.0')                       
             EXPORT     SYMBOL(#math_getSumInt)                 
             EXPORT     SYMBOL(#math_getDiffInt)                
             ENDPGMEXP                                          

Now, let's update our F.MATH service program using the F.MATTERR binder language so that when done, only one signature will be available.

UPDSRVPGM SRVPGM(ILESAMPLE/F.MATH) MODULE(ILESAMPLE/F.MATH) EXPORT(*SRCFILE) SRCFILE(ILESAMPLE/QSRVSRC) SRCMBR(F.MATHERR)

Once done, if we display the details of our service program we can verify that yes, only one signature has been exported:

                      Display Service Program Information 
                                                                 Display 1 of 1
 Service program  . . . . . . . . . . . . :   F.MATH     
   Library  . . . . . . . . . . . . . . . :     ILESAMPLE  
 Owner  . . . . . . . . . . . . . . . . . :   BVSTONE    
 Service program attribute  . . . . . . . :   RPGLE      
 Detail . . . . . . . . . . . . . . . . . :   *SIGNATURE 

                                  Signatures: 

 v2.0             

Now, if we leave things as they are, our program MATHTEST2 should run without issue since when it was created, it used the v2.0 signature.  Go ahead and run that program to verify.

Program MATHTEST was compiled when only signature v1.0 was exported.  What happens if we call that program now that our F.MATH service program doesn't export the v1.0 signature?

                        Additional Message Information 
            
Message ID . . . . . . :   MCH4431       Severity . . . . . . . :   40 
Message type . . . . . :   Escape                                   
Date sent  . . . . . . :   04/29/15      Time sent  . . . . . . :   10:02:21   
                                                                               
Message . . . . :   Program signature violation.                               
Cause . . . . . :   The source program MATHTEST specifies a signature          
  X'A5F14BF0404040404040404040404040' which is not supported by service        
  program F.MATH.                                                              
Recovery  . . . :   The service program interface has changed. Re-bind source  
  program MATHTEST.                                                            

As we can see, our program crashes and reports a signature violation error.

How could we fix this?  There really are two ways:

  1. When we update a service program that will export more or different procedures than previously, if all possible retain the old signature as type *PRV while also exporting the new signature
  2. If option 1 is not possible, then we will simply need to update our service program and then recompile any program that use our new service program so that it will use the new signature

In our case we're choosing option 1, so lets update our F.MATH service program and put it back to the state it was previously when it had exported 2 signatures:

UPDSRVPGM SRVPGM(ILESAMPLE/F.MATH) MODULE(ILESAMPLE/F.MATH) EXPORT(*SRCFILE) SRCFILE(ILESAMPLE/QSRVSRC) SRCMBR(*SRVPGM)                    

Once this is done we can verify both signatures exist in the service program and that both programs MATHTEST and MATHTEST2 will run without issue.

Next, we will look at the difference between Global and Local Variables when using subprocedures.

 


Last edited 04/29/2015 at 10:11:14


Reply




Copyright 1983-2017 BVSTools
GreenBoard(v3) Powered by the eRPG SDK, MAILTOOL Plus!, GreenTools for Google Apps, jQuery, jQuery UI, BlockUI, CKEditor and running on the IBM i (AKA AS/400, iSeries, System i).