|
Tim,
Check for end of file delay on the ddm file. This is
specified on an OvrDbf cmd. To see if it is used and its value, WrkJob on the
job that reads the ddm file and look at the overrides of the job.
Steve Richter
This DDM line/file is max'd out at 16M. And the stats on the DDM
is that it isn't even being used at 50%. This process runs constantly,
and the job is submitted on Sunday nights and runs all week. One thing
the program does do is use the QCMDEXC command to update a *dtaara with the
relative record number it processed every 100 records, so this QCMDEXC is
getting called all the time.
----- Original Message -----
Sent: Thursday, August 09, 2001
12:24 AM
Subject: Re: Most efficient AS400
physical file building ?
Tim,
The latentcy you describe is quite large. Can
you describe the ddm transfer, how frequently it runs, how is it
initiated. ( system B pulls from system A or A pushes to B
)
However you do it, another option is *Add, *Dlt and *Upd
triggers on the system A file. This gives your trigger pgm each chgd rcd
in the file. Then write a socket pgm to send the data to system b or use
a data queue.
Steve Richter
----------
Original Message ----------------------------------
From: "Tim
Truax" <truax@telerama.com>
Date:
Wed, 8 Aug 2001 23:07:04 -0400
>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
>+---
>
+---
|
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
+---
|
midrange.com
