Re: Service programs and QSRVSRC

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

Scott,

 Isn't managing your own signature (almost) the equivalent of doing 
LVLCHK(*NO)?  If you change the export sequence or add/delete one in 
the middle, there's no protection from using an version, if you 
forget to manually change the signature!

 Why does this technique seem to be the preferred method?  It might 
be nice to see a version in the export, but there are other ways to 
accomplish that (put it in the copyright statement or in the object 
description) without losing the signature protection.

 -mark


At 10/9/09 07:29 PM, you wrote:
> I don't change the version number unless I do something unusual, like
> remove an exported procedure.  (IOW, The version number is just the
> version of the signature, not the version of the product.)
>
> I was not referring to IBM generating the signature *for*you*, I was
> specifically replying to what Vern said.
>
> Vern was noting that IBM does this:
>
>    STRPGMEXP SIGNATURE('srvpgmname')
>
> I was suggesting that this is better:
>
>    STRPGMEXP SIGNATURE('srvpgmname 01.00')
>
> Because you can (if you want to) CHOOSE to break compatibility when you
> want to introduce an incompatible feature.
>
> You, on the other hand, are talking about coding
>
>    STRPGMEXP PGMLVL(*CURRENT)
> -and-
>    STRPGMEXP PGMLVL(*PRV)
> -and-
>    STRPGMEXP PGMLVL(*PRV)
> -and-
>    STRPGMEXP PGMLVL(*PRV)
> -and-
>    STRPGMEXP PGMLVL(*PRV)
> -and so on for every previous version-
>
> That's a whole different discussion, which we can have (for the
> umpteenth time) if you want... but I wanted to be clear that wasn't what
> I was referring to in my previous message.
>
>
> Kurt Anderson wrote:
> > If you retained the old signatures within the binder source and
> > didn't make a change that required them to recompile the programs as
> > well (e.g. a parameter change to an existing procedure), then there's
> > no need to make them recompile to use the new version number.