If you’re not making use of signatures, why are you using binder language? Is this simply testing?

Note that updating binder language has no effect other than a form of personal documentation until the service program is created or updated with reference to a binding language source member. The reference is through the EXPORT(), SRCFILE() and SRCMBR() parameters on CRTSRVPGM or UPDSRVPGM.

Tom

Thanks Tom, till now I’m clear. But here, where the signature is useful?
Actually I studied some information through net, and it says that signature is used to let system know that procedures list has been changed. however if we are running the UPDSRVPGM or CRPSRVPGM in that case whats the exact scope/purpose of signatures…..
“As I studied that if the signatures are not properly maintained, the result of calling procedures in binder language shows invalid results” and I’d like to see how the problem happens….
EX: I have two modules Mod_Add, Mod_Sub and written the Binder lang as
Export SYMBOL(Proc_Add)
Export SYMBOL(Proc_SUB)
I used the service pgm and got the correct results, now I changed the order
Export SYMBOL(Proc_Sub)
Export SYMBOL(Proc_Add)
then how can I get the incorrect results. As I know that symbloic links are maintained when referring through binder lang.

Yes Tom, I’m just trying to find out the importance of signature with a simple example. so can you explain me a bit clear

Scott Klement wrote a good article on this topic: Binder Language and the Signature Debate. Check it out at systeminetwork.com. It contains lots of good info and insights.

I have two modules Mod_Add, Mod_Sub and written the Binder lang as
Export SYMBOL(Proc_Add)
Export SYMBOL(Proc_SUB)
I used the service pgm and got the correct results, now I changed the order
Export SYMBOL(Proc_Sub)
Export SYMBOL(Proc_Add)

What your STRPGMEXP statement look like? The LVLCHK() and SIGNATURE() parms will predict results.

You have changed the order of the procedures. They will be represented by two procedure pointers. In the first case, the first proc pointer points to Proc_Add. In the second case, it points to Proc_Sub. If you call a program that accesses the first proc pointer, it will get a different procedure under the two cases.

The procedures are not accessed by name once the program is compiled; the binding results in procedure pointers being used. If you switch them around without providing signatures, your program will get confused.

You assign signatures to different sets of exports. Each signature labels the exports. When your program is compiled, the signature becomes part of the program. Then when it runs, the signature is used to locate which set of exports is appropriate for that program.

You would normally add a new signature if you added a procedure. You might add Proc_Divide, for example. You would add a new STRPGMEXP statement with a new signature, and put the new exports after it. That way, old programs that had the old signature would match the first STRPGMEXP statement, and new programs that requested the new Proc_Divide procedure would locate the new signature and get compiled with it.

But if your STRPGMEXP statement does not specify a signature, one will be generated. It will be based on something like a hash of the exports. This is kind of like how a file’s ‘format level’ gets generated and compiled into programs. A format level check against a file is like a signature check against a service program.

There are two significant differences. You can specify your own signatures, and a service program can have more than just one.

If a file’s format level changes, old programs can’t use the file until they’re recompiled. But you are able to add signatures to service programs. As long as previous signatures are left in place, old programs will continue to work without recompiling.

Tom