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


  • Subject: RE: Separating I/O from business logic
  • From: Chris Bipes <chris.bipes@xxxxxxxxxxxxxxx>
  • Date: Mon, 20 Nov 2000 06:39:03 -0800

Start by taking all the files except the screen and putting them into a
callable program.  Not to difficult to do and does not require ILE.  You
will be calling this program passing the fields from the screen I/O.  I like
to pass external data structure of the main file that is being maintained.
I also pass control fields, status fields and work variables.  A great way
of testing to make sure that every variable you need to retain between calls
is being passed back and forth is to set on LR in the edit/update program.
This will ensure that the module will work correctly latter when attached to
a server program.

Once you have the Screen I/O in a separate module calling the edit/update
program(s), you can now introduce the ILE environment, although not really
necessary.  Make sure that everything you need to retain between calls is
returned to the main module.  DO NOT count on any variables being retained
in the edit/update modules.  Several different jobs will be accessing once
you convert to a server program.  Again I set on LR between each call.

Now write a server program, I prefer data queue based, to read data queue
entries and process the responses.  I lay out the data queue into an file
with fields big enough to hold the data structures being passed.  I use the
job number for the key to the data queue.  The server reads with a key value
of zero and writes with the key value equal to the job number of the job
that send the entry to pass.  This can be a simple CL program that reads the
data queue and call the RPG that you are calling above although I think it
is easier in RPG.  

Finally take the program with the screen I/O and change to send a data queue
entry instead of call the edit/update module.

The layout of the data queue I use is in general:
1. Action                10 char
2. Time Stamp         timestamp
3. Return key     6 char (senders job number)
4. Sending file structure (optional before & after image)
5. Work variable structure

I prefer the data queue approach.  That way I can have several server
programs reading the data queue.  This gives me a many to many relationship.
By keying the data queue with a 6 char key you can control what program
reads what entry.  The server program wait with a key value of "SERVER" and
send responses back to the same data queue using the return key.

I also have a nightly job that deletes old data queue entries.  We use
special actions to start more occurrences of the server, end the servers and
reset the servers.




Christopher K. Bipes    mailto:ChrisB@Cross-Check.com
Sr. Programmer/Analyst  mailto:Chris_Bipes@Yahoo.com
CrossCheck, Inc.        http://www.cross-check.com
6119 State Farm Drive   Phone: 707 586-0551 x 1102
Rohnert Park CA  94928  Fax: 707 586-1884

If consistency is the hobgoblin of little minds, only geniuses work here.
Karen Herbelin - Readers Digest 3/2000

-----Original Message-----
From: Colin.A.Williams@chase.com [mailto:Colin.A.Williams@chase.com]
Sent: Monday, November 20, 2000 3:58 AM
To: MIDRANGE-L@midrange.com
Subject: Seperating I/O from business logic


I have seen old messages on this where people have discussed seperating file
and
DDS operations from the business rules( validation and calculations).
Whats the best way to start with something like this, how have other people
acheived this. Is it even feasible with RPG?
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.