Shmuel, I was indeed intent on correcting the incomplete impression given by the text in the original paper.
According to my understanding of the carefully selected word "sensitive" I had in mind that it was insufficient merely to note the variable screen dimensions - obviously - you have to do something with this information. Regarding "sensitive": I am sensitive to bright lights in my eyes. If a bright light suddenly appears I blink, that is, I do something about it. Similarly I drop a lighted match if I hold onto it for too long. I hope I've made my point. I'm out of the business end these days and I wondered whether or not there was some facility in REXX now to assist in creating 3270 data streams. I expect I should have asked Thomas what he was really trying to do. He has in fact now told us what he was doing - but not with what objective. Pat O'Keefe has now confirmed your point about which codes you should be putting in data for processing as text by a 3270 emulator - or 3270 microcode. I guess I could not be being bold enough here but I expect that, given that the range of codes for orders is X'00' to X'3F', one should avoid all these codes in data "written" from within a TSO REXX program. I once wrote a little 3270 demonstration program, first under CICS and then under NetView, which allowed the 3174 printer authorization matrix to be built on the screen interactively. As a demonstration program I was intent on exploiting 3270 data stream features such as extended highlighting, all the colours and attributes at the character level. A particular feature which, thinking through the dates, I must have added later was highlighting errors not by having the whole error message flashing as NLDM (NetView Session Monitor) did in its first release but by having a flashing rugby (read "American football" across the pond) ball in the spaces of the message. Why am I twittering on like this? Well, it was Pat's upper bound code value, X'3F', that caught my attention. That code I somehow discovered - maybe by playing about like Thomas - corresponded to this blob character. I have a vague memory of actual 3270 displays - as opposed to emulators on the PC - where the dimensions could be "customized". (I used to play with 3290s at one time - even using them in an exhibition for Network Management and having the punters think we were pushing 3290s. There were a range of customizing tricks possible on that delightful machine - physically not unlike the monitor I am seeing all this typed up on, come to think of it - well, it's not all orange of course.) Again, if you allow my carefully chosen shorthand, "the maximum of which it is capable" was intended to take into account any customization which might have limited or partitioned the dimensions in some way. Clearly, since I've mentioned the 3290, each of say 4 sessions is not going to be using the whole display surface. This reminds me that the reason I used the 3290 at the exhibition was in order to present characters with the standard 24 by 80 dimensions on the whole display surface. The odd thing is that the characters looked bigger but they were only more spread out. Chris Mason ----- Original Message ----- From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Monday, 19 December, 2005 1:22 PM Subject: Re: Creating dynamic 3270 screen size definitions for increased productivity > In <[EMAIL PROTECTED]>, on 12/17/2005 > at 05:54 PM, Chris Mason <[EMAIL PROTECTED]> said: > > >The original paper says "TSO applications will now automatically use > >the larger screen size whenever needed. > > That's false. In general, the application can only adapt to different > screen configurations if it has code to test for them. What is true is > that ISPF has such code, and has had it for a long time. > > >What maybe it should have said was "TSO applications which are > >sensitive to variable screen dimensions will now automatically ...". > > Not even that. They can use the larger screen size, but only if they > have the code to do so. Just doing a READ PARTITION - QUERY isn't > enough; they have to actually use the query response appropriately. > > Normally a program written in REXX will not be able to accommodate > multiple screen geometries. In order to do so it must use an external > package for terminal I/O, e.g., ISPF, installation-written fullscreen > function package. > > IAC, a program intended for use with a 3270 protocol must avoid any > text characters at the same code point as a 3270 order, e.g., 7E. It > should use such values only whaen they are3 intended to be 3270 > orders. > > >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 > > I believe that D4C32XX3 allows the terminal to set the primary screen > size to other values. > > >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. > > No, it sets it to the alternate screen size, which can be smaller than > what the display is capable of. As far back as the 3180 there were > 3270 terminals that the user could set to a restricted screen size. > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > ISO position; see <http://patriot.net/~shmuel/resume/brief.html> > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) ---------------------------------------------------------------------- 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
