Re: Latest RPG Updates -- RPG400-L

Bravo, Jon:

I have said for years that if IBM would just enhance PCML to handle all possible data types, then we could have "externally described" programs and procedures (in *SRVPGMs or *MODULEs) and we would no longer need the "dual maintenance" of hand-coding separate /include or /copy files ("/copy" is 1960s technology, after all).

So then, (using Scott Klement's HTTPAPI as an example), instead of coding:
     /copy HTTPAPI_H
we could code something like:
    /uses HTTPAPIR4;

where HTTPAPIR4 is the name of the *MODULE or *SRVPGM in the *LIBL

Or perhaps a more modern syntax might be:
    /import HTTPAPIR4.SRVPGM;
or    /import LIBHTTP/HTTPAPIR4.SRVPGM;    // library qualified

NOTE: this should also work for ILE C, ILE C++, and ILE COBOL and perhaps even be made "useable" in ILE CLLE. That "interoperability" between ILE languages is supposed to be the hallmark of "ILE."

Similarly, it should be possible to have something like:
    /uses /ifs/qualified/name/of/some/java.class;    // or .jar file

and it should just generate the correct interface, based on whatever the Java classes export -- since Java supports "reflection" etc., this should all be "possible." We should not have to "hard-code" those laborious definitions in ILE RPG IV to use Java classes (via JNI).

In my opinion, this would go a long way towards making ILE RPG IV a truly "modern" language.

The late Dick Bains, formerly with IBM RochLabs, was a proponent of this idea of having "externally described program objects" (including service programs and modules).

Should I open an RFE for this?   Who wants to vote for it? :-)

All the best,

Mark S. Waterbury

On Wednesday, October 9, 2019, 11:32:53 AM EDT, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

If it was enhanced to include all data types ad structures Vern But PCML is a better bet in that it already handles more than descriptors - just doesn't handle enough.

I've been asking for better descriptor support since way back when I worked for IBM - I'm not holding my breath!

On Oct 9, 2019, at 6:32 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:

Jon

Could operational descriptor support help with any of this?

Vern

On 10/9/2019 1:24 AM, Jon Paris wrote:

"I'm not convinced it would be impossible."

Not impossible no - b ut it requires work at the OS level - RP{G could not do it by itself in any meaningful fashion. At present the information is just not stored anywhere in the compiled objects. Foe example a program knows its maximum an minimum number of parameters - but not what type of data and size they should be. Same with service program procedures. that data is just not stored by the system. The closest we come is when the compiler generates on request the PCML data for a call. But even that would require a lot more work before it could be used for the type of introspection needed. PCML currently can only support a subset of the full range of data that can be passed as parameters - so PCML has to be enhanced significantly before you can even think of using it as the foundation for a call mechanism.

Not saying it wouldn't be nice - just that I don't see it happening any time soon.

On Oct 8, 2019, at 9:24 PM, Peter Dow <petercdow@xxxxxxxxx> wrote:

I remember having this same feeling about having to include PIs and PRs for every procedure. That eventually was resolved at the local level. Yes, it would be a lot more work for the compiler to have to look at the service program to determine the prototypes for each candidate procedure; I'm not convinced it would be impossible. Same thing with procedure prototypes.

My understanding of programs and other objects on the IBM i is that they can be composed of object subtypes, for example a file has metadata, index data, actual data, etc. To make things simpler for the compiler, how about a subtype object containing the prototypes?

I know, Barbara does a great job and has more than enough work just adding all the other things we want RPG to do, and this is not that big a deal. I just don't like to think that it's impossible.

On 10/8/2019 4:37 PM, Jon Paris wrote:

I thought that is what I had said Peter - but yes ALL have to be present otherwise how would the overload one know which to pick? If they are not there it has nothing to compare with.

The only time that an overloaded prototype is not required is for procedures that are local and the parameter information can de derived from the procedure interface.

On Oct 8, 2019, at 3:52 PM, Peter Dow <petercdow@xxxxxxxxx> wrote:

Yes, but my question is, are the candidate prototypes *required*, or just the overloading prototype? If it is indeed fundamentally a compiler directive, then it would seem they are all required. And if they're all required, one might as well use the candidate prototypes.

On 10/8/2019 1:21 PM, Jon Paris wrote:

Basically the rules haven't changed. For a procedure/program to be called, a prototype (or the PI for internals) must be present.

That includes the overloading proto. Normally I would have all (say) three protos in a /Copy source - I'm just going to add the overload one to that set. No increase in work except for the original definition of the overload proto.

This is all a compile time function and as I said earlier fundamentally a compiler directive in a different form.

On Oct 8, 2019, at 1:11 PM, Peter Dow <petercdow@xxxxxxxxx> wrote:

Jon,

Assuming the FORMAT procedure and its candidate procedures are all in a service program, how do I use it in another RPG program? I would guess that I have to put the prototype in the RPG program, yes? Do I have to put all the candidate prototypes in there too? My thought was the RPG program using it would simply have

Dcl-Pr Format Override( ProcA, PgmB, JavaC );

but now that I put it that way, the compiler would have to go to the service program to check my usage against each of those candidate prototypes to see if it's allowed.

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx>

/
On 10/8/2019 12:14 PM, Jon Paris wrote:

FORMAT is never exported because it is only really a compiler directive.

For example thing of it this way.

Dcl-Pr Format Override( ProcA, PgmB, JavaC );

This is handled by the compiler much like a conditional compilation directive such as ...

/IF ParmMatches ProcA
CallP ProcA(parm);
/ELSEIF ParmMatches ProcB
CallP PgmB(parm);
/ELSE
....

It is that simple.

On Oct 8, 2019, at 11:28 AM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:

Is FORMAT exported? There will be times when I want it exported and other times I don't. My best guess is that it inherits from the actual procedures.

-----Original Message-----
From: Jon Paris [mailto:jon.paris@xxxxxxxxxxxxxx]
Sent: Tuesday, October 08, 2019 1:04 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Latest RPG Updates

Actually it doesn't matter if the procedure is exported or not. In fact the overloaded routines can include programs, Java calls, and subprocs.

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com