|
midrange.com
Then some of the suggestions here bear some strong consideration
1) Mimix or a competitive product
2) Roll your own Mimix using remote journals
3) Using a trigger approach to use remote data queues or sockets.
Frankly I am socket ignorant. So I may suggest
a) Trigger updates local data queue.
b) Local data queue program updates remote data queue
c) Remote data queue program update remote file
The beauty of using 2 data queues versus one is that it handles downtime
better. Be it:
- comm
- backups on remote machine
- critical file locks
And it will minimize the interruption of response time to the local
application.
Flow chart:
* Your application writes to file on systema
* Trigger program on file on systema writes to data queue on systema
* A batch program on systema reads local data queue on systema and writes
to remote data queue on systemb
* A batch program on systemb reads data queue on systemb and writes to
file on systemb.
The biggest problem I have with data queues is that they are sna only. DDM
files can be either the default of sna, or the better performing tcp. You
still have this limitation under V5R1. Maybe it is time to evaluate
sockets. I wish IBM would embrace TCP for data queue support! (I would
put more exclamation points but some email filters would trash it.)
Rob Berendt
==================
A smart person learns from their mistakes,
but a wise person learns from OTHER peoples mistakes.
"Tim Truax"
<truax@telerama.com To: <MIDRANGE-L@midrange.com>
> cc:
Sent by: Subject: Re: Most efficient
AS400 physical file building ?
owner-midrange-l@mi
drange.com
08/08/2001 10:07 PM
Please respond to
MIDRANGE-L
Yes.. the file on (system A) is constantly receiving data nearly around the
clock.
----- Original Message -----
From: rob@dekko.com
To: MIDRANGE-L@midrange.com
Sent: Wednesday, August 08, 2001 6:01 PM
Subject: Re: Most efficient AS400 physical file building ?
Did you create the DDM file using SNA (the default), or TCP/IP? We've
discovered that TCP was much faster for DDM copy files. But we also have
2
lan cards and the TCP is using the gigabit ethernet.
Perhaps this might also be better served by a Mimix like solution. This
would keep the files in sync on a transactional basis. Or, is the file
on
systemA filled with the data all at once also?
Rob Berendt
==================
A smart person learns from their mistakes,
but a wise person learns from OTHER peoples mistakes.
"Tim Truax"
<truax@telerama.com To: <
MIDRANGE-L@midrange.com>
> cc:
Sent by: Subject: Most efficient
AS400 physical file building ?
owner-midrange-l@mi
drange.com
08/08/2001 04:30 PM
Please respond to
MIDRANGE-L
Hi All,
There's a process that I am analyzing that involves large volumes of data
records arriving in one (system A) AS400 physical file. Then another
(system B) AS400 that is attached to this physical file on (system A) via
a
DDM file which resides on (system B). This process that runs on (system
B)
then uses this DDM file and simply transfers the data that arrived in the
physical file on (system A).
Lately this process that transfers data between the two systems is lagging
behind to the tune of millions of records. These lags are happening at
heavy system use times.
I am wondering if there is an (overlooked by me) CRTPF option that I could
add to the (system B) receiving physical file when it's built weekly that
would minimize this lag on receiving data records? ..possibly ALLOCATING
THE STORAGE or something?
I have been directed to simply break the process in two (duplicate it) in
order that the 2 duplicated jobs could run concurrently on (system B), and
then the (system A) physical file would require 2 file members in order to
attach two different DDM files to.
FYI) These AS400's I am talking about are not farty little boxes they are
big AS400's.
Any suggestions or comments appreciated.
Tim Truax :-)
+---
| 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 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.
