John, Charles and Mark:
The ideas put forth are all "good" ... but we can never achieve any real
"guarantees" when you pass a procedure pointer, at run-time, that it
will actually point to a procedure that actually "matches" the
definition used at "compile-time" ... at least, within the confines of
the current ILE architecture, such as it is.
I think what is really needed is that the ILE "signature" mechanism
should take into consideration not only the sequence and names of the
procedures themselves, but also their parameters (or argument lists).
This can be done in much the same way that the database generates the
"Record Format Level ID" by computing a "hash" of the list of fields,
considering their types, lengths, etc. (but not the actual field names)
-- I can envision a similar algorithm to process "parameter lists" in
much the same way.
This could be added in an "upwards compatible" manner by providing a new
option on the "binding" commands, e.g. CRTPGM, CRTSRVPGM,, UPDPGM and
UPDSRVPGM, or perhaps new options within the "binder source"
The "big idea" would be to compute this "hash code" for each procedure,
and when you have more than one procedure in a *MODULE or *SRVPGM, we
can "exclusive or" (XOR) these signatures together to create a
"composite" signature for the entire module or service program. The
main idea is, we want to be able to detect, at runtime, a "signature
violation" in essentially the same way that IBM i does this today.
This may not be a "perfect" solution, but it is certainly far better
than what we have today. Today, you rely on the compiler checking, but
that can easily be "fooled" for example if you change the definition of
one or more parameters, or add a parameter, and you "forget" to change
the /COPY or /INCLUDE member for that procedure. Or, you did change the
include member, but then you failed to hunt down and recompile each and
every source member that "includes" this copy book member. In such
cases, the IBM i or OS/400 system provides "no guarantees" as to exactly
what will happen at runtime, if you happen to call a separately compiled
procedure (either bound into your *PGM or boind in another *SRVPGM), and
you pass a parameter list that is somehow "different" than what was
"expected" (at compile time).
With the situation we have today, if this sort of thing happens, the
results can be relatively benign or quite devastating... you can get all
sorts of "storage overlay" problems, or even worse ... data corruption,
etc. -- and these can be extremely vexing problems to "debug" and hunt
down, if they are even noticed in a timely manner.
What we really need are "externally described programs" -- in much the
same way that we now have "externally described files" -- this also
means that the compilers will need to include the definitions of all
(exported) procedure interfaces into any compiled modules, and they can
then be carried forward into any bound programs or service programs.
(We have part of this capability today, via the PGMINFO(*PCML *MODULE)
option -- but today, that feature only caters for information needed to
enable Java to "call" these program objects. This needs to be expanded
to store all of the interface definition information in such a way that
it can be consumed by all ILE compilers, and the binder.)
Then, it will become possible for the compilers to provide something
like an "IMPORT" or "USES" statement, e.g.:
uses PAYROLL.MODULE;
or
imports EMPLOYEE.SRVPGM;
instead of having to rely on the primitive notion of a "copy book" or
"include member" that represents the interface to some object --
(Include files have been around since the 1960s ... I think it is about
time we got something much better.)
With IBM i, modules, programs and service programs are all objects that
have one or more associated spaces, so there is already a nice place to
store such information, within this architecture. I hope we can convince
IBM to better take advantage of these features of the architecture, as
this would greatly improve upon the reliability, serviceability and
integrity of applications programs running on this platform, as compared
with all other platforms available today.
(I hope this sparks some meaningful debate and we can generate some
enhancement requests or DCRs as a result.)
All the best,
Mark S. Waterbury
> On 3/25/2015 10:35 AM, John Yeung wrote:
On Wed, Mar 25, 2015 at 10:07 AM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:
Mark, I agree this would be nice to have....it would be some nice insurance
to have when using procedure pointers
If I understand correctly, it's not just "insurance" (though that part
is certainly nice and important) but also an added convenience.
It feels like it combines the "don't have to keep typing/pasting the
same thing" aspect of copy books with the rigorousness of
compiler-level checking and linkage.
I don't think convenience should be downplayed (not that you were
doing that; I'm just speaking in general terms). A lot of modern
languages are highly dynamic (making them more convenient in many
respects), even sacrificing compiler-level safety to get it. And
while most on this list might not be of that ilk, the fact is that
these languages are being used with great success and effectiveness
*in production* by lots of businesses, particularly on the Web.
So, to get *both* added convenience *and* added safety seems like an
unqualified win. Obviously, the issue is the effort involved in
adding this feature to the compiler.
John Y.
midrange.com
