Thomas, I've just replied to Shmuel and, in the process of doing so, I wondered what your objective was in running this little REXX program - just curious.
You seem to conclude that the 3270 emulator is not the culprit whereas I am tempted to think that maybe it is. And I'm supported in this by Sam Knutson who is able to get different results from different emulators. What you might like to do is take some of your local VTAM specialist's time and get him to show you what is flowing on the session between your TSO and the emulator LU - using NLDM CPIU trace is easiest. Note that you will have "bugged" him to do this. Please take particular care to note how I spelled that verb. I'm sure all of the newsgroup who noted and understood your spelling will have made appropriate allowances. What you should be able to see in the trace is who complained - a negative response with a juicy sense code to set the investigative juices flowing - and when. You may even like to adjust your program to require some input after each character is presented so that you can work out precisely which one or ones cause(s) the PROG755 and the IKT00405I message. One can say that "IKT" messages are from both TSO and VTAM since the programming responsible is from VTAM development. There was a messy situation at one time when TSO was in some way part of TCAM and this programming then had to interface with VTAM. I hope I can be corrected by someone who recalls sufficiently far back to know precisely what the sequence of events was perhaps together with approximate dates just to satisfy the curious. (I can't help feeling the name TCAS has some connection with TCAM.) At some level in the path from the general VTAM application interface to the TSO address space programming, the IKT modules pass over into the IKJ modules. Chris Mason ----- Original Message ----- From: "Thomas Berg" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Tuesday, 20 December, 2005 9:22 AM Subject: SV: Creating dynamic 3270 screen size definitions for increased productivity Yes, I still have this problem. As normal ISPF/TSO usage is working I still haven't buggered my sysprog or VTAM prog with this. And also as I want to collect more info of possible reasons of this behaviour. What I'm doing is running this REXX (just a test to confirm what is happening): /* REXX */ Do i = 0 To 255 Say i': hex' D2x(i)':' '>'D2c(i)'<' End Exit 0 - with the following results; first at couple of: IKT00405I SCREEN ERASURE CAUSED BY ERROR RECOVERY PROCEDURE *** - then: IKT00405I SCREEN ERASURE CAUSED BY ERROR RECOVERY PROCEDURE 48: hex 30: > 72: hex 48: >ç< 73: hex 49: >ñ< 74: hex 4A: >§< 75: hex 4B: >.< 76: hex 4C: ><< 77: hex 4D: >(< 78: hex 4E: >+< 79: hex 4F: >!< 80: hex 50: >&< 81: hex 51: >`< *** - etc. (The rest of the characters displays whithout any problems.) NOTE that this does NOT happen when running in my old/normal setup with 43x80 resolution. I'm running IBM's PCOM 4.1 for Win NT and the host is: z/OS 01.06.00, TSO version 3.6.0, VTAM Level 6.1. Except for this problem, my choosen resolution of 51x116 of works fine even in plain TSO (outside ISPF). I followed the example in the IBM link except for e g the "HostCodePage" as I'm in Sweden. Now, as the output is from the host and the error message is from either TSO or VTAM (anybody knows exactly which of them that is initiating the error, QuickRef just says: "Explanation: TSO/VTAM erased the screen as part of the I/O error recovery procedure." ?), the 3270 emulator seems not to be the culprit. TIA Thomas Berg -----Ursprungligt meddelande----- Från: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] För Chris Mason Skickat: den 17 december 2005 17:54 Till: [email protected] Ämne: Re: Creating dynamic 3270 screen size definitions for increased productivity Thomas, I'm sorry. I found this e-mail in my Drafts folder. If you still have a problem, it may help. If you don't have a problem any more, perhaps you can explain to us all how you solved it. The original paper says "TSO applications will now automatically use the larger screen size whenever needed. For example, SDSF will display spool files in their full width of 132 characters while displaying nearly 50 lines of the file." ... In order to check this out, if you can see in the REXX clist where the first output data stream is written, you should ensure that the "Erase Write" command is the first byte rather than the "Erase Write Alternate". With the standard IBM-supplied mode table entry, D4C32XX3, "Erase Write", 0xF5, instructs the display microcode or the emulator programming that the screen is to have 24 rows of characters in 80 columns while "Erase Write Alternate", 0x7E, instructs the display microcode or the emulator programming that the screen is to adopt whatever is the maximum of which it is capable. In the case of PCOM, the maximum is what you specified with the ScreenSize keyword. Note that the screen dimensions defined by PCOM are made known to the VTAM application, in our case TSO, by a required fancy exchange of information at the beginning of the SNA session. ... You did hint that you suspected the byte values in your data stream. ... Chris Mason ----- Original Message ----- From: "Thomas Berg" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Monday, 31 October, 2005 8:55 PM Subject: VB: Creating dynamic 3270 screen size definitions for increased productivity TD102151 > I'm trying this now, but having some problems. > > I'm getting: > IKT00405I SCREEN ERASURE CAUSED BY ERROR RECOVERY PROCEDURE when e g running rexx that displays text containing characters with hexvalues below x'73' or even in the range x'74' - x'79'. (The same rexx is running and displaying without problems in my usual 43x80 "mode".) > > I suppose this has something to do with some character translation > table for TSO or VTAM ? ... > -----Ursprungligt meddelande----- > Från: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] För Knutson, Sam > Skickat: den 13 oktober 2005 14:47 > Till: [email protected] > Ämne: Creating dynamic 3270 screen size definitions for increased productivity TD102151 > > > It's not new news around IBM-MAIN but I stumbled on this note in the > WSC library which says the same thing Ed has said for many years about letting go of the real 3270 screen geometries. It might be useful to help convince others in your organization that this is really a good idea. > > Thanks, Sam > > http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD102151 ---------------------------------------------------------------------- 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
