Hi all, I need information about command Jes2($AJ), submited for job in execution, i saw in SYSLOG, that it was requeued, carried on in another initiator passed to other step.
Would id be normal behaviour ??? Help is wellcome. Jorge Campos TM SOLUTIONS 2011/10/6, Chris Mason <[email protected]>: > 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 > ---------------------------------------------------------------------- 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
