Re: printer history Languages influenced by PL/1

[Peter Flass]

On 7/21/2012 12:05 PM, John Levine wrote:
> [ note followup to more appropriate group ]
>
>>> > but not when many characters per line were printed.
>>>
>>> Wrong.
>>
>> Not wrong.
>
> I agree. I wasted too much of my high school spare time waiting for
> printouts to come out of Princeton's 1403-N1 printers, and the speed
> very obviously varied depending on what was printing.

You should have spent time with an 1132. After that the 1403 looked
like magic.

..

>
> The printouts from 1403s were good enough that they were used to
> typeset books, most notably David Gries' classic "Compiler Construction
> for Digital Computers".
>

Lecht's _The Programmer's PL/I_ was computer printed in 1968, and looks
typeset. I don't recall if he said what printer was used.


--
Pete

[Charles Richmond]

"Peter Flass" <Peter...@Yahoo.com> wrote in message
news:juenn8$5js$1...@dont-email.me...

> On 7/21/2012 12:05 PM, John Levine wrote:
>>

>> [snip...] [snip...]
>> [snip...]

>>
>> The printouts from 1403s were good enough that they were used to
>> typeset books, most notably David Gries' classic "Compiler Construction
>> for Digital Computers".
>>
>
> Lecht's _The Programmer's PL/I_ was computer printed in 1968, and looks
> typeset. I don't recall if he said what printer was used.
>

Just because a book was printed using 1403 output... that does *not* mean
the print was *good*! I've seen a book printed using DecWRITER (upper case
*and* lower case... such as lower case is on a DecWriter). That did *not*
make the DecWRITER lower case *good*!!! :-)

(The book was _Invitation to Forth_, by Harry Katzan. Lest some here think I
am prevaricating, I have posted some scans directly from Katzan's book on a
web page: http://aquaporin4.com/decwriter/.)

I even find the typeface in John Allen's book _Anatomy of Lisp_ to be
difficult to read. The typeface was produced somehow by computer.

--

numerist at aquaporin4 dot com

[Shmuel Metz]

In <juek0j$1is6$1...@leila.iecc.com>, on 07/21/2012

at 04:05 PM, John Levine <jo...@iecc.com> said:

>>> &gt; but not when many characters per line were printed.
>>>
>>> Wrong.
>>
>>Not wrong.

>I agree. I wasted too much of my high school spare time waiting for
>printouts to come out of Princeton's 1403-N1 printers, and the speed
>very obviously varied depending on what was printing.

The Devil is in the details. The print speed on the 1403-N1 depended
on the particular characters printed, not on the number of characters
per line.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Joe Morris]

"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote:
> John Levine <jo...@iecc.com> said:
>
>>>> &gt; but not when many characters per line were printed.

>>>> Wrong.

>>>Not wrong.

>>I agree. I wasted too much of my high school spare time waiting for
>>printouts to come out of Princeton's 1403-N1 printers, and the speed
>>very obviously varied depending on what was printing.

> The Devil is in the details. The print speed on the 1403-N1 depended
> on the particular characters printed, not on the number of characters
> per line.

Slight edit: the time required to print a given line was a function of the
character set on the print train and the set of characters present on that
line.

The extreme case for the 1403 was the model 3 (with the "Preferred Character
Set" option) or the N1 (with UCS), which could reach 1400 lines per minute
when printing lines containing only 0123456789.,-* which appeared eight
times in the PCAS-AN and PCS-HN trains. The nominal 1100 LPM speed of the N1
assumes that the train contains five identical glyph sets (for most users,
meaning the AN or HN train), and that (if UCS is installed) no line contains
any characters not present in the train. A character that's not mapped to
at least one glyph on the train will hold the printer at the current line
until the train has twice passed its home position.

Shops using PL/I would typically use either the PN or QN train. Both trains
contained the same 60 glyphs, but while the PN train had four identical
glyph sets and ran at the same speed (955 LPM) regardless of the contents of
the print file (assuming no unknown characters were used - see the above
paragraph) the QN train had five copies each of 45 characters, plus one copy
each of 15 additional glyphs. This meant that a PL/I listing would
significantly slow the printer (310 LPM), but if the output didn't use any
of the 15 singleton glyphs you would get the full rated printer speed.

H'mmm...lessee...according to the 1403 SRL the 15 singletons were

_"'$<>:;#?@^&|%

with the caret ^ above meaning the PL/I "not" symbol.

The TN (text) train had 120 characters in its glyph set, with two sets on
the train. It (obviously, I hope) slows the printer down, so it was
typically mounted only when requested by the user.

And, to add to the fun, customers could order "standard" RPQ type slugs for
a reasonably low cost (or pay a lot for a custom slug) and a create glyph
set that matched their particular requirements.

Joe

[John Levine]

>Slight edit: the time required to print a given line was a function of the
>character set on the print train and the set of characters present on that
>line.

The 1403-N1 had a Universal Character Set option to support different
print trains. The printer had a UCS buffer, into which software would
load the characters in each position on the print train.

Princeton had some 360/20's around campus, each with a 1403, MFCM
(card reader-punch-sorter thing) and a bisync modem used as RJE
terminals. One day while waiting for the /91 to come back up, I hand
punched a little program that loaded the UCS buffer with all the same
character, then printed lines of that character, and booted it.

That turned out to be a bad idea. The printer printed half a page of
gibberish at very high speed, then the cover raised halfway, then a
fuse blew. I didn't stick around to see what happened next.

R's,
John
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

[glen herrmannsfeldt]

In comp.lang.pl1 Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:

(snip on drum and train printers)

> The Devil is in the details. The print speed on the 1403-N1 depended
> on the particular characters printed, not on the number of characters
> per line.

Yes.

Still, on the average one can say something about how long a
line takes.

For a drum (one copy of each) printer, if you print one character
on a line, (or many of the same character) on the average you
wait one half drum rotation. If you print two different characters,
on the average 3/4 of a rotation, and 7/8 for three. (Assume no
correlation between characters printed and position on the drum.)

For a train printer with N copies of each, on the average the
train moves 1/(2N) of a rotation for one character, 3/(4N) for
two, and 7/(8N) for three.

So, not on the number of print positions per line, but the number
actually printed. One might expect to print more characters,
on average, on a longer line, though.

-- glen

[glen herrmannsfeldt]

In comp.lang.pl1 Joe Morris <j.c.m...@verizon.net> wrote:

(snip of AN and HN trains and print speed)

> Shops using PL/I would typically use either the PN or QN train. Both trains
> contained the same 60 glyphs, but while the PN train had four identical
> glyph sets and ran at the same speed (955 LPM) regardless of the contents of
> the print file (assuming no unknown characters were used - see the above
> paragraph) the QN train had five copies each of 45 characters, plus one copy
> each of 15 additional glyphs. This meant that a PL/I listing would
> significantly slow the printer (310 LPM), but if the output didn't use any
> of the 15 singleton glyphs you would get the full rated printer speed.

OK, I had thought I remembered the difference between PN and QN
as 6 or 8 lines per inch.

There were also trains allowing 8 lines per inch, usually on 8.5
inch long paper (either 11 or 14 inch wide) to save paper.
(That is, that looked right at 8lpi.)

> H'mmm...lessee...according to the 1403 SRL the 15 singletons were

> _"'$<>:;#?@^&|%

I believe I learned this while trying to use | and instead
switched to *.

[glen herrmannsfeldt]

In comp.lang.pl1 John Levine <jo...@iecc.com> wrote:

(snip)

> Princeton had some 360/20's around campus, each with a 1403, MFCM
> (card reader-punch-sorter thing) and a bisync modem used as RJE
> terminals. One day while waiting for the /91 to come back up, I hand
> punched a little program that loaded the UCS buffer with all the same
> character, then printed lines of that character, and booted it.

> That turned out to be a bad idea. The printer printed half a page of
> gibberish at very high speed, then the cover raised halfway, then a
> fuse blew. I didn't stick around to see what happened next.

The print position and slug character spacing aren't equal, so
you can't print all positions at the same time. (Also simplifies
the logic needed to do the compare.) Still, it seems like it
wasn't designed to be even close.

You could always find the spacing and order on the slugs and
print the appropriate line.

As well as I remember, you can fill the printer with paper
with too many consecutive form feeds. (Or a position with
no hole on the positioning tape.)

For the drum printers I knew, it would be easy to print a
whole line at once. I hope they were designed for it.

-- glen

[Walter Banks]

There were a number of printer destruction projects around in
the 70's. The trick to causing a chain printer to fail was select a
character sequence on a line that caused maximum stress on
the same point on the print chain. The rest was time until it failed.

Westinghouse was having a pricing disagreement with a TTY
supplier. A TTY was designed for well timed 10cps communication
and was a mechanical monster with a lot of parts. Like the chain
printer it was vunerable to data timing. The data bits needed to be
reasonably well timed but havoc could be had by playing with stop
bits timing. The game was to keep the timing within spec and break
the TTY. Someone wrote a hand timed P250 program that drove
TTY. It was painful to watch. The effective data rate was 7 or 8
characters per second. Mechanically moving parts got stuck, any
loose screw came out and parts became disconnected.

Westinghouse purchasing showed the vendor their "new
incoming inspection test that they would have to pass unless
they reduced the price" The vendor caved

w..

[Peter Flass]

Of course nearly every line would contain at least a ';', so the
improvement is not obvious to me.

--
Pete

[Peter Flass]

On 7/22/2012 6:45 PM, glen herrmannsfeldt wrote:
> In comp.lang.pl1 Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>
> (snip on drum and train printers)
>
>> The Devil is in the details. The print speed on the 1403-N1 depended
>> on the particular characters printed, not on the number of characters
>> per line.
>
> Yes.
>
> Still, on the average one can say something about how long a
> line takes.
>
> For a drum (one copy of each) printer, if you print one character
> on a line, (or many of the same character) on the average you
> wait one half drum rotation. If you print two different characters,
> on the average 3/4 of a rotation, and 7/8 for three. (Assume no
> correlation between characters printed and position on the drum.)

Okay, there's a problem right there. The 1132 would interrupt as each
character was coming into position. The CPU built a buffer with '1'
bits where that character was to be printed and '0' otherwise, so you'd
have to wait on average 1/2 rotation at the beginning of a line and up
to one full rotation to print the data.


--
Pete

[glen herrmannsfeldt]

In comp.lang.pl1 Peter Flass <Peter...@yahoo.com> wrote:
> On 7/22/2012 10:54 AM, Joe Morris wrote:

(snip)

>> Shops using PL/I would typically use either the PN or QN train. Both trains
>> contained the same 60 glyphs, but while the PN train had four identical
>> glyph sets and ran at the same speed (955 LPM) regardless of the contents of
>> the print file (assuming no unknown characters were used - see the above
>> paragraph) the QN train had five copies each of 45 characters, plus one copy
>> each of 15 additional glyphs. This meant that a PL/I listing would
>> significantly slow the printer (310 LPM), but if the output didn't use any
>> of the 15 singleton glyphs you would get the full rated printer speed.

(snip)

> Of course nearly every line would contain at least a ';', so the
> improvement is not obvious to me.

Shops running mostly Fortran, but some PL/I, might see the benefit.
Weight based on the fraction using PL/I or other languages using
those characters, and see which is best.

-- glen

[Joe Morris]

"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote:
> In comp.lang.pl1 Joe Morris <j.c.m...@verizon.net> wrote:

> (snip of AN and HN trains and print speed)

> OK, I had thought I remembered the difference between PN and QN
> as 6 or 8 lines per inch.
>
> There were also trains allowing 8 lines per inch, usually on 8.5
> inch long paper (either 11 or 14 inch wide) to save paper.
> (That is, that looked right at 8lpi.)

The vertical spacing was controlled by the clutch knob in the printer; I
never heard of any standard trains that were designed for a specific
vertical increment. The glyph height was (IIRC) enough less than 1/8 inch
so that you didn't wind up with glyphs on one line merging with ones the
lines above and below, although readability suffered.

Some shops made 1/8" the standard spacing for their SYSPRINT queues, but
most concluded that the reduction in the amount of paper consumed wasn't
worth the reduced readability of dense printouts at 1/8".

That's not to say that some shop might have bought a customized train with a
smaller-than-standard glyph height, but I would expect that to be
prohibitively expensive.

Joe

[Joe Morris]

"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote:

> For the drum printers I knew, it would be easy to print a
> whole line at once. I hope they were designed for it.

Most shops configured their printers to produce a flypage to mark the
beginning of each job's output, and flypage design usually included rows of
asterisks:

***********************************************
***********************************************
JOB: FUBAR USER: ALT.FOLKLORE.COMPUTERS
***********************************************
***********************************************

which, when output on a drum printer, as an unintended (and usually
unwanted) byproduct gave an aural announcement of the beginning of each
job's output.

Many IBM shops that had the ability to punch binary cards would punch a lace
card (all 960 holes) as a separator; that too provided an audio announcement
of a new job's output.

Joe

[glen herrmannsfeldt]

In comp.lang.pl1 Joe Morris <j.c.m...@verizon.net> wrote:

(snip, I wrote)

>> For the drum printers I knew, it would be easy to print a
>> whole line at once. I hope they were designed for it.

> Most shops configured their printers to produce a flypage to
> mark the beginning of each job's output, and flypage design
> usually included rows of asterisks:

> ***********************************************
> ***********************************************
> JOB: FUBAR USER: ALT.FOLKLORE.COMPUTERS
> ***********************************************
> ***********************************************

> which, when output on a drum printer, as an unintended (and
> usually unwanted) byproduct gave an aural announcement of
> the beginning of each job's output.

It wouldn't be hard to stagger them, maybe one per character
position. (That is, the path of the same character on the drum
would be a helix.) I don't remember that the DEC drum printers
I saw did that, though.

> Many IBM shops that had the ability to punch binary cards would
> punch a lace card (all 960 holes) as a separator; that too
> provided an audio announcement of a new job's output.

I was always told that the punches weren't designed to
do that. That they were pretty weak, and could rip
when going through the rest of the card path. Even worse,
don't duplicate one in a keypunch.

Now, it isn't hard to get a card with mostly X'00' which
has five or six holes. (Consider the object program of
an initialized (to zero) array.)

-- glen

[glen herrmannsfeldt]

In comp.lang.pl1 Joe Morris <j.c.m...@verizon.net> wrote:

(snip, I wrote)

>> There were also trains allowing 8 lines per inch, usually on 8.5
>> inch long paper (either 11 or 14 inch wide) to save paper.
>> (That is, that looked right at 8lpi.)

> The vertical spacing was controlled by the clutch knob in the printer; I
> never heard of any standard trains that were designed for a specific
> vertical increment. The glyph height was (IIRC) enough less than 1/8 inch
> so that you didn't wind up with glyphs on one line merging with ones the
> lines above and below, although readability suffered.

I thought I remembered the look, especially of characters like O that
were more square than the usual O. The usual ones wouldn't overlap,
but they would be close enough to be harder to read.

I thought I remembered it as PN, and the 6lpi as QN.

> Some shops made 1/8" the standard spacing for their SYSPRINT queues, but
> most concluded that the reduction in the amount of paper consumed wasn't
> worth the reduced readability of dense printouts at 1/8".

> That's not to say that some shop might have bought a customized
> train with a smaller-than-standard glyph height, but I would
> expect that to be prohibitively expensive.

Run them 24 hours a day, compute the paper cost savings, then
see if it is worthwhile.

-- glen

[John Levine]

>What's an 1132? Apparently a drum printer? What computer?

It's the drum printer that came with the IBM 1130 mini. It was a
modified 407 accounting machine, and printed at 80 lpm on a good day.

The interface was impressively horrible. As the drum rotated, it
would interrupt the CPU and send it the code of the character about to
come up to the hammers, at which point the CPU had to construct a bit
map of which hammers to fire in time for the printer controller to DMA
it to the transistors that controlled the hammers. Repeat as each
character comes past the hammers. When all of the characters on a
line had been printed, the CPU started the paper moving, waited for
the appropriate hole in the carriage control tape to appear, then
stopped the paper. It was a miracle it worked at all.

You could also attach a 1403, but that cost a lot more and few sites
did.

[Peter Flass]

On 7/22/2012 10:06 PM, Joe Morris wrote:
> "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote:
>> In comp.lang.pl1 Joe Morris <j.c.m...@verizon.net> wrote:
>
>> (snip of AN and HN trains and print speed)
>
>> OK, I had thought I remembered the difference between PN and QN
>> as 6 or 8 lines per inch.
>>
>> There were also trains allowing 8 lines per inch, usually on 8.5
>> inch long paper (either 11 or 14 inch wide) to save paper.
>> (That is, that looked right at 8lpi.)
>
> The vertical spacing was controlled by the clutch knob in the printer; I
> never heard of any standard trains that were designed for a specific
> vertical increment. The glyph height was (IIRC) enough less than 1/8 inch
> so that you didn't wind up with glyphs on one line merging with ones the
> lines above and below, although readability suffered.

You had to change the carriage control tape though, later the FCB.

--
Pete

[Charles Richmond]

"John Levine" <jo...@iecc.com> wrote in message
news:juih97$2ejt$2...@leila.iecc.com...

> >What's an 1132? Apparently a drum printer? What computer?
>
> It's the drum printer that came with the IBM 1130 mini. It was a
> modified 407 accounting machine, and printed at 80 lpm on a good day.
>
> The interface was impressively horrible. As the drum rotated, it
> would interrupt the CPU and send it the code of the character about to
> come up to the hammers, at which point the CPU had to construct a bit
> map of which hammers to fire in time for the printer controller to DMA
> it to the transistors that controlled the hammers. Repeat as each
> character comes past the hammers. When all of the characters on a
> line had been printed, the CPU started the paper moving, waited for
> the appropriate hole in the carriage control tape to appear, then
> stopped the paper. It was a miracle it worked at all.
>

This sounds like an *excellent* design... if you had a microprocessor CPU to
run the thing. But certainly you are talking about a printer that pre-dated
microprocessors by many years.

[Charles Richmond]

"Joe Morris" <j.c.m...@verizon.net> wrote in message
news:juibv...@news6.newsguy.com...

> "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote:
>
>> For the drum printers I knew, it would be easy to print a
>> whole line at once. I hope they were designed for it.
>
> Most shops configured their printers to produce a flypage to mark the
> beginning of each job's output, and flypage design usually included rows
> of asterisks:
>
> ***********************************************
> ***********************************************
> JOB: FUBAR USER: ALT.FOLKLORE.COMPUTERS
> ***********************************************
> ***********************************************
>
> which, when output on a drum printer, as an unintended (and usually
> unwanted) byproduct gave an aural announcement of the beginning of each
> job's output.
>

So do we know how the characters were apportioned on the drum printer??? Was
each line of the drum a single character... like all A's, or all *'s??? Or
did each line have the alphabet but skewed so that the rows might look
something like:

ABCDEFGHIJKLMNOPQRSTUVWXYZ
BCDEFGHIJKLMNOPQRSTUVWXYZA
CDEFGHIJKLMNOPQRSTUVWXYZAB

etc. etc. etc.

Or perhaps the letters were apportioned based on the frequency in English or
German or such...

If the rows of asterisks made a big "bang!" when they were typed, I guess
all the characters on each line of the drum were the same character. But
even if this was true, there could be more rows of E's than other
characters.

[jmfbahciv]

Or a PDP-8.


/BAH

[Anne & Lynn Wheeler]

"Joe Morris" <j.c.m...@verizon.net> writes:
> The vertical spacing was controlled by the clutch knob in the printer; I
> never heard of any standard trains that were designed for a specific
> vertical increment. The glyph height was (IIRC) enough less than 1/8 inch
> so that you didn't wind up with glyphs on one line merging with ones the
> lines above and below, although readability suffered.
>
> Some shops made 1/8" the standard spacing for their SYSPRINT queues, but
> most concluded that the reduction in the amount of paper consumed wasn't
> worth the reduced readability of dense printouts at 1/8".
>
> That's not to say that some shop might have bought a customized train with a
> smaller-than-standard glyph height, but I would expect that to be
> prohibitively expensive.

Los Gatos VLSI lab had special train for printing logic diagrams
sideways (& "dense" printing) on 1403n1 ... needed characters so that
boxes and lines appeared continuous. application could be used with
standard print train ... but lines wouldn't be solid/continuous.
Application was also sometimes used to print internal network diagram
... i.e. nodes were boxes and lines were the links that connected nodes.
I may still have such a copy printed at hone approx. 300(?) or so nodes
... I would have to find it to double check ... I may even have archived
post mentioning it) ... found archived post (references 4/15/77 print
... but not number of nodes)
http://www.garlic.com/~lynn/2002j.html#4

early on mainframe principles of operation was moved to cms script file.
actually it was the architecture "redbook" (for the red 3-ring binder it
was distributed in). There were conditional controls in the file that
printed either the full architecture redbook ... lots of engineering
notes, feature justification, discussion of alternatives, etc ... or the
principles of operation subset (version selection with command line
parameter, whether redbook or POP). when printed on 1403n1 ... some of
this can be seen in principles of operation ... where the diagram boxes
didn't have solid/continuous lines.

science center developed an application that traced instruction and
storage fetch/store addresses. "plotting" was done on 1403 with address
vertical and time horizontal ... addresses were scaled to about 7ft
length of 1403 output and time scaled could be 20-30ft. The paper
assembled on some of the interior hallways of the science center.

One of the uses was looking at how to redo apl storage management.
science center had ported apl\360 to cp67/cms for cms\apl. standard apl
storage management allocated new storage location on every assignment.
when all storage (in workspace) was exhausted, it would do garbage
collection (compacting inuse storage) and start all over again. apl\360
with 16kbyte workspace that was completely swapped as single entity
... didn't make any difference. Moved to multiple megabyte virtual
storage, demand paged environment ... resulted in severe page thrashing.
plot along the hallways was strong sawtooth pattern ... relatively rapid
rise from low storage to high followed by sharp "tooth blade" edge (as
garbage collected) ... repeated numerous times as moved down the hall.

application also did semi-automated program reorganization as aid in
improving preformance in virtual memory, demand paged environment. It
was used by lots of internal development group (like IMS) for moving
from real-storage (os/360) to virtual memory environment (as well as
identifying execution "hot-spots"). It was eventually released to
customers as VS/Repack in spring of 1976.

misc recent posts mentioning architecture redbook, vs/repack, and/or
cms\apl:
http://www.garlic.com/~lynn/2012.html#14 HONE
http://www.garlic.com/~lynn/2012.html#50 Can any one tell about what is APL language
http://www.garlic.com/~lynn/2012.html#64 Has anyone successfully migrated off mainframes?
http://www.garlic.com/~lynn/2012b.html#6 Cloud apps placed well in the economic cycle
http://www.garlic.com/~lynn/2012d.html#38 Invention of Email
http://www.garlic.com/~lynn/2012d.html#73 Execution Velocity
http://www.garlic.com/~lynn/2012e.html#59 Word Length
http://www.garlic.com/~lynn/2012j.html#20 Operating System, what is it?

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

[John Levine]

>> The interface was impressively horrible. ...

>
>This sounds like an *excellent* design... if you had a microprocessor CPU to
>run the thing. But certainly you are talking about a printer that pre-dated
>microprocessors by many years.

Well, yes, but the microprocessor was also the CPU of the computer.
It couldn't do anything else while printing, which meant that the
printer often ran slower than its modest nominal speed due to delays
to compute what to print on the next line.

The 1130 had a lot of other cost reduced stuff. The keyboard was a
keypunch keyboard that provided 12-bit card column code, and the card
reader read 12 bit binary columns. Software had to translate those to
EBCDIC. The console printer was a Selectric mechanism, programmed by
sending it the tilt and rotate location of the character, so it had
to translate to those codes, too.

The disk arm was run by a stepper motor, so you could hear the buzzing
as it ground its way from the outside of the disk toward the center
and back.

It's amazing the 1130 could get any actual computing done at all.

[hanc...@bbs.cpcn.com]

On Jul 22, 10:54 am, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> The extreme case for the 1403 was the model 3 (with the "Preferred Character
> Set" option) or the N1 (with UCS), which could reach 1400 lines per minute
> when printing lines containing only 0123456789.,-* which appeared eight
> times in the PCAS-AN and PCS-HN trains. The nominal 1100 LPM speed of the N1
> assumes that the train contains five identical glyph sets (for most users,
> meaning the AN or HN train), and that (if UCS is installed) no line contains
> any characters not present in the train.  A character that's not mapped to
> at least one glyph on the train will hold the printer at the current line
> until the train has twice passed its home position.

We had a 1403 printer with our S/360-40; and the printer had a 48
character chain. For COBOL this was an annoyance since certain
characters like parenthesis and the <> signs didn't get printed or got
a substitute.

Through some gross misinformation from IBM, the manager was told
upgrading to a 64 character chain would seriously degrade printing
speed, and also require expensive hardware add-ons and installations.
With that, the shop manager who was an old autocoder hand, who saw no
reason to upgrade.

But then the accounting department wanted to have parenthesis around
negative numbers in reports instead of a mere - sign, so as to make
negative values stand out. It turned out a new chain would not
noticeably affect printing speed, no hardware was required, and the
chain itself and installation was free. A simple change was required
to UCS controls.

The new chain did make it easier to go over complex program listings.

[hanc...@bbs.cpcn.com]

On Jul 22, 7:09 pm, Walter Banks <wal...@bytecraft.com> wrote:

[teletype failure from timing signals]

> Westinghouse purchasing showed the vendor their "new
> incoming inspection test that they would have to pass unless
> they reduced the price"  The vendor caved

Was this a Teletype brand Model 33 or 35? The 33 was a light duty
machine and probably more susceptible to failure; the 35 was robust.
Other brand machines varied greatly.

http://massis.lcs.mit.edu/telecom-archives/archives/technical/western-union-tech-review/19-1/p022.htm

[hanc...@bbs.cpcn.com]

On Jul 22, 8:56 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> Okay, there's a problem right there.  The 1132 would interrupt as each
> character was coming into position.  The CPU built a buffer with '1'
> bits where that character was to be printed and '0' otherwise, so you'd
> have to wait on average 1/2 rotation at the beginning of a line and up
> to one full rotation to print the data.

Did the 1132 use recycled parts out of surplus 407s?

I wish I had saved some 1132 printouts but they were tossed in a move
long ago, along with other stuff I wish I had now. Of course, that
was long before the Internet where this material could be shared with
others.

[hanc...@bbs.cpcn.com]

On Jul 22, 10:06 pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:
> > There were also trains allowing 8 lines per inch, usually on 8.5
> > inch long paper (either 11 or 14 inch wide) to save paper.
> > (That is, that looked right at 8lpi.)
>
> The vertical spacing was controlled by the clutch knob in the printer; I
> never heard of any standard trains that were designed for a specific
> vertical increment.  The glyph height was (IIRC) enough less than 1/8 inch
> so that you didn't wind up with glyphs on one line merging with ones the
> lines above and below, although readability suffered.
> Some shops made 1/8" the standard spacing for their SYSPRINT queues, but
> most concluded that the reduction in the amount of paper consumed wasn't
> worth the reduced readability of dense printouts at 1/8".
> That's not to say that some shop might have bought a customized train with a
> smaller-than-standard glyph height, but I would expect that to be
> prohibitively expensive.

Running the common 1403 font at 8 lines per inch produced a very
crowded appearance that was difficult to read. Many shops
experimented, once, with high density printing to save space on
archival reports but didn't bother putting it into practice.

I think they made a 'lower' font for use at 8 lines per inch; I recall
some utility bills printed that way.

Sometimes 8 lines was used at double space which produced an
attractive output. However, this wasn't popular in practice since it
required a setup change to the printer, which was often forgotten for
the next job (and would foul it); generally shops didn't like messing
with those controls.

[hanc...@bbs.cpcn.com]

On Jul 23, 12:44 pm, John Levine <jo...@iecc.com> wrote:

> The disk arm was run by a stepper motor, so you could hear the buzzing
> as it ground its way from the outside of the disk toward the center
> and back.

One time our system hung. The manager opened the disk drive door,
then slammed it close. The machine restarted.

If the 1130 had buffering, it wasn't enough. Running a simple program
with reading a card, a simple calculation, and printout, took
forever. I didn't have a stop watch, but I think the throughput speed
was only 40 lines a minute. I suspect one only got the 'rated' 80
lines per minute if one specially programmed the machine in its
assembler to expedite and optimized the printing I/O. (Undoubtedly
many users did just that if that had high volume reports.)

> It's amazing the 1130 could get any actual computing done at all.

The 1130 was a cheap successor to the 1620 and was a popular machine
for science/engineering applications, and even small businesses. In
its day, there wasn't much competition. It also had S/360
compatibility, a useful feature for units of larger organizations. It
had disk for offline storage. I believe IBM offered a series of
common programs for it, just as IBM did for S/360.

People who have used the 1130 for number crunching problems report it
was a fast machine. Yes, the I/O was terrible, but science/
engineering machines weren't designed for I/O. If you had a problem
where you loaded a bunch of numbers then did extensive calculations on
them, the machine gave good performance.

I suspect the competition later on (about five years after
introduction) from more sophisticated DEC, DataGeneral, Nova, and
other mini computer makers made the 1130 obsolete.

[Walter Banks]

I believe it was teletype model 35 mechanics. It was packaged in a
small console supplied by teletype. I remember that it had a different
teletype model number, a quick check on the internet didn't find it.
It was a console keyboard/printer only.

The PROdac 250 was a Scientific Data Systems (later Zerox Data Systems)
SDS sigma 2 repackaged by Westinghouse to be used for process control.

This happened in 1969 or early 1970.

w..

[hanc...@bbs.cpcn.com]

On Jul 22, 10:12 pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> Many IBM shops that had the ability to punch binary cards would punch a lace
> card (all 960 holes) as a separator; that too provided an audio announcement
> of a new job's output.

If your job abended, the printing of the coredump made a distinctive
different sound that alerted all to your screwup.

[John Levine]

>Did the 1132 use recycled parts out of surplus 407s?

It definitely used 407 parts. Nothing I've read says whether they
were refurbished used ones or built to be 1132s.

[glen herrmannsfeldt]

In comp.lang.pl1 John Levine <jo...@iecc.com> wrote:

>>Did the 1132 use recycled parts out of surplus 407s?

> It definitely used 407 parts. Nothing I've read says whether they
> were refurbished used ones or built to be 1132s.

IBM has been well known for building new products out of parts
of old ones. Since many products were leased, they had to find
something to do with them when they came back.

-- glen

[John Levine]

>If the 1130 had buffering, it wasn't enough.

It didn't. The card reader buffered one column, the printer had
extremely tight timing constraints to set up the bit map for each
character.

>> It's amazing the 1130 could get any actual computing done at all.
>
>The 1130 was a cheap successor to the 1620 and was a popular machine
>for science/engineering applications, and even small businesses. In
>its day, there wasn't much competition. It also had S/360

>compatibility, ...

Not really. You could attac some 360 type peripherals to it, such as
the 1442 and 2501 card readers and 1403 printer, but the internal
organization was entirely different and none of the peripherals other
than the 1132 spoke EBCDIC. There was a modest operating system that
could run stacked Fortran and assembler jobs, and a program library.

>People who have used the 1130 for number crunching problems report it
>was a fast machine.

They were mistaken, or they had extremely low expectations. A 16 bit
add with an indexed address took 12us, multiply took 32us, divide
83us, store took 11us.

>I suspect the competition later on (about five years after
>introduction) from more sophisticated DEC, DataGeneral, Nova, and
>other mini computer makers made the 1130 obsolete.

Right. IBM came out with the System 7 and Series 1, but by then it
was too late other than for true blue shops.

[Rod Speed]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote

Yeah, we bought an 029 card punch and there was one hell of
a stink when it turned out to be have been made from used parts.

[Peter Flass]

The 1130 was the microprocessor of its day. It was kept inexpensive by
having rather dumb peripherals and having the CPU do most of the work.
It was an EBCDIC machine, but each peripheral communicated using its own
code, except for the printer as previously described. For example the
console typewriter accepted Selectric "tilt and rotate" code.

Nevertheless it didn't compare unfavorably to a 360/20. I thought it
was a wonderful machine.


--
Pete

[Peter Flass]

On 7/23/2012 7:49 AM, Charles Richmond wrote:

Oh, by the way, to bring this thread back to a semblance of relevance,
there was a PL/I interpreter for it - SL/I (Student Language/I) that was
a more complete PL/I than PL/I(D). I'm still searching for a copy, by
the way...


--
Pete

[Peter Flass]

The 1132 had rows all the same. A line of all '*' mace quite a
satisfying bang! and rocked the printer.


--
Pete

[Howard S Shubs]

In article <jukk4v$2tcp$1...@leila.iecc.com>, John Levine <jo...@iecc.com>
wrote:

> Not really. You could attac some 360 type peripherals to it, such as
> the 1442 and 2501 card readers and 1403 printer, but the internal
> organization was entirely different and none of the peripherals other
> than the 1132 spoke EBCDIC. There was a modest operating system that
> could run stacked Fortran and assembler jobs, and a program library.

It was compatible with the 360 in that the same programs would run on
it, within limitations. Also, it could communicate with the 360 using
the SCA <http://www.ibm1130.net/functional/Introduction.html#SCA>. At
the time, this was pretty significant, as I understand it.
Communications between TWO computers?!? Whoa. The ARPANET wouldn't
exist for some years after this machine was introduced.

> They were mistaken, or they had extremely low expectations. A 16 bit
> add with an indexed address took 12us, multiply took 32us, divide
> 83us, store took 11us.

Consider what they were comparing it to. Older machines like the 1401
from 1959? The 1620, Can't Add, Doesn't Even Try? I don't think they
were comparing it with Xeon-based boxen, or even 8080s. I agree that it
wasn't fast compared to many 360-based boxes, or more recent systems.
Its main selling point was that it was CHEAP and physically SMALL, only
the size of a desk. You couldn't say that about IBM 360 installations.
Then again, you really couldn't say it about the IBM 1130 either, since
if you add in the peripherals, it got quite a bit larger. The 1132 was
about the size of many line printers which followed it, which isn't tiny.

> >I suspect the competition later on (about five years after
> >introduction) from more sophisticated DEC, DataGeneral, Nova, and
> >other mini computer makers made the 1130 obsolete.
>
> Right. IBM came out with the System 7 and Series 1, but by then it
> was too late other than for true blue shops.

The DEC PDP-8 was comparable in capacity and age to the IBM 1130.

--
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective

[Peter Flass]

On 7/23/2012 1:24 PM, hanc...@bbs.cpcn.com wrote:
>
> The 1130 was a cheap successor to the 1620 and was a popular machine
> for science/engineering applications, and even small businesses. In
> its day, there wasn't much competition. It also had S/360
> compatibility

Not really, except for EBCDIC. It *could* attach to an S/360 channel,
and was often equipped with a 2250-4 to offload some of the CPU cycles
from the mainframe.
...

>
> I suspect the competition later on (about five years after
> introduction) from more sophisticated DEC, DataGeneral, Nova, and
> other mini computer makers made the 1130 obsolete.
>

I think it became obsolete because IBM wanted an "all 360" solution. It
was limited to a 32K address space, but this could have been extended by
bank switching or memory map registers if anyone had wanted to bother.
The peripherals could also have been upgraded.


--
Pete

[Peter Flass]

On 7/23/2012 6:44 PM, John Levine wrote:
>> If the 1130 had buffering, it wasn't enough.
>
> It didn't. The card reader buffered one column, the printer had
> extremely tight timing constraints to set up the bit map for each
> character.
>
>>> It's amazing the 1130 could get any actual computing done at all.
>>
>> The 1130 was a cheap successor to the 1620 and was a popular machine
>> for science/engineering applications, and even small businesses. In
>> its day, there wasn't much competition. It also had S/360
>> compatibility, ...
>
> Not really. You could attac some 360 type peripherals to it, such as
> the 1442 and 2501 card readers and 1403 printer, but the internal
> organization was entirely different and none of the peripherals other
> than the 1132 spoke EBCDIC. There was a modest operating system that
> could run stacked Fortran and assembler jobs, and a program library.
>
>> People who have used the 1130 for number crunching problems report it
>> was a fast machine.
>
> They were mistaken, or they had extremely low expectations. A 16 bit
> add with an indexed address took 12us, multiply took 32us, divide
> 83us, store took 11us.

The index registers were memory locations. The 1800 (1130 upgrade) used
real registers.


--
Pete

[Joe Morris]

"John Levine" <jo...@iecc.com> wrote:

> The 1130 had a lot of other cost reduced stuff. The keyboard was a
> keypunch keyboard that provided 12-bit card column code, and the card
> reader read 12 bit binary columns. Software had to translate those to
> EBCDIC.

C'm on...where's your sense of history? The online card reader, card punch,
and printer for the IBM 7090 all used row-binary data transmission (none of
this wimpy new-fangled "column-binary" stuff".

What that meant was that (for example) to punch the character "I" in card
column 72 (did I mention that the card reader and punch could handle only 72
columns?) you had to send 24 words of data with a 1 in the low-order bit of
the second and 24th words...in other words (pun!) a 12-row and 9-row punch.

* ROW 12- 11- -0- -1- -2- -3-
OCT 0,1,0,0,0,0,0,0,0,0,0,0

* -4- -5- -6- -7- -8- -9-
OCT 0,0,0,0,0,0,0,0,0,0,0,1

And, of course, you had to shoehorn the code to translate between card codes
and BCD into the humongous memory - 32768 words of 36 bits each if the
machine was maxed out. (One side effect of this was that I have the value
of 2^15 hardwired in fast-access memory...)

Joe

[Joe Morris]

Minor edit: you *hope* that someone changed the carriage control tape, and
that ehen they didn't the jobs printed before someone corrected the mistake
were those submitted by peons (aka "undergraduates") and not the Big-Name
Professor.

Joe

[Joe Morris]

"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote:

> In comp.lang.pl1 Joe Morris <j.c.m...@verizon.net> wrote:

>> Some shops made 1/8" the standard spacing for their SYSPRINT queues, but
>> most concluded that the reduction in the amount of paper consumed wasn't
>> worth the reduced readability of dense printouts at 1/8".

>> That's not to say that some shop might have bought a customized
>> train with a smaller-than-standard glyph height, but I would
>> expect that to be prohibitively expensive.

> Run them 24 hours a day, compute the paper cost savings, then
> see if it is worthwhile.

I'll admit that my perspective was from an academic shop. I'll agree with
you that in a business shop - especially given the stability of the workload
and the power of the bean counters - the balance between legibility and cost
has a different location. Just look at the credit card statements or
similar business printouts from that era.

Joe

[glen herrmannsfeldt]

In comp.lang.pl1 Joe Morris <j.c.m...@verizon.net> wrote:

> "John Levine" <jo...@iecc.com> wrote:

>> The 1130 had a lot of other cost reduced stuff. The keyboard was a
>> keypunch keyboard that provided 12-bit card column code, and the card
>> reader read 12 bit binary columns. Software had to translate those to
>> EBCDIC.

> C'm on...where's your sense of history? The online card reader, card punch,
> and printer for the IBM 7090 all used row-binary data transmission (none of
> this wimpy new-fangled "column-binary" stuff".

> What that meant was that (for example) to punch the character "I" in card
> column 72 (did I mention that the card reader and punch could handle only 72
> columns?)

Same as the 704? As a result, Fortran got the column 72 limitation,
still in the standard for Fixed Form.

-- glen

[Shmuel Metz]

In <jujdo3$prr$1...@dont-email.me>, on 07/23/2012

at 06:49 AM, "Charles Richmond" <nume...@aquaporin4.com> said:

>This sounds like an *excellent* design... if you had a microprocessor
>CPU to run the thing. But certainly you are talking about a printer
>that pre-dated microprocessors by many years.

The design predated microprocessors by decades.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Lawrence Greenwald]

In article <howard-914DA3....@news.giganews.com>,

I got into computers because of the 1130. We had one at Brooklyn Tech
circa 1970 (probably one of the few high schools in America to have a
computer at that time!). I knew zero about computers, but once I did use
it, I was hooked and made computers my life's work.

Later I found it could be used as an RJE station to system/360. I've
seen pictures of a center in England where they used an 1130 as such
(with a 2501 card reader and 1403-N1 printer). From the looks of things
there, a totally self-service operation.

I wonder how fast it could operate the peripherals because the 1130 only
had a 512K (yes 512 thousand bytes!) single platter disk drive for
storage and buffering). A second one could be added, if I remember right.

--LG

[John Levine]

>> There was a modest operating system that
>> could run stacked Fortran and assembler jobs, and a program library.
>
>It was compatible with the 360 in that the same programs would run on
>it, within limitations.

So long as the limitation was that the programs were rewritten from
scratch to work on the entirely incompatible 1130, I suppose so.
Internally the 1130 was a 16 bit word addressed machine which was
nothing like a 360. Are you sure you don't have it confused with the
360/20?

> Also, it could communicate with the 360 using
>the SCA <http://www.ibm1130.net/functional/Introduction.html#SCA>. At
>the time, this was pretty significant, as I understand it.
>Communications between TWO computers?!? Whoa.

Yawn. Back in the early 1970s a friend at Princeton did a little
hardware hackery to attach a bisync line to a PDP-11 in his lab and do
RJE to the 360/91 a couple of blocks away. I helped him write some of
the front end user code.

>> They were mistaken, or they had extremely low expectations. A 16 bit
>> add with an indexed address took 12us, multiply took 32us, divide
>> 83us, store took 11us.
>
>Consider what they were comparing it to. Older machines like the 1401
>from 1959? The 1620, Can't Add, Doesn't Even Try? I don't think they
>were comparing it with Xeon-based boxen, or even 8080s. I agree that it
>wasn't fast compared to many 360-based boxes, or more recent systems.
>Its main selling point was that it was CHEAP and physically SMALL

If you were only aware of IBM equipment, I suppose. On a PDP-8, a 12
bit add took 3us, 24 bit add would be about 18us (CLR, TAD, TAD, DCA,
RAL, TAD, TAD)

>The DEC PDP-8 was comparable in capacity and age to the IBM 1130.

Kind of. It was only 12 bits and multiply/divide was an expensive
option. But it was under $20K, was small enough that one person could
move it, and was way more fun to program from the switches. I'd say a
PDP-7 or PDP-9 was more comparable to an 1130, but I never programmed
either of those.

[John Levine]

>> They were mistaken, or they had extremely low expectations. A 16 bit
>> add with an indexed address took 12us, multiply took 32us, divide
>> 83us, store took 11us.
>
>The index registers were memory locations. The 1800 (1130 upgrade) used
>real registers.

The 1800 was a lot faster, but also a lot more expensive. It was
aimed at a different market, realtime process control, rather than the
1130s low end data processing.

[Howard S Shubs]

In article
<lawrence.greenwald-8...@5ad64b5e.bb.sky.com>,

Lawrence Greenwald <lawrence....@sbcglobal.net> wrote:

> I wonder how fast it could operate the peripherals because the 1130 only
> had a 512K (yes 512 thousand bytes!) single platter disk drive for
> storage and buffering). A second one could be added, if I remember right.

Almost. The IBM 1130 measured memory in 16-bit words, so that disk was
roughly 1MB.

[John Levine]

>Nevertheless it didn't compare unfavorably to a 360/20. I thought it
>was a wonderful machine.

The 360/20 was WAY more fun to program from the switches. And you could
punch some interesting programs onto a single self-booting card.

[John Levine]

>> The 1130 had a lot of other cost reduced stuff. The keyboard was a
>> keypunch keyboard that provided 12-bit card column code, and the card
>> reader read 12 bit binary columns. Software had to translate those to
>> EBCDIC.
>
>C'm on...where's your sense of history?

Well, yeah. I was spoiled by the 360/20 where the code conversion was
all hidden in the microcode.

[Fritz Wuehler]

"Charles Richmond" <nume...@aquaporin4.com> wrote:

> This sounds like an *excellent* design... if you had a microprocessor CPU to
> run the thing. But certainly you are talking about a printer that pre-dated
> microprocessors by many years.

IBM didn't need microprocessors in their printers or sorters. They got they
start with time cards...mechanical wonders...

[Howard S Shubs]

In article <jul5vr$1e5o$1...@leila.iecc.com>, John Levine <jo...@iecc.com>
wrote:

> >> There was a modest operating system that
> >> could run stacked Fortran and assembler jobs, and a program library.
> >
> >It was compatible with the 360 in that the same programs would run on
> >it, within limitations.
>
> So long as the limitation was that the programs were rewritten from
> scratch to work on the entirely incompatible 1130, I suppose so.
> Internally the 1130 was a 16 bit word addressed machine which was
> nothing like a 360. Are you sure you don't have it confused with the
> 360/20?

I seem to recall some language in one of the two manuals I put on the
web that said it was compatible in some way in source, but I'm not
finding it now. You're probably right.

> > Also, it could communicate with the 360 using
> >the SCA <http://www.ibm1130.net/functional/Introduction.html#SCA>. At
> >the time, this was pretty significant, as I understand it.
> >Communications between TWO computers?!? Whoa.
>
> Yawn. Back in the early 1970s a friend at Princeton did a little
> hardware hackery to attach a bisync line to a PDP-11 in his lab and do
> RJE to the 360/91 a couple of blocks away. I helped him write some of
> the front end user code.

But the 1130 was released in the mid-1960s, not 1970s.

> >Consider what they were comparing it to. Older machines like the 1401
> >from 1959? The 1620, Can't Add, Doesn't Even Try? I don't think they
> >were comparing it with Xeon-based boxen, or even 8080s. I agree that it
> >wasn't fast compared to many 360-based boxes, or more recent systems.
> >Its main selling point was that it was CHEAP and physically SMALL
>
> If you were only aware of IBM equipment, I suppose. On a PDP-8, a 12
> bit add took 3us, 24 bit add would be about 18us (CLR, TAD, TAD, DCA,
> RAL, TAD, TAD)
>
> >The DEC PDP-8 was comparable in capacity and age to the IBM 1130.
>
> Kind of. It was only 12 bits and multiply/divide was an expensive
> option. But it was under $20K, was small enough that one person could
> move it, and was way more fun to program from the switches. I'd say a
> PDP-7 or PDP-9 was more comparable to an 1130, but I never programmed
> either of those.

Yeah, I can't claim those either.

[Walter Bushell]

In article <howard-1800A4....@news.giganews.com>,

Howard S Shubs <how...@shubs.net> wrote:

> In article
> <lawrence.greenwald-8...@5ad64b5e.bb.sky.com>,
> Lawrence Greenwald <lawrence....@sbcglobal.net> wrote:
>
> > I wonder how fast it could operate the peripherals because the 1130 only
> > had a 512K (yes 512 thousand bytes!) single platter disk drive for
> > storage and buffering). A second one could be added, if I remember right.
>
> Almost. The IBM 1130 measured memory in 16-bit words, so that disk was
> roughly 1MB.

There were giants on the Earth in those days, who did mighty deeds
with almost no resources.

Hail!

I wonder how long it would have taken that machine to do Kepler's
computation establishing the motion of the planets.

--
This space unintentionally left blank.

[Shmuel Metz]

In <jui0qf$2u7$1...@speranza.aioe.org>, on 07/22/2012
at 11:02 PM, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:

>You could always find the spacing and order on the slugs and print
>the appropriate line.

It was easy to lay out a print line that would generate synch
checks[1] on the original 1403, and I've been told that you could snap
the chain that way if you were unlucky, but I was under the impression
that IBM had re-engineered the newer models to prevent that.

[1] It fired a hammer every 11.5 microseconds in every third print
positions for three scans.

[Shmuel Metz]

In <howard-914DA3....@news.giganews.com>, on 07/23/2012

at 05:58 PM, Howard S Shubs <how...@shubs.net> said:

>Consider what they were comparing it to.

I believe that John's point was that they were only comparing it to
other slow machines. There were faster machines on the market long
before the 1130.

>The 1620, Can't Add, Doesn't Even Try?

The RCA 301 used the same trick. I wonder whether anybody ever diddled
the add tables for octal arithmetic?

[Shmuel Metz]

In <howard-914DA3....@news.giganews.com>, on 07/23/2012
at 05:58 PM, Howard S Shubs <how...@shubs.net> said:

>Communications between TWO computers?!? Whoa. The ARPANET
>wouldn't exist for some years after this machine was introduced.

Every generation thinks that it invented sex. Communication between
computers is older than the 1130.

[Rachna Shah]

watch the sensational effects that you can experience by watching porn

http://www.youtube.com/watch?v=dfheTtGtqeg&list=UUmhLtTCHD3S6Asrfi2zSJ2A&index=0&feature=plcp

subscribe for more footages...

[Walter Banks]

Good question.

The 1130 couldn't think and talk at the same time. If stopped talking (printing)
then it had enough time to think. It beat doing planet motion by hand which
made it fast.

Forty + years have not only made computers fast but the algorithms for
implementing a problem on computers have had equally dramatic performance
improvements.

w..

[Walter Banks]

"Shmuel (Seymour J.) Metz" wrote:

> In <howard-914DA3....@news.giganews.com>, on 07/23/2012
> at 05:58 PM, Howard S Shubs <how...@shubs.net> said:
>
> >Consider what they were comparing it to.
>
> I believe that John's point was that they were only comparing it to
> other slow machines. There were faster machines on the market long
> before the 1130.
>
> >The 1620, Can't Add, Doesn't Even Try?
>
> The RCA 301 used the same trick. I wonder whether anybody ever diddled
> the add tables for octal arithmetic?

Guilty.. I worked just fine. Actually almost anyone with access to the
original IBM1620 found some use for changing the math tables.

The time it took to reload the tables would kill the advantage. Besides
add of various bases the tables were sometimes used to create logic
operators. It was almost always a midnight to morning experiment that
had no real use beyond the curiosity factor.

w..

[Ahem A Rivet's Shot]

On Mon, 23 Jul 2012 19:16:31 -0700
Lawrence Greenwald <lawrence....@sbcglobal.net> wrote:


> I got into computers because of the 1130. We had one at Brooklyn Tech
> circa 1970 (probably one of the few high schools in America to have a
> computer at that time!). I knew zero about computers, but once I did use
> it, I was hooked and made computers my life's work.

That makes (at least) two of us, although the 1130 was at the local
technical college, at school we only had an ASR33 and an acoustic coupler.

> Later I found it could be used as an RJE station to system/360. I've
> seen pictures of a center in England where they used an 1130 as such
> (with a 2501 card reader and 1403-N1 printer). From the looks of things
> there, a totally self-service operation.

Ours had a 1442 and a 1403 (not N1), for an hour a day anyone could
walk in and drop a job onto the card reader. Trusted people could even book
the machine to themselves for an hour at a time. I lost my privilege by
playing moon lander for most of an hour one time.

> I wonder how fast it could operate the peripherals because the 1130 only
> had a 512K (yes 512 thousand bytes!) single platter disk drive for
> storage and buffering). A second one could be added, if I remember right.

I rather thought ours was a 1.5MB single platter drive, it also had
a cabinet with two more drives in it, a pretty much essential peripheral
for copying discs.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[hanc...@bbs.cpcn.com]

On Jul 23, 6:44 pm, John Levine <jo...@iecc.com> wrote:

> >It also had S/360
> >compatibility, ...
>

> Not really.  You could attac some 360 type peripherals to it, such as
> the 1442 and 2501 card readers and 1403 printer, but the internal
> organization was entirely different and none of the peripherals other

> than the 1132 spoke EBCDIC.  There was a modest operating system that

> could run stacked Fortran and assembler jobs, and a program library.

It could be used as a terminal to connect to S/360.

> >People who have used the 1130 for number crunching problems report it
> >was a fast machine.
>

> They were mistaken, or they had extremely low expectations.  A 16 bit
> add with an indexed address took 12us, multiply took 32us, divide
> 83us, store took 11us.

What were arithmetic processing speeds of other low-end computers of
that time-frame?

> >I suspect the competition later on (about five years after
> >introduction) from more sophisticated DEC, DataGeneral, Nova, and
> >other mini computer makers made the 1130 obsolete.
>
> Right.  IBM came out with the System 7 and Series 1, but by then it
> was too late other than for true blue shops.

I believe the S/7 was more of a process control computer, to replace
the 1130's cousin, the 1800. Interestingly, one of the few times the
Bell System went 'outside' to get hardware, was to use S/7's to
supplement AMA toll recording equipment. Bell later went to PDP
machines and was a big purchaser of DEC gear.

[hanc...@bbs.cpcn.com]

On Jul 23, 6:33 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In comp.lang.pl1 John Levine <jo...@iecc.com> wrote:
>
> >>Did the 1132 use recycled parts out of surplus 407s?
> > It definitely used 407 parts.  Nothing I've read says whether they
> > were refurbished used ones or built to be 1132s.
>
> IBM has been well known for building new products out of parts
> of old ones. Since many products were leased, they had to find
> something to do with them when they came back.

What other IBM _new_ products used parts of old ones?

They re-used the 2314 disk drive in S/370, but I don't think they gave
it a new model number.

Because new equipment generally was faster and smaller-sized than the
stuff it replaced, I'm not sure how old parts could be utilized to any
great extent. The 1132 printer is a notable exception since it was a
very slow printer. (The 407 ran faster at 150 lines per minute).

I've been told that they resold turned-in 1401 to schools and
hospitals at a good price after S/360 came out, but it was still sold
as a 1401, not incorporated into anything else.

IBM utilized its 1950s "SMS" circuit card technology in peripheral
units for S/360, but I don't think they physically re-used old circuit
cards.

[hanc...@bbs.cpcn.com]

On Jul 23, 8:54 pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> "Peter Flass" <Peter_Fl...@Yahoo.com> wrote:
> > On 7/22/2012 10:06 PM, Joe Morris wrote:
> >> The vertical spacing was controlled by the clutch knob in the printer; I
> >> never heard of any standard trains that were designed for a specific
> >> vertical increment.  The glyph height was (IIRC) enough less than 1/8
> >> inch

[8 lines per inch]

> >> so that you didn't wind up with glyphs on one line merging with ones the
> >> lines above and below, although readability suffered.
> > You had to change the carriage control tape though, later the FCB.
>
> Minor edit: you *hope* that someone changed the carriage control tape, and
> that ehen they didn't the jobs printed before someone corrected the mistake
> were those submitted by peons (aka "undergraduates") and not the Big-Name
> Professor.

Often they forgot to change the tape, and the subsequent run was
botched. A key reason 8 lines per inch was discouraged except in very
special cases.

[hanc...@bbs.cpcn.com]

On Jul 23, 8:02 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> > I suspect the competition later on (about five years after
> > introduction) from more sophisticated DEC, DataGeneral, Nova, and
> > other mini computer makers made the 1130 obsolete.
>

> I think it became obsolete because IBM wanted an "all 360" solution.  It
> was limited to a 32K address space, but this could have been extended by
> bank switching or memory map registers if anyone had wanted to bother.
> The peripherals could also have been upgraded.


IBM might have 'wanted' an all S/360 solution, but even a very low end
S/360 was not cost competitive with tab machines in small
installations. I don't know the costs, but I suspect a low end S/360-
model 30 would've cost more to both buy and operate than a good 1130.

Anyway, IBM ended up developing System/3 for small business needs. It
used modern technology and new ways of thinking to hold down costs.
The tiny punched card meant the card reader and punch could be
physically smaller which saved money. The S/3 begat its own line of
mini-computers (S/34, 36, 38, AS/400, i series) which remains
successful to this day.

While the IBM history touches on System/3, a separate history should
be written of life of the development of low-end business machines,
software, and the world of low-end business users. Much has been
written about the high end world (we just got the reference "The
Computer Boys"), but the low end world had a very different culture.

[glen herrmannsfeldt]

In comp.lang.pl1 hanc...@bbs.cpcn.com wrote:

(snip, I wrote)

>> IBM has been well known for building new products out of parts
>> of old ones. Since many products were leased, they had to find
>> something to do with them when they came back.

> What other IBM _new_ products used parts of old ones?

> They re-used the 2314 disk drive in S/370, but I don't think
> they gave it a new model number.

The 2319 IFA (integrated file adaptor). As I understand it,
they reuse 2314 parts, but without the traditional controller.
It seems to use special microcode on some S/370 models to replace
the logic that normally would be in a separate controller box.

> Because new equipment generally was faster and smaller-sized than the
> stuff it replaced, I'm not sure how old parts could be utilized to any
> great extent. The 1132 printer is a notable exception since it was a
> very slow printer. (The 407 ran faster at 150 lines per minute).

Also, as I understand, 370/158s were reused inside the 3032
and 3033 for I/O. As a 370/158, it had microcode for both CPU
and channel operations. Running the channels for the 303x, it
only needed (probably new) channel microcode, to offload that
function from the CPU.

-- glen

[hanc...@bbs.cpcn.com]

On Jul 23, 8:58 pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> > Run them 24 hours a day, compute the paper cost savings, then
> > see if it is worthwhile.
>
> I'll admit that my perspective was from an academic shop.  I'll agree with
> you that in a business shop - especially given the stability of the workload
> and the power of the bean counters - the balance between legibility and cost
> has a different location.  Just look at the credit card statements or
> similar business printouts from that era.

Since the 'bean counters' were the readers of computer generated
reports, they tended to not encourage hard-to-read formats.

Back then, computers and labor to run them were so expensive that
paper costs just got buried in the overall costs. Computer centers
and programmers used to waste tremendous amounts of paper. Efforts to
conserve (eg reuse of reports for printing on the back side* and
crowded 8 lines per inch) were limited to avoid confusion.

Of course, invoices and notices back then tended to be smaller than
what is printed today. Our phone bill in that era was a single slip
of paper, service & equipment on the left side, toll calls on the
right side. Our electric bill was a postcard, name/address on the
right, KWHrs and amount due on the left.

For whatever reason, electric and telephone bills are much more
complex. (Mine runs many pages even _without_ call itemization.)

Later on xeroxography printing came out (we had high speed mediocre
quality Xerox printers in 1979), which saved some paper costs.

When personal computers hit the office, paper consumption went way up
for a number of years.


* If there was a messsage to go out with the payroll checks, we reran
the checks printing the message on the backside of the pay stub. We
did tend to completely wear out a printer ribbon and used generic ones
to save money, except when printing checks.
Also, many business reports were on special forms, and the cost was
more in one-time set up (typesetting and design) than in subsequent
copies.

[hanc...@bbs.cpcn.com]

On Jul 23, 11:49 pm, John Levine <jo...@iecc.com> wrote:

> >> There was a modest operating system that
> >> could run stacked Fortran and assembler jobs, and a program library.
>
> >It was compatible with the 360 in that the same programs would run on
> >it, within limitations.
>
> So long as the limitation was that the programs were rewritten from
> scratch to work on the entirely incompatible 1130, I suppose so.
> Internally the 1130 was a 16 bit word addressed machine which was
> nothing like a 360.  Are you sure you don't have it confused with the
> 360/20?

The 1130 Fortran had a few limitations, such as not allowing logical
IF statements. But otherwise a modest sized Fortran program could be
recompiled and run on the 1130 without change, and the reverse.

> >Consider what they were comparing it to.  Older machines like the 1401
> >from 1959?  The 1620, Can't Add, Doesn't Even Try?  I don't think they
> >were comparing it with Xeon-based boxen, or even 8080s.  I agree that it
> >wasn't fast compared to many 360-based boxes, or more recent systems.
> >Its main selling point was that it was CHEAP and physically SMALL

> If you were only aware of IBM equipment, I suppose.  On a PDP-8, a 12
> bit add took 3us, 24 bit add would be about 18us (CLR, TAD, TAD, DCA,
> RAL, TAD, TAD)

Did the PDP-8 support a wide line printer, disk storage and punched
card input?

> >The DEC PDP-8 was comparable in capacity and age to the IBM 1130.
>
> Kind of.  It was only 12 bits and multiply/divide was an expensive
> option.  But it was under $20K, was small enough that one person could
> move it, and was way more fun to program from the switches.  I'd say a
> PDP-7 or PDP-9 was more comparable to an 1130, but I never programmed
> either of those.

If someone outgrew their PDP, were the next upward models compatible,
that is, could programs and compiled for say the PDP-7 run without
change on the PDP-8 or PDP-9, etc.?

[Anne & Lynn Wheeler]

glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> Also, as I understand, 370/158s were reused inside the 3032
> and 3033 for I/O. As a 370/158, it had microcode for both CPU
> and channel operations. Running the channels for the 303x, it
> only needed (probably new) channel microcode, to offload that
> function from the CPU.

370/158 had "integrated channels" ... 158 engine was shared running
"integrated channel" microcode and 370 microcode.

303x was a quick&dirty effort to get something out quick ... after
future system effort had failed ... during the FS period lots of 370
efforts were suspended and/or killed off (and is credited with allowing
clone processors to get market foothold). some past posts mentioning
FS
http://www.garlic.com/~lynn/submain.html#futuresys

303x channel director was 370/158 engine with only the integrated
channel microcode (and no 370 microcode)

3031 was two 370/158 engines, one dedicated to "channel director"
running just the integrated channel microcode and another engine running
just the 370 microcode (a 3031 multiprocessor being four 370/158
engines, two channel directors and two 370 processor).

3032 was 370/168 reconfigured to use channel director as its
external channels

3033 started out being 370/168 logic remapped to 20% faster chips that
also had 10times circuits/chip ... extra circuits originally gone
unused. during development there was some remapping of logic to
consolidate more onchip operations ... eventually getting 3033 up to
nearly 50% faster than 168. 3033 also used the channel director for its
i/o.

370/158 integrated channel microcode supported 6 channels. for 3032 and
3033 configurations with more than 6 channels required multiple "channel
directors"

some other details of future system, 3033, and 3081 (also quick&dirty
effort, reusing some FS technology)
http://www.jfsowa.com/computer/memo125.htm

this post has old 4341, 3031, & 158 benchmark shows 3031 increased
processing compared to 158 (since the engine was now dedicated to 370
processing)
http://www.garlic.com/~lynn/2000d.html#0

as an aside ... 4341 also had integrated channel ... but the 4341
processor engine was so much faster ... that with slight tweaks the 4341
supports 3380 3mbyte channel speeds ... something that the 370/158
engine was incapable of.

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

[Rod Speed]

<hanc...@bbs.cpcn.com> wrote in message
news:96711db9-9ea1-4534...@e7g2000yqh.googlegroups.com...

The 7 and 9 were just different technology with the same instruction set.

The 8 was very different to the 7 on stuff like word size.

The way text was packed into the 12 and 18 bit words respectively was quite
different.

[John Levine]

>The 1130 Fortran had a few limitations, such as not allowing logical
>IF statements. But otherwise a modest sized Fortran program could be
>recompiled and run on the 1130 without change, and the reverse.

Yes, I know, the first program I ever wrote was a quadratic equation
solver on an 1130.

But you could say that about any computer. You could recompile your
360 Fortran programs on a PDP-6 with minimal changes (its compiler had
a lot in common with Fortran G) but nobody would say a PDP-6 was in
any way compatible with a 360.

>> If you were only aware of IBM equipment, I suppose. �On a PDP-8, a 12
>> bit add took 3us, 24 bit add would be about 18us (CLR, TAD, TAD, DCA,
>> RAL, TAD, TAD)
>
>Did the PDP-8 support a wide line printer, disk storage and punched
>card input?

If you had enough money, sure, but most people didn't. DEC had enough
sense not to compete head-on with IBM, and their main markets were
scientific, process control and education. They made a half hearted
attempt at the commercial market with an RPG-ish language called Dibol
which wasn't very popular/

>If someone outgrew their PDP, were the next upward models compatible,
>that is, could programs and compiled for say the PDP-7 run without
>change on the PDP-8 or PDP-9, etc.?

There were multiple product lines. The 18 bit PDP-4, -7, -9, and -15
were largely instruction set compatible, as were the 12 bit PDP-5 and -8
and the 36 bit PDP-6, -10, and DEC 20.

R's,
John

[John Levine]

>The codes used in the 1950s probably derived from unit record
>equipment from the late 1800s.

Not that far back. Hole arrangements in the 1800s were quite ad-hoc
and the familiar 80 column card with rectangular holes wasn't
developed until 1928.

[hanc...@bbs.cpcn.com]

On Jul 24, 2:23 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:

> 3031 was two 370/158 engines, one dedicated to "channel director"
> running just the integrated channel microcode and another engine running
> just the 370 microcode (a 3031 multiprocessor being four 370/158
> engines, two channel directors and two 370 processor).

Did the 3031 actually use recycled circuits out of old 158's, or was
it new gear merely manufactured per 158 design and incorporated in a
bigger box?

From the description on the IBM website, it seems that the 3031 was
new technology given the improved storage and execution techinques.
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3031.html

> 3033 started out being 370/168 logic remapped to 20% faster chips that
> also had 10times circuits/chip ... extra circuits originally gone
> unused. during development there was some remapping of logic to
> consolidate more onchip operations ... eventually getting 3033 up to
> nearly 50% faster than 168. 3033 also used the channel director for its
> i/o.

It sounds like 3033 was all new hardware, even if some of it use an
older design.

[hanc...@bbs.cpcn.com]

On Jul 24, 12:46 am, Fritz Wuehler
<fr...@spamexpire-201207.rodent.frell.theremailer.net> wrote:

AFAIK, "time cards" merely recorded a time stamp (the current time of
day) on a piece of card stock, there was no further processing. While
IBM clocks became sophisticated, such as serving schools and
factories, they weren't really data processing machines. IBM sold off
its clock division in the late 1950s, but its website has details on
it.
http://www-03.ibm.com/ibm/history/exhibits/cc/cc_intro.html

The data processing machines were the tabulating system developed by
Herman Hollerith for the 1890 census. This evolved into a
sophisticated information processing system by the late 1930s, well
used for New Deal record keeping requirements, like social security.
The product line was revamped in 1948, and was IBM's flagship until
1962.

[glen herrmannsfeldt]

In comp.lang.pl1 hanc...@bbs.cpcn.com wrote:

(snip on printers)

> Back then, computers and labor to run them were so expensive that
> paper costs just got buried in the overall costs. Computer centers
> and programmers used to waste tremendous amounts of paper. Efforts to
> conserve (eg reuse of reports for printing on the back side* and
> crowded 8 lines per inch) were limited to avoid confusion.

I do remember 1403 printouts being reused as paper for 2714s.

For debugging, it was usual to print out the whole source
listing with each compilation, along with the storage map
and such.

With WYLBUR, it was usual to fetch the output, and look it
over before printing, or purge it if not needed.

> Of course, invoices and notices back then tended to be smaller than
> what is printed today. Our phone bill in that era was a single slip
> of paper, service & equipment on the left side, toll calls on the
> right side. Our electric bill was a postcard, name/address on the
> right, KWHrs and amount due on the left.

Many were on IBM punched cards!

> For whatever reason, electric and telephone bills are much more
> complex. (Mine runs many pages even _without_ call itemization.)

Most likely, change in regulations.

> Later on xeroxography printing came out (we had high speed mediocre
> quality Xerox printers in 1979), which saved some paper costs.

> When personal computers hit the office, paper consumption went way up
> for a number of years.

I remember 5000 line (default) print limits, and at least some
that printed more than they were supposed to, until the limit
was reached.

-- glen

[Anne & Lynn Wheeler]

hanc...@bbs.cpcn.com writes:
> Did the 3031 actually use recycled circuits out of old 158's, or was
> it new gear merely manufactured per 158 design and incorporated in a
> bigger box?
>
> From the description on the IBM website, it seems that the 3031 was
> new technology given the improved storage and execution techinques.
> http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3031.html

re:
http://www.garlic.com/~lynn/2012j.html#91 printer history Languages influenced by PL/1

the 370/158 engine manufacturing line had achieved an astonishing level
of efficiency ... incremental cost of every additional 370/158 of the
line was unbelievably small (imagine some of the old numbers for
incremental cost of building additional automobile).

note 370/168-1 to 370/168-3 was similar doubling of cache size also
... but resulted in significant problems. the bit chosen for indexing
additional cache lines was the 2k bit ... and therefor when 370/168-3
was running in 2k-byte page mode (dos/vs, vs1) ... it only used half the
cache (because the 2k bit was now part of the virtual address ... all
the othere cache index bits were low-order bits which were the same in
both virtual and real address). As a result for dos/vs & vs1, 168-3 had
the same performance as 168-1. The problem was even worse for vm370
running either dos/vs &/or vs1 in virtual machine. vm370 normally used
4k-byte page mode logic ... which used the full 32kbyte cache. However,
when switching to dos/vs or vs1 virtual machine running with 2k-byte
pages ... it used 2k-byte "shadow" tables. In the switch between 4k-byte
and 2k-byte virtual page mode ... there would be full cache flush
because of the different mapping ... with dos/vs & vs1 running under
vm370 ... this would be happening at very high frequency ... some number
of vm370 customers (running dos/vs &/or vs1) complained upgrading from
168-1 to 168-3 ... performance degrading to worse than 168-1.

something similar would happen for doubling cache for 158-3 to 3031.

the remapping of 168-3 logic to newer/faster chips started out 20%
faster than 168-3 for 3033 .... but eventually some logic tuning got it
up to 50% faster ... 168-3 was approx. 3mip machine and 3033 was
approx. 4.5mip machine (depending on typical application cache hit
ratios).

as sowa's references 3081 was kludged FS machine using the FS machine
370 emulator (enormous increase in number of circuits compared to all
other 370 machine implementations regardless of the vendor).
http://www.jfsowa.com/computer/memo125.htm

First 3081 out the door was 3081-D with supposedly two five-mip
processors ... but lots of benchmarks had 3081-d processors running
slower than 3033. Then similar to 168-1 to 168-3, amount of cache was
doubled for 3081-K which supposedly resulting in two 7mip processors
(i.e. larger cache, results in lower cache miss / higher cache hit
ratios ... increasing the effective instruction execution rate ... aka
fewer instruction stall from cache miss waiting for storage). However,
some number of benchmarks had 3081-K processor about the same or ownly
slightly faster than 3033 processor.

[Jorgen Grahn]

On Sun, 2012-07-22, Charles Richmond wrote:
...
> Just because a book was printed using 1403 output... that does *not* mean
> the print was *good*! I've seen a book printed using DecWRITER (upper case
> *and* lower case... such as lower case is on a DecWriter). That did *not*
> make the DecWRITER lower case *good*!!! :-)
>
> (The book was _Invitation to Forth_, by Harry Katzan. Lest some here think I
> am prevaricating, I have posted some scans directly from Katzan's book on a
> web page: http://aquaporin4.com/decwriter/.)

Ugh. Good proof of the rule: if you don't have hyphenation, don't
attempt to create a straight right margin!

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Dan Espen]

Jorgen Grahn <grahn...@snipabacken.se> writes:

> On Sun, 2012-07-22, Charles Richmond wrote:
> ...
>> Just because a book was printed using 1403 output... that does *not*
>> mean the print was *good*! I've seen a book printed using DecWRITER
>> (upper case *and* lower case... such as lower case is on a
>> DecWriter). That did *not* make the DecWRITER lower case *good*!!!
>> :-)
>>
>> (The book was _Invitation to Forth_, by Harry Katzan. Lest some here
>> think I am prevaricating, I have posted some scans directly from
>> Katzan's book on a web page: http://aquaporin4.com/decwriter/.)
>
> Ugh. Good proof of the rule: if you don't have hyphenation, don't
> attempt to create a straight right margin!

Yeah, looks like crap!

--
Dan Espen

[Peter Flass]

On 7/23/2012 7:58 PM, Howard S Shubs wrote:
> In article <jukk4v$2tcp$1...@leila.iecc.com>, John Levine <jo...@iecc.com>

> wrote:
>
>> Not really. You could attac some 360 type peripherals to it, such as
>> the 1442 and 2501 card readers and 1403 printer, but the internal
>> organization was entirely different and none of the peripherals other

>> than the 1132 spoke EBCDIC. There was a modest operating system that

>> could run stacked Fortran and assembler jobs, and a program library.
>
> It was compatible with the 360 in that the same programs would run on
> it, within limitations.

Impossible. It had a totally incompatible architecture, an accumulator,
and three index registers instead of GPRs. It was (16-bit)
word-addressed instead of byte addressed. Probably APL programs could
run unchanged, and the FORTRAN was somewhat similar, but that's it.

--
Pete

[Peter Flass]

On 7/24/2012 6:50 AM, Shmuel (Seymour J.) Metz wrote:
> In <howard-914DA3....@news.giganews.com>, on 07/23/2012
> at 05:58 PM, Howard S Shubs <how...@shubs.net> said:
>
>> Consider what they were comparing it to.
>
> I believe that John's point was that they were only comparing it to
> other slow machines. There were faster machines on the market long
> before the 1130.

How did the prices compare. I seem to recall that the 1130 leased for
$1000/mo when it was introduced. If this is right, at $12,000 a year it
was a very affordable machine.


--
Pete

[Peter Flass]

On 7/24/2012 3:20 PM, John Levine wrote:
>> The 1130 Fortran had a few limitations, such as not allowing logical
>> IF statements. But otherwise a modest sized Fortran program could be
>> recompiled and run on the 1130 without change, and the reverse.
>
> Yes, I know, the first program I ever wrote was a quadratic equation
> solver on an 1130.
>
> But you could say that about any computer. You could recompile your
> 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
> a lot in common with Fortran G) but nobody would say a PDP-6 was in
> any way compatible with a 360.

Before C, FORTRAN was the universal language. If you wanted to write a
portable program, you used FORTRAN.


--
Pete

[Joe Morris]

"glen herrmannsfeldt" wrote:

> I do remember 1403 printouts being reused as paper for 2714s.

I'm assuming a typo there...the popular terminal was the 2741, which was
essentially a remote Selectric. I've still got some typeballs I grabbed as
the last one went out the door...some still in a sealed box, others with the
infamous "chipped tooth" disease.

Joe

[hanc...@bbs.cpcn.com]

On Jul 24, 4:46 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:

> the 370/158 engine manufacturing line had achieved an astonishing level
> of efficiency ... incremental cost of every additional 370/158 of the
> line was unbelievably small (imagine some of the old numbers for
> incremental cost of building additional automobile).

So, if I understand this correctly, they just merely kept building
more CPU units since it was cheap to do so, rather than re-using old
ones.

The workings of the cache and virtual addressing was amazingly
complex. How they could write an operating system and micro code to
track all the stuff is beyond me. I once got a book explaining the
internals of modern Z series and the complexity is beyond belief.
Kind of downer when you're running an old simple program against a
small file.

[hanc...@bbs.cpcn.com]

On Jul 24, 7:18 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> How did the prices compare.  I seem to recall that the 1130 leased for
> $1000/mo when it was introduced.  If this is right, at $12,000 a year it
> was a very affordable machine.

It's weird that one could probably get--for a small fraction of
$1,000--an old second-hand PC, a copy of QuickBasic, and a cheap
printer, and yet have more processing power and easier use than the
1130. Heck, you might even get someone's cast off machine for free.

(I remember the first time I saw a PC in the trash--it was an OMG
moment. I took it home--it was a 386 that more or less worked. Now I
see scrap PCs and peripherals all the time and just ignore them.)

[hanc...@bbs.cpcn.com]

On Jul 24, 7:24 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> Before C, FORTRAN was the universal language.  If you wanted to write a
> portable program, you used FORTRAN.

Fortran was common for science and engineering applications; but COBOL
was the standard for business applications.

In the early days machine horsepower was limited, and even with
efficient compilers many users preferred to write in native assembler
language for a given machine. Skilled assembler programmers could
take advantage of machine timing to maximize efficiency by overlap and
other tricks. I think a good programmer on the IBM 1130 could
maximize I/O throughput by careful timing controls over I/O commands
so that each command was issued at the most opportune moment. This
also could be done on the 1401.


What language(s) were most commonly used to program PDP machines,
especially in the early days?

[hanc...@bbs.cpcn.com]

On Jul 24, 8:40 pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> I'm assuming a typo there...the popular terminal was the 2741, which was
> essentially a remote Selectric.  I've still got some typeballs I grabbed as
> the last one went out the door...some still in a sealed box, others with the
> infamous "chipped tooth" disease.

A business had a corporate 'yard sale' to get rid of old office
furniture and appliances. I picked up a dual pitch Correcting
Selectric II typewriter for $1.00 It worked ok, a bit sluggish. I
think it was $1,000 new.

I was thrilled to get it, but admittedly it soon fell into disuse--it
was just easier to use a word processor. I haven't used it in a long
time.

[John Levine]

>What language(s) were most commonly used to program PDP machines,
>especially in the early days?

Depends on what machine and where. There was a lot of assembler on the lower
end machines, and now forgotten languages like FOCAL which was sort of a stripped
down JOSS.

At Yale in 1970 on our PDP-10 there was a mix of assembler, Fortran,
Algol, BLISS (DEC's system programming language) and some locally
written stuff.

[John Levine]

>> I believe that John's point was that they were only comparing it to
>> other slow machines. There were faster machines on the market long
>> before the 1130.
>
>How did the prices compare. I seem to recall that the 1130 leased for
>$1000/mo when it was introduced. If this is right, at $12,000 a year it
>was a very affordable machine.

It's hard to compare, since other vendors tended to sell their
computers rather than leasing them, but the purchase price for a PDP-7
was similar to that for an 1130. The PDP-8 was famous for being the
first computer you could buy for under $20,000.

[Rod Speed]

<hanc...@bbs.cpcn.com> wrote

Mostly assembler. Some use of Focal, similar to Basic. Basic later.

Lots of Fortran later.

[Robin Vowels]

On Sunday, 22 July 2012 02:05:39 UTC+10, John Levine wrote:

> >> &amp;gt; but not when many characters per line were printed.

> >> Wrong.

> >Not wrong.

> I agree. I wasted too much of my high school spare time waiting for
> printouts to come out of Princeton's 1403-N1 printers, and the speed
> very obviously varied depending on what was printing.

> >Finally, the characters printed by a drum printer are precise
> >and crystal-clear, unlike the print from the 360's train printer,
> >which tended to be blurred and indistinct.

> Not the DEC drum printers I used. Maybe they were poorly maintained,
> but the print quality was awful, both blurry and terrible vertical
> registration. Based on in-house DEC printouts I've seen, everyone had
> the vertical registration problem.

> The printouts from 1403s were good enough that they were used to
> typeset books, most notably David Gries' classic Compiler Construction
> for Digital Computers".

Quite. I have a copy of that book.
IBM's programming manuals for the S/360 were printed on /360
printers fitted with a special print train (I hold copies
of some of these manuals). It looks like "Internal Sorting
Techniques" by R. P. Rich (which I also have), was printed by
the same kind of printer.

While the print quality of these documents is reasonable,
even good, the mis-printing of characters is evident.
By being reduced to about 50% of normal size for publication,
the defects in formation of characters is reduced.
Nevertheless the quality is significantly less that what the
Analine/Analex printer produced (print-outs in my possession).

Opening page at randon (p. 110-111) I see:
p. 110:
the letter 'e' is broken in many places -- the right-hand side is
missing;
the letter 'b' similarly broken;
the letter 'T' is broken;
the letter 'L' in the word 'LAST' is broken, and looks almost
identical to an 'I'.

p. 111:
In various places, the right-hand side of the letters 'e' and 'o'
is missing.
The letter 'B' in one place looks like an 'E'.
The right-hand side of 'T' is missing in two places.
Various other letters are affected.

These defects and similar ones appear thoughout the book.

I notice that on page 355, on line 3, that an E looks like an F,
and that it's impossible to tell whether a particular letter is
an 'O' or a 'C'.

[Robin Vowels]

That's debateable, as there were many flavours of FORTRAN.
Some might argue that COBOL was.

[Rod Speed]

Robin Vowels <robin....@gmail.com> wrote
> Peter Flass <Peter_Fl...@Yahoo.com> wrote

>> John Levine wrote

>>>> The 1130 Fortran had a few limitations, such as not allowing logical
>>>> IF statements. But otherwise a modest sized Fortran program could
>>>> be recompiled and run on the 1130 without change, and the reverse.

>>> Yes, I know, the first program I ever wrote was a quadratic equation
>>> solver on an 1130.

>>> But you could say that about any computer. You could recompile your
>>> 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
>>> a lot in common with Fortran G) but nobody would say a PDP-6 was in
>>> any way compatible with a 360.

>> Before C, FORTRAN was the universal language. If you wanted to write a
>> portable program, you used FORTRAN.

> That's debateable, as there were many flavours of FORTRAN.

Not that many at a particular time, and if you wanted a portable
program, you could always just use the portable subset that was
common to all the common ones.

> Some might argue that COBOL was.

Sure, particularly for business stuff. But it was
never that commonly used on DEC hardware.

[Walter Bushell]

In article <juna1v$ftk$1...@dont-email.me>,

Compiled or interpreted languages could be portable, within capacity
limits, I suppose. One could write a Forth system that could run on
both for example.

Is there a generally available Forth for the 360 et. al. systems?

--
This space unintentionally left blank.

[Walter Bushell]

In article <junar1$ftk$3...@dont-email.me>,

Or COBOL, if you need more capabilities. :)

[Walter Bushell]

In article
<7084d8a0-c34a-4e45...@v7g2000yqn.googlegroups.com>,

There were Selectrics with computer ports, IIRC RS 232 or compatible.
We used them at a major NYC bank for writing form letters to
presidents of foreign banks (driven by Trash 80s). It would have been
unthinkable to use dot matrix print of the day for such correspondence.

And of course, writing technical documentation as sending it to the
typing puddle just produced gibberish.

[glen herrmannsfeldt]

In comp.lang.pl1 Anne & Lynn Wheeler <ly...@garlic.com> wrote:

(snip)

> note 370/168-1 to 370/168-3 was similar doubling of cache size also
> ... but resulted in significant problems. the bit chosen for indexing
> additional cache lines was the 2k bit ... and therefor when 370/168-3
> was running in 2k-byte page mode (dos/vs, vs1) ... it only used half the
> cache (because the 2k bit was now part of the virtual address ... all
> the othere cache index bits were low-order bits which were the same in
> both virtual and real address).

I have had VM/370 running on the P/370, with the 4K key
feature (sic). That likely fails if it ever tries to run
with 2K byte pages. (To do that, you have to set bit 7 in all
the values to be loaded into CR0.)

-- glen

[Nomen Nescio]

Lost track of the thread, but...

COBOL very shortly became non-portable because of IBM's access methods (I/O)
support and the other extensions. None of IBM's languages have ever been
very portable. It is always easier to port to them than from them.

[Shmuel Metz]

In <junafb$ftk$2...@dont-email.me>, on 07/24/2012

at 07:18 PM, Peter Flass <Peter...@Yahoo.com> said:

>How did the prices compare.

I'm not sure; some of the alternative vendors were gone. Does anybody
have prices on the small machines from, e.g., DEC, PB, SDS, TRW? For
that matter, wasn't the UNIVAC 490[1] fairly inexpensive?

[1] And renumbered versions thereof.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[jmfbahciv]

Jorgen Grahn wrote:
> On Sun, 2012-07-22, Charles Richmond wrote:
> ...
>> Just because a book was printed using 1403 output... that does *not* mean
>> the print was *good*! I've seen a book printed using DecWRITER (upper case
>> *and* lower case... such as lower case is on a DecWriter). That did *not*
>> make the DecWRITER lower case *good*!!! :-)
>>
>> (The book was _Invitation to Forth_, by Harry Katzan. Lest some here think
I
>> am prevaricating, I have posted some scans directly from Katzan's book on a
>> web page: http://aquaporin4.com/decwriter/.)
>
> Ugh. Good proof of the rule: if you don't have hyphenation, don't
> attempt to create a straight right margin!

That's why we used RUNOFF. Once in a great, great while we had
to fake a hyphenation but I only remember two instances.

/BAH