Re: Processes after CRTSRVPGM

["M. Lazarus" <mlazarus@xxxxxxxx>]

Buck,

 If you would have the ability to directly set the level ID on a 
file, would you?  In the vast majority of cases, of course 
not!  Because the system knows to generate a new level ID / signature 
*automatically* when a significant attribute changes.

 Why wouldn't you want similar protection for binder signatures?  I 
think that signatures fall short as it is (no sig change if the 
attribute changes, etc.), why would you want to short change it even more?

 -mark


At 2/13/08 03:54 PM, you wrote:
> Adam Glauser wrote:
> > M. Lazarus wrote:
> >> Lim,
> >>
> >> [Specifying SIGNATURE on STRPGMEXP] tells the system that you are
> >  >  managing the signatures.
> >> This is almost the equivalent of setting LVLCHK(*NO) on your files.
> >> It gets rid of the error message, but also disables the error checking!
> >
> > That's a bit of a stretch in my opinion.  It's true that specifying a
> > signature can cause problems.  However, I think it's quite a bit simpler
> > to recreate or update a service program safely while overriding the
> > safety measures than it is to add a field to a file with LVLCHK(*NO)
> > without causing problems.
>
> I agree with Adam.  I think the difference is that with files, there is
> no *PRV support, whereas with binder language, we can successfully use a
> newly compiled service program with an old calling program.
>
> I have a strong tendency to make my signatures look like strpgmexp
> pgmlvl(*current) signature('01.02 20071019').  When I do a DSPPGM I can
> immediately see what version of a service program it's bound to.
>
> The caveat, of course, is that one must add new exports AFTER existing
> exports or the calling program will call the wrong procedure without a
> signature violation.
>    --buck