RE: Data Propagator vs DDM?

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
For openers,

Data propagation is built into the OS release e.g. the two key components
CAPTURE an APPLY so the more pressing question is where the data is comming
from and where it is going to and most important, did they buy DB2? DJRA
will cost a bundle and unless you have disparate and non DB2 databases as
data sources and/or targets, would be overkill. I do not know what CFINT is
so I can not speak to that question however DDM would be used by DpropR for
the actual movement of data, assuming that a path is defined for it to use!
If you do not set up a seperate path, data will traverse the network. DDM
can use either APPC or TCP over APPC so the network part can be fairly
simple. With respect to Oracle, you can use DpropR with the Data Joiner
tools (free) to get there but depending on the data, there may be a mapping
problem e.g. Timestamps etc.

Hope this helps!

-----Original Message-----
From: Jan Megannon [mailto:jmegannon@intekom.co.za]
Sent: Monday, November 19, 2001 6:53 PM
To: midrange-l@midrange.com
Subject: Data Propagator vs DDM?


Hello to all here,

Some things mentioned here may see me flamed, only to crash and burn. Well
so be it!!

I am fishing for comments and ideas regarding something I want to propose to
a customer.

<background:>
Customer purchased a 720-1501, a batch processor that invokes the wrath of
CFINT. The
customer claimed not to be able to afford the 1502 processor. More than a
year down the
line, they have now implemented an application that provides web access to
their 400 data.
Hey, is CFINT letting them have it or what! They are now being compelled to
consider an
upgrade, or other alternatives. The customer will be on the iSeries for (a
claimed) maximum
of another +-18 months. As such, they do not want to invest too much to keep
the system
going. No, I did not sell them the system.
</background>

I have been approached to assist with this problem and have some ideas of a
work-around.

1.    Install a secondary system (Model 170-2291) and move the web access to
that system.
       That should move the workload off the primary system, resolving the
performance issues
       over there.

2.    In order to retain all the functionality of the current
implementation, I am considering
       that they either use Data Propagator (along with it's components
required to let it
       function properly, like DRJA :-) ), or setting up DDM from source to
target.

I know that DDM works on APPC / APPN. Will I still be nailed by CFINT, or is
DDM not
subject to the 5250 data stream penalties? The same applies to Data
Propagator.

Certain database functions are subject to CFINT (async access?, etc.). Will
I truly realize
improvement on the 720, seeing as I have taken the processing of that
system, albeit that, in
the case of DDM, all database access is still on the 720?

I tend to think that while DDM is the cheaper, built in option, I may not
realize the expected
improvements. Data Propagator (at last check) is $3200-00 on the P05 and
about $6400-00
on the P10 charge groups. DPROP is also the more elegant solution, with more
reliability,
controls and menu driven management. That equates to greater customer
independence.

I hope I have explained myself properly :-). Any ideas out there?

BTW, they intend moving to Oracle when they do go. Hell, I have my job cut
out to educating
them over the next few months! I think it is easier to educate them than to
convince them!

TIA.

Jan Patrick Megannon.
'First thing to do in the morning is to plan your dinner. That way you will
have something good
to look forward to the whole day' - Old Irish saying.

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.