Elardus > 'Maximizing the SNA RU size reduces end-to-end acknowledgments at the 3270 > application level.'
This is just common sense. In order to illustrate the point I'm assuming you have to send 10K of data and the flow control parameters are such that each unit of data sent must be acknowledged - just to keep it simple. - If you send 10 units of 1K you are obliged to wait while 10 acknowledgements are returned. - If you send 1 unit of 10K you are obliged to wait while 1 acknowledgement is returned. QED! It's interesting that Bill Gates's men[1] have obscured the fact that, in the document to which Mike Schwab directed our attention, they do not discuss the other topic which it is a dereliction of duty not to discuss when talking about networking performance. The two topics which always go together are (1) the size of data units which can be employed and (2) the flow control regime which applies. Incidentally, the flow control in SNA can be implemented as follows: - the application is such that a limited amount of data is sent before a limited amount of data is received - the application requires definite responses after limited amounts of data are sent - where relatively large volumes are to be sent in one direction such as for a printer application, SNA-defined pacing It is the latter where the PACING and VPACING operands apply - and their use is *very* dependent on the configuration of the path over the SNA network. Except in the case of printers supported by LU type 1, it is usual to set both of these operands to 0 wherever that appear. Also the PSNDPAC, SSNDPAC and SRCVPAC operands of the MODEENT macro corresponding to any mode table entries employed should specify 0. Note that these operands are shown as not specified in the listing of ISTINCLM. Fortunately the default values are 0 - which does *not* apply to the PACING and VPACING operands! In order that you are not further misled, an application imposing its own pacing internally is a contradiction in terms. While most parameters specified in mode table entries, so-called "session parameters", serve as advice to the application[2] (strictly the application using the "record mode" API and not the APPC API), the pacing parameters (reset according to the values specified by PACING, VPACING and AUTH=(N)VPACE operands and the configuration of the path) are "policed" by VTAM and - I expect without ever having actually checked this - other SNA implementations. - Another somewhat misleading comment concerned VTAM's buffer pools. I am a great advocate of regular monitoring of buffer pool patterns of use. First of all I advise that dynamic buffering should be used. Then I advise to guard against "too much" or "too little". - "Too much" means that the initial allocation is (far) too large, will never or hardly ever be reached and is just wasting storage. This obviously has no effect on anything other than the wasted storage. - "Too little" means that there are always/sometimes periods of rapid expansion and contraction. This wastes processor capacity and/but just may be perceptible in terms of network activity - but, with today's machines, unlikely! Note that this is *not* a trivial topic and needs fully to be understood before tinkering begins. - [1] Anyone who has followed my posts in the so-called "BizTalk Server Host Integration Server Forum"[1.1] vainly attempting to correct the impression Gates's men seem to have that they are qualified to advise on anything to do with VTAM will know that I would advise the utmost scepticism over any advice emanating from that quarter. [1.1] http://social.technet.microsoft.com/Forums/en-US/biztalkhis/threads [2] It is relevant to this discussion to point out that, indeed, most of the "session parameters" are there for the application to use if it so desires. Obviously a well-written application might be expected to follow its instructions, as it were, and even refuse to start a session where any parameter was potentially dangerously out of the range supported by the application. Paying attention to these parameters definitely applies to the request unit (RU) sizes. IND$FILE may or may not follow the relevant RU size however large it is. Perhaps someone who really knows IND$FILE can check whether or not there is an upper limit. Alternatively, the point can be checked by someone with a "sandbox" ideally with NetView Session Monitor set up. - Chris Mason On Wed, 19 Sep 2012 12:48:32 -0500, Elardus Engelbrecht <[email protected]> wrote: >Mike Schwab wrote: > >>Here is Microsoft's suggestions for increasing the speed, from 2004. >http://support.microsoft.com/kb/125881 > >Interesting! Thanks Mike! > >I see this eye-catcher from micro$oft on that page: > >'Maximizing the SNA RU size reduces end-to-end acknowledgments at the 3270 >application level.' > >My searches on IBM Internet Library Collection failed to give me more info >about this. Perhaps I used wrong search keywords. Is there any info from IBM >about this tidbit? > >TIA! > >Groete / Greetings >Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
