Mike >Here is Microsoft's suggestions for increasing the speed, from 2004. >http://support.microsoft.com/kb/125881
The first point to make here is that the configuration which applies to Bill Gates's SNA Server (BizTalk Server Host Integration Server these grandiloquent days) is probably *not* the same as Laurence Tsai's configuration. - The first topic is "link speed". This is "motherhood"! Two observations: 1. > If you are using Host Integration Server 2004, the fastest link type would be > an IP-DLC link service ... Change "w" to "c" in order actually to make sense! 2. If you have a current, 2010, flavour of Host Integration Server, you can use only the so-called IP-DLC Link Service. - The second topic is the "size of data link control protocol data units". > The host frame size is configured in the MAXDATA= parameter in the PU > definition in VTAM. Not necessarily true and generally not true. This is where the limitations of Gates's men commenting on even topics which involve their own product is shown to be thoroughly unreliable! The poor lambs probably know that SNA Server implements a "Low Entry Networking" (LEN) node and some of them may even be dimly aware that the formal architecture designation for that type of node is 2.1. What they clearly have not grasped is that, with the introduction of the type 2.1 node, as opposed to the type 2.0 (or even type 1) node, the MAXDATA operand of the PU statement representing the adjacent link station is no longer required and there is nearly always no reason to specify it. The reason is that the XID data exchanged between type 2.1 nodes include "Maximum BTU Length" which corresponds to the number specified by the value of the MAXDATA operand. > This setting should match the "Max BTU size" in the SNA Server Connection > configuration dialog in SNA Admin/Manager. Presumably the "Max BTU size" means the same as the "Maximum BTU Length". Obviously with the enhanced capabilities of the XID used between type 2.1 nodes, there is no need for this "matching" with which anti-SNA bigots have tarred anything to do with SNA since time immemorial and Gates's men, whether intentionally or by accident, are continuing the tradition. - The third topic is "request unit sizes". > Maximizing the 3270 Structured Field RU Size Note that this anticipates that the "Write Structured Field (WSF) technique" flavour of IND$FILE will be used. > Maximizing the SNA RU size reduces end-to-end acknowledgments at the 3270 > application level. This reference to "end-to-end acknowledgments at the 3270 application level" refers to definite response units. It has nothing whatsoever to do with pacing as it relates to the PACING and VPACING operands as was confusingly suggested elsewhere. That is the significance of "application level". It's possible that what this is trying to say is that, given the half-duplex nature of request/response unit flow for the IND$FILE application, that the receive buffer is free for another unit of data is assured when the sending side receives a definite response to the previous unit. > An RU is split into multiple messages if the frame size is smaller. More accurately: a request unit with its 3-byte request header can be split into multiple *segments* to each of which a 6-byte (when the adjacent nodes are type 2.1 nodes) transmission header is prepended in order that each segment can fit into a data link control frame. > The RU size supported by the host is configured in the RUSIZES=LU mode entry > (MODEENT). Here we have a thoroughly mangled sentence offered to us! Thoroughly improved: the request unit sizes are defined using the RUSIZES operand of the MODEENT macro used to construct the mode able entry selected for the SNA session. > Here are common values used: > ... It's best simply to refer to famous Figure 6-1, "RU Sizes Corresponding to Values X'ab' in BIND" in the SNA Formats manual in order to decide on request unit sizes. http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/d50a5007/6.3.20 > The RU size is computed ... Whoever wrote this paragraph had had a good night and had enjoyed a strong cup of coffee and so managed to get it all 100% right. However I still prefer the famous Figure 6-1. > Within the 3270 emulator, the structured field file transfer RU size must be > specified in the file transfer configuration. I guess the ability to recognise this depends entirely upon the emulator concerned. I can see no reason why simply relying upon the request unit sizes so laboriously defined in the BIND image is not all that is necessary. Is that anti-SNA bigotry raising its ugly head again? There really should have been some advice on what the default mode table, ISTINCLM, supplies as suitable mode table entries. For example, D4C32XX3 offers RUSIZES=X'87F8' which is interpreted as 3 840 outbound and 1 024 inbound. - There is actually a fourth topic hidden within the third topic which concerns the first two bytes of the presentation services field. > First, the query bit on the LU definition at the host must be enabled in > order to support structured field file transfer. One up to Gates's men for once. I much prefer this emphasis on "WSF" in order to be able to use the "WSF technique" rather than the confusing references to "CUT" and "DFT". Unfortunately, it's still a bit clumsy. Better: the so-called "query" bit in the presentation services field of the BIND image used for the SNA session must be set to one in order to indicate that the "Write Structured Field" command is supported. The BIND image containing the so-called "query" bit is *not* a feature of the "LU definition". > This is enabled in bit 0 (the high order bit) on byte 1 in the PSERVIC > parameter which you can configure in the MODEENT on the 3270 LU's DLOGMODE > mode entry: Clumsier and clumsier! Thus, in the data specified by the PSERVIC operand of the MODEENT macro used to create the mode table entry specified for the TSO session, bit 0 of byte 1 must be set to one. The mode table entry specified for the TSO session can derive from the USS command or, if not specified in the USS command, it can be specified as the value of the DLOGMOD operand of the LU statement corresponding to the TCP TELNET connection. > PSERVIC=X'0280xxxx... > Byte 0 is the LU type (02 in this example) It appears that SNA Server, later Host Integration Server, supports an SNA-oriented TELNET server but that, in addition to emulating 3270 devices as SSCP-dependent LUs, it supports a type 2.1 node incorporating the capabilities of a type 2.0 node in that it supports a necessarily SSCP-dependent type 2 PU. Thus the type of SNA session is type 2. This is in contrast to the SNA-oriented TELNET server provided by the IP component of z/OS Communications Server which can support a type 0 session as well as a type 2 session for sessions with TSO. > PSERVIC=X'0280xxxx... > Byte 1 is used by VSCS ... Rubbish, rubbish, utter rubbish!!! Byte 1 of the presentation services field contains bits with a miscellany of significance, one of which, bit 2, just happens to be used to designate a printer which can be used for the "VM/SNA Console Support" (VSCS) application. See section 5.2.4, "PSERVIC Operand of the MODEENT Macroinstruction" of the VTAM Resource Definition Reference Version 4 Release 2 for MVS/ESA, VM/ESA, and VSE/ESA manual. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/isth1201/5.2.4 Incidentally, VTAM V4R2 is the latest release relevant to VSCS. It dates from 1994! > PSERVIC=X'0280xxxx... > ... > Byte 1 ... and needs to be set as follows: > 80 - Device supports extended data stream capability. "Extended data stream capability" is the formal description for this bit. > It supports write structured field (WSF) and read partition query (Query) > structured field. A little bit clumsy again. As already mentioned the so-called "query" bit indicates that WSF is supported. It is usual that, when a primary LU application such as TSO detects that the BIND image indicates support for WSF, as the first flows in the session, it will send a WSF command containing a "Read Partition/Query" and expect a "Query" reply from the secondary LU. > Otherwise, screen-mode transfer is used, ... Presumably "screen-mode" is the term the Gates's author has invented in order to describe the operation of IND$FILE when it is *not* entitled to use WSF. > ... limiting the data RU size to 1920 bytes. However I am surprised that the request unit size is necessarily limited to 1920 rather than the product of what has been agreed as the presentation space dimensions according to the often rehearsed significance of the tail end of the presentation services field. - Chris Mason On Wed, 19 Sep 2012 12:21:17 -0500, Mike Schwab <mike.a.sch...@gmail.com> wrote: >Here is Microsoft's suggestions for increasing the speed, from 2004. >http://support.microsoft.com/kb/125881 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
