🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: bit.listserv.appc-l
Article #428

Answer to AS/400 question re: bad APPC performance

#428
From: John Brady (TL 444-4167 or 919 2...
Date: Fri, 18 Jun 1993 20:03
49 lines
3116 bytes
Here's what the AS/400 developers have to say:


Manfred,
   I read your note on the APPC performance and I thought I would see if
I could help you out.   The first thing that jumped out at me was your
"DATA TRUNCATION".  This indicates that the ICF DDS record format that
you are receiving the data with is not large enough to hold the entire
record and the data which is in excess of the record format size is
being discarded.  This will definitely slow your performance down.  I
would suggest that you use the TRCICF tool to trace what your ICF
application is doing.  Since you are on the server side, you need to do
something a little tricky.  You have to create a CL program with the
same name as your server program and re-name your server program
temporarily.  For example, assume that your server program is called X.
Rename it to X1.  Here is what the "X" CL program would look like:
PGM
   TRCICF MAXSTG(16000)
   CALL X1
   TRCICF *OFF
ENDPGM

That will create a spool file containing a trace of your server program
from an ICF perspective.  It will show data lengths, record format
names, and ICF return code among other things.  This trace should show
you where you are running into your data truncation problem.  One sure
way to fix it is to define a record format of length 32767 and always
using that for a receive.   In case you didn't know, you set the record
format name on a receive by setting  _Rformat.

You also mentioned switching to CPI-C.  This may give you a slight
performance advantage, but very slight.  Also, CPI-C behaves a little
different that ICF.  For example, your "DATA TRUNCATED" turns into
something called "DATA INCOMPLETE".  The difference is that for CPI-C
the data in excess of the receive length is not thrown away, but
returned on later receive operations.  Also, CPI-C does not support
security, while ICF does.  There are other differences, but those are
two major ones.

Another thing, are you using the CONFIRM DDS keyword often?  This will
slow things down.

Well, those are a few things you could look for.  I hope they help.

--- Glenn Pederson
--- IBM AS/400 APPC/CPI-C/ICF Development
--- Internal address: RCHLAND(GLENN) or IBMMAIL(USIB1F6A)
--- Internet address: glenn@vnet.ibm.com
--- Glenn Pederson
Technical Details
Message-ID: <APPC-L%93061816033314@AMERICAN.EDU>
Path: arc1-ca.pugleaf.net!gmd.de!newsserver.jvnc.net!howland.reston.ans.net!paladin.american.edu!auvm!VNET.IBM.COM!JOHN_BRADY

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 10aed9,d4204b564104421,start
X-Google-Attributes: gid10aed9,public
X-Google-ArrivalTime: 1993-06-18 13:11:40 PST
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Path: arc1-ca.pugleaf.net!gmd.de!newsserver.jvnc.net!howland.reston.ans.net!paladin.american.edu!auvm!VNET.IBM.COM!JOHN_BRADY
Return-Path: <@AUVM.AMERICAN.EDU:owner-appc-l@AUVM.AMERICAN.EDU>
Return-Path: <@AUVM.AMERICAN.EDU,@CUNYVM.CUNY.EDU:john_brady@VNET.IBM.COM>
Message-ID: <APPC-L%93061816033314@AMERICAN.EDU>
Newsgroups: bit.listserv.appc-l
Date:         Fri, 18 Jun 1993 16:03:07 EDT
Sender:       APPC Discussion List <APPC-L@AUVM.BITNET>
From:         "John Brady (TL 444-4167 or 919 2)" <john_brady@VNET.IBM.COM>
Subject:      Answer to AS/400 question re: bad APPC performance
Lines: 49