My customer says, "We are not using SNA serv./6000 API but
LU0 API library directly. You say lu0 server itself
may decide to fragment the packet,and this may be caused by the RU
size being specified is larger than the max I-FIELD for the trans-
mission medium.In the lu0 config program we set max-data field as 2057
where as we set TS protocol field of logical units as 000088880000
(bind bytes 8-13) which I believe corresponds to 2048.Could this be the
reason for fragmentation? In the log file just after the WRITE command
I see a CANCEL command which I believe initiated by the secondary LU
which is a non-IBM machine."
What else can we do, to prevent fragmentation of packets since the
secondary LU requires non-fragmented packets? Could you also send
a simple lu0 configuration example if possible?
The problem is only with the write command (lu0writep subroutine).
Session between the primary and secondary machines are successfully
set and SDT command send has been accepted by the secondary machine.
The PTF you suggested seems to be installed when we check with
lslpp -h command. We still have the 256 byte limitation problem.
ANSWER
I will answer your questions in the order you have presented them:
1. In the lu0 config program we set max-data field as 2057 where as
we set TS protocol field of logical units as 000088880000 (bind
bytes 8-13) which I believe corresponds to 2048. Could this be the
reason for fragmentation?
Yes, this would cause the fragmentation. The reason for it is that
besides TH, whose length is 9 bytes, package also includes RH,
whose length is 3 bytes. Probably RH wasn't considered when setting
up max-data field size on the primary and secondary LUs. This
problem can be resolved by increasing max-data size for the
secondary lu by 3 bytes or decreasing it for the primery lu by 3
bytes.
2. What else can we do, to prevent fragmentation of packets since
the secondary LU requires non-fragemnted packets?
Quality Refresh I provides lu0 with capability to support larger
RUs. Below I appended an excerpt from /usr/lpp/sna/README file
describing this feature:
_________________________________________________________________
LU0 RU SIZES UP TO 3,840 BYTES NOW SUPPORTED
LU0 primary and secondary support now allows RU sizes of up to
3,840 bytes (PIU sizes of up to 3,849 bytes). This is an
enhancement over the previous support of maximum of 256-byte RUs.
To utilize this new size enhancement, your LU0 application must
either use their own PIU structure or the new 'lu0piu_var'
structure defined in the "lu0api.h" include file. the 'lu0piu_var'
structure forces the user to allocate the appropriate size buffer
for the RU size that will be used. For example, if you would like
to use the 3,840 RU size, you would need to do the following:
struct lu0piu_var *buf_ptr; /* Define a pointer */
...
buf_ptr = (struct lu0piu_var *) malloc(MAXPIU);
/* Allocate the buffer */
The MAXPIU vatiable is defined to be '3849' in the "lu0api.h"
include file (the extra nine bytes is for the TH and RH). Then you
will be able to utilize the 'buf_ptr' pointer variable. Freeing
this memory is left to the user's application.
___________________________________________________________________
Quality Refresh I is PTF U404890.
3. The examples of lu0 configuration are given in the book
'Experiences in using AIX Netview Service Point' GG24-3700-00.
4. We still have the 256 byte limitation problem.
S e a r c h - k e y w o r d s:
SNA
WWQA: ITEM: RTA000066135 ITEM: RTA000066135
Dated: 08/1995 Category: ITSAI6000CO
This HTML file was generated 99/06/24~12:43:24
Comments or suggestions?
Contact us