2

I have a Nomain *MODULE object to which I added a new procedure.

The *MODULE object is used to create a service program using a binder language source file which already exports a couple of other symbols (procedure names).

So question is, if I add a new procedure name, will the dependant programs need to be re-compiled?

Below is the binder language:

  ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 ...+... 9
 *************** Beginning of data ********************************************************
 STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('MAISV320111003')                                    
 /********************************************************************/                    
 /*   *MODULE      IPLMAI_PR3   IPLPGMD      11/10/03  16:03:18      */                    
 /********************************************************************/                    
   EXPORT SYMBOL("GETMAXAMENDDATETIMEFORMBRSHIPAGR")                                       
   EXPORT     SYMBOL("GETALLMBRSHPAGRBYUSGDATEANDTERRITORY")                               
   EXPORT     SYMBOL("GETMBRSHIPAGREEMENTBYIPCCLSOCRIGHTDATE")  --> newly added                           
 ENDPGMEXP                                                                                 
 ****************** End of data ***********************************************************

Would dependant objects (ones using GETMAXAMENDDATETIMEFORMBRSHIPAGR and GETALLMBRSHPAGRBYUSGDATEANDTERRITORY) need re-compilation ?

Edit: When I do a DSPSRVPGM SRVPGM(IPLPGMA/IPLMAI_SV3) DETAIL(*SIGNATURE) on the dev system, the value I see is the same as the value I see in production.. so I guess no re-compilation needed.

Theju112
  • 185
  • 7
  • You should actually make another export group marked as *CURRENT and change the old one to *PRV so your service program will have 2 signatures. Then any old programs using the old one will still work and any new ones will use the new signature. See this: https://www.fieldexit.com/forum/display?threadid=154 – bvstone Jun 19 '23 at 13:00
  • @bvstone, from what I understand, maintaining the order of the exported symbols and using a named signature value should work as needed. https://stackoverflow.com/questions/50825013/program-not-throwing-signature-violation-error-even-though-signature-id-differs So why suggest to use *current and *prv blocks if adds to complexity ? – Theju112 Jun 19 '23 at 14:19
  • 1
    You don't /have to/ make a *PRV block; you can absolutely add new exports to the end. The *PRV/*CURRENT functionality is there in case you want to know which set of exports - which signature - any particular program is bound to. Someone in your group gave the original exports a signature that /looks like/ a version. If your group doesn't track which *PGM is using what version, treat that signature as though it has no meaning. – Buck Calabro Jun 19 '23 at 15:21
  • @BuckCalabro, Thanks Buck.. so could you confirm about my original question? I hope no re-compiling would be needed when adding new procedure names ? – Theju112 Jun 19 '23 at 15:26
  • @theju112 I do it mainly for documentation to know how the service program has evolved. I use my own hard coded signatures (it, v1.0, v2.0, etc). If you let the system create the signature adding new functions WILL change the signature. – bvstone Jun 19 '23 at 19:08
  • Since the STRPGMEXP specifies a specific signature, when you recreate the service program, that service program will keep the same signature. Since all of the *PGM objects already have that signature (DSPPGM will verify this) , you won't need to recompile the *PGM objects - for the purpose of avoiding a signature violation. If one of those *PGMs needs to use the new sub-procedure, it will need to be compiled :-) – Buck Calabro Jun 20 '23 at 14:53

1 Answers1

4

Current best practices...

  • Use Binder source to export specific procedures during CRTSRVPGM
  • Use a hardcoded unchanging signature unless you want to force recompiles
  • Add new procedures at the end of the binder source

In order to not need to force a recompile of all callers

  • don't modify order of procedures in the binder source
  • don't add new parms to existing procedures without option(*NOPASS)
  • don't change the size, types, order of any procedure parameters.

It seems you've followed the above, so you should be good.

You could use *PRV and *CURRENT blocks (usually with a SIGNATURE(*GEN)), but it's extraneous noise that doesn't provide any additional value over the above.

If you're new to ILE I highly recommend taking a look at Scott Klement's ILE Concepts (For the Impatient RPG Programmer).

Charles
  • 21,637
  • 1
  • 20
  • 44
  • thanks for the detailed answer as always! So, I conclude no re-compiles needed in my case as I am merely adding a new procedure name at the end of the binder language. I am not touching the existing procedures and the signature name is hardcoded. But one additional question, when I do a DSPSRVPGM DETAIL(*SIGNATURE) , I see a long alpha numeric string.. not the name specified.. is that always a system generated value regardless of the signature name hardcoded in the binder language? – Theju112 Jun 19 '23 at 15:58
  • 2
    @Theju112 It defaults to a hexadecimal representation, since system generated signatures don't have a valid character view. Use `F11=Display character signature`. – Charles Jun 19 '23 at 19:11