form feed tapes on printers (was Re: Mona Lisa)
ethan.dicks at usap.gov
Wed Oct 8 23:03:21 CDT 2008
On Wed, Oct 08, 2008 at 08:28:40PM -0700, Chuck Guzis wrote:
> I seem to remember that FORTRAN on many systems used the first
> character of a PRINT/WRITE statement as "carriage control". A "1"
> caused a page eject (actually a skip on channel 1 in the carriage
> control tape.) Similarly, other numbers caused skips to other
Yep. You could get very fancy with pre-printed form letters,
but I only ever saw that done in textbook examples, not on a real
printer. By the time I was playing around with such things,
it was easier to just generate the entire letter on the
computer rather than have the computer "fill in the blanks".
I suspect in the days of the 1401 and friends, they didn't
want to try to merge pre-formatted text with calculated
values, addresses, etc., but once disk-based systems were
common, mingling text and data was trivial.
> woe betide you if you forgot to put a perforation in each
> of the 12 channels--a skip in an unperfed channel would enpty a box
> of paper really quickly.
And 'channel 0' was always "unperfed" - it wasn't documented,
but it _was_ a legal request (and you'll never see a hole in
channel 0 since there's no wire for it).
I heard tales of students who kept a "skip to channel 0" job handy
(in the days of electronic, not punchcard job submission, so early
1980s, IIRC)... when they spotted an item (stack of cards, paper,
disk pack!) sitting on top of one of the large printers, they'd
submit the job to run the paper out intentionally, and, here's
where the prank comes in, certain models of large printer would
automatically open when the paper was out, spilling whatever was
on top onto the floor.
We had to emulate skip channels in COMBOARDs, since folks were
submitting the same types of jobs they did with real printers
via our HASP/3780 link, and expecting equivalent results to
come back to their VAX. One of the (many) bugs I fixed was
that if you submitted a job with a "skip to channel 0", our
product's master control process would appear to hang. What
was really happening was that the process was writing an infinite
amount of blank lines to disk, i.e., "emptying" the box of
"paper". No customer ever waited around long enough to fill
their disk, so they'd kill the process and call us with a
bug report. The call that solved it for us was that a student
at some University kept submitting his job (since it never
ran to completion) often enough that the sysops caught him
at it and were able to examine the student's code to see
what he was doing. Everyone, but the student of course,
"knew" that you "can't" skip to channel 0 since it doesn't
exist, but with no error message to tell you you "can't"
do it, you'd never know (until perhaps after a real box of
paper was spooled into the output tray).
The bugfix was rather easy - we treated a "skip to channel 0"
as a "skip to channel 1", which was by convention, a form-feed
(though with our product as with a real printer, it was possible
to assign that to another line on the page).
I presume after a certain point in time, real printers did much
the same thing.
> A blank was the usual character for single-
> spaced output. You could also punch a tape so that a skip was
> executed over the perforation, but single-spaced output otherwise.
Not sure about that - I've never punched a real forms control
> "+" kept the paper from advancing, I believe. This is all from
> memory--I'd have to check to be sure.
That sounds familiar from the one FORTRAN class I took.
Ethan Dicks, A-333-S Current South Pole Weather at 9-Oct-2008 at 03:40 Z
South Pole Station
PSC 468 Box 400 Temp -71.5 F (-57.5 C) Windchill -97.5 F (-72.0 C)
APO AP 96598 Wind 5.4 kts Grid 49 Barometer 668.4 mb (11069 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
More information about the cctech