Re: Best way of using Service programs.

On 2/15/06, Mike Tobey <Mike.Tobey@xxxxxxxxxxxxxxxxx> wrote:
>
> >You have to add the new exports to the end of your binding source.
> >Which screws up your attempt to use your binding source member as a
> handy service program reference sheet.
>
> I don't see how updating the binding source screws up anything.  We
> assign signatures for each change that hold the version and date.

I was doing that and thought the system would map the export numbers
from the *PRV STRPGMEXP group to the current, actual exports of the
service program. It didnt work for me. When you insert a new export
into a list of exports in the binding source:

 STRPGMEXP  PGMLVL(*CURRENT)   Signature('FEB14_2006')

 EXPORT     SYMBOL('Customer_CreateNew')
 EXPORT     SYMBOL('Customer_GetAddress')

/* new GetName procedure   */
 EXPORT     SYMBOL('Customer_GetName')

 EXPORT     SYMBOL('Customer_PrintInfo')
 Export   symbol('Order_Delete')
 Export   symbol('Order_Display')
 export   symbol('Order_Print')

ENDPGMEXP

STRPGMEXP  PGMLVL(*prv)   Signature('JAN08_2006')

 EXPORT     SYMBOL('Customer_CreateNew')
 EXPORT     SYMBOL('Customer_GetAddress')
 EXPORT     SYMBOL('Customer_PrintInfo')
 Export   symbol('Order_Delete')
 Export   symbol('Order_Display')
 export   symbol('Order_Print')

ENDPGMEXP

the export number of all the exports that follow the new added
procedure are changed. This means that when a program calls export
number 5 in the service program, what once was a call to the
"Order_Display" procedure could now be the "Order_Delete" procedure. 
If you have been assigning *PRV and *CURRENT signatures, your code
will not get a signature violation, but it will call the wrong
procedure and hopefully get a decimal data error before it does some
damage.

-Steve