Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #162501 > unrolled thread

Re: IBM's 96 column punch card (was System/3)?

Back to article view | Back to alt.folklore.computers

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: IBM's 96 column punch card (was System/3)? Quadibloc <jsavard@ecn.ab.ca> - 2016-04-15 07:16 -0700
    Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-04-15 17:16 +0200
      Re: IBM's 96 column punch card (was System/3)? "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-04-21 19:55 +1000
        Re: IBM's 96 column punch card (was System/3)? Stephen Wolstenholme <steve@easynn.com> - 2016-04-21 11:10 +0100
          Re: IBM's 96 column punch card (was System/3)? "J. Clarke" <j.clarke.873638@gmail.com> - 2016-04-21 22:17 -0400
    Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-15 14:03 -0700
    Re: IBM's 96 column punch card (was System/3)? Walter Bushell <proto@panix.com> - 2016-04-17 10:36 -0400
      Re: IBM's 96 column punch card (was System/3)? Stephen Wolstenholme <steve@easynn.com> - 2016-04-17 15:46 +0100
        Re: IBM's 96 column punch card (was System/3)? Dave Pitts <dpitts@cozx.com> - 2016-04-17 09:52 -0600
      Re: IBM's 96 column punch card (was System/3)? Gerard Schildberger <gerard46@rrt.net> - 2016-04-17 17:18 -0700
        Re: IBM's 96 column punch card (was System/3)? Walter Bushell <proto@panix.com> - 2016-04-22 11:01 -0400
          Re: IBM's 96 column punch card (was System/3)? Ahem A Rivet's Shot <steveo@eircom.net> - 2016-04-26 08:22 +0100
          Re: IBM's 96 column punch card (was System/3)? Ahem A Rivet's Shot <steveo@eircom.net> - 2016-04-26 08:20 +0100
      Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-19 11:44 -0700
        Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-20 01:36 +0000
          Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-20 16:58 -0700
            Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-21 03:52 +0000
              Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-21 12:37 -0700
              Re: IBM's 96 column punch card (was System/3)? Peter Flass <peter_flass@yahoo.com> - 2016-04-21 16:25 -0400
                Re: IBM's 96 column punch card (was System/3)? Dan Espen <despen@verizon.net> - 2016-04-21 17:35 -0400
                  Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-21 21:51 +0000
                    Re: IBM's 96 column punch card (was System/3)? Dan Espen <despen@verizon.net> - 2016-04-21 20:58 -0400
                      Re: IBM's 96 column punch card (was System/3)? Peter Flass <peter_flass@yahoo.com> - 2016-04-22 11:34 -0400
                        Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-22 12:53 -0700
                      Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-22 12:45 -0700
                    Re: IBM's 96 column punch card (was System/3)? Peter Flass <peter_flass@yahoo.com> - 2016-04-22 11:34 -0400
                      Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-22 12:55 -0700
                      Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-22 22:18 +0000
                    Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-22 12:38 -0700
                  Re: IBM's 96 column punch card (was System/3)? "Joe Morris" <j.c.morris@verizon.net> - 2016-04-21 21:21 -0400
                    Re: IBM's 96 column punch card (was System/3)? Dan Espen <despen@verizon.net> - 2016-04-21 22:21 -0400
                    Re: IBM's 96 column punch card (was System/3)? Anne & Lynn Wheeler <lynn@garlic.com> - 2016-04-21 21:53 -0700
                    Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-22 15:22 +0000
                      Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-04-22 17:55 +0000
                  Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-22 12:31 -0700
                    Re: IBM's 96 column punch card (was System/3)? Dan Espen <despen@verizon.net> - 2016-04-23 10:43 -0400
                      Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-23 12:48 -0700
                        Re: IBM's 96 column punch card (was System/3)? Peter Flass <peter_flass@yahoo.com> - 2016-04-23 16:21 -0400
                          Re: IBM's 96 column punch card (was System/3)? Dan Espen <despen@verizon.net> - 2016-04-23 18:12 -0400
                            Re: IBM's 96 column punch card (was System/3)? JimP <solosam90@gmail.com> - 2016-04-23 20:44 -0500
                              Re: IBM's 96 column punch card (was System/3)? Huge <Huge@nowhere.much.invalid> - 2016-04-24 09:09 +0000
                          Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-25 15:08 +0000
                          Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-25 13:39 -0700
                        Re: IBM's 96 column punch card (was System/3)? Dan Espen <despen@verizon.net> - 2016-04-23 18:07 -0400
                          Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-25 13:48 -0700
                            Re: IBM's 96 column punch card (was System/3)? Dan Espen <despen@verizon.net> - 2016-04-25 17:33 -0400
                              Re: IBM's 96 column punch card (was System/3)? "Joe Morris" <j.c.morris@verizon.net> - 2016-04-25 19:47 -0400
                                Re: IBM's 96 column punch card (was System/3)? Dan Espen <despen@verizon.net> - 2016-04-25 22:56 -0400
                              Re: IBM's 96 column punch card (was System/3)? Jon Elson <jmelson@wustl.edu> - 2016-04-26 17:51 -0500
                Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-21 21:40 +0000
                Re: IBM's 96 column punch card (was System/3)? Walter Bushell <proto@panix.com> - 2016-04-21 22:31 -0400
                  Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-22 15:22 +0000
                Re: IBM's 96 column punch card (was System/3)? Stephen Wolstenholme <steve@easynn.com> - 2016-04-22 07:15 +0100
                  Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-04-22 14:44 +0000
                Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-22 12:16 -0700
                  Re: IBM's 96 column punch card (was System/3)? Peter Flass <peter_flass@yahoo.com> - 2016-04-22 17:10 -0400
                Re: IBM's 96 column punch card (was System/3)? Gene Wirchenko <genew@telus.net> - 2016-04-22 22:38 -0700
                  Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-23 16:28 +0000
            Re: IBM's 96 column punch card (was System/3)? Peter Flass <peter_flass@yahoo.com> - 2016-04-21 12:35 -0400
              Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-21 12:41 -0700
                Re: IBM's 96 column punch card (was System/3)? Peter Flass <peter_flass@yahoo.com> - 2016-04-21 16:25 -0400
                  Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-22 12:18 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#162827

On 2016-04-21, Dan Espen <despen@verizon.net> wrote:

> Peter Flass <peter_flass@yahoo.com> writes:
>
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> 
>>> My first job was in a shop with three card readers.  
>>
>> Wow, I never saw a place with more than one!
>
> Sounds like your EAM procedures got moved to the computer without
> redesign.

At the time, we were a pure card shop - we had no disk or
tape drives on which to write data.  Not having to collate
and sort card decks saved a lot of time.

> I had a lot of designs handed to me that involved punching out
> new cards.  Somehow I managed to resist all that nonsense.

The boss was a hard-core tab man.  He never really trusted that
the data was there if you couldn't actually look at the holes.
Even after we got disks, a typical run would involve reading all
the card decks onto disk, doing the run, then punching out a new
set of cards for next time.  I eventually got frustrated enough
that when another job offer came along I left.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [next] | [standalone]

#162830

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:

> On 2016-04-21, Dan Espen <despen@verizon.net> wrote:
>
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>> 
>>>> My first job was in a shop with three card readers.  
>>>
>>> Wow, I never saw a place with more than one!
>>
>> Sounds like your EAM procedures got moved to the computer without
>> redesign.
>
> At the time, we were a pure card shop - we had no disk or
> tape drives on which to write data.  Not having to collate
> and sort card decks saved a lot of time.

Yep, but someone should have ordered some tapes or disk.

>> I had a lot of designs handed to me that involved punching out
>> new cards.  Somehow I managed to resist all that nonsense.
>
> The boss was a hard-core tab man.  He never really trusted that
> the data was there if you couldn't actually look at the holes.
> Even after we got disks, a typical run would involve reading all
> the card decks onto disk, doing the run, then punching out a new
> set of cards for next time.  I eventually got frustrated enough
> that when another job offer came along I left.

Yep, that would make me walk out the door too.
Knew a lot of old tab guys.
They always claimed they had all this special knowledge and
knew how things should be.
They were more of a liability than an asset.

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#162868

Dan Espen <despen@verizon.net> wrote:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> 
>> On 2016-04-21, Dan Espen <despen@verizon.net> wrote:
>> 
>>> Peter Flass <peter_flass@yahoo.com> writes:
>>> 
>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>>> 
>>>>> My first job was in a shop with three card readers.  
>>>> 
>>>> Wow, I never saw a place with more than one!
>>> 
>>> Sounds like your EAM procedures got moved to the computer without
>>> redesign.
>> 
>> At the time, we were a pure card shop - we had no disk or
>> tape drives on which to write data.  Not having to collate
>> and sort card decks saved a lot of time.
> 
> Yep, but someone should have ordered some tapes or disk.
> 
>>> I had a lot of designs handed to me that involved punching out
>>> new cards.  Somehow I managed to resist all that nonsense.
>> 
>> The boss was a hard-core tab man.  He never really trusted that
>> the data was there if you couldn't actually look at the holes.
>> Even after we got disks, a typical run would involve reading all
>> the card decks onto disk, doing the run, then punching out a new
>> set of cards for next time.  I eventually got frustrated enough
>> that when another job offer came along I left.
> 
> Yep, that would make me walk out the door too.
> Knew a lot of old tab guys.
> They always claimed they had all this special knowledge and
> knew how things should be.
> They were more of a liability than an asset.
> 

Maybe.  Those old tab systems might have lots of exceptions that the tab
guy would just handle.  When you went to program it based on what the
end-users said you'd discover each and every one of them in testing - or
when it went live.


-- 
Pete

[toc] | [prev] | [next] | [standalone]

#162887

On Friday, April 22, 2016 at 11:34:31 AM UTC-4, Peter Flass wrote:

> Maybe.  Those old tab systems might have lots of exceptions that the tab
> guy would just handle.  When you went to program it based on what the
> end-users said you'd discover each and every one of them in testing - or
> when it went live.

Yes, the old tab systems were actually amazingly flexible. Tab systems
required substantial skilled operator involvement, not just in
moving cards around and operating the machines, but also in running
and checking control totals, and searching out errors if things 
didn't balance.

Since the operators were doing all that stuff anyway, it wasn't
hard for them to handle, manually, special situations, and they
often did so, as described above.  

We had a pure tab application that stayed in service until about
1982.  It took that long until it was cost effective to develop
a CICS application that did everything the tab operators did.

(Once the application went live, they _abruptly_ fired the tab
operators.  This wasn't too onerous for them as they were all
past retirement age, but a little warning and a more dignified
transition would've been the right thing to do.)

[toc] | [prev] | [next] | [standalone]

#162886

On Thursday, April 21, 2016 at 8:58:30 PM UTC-4, D_J_E wrote:

> > At the time, we were a pure card shop - we had no disk or
> > tape drives on which to write data.  Not having to collate
> > and sort card decks saved a lot of time.
> 
> Yep, but someone should have ordered some tapes or disk.

The cost of that additional hardware, way back then, might have 
exceeded the time and material savings.  There were many bare bones
1401 installations--CPU only, with 1,400 characters of memory.

In our 360-40 shop, we had two 2415 tape drives--the budget model,
that were extremely slow.  I naturally wanted faster drives, but
the cost wasn't coming out of my pocket.


> Knew a lot of old tab guys.
> They always claimed they had all this special knowledge and
> knew how things should be.
> They were more of a liability than an asset.

A _good_ "tab guy" wasn't actually a "tab guy", but an "information
processing" guy.  While he knew the card machine technology well,
the good ones could also see the big picture and easily transition
into electronic computers, and make good use of them.

I learned a heck of a lot from the good tab guys.

They were particularly useful in techniques that didn't change
from card to computer, such as how to recover production after
a crash, dealing with end clients, or things like designing a
source document for maximum efficiency and effectiveness and
ease of key punching, and designing an output report for maximum
clarity and usefulness.

[toc] | [prev] | [next] | [standalone]

#162867

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2016-04-21, Dan Espen <despen@verizon.net> wrote:
> 
>> Peter Flass <peter_flass@yahoo.com> writes:
>> 
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>> 
>>>> My first job was in a shop with three card readers.  
>>> 
>>> Wow, I never saw a place with more than one!
>> 
>> Sounds like your EAM procedures got moved to the computer without
>> redesign.
> 
> At the time, we were a pure card shop - we had no disk or
> tape drives on which to write data.  Not having to collate
> and sort card decks saved a lot of time.
> 
>> I had a lot of designs handed to me that involved punching out
>> new cards.  Somehow I managed to resist all that nonsense.
> 
> The boss was a hard-core tab man.  He never really trusted that
> the data was there if you couldn't actually look at the holes.
> Even after we got disks, a typical run would involve reading all
> the card decks onto disk, doing the run, then punching out a new
> set of cards for next time.  I eventually got frustrated enough
> that when another job offer came along I left.
> 

We had a boss like that.  He insisted that all program source had to be
cards.  When we got TSO and I had to make more than a few cards-worth of
changes to a program I'd read it in, edit it online, and punch out a new
deck when I was done.  Pretty soon he gave up on the requirement for cards.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#162888

On Friday, April 22, 2016 at 11:34:31 AM UTC-4, Peter Flass wrote:


> We had a boss like that.  He insisted that all program source had to be
> cards.  When we got TSO and I had to make more than a few cards-worth of
> changes to a program I'd read it in, edit it online, and punch out a new
> deck when I was done.  Pretty soon he gave up on the requirement for cards.

+1 (when we got ADR's Librarian.  We quickly abandoned decks, though.)

[toc] | [prev] | [next] | [standalone]

#162893

On 2016-04-22, Peter Flass <peter_flass@yahoo.com> wrote:

> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> 
>> The boss was a hard-core tab man.  He never really trusted that
>> the data was there if you couldn't actually look at the holes.
>> Even after we got disks, a typical run would involve reading all
>> the card decks onto disk, doing the run, then punching out a new
>> set of cards for next time.  I eventually got frustrated enough
>> that when another job offer came along I left.
>
> We had a boss like that.  He insisted that all program source had to be
> cards.  When we got TSO and I had to make more than a few cards-worth of
> changes to a program I'd read it in, edit it online, and punch out a new
> deck when I was done.  Pretty soon he gave up on the requirement for cards.

At one shop we got a new manager who had worked in a larger IBM shop and was
used to storing source code on disk, while in the sort of shops where I was
working it was unheard of.  "Why can't you store source code on disk?" he
asked me one day.  "But you can!" I exclaimed delightedly, relieved to
finally have an opportunity to do so.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [next] | [standalone]

#162884

On Thursday, April 21, 2016 at 5:50:16 PM UTC-4, Charlie Gibbs wrote:


> The boss was a hard-core tab man.  He never really trusted that
> the data was there if you couldn't actually look at the holes.
> Even after we got disks, a typical run would involve reading all
> the card decks onto disk, doing the run, then punching out a new
> set of cards for next time.  I eventually got frustrated enough
> that when another job offer came along I left.

Depending on the time frame, I can understand where that boss was
coming from.  In the old, old days, too many people experienced
the horror of watching a tape get caught and shredded in the drive,
or be so full of read errors as to be unusable.  Or, when an input
file was accidently read over.  People used to back up disk files,
but did they make a duplicate copy of a master tape file after a
posting run?


The Bell System used punched paper tape to record long distance
calling for billing purposes, and waited for _years_ before they
were willing to go to mag tape, which was far more efficient.
They were afraid of losing data on the mag tapes.

[toc] | [prev] | [next] | [standalone]

#162831

"Dan Espen" <despen@verizon.net> wrote:

[IBM mainframe card readers]
> 2540 and a 2501.
> The 2501 never got much use.
> I always felt the 2501 was a favor for the salesman.

The 2540 wasn't just a card reader; it also had a card punch (and, as an 
optional feature, could use the punch side as a second reader). 
Additionally, the 2540 could not be directly attached to the computer's 
channel; it required a separate control unit (2820) - at, of course, 
additional cost.  (Note that a 2820 could support up to three 140x printers 
in addition to the 2540.)  The 2820 occupied about the same floor space as 
the 2540.

The 2501, on the other hand, had the control unit function built into the 
frame. Where the 2540 used wire brushes to read all 80 columns in parallel 
(9-row first), the 2501 read the card with optical sensors, one column at a 
time (cc1 first).  A distinct advantage of the 2501 in a college environment 
was that it wa reasonably fool-resistant, to the point that my PPOE (a Very 
Large State University) put one in the door to the computer room where 
students could read in their own job decks.

One way that IBM kept down the cost of the 2501 was that while the 2540/2820 
read and stored a complete image of the card just read (and the program 
could read it multiple times (*) before requesting that the next card be 
read), the 2501 had the ability to store only a single column at a time: 
when a column was read the 2501 had to be able to send that column (either 
as an EBCDIC character or as a 12-bit binary field) before the next column 
arrived at the optical sense station.

Joe

(*) This allowed the program to read a card as a binary image, then 
programmatically check cc1 for a 7-9 punch (the flag for a binary card) and 
if the card wasn't binary, then read it again as EBCDIC.  The 2501 didn't 
have this capability, so if you didn't know whether a card was binary or 
EBCDIC you had to read it as binary, and if it wasn't binary, 
programmatically translate the binary data into EBCDIC.  I wrote a program 
to do this, and would hesitate to even guess at the amount of time I spent 
trying to optimize the translation logic (this was on a 360/40, in an 
environment that could not exceed 6 KB for the entire program, so no room 
for a TR table) to be able to request the next card before the reader gears 
reached their clutch point.  I was quite happy to see the binary machine (a 
7040) leave a few years later. 

[toc] | [prev] | [next] | [standalone]

#162840

"Joe Morris" <j.c.morris@verizon.net> writes:

> "Dan Espen" <despen@verizon.net> wrote:
>
> [IBM mainframe card readers]
>> 2540 and a 2501.
>> The 2501 never got much use.
>> I always felt the 2501 was a favor for the salesman.
>
> The 2540 wasn't just a card reader; it also had a card punch (and, as an 
> optional feature, could use the punch side as a second reader). 
> Additionally, the 2540 could not be directly attached to the computer's 
> channel; it required a separate control unit (2820) - at, of course, 

2820->2821

> additional cost.  (Note that a 2820 could support up to three 140x printers 

Six models of the IBM 2821 Control Unit were available, as follows:

    Model 1 attached one IBM 2540 and one IBM 1403;
    Model 2 attached one IBM 1403;
    Model 3 attached two or three IBM 1403s;
    Model 4 attached one IBM 2540 and one IBM 1404, but only on IBM System/360 models 30, 40 and 50;
    Model 5 attached one IBM 2540 and two or three IBM 1403s; and
    Model 6 attached one IBM 2540.

..


-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#162853

"Joe Morris" <j.c.morris@verizon.net> writes:
> The 2540 wasn't just a card reader; it also had a card punch (and, as an 
> optional feature, could use the punch side as a second reader). 
> Additionally, the 2540 could not be directly attached to the computer's 
> channel; it required a separate control unit (2820) - at, of course, 
> additional cost.  (Note that a 2820 could support up to three 140x printers 
> in addition to the 2540.)  The 2820 occupied about the same floor space as 
> the 2540.

2540 had punch on one side and reader on the other side with five
stackers in the middle ... two for the reader, two for the punch and
middle could be used by both reader and punch.

one of my first programming jobs at the univ was class registration
... still done in the gym with tables for classes and sense mark cards
... which are then interpreted/punched. large number of card trays
(about 3000 cards per tray). read card into middle stacker, validate the
card information ... and if there is problem, punch a "blank" card
behind it (card punch loaded with colored cards).

later problem cards can be identified in the trays by colored card
punched behind it.

virtual (ios3270) green card (converted to html) reader/punch CCWs (says
3504, 3505, 3525, similar for 2540, but select three stackers)
http://manana.garlic.com/~lynn/gcard.html#23

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#162866

On 2016-04-22, Joe Morris <j.c.morris@verizon.net> wrote:

> One way that IBM kept down the cost of the 2501 was that while the 2540/2820 
> read and stored a complete image of the card just read (and the program 
> could read it multiple times (*) before requesting that the next card be 
> read), the 2501 had the ability to store only a single column at a time: 
> when a column was read the 2501 had to be able to send that column (either 
> as an EBCDIC character or as a 12-bit binary field) before the next column 
> arrived at the optical sense station.
>
> Joe
>
> (*) This allowed the program to read a card as a binary image, then 
> programmatically check cc1 for a 7-9 punch (the flag for a binary card) and 
> if the card wasn't binary, then read it again as EBCDIC.  The 2501 didn't 
> have this capability, so if you didn't know whether a card was binary or 
> EBCDIC you had to read it as binary, and if it wasn't binary, 
> programmatically translate the binary data into EBCDIC.  I wrote a program 
> to do this, and would hesitate to even guess at the amount of time I spent 
> trying to optimize the translation logic (this was on a 360/40, in an 
> environment that could not exceed 6 KB for the entire program, so no room 
> for a TR table) to be able to request the next card before the reader gears 
> reached their clutch point.  I was quite happy to see the binary machine (a 
> 7040) leave a few years later. 

That must have been some hairy programming.  I remember looking at all
the inconsistencies in the EBCDIC code table and just shaking my head.

Univac worked around this by having their readers and punches run natively
in what they called "compressed code" (plus image mode if you really needed
column binary, but again you had to choose one or the other before reading).  
Compressed code copied row 9 directly to the high-order bit in memory;
the low-order 4 bits came from rows 8, 0, 11, and 12 (high to low).
The remaining three bits were determined by whichever of rows 1 through 7
were punched, as follows:

    Row   Bit pattern
    ---   -----------
   (none)  x000xxxx
     1     x011xxxx
     2     x101xxxx
     3     x001xxxx
     4     x010xxxx
     5     x100xxxx
     6     x111xxxx
     7     x110xxxx
           |   |||`-- row 12
           |   ||`--- row 11
           |   |`---- row 0
           |   `----- row 8
           `--------- row 9

I have no idea why the codes were chosen in this seemingly arbitrary
order, rather than just having row 1 be 001, row 2 002, etc.

Since no valid 8-bit code has more than one punch in rows 1 through 7,
this encoding worked well with a minimum of hardware.  To further save
on hardware, no validity checking was done; if there was more than one
of rows 1 through 7 punched, the corresponding codes were ORed together.
These codes had a one-to-one correspondence with EBCDIC; one TRanslate
instruction would convert it.

Object code decks were punched directly in this code, eliminating the
need for the loader to contain a translation table.  You could spot
fields that were initialized to blanks (X'40') by the run of columns
containing only a punch in row 5.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [next] | [standalone]

#162876

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>On 2016-04-22, Joe Morris <j.c.morris@verizon.net> wrote:
>
>> One way that IBM kept down the cost of the 2501 was that while the 2540/2820 
>> read and stored a complete image of the card just read (and the program 
>> could read it multiple times (*) before requesting that the next card be 
>> read), the 2501 had the ability to store only a single column at a time: 
>> when a column was read the 2501 had to be able to send that column (either 
>> as an EBCDIC character or as a 12-bit binary field) before the next column 
>> arrived at the optical sense station.
>>
>> Joe
>>
>> (*) This allowed the program to read a card as a binary image, then 
>> programmatically check cc1 for a 7-9 punch (the flag for a binary card) and 
>> if the card wasn't binary, then read it again as EBCDIC.  The 2501 didn't 
>> have this capability, so if you didn't know whether a card was binary or 
>> EBCDIC you had to read it as binary, and if it wasn't binary, 
>> programmatically translate the binary data into EBCDIC.  I wrote a program 
>> to do this, and would hesitate to even guess at the amount of time I spent 
>> trying to optimize the translation logic (this was on a 360/40, in an 
>> environment that could not exceed 6 KB for the entire program, so no room 
>> for a TR table) to be able to request the next card before the reader gears 
>> reached their clutch point.  I was quite happy to see the binary machine (a 
>> 7040) leave a few years later. 
>
>That must have been some hairy programming.  I remember looking at all
>the inconsistencies in the EBCDIC code table and just shaking my head.

Burroughs would punch binary as 12-bits (3 digits/nibbles) per column.

The card reader I/O control/DLP had different OPs for reading BCL, EBCDIC
or BINARY.   Just after reset  the processor would issue the READ/BINARY
op and transfer control directly to the buffer address for the READ after it
completed.   The code on the first card would handle reading in the rest of
the bootstrap loader from cards.

[toc] | [prev] | [next] | [standalone]

#162881

On Thursday, April 21, 2016 at 5:35:03 PM UTC-4, D_J_E wrote:


> Sounds like your EAM procedures got moved to the computer without
> redesign.

In many installations, that was the whole idea--a relatively
painless way to install a real computer to replace a tab
operation.

Actually, it's not really a bad approach.  After the site gets
used to running the new machine--and there is a lot to get used
to after using tab machines--they can then slowly modernize the
old applications, like using disk and tape for intermediate files,
a program to do what the collator used to do, etc.


> I had a lot of designs handed to me that involved punching out
> new cards.  Somehow I managed to resist all that nonsense.

If you were already conversant in computer technology (e.g. JCL,
utilities, programming), it would be useful for you to upgrade
the old applications.  However, you would likely also need to
do some considerable training of the operators and other
programmers on new procedures, including abend recovery steps.

When I was a young-un, I had little patience for old time
managers who resisted new technology.  However, now that I
am old, I can now see their point.  The reality is that too often
many promises were (are) made for the power of new technology,
and too much is done too soon, resulting in a big mess.  I've
seen many early mainframe applications where far too much was
imposed on the limited hardware of era, creating a very slow
running and cumbersome system.

For example, in our S/360-40 shop, we did a lot of offline
sorting on our 082.  I didn't understand why we didn't use
the computer for that, as it presumably would be faster.  It
was explained here that with limited I/O and memory of the time,
sorting on the mainframe could be slow and not as efficient.
Also, some of the files being sorted were 1401 files, and sorting
on-line would've required changing the applications, not so easy.

The old tab machine applications were 'harder', that is, they
tended to run reasonably reliably.  They took time to run, but they
tended to meet their schedules day after day.  In the mainframe
world, there once were lots of outages--hardware faults in the
CPU, disk, tape, printer, card reader, etc.  Disk technology
could be unpredictable, with unexpected problems.

Management likes control and predictability, and they had more
of that in the tab world than with electronic computers.

[toc] | [prev] | [next] | [standalone]

#162902

hancock4@bbs.cpcn.com writes:

> On Thursday, April 21, 2016 at 5:35:03 PM UTC-4, D_J_E wrote:
>
>
>> Sounds like your EAM procedures got moved to the computer without
>> redesign.
>
> In many installations, that was the whole idea--a relatively
> painless way to install a real computer to replace a tab
> operation.
>
> Actually, it's not really a bad approach.  After the site gets
> used to running the new machine--and there is a lot to get used
> to after using tab machines--they can then slowly modernize the
> old applications, like using disk and tape for intermediate files,
> a program to do what the collator used to do, etc.
>
>
>> I had a lot of designs handed to me that involved punching out
>> new cards.  Somehow I managed to resist all that nonsense.
>
> If you were already conversant in computer technology (e.g. JCL,
> utilities, programming), it would be useful for you to upgrade
> the old applications.  However, you would likely also need to
> do some considerable training of the operators and other
> programmers on new procedures, including abend recovery steps.
>
> When I was a young-un, I had little patience for old time
> managers who resisted new technology.  However, now that I
> am old, I can now see their point.  The reality is that too often
> many promises were (are) made for the power of new technology,
> and too much is done too soon, resulting in a big mess.  I've
> seen many early mainframe applications where far too much was
> imposed on the limited hardware of era, creating a very slow
> running and cumbersome system.
>
> For example, in our S/360-40 shop, we did a lot of offline
> sorting on our 082.  I didn't understand why we didn't use
> the computer for that, as it presumably would be faster.  It
> was explained here that with limited I/O and memory of the time,
> sorting on the mainframe could be slow and not as efficient.
> Also, some of the files being sorted were 1401 files, and sorting
> on-line would've required changing the applications, not so easy.
>
> The old tab machine applications were 'harder', that is, they
> tended to run reasonably reliably.  They took time to run, but they
> tended to meet their schedules day after day.  In the mainframe
> world, there once were lots of outages--hardware faults in the
> CPU, disk, tape, printer, card reader, etc.  Disk technology
> could be unpredictable, with unexpected problems.
>
> Management likes control and predictability, and they had more
> of that in the tab world than with electronic computers.

Sounds like you're making excuses for those idiots.

Your argument about disk being unpredictable (especially
compared to card systems) is clearly wrong.

All of my experience showed new, well designed automation
could be error proof compared to card shuffling EAM based
systems.

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#162904

On Saturday, April 23, 2016 at 10:43:13 AM UTC-4, D_J_E wrote:

> > Management likes control and predictability, and they had more
> > of that in the tab world than with electronic computers.
> 
> Sounds like you're making excuses for those idiots.

Certainly, many managers are idiots.  However, managers do
have a different perspective--and responsibility--on the 
situation than the workers, so it is understandable they
would make different decisions.


> Your argument about disk being unpredictable (especially
> compared to card systems) is clearly wrong.

Computer mainframe hardware was significantly less reliable 
than it is today.  Today, it is extremely rare for our 
mainframe and CICS applications to be unavailable.  Forty
years ago, outages (for various reasons) were common.  The
360-40, 158 and supporting peripherals and operating systems
did not have the reliability as today's systems.

If you go back to pre-S/360 days, the hardware was even less
reliable.  Yes, an electronic computer had advantages over
electro-mechanical card machines, but in those days it was
understandable for a manager to be nervous.

Also, in those days, there was a shortage of competent qualified
programmers.  Histories (various books by MIT Press) report
that sometimes industry got stuck with academics who developed
notoriously poor systems, that didn't have good controls nor 
backup, and proved to be a mess in actual service.  Author
Alvin Townsend (Up the Organization) also wrote about this.

Unfortunately, back then many managers were at the mercy
of the new fellows--it was so new then few had the experience--
and managers weren't equipped to accurately judge if someone
was just bullsh** or not.
 
> All of my experience showed new, well designed automation
> could be error proof compared to card shuffling EAM based
> systems.

The key word was "well designed".  

Our first assignment in my college computer class was to 
bring in an example of a poor computer system.  Every
kid brought in not one, but multiple examples of systems
that they personally had trouble with.  Clearly, there were
lots of systems out there that, for whatever reason, were
not "well designed".

Fast forward to the present, I know of an expensive Oracle 
system that was supposed to replace a mainframe system.  Ten 
years later, the mainframe app remains in service in parallel 
since certain sub-functions were never developed, and 
certain things still do not work properly.

[toc] | [prev] | [next] | [standalone]

#162905

<hancock4@bbs.cpcn.com> wrote:
> On Saturday, April 23, 2016 at 10:43:13 AM UTC-4, D_J_E wrote:
> 
>>> Management likes control and predictability, and they had more
>>> of that in the tab world than with electronic computers.
>> 
>> Sounds like you're making excuses for those idiots.
> 
> Certainly, many managers are idiots.  However, managers do
> have a different perspective--and responsibility--on the 
> situation than the workers, so it is understandable they
> would make different decisions.
> 
> 
>> Your argument about disk being unpredictable (especially
>> compared to card systems) is clearly wrong.
> 
> Computer mainframe hardware was significantly less reliable 
> than it is today.  Today, it is extremely rare for our 
> mainframe and CICS applications to be unavailable.  Forty
> years ago, outages (for various reasons) were common.  The
> 360-40, 158 and supporting peripherals and operating systems
> did not have the reliability as today's systems.
> 
> If you go back to pre-S/360 days, the hardware was even less
> reliable.  Yes, an electronic computer had advantages over
> electro-mechanical card machines, but in those days it was
> understandable for a manager to be nervous.
> 
> Also, in those days, there was a shortage of competent qualified
> programmers.  Histories (various books by MIT Press) report
> that sometimes industry got stuck with academics who developed
> notoriously poor systems, that didn't have good controls nor 
> backup, and proved to be a mess in actual service.  Author
> Alvin Townsend (Up the Organization) also wrote about this.
> 
> Unfortunately, back then many managers were at the mercy
> of the new fellows--it was so new then few had the experience--
> and managers weren't equipped to accurately judge if someone
> was just bullsh** or not.
>  
>> All of my experience showed new, well designed automation
>> could be error proof compared to card shuffling EAM based
>> systems.
> 
> The key word was "well designed".  
> 
> Our first assignment in my college computer class was to 
> bring in an example of a poor computer system.  Every
> kid brought in not one, but multiple examples of systems
> that they personally had trouble with.  Clearly, there were
> lots of systems out there that, for whatever reason, were
> not "well designed".
> 
> Fast forward to the present, I know of an expensive Oracle 
> system that was supposed to replace a mainframe system.  Ten 
> years later, the mainframe app remains in service in parallel 
> since certain sub-functions were never developed, and 
> certain things still do not work properly.
> 
> 

Also, take  look at a lot of web applications.  It doesn't take long to
find numerous examples of atrocious design - lack of appropriate help,
impenetrable navigation, sites that force you to go back several steps to
make a simple correction, etc.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#162907

Peter Flass <peter_flass@yahoo.com> writes:

> <hancock4@bbs.cpcn.com> wrote:
>> On Saturday, April 23, 2016 at 10:43:13 AM UTC-4, D_J_E wrote:
>> 
>>>> Management likes control and predictability, and they had more
>>>> of that in the tab world than with electronic computers.
>>> 
>>> Sounds like you're making excuses for those idiots.
>> 
>> Certainly, many managers are idiots.  However, managers do
>> have a different perspective--and responsibility--on the 
>> situation than the workers, so it is understandable they
>> would make different decisions.
>> 
>> 
>>> Your argument about disk being unpredictable (especially
>>> compared to card systems) is clearly wrong.
>> 
>> Computer mainframe hardware was significantly less reliable 
>> than it is today.  Today, it is extremely rare for our 
>> mainframe and CICS applications to be unavailable.  Forty
>> years ago, outages (for various reasons) were common.  The
>> 360-40, 158 and supporting peripherals and operating systems
>> did not have the reliability as today's systems.
>> 
>> If you go back to pre-S/360 days, the hardware was even less
>> reliable.  Yes, an electronic computer had advantages over
>> electro-mechanical card machines, but in those days it was
>> understandable for a manager to be nervous.
>> 
>> Also, in those days, there was a shortage of competent qualified
>> programmers.  Histories (various books by MIT Press) report
>> that sometimes industry got stuck with academics who developed
>> notoriously poor systems, that didn't have good controls nor 
>> backup, and proved to be a mess in actual service.  Author
>> Alvin Townsend (Up the Organization) also wrote about this.
>> 
>> Unfortunately, back then many managers were at the mercy
>> of the new fellows--it was so new then few had the experience--
>> and managers weren't equipped to accurately judge if someone
>> was just bullsh** or not.
>>  
>>> All of my experience showed new, well designed automation
>>> could be error proof compared to card shuffling EAM based
>>> systems.
>> 
>> The key word was "well designed".  
>> 
>> Our first assignment in my college computer class was to 
>> bring in an example of a poor computer system.  Every
>> kid brought in not one, but multiple examples of systems
>> that they personally had trouble with.  Clearly, there were
>> lots of systems out there that, for whatever reason, were
>> not "well designed".
>> 
>> Fast forward to the present, I know of an expensive Oracle 
>> system that was supposed to replace a mainframe system.  Ten 
>> years later, the mainframe app remains in service in parallel 
>> since certain sub-functions were never developed, and 
>> certain things still do not work properly.
>
> Also, take  look at a lot of web applications.  It doesn't take long to
> find numerous examples of atrocious design - lack of appropriate help,
> impenetrable navigation, sites that force you to go back several steps to
> make a simple correction, etc.

Just ran into one the other day.
I attempted to register a new account.
Had to use my SS as an identifier.
My brain slipped out of gear and I typed my email 2x
as .com instead of .net.

Now I'm stuck with an account that is trying to email me
the verification code but can't.  No way on the site to
fix the email.  Hopefully they have a timeout period where
I can start over, but right now all it tells me is that
the account is already there.

The worst thing I find on the web are tiny fonts and low contrast
between foreground and background.  If you can't see it, what good is it?

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#162908

On Sat, 23 Apr 2016 18:12:20 -0400, Dan Espen <despen@verizon.net>
wrote:

>Peter Flass <peter_flass@yahoo.com> writes:
>
>> <hancock4@bbs.cpcn.com> wrote:
>>> On Saturday, April 23, 2016 at 10:43:13 AM UTC-4, D_J_E wrote:
>>> 
>>>>> Management likes control and predictability, and they had more
>>>>> of that in the tab world than with electronic computers.
>>>> 
>>>> Sounds like you're making excuses for those idiots.
>>> 
>>> Certainly, many managers are idiots.  However, managers do
>>> have a different perspective--and responsibility--on the 
>>> situation than the workers, so it is understandable they
>>> would make different decisions.
>>> 
>>> 
>>>> Your argument about disk being unpredictable (especially
>>>> compared to card systems) is clearly wrong.
>>> 
>>> Computer mainframe hardware was significantly less reliable 
>>> than it is today.  Today, it is extremely rare for our 
>>> mainframe and CICS applications to be unavailable.  Forty
>>> years ago, outages (for various reasons) were common.  The
>>> 360-40, 158 and supporting peripherals and operating systems
>>> did not have the reliability as today's systems.
>>> 
>>> If you go back to pre-S/360 days, the hardware was even less
>>> reliable.  Yes, an electronic computer had advantages over
>>> electro-mechanical card machines, but in those days it was
>>> understandable for a manager to be nervous.
>>> 
>>> Also, in those days, there was a shortage of competent qualified
>>> programmers.  Histories (various books by MIT Press) report
>>> that sometimes industry got stuck with academics who developed
>>> notoriously poor systems, that didn't have good controls nor 
>>> backup, and proved to be a mess in actual service.  Author
>>> Alvin Townsend (Up the Organization) also wrote about this.
>>> 
>>> Unfortunately, back then many managers were at the mercy
>>> of the new fellows--it was so new then few had the experience--
>>> and managers weren't equipped to accurately judge if someone
>>> was just bullsh** or not.
>>>  
>>>> All of my experience showed new, well designed automation
>>>> could be error proof compared to card shuffling EAM based
>>>> systems.
>>> 
>>> The key word was "well designed".  
>>> 
>>> Our first assignment in my college computer class was to 
>>> bring in an example of a poor computer system.  Every
>>> kid brought in not one, but multiple examples of systems
>>> that they personally had trouble with.  Clearly, there were
>>> lots of systems out there that, for whatever reason, were
>>> not "well designed".
>>> 
>>> Fast forward to the present, I know of an expensive Oracle 
>>> system that was supposed to replace a mainframe system.  Ten 
>>> years later, the mainframe app remains in service in parallel 
>>> since certain sub-functions were never developed, and 
>>> certain things still do not work properly.
>>
>> Also, take  look at a lot of web applications.  It doesn't take long to
>> find numerous examples of atrocious design - lack of appropriate help,
>> impenetrable navigation, sites that force you to go back several steps to
>> make a simple correction, etc.
>
>Just ran into one the other day.
>I attempted to register a new account.
>Had to use my SS as an identifier.
>My brain slipped out of gear and I typed my email 2x
>as .com instead of .net.
>
>Now I'm stuck with an account that is trying to email me
>the verification code but can't.  No way on the site to
>fix the email.  Hopefully they have a timeout period where
>I can start over, but right now all it tells me is that
>the account is already there.
>
>The worst thing I find on the web are tiny fonts and low contrast
>between foreground and background.  If you can't see it, what good is it?

Most sites like that you can contact the admin and they will reset.

-- 
JimP.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web