×

Good News Everybody!

The new search engine is LIVE!

Please report any problems to david (at) midrange.com.




Barbara,

This is actually the way we do it, we hardcode package name and release # in
the signatures of all our service programs. I'm still not quite sure whether
this is preferable over using LVLCHK(*NO); we have the possibility of
deliberately changing the signature, but I wonder if we'll ever do that. The
only reason I can think of is that at some point in time we will want to
clean up; removing obsolete procedures. In the mean time additions go to the
end of the list; changing parameter lists can be handled either by adding
optional parameters or creating new versions of procedures as described in
the ILE Concepts Guide.

Joep Beckeringh

----- Original Message -----
From: "Barbara Morris" <bmorris@xxxxxxxxxx>
To: <rpg400-l@xxxxxxxxxxxx>
Sent: Thursday, June 19, 2003 7:48 PM
Subject: Re: binder language, binding directories, bind by copy/reference


> Given that you have to keep the procedures in the same order in all the
> lists, why is the *CURRENT/*PRV method preferred over the hard-coded
> signature method?
>
> For example, this might be your entire binder source when using a
> hardcoded signature:
>
> signature('SRVPGMNAM')
>   procA
>   procB
>   procC
>   procB2
>
> This would be your entire binder source when using *CURRENT / *PRV
>
> signature(*current)
>   procA
>   procB
>   procC
>   procB2
>
> signature(*prv)
>   procA
>   procB
>   procC
>
> signature(*prv)
>   procA
>   procB
>
> I just don't see the attraction of the second one.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.