Re: Reduced 3270 Screen Geometry

[Shmuel Metz (Seymour J.)]

In <4e0a7008.8050...@valley.net>, on 06/28/2011
   at 08:21 PM, Gerhard Postpischil  said:

>I have to plead ignorance on that. It's been too many decades to 
>remember the details (I normally use Wylbur rather than TSO),  but I
>was under the impression that a key declared as the Reshow  key
>causes a redisplay without involving the application?

That depends very much on the options used. Take a look at your code
for EXHIBIT under TSO; as I recall it dotted the I's and crossed the
T's.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Shmuel Metz (Seymour J.)]

In <4e09f1b1.2000...@valley.net>, on 06/28/2011
   at 11:22 AM, Gerhard Postpischil  said:

>There is no formal mechanism to let TSO announce a change in  screen
>size.

However, PA2 is defined as a reshow key for TSO, and there are return
codes defined as I/O error.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Scott Rowe]

Then it sounds like ISPF need to have logic added to do a GTTERM on either
an I/O error or a PA2 (RESHOW), and then needs to implement a way to
communicate any geometry changes to any applications that may have an
interest.

On Wed, Jun 29, 2011 at 10:30 AM, Edward Jaffe
wrote:

> On 6/28/2011 3:32 PM, Paul Gilmartin wrote:
>
>> Since it is my habit (as I suspect of many users) to press
>> PA2 when the screen is garbled, might that be a good key
>> to the programmer to issue the (QUERY)?
>>
>
> That is exactly what Greg Price suggested earlier in this thread. REVIEW
> re-sizes the screen when you press the RESHOW key.
>
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> 310-338-0400 x318
> edja...@phoenixsoftware.com
> http://www.phoenixsoftware.**com/ 
>
> --**--**--
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at 
> http://bama.ua.edu/archives/**ibm-main.html
>

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
confidential and privileged information intended only for the addressee.
If you are not the intended recipient, please be advised that you have
received this material in error and that any forwarding, copying, printing,
distribution, use or disclosure of the material is strictly prohibited.
If you have received this material in error, please (i) do not read it,
(ii) reply to the sender that you received the message in error, and
(iii) erase or destroy the material. Emails are not secure and can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by email. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Edward Jaffe]

On 6/28/2011 3:32 PM, Paul Gilmartin wrote:

Since it is my habit (as I suspect of many users) to press
PA2 when the screen is garbled, might that be a good key
to the programmer to issue the (QUERY)?


That is exactly what Greg Price suggested earlier in this thread. REVIEW 
re-sizes the screen when you press the RESHOW key.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Gerhard Postpischil]

On 6/28/2011 6:32 PM, Paul Gilmartin wrote:

Since it is my habit (as I suspect of many users) to press
PA2 when the screen is garbled, might that be a good key
to the programmer to issue the (QUERY)?


I have to plead ignorance on that. It's been too many decades to 
remember the details (I normally use Wylbur rather than TSO), 
but I was under the impression that a key declared as the Reshow 
key causes a redisplay without involving the application? While 
this doesn't preclude using PA2, I have no way of trying this.



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Paul Gilmartin]

On Tue, 28 Jun 2011 11:22:25 -0400, Gerhard Postpischil wrote:

>On 6/27/2011 5:48 PM, Shmuel Metz (Seymour J.) wrote:
>> Why? The correct response to a change in geometry is to write a READ
>> PARTITION (QUERY) and to adjust to the new screen geometry. That
>> should elimenate the garbage whether the new size is smaller, larger
>> or the same.
>
>There is no formal mechanism to let TSO announce a change in
>screen size. The closest would be an error on the terminal due
>to a screen size modified to a smaller character count. So an
>I/O error on a TPUT might justify the Query, assuming the
>program can copy with the results, but a TPUT without error, to
>a larger screen size, may go undetected except by the viewer.
>
>Whether or not an error occurs also depends on the interface. A
>local non-SNA may not produce an error, and even the more
>obvious case where a session is suspended and the user does a
>RECONNECT from a different geometry is not addressed.
>
Since it is my habit (as I suspect of many users) to press
PA2 when the screen is garbled, might that be a good key
to the programmer to issue the (QUERY)?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Gerhard Postpischil]

On 6/27/2011 5:48 PM, Shmuel Metz (Seymour J.) wrote:

Why? The correct response to a change in geometry is to write a READ
PARTITION (QUERY) and to adjust to the new screen geometry. That
should elimenate the garbage whether the new size is smaller, larger
or the same.


There is no formal mechanism to let TSO announce a change in 
screen size. The closest would be an error on the terminal due 
to a screen size modified to a smaller character count. So an 
I/O error on a TPUT might justify the Query, assuming the 
program can copy with the results, but a TPUT without error, to 
a larger screen size, may go undetected except by the viewer.


Whether or not an error occurs also depends on the interface. A 
local non-SNA may not produce an error, and even the more 
obvious case where a session is suspended and the user does a 
RECONNECT from a different geometry is not addressed.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Shmuel Metz (Seymour J.)]

In <4e08ac3e.6050...@valley.net>, on 06/27/2011
   at 12:13 PM, Gerhard Postpischil  said:

>As you pointed out, return codes from TSO macros need to be  checked,
>but unless the user switches to a smaller screen size,  an error may
>not be forthcoming, only garbage on the screen.

?

Why? The correct response to a change in geometry is to write a READ
PARTITION (QUERY) and to adjust to the new screen geometry. That
should elimenate the garbage whether the new size is smaller, larger
or the same.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Shmuel Metz (Seymour J.)]

In , on 06/27/2011
   at 11:42 AM, Paul Gilmartin  said:

>You can't win.

Not without correct coding.

>Switching to a larger screen size may result in
>buffer overrun; 

Not if you allocate the buffer with the correct size and check
addresses against the end address.

>switching to a smaller screen size may result
>in display overrun.

Again, not with correct coding.

>And switching to the same size but a different shape 
>(e.g. 30x80 <-> 24x100) results in garbage on the screen.

Why would you write code that detects a change in screen geometry but
doesn't check what the new geometry is? 

 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Gerhard Postpischil]

On 6/27/2011 12:31 PM, Chris Mason wrote:

Thus 081B is related to half-duplex flip-flop. If you needed to handle this in
your VTAM program, you dropped the baton!


When our VTAM came up, I sent an invitation screen to every 
terminal (in appropriate categories). Then the ladies came in 
and dropped their handbags on the keyboard - resulted in all 
sorts of fascinating errors.



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Paul Gilmartin]

On Mon, 27 Jun 2011 12:13:50 -0400, Gerhard Postpischil wrote:
>
>As you pointed out, return codes from TSO macros need to be
>checked, but unless the user switches to a smaller screen size,
>an error may not be forthcoming, only garbage on the screen.
>
You can't win.  Switching to a larger screen size may result in
buffer overrun; switching to a smaller screen size may result
in display overrun.  And switching to the same size but a
different shape (e.g. 30x80 <-> 24x100) results in garbage
on the screen.  The fundamental design blunder is that 327x
screen addressing is not in terms of X-Y coordinates but in
serial character cells on the display.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Chris Mason]

Gerhard



1.1.1.42 Sense code 082B

Presentation space integrity lost: Presentation space integrity lost (for 
example, cleared or changed) because of a transient condition, for example, 
because of a transient hardware error or an end-user action such as allowing 
presentation services to be used by the SSCP. 



This is used when there has been a change of session from LU-LU to SSCP-LU 
back to LU-LU. The primary LU needs to know that the data on the 
presentation space is not what the primary LU is entitled to expect. Thus, in 
response to an 082B, a complete refresh of the presentation space with an 
Erase/Write or Erase/Write-Alternate is going to be required.



1.1.1.27 Sense code 081B

Receiver in transmit mode (a race condition): Normal-flow request received 
while the half-duplex contention state was not-receive, (*S,¬R), or while 
resources (such as buffers) necessary for handling normal-flow data were 
unavailable. (Contrast this sense code with sense code X'2004', which signals 
a protocol violation.) 



Thus 081B is related to half-duplex flip-flop. If you needed to handle this in 
your VTAM program, you dropped the baton!

Chris Mason

On Mon, 27 Jun 2011 12:13:50 -0400, Gerhard Postpischil 
 wrote:

>On 6/27/2011 7:45 AM, Shmuel Metz (Seymour J.) wrote:
>> AFAIK, there's nothing in VTAM that would be affected by a change in
>> screen geometry. VTIOC is fairly small and TIOC is dead. Yes, TSO has
>> multiple TCB's, but other than SM I'm not aware of any TSO code that
>> is affected by screen geometry. It's ISPF that is the problem.
>
>I seem to recall a VTAM error code of 081B or 082B upon a screen
>size change with local non-SNA terminals (my highly modified
>NETSOL has specified recovery for those). Also the buffer sizes
>and pools may impose constraints.
>
>I think you would find a problem whenever the geometry is
>changed within any running program.
>
>> All of the plumbing is in place for a TSO command to recognize and
>> respond to a change in geometry.
>
>As you pointed out, return codes from TSO macros need to be
>checked, but unless the user switches to a smaller screen size,
>an error may not be forthcoming, only garbage on the screen.
>
>
>Gerhard Postpischil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Gerhard Postpischil]

On 6/27/2011 2:50 AM, Chris Mason wrote:

You are invited to compare pages 5-16 and 5-18 of the following:

IBM 3270 Systems Information Display System Installation Manual - Physical
Planning

http://computer-refuge.org/bitsavers/pdf/ibm/system3/GA27-2787-
5_IBM3270_InformationDisplaySystem_InstallationManu
al_PhysicalPlanning_Dec80.pdf


Note that the 3277-1 is much larger than needed to support the 
screen size.




Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Gerhard Postpischil]

On 6/27/2011 7:45 AM, Shmuel Metz (Seymour J.) wrote:

AFAIK, there's nothing in VTAM that would be affected by a change in
screen geometry. VTIOC is fairly small and TIOC is dead. Yes, TSO has
multiple TCB's, but other than SM I'm not aware of any TSO code that
is affected by screen geometry. It's ISPF that is the problem.


I seem to recall a VTAM error code of 081B or 082B upon a screen 
size change with local non-SNA terminals (my highly modified 
NETSOL has specified recovery for those). Also the buffer sizes 
and pools may impose constraints.


I think you would find a problem whenever the geometry is 
changed within any running program.



All of the plumbing is in place for a TSO command to recognize and
respond to a change in geometry.


As you pointed out, return codes from TSO macros need to be 
checked, but unless the user switches to a smaller screen size, 
an error may not be forthcoming, only garbage on the screen.



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Gerhard Postpischil]

On 6/27/2011 7:46 AM, Shmuel Metz (Seymour J.) wrote:

Yes. I don't recall whether that was the 3277-1 or one of the 2260
models.


The only 2260 size I remember is 12*80.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

TSO SDSF + Large Screen (was Re: Reduced 3270 Screen Geometry)

[Mark Zelden]

On Thu, 23 Jun 2011 07:30:39 -0500, Chase, John  wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
>>
>> On Wed, 22 Jun 2011 14:34:11 +, Rob Scott
> wrote:
>> >
>> >FYI : SDSF does support large screens in TSO mode (rather than ISPF)
>- I
>> have just checked in 62x160 and it handles it fine.
>>
>> What version are you using?  I am using 62 x 142 on z/OS 1.11 at
>> RSU1103 and it still doesn't work.  I get a menu fine, but if I type
>any
>> commands like "DA" my terminal is so hosed up I can't even get an
>> END excepted.  The "LOG" command produces some really interesting
>> results of asterisks covering half my screen.
>
>Weird.  I configured an emulator session (Bluezone) for 62x142, and from
>TSO Ready SDSF presents its menu, but nothing else.  The commands, (DA,
>LOG, etc.) appear to be accepted, but the menu remains displayed.  PF4
>exits just fine; END command does nothing.
>
>When I put the emulator back to "Model 3290" (62x160), it works fine.
>Running z/OS 1.11 at RSU1101.
>

Yeah, I saw the same thing on one of my sandbox systems.  I'm not sure
what the difference is that causes SDSF to ignore all the input as opposed
to displaying back garbage.  

Rob, are you sure this works beyond getting a menu for you?   What 
OS version are you running and what RSU level?

Anyone else get this to work?

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Shmuel Metz (Seymour J.)]

In <4e07ef3c.1000...@valley.net>, on 06/26/2011
   at 10:47 PM, Gerhard Postpischil  said:

>For ISPF, there are multiple programs that need to support the 
>change, VTAM, TIOC, TSO (recall that TSO has multiple TCBs, even  if
>not all of them are running), and ISPF (or SDSF). Proper  support
>requires that some of them acquire differently sized  buffers,
>communicate the change, etc.. It's not impossible, just  costly.

AFAIK, there's nothing in VTAM that would be affected by a change in
screen geometry. VTIOC is fairly small and TIOC is dead. Yes, TSO has
multiple TCB's, but other than SM I'm not aware of any TSO code that
is affected by screen geometry. It's ISPF that is the problem.

All of the plumbing is in place for a TSO command to recognize and
respond to a change in geometry. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Shmuel Metz (Seymour J.)]

In <4e07efa6.2010...@valley.net>, on 06/26/2011
   at 10:49 PM, Gerhard Postpischil  said:

>Or possibly smaller. I seem to recall a 12*40 unit that was way 
>oversize for its screen (same size as 24*80 3277).

Yes. I don't recall whether that was the 3277-1 or one of the 2260
models.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Chris Mason]

Gerhard

You are invited to compare pages 5-16 and 5-18 of the following:

IBM 3270 Systems Information Display System Installation Manual - Physical 
Planning

http://computer-refuge.org/bitsavers/pdf/ibm/system3/GA27-2787-
5_IBM3270_InformationDisplaySystem_InstallationManu
al_PhysicalPlanning_Dec80.pdf

Chris Mason

On Sun, 26 Jun 2011 22:49:10 -0400, Gerhard Postpischil 
 wrote:

>On 6/20/2011 6:10 PM, Edward Jaffe wrote:
>> I just reduced the screen geometry of my 3270 displays from
>> 90x142 down to 68x142 due to ever-increasing eye strain. When I
>> started in this business, I worked with a 24x80 display. At this
>> rate, I'll probably retire with the same screen geometry I
>> started with... :-D
>
>Or possibly smaller. I seem to recall a 12*40 unit that was way
>oversize for its screen (same size as 24*80 3277).
>
>
>Gerhard Postpischil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Ken Brick]

On 27/06/2011 12:49 PM, Gerhard Postpischil wrote:


Or possibly smaller. I seem to recall a 12*40 unit that was way 
oversize for its screen (same size as 24*80 3277).


3277-M1 the 24*80 was 3277-M2 from memory

Ken

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Gerhard Postpischil]

On 6/20/2011 6:10 PM, Edward Jaffe wrote:

I just reduced the screen geometry of my 3270 displays from
90x142 down to 68x142 due to ever-increasing eye strain. When I
started in this business, I worked with a 24x80 display. At this
rate, I'll probably retire with the same screen geometry I
started with... :-D


Or possibly smaller. I seem to recall a 12*40 unit that was way 
oversize for its screen (same size as 24*80 3277).



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Gerhard Postpischil]

On 6/20/2011 7:05 PM, Paul Gilmartin wrote:

o What terminal emulators have a useful zoom function?


Some support the Windows Ctrl+ function to increase the font, 
others allow specifying the font size (or both).



o Does any terminal emulator provide dynamic geometry change
   during a session?  ISPF wouldn't tolerate it; I know;
   disconnecting from an ISPF session and reconnecting with
   a different geometry results in an endless iterative
   "TERMINAL I/O ERROR".  I can't even SAVE and END.  But
   that's ISPF tunnel vision.


Apparently you're changing the screen size in your active 
session using the emulator; I know of no software that support 
this correctly. However, some packages (e.g., BlueZone) supports 
explicit partition sizes as set by the running program. While 
this doesn't work with ISPF either, it is quite handy for 
non-TSO applications (think 32180 and 3290 support).







  OTOH:


o If I disconnect from a VM/CMS XEDIT session, then reconnect
   with a different terminal geometry, I merely press PA2
   and XEDIT refreshes the screen correctly in the new
   geometry.  Why can't ISPF be as smart?  Increasingly relevant
   as TSO's "RECONNECT" becomes more sophisticated.  Of course,
   if I did this in the midst of a complex XEDIT macro that
   depended on screen geometry and couldn't handle the SIGWINCH,
   I'd expect misbehavior.


ISPF wasn't written to handle that, presumably because IBM 
didn't want to spend resources on something that can't be 
justified - they sell more hardware if you have one real 
terminal for each size, and they didn't anticipate the almost 
total replacement by emulator.



o If I disconnect from a TSO READY prompt and reconnect with
   a different screen geometry, TSO continues in line mode
   savvy to the change.  Why doesn't TSO pass notification
   of this change to ISPF if it's running, and/or why doesn't
   ISPF accommodate?


For ISPF, there are multiple programs that need to support the 
change, VTAM, TIOC, TSO (recall that TSO has multiple TCBs, even 
if not all of them are running), and ISPF (or SDSF). Proper 
support requires that some of them acquire differently sized 
buffers, communicate the change, etc.. It's not impossible, just 
costly.



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Shmuel Metz (Seymour J.)]

In <4e025c9c.5020...@phoenixsoftware.com>, on 06/22/2011
   at 02:20 PM, Edward Jaffe  said:

>All screens are garbled with 68x80 default size and 68x142 alternate.
>I think  this particular code may have been written back in the
>1980s.

Does the code support 14-bit addressing? What's in TSOKEYxx?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Shmuel Metz (Seymour J.)]

In <4e01fbe4.1010...@phoenixsoftware.com>, on 06/22/2011
   at 07:27 AM, Edward Jaffe  said:

>A command processor is not expected to issue GTTERM and adapt to any
>changes in  screen geometry prior to every terminal I/O.

But it is expected to test return codes from the macros it issues.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Greg Price]

Paul Gilmartin wrote:
> This "standard procedure" is of little avail to the user who can't
> get past the I/O error to issue the SAVE and END commands.  Surely
> issuing GTTERM would be a reasonable component of recovering from
> a terminal I/O error.

When running pre-z software the TSO LOGON RECONNECT is less than
perfect sometimes, so I put a GTTERM call in the screen reshow logic
of REVIEW, and if the screen size has changed it passes that back to
the browser/editor instead of just resending the lastest screen contents.
It seemed to work well enough under testing.

Cheers,
Greg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
> 
> On Wed, 22 Jun 2011 14:34:11 +, Rob Scott
 wrote:
> >
> >FYI : SDSF does support large screens in TSO mode (rather than ISPF)
- I
> have just checked in 62x160 and it handles it fine.
> 
> What version are you using?  I am using 62 x 142 on z/OS 1.11 at
> RSU1103 and it still doesn't work.  I get a menu fine, but if I type
any
> commands like "DA" my terminal is so hosed up I can't even get an
> END excepted.  The "LOG" command produces some really interesting
> results of asterisks covering half my screen.

Weird.  I configured an emulator session (Bluezone) for 62x142, and from
TSO Ready SDSF presents its menu, but nothing else.  The commands, (DA,
LOG, etc.) appear to be accepted, but the menu remains displayed.  PF4
exits just fine; END command does nothing.

When I put the emulator back to "Model 3290" (62x160), it works fine.
Running z/OS 1.11 at RSU1101.

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Rick Fochtman]

Shmuel Metz (Seymour J.) wrote:


In <4e00b8cf.7060...@dignus.com>, on 06/21/2011
  at 11:29 AM, Thomas David Rivers  said:

 


I've been told that the newer "flexible" lenses they use as
replacements in cateracts surgery solve this problem;
   



My insurance didn't cover those.

 


Now, it seems, I need cateracts :-)
   



I would have been perfectly happy to let someone el;se have mine :-(

 


Or mine --- both of them.. :-((   (No insurance!)

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Mark Zelden]

On Wed, 22 Jun 2011 21:24:06 +, Rob Scott  wrote:

>Mark
>
>Have you got the following in TSOKEYxx?
>
>HIBFREXT=96000
>

Yes
>
>For later releases of z/OS this prevents some hang conditions with wide
screen geometry in TSO and ISPF applications
>

Exactly what I was going to point out.  I would be having ISPF problems
also if I didn't.   It's just SDSF if TSO mode that doesn't work.

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Rob Scott]

Mark

Have you got the following in TSOKEYxx?

HIBFREXT=96000


For later releases of z/OS this prevents some hang conditions with wide screen 
geometry in TSO and ISPF applications


Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Mark Zelden
Sent: 22 June 2011 21:22
To: IBM-MAIN@bama.ua.edu
Subject: Re: Reduced 3270 Screen Geometry

On Wed, 22 Jun 2011 14:34:11 +, Rob Scott  wrote:

>> Last time I checked it didn't even support 'large' screens except 
>> under
ISPF, so I think it's very old code.
>
>FYI : SDSF does support large screens in TSO mode (rather than ISPF) - 
>I
have just checked in 62x160 and it handles it fine.

What version are you using?  I am using 62 x 142 on z/OS 1.11 at
RSU1103 and it still doesn't work.  I get a menu fine, but if I type any 
commands like "DA" my terminal is so hosed up I can't even get an END excepted. 
 The "LOG" command produces some really interesting results of asterisks 
covering half my screen.

>
>These days I cannot imagine many people actually using SDSF too much 
>from
the READY prompt
>

What Bob said. :-)

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Edward Jaffe]

On 6/22/2011 1:21 PM, Mark Zelden wrote:


What version are you using?  I am using 62 x 142 on z/OS 1.11 at
RSU1103 and it still doesn't work.  I get a menu fine, but if I type any
commands like "DA" my terminal is so hosed up I can't even get an
END excepted.  The "LOG" command produces some really interesting
results of asterisks covering half my screen.


All screens are garbled with 68x80 default size and 68x142 alternate. I think 
this particular code may have been written back in the 1980s.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Mark Zelden]

On Wed, 22 Jun 2011 14:34:11 +, Rob Scott  wrote:

>> Last time I checked it didn't even support 'large' screens except under
ISPF, so I think it's very old code.
>
>FYI : SDSF does support large screens in TSO mode (rather than ISPF) - I
have just checked in 62x160 and it handles it fine.

What version are you using?  I am using 62 x 142 on z/OS 1.11 at
RSU1103 and it still doesn't work.  I get a menu fine, but if I type any
commands like "DA" my terminal is so hosed up I can't even get an
END excepted.  The "LOG" command produces some really interesting
results of asterisks covering half my screen.

>
>These days I cannot imagine many people actually using SDSF too much from
the READY prompt
>

What Bob said. :-)

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Edward Jaffe]

On 6/22/2011 9:28 AM, Paul Gilmartin wrote:

On Wed, 22 Jun 2011 07:27:48 -0700, Edward Jaffe wrote:

On 6/20/2011 4:05 PM, Paul Gilmartin wrote:

ISPF wouldn't tolerate it; I know;
disconnecting from an ISPF session and reconnecting with
a different geometry results in an endless iterative
"TERMINAL I/O ERROR".  I can't even SAVE and END.  But
that's ISPF tunnel vision.  OTOH:

A command processor is not expected to issue GTTERM and adapt to any changes in
screen geometry prior to every terminal I/O. Rather, standard procedure is to
issue GTTERM once per command. When the command ends, the user can rebind and
run another command at the new dimensions.


This "standard procedure" is of little avail to the user who can't
get past the I/O error to issue the SAVE and END commands.  Surely
issuing GTTERM would be a reasonable component of recovering from
a terminal I/O error.  Don't tell me; let me guess: the command
processor is never notified of unrecoverable terminal I/O errors,
not even by RC/RSN value.


That's not a very workable solution and hardly reasonable. Only a small subset 
of issues after an incompatible reconnect will result in an I/O error. (Yes, 
they are detectable.)


You would be *far* better off with an exit of some sort (ala STAX) being driven 
when a reconnect occurs. The exit could set a flag to let the mainline code know 
it needs to resize the geometry and reassess the capabilities of the device 
before the next read/write of a 3270 message. Command processors could use this 
facility to dynamically adjust as necessary; I'm sure we could/would use it in 
our software.


There's no reason ISPF couldn't tap into such a facility as well. How it would 
communicate the information to running ISPF applications is another question.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Paul Gilmartin]

On Wed, 22 Jun 2011 07:27:48 -0700, Edward Jaffe wrote:

>On 6/20/2011 4:05 PM, Paul Gilmartin wrote:
>
>>ISPF wouldn't tolerate it; I know;
>>disconnecting from an ISPF session and reconnecting with
>>a different geometry results in an endless iterative
>>"TERMINAL I/O ERROR".  I can't even SAVE and END.  But
>>that's ISPF tunnel vision.  OTOH:
>
>A command processor is not expected to issue GTTERM and adapt to any changes in
>screen geometry prior to every terminal I/O. Rather, standard procedure is to
>issue GTTERM once per command. When the command ends, the user can rebind and
>run another command at the new dimensions.
>
This "standard procedure" is of little avail to the user who can't
get past the I/O error to issue the SAVE and END commands.  Surely
issuing GTTERM would be a reasonable component of recovering from
a terminal I/O error.  Don't tell me; let me guess: the command
processor is never notified of unrecoverable terminal I/O errors,
not even by RC/RSN value.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Richards, Robert B.]

> These days I cannot imagine many people actually using SDSF too much from the 
> READY prompt

Only when I am getting ready to logoff for the day and then remember that I 
forgot to look at something I submitted. :-)

Bob

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Rob Scott]

> Last time I checked it didn't even support 'large' screens except under ISPF, 
> so I think it's very old code.

FYI : SDSF does support large screens in TSO mode (rather than ISPF) - I have 
just checked in 62x160 and it handles it fine.

These days I cannot imagine many people actually using SDSF too much from the 
READY prompt 

Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Edward Jaffe
Sent: 22 June 2011 15:28
To: IBM-MAIN@bama.ua.edu
Subject: Re: Reduced 3270 Screen Geometry

On 6/20/2011 4:05 PM, Paul Gilmartin wrote:
>
> o Does any terminal emulator provide dynamic geometry change
>during a session?

Probably most of them. I know PCOMM supports this. Rebind is a standard part of 
the protocol.

>ISPF wouldn't tolerate it; I know;
>disconnecting from an ISPF session and reconnecting with
>a different geometry results in an endless iterative
>"TERMINAL I/O ERROR".  I can't even SAVE and END.  But
>that's ISPF tunnel vision.  OTOH:
>
> o If I disconnect from a TSO READY prompt and reconnect with
>a different screen geometry, TSO continues in line mode
>savvy to the change.  Why doesn't TSO pass notification
>of this change to ISPF if it's running, and/or why doesn't
>ISPF accommodate?

A command processor is not expected to issue GTTERM and adapt to any changes in 
screen geometry prior to every terminal I/O. Rather, standard procedure is to 
issue GTTERM once per command. When the command ends, the user can rebind and 
run another command at the new dimensions.

> o I must have tried the experiment with SDSF, under ISPF
>and/or from the READY prompt.  I don't recall the result.

I would not expect SDSF to do anything other than follow standard procedures. 
Last time I checked it didn't even support 'large' screens except under ISPF, 
so I think it's very old code.

> o What would (E)JES do in case of reconnect with changed
>terminal geometry?  :-)

(E)JES supports any terminal geometry in any environment (ISPF, TSO READY, 
CICS, stand-alone VTAM, even the emulated screens [should a program care to 
inspect them for some reason] under the APIs, etc.) If you reconnect to the 
stand-alone VTAM environment with different dimensions, the environment will 
pick up the change dynamically. But, to avoid 'strange' looking screens you 
should return to the equivalent of TSO/E READY and restart your (E)JES session 
(which takes only two keystrokes in that environment).

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Edward Jaffe]

On 6/20/2011 4:05 PM, Paul Gilmartin wrote:


o Does any terminal emulator provide dynamic geometry change
   during a session?


Probably most of them. I know PCOMM supports this. Rebind is a standard part of 
the protocol.



   ISPF wouldn't tolerate it; I know;
   disconnecting from an ISPF session and reconnecting with
   a different geometry results in an endless iterative
   "TERMINAL I/O ERROR".  I can't even SAVE and END.  But
   that's ISPF tunnel vision.  OTOH:

o If I disconnect from a TSO READY prompt and reconnect with
   a different screen geometry, TSO continues in line mode
   savvy to the change.  Why doesn't TSO pass notification
   of this change to ISPF if it's running, and/or why doesn't
   ISPF accommodate?


A command processor is not expected to issue GTTERM and adapt to any changes in 
screen geometry prior to every terminal I/O. Rather, standard procedure is to 
issue GTTERM once per command. When the command ends, the user can rebind and 
run another command at the new dimensions.



o I must have tried the experiment with SDSF, under ISPF
   and/or from the READY prompt.  I don't recall the result.


I would not expect SDSF to do anything other than follow standard procedures. 
Last time I checked it didn't even support 'large' screens except under ISPF, so 
I think it's very old code.



o What would (E)JES do in case of reconnect with changed
   terminal geometry?  :-)


(E)JES supports any terminal geometry in any environment (ISPF, TSO READY, CICS, 
stand-alone VTAM, even the emulated screens [should a program care to inspect 
them for some reason] under the APIs, etc.) If you reconnect to the stand-alone 
VTAM environment with different dimensions, the environment will pick up the 
change dynamically. But, to avoid 'strange' looking screens you should return to 
the equivalent of TSO/E READY and restart your (E)JES session (which takes only 
two keystrokes in that environment).


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Shmuel Metz (Seymour J.)]

In <4e00b8cf.7060...@dignus.com>, on 06/21/2011
   at 11:29 AM, Thomas David Rivers  said:

>I've been told that the newer "flexible" lenses they use as
>replacements in cateracts surgery solve this problem;

My insurance didn't cover those.

>Now, it seems, I need cateracts :-)

I would have been perfectly happy to let someone el;se have mine :-(
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Shmuel Metz (Seymour J.)]

In , on 06/20/2011
   at 06:05 PM, Paul Gilmartin  said:

>o If I disconnect from a TSO READY prompt and reconnect with
>  a different screen geometry, TSO continues in line mode
>  savvy to the change.  Why doesn't TSO pass notification
>  of this change to ISPF if it's running, and/or why doesn't
>  ISPF accommodate?

TSO has several NOWAIT facilities. Why can't ISPF exploit them?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Thomas David Rivers]

Edward Jaffe wrote:

I just reduced the screen geometry of my 3270 displays from 90x142 
down to 68x142 due to ever-increasing eye strain. When I started in 
this business, I worked with a 24x80 display. At this rate, I'll 
probably retire with the same screen geometry I started with... :-D



I'm right there with you!

*very* frustrating

I've been told that the newer "flexible" lenses they use
as replacements in cateracts surgery solve this problem;
but there's not approved for simply "getting old."  Now,
it seems, I need cateracts :-)

   - Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe
> 
> I just reduced the screen geometry of my 3270 displays from 90x142
down to
> 68x142 due to ever-increasing eye strain. When I started in this
business, I
> worked with a 24x80 display. At this rate, I'll probably retire with
the same
> screen geometry I started with... :-D

I'm looking at retiring in about 3 years, and still like the 3290
display size -- 62x160 -- on a 19-inch monitor.  

No, I haven't had the cataract surgery yet.  :-)

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Paul Gilmartin]

On Mon, 20 Jun 2011 15:10:51 -0700, Edward Jaffe wrote:

>I just reduced the screen geometry of my 3270 displays from 90x142 down to
>68x142 due to ever-increasing eye strain. When I started in this business, I
>worked with a 24x80 display. At this rate, I'll probably retire with the same
>screen geometry I started with... :-D
>
There's a growing concern here as users in increasing numbers
rely on their fondleslabs.

o What terminal emulators have a useful zoom function?

o Does any terminal emulator provide dynamic geometry change
  during a session?  ISPF wouldn't tolerate it; I know;
  disconnecting from an ISPF session and reconnecting with
  a different geometry results in an endless iterative
  "TERMINAL I/O ERROR".  I can't even SAVE and END.  But
  that's ISPF tunnel vision.  OTOH:

o If I disconnect from a VM/CMS XEDIT session, then reconnect
  with a different terminal geometry, I merely press PA2
  and XEDIT refreshes the screen correctly in the new
  geometry.  Why can't ISPF be as smart?  Increasingly relevant
  as TSO's "RECONNECT" becomes more sophisticated.  Of course,
  if I did this in the midst of a complex XEDIT macro that
  depended on screen geometry and couldn't handle the SIGWINCH,
  I'd expect misbehavior.

o If I disconnect from a TSO READY prompt and reconnect with
  a different screen geometry, TSO continues in line mode
  savvy to the change.  Why doesn't TSO pass notification
  of this change to ISPF if it's running, and/or why doesn't
  ISPF accommodate?

o I must have tried the experiment with SDSF, under ISPF
  and/or from the READY prompt.  I don't recall the result.

o What would (E)JES do in case of reconnect with changed
  terminal geometry?  :-)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Mike Schwab]

60 inch screen with HDMI connector.  DSL to watch Netflix.

On Mon, Jun 20, 2011 at 5:29 PM, Linda Mooney  wrote:
> Nah, you just need a newer, larger monitor.  ;-)
>
> Linda
> - Original Message -
> From: "Edward Jaffe" 
> To: IBM-MAIN@bama.ua.edu
> Sent: Monday, June 20, 2011 3:10:51 PM
> Subject: Reduced 3270 Screen Geometry
>
> I just reduced the screen geometry of my 3270 displays from 90x142 down to
> 68x142 due to ever-increasing eye strain. When I started in this business, I
> worked with a 24x80 display. At this rate, I'll probably retire with the same
> screen geometry I started with... :-D
>
> --
> Edward E Jaffe

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Linda Mooney]

Nah, you just need a newer, larger monitor.  ;-) 



Linda 
- Original Message - 
From: "Edward Jaffe"  
To: IBM-MAIN@bama.ua.edu 
Sent: Monday, June 20, 2011 3:10:51 PM 
Subject: Reduced 3270 Screen Geometry 

I just reduced the screen geometry of my 3270 displays from 90x142 down to 
68x142 due to ever-increasing eye strain. When I started in this business, I 
worked with a 24x80 display. At this rate, I'll probably retire with the same 
screen geometry I started with... :-D 

-- 
Edward E Jaffe 
Phoenix Software International, Inc 
831 Parkview Drive North 
El Segundo, CA 90245 
310-338-0400 x318 
edja...@phoenixsoftware.com 
http://www.phoenixsoftware.com/ 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reduced 3270 Screen Geometry

[Skip Robinson]

I think that for a slight surcharge, you can specify a large font on your 
headstone...

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Edward Jaffe 
To: IBM-MAIN@bama.ua.edu
Date:   06/20/2011 03:16 PM
Subject:Reduced 3270 Screen Geometry
Sent by:IBM Mainframe Discussion List 



I just reduced the screen geometry of my 3270 displays from 90x142 down to 

68x142 due to ever-increasing eye strain. When I started in this business, 
I 
worked with a 24x80 display. At this rate, I'll probably retire with the 
same 
screen geometry I started with... :-D

-- 
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reduced 3270 Screen Geometry

[Edward Jaffe]

I just reduced the screen geometry of my 3270 displays from 90x142 down to 
68x142 due to ever-increasing eye strain. When I started in this business, I 
worked with a 24x80 display. At this rate, I'll probably retire with the same 
screen geometry I started with... :-D


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html