While I don't disagree that signatures and binding would be greatly improved if parameters were taken into account (overloading anyone?), we should avoid PCML in the solutions.
PCML is a nice idea, but it lacks support for commonly used data types in RPG applications. Things such as Dates, Times, Timestamps, Graphic, procedure pointers, and certain variations of integers are just not supported in PCML.
Brian May
Solutions Architect
Profound Logic Software
http://www.profoundlogic.com
937-439-7925 Phone
877-224-7768 Toll Free
The IBM i Modernization Experts
www.profoundlogic.com
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Wednesday, March 25, 2015 10:26 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: [Bulk] Re: New Template Type
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.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.
midrange.com
