Re: Processes after CRTSRVPGM

Mark,

The signature on a service program does NOT work like a level check on a file. Using *CURRENT/*PRV with a generated signature does NOT detect ANY additional errors over using a hard-coded signature.

If you're using a *CURRENT block *WITHOUT* using a *PRV block (but still using a generated signature) then it does offer some protection, but throws away one of the biggest values of ILE -- because now every time you change the procedures that are exported from the service program, you have to recompile everything.

There's no value to using *CURRENT/*PRV. If you disagree, please outline a situation where it'd protect you, but a hard-coded signature wouldn't.



M. Lazarus wrote:

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