× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Scott,

You've (and others) made some excellent points. I think that this discussion has pointed out some major shortcomings in the implementation on export signatures. It would be nice if IBM gave us a way to tighten up the process, maybe as a keyword in the binder source: OPTION(*LVL2).

-mark

At 10/14/09 12:05 PM, you wrote:
Hi Mark,

> 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.

So every time you add a new procedure to your service program, you
re-bind all callers. What would you do in a situation where you don't
control all callers?

Consider my HTTPAPI service program. It's used by more than 1000 shops,
all over the world. How can I rebind my callers when many of them are on
boxes I know nothing about? I could, of course, force anyone who uses
the tool to rebind when they upgrade -- but I've found that becomes a
deterrent to upgrade. People will put the upgrade off because of the
amount of work required.

Even for in-house stuff (which is a majority of my work) I find
rebinding everything to be a deterrent. When I've done that sort of
work, I found myself avoiding adding new procedures (likewise, I also
avoid adding new fields to a file) because of the extra work of
rebinding everything.

And, in shops where they don't have a good CMS in place, it might take
an hour of work just to figure out who the callers are.


> 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

Yes that's true... I can see your point of view. In a situation where
you're not using *PRV, and you WANT to rebind with every change, it
makes more sense to use (the default) SIGNATURE(*GEN)

However, my experience has been that it's much more efficient for the IT
staff to adhere to the REALLY SIMPLE rule of just adding new exports to
the end of the binder language, thus making it very easy to avoid the
need to rebind everything.

You say it's really easy to accidentally break things with that policy.
But it's very simple to just add your exports to the end. I mean, how
hard is that? It's no different from adding parameters to an existing
procedure, the programmer needs to add them at the end and make them
optional... and IBM doesn't have any sort of level check or signature
to verify *that* at all. Why is that any different?


> 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.

You do understand that the sequence of your RPG code doesn't matter at
all, right? The only sequence that matters is the sequence of data in
the binder language. Who is going to resequence the binder language?

Deleting procedures is EXTRAORDINARILY rare. It almost never happens,
and if it does, how hard is it to increase a version number?

Inserting procedures simply has to be done at the end. It's not hard,
and if you are using *PRV you have the same restriction, you must always
do it at the end, and if you don't, the system won't catch it.

So really the only time using SIGNATURE(*GEN) makes sense is when you're
doing what you are describing, Mark. When you WANT to force a re-bind
every time you add a procedure.

In my environment, that re-bind isn't practical.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 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.