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
