RE: Organising modules, programs and service programs

Johan,

Externalizing file I/O is in my view the first step towards an
architecture which enables you to use the same database layer (with all
checks, rules and what have you) whether you try to do things via a web
application or 'old fashioned' green screen terminal or enterprise
server bus. A very usefull architecture with a lot of potential.

However nice this is, you will have to do something about the fact that
most oldfashioned programs are written in a fashion which implicitly
takes for granted that the record locks are exclusive are placed and
remain there in the program while it runs (or whenever the lock is
released by another read etc.). If you externalize the file I/O to a
service program, this no longer holds true. Take the example of a
program which reads a record, goes into a subroutine which executes some
stuff and then updates the record which it read before the EXSR. If the
file is 'in the F-spec' this poses no problem, if the file I/O is done
via a service program however there is a big snake under the grass: if
the subroutine calls another program which also accesses this file where
will the file pointer be directed at? Will updates have been done in the
meantime by other processes in the same job? Is there a way to tell?

The move to external file I/O should trigger you to  check the
architecture of all the programs in the (sub)system and an almost
paranoid style of programming needs to be introduced: any update or
delete needs to be preceeded with a read of the file (with lock) and a
comparison of the old record buffer (the one before the fieldvalues were
changed by the program) and the latest read record buffer. Only if the
record contents is equal then the update or delete can go ahead.
Granted: there are currently programs around which have this optimistic
locking mechanism in place, but if this is not the case a considerable
programming effort needs to go in to build this in (and test it
thouroughly).

Moving to SQL for file I/O is also suggested, and indeed SQL also offers
a lot of advantages, however the optimistic locking mechanisms need to
be in place as well. SQL also introduces a new concept of cursors,
result sets, etcetera. Building up a subfile page by page and the
scrolling mechanisms almost force you to link the I/O module to the
program instead of exporting the program as a symbol from a service
program because there is no easy way of transferring the resultset and
the cursor attached between the service program and the using program. I
am not saying the scrolling mechanism and cursor/resultset challenges
compel you to link the I/O module to the program and that it is
absolutely impossible to solve this another way. I am merely saying that
any move away from 'ye olde way' of file I/O methods introduces all
kinds of new issues which need to be addressed.

Don't be surprised if the externalisation forces you to redesign the
programs, and perhaps even forces you to rebuild your entire system. I
am merely trying to warn anybody: The step of externalizing the file I/O
to modules to the program is a step which is often taken much too
lightly. Nonetheless it is an interesting subject and can offer a lot of
advantages, or is even mandatory when moving to a service bus
environment.

My 2 cents,

Cor Takken

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx 
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Johan Vangilbergen
Sent: woensdag 24 januari 2007 20:39
To: RPG400-L@xxxxxxxxxxxx
Subject: Organising modules, programs and service programs

Hi,

 

I work on an application that has a history of more than 15 years.
Originally this application was written in RPG400 and 
somewhat 5-6 years ago, the whole bunch was converted to RPG 
IV using the CVTRPGSRC.  Since then most of the programs are 
being created with the CRTBNDRPG command.

 

Since a few months I've did some trials to create modules and 
bind them together in real ILE-programs.  With, all together, 
reasonable success.

 

Now I want to go a step further on the ILE-way and want to 
start externalizing file I/O's.  However, I'm having some 
difficulties in setting up a workable organization for this.  

I was thinking of creating two modules for each file in the database :
the first one would contain procedures to update, add or 
delete records in the file, the second would contain 
procedures to get information from the specified file (input 
only).  Finally, I thought of binding these two modules in a 
service program.  So, I would have one service program for 
all I/O's per file.

 

Is this a workable method ? Does anyone has any suggestions, 
or can you point me to some literature and/or examples of how 
to handle this ?

 

Another question to this is : do I need to have a different 
name for each procedure.  For example : I have customer-file 
and a supplier-file.
If I want to read a record, does the name of the two 
procedures to read a record have to be different (e.g. 
ReadCust and ReadSup) ? Or is there a way to name it both for 
example Readrecord ?

 

Any suggestions will be welcome, as well as tips for further reading.

 

 

 

Johan Vangilbergen

 

YUSE

Phone : +32 16 74 50 80

Fax : +32 16 74 50 89

Email : jvg@xxxxxxx <mailto:jvg@xxxxxxx> 

Web : WWW.Yuse.be <http://www.Yuse.be> 

Address : Bondgenotenlaan 138, B-3000 Leuven, Belgium

 

--
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 and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.