Re: Data Propagator vs DDM?

[Mike.Crump@xxxxxxxxxxxxxxxx]

Jan,

I think there are some fundemental differences with DDM/DRDA and
DataPropogator.

1.)  DataPropogator with it's capture/apply logic does not lend itself well
to a 'real-time' data transfer at all.  It is better designed for periodic
updates/refreshes (5 min, hourly, daily, etc.).

2.)  With DDM/DRDA you can do real-time data access as well as program
periodic refreshes.

DDM/DRDA access will not evoke the wrath of CFINT.  DProp will not either.

DProp is somewhat more elegant but I don't think it will actually do what
you want to do.

Michael Crump
Saint-Gobain Containers
1509 S. Macedonia Ave.
Muncie, IN  47302
(765)741-7696
(765)741-7012 f
(800)428-8642

mailto:mike.crump@saint-gobain.com





                    Jan Megannon
                    <jmegannon@inte       To:     midrange-l@midrange.com
                    kom.co.za>            cc:
                                          Subject:     Data Propagator vs DDM?
                    11/19/01 06:52
                    PM
                    Please respond
                    to midrange-l





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.