Maarten (John and Helio) Researching another topic, I found this thread - and I hate inaccurate information to persist in the archives. Particularly so when it has been set up by someone who knows something about the topic area but can be excused, where a bit of detail is missing, for jumping to the wrong conclusion!
It must be about 20 years or more ago now that I paid any attention to the details of the autoinstall exit but I am pretty sure I know how the X'38', by which your answer sets some store, is intended to identify the "mismatching bits" - as the text to the left says, after all. Picking up the full sequence and stripping out the uninteresting part so that it can be read clearly - with a non-proportional font, of course - we can see how those bits indicting mismatching work. > CINIT BIND: ... 00000018 5020507F ... > MODEL BIND: ... 00000018 5018507F > MISMATCH BITS: ... 00000000 0038 Indeed, in both the "CINIT BIND" and the "MODEL BIND", the (first) X'1850', 24 and 80 in decimal, referring to the presentation space dimensions established by the "Erase Write" command, are the same. The autoinstall logic is quite happy with the match there and so all mismatch bits are B'0' meaning no mismatch. However, referring to the presentation space dimensions established by the "Erase Write Alternate" command, in the "CINIT BIND" the following X'2050', 32 and 80 in decimal, differs from the "best fit" "MODEL BIND" which has again X'1850'. This is where the autoinstall logic is providing the information that there is a mismatch by highlighting the *bits* which are different. In the upper bits we have X'20' while in the lower bits we have X'01' and so both bits 6 and 7 (0 origin) are different. Thus the byte used to indicate the mismatch is X'30'. Similarly bit 0 is indicted to be different in the following byte. This is *not* a reference to number 56! Again calling on long dormant memories, I think the problem can be solved in one of two ways: 1. Set the emulator up so that it specifies that it will use only the 24x80 presentation space dimensions - called "screen size" in some quarters (!) - so that the "device code" agreed by TELNET negotiation is "IBM-3278-2-E". This will cause the mode table entry name NSX32702 to be selected - assuming the default TELNETDEVICE statement values apply. The BIND image derived from mode table entry name NSX32702 will be acceptable and will match those parts of the BIND image about which CICS cares - in fact corresponding to what is shown as the "best fit" model. Note that, although the default mode table entry name for "IBM-3278-3-E" is NSX32702, the TELNETDEVICE statements to be found in the SEZAINST(TNPROF) sample SNA-oriented TELNET PROFILE data set override this with NSX32703 - which is what we see in the diagnostic output - all caused in all probability by specifying that the presentation space dimensions are 32x80. Well, that's very probably the explanation for what we see here. Actually what is a bit odd is that the mode table entry for when TN3270E protocols are agreed between the client and the server is not being used here. I guess it's just an emulator implementation which is getting on in years! 2. The alternative solution is to ensure that a model definition is in place which will allow matching with the presentation space dimensions which are specified in the BIND image contained in the CINIT request unit, namely 32x80. This is CICS territory so I'll not risk straining my memory and giving false information! Actually a third possibility could be to employ the "dynamic" option for both the emulator customisation and the model definitions. What can happen here is that the "device code" agreed by TELNET negotiation becomes "IBM-DYNAMIC" and the mode table entry name defaults to D4C32XX3. The consequence of this is that a half-duplex (normal conversation) rather than a full-duplex (Mediterranean ladies in supposed conversation) exchanges are imposed - so much more predictable for the end user - *and* it will be possible, depending upon how flexible the emulator is, to define any presentation space dimensions which the primary application, CICS in this case, can tolerate. - Interestingly enough, and in fact before I unearthed this original post, I found the identical post posted one day after the original post and John Giltner's reply in a very curious "blog", http://legacymainframe.wordpress.com/, somewhat moribund to judge from the last activity, May 27, 2010 by Bharathiselvan. This same Bharathiselvan had posted the original question and, even more curiously, the same answer as provided by John Giltner. http://legacymainframe.wordpress.com/2008/03/28/cics-abend-analysis/ I guess he - it is a "he" to judge from a photograph - may have asked permission from both the quoted original authors although neither is acknowledged. - Chris Mason On Mon, 31 Mar 2008 10:05:11 +0200, Maarten Slegtenhorst <[email protected]> wrote: >Hélio, > >> MODEL BIND: 01020271 40200000 00000000 00008000 00000018 5018507F >> MISMATCH BITS: 00000000 00000000 00000000 00000000 00000000 0038 > >1850 and 1850 look like screensizes >1850 is 24 rows, 80 columns > >Apparently your terminal is configured as 3850 ( 56 rows, 80 columns ) and >that is not accepted by the autoinstall. >Take a look at the logmode of your TCP/IP-lu's and at the screensettings of >your tn3270-emulator. > > > > >-- >Maarten Slegtenhorst ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
