Re: 3270 archaeology (Was: TSO SCREENSIZE)

[Kirk Talman]

"On January 14 1970, DPD rolls out IBM DATA/360, a new program product 
that simulates the functions of the IBM 29 keypunch and IBM 59 verifier to 
enter data from an IBM 2260 display station to an IBM 2311 or 2314 direct 
access storage device, bypassing punched cards;"

we used this w/2270-1 s a few years after this.  product was renamed but 
google can't find the new name.  I remembered ENTRY/370 but not found.

Our greatest danger in life is in permitting the urgent things to crowd 
out the important. - Charles E. Hummel
Efforts and courage are not enough without purpose and direction. - John 
F. Kennedy
The probability of error in a change is inversely proportional to the size 
of the change. - B.I Kahn's First Law
The probability of error in a one character change is approximately 100%. 
If the possibility of collateral damage exists, the probably of error can 
appear to exceed 100%. - corollary to B.I Kahn's First Law





-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. 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: 3270 archaeology (Was: TSO SCREENSIZE)

[Shmuel Metz (Seymour J.)]

In <6332589144814230.wa.paulgboulderaim@bama.ua.edu>, on
11/14/2011
   at 09:40 AM, Paul Gilmartin  said:

>Actually, it was never STK during the independent existence of
>Storage Technology Corporation. 

Ah, so! Thanks. I had been told that they changed the name due to a
trademark infringement complaint.
 
-- 
 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: 3270 archaeology (Was: TSO SCREENSIZE)

[Paul Gilmartin]

On Fri, 11 Nov 2011 15:34:21 -0500, Shmuel Metz (Seymour J.)  wrote:

>You didn't have the STC (later STK) ...
> 
Actually, it was never STK during the independent existence of Storage
Technology Corporation.  The approved branding was StorageTek, and
employees were instructed that "STK" was an NYSE stock ticker symbol,
not to be used to identify the company in either external or external
communications.  Predictably, some StorageTek employes were careless
and misused "STK", even as some IBM employees have carelessly
misused "USS".  I hope that you are fair in pedantry, recognizing that
neither informal use constitutes official approval.

Later, under Sun and Oracle ownership, employees and management
have adopted the casual use with no fear of retribution.

-- 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: TSO SCREENSIZE

[Shmuel Metz (Seymour J.)]

In <4ebdb42e.4070...@ync.net>, on 11/11/2011
   at 05:47 PM, Rick Fochtman  said:

>IIRC, the 2250 was a vector-graphics tube requiring GAM to fully
>exploit.

FSVO. Don't forget GSP and GJP.
 
-- 
 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: 3270 archaeology (Was: TSO SCREENSIZE)

[Shmuel Metz (Seymour J.)]

In <4ebd9513.4040...@valley.net>, on 11/11/2011
   at 04:35 PM, Gerhard Postpischil  said:

>The one that didn't handle wrap-around correctly?

After RA the buffer address was left at the beginning instead of the
documented location.

>I fondly recall referring to it as the PIG multiplexer 

Up to and including altering the nameplate to match. ;-)
 
-- 
 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: TSO SCREENSIZE

[Rick Fochtman]

There was also a 2250 in that timeframe, but I do not remember the size. 
We had one of each in Stuttgart, but could not use them because the 
request for the extra memory to be able to run the communications 
program was cut from the budget request. The general did not care about 
the system memory, just the CRTs.

---
IIRC, the 2250 was a vector-graphics tube requiring GAM to fully exploit.

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: TSO SCREENSIZE

[Rick Fochtman]

The 2260, controlled by a 2848 controller, was a separate "family" of 
displays. We used them at Michigan Tech under a system called "RAX".


Rick
-
Ed Gould wrote:


Rick,

My memory is iffy here as well but I do remember that we had 12 x 80 screens but 
the model number was 2260. The screen was incredibly small. This was in the early 
1970's.

Ed

--
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: 3270 archaeology (Was: TSO SCREENSIZE)

[Gerhard Postpischil]

On 11/11/2011 3:34 PM, Shmuel Metz (Seymour J.) wrote:

Then you should have ordered from GTE :-(


The one that didn't handle wrap-around correctly?


You didn't have the STC (later STK) tape drives where only every other
jumper position was used but the CE documentation didn't mention the
fact?


At one time we had a string of STK drives, but they gave us 
nothing but problems, and were replaced with Memorex hardware 
very quickly.



I vaguely recall you grumbling about the CIG[1] block multiplexor
channel as well.


Only until they fixed the timing (3350 response came before 
channel was able to handle it). Memorex plugged their 
controllers for slower response, thus giving us support for 
3330-1 and 3350 capacity, but without the speed improvements. I 
fondly recall referring to it as the PIG multiplexer 



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: 3270 archaeology (Was: TSO SCREENSIZE)

[Ed Gould]

 Gerhard,

I agree with you. We had over 1200 3270's locally  attached and never had 
issues with IBM controllers or devices. Where we did have issues was we had an 
OEM "channel" extender. That gavesusno end of problems. At one time I was 
providing the vendor with2 or 3 dumps a day and they were providing me with new 
"load" decks daily(almost). I was getting really mad with the vendor and I was 
getting singed by my management over the issues. I finally said either live 
with the problems or replace it. This was a political bombshell and the vendor 
got upset with me and I indiated it was their hardware and software and it 
wasn't my problem. They tried to point at MVS and I indicated that we 
didn't have problems with IBM hardware. The started to give me more static 
and I just said look either give me a way to get some traces for you or fix 
your problems.

They finally came up with a trace program and I ran it till I was blue in the 
face and was sending them boxes of output for a few weeks and a month later 
they produced a new load deck ad it actually was a lot more stable but still 
not as good as IBMs .

Ed

--
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: 3270 archaeology (Was: TSO SCREENSIZE)

[Shmuel Metz (Seymour J.)]

In <4ebd5c40.8090...@valley.net>, on 11/11/2011
   at 12:32 PM, Gerhard Postpischil  said:

>Only the AT&T and one Telex gave us problems

Then you should have ordered from GTE :-(

>The worst incident I recall was when the C.E. was asked to plug  a
>new 3272 as address 0C0, and he held the board upside down.

You didn't have the STC (later STK) tape drives where only every other
jumper position was used but the CE documentation didn't mention the
fact?

I vaguely recall you grumbling about the CIG[1] block multiplexor
channel as well.

[1] An amusing name because at RCA CIG stood for characters[2]
in gap.

[2] We normally used a different word for the C.
 
-- 
 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: TSO SCREENSIZE

[Shmuel Metz (Seymour J.)]

In <1321016908.8332.yahoomai...@web82202.mail.mud.yahoo.com>, on
11/11/2011
   at 05:08 AM, Lloyd Fuller  said:

>There was also a 2250 in that timeframe,

Considerably more expensive than a 2260. Worth it for graphics, but
not if you just needed text.
 
-- 
 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: TSO SCREENSIZE

[Shmuel Metz (Seymour J.)]

In
,
on 11/11/2011
   at 09:21 AM, Mike Wawiorko  said:

>Maybe not such a bad design choice?

Perhaps, but you haven't made a case. 

>How many of us have ever used the various web interfaces to z/OS for
>any length of time? 

Get your red herrings while they're fresh! The issue is not whether a
web interface would have been better, the issue is whether
transmitting row/column would have been better. John raised a
legitimate point, although I could come up with a counterargument.
 
-- 
 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: 3270 archaeology (Was: TSO SCREENSIZE)

[Shmuel Metz (Seymour J.)]

In <0A25A0D191144ABB8F0649705ADAA187@DJVBN391>, on 11/11/2011
   at 12:07 AM, Larry Chenevert  said:

>The channel attached control units for those 3270's were notorious
>for  generating interface control checks, which the operating systems
>of the era  (OS/VS1, SVS, and MVS 3.8) were notorious for responding
>by entering  disabled waits, resulting in many unscheduled outages,
>and this seemed to  persist into the early 80's.

My recollection is that the CCH[1] could handle an ICC, although you
might lose the use of the devices.

>stuff one is not supposed to do in CICS

For good reason. You delay other transactions.

>and there was the need for GX20-1878-3.

Why? That's a summary; what information did it have that wasn't in the
regular manuals?

>Later, there were even people who told me and others closely 
>involved "You can not do that using Verify." after I had already
>done it!

Well, at least it hadn't been in the manual for over a decade before
they told you that it couldn't be done. 

[1] Well, for SVS and MVS; I don't have experience on OS/VS1.
 
-- 
 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: The "IBM Displays" Memory Lane (Was: TSO SCREENSIZE)

[Lynn Wheeler]

m...@mentor-services.com (Mike Myers) writes:
> The 2250 was very interesting to me. I took a class on 2250
> programming in 1968. I learned that it had both character and graphics
> mode. The character mode was of special interest and I developed a
> full-screen editor that let the group I was working in at the time
> develop and edit source code and data files. It wasn't quite as good
> as ISPF's editor (which wasn't around yet), but it was a lot better
> than TSO's line editor. The screen was also much bigger than the
> 2260's and could display a whole card image.
>
> You could overtype data directly on the screen and there was a single
> line on the screen (at the bottom) which permitted commands that
> supported single line and block moves, copies and deletes.
>
> It saved the group a great deal of effort in developing programs and
> course material. I was teaching PSRs at IBM's Field Engineering school
> in Poughkeepsie at the time.
>
> Brings back some pleasant memories.

2250 had a number of different models ... 2250-1 was direct 360 channel
attach while 2250-4 was 2250/1130 combo ... (but they cost approx. the
same).

we had 2250-1 at the univ in the 60s ... and i used the CMS 2250
graphics fortran library from lincoln labs ... to hack 2250 support
into the cms editor.

the science center had 2250-4 (2250/1130 combo), which somebody ported a
copy of spacewars from PDP1.
http://en.wikipedia.org/wiki/Spacewar!

misc. past posts mentioning science center
http://www.garlic.com/~lynn/subtopic.html#545tech

then summer of 1969 ... i got brought in to boeing hdqtrs to help with
the fledging boeing computer services (bringing all dataprocessing into
its own business unit). hdqtrs had 360/30 mainly used for payroll and
the machine room was built out to add a 1mbyte 360/67 to run cp67/cms.
This was tiny compared to the renton datacenter which had dozens of
360/65 and some claim to have $300M or so in 360 equipment ... which was
being replicated at the 747 plant up in everett.

For a long time, I thot Renton was the largest mainframe machine room
... but later i would sponsor Boyd's briefings at IBM ... and in recent
bio ... it mentioned Boyd was in charge of spook base (about the time I
was at Boeing) ... which was a $2.5B "windfall" for IBM (possibly $17+B
inflation adjusted in today's dollars?).

this has description of spook base ... gone 404, but lives on at
the wayback machine
http://web.archive.org/web/20030212092342/http://home.att.net/~c.jeppeson/igloo_white.html

above has picture claimed to be 2250s ... but obvious is something else.

Later replacements for 2250 i believe were repackaged/relogo'ed graphics
display from Sanders Associates (in NH)
http://www.pong-story.com/sanders.htm
http://books.google.com/books?id=XK4v1gh0JroC&pg=PA31&lpg=PA31&dq=sanders+associates+graphics+display&source=bl&ots=62_kZWXpki&sig=zKyb8WrQnJUzEQFgVMcJBZvq-XQ&hl=en&ei=QVu9ToTQPKWsiQL63I2mAw&sa=X&oi=book_result&ct=result&resnum=5&ved=0CFgQ6AEwBA

--
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: 3270 archaeology (Was: TSO SCREENSIZE)

[Gerhard Postpischil]

On 11/11/2011 1:07 AM, Larry Chenevert wrote:

The channel attached control units for those 3270's were
notorious for generating interface control checks, which the
operating systems of the era (OS/VS1, SVS, and MVS 3.8) were
notorious for responding by entering disabled waits, resulting
in many unscheduled outages, and this seemed to persist into the
early 80's.


Your experience differs from mine. We usually installed new 
hardware over weekends, and gave it a thorough workout before 
acceptance. While we had occasional channel checks, it was only 
during the initial testing. I have no recollection of problems 
(other than normal failing boards) with the controllers (we ran 
IBM 3272s, then 3274s, later lots of ITT and one AT&T units. 
Only the AT&T and one Telex gave us problems). It makes me 
wonder whether your problems might have been due to other 
controllers on the channel (I know at least one installation 
that hooked their 3270s on the same selector as their tape drives!).


The worst incident I recall was when the C.E. was asked to plug 
a new 3272 as address 0C0, and he held the board upside down. We 
had a TP controller on 030 and had lots of interesting errors 
until we made him fix the switches. The other major problem was 
an installation where the C.E. didn't hook up the EPO cable, and 
after he left, the 4341 CPU wouldn't power up.


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: TSO SCREENSIZE

[Joel C. Ewing]

On 11/10/2011 02:58 PM, Rick Fochtman wrote:

---

Remember how old the 3270 architecture is. Wikipedia says about 1972.
Think 1 Mhz 8080 as "top of the line" micro processor. The original
3277 and its controllers were STUPID. Rather than put a more powerful
processor in the controller, IBM decided to offload the "complicated"
function of calculating the position of the data into the host. Made
of discrete transistors and resistors! Very primitive. So, the host
just sent a simple to understand "buffer address" (a single number)
to the 3274.



Not without a time machine. The 3274 came later. The original 3270
controller lineup was 3271, 3272 and 3275, the latter combining
controller and display.

--

Wasn't there also a 3276, with a display and controller that would
handle the integerated display, plus 7 more display-only devices?

Rick



Yes indeed, for remote BSC or SDLC operation.  The other 7 devices could 
also include 3270 printers.  Deceptively the same external size as a 
3278, but with enough additional steel and components inside to be 
appreciably heavier than a 3278, which was already borderline for one 
person to carry.  Trying to carry a 3276 by yourself was not wise if you 
wanted to avoid back problems.


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
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: TSO SCREENSIZE

[Ed Gould]

 Shmuel,
My memory was faulty. The screen size was not as I stated.as others have 
correctly stated the right size.
The army post I was at was doing a development of an online system for a 
proposed worldwide army supply system. The displays were either 2260's or 
3270-1's the 40 years has dimmed my memory.

Ed


--
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: The "IBM Displays" Memory Lane (Was: TSO SCREENSIZE)

[Mike Myers]

The 2250 was very interesting to me. I took a class on 2250 programming 
in 1968. I learned that it had both character and graphics mode. The 
character mode was of special interest and I developed a full-screen 
editor that let the group I was working in at the time develop and edit 
source code and data files. It wasn't quite as good as ISPF's editor 
(which wasn't around yet), but it was a lot better than TSO's line 
editor. The screen was also much bigger than the 2260's and could 
display a whole card image.


You could overtype data directly on the screen and there was a single 
line on the screen (at the bottom) which permitted commands that 
supported single line and block moves, copies and deletes.


It saved the group a great deal of effort in developing programs and 
course material. I was teaching PSRs at IBM's Field Engineering school 
in Poughkeepsie at the time.


Brings back some pleasant memories.

Mike Myers
Mentor Services Corporation

On 11/11/2011 09:11 AM, Chris Mason wrote:

To all who may be interested in the 2250

The Wikipedia article is quite short so here it is in its entirety.



IBM 2250

The IBM 2250 Graphics Display Unit was announced as part of System/360 in 1964. 
Unlike most modern computer displays, which show images in raster format, the 
IBM 2250 used vector graphics. A display list of line segments (vectors) on a 
1024 by 1024 grid was stored in the computer's memory and repainted on the 
2250s CRT up to 40 time per second. Characters were built of line segments 
specified by display list subroutines. Thus any character set or font could be 
displayed, although fonts were generally extremely simplified for performance 
reasons. The computer altered the display by changing the display list. As the 
display list got longer, the refresh time got longer too and eventually the 
display would start to flicker.

The 2250 was housed in a desk with an alphanumeric (QWERTY) keyboard and a separate 
programmed function keyboard which had keys, indicator lights and switches. A 
plastic overlay label could be placed over the function keyboard. Punches on the top 
edge of the overlay could be sensed by the computer so the keys, lights and switches 
could be reprogrammed simply by changing overlays. The 2250s CRT measured 21" 
diagonal, but the useful display area was 12 inch by 12 inch. A light pen was 
provided as a pointing device, serving the function of the modern computer mouse.

An IBM 2285 Display Copier could be attached to the 2250 to provide 8½ by 11 
inch hard copy of the display contents under operator control.



http://en.wikipedia.org/wiki/IBM_2250


... but I do not remember the size.

It covers the key point I wanted to make in connection with this comment. If "size" is a 
reference to character rows and columns, we are comparing "apples and oranges" as I hope 
can be noted from the description.

">" ... although fonts were generally extremely simplified for performance 
reasons.

I saw one at one time in use as a console in the Santa Teresa labs - and possibly 
elsewhere - my memory's not what it was! The "feature" of the presentation of 
console messages which most impressed was actually the relative crudeness of the 
character rendering.

Incidentally one could suppose that this type of display technology, rendering characters 
from subroutines of a mathematical nature using lines with start and end coordinates, 
would find approval from at least one denizen of this list who has gone on record 
regarding his - for it is a "he" - disgust at the technology of display devices 
which simply display characters of one font within character cells within the 
presentation space relative to the beginning of a linear buffer.

Chris Mason


On Fri, 11 Nov 2011 05:08:28 -0800, Lloyd Fuller  wrote:


There was also a 2250 in that timeframe, but I do not remember the size.  We had
one of each in Stuttgart, but could not use them because the request for the
extra memory to be able to run the communications program was cut from the
budget request.  The general did not care about the system memory, just the
CRTs.

Lloyd



- Original Message ----
From: Ed Gould
To: IBM-MAIN@bama.ua.edu
Sent: Thu, November 10, 2011 8:55:41 PM
Subject: Re: TSO SCREENSIZE

Rick,

My memory is iffy here as well but I do remember that we had 12 x 80 screens but
the model number was 2260. The screen was incredibly small. This was in the
early 1970's.

Ed

--
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

SV: The "IBM Displays" Memory Lane (Was: TSO SCREENSIZE)

[Thomas Berg]

About the 2250, a link with a photo of the wonder in action: 
http://www.columbia.edu/cu/computinghistory/2250.html


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

--
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

The "IBM Displays" Memory Lane (Was: TSO SCREENSIZE)

[Chris Mason]

To all who may be interested in the 2250

The Wikipedia article is quite short so here it is in its entirety.



IBM 2250

The IBM 2250 Graphics Display Unit was announced as part of System/360 in 1964. 
Unlike most modern computer displays, which show images in raster format, the 
IBM 2250 used vector graphics. A display list of line segments (vectors) on a 
1024 by 1024 grid was stored in the computer's memory and repainted on the 
2250s CRT up to 40 time per second. Characters were built of line segments 
specified by display list subroutines. Thus any character set or font could be 
displayed, although fonts were generally extremely simplified for performance 
reasons. The computer altered the display by changing the display list. As the 
display list got longer, the refresh time got longer too and eventually the 
display would start to flicker.

The 2250 was housed in a desk with an alphanumeric (QWERTY) keyboard and a 
separate programmed function keyboard which had keys, indicator lights and 
switches. A plastic overlay label could be placed over the function keyboard. 
Punches on the top edge of the overlay could be sensed by the computer so the 
keys, lights and switches could be reprogrammed simply by changing overlays. 
The 2250s CRT measured 21" diagonal, but the useful display area was 12 inch by 
12 inch. A light pen was provided as a pointing device, serving the function of 
the modern computer mouse.

An IBM 2285 Display Copier could be attached to the 2250 to provide 8½ by 11 
inch hard copy of the display contents under operator control.



http://en.wikipedia.org/wiki/IBM_2250

> ... but I do not remember the size.

It covers the key point I wanted to make in connection with this comment. If 
"size" is a reference to character rows and columns, we are comparing "apples 
and oranges" as I hope can be noted from the description.

">" ... although fonts were generally extremely simplified for performance 
reasons.

I saw one at one time in use as a console in the Santa Teresa labs - and 
possibly elsewhere - my memory's not what it was! The "feature" of the 
presentation of console messages which most impressed was actually the relative 
crudeness of the character rendering.

Incidentally one could suppose that this type of display technology, rendering 
characters from subroutines of a mathematical nature using lines with start and 
end coordinates, would find approval from at least one denizen of this list who 
has gone on record regarding his - for it is a "he" - disgust at the technology 
of display devices which simply display characters of one font within character 
cells within the presentation space relative to the beginning of a linear 
buffer.

Chris Mason


On Fri, 11 Nov 2011 05:08:28 -0800, Lloyd Fuller  wrote:

>There was also a 2250 in that timeframe, but I do not remember the size.  We 
>had
>one of each in Stuttgart, but could not use them because the request for the
>extra memory to be able to run the communications program was cut from the
>budget request.  The general did not care about the system memory, just the
>CRTs.
>
>Lloyd
>
>
>
>- Original Message 
>From: Ed Gould 
>To: IBM-MAIN@bama.ua.edu
>Sent: Thu, November 10, 2011 8:55:41 PM
>Subject: Re: TSO SCREENSIZE
>
>Rick,
>
>My memory is iffy here as well but I do remember that we had 12 x 80 screens 
>but
>the model number was 2260. The screen was incredibly small. This was in the
>early 1970's.
>
>Ed

--
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: TSO SCREENSIZE

[Lloyd Fuller]

There was also a 2250 in that timeframe, but I do not remember the size.  We 
had 
one of each in Stuttgart, but could not use them because the request for the 
extra memory to be able to run the communications program was cut from the 
budget request.  The general did not care about the system memory, just the 
CRTs.

Lloyd



- Original Message 
From: Ed Gould 
To: IBM-MAIN@bama.ua.edu
Sent: Thu, November 10, 2011 8:55:41 PM
Subject: Re: TSO SCREENSIZE

Rick,

My memory is iffy here as well but I do remember that we had 12 x 80 screens 
but 
the model number was 2260. The screen was incredibly small. This was in the 
early 1970's.

Ed

--
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: 3270 archaeology (Was: TSO SCREENSIZE)

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of William Donzelli
> Sent: Friday, November 11, 2011 12:30 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: 3270 archaeology (Was: TSO SCREENSIZE)
> 
> > I happen to have a GX20-1878-3 (October 1978) 3270 
> Information Display
> > System Reference Summary in the top drawer of my desk.  It 
> shows the screen
> > size of a Mod 1 as 12x40, although I never worked with a 
> Mod 1 or ever even
> > saw one, to my knowledge.
> 
> Just about the only place you would be certain to see a model 1 was as
> a console on an S/3 model 15.
> 
> The things are really quite rare today.
> 
> --
> Will

When I first went to work at the City of Ft. Worth, TX in 1976, they had a 
bunch of 3277-1s in various departments. They talked to CICS 1.1.1 on DOS 
(release 34?). 

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone . 
john.mck...@healthmarkets.com . www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM

 

--
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: TSO SCREENSIZE

[Mike Wawiorko]

3270 is 40 years old and still in use as the most common interface to z/OS for 
programmers and systems programmers.

Maybe not such a bad design choice?

Certainly not stupid.

How many of us have ever used the various web interfaces to z/OS for any length 
of time?  Reverting to tried and trusted 3270 is the usual end.

Regards,
Mike Wawiorko
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Chris Mason
Sent: 10 November 2011 19:08
To: IBM-MAIN@bama.ua.edu
Subject: Re: TSO SCREENSIZE

John

> 3274

3271

> STUPID

>From the perspective of the new millennium. At the time (1970 approximately) 
>I'm sure it was a sensible design choice.

Chris Mason

On Thu, 10 Nov 2011 11:48:30 -0600, McKown, John 
 wrote:

> ...
>
>Remember how old the 3270 architecture is. Wikipedia says about 1972. Think 1 
>Mhz 8080 as "top of the line" micro processor. The original 3277 and its 
>controllers were STUPID. Rather than put a more powerful processor in the 
>controller, IBM decided to offload the "complicated" function of calculating 
>the position of the data into the host. Made of discrete transistors and 
>resistors! Very primitive. So, the host just sent a simple to understand 
>"buffer address" (a single number) to the 3274. It basically just starting 
>stuffing data characters at that location in a RAM buffer. More power == most 
>cost == fewer purchases. Much like some of the "krud" in z/OS today due to 
>"short sighted" architects who were worried about memory and slow CPUs and 
>expensive DASD.

>
>The answer to these problems is obvious: Convert from archaic z/OS to modern 
>Windows 8! At least that's what a lot of "Windows weenies" around here are 
>saying. Over and over and over and over. "Better! Faster!! Cheaper!!!" is 
>their cry. Anything z/OS can do, they state can be done using Windows and at 
>lower TCO. Herr Gobbles would be proud of them.
>
>--
>John McKown

--
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
This e-mail and any attachments are confidential and intended
solely for the addressee and may also be privileged or exempt from
disclosure under applicable law. If you are not the addressee, or
have received this e-mail in error, please notify the sender
immediately, delete it from your system and do not copy, disclose
or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or
virus-free.
The Barclays Group does not accept responsibility for any loss
arising from unauthorised access to, or interference with, any
Internet communications by any third party, or from the
transmission of any viruses. Replies to this e-mail may be
monitored by the Barclays Group for operational or business
reasons.

Any opinion or other information in this e-mail or its attachments
that does not relate to the business of the Barclays Group is
personal to the sender and is not given or endorsed by the Barclays
Group.

Barclays Bank PLC. Registered in England and Wales (registered no.
1026167).
Registered Office: 1 Churchill Place, London, E14 5HP, United
Kingdom.

Barclays Bank PLC is authorised and regulated by the Financial
Services Authority.

--
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: 3270 archaeology (Was: TSO SCREENSIZE)

[William Donzelli]

> I happen to have a GX20-1878-3 (October 1978) 3270 Information Display
> System Reference Summary in the top drawer of my desk.  It shows the screen
> size of a Mod 1 as 12x40, although I never worked with a Mod 1 or ever even
> saw one, to my knowledge.

Just about the only place you would be certain to see a model 1 was as
a console on an S/3 model 15.

The things are really quite rare today.

--
Will

--
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: 3270 archaeology (Was: TSO SCREENSIZE)

[Larry Chenevert]

Thanks for the link, Chris.

I happen to have a GX20-1878-3 (October 1978) 3270 Information Display 
System Reference Summary in the top drawer of my desk.  It shows the screen 
size of a Mod 1 as 12x40, although I never worked with a Mod 1 or ever even 
saw one, to my knowledge.


My first 3270 data stream experience was with a Mod 2 in 1976.  I did 
something similar to the classic "Hello World" application, but it was 
acctually a calculator that supported two operands and the operators +-*/. 
By sometime in 1977, we had a homegrown 3270 based transaction processor 
affectionately called "TP" which was similar in overall function to CICS (of 
that era), but nowhere near comparable to CICS as far as features.


The channel attached control units for those 3270's were notorious for 
generating interface control checks, which the operating systems of the era 
(OS/VS1, SVS, and MVS 3.8) were notorious for responding by entering 
disabled waits, resulting in many unscheduled outages, and this seemed to 
persist into the early 80's.


The last time I used the GX20-1878-3 was probably 1989-1991 when I was asked 
to see if I could write a number of user exits to a  product called Verify 
(then developed and owned by Online Software International -- later acquired 
by CA, and I believe retired, although an incarnation of it for VTAM might 
still exist), which was an early regression tester for CICS.  Verify had the 
ability to record input 3270 data streams and output 3270 data streams from 
a series of transactions, and "rerun" them later, presumably after system 
changes were made.  There was a compare function to see if the same output 
resulted before and after the changes -- regression testing.  We didn't use 
it that way, though. . .


...The task was to drive CICS transactions with input data from flat files 
(QSAM), record the output in flat files, and respond with some level of 
intelligence to whatever output from the transaction was.  This required a 
lot of dynamic file allocation and OPEN, GET, PUT, and CLOSE  -- stuff one 
is not supposed to do in CICS-- and precise 3270 data stream interpretation 
and manipulation, and there was the need for GX20-1878-3.  A couple of big 
SW vendors were approached about this and passed on the opportunity before I 
was contacted.  Later, there were even people who told me and others closely 
involved "You can not do that using Verify." after I had already done it!


Not really relevant, but the application requiring the Verify work was a 
very industry-specific accounting application (something like mining --  
multiple landowners, etc.) that had been developed with the help of one of 
the big accounting firms.  The customer needed to migrate data from several 
disparate systems to their new application which was CICS/DB2 based, so this 
creation served to:
1) stress test the new infrastructure (and stress the infrastructure it did, 
with a near zero user think time),

2) test the new application code, and ...
3) facilitate the data migration from the older disparate systems to the new 
one.



Larry Chenevert
- Original Message - 
From: "Chris Mason" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Thursday, November 10, 2011 7:41 PM
Subject: 3270 archaeology (Was: TSO SCREENSIZE)



To all actually interested in 3270 pre-history

And the original IBM 3270 screen size was Model 1, 12 lines by 40 
characters. Model 2 (24 * 80) didn't come along until later.


It was my possibly faulty recollection that just about all of the first 
generation of 3270 equipment was announced - and, I'm going to guess, 
could be delivered - in one go.


By resort to comprehensive Googling, it is possible to avoid dubious 
speculation - because I found the "smoking gun" - and I also found the 
page which is indeed phrased in such a way that it could be 
misunderstood.[1]


By entry of the following:

history 3270 IBM

the 26th "hit" (3rd page) is the following manual very kindly retained for 
us by "bitsavers":


"An Introduction to the IBM 3270 Information Display System", GA27-2739-1, 
Second Edition (May 1971)


http://bitsavers.org/pdf/ibm/3270/GA27-2739-1_An_Introduction_to_the_IBM_3270_Information_Display_System_May71.pdf

or the 4th item on the following page:

http://bitsavers.org/pdf/ibm/3270/

I draw your attention in particular to the "-1" at the end of the "form 
number". Unfortunately this isn't "-0" but literally the next best 
thing.[2] You will note the following in the "Preface":




. 3277 Display Station, Models 1 and 2



and the fact there are *no* revision bars. That means that this bulleted 
list item was the same in the previous edition of the manual, the "-0", 
and that, because of the date and, unlike another manual I unearthed 
(GA23-0060-0, November 1980), this is not some reis

Re: TSO SCREENSIZE

[Shmuel Metz (Seymour J.)]

In <4ebc3a73.5070...@ync.net>, on 11/10/2011
   at 02:56 PM, Rick Fochtman  said:

>While the Windoze-based processors

There are none. The same processors running windoze are capable of
running better operating systems. In fact, IBM announced support for
Linux in a zBX before it announced support for windoze on the same
processors.
 
-- 
 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: TSO SCREENSIZE

[Shmuel Metz (Seymour J.)]

In <4ebc3b0f@ync.net>, on 11/10/2011
   at 02:58 PM, Rick Fochtman  said:

>Wasn't there also a 3276,

That came later, along with the 3278 and 3279,
 
-- 
 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: TSO SCREENSIZE

[Shmuel Metz (Seymour J.)]

In
,
on 11/10/2011
   at 03:15 PM, Mike Schwab  said:

>DR had CP/M 86 for the 8086 but didn't meet with IBM to put it 
so IBM hired Bill Gates to write DOS 1.0)

That may be what gill bates promised, but in the event he bought QDOS
and renamed it.
 
-- 
 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: TSO SCREENSIZE

[Shmuel Metz (Seymour J.)]

In <1320976541.27279.yahoomailmob...@web161405.mail.bf1.yahoo.com>, on
11/10/2011
   at 05:55 PM, Ed Gould  said:

>My memory is iffy here as well but I do remember that we had 12 x 80
>screens but the model number was 2260.

There was a 2260 Model 1[1] and a 2260 Model 2. Both shipped in the
1960's. By the 1970's the 2260 was obsolete.

[1] Google for "landfill" 
 
-- 
 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: TSO SCREENSIZE

[Ed Gould]

 Rick,

My memory is iffy here as well but I do remember that we had 12 x 80 screens 
but the model number was 2260. The screen was incredibly small. This was in the 
early 1970's.

Ed

--
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

3270 archaeology (Was: TSO SCREENSIZE)

[Chris Mason]

To all actually interested in 3270 pre-history

> And the original IBM 3270 screen size was Model 1, 12 lines by 40 characters. 
> Model 2 (24 * 80) didn't come along until later.

It was my possibly faulty recollection that just about all of the first 
generation of 3270 equipment was announced - and, I'm going to guess, could be 
delivered - in one go.

By resort to comprehensive Googling, it is possible to avoid dubious 
speculation - because I found the "smoking gun" - and I also found the page 
which is indeed phrased in such a way that it could be misunderstood.[1]

By entry of the following:

history 3270 IBM

the 26th "hit" (3rd page) is the following manual very kindly retained for us 
by "bitsavers":

"An Introduction to the IBM 3270 Information Display System", GA27-2739-1, 
Second Edition (May 1971)

http://bitsavers.org/pdf/ibm/3270/GA27-2739-1_An_Introduction_to_the_IBM_3270_Information_Display_System_May71.pdf

or the 4th item on the following page:

http://bitsavers.org/pdf/ibm/3270/

I draw your attention in particular to the "-1" at the end of the "form 
number". Unfortunately this isn't "-0" but literally the next best thing.[2] 
You will note the following in the "Preface":



• 3277 Display Station, Models 1 and 2



and the fact there are *no* revision bars. That means that this bulleted list 
item was the same in the previous edition of the manual, the "-0", and that, 
because of the date and, unlike another manual I unearthed (GA23-0060-0, 
November 1980), this is not some reissue of an earlier manual. Therefore the 
Model 1 and the Model 2 were described initially at the same time and I am 
going to assume they were announced at the same time, approximately the date of 
this manual.

-

[1] The 5th "hit":

http://www.hob-techtalk.com/2008/09/12/3270-a-brief-history



The first display had a very small screen displaying only 12 rows with 40 
characters.



A bit of a sort-of "Chinese whisper" problem here. I think this "first" need 
not *mean* chronologically although that is implied.

[2] Fortunately I've just finished reading "Tinker, Tailor, Soldier, Spy" and 
so I have been tuning my deductive reasoning! I don't believe I had actually 
read the book before but I - tried to - follow carefully the 7-episode BBC 
series 30 odd years ago. I don't believe the film can possibly do justice to 
the complexities or the sequencing of the revelations.

Another interesting point is that the BBC series included a key scene near the 
end which is not explicit in the book. I wonder what the film will do ...

-

Chris Mason

On Thu, 10 Nov 2011 15:15:25 -0600, Mike Schwab  wrote:

> ...
>
>And the original IBM 3270 screen size was Model 1, 12 lines by 40
>characters.  Model 2 (24 * 80) didn't come along until later.
>
>--
>Mike A Schwab, Springfield IL USA

--
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: TSO SCREENSIZE

[Gerhard Postpischil]

On 11/10/2011 4:15 PM, Mike Schwab wrote:

And the original IBM 3270 screen size was Model 1, 12 lines by 40
characters.  Model 2 (24 * 80) didn't come along until later.


I seem to recall the model 2 to be available at the same time as 
the model 1, but that may be due to my dismissing the model 1 as 
useless. At the time we were running 12*80 2260s. (And while 
google may be my friend, in this case it turned up nothing useful)


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: TSO SCREENSIZE

[Mike Schwab]

On Thu, Nov 10, 2011 at 11:48 AM, McKown, John
 wrote:
>
> Remember how old the 3270 architecture is. Wikipedia says about 1972. Think 1 
> Mhz 8080 as "top of the line" micro processor. The original 3277 and its 
> controllers were STUPID. Rather than put a more powerful processor in the 
> controller, IBM decided to offload the "complicated" function of calculating 
> the position of the data into the host. Made of discrete transistors and 
> resistors! Very primitive. So, the host just sent a simple to understand 
> "buffer address" (a single number) to the 3274. It basically just starting 
> stuffing data characters at that location in a RAM buffer. More power == most 
> cost == fewer purchases. Much like some of the "krud" in z/OS today due to 
> "short sighted" architects who were worried about memory and slow CPUs and 
> expensive DASD.
>
> The answer to these problems is obvious: Convert from archaic z/OS to modern 
> Windows 8! At least that's what a lot of "Windows weenies" around here are 
> saying. Over and over and over and over. "Better! Faster!! Cheaper!!!" is 
> their cry. Anything z/OS can do, they state can be done using Windows and at 
> lower TCO. Herr Gobbles would be proud of them.
>
> --
> John McKown
> Systems Engineer IV
> IT

http://en.wikipedia.org/wiki/Intel_4004
1st microprocess in 1971, 740 kHz 2,300 transistors

http://en.wikipedia.org/wiki/Intel_8008
April 1972 500-800 kHz 3,500 transistors

http://en.wikipedia.org/wiki/Intel_8080
April 1974 2,000 kHz 6,000 transistors
(CP/M 80 was designed for this processor, DR had CP/M 86 for the 8086
but didn't meet with IBM to put it on the IBM PC, so IBM hired Bill
Gates to write DOS 1.0)

And the original IBM 3270 screen size was Model 1, 12 lines by 40
characters.  Model 2 (24 * 80) didn't come along until later.

-- 
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: TSO SCREENSIZE

[Rick Fochtman]

--


My phrasing is getting to be very poor. By STUPID, I meant more that the architecture implementation was 
primitive compared to today's architecures. Not that the designers or the design was stupid. It just resulted 
in a "stupid computer" (one with not many abilities) compared to today's "smart 
computers". Which will be considered "stupid" in the future.
 



I'd accept the term "primitive" far more easily than "stupid". Leave us 
always remember the speed at which technology changes.  :-)


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: TSO SCREENSIZE

[Rick Fochtman]

---


Remember how old the 3270 architecture is. Wikipedia says about 1972. Think 1 Mhz 8080 as "top of the line" micro 
processor. The original 3277 and its controllers were STUPID. Rather than put a more powerful processor in the controller, IBM 
decided to offload the "complicated" function of calculating the position of the data into the host. Made of discrete 
transistors and resistors! Very primitive. So, the host just sent a simple to understand "buffer address" (a single 
number) to the 3274. It basically just starting stuffing data characters at that location in a RAM buffer. More power == most 
cost == fewer purchases. Much like some of the "krud" in z/OS today due to "short sighted" architects who 
were worried about memory and slow CPUs and expensive DASD.

The answer to these problems is obvious: Convert from archaic z/OS to modern Windows 8! At least 
that's what a lot of "Windows weenies" around here are saying. Over and over and over and 
over. "Better! Faster!! Cheaper!!!" is their cry. Anything z/OS can do, they state can be 
done using Windows and at lower TCO. Herr Gobbles would be proud of them.
 


---
Leave us also keep in mind another set of parameters that are significant.

While the Windoze-based processors may be blindingly fast at doing 
arithmetic, when it comes to large-scale data movements they are 
abysmally slow. Large-scale data mining operations are nothing 
more than a far-off dream of the future for Windoze processors. 
Similarly, processing of large matrices is a similar pipe-dream, unless 
the entire matrix can be maintained in RAM, as opposed to disk storage. 
"Windoze security" is an oxymoron, as is "reliability" (but it's slowly 
improving). We know that the big iron has a few drawbacks; when are the 
"Windoze Weenies" going to realize that the same is true of their platforms?


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: TSO SCREENSIZE

[Rick Fochtman]

---


Remember how old the 3270 architecture is. Wikipedia says about 1972.
Think 1 Mhz 8080 as "top of the line" micro processor. The original
3277 and its controllers were STUPID. Rather than put a more powerful
processor in the controller, IBM decided to offload the "complicated"
function of calculating the position of the data into the host. Made
of discrete transistors and resistors! Very primitive. So, the host
just sent a simple to understand "buffer address" (a single number)
to the 3274.
   



Not without a time machine. The 3274 came later. The original 3270
controller lineup was 3271, 3272 and 3275, the latter combining
controller and display.
 


--
Wasn't there also a 3276, with a display and controller that would 
handle the integerated display, plus 7 more display-only devices?


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: TSO SCREENSIZE

[McKown, John]

My phrasing is getting to be very poor. By STUPID, I meant more that the 
architecture implementation was primitive compared to today's architecures. Not 
that the designers or the design was stupid. It just resulted in a "stupid 
computer" (one with not many abilities) compared to today's "smart computers". 
Which will be considered "stupid" in the future.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason
> Sent: Thursday, November 10, 2011 1:08 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: TSO SCREENSIZE
> 
> John
> 
> > 3274
> 
> 3271
> 
> > STUPID
> 
> From the perspective of the new millennium. At the time (1970 
> approximately) I'm sure it was a sensible design choice.
> 
> Chris Mason
> 
> On Thu, 10 Nov 2011 11:48:30 -0600, McKown, John 
>  wrote:
> 
> > ...
> >
> >Remember how old the 3270 architecture is. Wikipedia says 
> about 1972. Think 1 Mhz 8080 as "top of the line" micro 
> processor. The original 3277 and its controllers were STUPID. 
> Rather than put a more powerful processor in the controller, 
> IBM decided to offload the "complicated" function of 
> calculating the position of the data into the host. Made of 
> discrete transistors and resistors! Very primitive. So, the 
> host just sent a simple to understand "buffer address" (a 
> single number) to the 3274. It basically just starting 
> stuffing data characters at that location in a RAM buffer. 
> More power == most cost == fewer purchases. Much like some of 
> the "krud" in z/OS today due to "short sighted" architects 
> who were worried about memory and slow CPUs and expensive DASD.
> >
> >The answer to these problems is obvious: Convert from 
> archaic z/OS to modern Windows 8! At least that's what a lot 
> of "Windows weenies" around here are saying. Over and over 
> and over and over. "Better! Faster!! Cheaper!!!" is their 
> cry. Anything z/OS can do, they state can be done using 
> Windows and at lower TCO. Herr Gobbles would be proud of them.
> >
> >--
> >John McKown
> 
> --
> 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: TSO SCREENSIZE

[Shmuel Metz (Seymour J.)]

In <9616460194674244.wa.juergen.kellerdeutscheboerse@bama.ua.edu>,
on 11/10/2011
   at 07:23 AM, Juergen Keller 
said:

>I wonder what the TERMINAL-command is for.

It saves the information for use by VTIOC and applications.

>When I change SCRSIZE I can see that something changes but not for
>the application issuing some TPUTs

It's the responsibility of the application to query the screen size
before doing full-screen I/O. If the application only uses line mode
then VTIOC will handle the screen geometry automatically.

>(I think that are TPUTs). 

TPUT is certainly the most common interface to VTIOC.

>I traced the data send to the screen and there where only the
>typical 2-byte-fields giving the position.

Yes, and the application needs the screen width in order to convert
row/column to buffer address.

>Yes we can change the application program but its a very old one and
>I think noone will do that.

Then run it in an 80-wide screen.
 
-- 
 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: TSO SCREENSIZE

[Chris Mason]

John

> 3274

3271

> STUPID

>From the perspective of the new millennium. At the time (1970 approximately) 
>I'm sure it was a sensible design choice.

Chris Mason

On Thu, 10 Nov 2011 11:48:30 -0600, McKown, John 
 wrote:

> ...
>
>Remember how old the 3270 architecture is. Wikipedia says about 1972. Think 1 
>Mhz 8080 as "top of the line" micro processor. The original 3277 and its 
>controllers were STUPID. Rather than put a more powerful processor in the 
>controller, IBM decided to offload the "complicated" function of calculating 
>the position of the data into the host. Made of discrete transistors and 
>resistors! Very primitive. So, the host just sent a simple to understand 
>"buffer address" (a single number) to the 3274. It basically just starting 
>stuffing data characters at that location in a RAM buffer. More power == most 
>cost == fewer purchases. Much like some of the "krud" in z/OS today due to 
>"short sighted" architects who were worried about memory and slow CPUs and 
>expensive DASD.
>
>The answer to these problems is obvious: Convert from archaic z/OS to modern 
>Windows 8! At least that's what a lot of "Windows weenies" around here are 
>saying. Over and over and over and over. "Better! Faster!! Cheaper!!!" is 
>their cry. Anything z/OS can do, they state can be done using Windows and at 
>lower TCO. Herr Gobbles would be proud of them.
>
>--
>John McKown

--
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: TSO SCREENSIZE

[Shmuel Metz (Seymour J.)]

In ,
on 11/10/2011
   at 11:48 AM, "McKown, John"  said:

>Remember how old the 3270 architecture is. Wikipedia says about 1972.
>Think 1 Mhz 8080 as "top of the line" micro processor. The original
>3277 and its controllers were STUPID. Rather than put a more powerful
>processor in the controller, IBM decided to offload the "complicated"
>function of calculating the position of the data into the host. Made
>of discrete transistors and resistors! Very primitive. So, the host
>just sent a simple to understand "buffer address" (a single number)
>to the 3274.

Not without a time machine. The 3274 came later. The original 3270
controller lineup was 3271, 3272 and 3275, the latter combining
controller and display.
 
-- 
 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: TSO SCREENSIZE

[Staller, Allan]

Neither is Unix, nor ACSII


"42" is _not_ the answer to life, the universe, and everything.
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: TSO SCREENSIZE

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Thursday, November 10, 2011 11:21 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: TSO SCREENSIZE
> 
> On Thu, 10 Nov 2011 09:35:18 -0600, John P Kalinich wrote:
> 
> >Greg Price of the IBM Mainframe Discussion List 
> 
> >wrote on 11/10/2011 08:46:03 AM:
> >
> >> Unless they have fixed it fairly recently, SDSF does not 
> handle large
> >screen
> >> sizes well (unless running as an ISPF application).
> >
> >One problem with large screens in SDSF (ISPF) is that the 
> ISFCMD variable
> >is limited to 42 characters.
> > 
> The often recurrence of topics related to this impels me to 
> the belief that
> the design philosophy of the 327x series is fundamentally flawed.
> 
> To begin, why doesn't it address character cells by 
> (row,column) coordinates
> rather than numbering the cells sequentially over the entire 
> screen?  The
> former alternative would result in far more graceful behavior 
> with unexpected
> screen sizes; the latter merely saves a few bits in the 
> address representation.
> "Penny wise and pound foolish."  Unforgivably shortsighted.
> 
> "42" is _not_ the answer to life, the universe, and everything.
> 
> -- gil

Remember how old the 3270 architecture is. Wikipedia says about 1972. Think 1 
Mhz 8080 as "top of the line" micro processor. The original 3277 and its 
controllers were STUPID. Rather than put a more powerful processor in the 
controller, IBM decided to offload the "complicated" function of calculating 
the position of the data into the host. Made of discrete transistors and 
resistors! Very primitive. So, the host just sent a simple to understand 
"buffer address" (a single number) to the 3274. It basically just starting 
stuffing data characters at that location in a RAM buffer. More power == most 
cost == fewer purchases. Much like some of the "krud" in z/OS today due to 
"short sighted" architects who were worried about memory and slow CPUs and 
expensive DASD.

The answer to these problems is obvious: Convert from archaic z/OS to modern 
Windows 8! At least that's what a lot of "Windows weenies" around here are 
saying. Over and over and over and over. "Better! Faster!! Cheaper!!!" is their 
cry. Anything z/OS can do, they state can be done using Windows and at lower 
TCO. Herr Gobbles would be proud of them.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
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: TSO SCREENSIZE

[Ford Prefect]

Blasphemer!

;-)

On Thu, Nov 10, 2011 at 12:21 PM, Paul Gilmartin wrote:

>
> "42" is _not_ the answer to life, the universe, and everything.
>
> -- 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: TSO SCREENSIZE

[Paul Gilmartin]

On Thu, 10 Nov 2011 09:35:18 -0600, John P Kalinich wrote:

>Greg Price of the IBM Mainframe Discussion List 
>wrote on 11/10/2011 08:46:03 AM:
>
>> Unless they have fixed it fairly recently, SDSF does not handle large
>screen
>> sizes well (unless running as an ISPF application).
>
>One problem with large screens in SDSF (ISPF) is that the ISFCMD variable
>is limited to 42 characters.
> 
The often recurrence of topics related to this impels me to the belief that
the design philosophy of the 327x series is fundamentally flawed.

To begin, why doesn't it address character cells by (row,column) coordinates
rather than numbering the cells sequentially over the entire screen?  The
former alternative would result in far more graceful behavior with unexpected
screen sizes; the latter merely saves a few bits in the address representation.
"Penny wise and pound foolish."  Unforgivably shortsighted.

"42" is _not_ the answer to life, the universe, and everything.

-- 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: TSO SCREENSIZE

[John P Kalinich]

Greg Price of the IBM Mainframe Discussion List 
wrote on 11/10/2011 08:46:03 AM:

> Unless they have fixed it fairly recently, SDSF does not handle large
screen
> sizes well (unless running as an ISPF application).

One problem with large screens in SDSF (ISPF) is that the ISFCMD variable
is limited to 42 characters.

Regards,
John K

--
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: TSO SCREENSIZE

[Edward Jaffe]

On 11/10/2011 5:23 AM, Juergen Keller wrote:

Yes we can change the application program but its a very old one and I think 
noone will do that. As explained before the same Problem happens with SDSF 
nativ under TSO and that is definitely a new application.


New?? Lol! That native 3270 support in SDSF is older than dirt!

--
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: TSO SCREENSIZE

[Greg Price]

Juergen Keller wrote:
> I wonder what the TERMINAL-command is for.

The TERMINAL SCRSIZE setting controls how TSO line-mode
terminal housekeeping is performed. Fullscreen applications
are free to use an available screen size different from the
one used by line-mode TSO. Of course, many fullscreen apps
use GTSIZE to ascertain the line-mode screen dimensions
and then proceed to use this size also. And then some apps
use GTTERM to ascertain the primary and alternate screen
sizes that the terminal supports, and choose one without
inspecting the current line-mode screen size setting. And
then again, some apps just proceed on the basis that the
screen size is 24 by 80 without checking. Unless they have
fixed it fairly recently, SDSF does not handle large screen
sizes well (unless running as an ISPF application).

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: TSO SCREENSIZE

[Juergen Keller]

I wonder what the TERMINAL-command is for. When I change SCRSIZE I can see that 
something changes but not for the application issuing some TPUTs (I think that 
are TPUTs). I traced the data send to the screen and there where only the 
typical 2-byte-fields giving the position. And this is shown with the the 
physical screen size of the terminal and NOT the physical screensize changed 
with the TERMINAL-command. 
Yes we can change the application program but its a very old one and I think 
noone will do that. As explained before the same Problem happens with SDSF 
nativ under TSO and that is definitely a new application.
Its very frustrating 

--
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: TSO SCREENSIZE

[Shmuel Metz (Seymour J.)]

In <2925062076757125.wa.juergen.kellerdeutscheboerse@bama.ua.edu>,
on 11/04/2011
   at 08:53 AM, Juergen Keller 
said:

>I have a strange problem and maybe someone had the same and had 
>a solution for this we got new terminals with bigger sizes 
>and now the users wants to use the "new" PCOM-size of 62x160 which 
>is supported I think since PCOM6.0.

Does PCOMM allow you to configure it as 3290 (i.e., explicit
partitions)? If so, and if the application uses the ISPF Dialog
Manager, then you can use VSPLIT before running the application and
let it run in an 80-wide window.

>Now I had the idea to use the TERMINAL-command and set the
>screensize to 43x80 for this application 

TERMINAL doesn't *change* the screen geometry; it tells the software
what geometry to assume. What ahh[ens if you set the screen width to
160?

>The problem now is what are this very old applications doing?

Among other things, probably using 12-bit addresses, which won't work
with a large screen.
 
-- 
 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: TSO SCREENSIZE

[Linda Mooney]

Tag Juergen, 



Some applications use screen maps to control how they display.  We have some 
like that in my shop .  If used with a screen size that a screen map has not 
been defined for, the display results can be anything from really wierd to just 
a not very helpful error message.  Depends on how the application was written. 



The applications programmers who support the application should know if screen 
maps  are used for it or not.  You might also find a .MAPS or .SKELTNS or 
similar dataset in the user's TSO proc, or in the application's STC.  



Of course, not knowing anything about your application or how it is written, 
this suggestion may, or may not, apply to your situation.  



HTH, 


Linda 


- Original Message -


From: "Juergen Keller"  
To: IBM-MAIN@bama.ua.edu 
Sent: Friday, November 4, 2011 6:53:32 AM 
Subject: TSO SCREENSIZE 

hello together, 
I have a strange problem and maybe someone had the same and had a solution for 
this 
we got new terminals with bigger sizes and now the users wants to use the "new" 
PCOM-size of 62x160 which is supported I think since PCOM6.0. So a user logon 
to TSO with the "variable" logmode D4C32XX3. In ISPF you can see that it uses 
62x160 (SDSF LOG) and TSO also uses 62x160 (also SDSF LOG). Now we have some 
ISPF-applications having problems with this logmode. The panels are not defined 
to ISPPLIB and look like "hardcoded" in the application. The result is that the 
panels are disrupted. The first line (80 bytes) of the panel is shown in line 1 
- byte 1-80 and the second line of the panel is shown in line 1 - byte 81-160. 
The result is that the panels look very stange. 

Now I had the idea to use the TERMINAL-command and set the screensize to 43x80 
for this application (first command in calling REXX). But unfortunately the 
result is the same. I can see that TSO has switched its size but the panels of 
the application are still disrupted. The problem now is what are this very old 
applications doing? Do we have sourcecode? We have no answer .. we only have 
that problem :-( 
  
Then I tried to call SDSF in READY-mode of TSO after I had changed the 
screensize to 43x80. The result is the same. The panel is disrupted and look 
like the problem we have with our applications. I can ask IBM (pmr) but I new 
the answer: "why are we doing that" and "this is not supported". But I only 
want to help the users to use 62x160 for ISPF and maybe 43x80 when using TSO. 
  
To make it complete confusing ... it you change SCRSIZE to 24x80 all looks fine 
... only with 32x80, 43x80 and 27x132 and SDSF called in READY-mode you have 
that problem (and also with our own application). 
  
Is there anyone who had the same problem in the past and got a solution? 

TNX Juergen 

-- 
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: TSO SCREENSIZE

[Turriff, Leslie]

Perhaps if you go to ISPF Settings (0 from the main menu) and set 
Screen format to Std that will help. (?)

Leslie Turriff
MO ITSD

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Juergen Keller
Sent: Friday, November 04, 2011 08:54
To: IBM-MAIN@bama.ua.edu
Subject: TSO SCREENSIZE

hello together,
I have a strange problem and maybe someone had the same and had a solution for 
this
we got new terminals with bigger sizes and now the users wants to use the "new" 
PCOM-size of 62x160 which is supported I think since PCOM6.0. So a user logon 
to TSO with the "variable" logmode D4C32XX3. In ISPF you can see that it uses 
62x160 (SDSF LOG) and TSO also uses 62x160 (also SDSF LOG). Now we have some 
ISPF-applications having problems with this logmode. The panels are not defined 
to ISPPLIB and look like "hardcoded" in the application. The result is that the 
panels are disrupted. The first line (80 bytes) of the panel is shown in line 1 
- byte 1-80 and the second line of the panel is shown in line 1 - byte 81-160. 
The result is that the panels look very stange. 

Now I had the idea to use the TERMINAL-command and set the screensize to 43x80 
for this application (first command in calling REXX). But unfortunately the 
result is the same. I can see that TSO has switched its size but the panels of 
the application are still disrupted. The problem now is what are this very old 
applications doing? Do we have sourcecode? We have no answer .. we only have 
that problem :-(
 
Then I tried to call SDSF in READY-mode of TSO after I had changed the 
screensize to 43x80. The result is the same. The panel is disrupted and look 
like the problem we have with our applications. I can ask IBM (pmr) but I new 
the answer: "why are we doing that" and "this is not supported". But I only 
want to help the users to use 62x160 for ISPF and maybe 43x80 when using TSO.
 
To make it complete confusing ... it you change SCRSIZE to 24x80 all looks fine 
... only with 32x80, 43x80 and 27x132 and SDSF called in READY-mode you have 
that problem (and also with our own application).
 
Is there anyone who had the same problem in the past and got a solution? 

TNX Juergen

--
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: TSO SCREENSIZE

[McKown, John]

Not knowing what the application does, the most I can do is hazard a guess. 
When you are in the application, can you swap screens? If not, then perhaps the 
application is not using ISPF screen management, but controlling the 3270 
screen itself (likely using TGET/TPUT or TPG. In this latter case, the 
application is using "buffer addresses" which it must calculate. The physical 
location of a given "buffer address" is dependant on the screen geometry. That 
is, it is not a simple row&column number, but a single number which is a 
function of the row,column, and screen geometry. And so the screen is 
"disrupted" when you do anything other than 24x80.

If the above is the case, then the "fix" is to rewrite the code to properly 
support multiple screen sizes. Or, as you have seen, run only in 24x80.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Juergen Keller
> Sent: Friday, November 04, 2011 8:54 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: TSO SCREENSIZE
> 
> hello together,
> I have a strange problem and maybe someone had the same and 
> had a solution for this
> we got new terminals with bigger sizes and now the users 
> wants to use the "new" PCOM-size of 62x160 which is supported 
> I think since PCOM6.0. So a user logon to TSO with the 
> "variable" logmode D4C32XX3. In ISPF you can see that it uses 
> 62x160 (SDSF LOG) and TSO also uses 62x160 (also SDSF LOG). 
> Now we have some ISPF-applications having problems with this 
> logmode. The panels are not defined to ISPPLIB and look like 
> "hardcoded" in the application. The result is that the panels 
> are disrupted. The first line (80 bytes) of the panel is 
> shown in line 1 - byte 1-80 and the second line of the panel 
> is shown in line 1 - byte 81-160. The result is that the 
> panels look very stange. 
> 
> Now I had the idea to use the TERMINAL-command and set the 
> screensize to 43x80 for this application (first command in 
> calling REXX). But unfortunately the result is the same. I 
> can see that TSO has switched its size but the panels of the 
> application are still disrupted. The problem now is what are 
> this very old applications doing? Do we have sourcecode? We 
> have no answer .. we only have that problem :-(
>  
> Then I tried to call SDSF in READY-mode of TSO after I had 
> changed the screensize to 43x80. The result is the same. The 
> panel is disrupted and look like the problem we have with our 
> applications. I can ask IBM (pmr) but I new the answer: "why 
> are we doing that" and "this is not supported". But I only 
> want to help the users to use 62x160 for ISPF and maybe 43x80 
> when using TSO.
>  
> To make it complete confusing ... it you change SCRSIZE to 
> 24x80 all looks fine ... only with 32x80, 43x80 and 27x132 
> and SDSF called in READY-mode you have that problem (and also 
> with our own application).
>  
> Is there anyone who had the same problem in the past and got 
> a solution? 
> 
> TNX Juergen
> 
> --
> 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

TSO SCREENSIZE

[Juergen Keller]

hello together,
I have a strange problem and maybe someone had the same and had a solution for 
this
we got new terminals with bigger sizes and now the users wants to use the "new" 
PCOM-size of 62x160 which is supported I think since PCOM6.0. So a user logon 
to TSO with the "variable" logmode D4C32XX3. In ISPF you can see that it uses 
62x160 (SDSF LOG) and TSO also uses 62x160 (also SDSF LOG). Now we have some 
ISPF-applications having problems with this logmode. The panels are not defined 
to ISPPLIB and look like "hardcoded" in the application. The result is that the 
panels are disrupted. The first line (80 bytes) of the panel is shown in line 1 
- byte 1-80 and the second line of the panel is shown in line 1 - byte 81-160. 
The result is that the panels look very stange. 

Now I had the idea to use the TERMINAL-command and set the screensize to 43x80 
for this application (first command in calling REXX). But unfortunately the 
result is the same. I can see that TSO has switched its size but the panels of 
the application are still disrupted. The problem now is what are this very old 
applications doing? Do we have sourcecode? We have no answer .. we only have 
that problem :-(
 
Then I tried to call SDSF in READY-mode of TSO after I had changed the 
screensize to 43x80. The result is the same. The panel is disrupted and look 
like the problem we have with our applications. I can ask IBM (pmr) but I new 
the answer: "why are we doing that" and "this is not supported". But I only 
want to help the users to use 62x160 for ISPF and maybe 43x80 when using TSO.
 
To make it complete confusing ... it you change SCRSIZE to 24x80 all looks fine 
... only with 32x80, 43x80 and 27x132 and SDSF called in READY-mode you have 
that problem (and also with our own application).
 
Is there anyone who had the same problem in the past and got a solution? 

TNX Juergen

--
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