RE: i/o module

I suppose background on my viewpoint of using file encapsulation might
be helpful. We use VARPG for our interface. VARPG can "natively"
access files, but updating these programs is trickier than updating the
service program since the VARPG .dll files get locked. The added bonus
is that we're trying to make the VARPG side of things as light as
possible, so there's no need to stream all of a records data to the
interface when it's not wanted. This can be done with business logic
service programs, not necessarily file encapsulation, but that's how we
got down that path.

To answer Rob's questions... (this history is below, I don't like doing
everything in line).
1.

1. Why have a file encapsulated so it can be reused in multiple places?
Since our I/O is done in service programs vs. at the interface, we have
get procedures (getters) to retrieve the needed data. Without file
encapsulation, if we had two distinctly different business logic service
programs accessing the same file, we would need getters for that file in
both service programs (duplication of code). Instead we have a service
program for the file, so all the getters are already established.

2. Zoned vs. packed data conversion. (Which really isn't the best of
convincing points.) We use externally defined files. I'm not sure
where you're coming from. The issue I'm referring to is this: if I have
a file defined in a file as 3s 0 and that is being accessed with a
getter, the parameter HAS to be 3s 0 (since it's not Const which would
do the numeric conversion). The interface shouldn't care if it's packed
or zoned, so by always using returning one style of number, the
interface isn't required to create temporary holding variables to do the
conversion itself.

3. Shared Constants. A status code is a good example. Let's say we
have a status of 'C' which means complete. I have a constant (that is
shared because it's in the service program's copy source) called
ITEMSTATUS_Complete which has a value of 'C'. Any program that wants to
make a comparison looking for a complete status doesn't have to define a
constant for 'C', it can simply use the "shared" constant. Of course
you can always compare against 'C', but we try to replace hardcoded
values with constants for readability.

4. Comment Sequence number. Actually I'm a big fan of what you're
suggesting. And as far as changing the middle part, I would simply
update the entire field. We made a change to store our item
descriptions in that manner. However, we simply don't have the time to
change how our comment files are set up. Also, we have a line by line
user/date/time tracking so merging them would lose that.

5. Open File Initialization. Generally I do this more with business
logic service programs vs. file encapsulation, but I have used it in
both cases. The most common use of this that I've found is when I need
to create a file in Qtemp. In one instance we have 5 programs that use
this particular file. All 5 programs shouldn't have to go through the
pain of creating it in Qtemp, let the file encapsulation service program
do that for you. So if there's a 6th program coming down the line that
needs to use the file, there is no chance that the programmer is going
to "forget" or accidentally not create the file in Qtemp.

Thanks for reading. ;)

Kurt Anderson
Application Developer
Highsmith Inc

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, May 28, 2008 2:50 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: i/o module

<snip>
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.
</snip>
Why?

<snip>
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.
</snip>
I use externally defined files. I never care.

<snip>
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.
</snip>
Huh? You mean like changing 'IZ' to inactive record? Or do you mean
changing the item class code to the item class description? Sort of
like what a view, or a decent join logical would do?

<snip>
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.
</snip>
Initially I was thinking of an IDENTITY column, but typically the way an
application like yours would go is order#, seq# where seq# starts over
at 1 for each order# and thus an identity column is not what you want.
Actually, what is probably better than a comment file is a clob field or
a nice varying length field. Then your application could determine how
long each line is based on what they are trying to fit it into, ie, data
entry screen vs report column, etc. Granted, coding a decent column
this on a 5250 data entry screen is a boatload of work versus a better
interface like a simple "text" field in a web or client server
interface. But if you have to stick with a bad file layout that has the
typical order#, seq# layout then maybe externalizing it might make some
sense. How would it handle deleting a row out of the middle?

<snip>
Other examples of business logic: Error logging on the specific file.
</snip>
That might start to make more sense. When you start having to trap for
trigger errors, constraint errors and programmers assuming that every
write failure is because the key already exists and thus tries a
chain/update or some such animal...

<snip>
Open file initialization.
</snip>
Huh?


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.)


Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Kurt Anderson" <kjanderson@xxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
05/28/2008 02:15 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: i/o module






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.