× 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: Ken.Slaugh@xxxxxxxxxx
  • Date: Mon, 20 Nov 2000 08:10:56 -0800


Chris,
     Your method requires that the business rules be duplicated. Thus
maintained twice in the future. Don't make your life more difficult than it
already is.

     Use the existing display file enabled program. Just simply change the
workstation file to USROPN. Put an indicator on the new OPEN and CLOSE
statements and use the indicator to control the client/server modal.

     Instead of using DataQs directly, pass the I/O in *entry plist
parameters. Then write a driver program, using DataQs or Sockets, to call
the original application program and send/receive the data.

Ken Slaugh  (707) 795-1512 x118
Chouinard & Myhre, Inc.
AS/400 Professional Administrator/MSE
Client Access Specialist
http://www.cm-inc.com/


                                                                                
                
                    Chris Bipes                                                 
                
                    <chris.bipes@cross-        To:     
"'MIDRANGE-L@midrange.com'"              
                    check.com>                 <MIDRANGE-L@midrange.com>        
                
                    Sent by:                   cc:                              
                
                    owner-midrange-l@mi        Subject:     RE: Separating I/O 
from business    
                    drange.com                 logic                            
                
                                                                                
                
                                                                                
                
                    11/20/00 06:39 AM                                           
                
                    Please respond to                                           
                
                    MIDRANGE-L                                                  
                
                                                                                
                
                                                                                
                



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
+---




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