We've been doing some file encapsulation which includes gets/sets,
reads, writes, updates, deletes, etc. We mainly wanted to move our file
I/O out of VARPG and into our business logic service programs. But, if
I have one inquiry program and one maintenance program both accessing
the same file, having that file encapsulated into one service program
makes it easy to reuse.
Other benefits:
Data conversion.
Some of our older files have fields that are zoned vs. packed. Why? I
don't know. So to make the interface not care if it's packed or zoned,
the getter procedure converts it.
Shared Constants.
Let's say the file has a code field. If that code's only use is with
the data in the file, why not define those values in an associated copy
source (that already houses the prototypes). That way both the
encapsulated file service program and any module using that service
program can access constants without redefining them.
File specific business logic.
When we write a comment record, we're always incrementing the sequence.
Why should the every business logic service program that writes comments
to a certain file have to recode the increment logic? So it's embedded
in the write procedure within the file's service program.
Other examples of business logic: Error logging on the specific file.
Open file initialization.
It took me a little while to believe file encapsulation was for me. It
was working in VARPG that really brought it to light. And while there's
the initial hit on time to create the service program, it has made my
life easier when working on other programs that use these file service
programs. (Note, the amount of time to create them gets a lot easier
when you have a utility to do it for you - we created one that works
great, adheres to our shop standards, and could use even more
enhancements. I see someone else has posted one too.)
Kurt Anderson
Application Developer
Highsmith Inc
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Wilt, Charles
Sent: Wednesday, May 28, 2008 11:35 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: i/o module
I agree completely.
Replacing CHAIN with a user written procedure, particularly one that
passes back the entire record buffer in a DS, is silly.
Instead, look at encapsulating business logic into the procedure. Scott
Klement has articles with some examples, as do others.
The only time it makes sense to even get close to having "chain
replacement file encapsulation", is when you're adding two layers of
encapsulation. So for example, you might have an inventory master
(INVMAST) file along with a module that encapsulates it's I/O perhaps in
a service program named INVMAST. But the only place those INVMAST
procedures are used are by another service program, call it INVENTORY.
So your external screen functions call only procedures from INVENTORY
and never INVMAST.
Even in this scenario, INVMAST won't have an exact CHAIN replacement.
Instead, it will have simple Create, Retrieve, Update, and Delete
procedures that incorporate multiple file I/O opcodes. For instance,
update would probably do it own chain, check to see if the records has
changed, and if not go ahead and do the update.
HTH,
Charles Wilt
--
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307
wiltc@xxxxxxxxxx
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of DeLong, Eric
Sent: Wednesday, May 28, 2008 10:05 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: i/o module
David,
First, I should say this is just my opinion, but I have been fairly
dissatisfied with externalized file i/o. IBM has given us a VERY
efficient means of processing file i/o, whereas most implementations
of externalized i/o I have seen seem to simulate IBM's opcodes...
Replacing CHAIN with a procedure performing the CHAIN does not seem
particularly efficient to me...
Personally, I'd rather focus on writing procedures that encapsulate
business logic, and make use of whatever native file i/o operation
(chain, read, SQL, etc.) are suited to the problem at hand.
The only reason I can see to abstract low-level file i/o into
procedures is if you intend to port your application to another
language or platform.
jmo,
Eric DeLong
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of David FOXWELL
Sent: Wednesday, May 28, 2008 2:34 AM
To: RPG programming on the AS400 / iSeries
Subject: i/o module
Hi,
Does anyone have some code that they could post for externalizing file
i/o operations ?
I've had my first go at this and although it works I'm not fully happy
with it.
To replace an RPG CHAIN operation, my program does something like IF
NOT ReadFile ( ), and the function ReadFile will do a CHAIN.
However in replacing a loop like
SETLL File
DOU %eof
READ File
ENDDO
I use another function that uses an SQL cursor. I realise that this
last function could also do the same as the ReadFile ( ) , but should
I replace a simple CHAIN by SQL?
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.
This e-mail transmission contains information that is intended to be
confidential and privileged. If you receive this e-mail and you are not
a named addressee you are hereby notified that you are not authorized to
read, print, retain, copy or disseminate this communication without the
consent of the sender and that doing so is prohibited and may be
unlawful. Please reply to the message immediately by informing the
sender that the message was misdirected. After replying, please delete
and otherwise erase it and any attachments from your computer system.
Your assistance in correcting this error is appreciated.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
