RE: Breaking in to ILE

I think the whole "externalizing I/O" as service program misses the mark and serves to mislead newbie's away from the real values of ILE...

Brian May posted a brief response that I think is on target. Essentially, he's suggesting a "business object" design, which I think is much more productive at a high level than just simple I/O methods.

Don't misunderstand, by defining your service programs as "business objects", you cannot avoid having to concentrate your I/O into modules, but once the interfaces to the "business object" are built, you have complete autonomy to re-engineer the implementation however you please.

Take any common "business object"... Let's say ADDRESS...

What do you know about ADDRESS? Define the data elements that collectively represent all the details of ADDRESS, and assemble them into data structure definitions. These data structures become the basis for "object data" that is acted upon by your procedures (or business object methods).

So, now define some methods.
Addresses can be C.R.U.D. from the database (Adr_NewLocation, Adr_GetLocation, etc.)
Addresses can be formatted to produce a label (Adr_PrintShippingLbl)
Addresses can be validated (Adr_IsValid)
Addresses can be geocoded to identify taxing jurisdictions (Adr_LookupGeocode)
Addresses can be flagged for review/correction (Adr_LogError)
Etc.

When you're done, you wind up with a series of nouns (business objects) and verbs (procedures) that you use to build your business applications.

D CustShipTo LikeDS(t_Location)

Adr_GetLocation( lCustomerID : 'SHIPTO' : CustShipTo );
If Adr_IsValid( CustShipTo );
Adr_PrintShippingLbl( CustShipTo );
Else;
CustShipTo.ValStatus = 'ERR'
Adr_UpdLocation( lCustomerID : 'SHIPTO' : CustShipTo )
Adr_LogError( lCustomerID : 'Error with ShipTo...');
Endif;

Just food for thought...

-Eric DeLong


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, January 20, 2012 10:02 AM
To: Midrange Systems Technical Discussion
Subject: Re: Breaking in to ILE

I think it depends on shop. For example you may be externalizing I/O and
by table may make sense for you. Then again, it may not. Because if
you're externalizing I/O the name of the 'table' shouldn't matter.

Organizing by application may be applicable. For example: A/P, A/R, etc.
Or even by software vendor.

We have very few custom service programs. I think they are all in our
ROUTINES library. All prototypes for the various procedures in those
service programs are in QPROTOSRC.


Rob Berendt