9 Feb
2011
9 Feb
'11
12:53 a.m.
What started out as a novelty search for an old IBM COBOL coding sheet
has turned into a serious-ish quest: I am now looking for any original
IBM (and other) coding forms so that I might build a collection on our
documents site.
As for IBM, Google has helped me uncover the part/form # GX28-1464 for
the COBOL form, GX09-0011 for FORTRAN and GX21-9279 for Assembler.
More useful would be part # GX21-9818, which is listed as "Coding
Forms Masters" and may contain these and other forms.
If anyone has these and can a) scan them with high quality or b)
lend/send them to me for scanning, I'd much appreciate it.
Of course, if my Google-fu has failed and they're already out there,
pointers to the downloads will do, too.
--
jht
9 Feb
9 Feb
9:44 p.m.
Hi Jason,
I have some HP printer layout forms. Has a grid for printer output of 132
columns, and a corresponding Vertical Format Control tape grid. I'd be happy to
send you one if you send me your email address.
Cheers,
Lee Courtney
Menlo Park, CA 94025
----- Original Message ----
From: Jason T <silent700 at gmail.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>;
chiclassiccomp at yahoogroups.com
Sent: Tue, February 8, 2011 9:53:38 PM
Subject: Seeking: IBM Coding Forms
What started out as a novelty search for an old IBM COBOL coding sheet
has turned into a serious-ish quest: I am now looking for any original
IBM (and other) coding forms so that I might build a collection on our
documents site.
As for IBM, Google has helped me uncover the part/form # GX28-1464 for
the COBOL form, GX09-0011 for FORTRAN and GX21-9279 for Assembler.
More useful would be part # GX21-9818, which is listed as "Coding
Forms Masters" and may contain these and other forms.
If anyone has these and can a) scan them with high quality or b)
lend/send them to me for scanning, I'd much appreciate it.
Of course, if my Google-fu has failed and they're already out there,
pointers to the downloads will do, too.
--
jht
4:52 p.m.
On Thu, Feb 10, 2011 at 2:51 PM, William Donzelli <wdonzelli at gmail.com> wrote:
Totally! This has turned into a generic coding and printer and tape
forms exercise, so why not? I have IBM FORTRAN but not CDC so that
would be great.
If you can't scan them, PM me and I'll give you an address for mailing.
Thanks!
-j
I am now
looking for any original
IBM (and other) coding forms so that I might build a collection on our
documents site.
Do FORTRAN coding forms count? I could probably spare a few CDC ones. 
6:36 p.m.
Jason T wrote:
Totally! This has turned into a generic coding and
printer and tape
forms exercise, so why not? I have IBM FORTRAN but not CDC so that
would be great.
Has anyone noticed that the size of IBM's coding forms (24 lines x 80
columns) was the same as the size of their terminals (e.g., 3277)? Was
this coincidence or intentional?
--
Dick Hadsell 203-992-6320 Fax: 203-992-6001
Reply-to: hadsell at blueskystudios.com
Blue Sky Studios http://www.blueskystudios.com
1 American Lane, Greenwich, CT 06831-2560
6:48 p.m.
Fred Cisin wrote:
80 columns goes back to way before their terminals.
Right. I meant that the size of the coding forms might have been used
to decide the size of the terminals.
--
Dick Hadsell 203-992-6320 Fax: 203-992-6001
Reply-to: hadsell at blueskystudios.com
Blue Sky Studios http://www.blueskystudios.com
1 American Lane, Greenwich, CT 06831-2560
7:02 p.m.
On Thu, 10 Feb 2011, Richard Hadsell wrote:
Right. I meant that the size of the coding forms
might have been used
to decide the size of the terminals.
Absolutely, with a few steps in between, such as the FORTRAN language
being designed with a fixed 80 columns. The cards caused a de-facto
standardization throughout the Data processing industry.
9:05 p.m.
On 10 Feb 2011 at 16:02, Fred Cisin wrote:
On Thu, 10 Feb 2011, Richard Hadsell wrote:
Actually, 72 columns. 73-80 wasn't used--that may go back to 704
hardwarware, I don't recall.
And 1-5 for statement numbers and 6 for continuation, so the actual
statement area was 66 columns if you didn't count the label field.
The CDC 3290's standard configuration was 50 characters x 20 lines.
You could get an option that would give you 80 x 13. Uppercase only,
of course.
The best the 6602 operator's display could do was 64 lines x 64
columns. That never stopped anyone from using O26 rather than trying
to find a spare keypunch. I believe that most of MACE/Kronos was
coded using O26 by Greg Mansfield using whatever systems were
available on the QA floor. It was the closest thing to a real
editing video terminal that most people had.
Doubtless there are many other early displays that did not do 80
characters. Heck, my TV Typewriter after modification only did 64
characters (originally it was 32 characters).
Cheers,
Chuck
Right. I meant that the size of the coding forms
might have been
used to decide the size of the terminals.
Absolutely, with a few steps in between, such as the FORTRAN language
being designed with a fixed 80 columns. The cards caused a de-facto
standardization throughout the Data processing industry.
9:19 p.m.
> Absolutely, with a few steps in between, such as
the FORTRAN language
> being designed with a fixed 80 columns. The cards caused a de-facto
> standardization throughout the Data processing industry.
On Thu, 10 Feb 2011, Chuck Guzis wrote:
Actually, 72 columns. 73-80 wasn't used--that may
go back to 704
hardwarware, I don't recall.
I have to disagree. Although 73-80 were not used by the COMPILER, they
were "reserved", so that you could put a sequence number on your cards.
That worked a little better for putting them back into order than the
diagonal felt-tip marker lines.
Most? FORTRAN coding sheets explicitly included those columns, so that you
could specify to the keypunchers what you wanted there.
And 1-5 for statement numbers and 6 for continuation,
so the actual
statement area was 66 columns if you didn't count the label field.
FORTRAN
without the label field??
The CDC 3290's standard configuration was 50
characters x 20 lines.
You could get an option that would give you 80 x 13. Uppercase only,
of course.
Of course. Using lower case means that you are showing off, or trying
to
whisper.
11:26 p.m.
On 10 Feb 2011 at 18:19, Fred Cisin wrote:
I have to disagree. Although 73-80 were not used by
the COMPILER,
they were "reserved", so that you could put a sequence number on your
cards. That worked a little better for putting them back into order
than the diagonal felt-tip marker lines. Most? FORTRAN coding sheets
explicitly included those columns, so that you could specify to the
keypunchers what you wanted there.
Yes, but they weren't part of FORTRAN, or COBOL, or JOVIAL or GPSS;
they were used for sequence numbers or dirty jokes. I didn't know of
anyone who actually punched sequence numbers by hand.
Remember that COBOL used 73-80, but as "program identification"; 1-6
were used for sequence numbers--and checked by most compilers. So
naturally, if you had half a brain in your head, you left them blank.
Realistically, you put your decks on tape as soon as you could. Most
operating systems had source maintenance utilities (e.g. CDC EDITSYM,
UPDATE or others), some of which extended the card image past 80
columns, so that very detailed sequence information could be added.
If you had to use and keep cards, you punched and interpreted a
duplicate deck using your handy-dandy mainframe or unit record gear
and inserted sequence numbers automatically.
At CDC, we'd use the PSR number as part of the sequence number.
Since UPDATE kept all card images, both active and inactive, you
could always "YANK" a correction ID set to reverse its effect. While
I had several filing cabinets of cards in my office, it was mostly in
case some butterfingers in Test and Integration lost the deck (this
was long before Unix VCS).
...but back to my original point. The 704, on which FORTRAN was
first developed could read only 72 columns of an 80 column card using
the 711 reader. You could program (via plugboard) any 72 columns to
be read, but that was it.
There's a very practical reason why the 72-column FORTRAN statement
came about.
--Chuck
9:18 p.m.
I don't recall who asked for them, but if you'll send me your mailing
address I'll send you two full pads of coding forms. One is for COBOL,
the other for FORTRAN.
They're roughly 13.5" wide by 8.5" high.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
Political correctness is a doctrine, fostered by a delusional, illogical
minority, and rabidly promoted by an unscrupulous mainstream media, which
holds forth the proposition that it is entirely possible to pick up a turd
by the clean end.
6:59 p.m.
On Thu, 10 Feb 2011, Richard Hadsell wrote:
Has anyone noticed that the size of IBM's coding
forms (24 lines x 80
columns) was the same as the size of their terminals (e.g., 3277)? Was
this coincidence or intentional?
Absolutely NOT coincidence.
First came the cards for data.
Those begat coding sheets for one person to write down the content, and
another to punch it onto cards.
Then came the languages (COBOL, FORTRAN, VALTREP?), many of which had
FIXED FORMATs, but based on 80 column cards
THSN came the terminals.
7:08 p.m.
Fred Cisin wrote:
On Thu, 10 Feb 2011, Richard Hadsell wrote:
That's the chronological order, and of course the forms were for
80-column cards. But why did the terminals, which replaced cards, have
to be 80 columns and, more coincidental, the same number of lines as on
a coding sheet? There was never any way to transfer from forms to the
terminal, other than by hand.
My best guess was only that IBM also printed forms for designing what
you wanted to display on the terminal, and they could use exactly the
same forms as for FORTRAN, with just some relabeling. That seems lame,
but there it was.
--
Dick Hadsell 203-992-6320 Fax: 203-992-6001
Reply-to: hadsell at blueskystudios.com
Blue Sky Studios http://www.blueskystudios.com
1 American Lane, Greenwich, CT 06831-2560
Has anyone noticed that the size of IBM's
coding forms (24 lines x 80
columns) was the same as the size of their terminals (e.g., 3277)? Was
this coincidence or intentional?
Absolutely NOT coincidence.
First came the cards for data.
Those begat coding sheets for one person to write down the content, and
another to punch it onto cards.
Then came the languages (COBOL, FORTRAN, VALTREP?), many of which had
FIXED FORMATs, but based on 80 column cards
THSN came the terminals.
7:41 p.m.
My best guess was only that IBM also printed forms for
designing what you
wanted to display on the terminal, and they could use exactly the same forms
as for FORTRAN, with just some relabeling. ?That seems lame, but there it
was.
When terminals finally hit the big time (early 1970s), there was still
a huge installed base of card technology out there. Disks were very
expensive, and disk packs were often in very short supply. It took
until the late 1970s for cards to finally fall. During the transition,
it only made sense to make the terminal standard adhere to the card
standard.
For example, imagine if terminals were standardized to 64 columns -
what do you do with all the data entry jobs and databases that use
columns 65 and up? Modify them? Programmers cost money. Or if
terminals had 100 columns - the memory chips inside the tubes were
damn expensive, and all those bits for the extra columns would not get
used much. An extra couple hundred bucks times hundreds of terminals
adds up, and looks really bad when they are not used.
--
Will
7:58 p.m.
On 2/10/2011 5:41 PM, William Donzelli wrote:
For example, imagine if terminals were standardized to
64 columns -
what do you do with all the data entry jobs and databases that use
columns 65 and up? Modify them? Programmers cost money. Or if
terminals had 100 columns - the memory chips inside the tubes were
damn expensive, and all those bits for the extra columns would not get
used much. An extra couple hundred bucks times hundreds of terminals
adds up, and looks really bad when they are not used.
Did anybody use 96 column terminals?
--
Will
Ben.
8:23 p.m.
On Thu, 10 Feb 2011, ben wrote:
Did anybody use 96 column terminals?
Later - in the 1980s (in the mid to late 1980s, I had 160 x 50!)
In the 1970s, anything more than 80 columns cost MONEY!
Even getting 80 columns was pushing some limits. That's why early
microcomputers, from the beginning, through Apple, Commodore and TRS80 ran
less than 80 columns. Of course it didn't help that the bulk of the
public used old TV sets. The RCA TV set that Radio Shak modified for the
TRS80 model I was not very high resolution.
'round about 1980, better video started to become available.
TRS80 model 4 had 80 x 24, and 80 column cards became available
for Apple ][.
--
Grumpy Ol' Fred cisin at xenosoft.com
8:48 p.m.
Somebody just left an IBM FLOWCHARTING TEMPLATE X20-8020 on the floor in
the hallway.
Remember when flowcharts were a REQUIRED part of documentation?
So, sure enough, we wrote a program that would take a deck of FORTRAN
cards and produce a flowchart. It was not a particcularly USABLE
flowchart, but it met the "requirement".
Perhaps we should couple a flowchart editor/creator with a code generator
as our next paradigm :-?
--
Grumpy Ol' Fred cisin at xenosoft.com
9:30 p.m.
On 2/10/2011 6:48 PM, Fred Cisin wrote:
Somebody just left an IBM FLOWCHARTING TEMPLATE
X20-8020 on the floor in
the hallway.
Remember when flowcharts were a REQUIRED part of documentation?
So, sure enough, we wrote a program that would take a deck of FORTRAN
cards and produce a flowchart. It was not a particcularly USABLE
flowchart, but it met the "requirement".
Perhaps we should couple a flowchart editor/creator with a code generator
as our next paradigm :-?
Only if you remember to number the cards by three ... :)
--
Grumpy Ol' Fred cisin at xenosoft.com
12 Feb
12 Feb
8:58 p.m.
New subject: OT: Coding revolution, was: Seeking: IBM Coding Forms
On 2/10/2011 7:48 PM, Fred Cisin wrote:
Somebody just left an IBM FLOWCHARTING TEMPLATE
X20-8020 on the floor in
the hallway.
Remember when flowcharts were a REQUIRED part of documentation?
So, sure enough, we wrote a program that would take a deck of FORTRAN
cards and produce a flowchart. It was not a particcularly USABLE
flowchart, but it met the "requirement".
Perhaps we should couple a flowchart editor/creator with a code generator
as our next paradigm :-?
--
Grumpy Ol' Fred cisin at xenosoft.com
Something along those lines has actually occurred to me too. I keep
thinking there should be *something* that could be done to revolutionize
the way software is created. I'm pretty convinced the way it's
currently done is not the answer. Though I still really enjoy writing C
code, and though I'm careful to try to create easily understandable and
maintainable code, I always seem to finish projects with the uneasy
feeling that it could have been done better, maybe a lot better. BTW, I
reject the idea that OO is the answer. I think when I was younger I
didn't feel that way; I was just happy that the blooming thing worked!
Maybe there's a penalty for spending too many years doing too many
projects - you start to get all philosophical about the process...
Later,
Charlie C.
9:35 p.m.
New subject: OT: Coding revolution, was: Seeking: IBM Coding Forms
On 12 Feb 2011 at 19:58, Charlie Carothers wrote:
Something along those lines has actually occurred to
me too. I keep
thinking there should be *something* that could be done to
revolutionize the way software is created. I'm pretty convinced the
way it's currently done is not the answer. Though I still really
enjoy writing C code, and though I'm careful to try to create easily
understandable and maintainable code, I always seem to finish projects
with the uneasy feeling that it could have been done better, maybe a
lot better. BTW, I reject the idea that OO is the answer. I think
when I was younger I didn't feel that way; I was just happy that the
blooming thing worked! Maybe there's a penalty for spending too many
years doing too many projects - you start to get all philosophical
about the process... Later, Charlie C.
Ah, the silver bullet problem. People claiming to have The Answer
have been around almost as long as electronic computing.
Anyone remember the "Pride Method"? I think (google doesn't turn it
up) a fellow by the name of Robert(?) Pride, who back in the 60's or
early 70's ran workshops on creating (mostly business) programs that
worked. His Method was fairly straightforward--start from results
(reports, screens, whatever) and inputs (data, user prompts) and work
backwards, coding backwards from these endpoints. Basic top-down
design stuff.
It was revolutionary back then, but probably wouldn't make a ripple
now.
OO may be *an* answer, but it's discipline and clear thinking that
will get you where you're going. Where things start to get ugly is
when "enhancements" are added to existing code. Pride insisted that
it was necessary to start the design process all over again when
enhancements that changed the fundamental nature of the prograom.
That's exactly what budget-conscious development managers didn't want
to hear, but it did make sense.
Cheers,
Chuck
13 Feb
13 Feb
11:23 a.m.
New subject: OT: Coding revolution, was: Seeking: IBM Coding Forms
As you all know, I'm heavily biased towards the hardware side, but much
of it is the same there...
OO may be *an* answer, but it's discipline and
clear thinking that
will get you where you're going. Where things start to get ugly is
Agreed... 'Banning' certain things becuase they make code (or hardware)
difficult to undersnd or maintian is silly IMHO. I've sene pefecrly
understnadable progeams with GOTOs (or their equivalent). I've seen right
messes trying to avoind them (condtionals around just about everything).
I've sene right messes of hardware built with monostables all triggering
each other so if one drifts a bit the whole lot falls over. And I've seen
them used properly. I've seen a right mess which claimed to be a state
machine too...
when "enhancements" are added to existing
code. Pride insisted that
Again I think it's a matter of (good) judgement. You can add small extra
feautres ot hardware or software without problems. But as you said, if
you want a major change, it's time tore-think the deisng from the start.
it was necessary to start the design process all over
again when
enhancements that changed the fundamental nature of the prograom.
That's exactly what budget-conscious development managers didn't want
to hear, but it did make sense.
I would add soemthing else that managers don't like, and that is that
using 'standard solutions' is not always best. Of course subroutine
libraries are a Good Thing. But over-use of them, when you mess about wit
hthe problem so that you can use one library routine after another, this
routine for this case, and that routine fo thtat case, often makes a less
reliable solution than writing the special routine to solve that problem.
Similarly in hardware, I don't like starting from a stnadard module
(microcontorler PCB, etc) and somehow making it fit the problem. I find
it better to actually think of the solution.
-tony
5:41 p.m.
New subject: OT: Coding revolution, was: Seeking: IBM Coding Forms
On 13 Feb 2011 at 16:23, Tony Duell wrote:
I would add soemthing else that managers don't
like, and that is that
using 'standard solutions' is not always best. Of course subroutine
libraries are a Good Thing. But over-use of them, when you mess about
wit hthe problem so that you can use one library routine after
another, this routine for this case, and that routine fo thtat case,
often makes a less reliable solution than writing the special routine
to solve that problem.
Brings up an interesting side question. Was FORTRAN also the
original for standard library routines, or was there something
earlier that was available cross-platform? (i.e. If I code "X =
MAX1F(A, B, C, E), it does the same on all platforms).
--Chuck
12 Feb
12 Feb
11:42 p.m.
New subject: OT: Coding revolution, was: Seeking: IBM Coding Forms
On 2011 Feb 12, at 5:58 PM, Charlie Carothers wrote:
On 2/10/2011 7:48 PM, Fred Cisin wrote:
Decades ago I wanted to think about designing a graphical GP
programming language, we (or many of us) conceptualise things in terms
of flowchart-like diagrams and state diagrams and such and they tend to
be considered useful descriptions, so why not program in them, and skip
the intermediate procedural text-based-stream language. I suspect there
have been many attempts or half-efforts over the years, I also suspect
they end up being incomplete as GP languages or end up looking like
hacks.
Some time ago while talking with a friend about this he suggested that
UML (Unified Modelling Language) is a serious effort in this direction.
A cursory inspection looks interesting, but I'm not close enough to it
to comment on it more than that.
It's interesting that hardware logic description in the form of
FPGA/CPLD configuration has taken what might be considered a backward
step, from the graphical schematic diagram to procedural-like
text-based-stream languages, not to say there aren't reasons for that
direction, but nonetheless the text-based language gets more ingrained
as the description paradigm.
Way back when, there was the stumbling block of lack of graphical user
interfaces, not as much of an issue these days, although an agreed-upon
underlying graphical description language may be still contentious.
Somebody just left an IBM FLOWCHARTING TEMPLATE
X20-8020 on the floor
in
the hallway.
Remember when flowcharts were a REQUIRED part of documentation?
So, sure enough, we wrote a program that would take a deck of FORTRAN
cards and produce a flowchart. It was not a particcularly USABLE
flowchart, but it met the "requirement".
Perhaps we should couple a flowchart editor/creator with a code
generator
as our next paradigm :-?
Something along those lines has actually occurred to me too. I keep
thinking there should be *something* that could be done to
revolutionize the way software is created. I'm pretty convinced the
way it's currently done is not the answer. Though I still really
enjoy writing C code, and though I'm careful to try to create easily
understandable and maintainable code, I always seem to finish projects
with the uneasy feeling that it could have been done better, maybe a
lot better. BTW, I reject the idea that OO is the answer. I think
when I was younger I didn't feel that way; I was just happy that the
blooming thing worked! Maybe there's a penalty for spending too many
years doing too many projects - you start to get all philosophical
about the process... 
13 Feb
13 Feb
1:34 p.m.
New subject: OT: Coding revolution, was: Seeking: IBM Coding Forms
Hello.
Remember when flowcharts were a REQUIRED part of documentation?
A) In my company, Flowcharts are yet required. But the Architecture Unit
make them.
B) If I remember it correctly, IBM had something so. I've read it in one of
my books.
C) And, of course, it's the infamous IBM truth tables program generator
referred in other of my books
Sergio
So, sure
enough, we wrote a program that would take a deck of FORTRAN
cards and produce a flowchart. It was not a particcularly USABLE
flowchart, but it met the "requirement".
2:21 p.m.
New subject: Coding revolution, was: Seeking: IBM Coding Forms
I've seen that. I'm not sure the folks who own it would be happy if I invoked
their corporate name (it was an internal tool), but that's exactly what they built: a
system that took flow charts and converted them to code. The code was nearly impossible
to maintain outside the tool environment, and awkward to maintain within it. -- Ian
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of
Charlie Carothers [csquared3 at tx.rr.com]
Sent: Saturday, February 12, 2011 5:58 PM
To: On-Topic Posts Only
Subject: OT: Coding revolution, was: Seeking: IBM Coding Forms
On 2/10/2011 7:48 PM, Fred Cisin wrote:
Somebody just left an IBM FLOWCHARTING TEMPLATE
X20-8020 on the floor in
the hallway.
Remember when flowcharts were a REQUIRED part of documentation?
So, sure enough, we wrote a program that would take a deck of FORTRAN
cards and produce a flowchart. It was not a particcularly USABLE
flowchart, but it met the "requirement".
Perhaps we should couple a flowchart editor/creator with a code generator
as our next paradigm :-?
--
Grumpy Ol' Fred cisin at xenosoft.com
Something along those lines has actually occurred to me too. I keep
thinking there should be *something* that could be done to revolutionize
the way software is created. I'm pretty convinced the way it's
currently done is not the answer. Though I still really enjoy writing C
code, and though I'm careful to try to create easily understandable and
maintainable code, I always seem to finish projects with the uneasy
feeling that it could have been done better, maybe a lot better. BTW, I
reject the idea that OO is the answer. I think when I was younger I
didn't feel that way; I was just happy that the blooming thing worked!
Maybe there's a penalty for spending too many years doing too many
projects - you start to get all philosophical about the process...
Later,
Charlie C.
2:24 p.m.
New subject: Coding revolution, was: Seeking: IBM Coding Forms
On 2/13/11 2:21 PM, Ian King wrote:
I've seen that. I'm not sure the folks who
own it would be happy if
I invoked their corporate name (it was an internal tool), but that's
exactly what they built: a system that took flow charts and converted
them to code. The code was nearly impossible to maintain outside the
tool environment, and awkward to maintain within it. -- Ian
So, kinda like most code generators, then.
-Dave
--
Dave McGuire
Port Charlotte, FL
2:49 p.m.
New subject: Coding revolution, was: Seeking: IBM Coding Forms
I've seen
that. I'm not sure the folks who own it would be happy if
I invoked their corporate name (it was an internal tool), but that's
exactly what they built: a system that took flow charts and converted
them to code. The code was nearly impossible to maintain outside the
tool environment, and awkward to maintain within it.
So, kinda like most code generators, then.
3:02 p.m.
New subject: Coding revolution, was: Seeking: IBM Coding Forms
On 2/13/11 2:49 PM, Cameron Kaiser wrote:
Having written several code generators for various projects, I resemble
that remark. :-P
That's ok Cameron, we like you anyway. ;)
-Dave (running for cover)
--
Dave McGuire
Port Charlotte, FL
I've seen that. I'm not sure the folks who
own it would be happy if
I invoked their corporate name (it was an internal tool), but that's
exactly what they built: a system that took flow charts and converted
them to code. The code was nearly impossible to maintain outside the
tool environment, and awkward to maintain within it.
So, kinda like most code generators, then.
3:11 p.m.
New subject: Coding revolution, was: Seeking: IBM Coding Forms
Having written
several code generators for various projects, I resemble
that remark. :-P
That's ok Cameron, we like you anyway. ;) 
5:47 p.m.
New subject: Coding revolution, was: Seeking: IBM Coding Forms
On 13/02/11 19:49, Cameron Kaiser wrote:
I'm having to write a code generator for a UML modelling tool with
aspect-oriented extensions. If it generates readable code, I'll be
amused. If it generates *maintainable* code, I'll be absolutely shocked.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
So, kinda like
most code generators, then.
Having written several code generators for various projects, I resemble
that remark. :-P
10 Feb
10 Feb
7:56 p.m.
On Thu, 10 Feb 2011, Richard Hadsell wrote:
That's the chronological order, and of course the
forms were for
80-column cards. But why did the terminals, which replaced cards, have
to be 80 columns
To replace cards, they "obviously" had to be at least 80 columns, and in
the early days, any more than that was pushing the limits on screen
quality.
and, more coincidental, the same number of lines as
on
a coding sheet? There was never any way to transfer from forms to the
terminal, other than by hand.
There was also never any PRACTICAL way to transfer from forms to CARDS,
other than by hand.
But, in most installations, PROGRAMMERS were not permitted to use the
keypunch machines, other than for correcting a single card at a time.
I had to write everything on forms, and hand them to the keypunchers to
punch. The "benefit": It took me longer to hand write than to use a
keyboard; there was an extra delay waiting for another department; and one
more human in the chain ready and able to add addtional mistakes.
My best guess was only that IBM also printed forms for
designing what
you wanted to display on the terminal, and they could use exactly the
same forms as for FORTRAN, with just some relabeling. That seems lame,
but there it was.
Yes, in addition to forms for punching cards, there were ALSO forms for
designing output (for 407's, printers, etc.). Those were also available
for video displays, although like DATA coding forms, they weren't much
more than graph paper.
Why "lame"?
They were designed specifically to replace cards. Why WOULDN'T they keep
the existing size and format?
Why did they create 80 x 24 monochrome text displays? Why didn't they go
straight to 32bit multi-megabyte graphics display? in 3D?
Has anybody else ever considered IBM to not be as innovative as they could
have been?
--
Grumpy Ol' Fred cisin at xenosoft.com
11 Feb
11 Feb
10:11 a.m.
On Thu, Feb 10, 2011 at 6:36 PM, Richard Hadsell
<hadsell at blueskystudios.com> wrote:
Has anyone noticed that the size of IBM's coding
forms (24 lines x 80
columns) was the same as the size of their terminals (e.g., 3277)? ?Was this
coincidence or intentional?
As many other have asserted, the 80-column part? Yes. It's also
handy for displaying part of a page to be typed at "pica" sizes (10
chars to the inch on a 8.5" page with 0.25" margins).
The length, though, took a while to catch up. The VT50 (1975) was 80
columns (its predecessor, the VT05 (1970) was 72, like an ASR-33), but
only 12 lines. It was the VT52 (1976) that was AFAIK, DEC's first
80x24 terminal.
Over in IBM land, there's the 3277 terminal, which I always thought
was 80x24, but I found a mention of a "model 1" with 40x12.
There are also a couple of external factors that most likely
influenced the path to 80x24 - CRT aspect ratio and memory geometry.
Inexpensive CRTs were (are still) 4:3 aspect ratio. The DEC VT50 was
12 lines, but AFAIK, they were double-spaced on the screen, spread
out across the horizontal axis, not crushed together (like an
unenhanced VT100 in 132-column mode). They certainly didn't go out
and make a custom CRT to neatly fit 80x12. Memory geometry comes into
play when designing an inexpensive character buffer for the display.
If there had been an arbitrary reason to support, say, 80x30, perhaps
the designers of the 1970s might have taken a different path, but with
80 columns a preferred width due to previously mentioned factors,
80x12 == 960 bytes (under 1K) and 80x24 == 1920 bytes (under 2K) and
further, 80x25 == 2000 bytes (still under 2K, but it was a while until
the "25th status line" feature crept in).
I was merely a user of terminals in the 1970s, not a designer, but
this place is as good as any to find folks who might have been there
at the time and can confirm/deny any speculations from their own
experience.
-ethan
10 Feb
10 Feb
6:58 p.m.
I did some work about this over two years ago. I took it from inside the PDF
in Bitsavers plus other sources. Some items are in good shape but others are
strange forms very dirty that only appeared in some old IBM manuals.
I had the intention to put it in my website but it remains by now in my hard
disk. It's size in storage terms is about 1,26 gb in PDF and BMPs.
What do you have in mind with this ?
Greetings
Sergio
2011/2/9 Jason T <silent700 at gmail.com>
What started out as a novelty search for an old IBM
COBOL coding sheet
has turned into a serious-ish quest: I am now looking for any original
IBM (and other) coding forms so that I might build a collection on our
documents site.
As for IBM, Google has helped me uncover the part/form # GX28-1464 for
the COBOL form, GX09-0011 for FORTRAN and GX21-9279 for Assembler.
More useful would be part # GX21-9818, which is listed as "Coding
Forms Masters" and may contain these and other forms.
If anyone has these and can a) scan them with high quality or b)
lend/send them to me for scanning, I'd much appreciate it.
Of course, if my Google-fu has failed and they're already out there,
pointers to the downloads will do, too.
--
jht
11 Feb
11 Feb
12:44 a.m.
On Thu, Feb 10, 2011 at 5:58 PM, SPC <spedraja at ono.com> wrote:
I did some work about this over two years ago. I took
it from inside the PDF
in Bitsavers plus other sources. Some items are in good shape but others are
strange forms very dirty that only appeared in some old IBM manuals.
I had the intention to put it in my website but it remains by now in my hard
disk. It's size in storage terms is about 1,26 gb in PDF and BMPs.
What do you have in mind with this ?
We run a small doc archive at our site http://chiclassiccomp.org/docs.
So far it holds only things we have scanned. I figured it would be a
fun exercise to gather these old sheets in one place.
If you'd like to contribute your scans, I can give you a place to upload them.
-j
4912
days inactive
4913
days old
35 comments
17 participants
participants (17)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
charlesleecourtney＠yahoo.com -
cisin＠xenosoft.com -
classiccmp＠philpem.me.uk -
csquared3＠tx.rr.com -
ethan.dicks＠gmail.com -
geneb＠deltasoft.com -
hadsell＠blueskystudios.com -
hilpert＠cs.ubc.ca -
IanK＠vulcan.com -
mcguire＠neurotica.com -
silent700＠gmail.com -
spectre＠floodgap.com -
spedraja＠ono.com -
wdonzelli＠gmail.com