Re: Early Client Server on the AS/400

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

Hello Nina,

I see Carl has answered your question about how the system gives you just the 
record you requested.  
Note that this isn't true for duplicate keyed files accessed with a READE -- in 
this case more records 
than requested are transferred to the source.

DDM, ICF, CPI-C, and APPC are all members of the same family.  DDM makes a 
remote file APPEAR local.  
ICF makes a remote system/program APPEAR like a file.  CPI-C is a set of APIs 
to make APPC programming 
easier and common across IBM platforms -- yet another form of abstraction.  
APPC is the base comms 
layer on which the others are built.

You don't use the override to send back just a piece of data (I assume you mean 
database field).  You 
cannot do that without building your own source/target protocol and programs.  
Overrides are used to 
improve throughput by increasing the blocking factor.  DDM will almost always 
only fetch the record 
you asked for (see first para for the exception).  You improve DDM response in 
exactly the same way as 
local DB response; by fetching more data at one time.  If you need 10 records 
for a selection list use 
blocking to ensure DDM fetches 10 records at once from the remote system.

The same rules apply to DDM as to local DB access: Blocking can only be used 
for input sequential or 
output files -- sequential means reading sequentially either by key or RRN. 
(This is controlled simply 
by the presence or absence of a K in the F-spec -- business as usual.)  The 
other "gotcha" is that 
blocking used badly can decrease throughput.

(As an example of the benefit of proper blocking I have reduced the run time of 
a job from 47 hours to 
12 hours just by sorting the data and using a large blocking factor -- no major 
code changes, just 
using the DB properly.)

Read the DDM reference manual for more information.  There is a section on 
performance.

The "whole idea" is to make the remote file appear local -- but you don't get 
something for nothing.  
You don't need to change your program, just create a DDM file pointing to the 
proper remote file and 
it will still run.  DB takes care of the communication however the file isn't 
local so data access is 
slower.

When you switched from DDM to ICF/APPC you gained more control at the expense 
of extra programming.  
Your ICF program doesn't look exactly like your DDM program.  F-spec uses a 
different file, comms 
keywords added to DDS, etc, etc.


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: Sun, 03 Jan 99 12:37:01 -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
> DDM just does a chain to the remote system and only returns the data that
> you requested over the comm line.  The whole file definitely does not have
> to be transfered.  This is done via an ICF file.  The source system evokes a
> program on the target system that retrives the record requested via the
> CHAIN, and then only returns the record requested.  Note though that the
> entire RECORD is returned, not just the field you need.

i thought ddm and icf were two different things.

when we tried ddm, we set up file overrides to the remote system.  and response 
went down
the drain.  in the override, how do you tell it to only send back a piece of 
data.  i
thought the whole idea was the file was accessed just like it was a local 
system.

we switched to the source/target programming method, where the source program 
would
aquire the correct system, send the request, the data was created on the target 
system,
and then received back via icf.

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