Re: Early Client Server on the AS/400 -- MIDRANGE-L

Hello Nina,

>excuse me, i should have said 'downsides are pure communication line speed'.
>
>in the early 90's we had an application that needed to be networked between 
>as/400.  there was a lot 
>ofcontstruction on the fly of the data, and the result was 2 minute response 
>time over 9600 lines 
>using ddm.
>
>so we used icf instead.  but remember this was 6 years ago, and i wouldn't do 
>it that way today.
>
>nj

My point was more that DDM is unfairly blamed as slow when the real problem is 
generally elsewhere.  
Usually whith the programmer of the application -- although not much can be 
done if the communication 
line speed is simply too slow.  A lot of programming stupidities are masked by 
local data access.  
Remote data tends to highlight those flaws and then the tool is blamed rather 
than the worker.

Your original comments implied that the entire file needs to be transmitted to 
the source system which 
isn't true.  That's really what I wanted to clear up.

Regards,
Simon Coulter.

//----------------------------------------------------------
// FlyByNight Software         AS/400 Technical Specialists
// Phone: +61 3 9419 0175      Mobile: +61 0411 091 400
// Fax:   +61 3 9419 0175      E-mail: shc@flybynight.com.au
// 
// Windoze should not be open at Warp speed.

X-Mailer: Mozilla 4.04 [en] (Win95; I)
Date: Fri, 01 Jan 99 09:47:05 -0600
From: "nina jones" <ddi@datadesigninc.com>
To: MIDRANGE-L@midrange.com
Reply-To: MIDRANGE-L@midrange.com
Subject: Re: Early Client Server on the AS/400

> >downsides are pure communication speed.  if your files are large, and you 
>are only
> >using a little bit of data, the entire file has to be transmitted.  in some 
>cases,
> >this won't work well.
>
> This isn't quite true.  Most of the overhead in DDM is purely due to 
>communications line speed.  There
> is some additional overhead when using DDM between AS/400 or S/38 and the DDM 
>extensions for those
> platforms are used resulting in extra data being transmitted.  The trade-off 
>is reduced processing at
> the source because a more intelligent request can be made of the target 
>system but it can result in
> bandwidth limits being reached sooner than expected.

> The only instance where an application may suffer additional degradation is 
>when duplicate-key files are
> being processed with READE operations.  In this case the source system 
>performs a READ-NEXT and compares
> the key value (much like RPG performs with partial-key operations) resulting 
>in the likelyhood of
> unnecessary records being returned to the source and discarded.
>
> OPNQRYF can be used to remedy the above situation in most cases because the 
>query is sent to the target
> system (using the S/38 and AS/400 DDM extensions) and the target returns only 
>the result set -- much
> like SQL and DRDA.  Blocking can also be used for sequential access to 
>improve throughput.

excuse me, i should have said 'downsides are pure communication line speed'.

in the early 90's we had an application that needed to be networked between 
as/400.  there was a lot of
contstruction on the fly of the data, and the result was 2 minute response time 
over 9600 lines using ddm.

so we used icf instead.  but remember this was 6 years ago, and i wouldn't do 
it that way today.

nj

begin:          vcard
fn:             nina  jones
n:              jones;nina 
org:            Data Design Inc 
adr:            2408 Tee Circle;;;Norman;Oklahoma;73069;USA
email;internet: ddi@datadesigninc.com
title:          Chief Programmer and bottle washer
tel;work:       405-321-0354
tel;fax:        405-360-9202
tel;home:       405-364-8960
note:           IBM Business Partner
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard