Program objects (*PGMs, *MODULEs, *SRVPGMs) should support "reflection" so that the interface(s) are "visible" so that it is no longer necessary to hand code and maintain "/COPY book members" (1960s technology.)
Back around V5R2, IBM began adding PCML support to some ILE languages, so they can be more easily used with tooling such as IWS. That was a great "first step."
I propose to take this to its logical conclusion -- extend the PCML so that it covers all of the possible data types of the parameters etc., such that any other language compiler, instead of having to use a "/INCLUDE" statement to pull in the source code for a definition of the externally exported interfaces, can use a statement such as:
uses pgmName.PGM;
or
imports srvPgmName.SRVPGM;
or
import moduleName.MODULE;
and those compilers will use the embedded PCML to extract the needed definitions.
Also, the "uses" or "import" statement should permit optional "library qualification," for example:
import LIBHTTP/HTTPAPIR4.SRVPGM;
This will go a long way towards making IBM i the truly modern object-based OS that it was intended to be.
This will greatly reduce the possibility of runtime errors and storage overlays and corruption due to mismatches between the "definition" (/COPY book) used at "compile time" and the actual generated code executed at runtime, thereby further improving the reliability and integrity of the platform.
Ideally, the compilers can generate some kind of a "hash" or "signature" over the parameters as well as the procedure names, so that at runtime, when a program or service program first references (and activates) another *PGM or *SRVPGM, it can check these signatures just once, at initialization time, and detect any "mismatch" between the definition used when the calling program or service program was originally created, and the *PGM or *SRVPGM that is about to be used at runtime.
This is analogous to the OS/400 database "record format Level ID" and compiler generated code to perform a "Level Check" at file OPEN time, to prevent similar disasters where the record layout used at compile time no longer matches the actual database file record layout. This feature has likely prevented may serious problems where data could otherwise be "corrupted" in customer database files.
A similar feature for compiled *MODULEs, *PGMs and *SRVPGMs will provide similar benefits.
The "good news" is, IBM has already added some PCML support. So, IBM can just build upon that as a foundation, to create the needed capabilities.
Use Case: Many modern languages such as Java support a similar mechanism, where you simply state:
use packageName;
to import the definitions from the .class or .jar file.
This is also similar to modern languages such as Python, node.js, etc.
There is also a movement in the ANSI C standard to add "modules" to ANSI C, for a similar purpose.
This support should also be extended to work with Java --since Java supports "reflection" it should be possible to code a statement such as:
use javaPackageName.class;
or
use javaPackageName.jar;
and the compilers should be able to extract any needed definitions from the Java .classes using the "reflection" capabilities built into Java.
This would alleviate the error-prone process of having to manually define the interface to the Java methods, etc.
About the suggestion for an additional parameter (such as JAVA_COMPATIBILITY) to allow PCML to be generated for any data type, Idea IBMI-I-3437 requests that support for RPG: (https://ibm-power-systems.ideas.ibm.com/ideas/IBMI-I-3437)
- Barbara Morris, IBM
About distinguishing between 1A and 1N: a recent enhancement for PCML (version 8) and the RPG compiler (7.3+) supports attribute boolean="true". If RPG is generating version 8, it will add that attribute to indicate items. You can get the compiler to generate PCML version 8 either by coding PGMINFO(*PCML:*V8) in a Control statement or with environment variable QIBM_RPG_PCML_VERSION with value '8.0'.
In a future release of the RPG compiler, PCML version 8 will be the default.
For PTF info, see https://www.ibm.com/support/pages/node/6983230 (RPG Cafe: Spring 2023: Generate the "boolean" atribute for indicators in PCML)
<pcml version="8.0">
<program name="MYPROC" entrypoint="MYPROC">
<data name="IND1" type="char" length="1" boolean="true" usage="inputoutput" />
<data name="CHR1" type="char" length="1" usage="inputoutput" />
</program>
</pcml>
- Barbara Morris, IBM
Sounds great to me.
I just wanted to add that we would also very much like to see PCML extended to support documentation of any interface - regardless of technical compatibility with the Java layer it was originally introduced to support. This would open many doors. Specifically on the PCML side, I was thinking of a new optional parameter for JAVA_COMPATIBILITY or some such, obviously with a default of *YES to preserve backwards compatibility. With this disabled, we would be free to include a variety of things which would otherwise have resulted in a technical error to generate the PCML.
One other, related point: the inability to distinguish between a 1A and a 1N in the PCML we have today can be a bit of a pain for us. Whether this would be automatically resolved with any solution to this RFE/Idea I'm not sure, but I'd previously thought of an additional 'native_type' attribute to cover all bases - allowing the reporting of a somewhat generic/normalised type still as the primary attribute, but then also providing the full detail for those who want to read it out.
The CAAC has reviewed this requirement and recommends that IBM view this as a medium priority requirement that should be addressed. It is essential that IBM i does all it can to keep current with other languages. PCML really does need to be extended.
Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.
For more information about CAAC, see www.common.org/caac
For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/
Nancy Uthke-Schmucki - CAAC Program Manager
The COMMON Europe Advisory Council (CEAC) has reviewed this requirement and recommends that IBM view this as a MEDIUM priority requirement that should be addressed.
Background: The CEAC members have a broad range of experience in working with small and medium-sized IBM i customers. CEAC has a crucial role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community and has therefore reviewed your RFE.
To find out how CEAC help to shape the future of IBM i, see CEAC @ ibm.biz/BdYSYj and the article "The Five Hottest IBM i RFEs Of The Quarter" at ibm.biz/BdYSZT
Therese Eaton – CEAC Program Manager, IBM
Great.
Maybe also eliminate the need to code the prototype twice (in the called and calling procedures) for external procedures. The compiler should find the called service program, and from it the called module / procedure and copy from there the prototype. Similar to RPG built in functions, that no prototype is needed.
I have A similar idea. perhaps a _meta_ procedure could expose all exports and parameter descriptions ( In JSON) that describe features of a service program etc. that means that webservices and code completion could be done automatically.
A candidate for a new RFE
Attachment (Description): This presentation describes the idea in terms of how to enhance the ANSI C language to include this kind of functionality, called "modules" in C. If you look at this presentation, you should be able to understand how the same kinds of issues exist with ILE RPG IV compiler built-in pre-processor /include and /define mechanisms. Also similar for COBOL with its COPY mechanism.