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.

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