× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.