RE: Externalizing I/O -- MIDRANGE-L

I could not agree more.

<rant>

In a shop of 6-1/2 developers, I am the only one using fully free, procedures, and RDi. Been trying to get them using RDi, which I convinced my boss to buy for all of us, for 2 years - no success. Tried to start off slowly to get them modernized. Did a training session on CL enhancements - DOxxx, CALLSUBR, etc. Not a bit of success. "Why learn when it's dying?" Well, guess what? You didn't learn, and it is going away in our shop as we're migrating to Oracle ERP. Self-fulfilling prophecy.

If any of these people don't get kept on after Oracle (I'm hoping I stay!) good luck finding a shop that will want RPGIII coders. Well, they think they're doing ILE because the source type is RPGLE and they use the EVAL opcode.

</rant>

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Thursday, October 27, 2016 2:36 PM
To: Midrange Systems Technical Discussion
Subject: Re: Externalizing I/O

<<I''m coming from a RLA perspective because the new RPG Redbook that
prompted this discussion used RLA, and I think most people would agree that
RLA is the dominant I/O method for RPG.>>
For no other reason than people won't change. They keep on writing the 1980
code again and again including RLA just as they keep creating un-normalized
databases which, of course, is why the machine is dying. If RPG programmers
won't change, companies move to new development platforms where people will
use SQL and normalize their databases and build maintainable code. The
iSeries is a far and away a better business machine but it does no good at
all if we keep writing 1980 code. I see it every day. My opinion only.

On Thu, Oct 27, 2016 at 11:46 AM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
wrote:

I'm coming from a RLA perspective because the new RPG Redbook that
prompted this discussion used RLA, and I think most people would agree that
RLA is the dominant I/O method for RPG.

I haven't given a whole of thought on this from a SQL perspective. My
understanding is that the pre-compiler pulls in the column definitions,
kind of like RLA record formats. Of course, with SQL you would only bring
in the columns you need so you might be OK if a non-referenced column was
changed. I'm not sure a single *SRVPGM could handle all the I/O using SQL
since most programs will have specific WHERE's and/or JOIN's.

And how did this end up on the Midrange list?

-----Original Message-----
From: D*B [mailto:dieter.bender@xxxxxxxxxxxx]
Sent: Thursday, October 27, 2016 12:58 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Externalizing I/O

<justin>
I'm not sure getters/setters and ORM are mutually exclusive. You use ORM
to set properties on your objects, but without getters/setters how do you
expose those properties? My thinking was to treat a *SRVPGM like that
object and access the "properties" via getters/setters.
</justin>

... setters and getters could handle complex (compound) types, (speaking
in OO Obejcts, speaking RPG DS) not only elementary types. The real thing
is: a type is a type and would not change is external content and behaviour
- never ever.

<justin>
Let me explain the issue I'm trying to solve so we're both on the same
page.
Traditionally, RPG references a PF directly and is tied to the record
format at compile time. If an existing column was changed in the PF, all
the RPG programs that use it will fail with level check errors. This is
rather than having them run over bogus data. So the question is how to get
the data to/from that PF without tying every RPG program to a static format.
</justin>

... that's one of the limitations of RLA and why it should be changed to
SQL. Using SQL you would never (never ever!!!) reference a table in an
application, only use views and your external DS only adress views. As this
DS is a type, it would never change!!! If you need an extended database
object, you will get an extended view and an extended DS (OO names this
relation inheritance). Ýour existing getters and setters won't change - you
might have additional setters and getters, as RPG is rather limited and
doesn't know overloading, you would have to use some workarounds - some
naming conventions could help. All programms - not knowing additional
properties, would work unchanged, programms using it, you would have to
touch anyway and changig it to use the extended types.

D*B

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.