RE: EXTPROC(*CL) and V6R1

Thanks all for such an enjoyable thread! Only read it this morning as the replies came after I'd left for the weekend. Yesterday I was snowed in and didn't make it to the office.

The replies didn't really answer my simple original question, but I am glad they opened up the discussion again on a subject that is dear to me.

I reply to the points raised by Scott, and give a simple(!) example of a prototype. When it changes, we recompile everything. And for those who don't know me, without any service programs.

-----Message d'origine-----
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Scott Klement
Disadvantages are:

a) No bidirectional parameter support without discarding
encapsulation entirely.

We just put clientNameIn and clientNameOut. No parameter updating.

b) Total size of all parameters is limited to 64k at v5r4, or
16M at 6.1

I would guess that that's ever occurred to anyone.

c) calling routines is significantly more cumbersome and
complex (you may as well go back to the days of CALL/PARM!)

I agree but have no choice.

d) No real error checking from the compiler (back to the days
of CALL/PARM there, too!)

I agree there, I now realise how much time prototyped parameters was saving me.
Now I'm only finding the errors during the test, when I have bad data in the DS.
Before I'd never have had to test that, as the compiler would have detected it.
I wrongly declared a variable as 15P0 and passed it to my input DS, where the subfield it was supposed to fill was 1A!
In my program, I test the value of this subfield. Couldn't understand why the program wouldn't work as it should and had to debug.
So, lots of time wasted, there. Now, what if I hadn't correctly tested.... what if somewhere, some other programmer hasn't correctly tested....
Like that's ever gonna happen!

e) No automatic setting of the sizes, so to avoid memory
corruption you have to rely on every caller to be coded
correctly. (Something that can't be reliably detected during testing!)

Not sure if I understand that.

f) No ability to omit data in the middle, other than using
"special values" which have to be manually set by the caller.

Nobody used omitted data even before the new rule.

g) Every time you check for an optional parameter, you have
to manually calculate the start position of the optional
subfields. An error in this would also not be detected by
the compiler, or by testing, resulting in memory corruption.

No optional parameters.

h) You can't ever call your routines from SQL or other
languages that don't support structures.

Not needed because no experience of calling from SQL. I will definitely be looking into that one.

And all for WHAT? So you can check your own length instead
of %PARMS?
What does any of this gain you? Can you provide even a
single thing that this does better than separate parameters do?!?!

The argument is simple. Modify the parameter list on the called procedure, recompile and no need to touch the callers that don't use the parameter.
I think the real problem is wanting to still write RPGIII. Procedures are being treated as OPM's and so they are expected to bring everything back to the caller by parameters.

Today, we find ourselves having to add the keyword EXTPROC(*CL) to
the prototype. Would it be reasonable to assume that we would never
have to add a keyword to a parameter, at a later release?

EXTPROC(*CL) isn't set on a parameter, it's set on the whole
prototype.
It only matters if you have 1-byte return values, and since you say
all of your output is through an output parameter, I don't see how it
applies to you at all.

Well, I was just imagining if the correctif WERE to apply to a parameter. As we can no longer use keywords on individual parameters.







D GetClientStuff PR N
* Input parameters
D GetClientStuffIn...
D LIKEDS (GetClientStuffInDS)
D CONST
* Output parameters
D GetClientStuffOut...
D LIKEDS (GetClientStuffOutDS)

* Define input here
D GetClientStuffInDS...
D DS BASED (p_GetClientStuff)
D QUALIFIED
D ClientNumber LIKE(DFN_ClientNumber)

* Define output here
D GetClientStuffOutDS...
D DS BASED (p_GetClientStuff)
D QUALIFIED
D ClientName LIKE(DFN_ClientName)
D ClientDate LIKE(DFN_ClientDate)

* Definitions for calling procedures.
D GetClientStuffIn...
D DS LIKEDS (GetClientStuffInDS)
D GetClientStuffOut...
D DS LIKEDS (GetClientStuffOutDS)