Article View: bit.listserv.appc-l
Article #428Answer to AS/400 question re: bad APPC performance
From: John Brady (TL 444-4167 or 919 2...
Date: Fri, 18 Jun 1993 20:03
Date: Fri, 18 Jun 1993 20:03
49 lines
3116 bytes
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_BRADYShow 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