Re: Service programs and QSRVSRC

Mark,

As I see it, you really aren't arguing for system generated signatures
in place of hardcoded ones.

What you're arguing for is the rebinding of anything that makes use of
a changed service program.

I suppose I could agree that with a decent CMS, rebinding is not
particularly difficult, maybe a little safer and thus as long as
you're not a vendor of software may not be a bad idea.

However, as I see it, at least with Aldon CMS, I can't just simply
rebind, I'd have to recompile and thing that used the service program.
Which would mean that I should probably regression test everything as
well. Even if I could just rebind, the rebind is still a change and
thus you should probably still regression test everything.

If however, through the use of *PRV blocks and a system signature or
the use of a hardcoded signature, the only object actually changed is
the service program itself, then the only object that needs to be
tested is the service program. If screwing up the exports is that big
of a concern, it wouldn't be to hard to have a unit test program or
some other means of ensuring that the exports are all right.


If you're not rebinding, the system signatures and *PRV blocks are
more work with no added benefit vs. hard coded signatures.

Charles


On Tue, Oct 13, 2009 at 12:16 PM, M. Lazarus <mlazarus@xxxxxxxx> wrote:

Scott,

 It may be that our usage and environments are different, so for you
the automatic sig generation provides nothing.

  Normally, when I create/release a *SRVPGM I don't use *PRV
blocks.  In the rare case I need it, it's a deliberate
decision.  Therefore, if I were to use a hardcoded sig and I rebuilt
the *SRVPGM with a new export sequence, but neglected to manually
change the sig, I would probably be getting some unexpected results.

 These are "gotcha" errors that may or may not be found in testing,
since an already tested part of the code might not get
re-tested.  Since there was a resequenced/inserted/deleted export
list, it won't work properly.  Of course, I think it's a really bad
idea, for this reason, to do that.

 The bottom line is, if you are using *PRV as a matter of course for
all past versions, then a system generated sig probably won't do much
for you.  But the way I usually use them, it's useful.  I
experimented with a manual sig a while back and got bitten with the
program finding the wrong export when the sig was accidentally not
changed for the new version.  An automatically generated sig would
have caused an error to be thrown right away when the program got
activated during testing.

 It's not much, but given the loose/poor implementation it's better
than nothing.

 -mark


At 10/13/09 01:11 AM, you wrote:

M. Lazarus wrote:

  I don't think that many people like the way that service program
signatures have been implemented, but specifying your own removes
what little protection it does give.  It's way too easy to overlook
changing the signature when a service program is regenerated.

Why aren't you answering my question?  WHAT protection does the system
provide you?  HOW are you recommending that I code my SRVPGM that will
solve this problem?

Are you suggesting using STRPGMEXP PGMLVL(*CURRENT) with no *PRV blocks?
  Is that the method you recommend?  Or what method do you recommend?

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.