Burroughs B5000, B5500, B6500 videos

[Scott Lurndal]

There are some videos on you-tube of three marketing films
for the Burroughs B5000, B5500 and B6500 systems:

B5000 <http://www.youtube.com/watch?v=K3q5n1mR9iM>
B5500 <http://www.youtube.com/watch?v=KswWJ6zvBUs>
B6500 <http://www.youtube.com/watch?v=rNBtjEBYFPk>

enjoy

scott

[Nigel Williams]

On Apr 7, 10:11 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
> There are some videos on you-tube of three marketing films
> for the Burroughs B5000, B5500 and B6500 systems:

Thank you Scott for taking the time and effort to preserve and
digitize these fascinating films. I have made a transcript of the
B6500 film here:

http://www.retrocomputingtasmania.com/home/projects/burroughs-b5500/b6500-film-transcript

with an initial attempt extracting references to people, places and
objects. If anyone can add detail and stories please do.

I am particularly intrigued about the use of the B5500 to simulate the
B6500 - how much of the system was simulated? were they just compiling
the new MCP and using the regular B5500 peripherals? or were new
hardware characteristics simulated too?

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

On Apr 6, 8:11 pm, sc...@slp53.sl.home (Scott Lurndal) wrote:
> There are some videos on you-tube of three marketing films
> for the Burroughs B5000, B5500 and B6500 systems:

My college used a B5500. It gradually transitioned over to a shared
(with other colleges) large S/370 (168?). The main console of the
Burroughs was cut out and mounted on the wall after it terminated
service. It was still there as of a few years ago. I should go back
and check because the room used to be for printout delivery to bins
and keypunch machines for students; obviously that's not needed any
more.

In my day on a Saturday anyone could go in and wander around. I think
today one needs an ID card or visitor's pass, especially on a
weekend. (On my last visit, the student lounge, with pinball
machines, pool tables, and a bowling alley, was gone. I wonder if any
of that stuff is elsewhere.)


The Burroughs printer had rather wavy lines.

Our report cards were printed in a carbon mailer. The resultant
printout for us students was the last copy and barely legible due to
smudging.

[Peter Flass]

On 4/11/2012 11:23 PM, hanc...@bbs.cpcn.com wrote:
>
> The Burroughs printer had rather wavy lines.

My theory is that the 1403 printer is solely responsible for IBM's
success. No one else, it seems, could build anything as good until the
Dataproducts band printers came out, and they were much later. I'm not
sure if these were OEM'd to DEC as their LP<mumble> line printer for
VAXen, but we had one that was (IIRC) 1200lpm and did a great job.

Maybe it was IBM CE support, because all printers seemed to require a
lot of adjustment to stay registered. Also, many other printers were
drum printers, that would tend to produce wavy lines up and down, and
chop off the tops or bottoms of characters. A misadjusted 1403 would
still print a straight line, but might chop off the left or right sides
of characters.

Also, the 1403 font was a clean design and tended to stay readable.
Some line-printer fonts had extraneous design elements that detracted
from readability. [Not Burroughs, I just looked at
http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/listing/mcp_mkXV/B5700_MCP_Procedure_Names_Apr75.pdf
that shows some wavyness, but generally appears to be from a
well-adjusted printer and has a pretty clean design. I must be thinking
of XDS, like
http://www.bitsavers.org/pdf/sds/sigma/cp-v/CP-V_listing_revD00B_sep75/allycat.pdf]


--
Pete

[Ibmekon]

Also, it may be that an important component of the success of IBM was
design reliability.

If my memory is right the 1403 would give a 'hammer check' error when
just one failed - rather than continue to print out reams of paper
with a blank column.

This must have entailed significant extra design and manufacturing
cost.

So, decades later, it was disappointing when a Dataproduct printer did
just this.


Carl Goldsworthy

[Nick Spalding]

Peter Flass wrote, in <jm6j2d$al0$1...@dont-email.me>
on Thu, 12 Apr 2012 08:50:46 -0400:

>On 4/11/2012 11:23 PM, hanc...@bbs.cpcn.com wrote:
>>
>> The Burroughs printer had rather wavy lines.
>
>My theory is that the 1403 printer is solely responsible for IBM's
>success. No one else, it seems, could build anything as good until the
>Dataproducts band printers came out, and they were much later. I'm not
>sure if these were OEM'd to DEC as their LP<mumble> line printer for
>VAXen, but we had one that was (IIRC) 1200lpm and did a great job.
>
>Maybe it was IBM CE support, because all printers seemed to require a
>lot of adjustment to stay registered. Also, many other printers were
>drum printers, that would tend to produce wavy lines up and down, and
>chop off the tops or bottoms of characters. A misadjusted 1403 would
>still print a straight line, but might chop off the left or right sides
>of characters.

That was the received wisdom among us IBM CEs in the 1960s, though it
was rarely bad enough on a 1403 to actually chop the characters.

>Also, the 1403 font was a clean design and tended to stay readable.
>Some line-printer fonts had extraneous design elements that detracted
>from readability. [Not Burroughs, I just looked at
>http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/listing/mcp_mkXV/B5700_MCP_Procedure_Names_Apr75.pdf
>that shows some wavyness, but generally appears to be from a
>well-adjusted printer and has a pretty clean design. I must be thinking
>of XDS, like
>http://www.bitsavers.org/pdf/sds/sigma/cp-v/CP-V_listing_revD00B_sep75/allycat.pdf]

--

Nick Spalding

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

On Apr 12, 8:50 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> My theory is that the 1403 printer is solely responsible for IBM's
> success.  No one else, it seems, could build anything as good until the
> Dataproducts band printers came out, and they were much later.  I'm not
> sure if these were OEM'd to DEC as their LP<mumble> line printer for
> VAXen, but we had one that was (IIRC) 1200lpm and did a great job.

The Campbell Kelly book "Computer" also gives a great deal of credit
to the 1403 for the success of the IBM 1401 computer, the largest
selling computer up to that point. Interestingly, it was IBM's long
standing ability in electro-mechanical development (from tab
machines)--not electronics--that enabled it to build such a design.

But I do not agree that the 1403 printer was "solely" responsible for
IBM's success. By 1960 IBM had already pulled far ahead of its
computer competitors--after starting later with little electronics
experience. IMHO, IBM's success was due to its high degree of staff
training and preparation, and its focus on helping customers solve
problems. As a later user of various brands of computers, IBM still
had superior customer support and better trained personnel*.

*At at least two product demos from competitors, the machine hung and
the salesman was unable to restore it. I looked in the manual and
figured out the fix--it was rather simple--but the salesman didn't see
it. IBMers were like boy scouts--always prepared.

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

On Apr 12, 8:50 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> My theory is that the 1403 printer is solely responsible for IBM's
> success.  No one else, it seems, could build anything as good until the
> Dataproducts band printers came out, and they were much later.  I'm not
> sure if these were OEM'd to DEC as their LP<mumble> line printer for
> VAXen, but we had one that was (IIRC) 1200lpm and did a great job.

In the late 1970s I worked on a small Univac (90/30). The printer, a
new 400 lpm unit, was lousy. How come after all those years a
relatively slow speed line printer would still be made with poor
quality?

Anyway, I recall my manager wanting to print a organization directory
from the computer (we kept the data on line) and then have it
duplicated and distrisbuted. He obtained a one-time use carbon
printer ribbon. We discovered using a fancy ribbon on a lousy printer
only looks worse. No matter how carefully we tried to adjust it, the
letter always looked 'cropped' just a bit, and it looked worse with
the carbon ribbon.

I think in the time we played with it trying to get it right, a
secretary could've typed up a document.

As an aside, the secretaries in that office used IBM carriage
typewriters, not Selectrics. They were still new machines and typed
very well. I don't know why those were chosen over Selectrics, nor
which cost more. We also had one IBM Mag Card machine to type
repetitive documents.

(I don't think in those days there was anyway we could 'download' our
computerized directory file from the Univac to the MagCard, so the
MagCard could print out a nice crisp copy. That would've been nice.
The stuff we take for granted today.)

In another place I used a S/360-40. That had a Selectric as its
console typewriter, though with a fabric ribbon. I think it would've
been rather easy for a program to print a formatted report to the
console printer, and with a new ribbon, get reasonable print quality.
(The above Univac had a terminal for a console, not a printer). But
at that employer the issue never came up.

Also, at that employer I saw the transition in duplicating. For years
it seemed company policy at many places was that any large duplicating
runs (over 10) were to be sent to the company print shop and done on
the offset machine as opposed to the Xerox machine. By then offset
masters were relatively cheap to make. But then that employer got a
jumbo Xerxo duplicator where it was cost effective to simply use that
instead of going offset.

Schools had extensive spirit and mimeograph duplication, which was
cheap, but I did not come across those industry, though I'm sure they
were extensive used, too. Anyone could run a mimeo machine while an
offset press required more training. For short run internal documents
(eg, "Company Cafeteria Menu"), a spirit ditto machine was fine.

[Charlie Gibbs]

In article
<97e89da8-628c-45e5...@12g2000vba.googlegroups.com>,

hanc...@bbs.cpcn.com (hancock4) writes:

> In the late 1970s I worked on a small Univac (90/30). The printer,
> a new 400 lpm unit, was lousy. How come after all those years a
> relatively slow speed line printer would still be made with poor
> quality?

I remember that unit well. IMHO the most careful bit of engineering
that went into it was designing the angle of the top cover to be just
level enough to tempt you to set your card decks or papers on it while
removing your printout from the back, while being just angled enough
to make everything slide off onto the floor when you weren't looking.

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

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

On Apr 13, 1:17 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
> In article
> <97e89da8-628c-45e5-9a3f-c656e4af5...@12g2000vba.googlegroups.com>,

>
> hanco...@bbs.cpcn.com (hancock4) writes:
> > In the late 1970s I worked on a small Univac (90/30).  The printer,
> > a new 400 lpm unit, was lousy.  How come after all those years a
> > relatively slow speed line printer would still be made with poor
> > quality?
>
> I remember that unit well.  IMHO the most careful bit of engineering
> that went into it was designing the angle of the top cover to be just
> level enough to tempt you to set your card decks or papers on it while
> removing your printout from the back, while being just angled enough
> to make everything slide off onto the floor when you weren't looking.

The 1403 printer had a powered cover. When the printer ran out of
paper the cover would raise automatically, spilling any coffee, cards,
and papers left atop of it.

Univac call their on-line terminals "Uniscopes", a name I thought was
dated. the console screen was an older model than the other screens.
I think they used different technologies to "paint" the data on the
screen. If memory serves, the older one (100 series?) was more of an
"analog" display with 'painted' characters, while the newer one (200
series?) had a dot matrix looking display. the characters on the
newer displays looked more even than the older displays.

Anyone of any idea of how many Univac 90/xx series they sold?

(mentioned previously). I visited Univac's Blue Bell HQ several
times. In terms of technological ability and training, I did not feel
the Univac people were as well trained as IBMers at IBM facilities.
But the Univac people were much more down to earth and "real"; people
you could hang out with. While at IBM, everyone was just so perfectly
mannered and dressed, everything was in perfect order; I always felt
self conscious of making a faux pas. I knew of managers who preferred
non-IBM equipment for that reason--they did not like IBM's "polish".

Also, very roughly speaking, it seemed that the users of non-IBM
machines tended to be more informal and friendly than users of IBM
machines, but of course there were exceptions. (The boss at my Univac
job was very stuffy.)

I remember going for job interviews in those days and it appeared
shops using IBM OS were a bit snotty about it--they wouldn't consider
applicants with a non IBM background--or even a background in IBM
mainframes but with DOS instead of OS. Non-IBM shops tended to be
more open minded about one's background, that is, a Burroughs shop
would consider a Univac or CDC person.

IBM OS shops tended (but not always) to be more structured, and junior
programmer jobs could be grunt work, eg "here, make this table bigger
and change all searches accordingly in these 500 programs". In
contrast, at other shops, which were usually smaller, junior
programmers could start doing varied work, including meeting with end-
users, operations, etc., which was more helpful toward building a
career and understanding the overall business. Of course, some
programmers _preferred_ to work in a very structured environment.

[Nick Spalding]

hanc...@bbs.cpcn.com wrote, in
<380ba03a-9504-45cc...@fw28g2000vbb.googlegroups.com>
on Fri, 13 Apr 2012 09:42:48 -0700 (PDT):

>On Apr 13, 1:17 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>> In article
>> <97e89da8-628c-45e5-9a3f-c656e4af5...@12g2000vba.googlegroups.com>,
>>
>> hanco...@bbs.cpcn.com (hancock4) writes:
>> > In the late 1970s I worked on a small Univac (90/30).  The printer,
>> > a new 400 lpm unit, was lousy.  How come after all those years a
>> > relatively slow speed line printer would still be made with poor
>> > quality?
>>
>> I remember that unit well.  IMHO the most careful bit of engineering
>> that went into it was designing the angle of the top cover to be just
>> level enough to tempt you to set your card decks or papers on it while
>> removing your printout from the back, while being just angled enough
>> to make everything slide off onto the floor when you weren't looking.
>
>The 1403 printer had a powered cover. When the printer ran out of
>paper the cover would raise automatically, spilling any coffee, cards,
>and papers left atop of it.

I think that was the 1403N1 that came in with 360, the original 1401
version was less dangerous.
--
Nick Spalding

[Stephen Fuld]

On 4/13/2012 9:42 AM, hanc...@bbs.cpcn.com wrote:

snip

> Univac call their on-line terminals "Uniscopes", a name I thought was
> dated.

Sure. The name goes back to the older Univac systems where all the
peripherals had a "uni" prefix. The CRTs were Uniscopes, the tape
drives were Uniservos and the low speed (i.e. console type) printers
were Unitypers.

> the console screen was an older model than the other screens.
> I think they used different technologies to "paint" the data on the
> screen.

Yes, They were vector displays. Each character was a set of "vectors",
i.e. lines with a start point a length and a direction. This technology
was frequently used for graphics terminals in those days. Just another
example (along with Drum storage, and relevant to this thread, drum
printers) where Univac backed the wrong technology.

> If memory serves, the older one (100 series?) was more of an
> "analog" display with 'painted' characters, while the newer one (200
> series?) had a dot matrix looking display. the characters on the
> newer displays looked more even than the older displays.

The newer displays are an array of dots, just like current PC displays,
etc. That technology won out over vectors.


--
- Stephen Fuld
(e-mail address disguised to prevent spam)

[David Dyer-Bennet]

hanc...@bbs.cpcn.com writes:

> On Apr 13, 1:17 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>> In article
>> <97e89da8-628c-45e5-9a3f-c656e4af5...@12g2000vba.googlegroups.com>,
>>
>> hanco...@bbs.cpcn.com (hancock4) writes:
>> > In the late 1970s I worked on a small Univac (90/30).  The printer,
>> > a new 400 lpm unit, was lousy.  How come after all those years a
>> > relatively slow speed line printer would still be made with poor
>> > quality?
>>
>> I remember that unit well.  IMHO the most careful bit of engineering
>> that went into it was designing the angle of the top cover to be just
>> level enough to tempt you to set your card decks or papers on it while
>> removing your printout from the back, while being just angled enough
>> to make everything slide off onto the floor when you weren't looking.
>
> The 1403 printer had a powered cover. When the printer ran out of
> paper the cover would raise automatically, spilling any coffee, cards,
> and papers left atop of it.

The 1403 I worked with did not have this feature. I've heard about it,
though; so I think it came along in later models.
--
David Dyer-Bennet, dd...@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

[Dan Espen]

David Dyer-Bennet <dd...@dd-b.net> writes:

> hanc...@bbs.cpcn.com writes:
>
>> On Apr 13, 1:17 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>>> In article
>>> <97e89da8-628c-45e5-9a3f-c656e4af5...@12g2000vba.googlegroups.com>,
>>>
>>> hanco...@bbs.cpcn.com (hancock4) writes:
>>> > In the late 1970s I worked on a small Univac (90/30).  The printer,
>>> > a new 400 lpm unit, was lousy.  How come after all those years a
>>> > relatively slow speed line printer would still be made with poor
>>> > quality?
>>>
>>> I remember that unit well.  IMHO the most careful bit of engineering
>>> that went into it was designing the angle of the top cover to be just
>>> level enough to tempt you to set your card decks or papers on it while
>>> removing your printout from the back, while being just angled enough
>>> to make everything slide off onto the floor when you weren't looking.
>>
>> The 1403 printer had a powered cover. When the printer ran out of
>> paper the cover would raise automatically, spilling any coffee, cards,
>> and papers left atop of it.
>
> The 1403 I worked with did not have this feature. I've heard about it,
> though; so I think it came along in later models.

Yes, the N1 (Nancy 1) as another poster said.

--
Dan Espen

[Rod Speed]

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

> Peter Flass <Peter_Fl...@Yahoo.com> wrote

>> My theory is that the 1403 printer is solely responsible for IBM's
>> success. No one else, it seems, could build anything as good until the
>> Dataproducts band printers came out, and they were much later. I'm not
>> sure if these were OEM'd to DEC as their LP<mumble> line printer for
>> VAXen, but we had one that was (IIRC) 1200lpm and did a great job.

> In the late 1970s I worked on a small Univac (90/30). The printer,
> a new 400 lpm unit, was lousy. How come after all those years a
> relatively slow speed line printer would still be made with poor quality?

Presumably a combination of being cheaper to make that way and the
crew designing it not having as much of a clue as the opposition etc.

[Anne & Lynn Wheeler]

David Dyer-Bennet <dd...@dd-b.net> writes:
> The 1403 I worked with did not have this feature. I've heard about it,
> though; so I think it came along in later models.

1403N1 ... 1100 lpm ... story goes that it ran faster, made more noise,
needed more sound proofing, made the cover heavier, needed power assist
to lift.

recent post (chain versus train)
http://www.garlic.com/~lynn/2010h.html#53

URLs from above
http://en.wikipedia.org/wiki/IBM_1403
http://www-03.ibm.com/ibm/history/exhibits/attic3/attic3_024.html
http://www.columbia.edu/acis/history/chain.html
http://www-03.ibm.com/ibm/history/exhibits/endicott/endicott_chronology1970.html

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

[Peter Flass]

On 4/13/2012 10:23 AM, hanc...@bbs.cpcn.com wrote:
>
> Anyway, I recall my manager wanting to print a organization directory
> from the computer (we kept the data on line) and then have it
> duplicated and distrisbuted. He obtained a one-time use carbon
> printer ribbon. We discovered using a fancy ribbon on a lousy printer
> only looks worse. No matter how carefully we tried to adjust it, the
> letter always looked 'cropped' just a bit, and it looked worse with
> the carbon ribbon.

Cut a tape and take it to someplace with a 1403 ;-)

>
> Also, at that employer I saw the transition in duplicating. For years
> it seemed company policy at many places was that any large duplicating
> runs (over 10) were to be sent to the company print shop and done on
> the offset machine as opposed to the Xerox machine. By then offset
> masters were relatively cheap to make. But then that employer got a
> jumbo Xerxo duplicator where it was cost effective to simply use that
> instead of going offset.
>

Nowadays it's cheap to print while books on a laser printer. You can
get it punched, stapled. perfect-bound with a glossy cover.

--
Pete

[Peter Flass]

On 4/13/2012 12:42 PM, hanc...@bbs.cpcn.com wrote:
>
> (mentioned previously). I visited Univac's Blue Bell HQ several
> times. In terms of technological ability and training, I did not feel
> the Univac people were as well trained as IBMers at IBM facilities.
> But the Univac people were much more down to earth and "real"; people
> you could hang out with. While at IBM, everyone was just so perfectly
> mannered and dressed, everything was in perfect order; I always felt
> self conscious of making a faux pas. I knew of managers who preferred
> non-IBM equipment for that reason--they did not like IBM's "polish".

Depends on who you hung out with. In the formal meetings with sales and
sales-support people things could be pretty formal, but if you could get
with the guys in the back room you could have a lot of fun.

>
> Also, very roughly speaking, it seemed that the users of non-IBM
> machines tended to be more informal and friendly than users of IBM
> machines, but of course there were exceptions. (The boss at my Univac
> job was very stuffy.)
>
> I remember going for job interviews in those days and it appeared
> shops using IBM OS were a bit snotty about it--they wouldn't consider
> applicants with a non IBM background--or even a background in IBM
> mainframes but with DOS instead of OS.

Ah yes, I remember it well.

Non-IBM shops tended to be
> more open minded about one's background, that is, a Burroughs shop
> would consider a Univac or CDC person.

They had to, there weren't enough applicants with the right background.
I think they figured that an IBM guy was just biding his time until he
could get an IBM job, whereas a non-IBM guy had already shown flexibility.

>
> IBM OS shops tended (but not always) to be more structured, and junior
> programmer jobs could be grunt work, eg "here, make this table bigger
> and change all searches accordingly in these 500 programs". In
> contrast, at other shops, which were usually smaller, junior
> programmers could start doing varied work, including meeting with end-
> users, operations, etc., which was more helpful toward building a
> career and understanding the overall business. Of course, some
> programmers _preferred_ to work in a very structured environment.
>

I think it was the size of the organization ratherthan IBM/non-IBM. IBM
OS shops tended to be bigger and have more employees, so the environment
was more structured. IBM DOS shops were smaller so everyone did a
little of everything. One guy might do SYSGENs and stuff because he had
more interest and talent, but there usually wasn't a specialized staff.
Everyone had to get their hands dirty on all the applications.


--
Pete

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

On Apr 13, 1:18 pm, Nick Spalding <spald...@iol.ie> wrote:

> >The 1403 printer had a powered cover.  When the printer ran out of
> >paper the cover would raise automatically, spilling any coffee, cards,
> >and papers left atop of it.
>
> I think that was the 1403N1 that came in with 360, the original 1401
> version was less dangerous.

Probably. The S/360 version had a full cover reaching down to the
floor while the 1401 only had a partial cover. The S/360 version was
also faster.

A few years ago I ordered something via the Internet. When the item
arrived, I was surprised to find that the packing slip had been
printed by a traditional mainframe computer printer, with a typeface
that looked like the 1403 (probably a later model). The form was pre-
printed multi-part with the sprocket feeds and printed in two colors.

This kind of took me by surprise since such pre-printed forms were
largely obsolete since laser printers could generate their own forms
as needed, a big time and spave saver. Also, as said, this was an
Internet order, and I figured that would be "more modern".

[David Dyer-Bennet]

Anne & Lynn Wheeler <ly...@garlic.com> writes:

> David Dyer-Bennet <dd...@dd-b.net> writes:
>> The 1403 I worked with did not have this feature. I've heard about it,
>> though; so I think it came along in later models.
>
> 1403N1 ... 1100 lpm ... story goes that it ran faster, made more noise,
> needed more sound proofing, made the cover heavier, needed power assist
> to lift.

Ours ran 600 lpm (which was quite impressive enough, in 1969). And was
QUITE loud enough already. I can certainly imagine a faster model being
noisier, and the rest following. (I note you say 'story goes'; I have
no idea if that's really accurate either, but it's believable.)

[David Dyer-Bennet]

hanc...@bbs.cpcn.com writes:

> IBM OS shops tended (but not always) to be more structured, and junior
> programmer jobs could be grunt work, eg "here, make this table bigger
> and change all searches accordingly in these 500 programs". In
> contrast, at other shops, which were usually smaller, junior
> programmers could start doing varied work, including meeting with end-
> users, operations, etc., which was more helpful toward building a
> career and understanding the overall business. Of course, some
> programmers _preferred_ to work in a very structured environment.

My very first job, at a very small IBM shop (nearly all the programmers
were part-time students; I was hired while I was still in highschool, 15
yeras old), my first assignment was "go talk to the director of
admissions, find out what he wants in this cross-tabulating counting
program, and write it." I only learned the job title "programmer
analyst" some time later.

Then I got to write 1401 Autocoder (macro assembler) code to count into
a five-dimensional table. And figure out a way to convince myself it
was working right. And figure out a way to present the data usefully on
line-printer output (1403, in fact).

[Lawrence Greenwald]

In article <m3mx6fi...@garlic.com>,

Anne & Lynn Wheeler <ly...@garlic.com> wrote:

> David Dyer-Bennet <dd...@dd-b.net> writes:
> > The 1403 I worked with did not have this feature. I've heard about it,
> > though; so I think it came along in later models.
>
> 1403N1 ... 1100 lpm ... story goes that it ran faster, made more noise,
> needed more sound proofing, made the cover heavier, needed power assist
> to lift.
>
> recent post (chain versus train)
> http://www.garlic.com/~lynn/2010h.html#53
>
> URLs from above
> http://en.wikipedia.org/wiki/IBM_1403
> http://www-03.ibm.com/ibm/history/exhibits/attic3/attic3_024.html
> http://www.columbia.edu/acis/history/chain.html
> http://www-03.ibm.com/ibm/history/exhibits/endicott/endicott_chronology1970.ht
> ml

How did the 1403N1 compare to its successor, the 3211?

--LG

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

On Apr 13, 1:46 pm, Stephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:

> Yes, They were vector displays.  Each character was a set of "vectors",
> i.e. lines with a start point a length and a direction.  This technology
> was frequently used for graphics terminals in those days.  Just another
> example (along with Drum storage, and relevant to this thread, drum
> printers) where Univac backed the wrong technology.

Ah, that explains it. Thanks for the clarification.

[Ahem A Rivet's Shot]

Yep, the original was a hand lift cover assisted by a torsion bar,
when it snapped in ours (in the middle of *my* job) it appeared at first
that nothing had happened but an alarming loud bang. It wasn't until I
tried to lift the cover, only to find that instead of needing a light flick
upwards it needed *lifting* and it was *heavy*, that the cause of the bang
became clear.

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

[Anne & Lynn Wheeler]

Lawrence Greenwald <lawrence....@sbcglobal.net> writes:
> How did the 1403N1 compare to its successor, the 3211?

re:
http://www.garlic.com/~lynn/2012e.html#92 Burroughs B5000, B5500, B6500 videos

3211 was 2000 lpm and programmable loadable "forms control" ... rather
than control tape.
http://bitsavers.org/pdf/ibm/38xx/3811/GA24-3543-0_3211_Printer_3811_Control_Unit_Component_Description_Jun70.pdf

[Dan Espen]

Anne & Lynn Wheeler <ly...@garlic.com> writes:

> Lawrence Greenwald <lawrence....@sbcglobal.net> writes:
>> How did the 1403N1 compare to its successor, the 3211?
>
> re:
> http://www.garlic.com/~lynn/2012e.html#92 Burroughs B5000, B5500, B6500 videos
>
> 3211 was 2000 lpm and programmable loadable "forms control" ... rather
> than control tape.
> http://bitsavers.org/pdf/ibm/38xx/3811/GA24-3543-0_3211_Printer_3811_Control_Unit_Component_Description_Jun70.pdf

Looks like the same technology as the 1403, just faster.
Knowing IBM I'm guessing they managed to keep the print quality just as
good.

During that era, I started working at Bell Labs. Their high speed
mainframe printers were Xerox 9700s, printing a page at a time with
multiple fonts and 300DPI. We got book quality print. I remember
creating some pretty high quality customer documentation on
those things.

I worked in one shop with 1403N1s but instead of IBM Power for DOS,
they were using something called EDOS. It used the simple trick
of not printing a page until all the lines were in memory then
using command chaining to print the whole page with 1 I/O operation.

You could tell from the sound that EDOS was driving the printer
faster than IBM software ever did.


--
Dan Espen

[Anne & Lynn Wheeler]

Dan Espen <des...@verizon.net> writes:
> Looks like the same technology as the 1403, just faster.
> Knowing IBM I'm guessing they managed to keep the print quality just as
> good.
>
> During that era, I started working at Bell Labs. Their high speed
> mainframe printers were Xerox 9700s, printing a page at a time with
> multiple fonts and 300DPI. We got book quality print. I remember
> creating some pretty high quality customer documentation on
> those things.
>
> I worked in one shop with 1403N1s but instead of IBM Power for DOS,
> they were using something called EDOS. It used the simple trick
> of not printing a page until all the lines were in memory then
> using command chaining to print the whole page with 1 I/O operation.
>
> You could tell from the sound that EDOS was driving the printer
> faster than IBM software ever did.

re:
http://www.garlic.com/~lynn/2012e.html#92 Burroughs B5000, B5500, B6500 videos

http://www.garlic.com/~lynn/2012e.html#93 Burroughs B5000, B5500, B6500 videos

hasp & cp67 used similar command chaining to improve printing throughput
(and follow-on jes2 and vm370).

in the 3211 time-frame ... ibm also had 3800 laser page printer
http://en.wikipedia.org/wiki/IBM_3800

announce 15apr1975 and first shipped july1976 ... mentions 9700 didn't
ship until 1977.

ibm also took its copier3 and added computer interface as 6670 for
departmental printer. san jose research then modifications as sherpa or
apa6670 (all points addressable).

6670/sherpa was put all over san jose research bldg, nearly every department
got one.

6670/sherpa had dual paper trays (from copier3) and it was possible to
put different colored paper in the 2nd tray. the device driver was
change to do a output "separator" page from the 2nd tray with person's
name & other details. Since that left the majority of the separator page
blank ... the device driver was enhanced to randomly choose from a
quotations file to also print on the separator page.

we were having a corporate security audit and in a battle over "demo
programs" (aka "games") on the system. We had gotten the guidelines
rewritten so the logon 3270 screen no longer said "for business use
only" to "for management approved uses only" (which included demo
programs). In show down, demo programs were upheld.

the audit also included after-hour sweeps for classified documents being
left out, unlocked, on desks and/or printed and not secured. at one
of the 6670s, an auditor found unclassifed output left out ontop
... but with the following (random selection) on the separator page:

[Business Maxims:] Signs, real and imagined, which belong on the walls
of the nation's offices:
1) Never Try to Teach a Pig to Sing; It Wastes Your Time and It Annoys
the Pig.
2) Sometimes the Crowd IS Right.
3) Auditors Are the People Who Go in After the War Is Lost and Bayonet
the Wounded.
4) To Err Is Human -- To Forgive Is Not Company Policy.

... snip ...

another scenario was blank corporate letterhead paper use to be left
unsecured. one weekend somebody printed the following password rules on
corporate letterhead and placed one in every building bulletin board.
http://www.garlic.com/~lynn/2001d.html#52

Monday morning, several people arriving at work ... took it as an
official corporate document (they failed to notice it was dated April
1st ... which was Sunday ... and no official documents carry a Sunday
date). Afterwards there was directive that all official corporate
letterhead paper had to be kept secured under lock&key. Although I had
received the contents in email the previous Friday and redistributed it
to several people in the building ... it wasn't me that placed it in the
building bulletin boards.

past posts mentioning 3800
http://www.garlic.com/~lynn/99.html#42 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/99.html#43 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000d.html#81 Coloured IBM DASD
http://www.garlic.com/~lynn/2000e.html#1 What good and old text formatter are there ?
http://www.garlic.com/~lynn/2001b.html#50 IBM 705 computer manual
http://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
http://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002g.html#52 Spotting BAH Claims to Fame
http://www.garlic.com/~lynn/2002h.html#7 disk write caching (was: ibm icecube -- return of
http://www.garlic.com/~lynn/2002k.html#42 MVS 3.8J and NJE via CTC
http://www.garlic.com/~lynn/2002m.html#50 Microsoft's innovations [was:the rtf format]
http://www.garlic.com/~lynn/2002m.html#52 Microsoft's innovations [was:the rtf format]
http://www.garlic.com/~lynn/2002o.html#24 IBM Selectric as printer
http://www.garlic.com/~lynn/2002o.html#29 6670
http://www.garlic.com/~lynn/2003c.html#43 Early attempts at console humor?
http://www.garlic.com/~lynn/2003k.html#45 text character based diagrams in technical documentation
http://www.garlic.com/~lynn/2003k.html#52 dissassembled code
http://www.garlic.com/~lynn/2004c.html#1 Oldest running code
http://www.garlic.com/~lynn/2004d.html#13 JSX 328x printing (portrait)
http://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004k.html#48 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004l.html#61 Shipwrecks
http://www.garlic.com/~lynn/2005b.html#25 360POO
http://www.garlic.com/~lynn/2005f.html#34 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#48 1403 printers
http://www.garlic.com/~lynn/2005f.html#51 1403 printers
http://www.garlic.com/~lynn/2005f.html#52 1403 printers
http://www.garlic.com/~lynn/2005f.html#54 1403 printers
http://www.garlic.com/~lynn/2005k.html#58 Book on computer architecture for beginners
http://www.garlic.com/~lynn/2005l.html#0 Book on computer architecture for beginners
http://www.garlic.com/~lynn/2005r.html#29 Job seperators
http://www.garlic.com/~lynn/2006b.html#20 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006n.html#0 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006n.html#4 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006p.html#44 Materiel and graft
http://www.garlic.com/~lynn/2006p.html#49 Materiel and graft
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2007b.html#36 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007g.html#27 The Complete April Fools' Day RFCs
http://www.garlic.com/~lynn/2007u.html#72 Parse/Template Function
http://www.garlic.com/~lynn/2008d.html#51 It has been a long time since Ihave seen a printer
http://www.garlic.com/~lynn/2008h.html#8a Using Military Philosophy to Drive High Value Sales
http://www.garlic.com/~lynn/2008l.html#15 Code Page 1047 vs 037 - Green card confusion
http://www.garlic.com/~lynn/2008l.html#79 Book: "Everyone Else Must Fail" --Larry Ellison and Oracle ???
http://www.garlic.com/~lynn/2008o.html#68 Blinkenlights
http://www.garlic.com/~lynn/2008o.html#69 Blinkenlights
http://www.garlic.com/~lynn/2008p.html#42 Password Rules
http://www.garlic.com/~lynn/2008p.html#71 Password Rules
http://www.garlic.com/~lynn/2009k.html#6 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009l.html#0 Cyber attackers empty business accounts in minutes
http://www.garlic.com/~lynn/2009l.html#19 Disksize history question
http://www.garlic.com/~lynn/2009m.html#1 Does this count as 'computer' folklore?
http://www.garlic.com/~lynn/2010c.html#24 Processes' memory
http://www.garlic.com/~lynn/2010c.html#69 Apple iPad -- this merges with folklore
http://www.garlic.com/~lynn/2010c.html#74 Apple iPad -- this merges with folklore
http://www.garlic.com/~lynn/2010c.html#85 Apple iPad -- this merges with folklore
http://www.garlic.com/~lynn/2010d.html#2 Apple iPad -- this merges with folklore
http://www.garlic.com/~lynn/2010d.html#23 Apple iPad -- this merges with folklore
http://www.garlic.com/~lynn/2010d.html#60 LPARs: More or Less?
http://www.garlic.com/~lynn/2010d.html#68 Adventure - Or Colossal Cave Adventure
http://www.garlic.com/~lynn/2010e.html#43 Boyd's Briefings
http://www.garlic.com/~lynn/2010h.html#57 IBM 029 service manual
http://www.garlic.com/~lynn/2010h.html#59 IBM 029 service manual
http://www.garlic.com/~lynn/2010k.html#49 GML
http://www.garlic.com/~lynn/2010l.html#61 Mainframe Slang terms
http://www.garlic.com/~lynn/2010p.html#18 Rare Apple I computer sells for $216,000 in London
http://www.garlic.com/~lynn/2010p.html#60 Daisywheel Question: 192-character Printwheel Types
http://www.garlic.com/~lynn/2011.html#1 Is email dead? What do you think?
http://www.garlic.com/~lynn/2011.html#89 Make the mainframe work environment fun and intuitive
http://www.garlic.com/~lynn/2011b.html#82 If IBM Hadn't Bet the Company
http://www.garlic.com/~lynn/2011b.html#84 If IBM Hadn't Bet the Company
http://www.garlic.com/~lynn/2011c.html#24 If IBM Hadn't Bet the Company
http://www.garlic.com/~lynn/2011e.html#55 junking CKD; was "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011f.html#10 History of APL -- Software Preservation Group
http://www.garlic.com/~lynn/2011f.html#21 WHAT WAS THE PROJECT YOU WERE INVOLVED/PARTICIPATED AT IBM THAT YOU WILL ALWAYS REMEMBER?
http://www.garlic.com/~lynn/2011f.html#62 Mixing Auth and Non-Auth Modules
http://www.garlic.com/~lynn/2011g.html#19 program coding pads
http://www.garlic.com/~lynn/2011g.html#21 program coding pads
http://www.garlic.com/~lynn/2011g.html#26 program coding pads
http://www.garlic.com/~lynn/2011n.html#53 Virginia M. Rometty elected IBM president
http://www.garlic.com/~lynn/2012e.html#77 Just for a laugh... How to spot an old IBMer

[Joe Morris]

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

On Apr 13, 1:17 pm, "Charlie Gibbs" wrote:

>The 1403 printer had a powered cover. When the printer ran out of
>paper the cover would raise automatically, spilling any coffee, cards,
>and papers left atop of it.

Make that "1403 model N1". The other 1403 models had manual covers...but
they didn't have the acoustic insulation that made the motorized cover, if
not necessary, at least highly desirable.

The automatic cover lift did have one nice thing about it: it offered
amusement to the existing staff when a new operator learned the hard way not
to stack paper atop the cover. (As self-protection the operators would
usually remove any coffee cups or other spillable/breakable objects placed
on the covers.)

Another bit of humor came from watching the same new operators when the CE
was working on the backside of the printer: he could latch the front of the
cover in place and use the motor lift to open the *back*...much to the
surprise of staff who hadn't seen it in action.

And not necessarily restricted to the 1403-N1: to really confuse the new
staff, a common practical joke was to switch the indicator jewels between
the 1403 and the 2540 card reader/punch. Great fun watching the new
operator trying to figure out how to respnd to a "Chip Box Full" error on
the printer...

>(mentioned previously). I visited Univac's Blue Bell HQ several
>times. In terms of technological ability and training, I did not feel
>the Univac people were as well trained as IBMers at IBM facilities.
>But the Univac people were much more down to earth and "real"; people
>you could hang out with. While at IBM, everyone was just so perfectly
>mannered and dressed, everything was in perfect order; I always felt
>self conscious of making a faux pas. I knew of managers who preferred
>non-IBM equipment for that reason--they did not like IBM's "polish".

Depends on the specific branch office management, which could sometimes be
enforcing the dress policies to a degree that was inversely proportional to
the distance from Galactic Headquarters.

The office that serviced my account in the mid-1960s had a "traditional" IBM
culture, but the BO manager was promoted to Corporate, and for several
months the slot wasn't filled. With nobody to enforce it the traditional
IBM dress code died a quick death, and the office blossomed with color; when
a new manager arrived the change had gone too far to be reversed -
especially since none of the customers had problems with the "new" IBM
culture.

The office was never "stuffy", at least from the viewpoint from the four
large accounts that it serviced (one of which was mine). It might have been
less accommodating to small shops that didn't deliver high commissions.

Like any large organization there were CEs who geniuses in their specialty
and idiots elsewhere, but to a great degree the CE crew and the senior
engineering staff quickly learned to trust each other's judgment, and at
times the CEs looked the other way after we had done repairs on our own
rather than wait for the CE if our normally resident CE was unavailable (one
of our sysprogs even designed and instlled a hardware mod to the 7040 - the
CEs had no problems with it). (And when I left that shop, the entire CE
staff at the branch took me to lunch, presenting me with one of the machined
hex keys that came with the early 3380s.)

Of course, not all branches worked that way. At my current POE (which
ceased using IBM equipment almost 20 years ago) one night we had a failure
of the floppy reader in a 3880, and the IBM dispatcher was absolutely
floored when I gave her the FRU number that the CE would need to
bring...apparently she had no clue that a mere customer could figure that
out...

>Also, very roughly speaking, it seemed that the users of non-IBM
>machines tended to be more informal and friendly than users of IBM
>machines, but of course there were exceptions. (The boss at my Univac
>job was very stuffy.)

All of my experience has been in academia (at a Very Large State University)
and (in my current position) with a nonprofit spinnoff of a Very Well-Known
Private University. So-called "commercial" shops (more accurately, those
that existed to process business data) may have been stuffy, but staff at
the academic and research shops were anything but "stuffy". I haven't
attended a SHARE meeting in many years, but at its biannual meetings,
Thursday night at SCIDS was about as un-stuffy as you could hope for. (How
many people here have sung "HASP-y Days Are Here Again", with music played
on a Model 88?)

>I remember going for job interviews in those days and it appeared
>shops using IBM OS were a bit snotty about it--they wouldn't consider
>applicants with a non IBM background--or even a background in IBM
>mainframes but with DOS instead of OS. Non-IBM shops tended to be
>more open minded about one's background, that is, a Burroughs shop
>would consider a Univac or CDC person.

Depends on what skills the shop needs, and how much of a cold-start training
budget it has. When I was running a datacenter (IBM VM/HPO and Vaxen
running Ultrix and VMS) if I wanted an operator/setup clerk/gofer I wouldn't
have much problem in taking on someone who had no IBM or DEC experience if
no candidate could offer that background. However, if I was looking for a
VM system programmer, VMS sysadmin, or an operations supervisor, I didn't
have the luxury of hand-holding that person while they learned the odd
corners of the operating system and hardware.

>IBM OS shops tended (but not always) to be more structured, and junior
>programmer jobs could be grunt work, eg "here, make this table bigger
>and change all searches accordingly in these 500 programs". In
>contrast, at other shops, which were usually smaller, junior
>programmers could start doing varied work, including meeting with end-
>users, operations, etc., which was more helpful toward building a
>career and understanding the overall business. Of course, some
>programmers _preferred_ to work in a very structured environment.

Again, business-oriented computer facilities (which were usually the
outgrowth of card-walloper shops) might be that way, but research shops, and
especially academic shops, didn't usually work that way.

Joe

[Charlie Gibbs]

In article
<380ba03a-9504-45cc...@fw28g2000vbb.googlegroups.com>,

hanc...@bbs.cpcn.com (hancock4) writes:

> On Apr 13, 1:17 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>
>> In article
>> <97e89da8-628c-45e5-9a3f-c656e4af5...@12g2000vba.googlegroups.com>,
>>
>> hanco...@bbs.cpcn.com (hancock4) writes:
>>
>>> In the late 1970s I worked on a small Univac (90/30).  The printer,
>>> a new 400 lpm unit, was lousy.  How come after all those years a
>>> relatively slow speed line printer would still be made with poor
>>> quality?
>>
>> I remember that unit well.  IMHO the most careful bit of engineering
>> that went into it was designing the angle of the top cover to be
>> just level enough to tempt you to set your card decks or papers
>> on it while removing your printout from the back, while being just
>> angled enough to make everything slide off onto the floor when you
>> weren't looking.
>
> The 1403 printer had a powered cover. When the printer ran out of
> paper the cover would raise automatically, spilling any coffee, cards,
> and papers left atop of it.

I guess you could say that the Univac printer was eco-friendly -
it accomplished much of the same mayhem without consuming extra
power. :-)

> Univac call their on-line terminals "Uniscopes", a name I thought was
> dated. the console screen was an older model than the other screens.
> I think they used different technologies to "paint" the data on the
> screen. If memory serves, the older one (100 series?) was more of an
> "analog" display with 'painted' characters, while the newer one (200
> series?) had a dot matrix looking display. the characters on the
> newer displays looked more even than the older displays.

Yes, the Uniscope 100 drew each character with individual strokes,
while the U200 had a raster display. (Later terminals, e.g. the
UTS 400, dropped the "Uniscope" moniker.)

If you popped off the bezel of a U100 you revealed a couple of
controls that were reserved for the CEs. One of them was a master
brightness control which you could turn high enough to make a grid
of dots appear on the screen, one at each character position. These
were the "home positions" relative to which the strokes forming each
character were were based.

The U100s were indeed an earlier model; they had a smaller screen.
The ones used as the 90/30 console displayed 16 rows of 64 characters,
although a 12x80 option was available for general applications.
The U200 offered a full 24x80 display (including lower case if
you moved a secret jumper inside).

> Anyone of any idea of how many Univac 90/xx series they sold?

A lot. They were all over Vancouver in the early '80s; I worked
at a couple of sites that had them, and when I was working for
Sperry I visited most of the local sites. My job consisted mostly
of converting customers from 9300 and 9400 systems to the 90/30
(and later the System 80).

> (mentioned previously). I visited Univac's Blue Bell HQ several
> times. In terms of technological ability and training, I did not feel
> the Univac people were as well trained as IBMers at IBM facilities.
> But the Univac people were much more down to earth and "real"; people
> you could hang out with. While at IBM, everyone was just so perfectly
> mannered and dressed, everything was in perfect order; I always felt
> self conscious of making a faux pas. I knew of managers who preferred
> non-IBM equipment for that reason--they did not like IBM's "polish".

That's the feel I got. I didn't hang out with IBMers much, but
Univac people (both customers and staff) felt much more like the
kind of people you'd go for a beer with. (And I did.)

<snip>

> IBM OS shops tended (but not always) to be more structured, and junior
> programmer jobs could be grunt work, eg "here, make this table bigger
> and change all searches accordingly in these 500 programs". In
> contrast, at other shops, which were usually smaller, junior
> programmers could start doing varied work, including meeting with

> end-users, operations, etc., which was more helpful toward building

> a career and understanding the overall business. Of course, some
> programmers _preferred_ to work in a very structured environment.

I liked the informal attitude, and gravitated toward smaller shops,
which were less formal by nature. As a programmer, I enjoyed the
freedom of talking with the users and operators and being able to
hack the programs to meet their needs.

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

On Apr 13, 5:58 pm, Dan Espen <des...@verizon.net> wrote:

> During that era, I started working at Bell Labs.  Their high speed
> mainframe printers were Xerox 9700s, printing a page at a time with
> multiple fonts and 300DPI.  We got book quality print.  I remember
> creating some pretty high quality customer documentation on
> those things.

We had some sort of Xerox mainframe printer, but it sure was not book
quality. For forms, we had rubber "mats" that were placed atop the
printer, like on a copier machine, that served as a flash overlay for
the form. That was still easier than stocking all sorts of forms.

While the quality was only so-so (more of a gray on white than black
on white and some stray speckles), it was certainly adequate for stock
paper reports and internal registers. It saved a ton on filing space
since instead of 11" x 15" greenbar paper we had plain 8.5" x 11"
paper which fit in standard binders, filing cabinets, and was much
easier to work with than the big greenbar paper.

It also handled lower case, so it could be used for documentation
purposes--once we got terminals that handled lower case.

I think later we got 9700 where the forms were programmed into the
machine

> I worked in one shop with 1403N1s but instead of IBM Power for DOS,
> they were using something called EDOS.  It used the simple trick
> of not printing a page until all the lines were in memory then
> using command chaining to print the whole page with 1 I/O operation.
>
> You could tell from the sound that EDOS was driving the printer
> faster than IBM software ever did.

Our S/360-40 originally did not have any spooling, a legacy of the
1401 days. Then a new manager brought in spooling and that improved
machine throughput tremendously. There was just those 2415 tape
drives that were horrendously slow. When I changed jobs I was amazed
at how fast 'normal' 2400 tape drives ran.

What amazed me was how easy it was to install spooling on the S/360-40
(DOS Rel 26). I didn't think it would be compatible with our
Autocoder Emulation jobs, but it was. There was very little tweaking
involved.

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

On Apr 13, 4:37 pm, David Dyer-Bennet <d...@dd-b.net> wrote:

> My very first job, at a very small IBM shop (nearly all the programmers
> were part-time students; I was hired while I was still in highschool, 15
> yeras old), my first assignment was "go talk to the director of
> admissions, find out what he wants in this cross-tabulating counting
> program, and write it."  I only learned the job title "programmer
> analyst" some time later.

I used to think those days and opportunities were gone forever, but I
heard of two guys who got jobs in a small outfit where they do pretty
much everything. Of course, in today's world both guys were
experienced, not at all kids. (One guy was grateful to have any job
since he was out of work.)

I do think kids coming out of school today will have it _harder_ than
those who graduated in the 1970s. IMHO, there are fewer jobs,
companies are fussier, and salaries and benefits crappy.

Back then, companies, esp IT units, were not charities, but most
didn't have "white collar workers are the enemy" attitude so prevalent
today. (Blue collar workers were and are another story).

FWIW, it seemed to me back then Personnel Departments were interesting
in helping people enjoy the benefits a company provided and solving
any problems. Now it seems they're more interested in finding ways to
deny benefits and find rule breakers--and there are a lot more rules
to break.

[Dan Espen]

Anne & Lynn Wheeler <ly...@garlic.com> writes:

> in the 3211 time-frame ... ibm also had 3800 laser page printer
> http://en.wikipedia.org/wiki/IBM_3800
>
> announce 15apr1975 and first shipped july1976 ... mentions 9700 didn't
> ship until 1977.

I did not know that. We got them in a different order.
I had been used to the X9700 for many years before the IBM 3800
and 3820s showed up at our site.

I wrote mainframe software that enabled users to utilize just about
every capability of the X9700 I could find.

When the 38xx's showed up, one of the IT guys claimed I could never
get the X9700 features I had exploited to work compatibly on the 3800s.

I had a 20+ page manual demonstrating all the features of the
X9700 and eventually did get it to print character for character
on a 3800. Looked pretty weird on fanfold.

Had to learn that crazy PSF stuff. The folks at IBM just never
believed in escape sequences or simple commands.

The 3800 series is 240 DPI and produces an inferior result
compared to the X9700.


--
Dan Espen

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

On Apr 13, 9:17 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:

Thanks for the Uniscope information. I was curious as to how they
worked.

> > Anyone of any idea of how many Univac 90/xx series they sold?
>
> A lot.  They were all over Vancouver in the early '80s; I worked
> at a couple of sites that had them, and when I was working for
> Sperry I visited most of the local sites.  My job consisted mostly
> of converting customers from 9300 and 9400 systems to the 90/30
> (and later the System 80).

When I started my first assignment was to do conversion per above. I
think the old machine was a 9000. It meant learning RPG real fast. I
was not a big RPG fan. (BTW, RPG was developed by IBM for its 1401 to
make it easy for tab machine operators to learn to program). [Also
not a big fan of APL which I had to learn in college as part of
another class. Did not learn it very well and remember _nothing_
about it.]

I don't know what RPG version they used. On IBM's S/3x series, they
upgraded RPG and got away from using the built-in "cycle"--RPG IV was
totally different than the RPG used in the old days. Today they have
Visual RPG, but I know nothing about it.

> That's the feel I got.  I didn't hang out with IBMers much, but
> Univac people (both customers and staff) felt much more like the
> kind of people you'd go for a beer with.  (And I did.)

Exactly. I got friendly with our Univac rep and we used to go to
lunch. Nice guy.

In earlier threads, we talked about Herman Lukoff "From Dits to
Bits". You could tell from his book he was a nice guy. To me, that
was the old Univac.

While I was not a big fan of Univac machines (I didn't particularly
enjoy my stint on the 90/30), I still was sad when the company merged
with Burroughs and later ran into trouble. It seems today it's but a
tiny speck of its former self. Let's not forget Remington Rand was a
big office machine company in its own right, as was Burroughs. I did
like Remington typewriters.

[Dan Espen]

In a DOS shop we had a guy come in and install something called GRASP.
Not an IBM product.

Very simple to install and worked great.

Then IBM started with the relentless meetings with the boss to get
us to switch to Power. I left before they succeeded.

Never messed with the slow tape drives.
High speed tapes were pretty cool to watch.

--
Dan Espen

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

On Apr 13, 8:10 pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> The office that serviced my account in the mid-1960s had a "traditional" IBM
> culture, but the BO manager was promoted to Corporate, and for several
> months the slot wasn't filled.  With nobody to enforce it the traditional
> IBM dress code died a quick death, and the office blossomed with color; when
> a new manager arrived the change had gone too far to be reversed -
> especially since none of the customers had problems with the "new" IBM
> culture.

It wasn't just the IBM dress code (though that was part of it); it was
the "IBM atmosphere": All the IBMers were always very polished, very
professional, always dignified, very low-key. They were confident,
but not egotistical. There were certainly social graces--starting off
with coffee and some chitchat and even humor, but it was always very
polite conversation, no loud laughter, no nasty jokes. Everything was
always well organized and neat and clean.

Let's see: the following TV folks could be IBMers:

-Ward Cleaver
-June Cleaver
-Dr. Bob Hartley (Bob Newhart), but _not_ Emily, his secretary, or the
dentist.
-Mike & Carol Brady but not the kids or the housekeeper. Marcia is
sweet and clean-cut enough, but cries too easily. Mike Brady (the
father) would be a perfect IBMer--confident, soft spoken, competent.
-Nobody in any Norman Lear show--none of the Bunkers, Maud & Family,
One Day at the time, Jeffersons (except perhaps Louise Jefferson).
--Rob & Laura Petrie, but not the other characters.
--Dobie Gillis--assuming he matured after he grew up. Certainly not
his parents nor Maynard/Gilligan.
--The Professor and Mary Ann could be, but not the skipper, movie
star, the Howells.

[Peter Flass]

On 4/13/2012 10:55 PM, hanc...@bbs.cpcn.com wrote:
> On Apr 13, 9:17 pm, "Charlie Gibbs"<cgi...@kltpzyxm.invalid> wrote:
>
> Thanks for the Uniscope information. I was curious as to how they
> worked.
>
>>> Anyone of any idea of how many Univac 90/xx series they sold?
>>
>> A lot. They were all over Vancouver in the early '80s; I worked
>> at a couple of sites that had them, and when I was working for
>> Sperry I visited most of the local sites. My job consisted mostly
>> of converting customers from 9300 and 9400 systems to the 90/30
>> (and later the System 80).

I've been meaning to ask, was the 90/ series the old RCA Spectra-70?

...

>
> While I was not a big fan of Univac machines (I didn't particularly
> enjoy my stint on the 90/30), I still was sad when the company merged
> with Burroughs and later ran into trouble. It seems today it's but a
> tiny speck of its former self.

Unfortunately, both Univac and Burroughs are. It's hard to even find
out that they're in the mainframe biz anymore.

--
Pete

[Peter Flass]

On 4/13/2012 11:14 PM, Dan Espen wrote:
>
> Never messed with the slow tape drives.
> High speed tapes were pretty cool to watch.
>

I'll never forget the load "honk" when the things loaded a tape. My
original acquaintance with tape was 2415s. Unfortunately, one of the
first times I saw a 2480 it loaded a tape and the take-up reel came off.


--
Pete

[Anne & Lynn Wheeler]

hanc...@bbs.cpcn.com writes:
> Our S/360-40 originally did not have any spooling, a legacy of the
> 1401 days. Then a new manager brought in spooling and that improved
> machine throughput tremendously. There was just those 2415 tape
> drives that were horrendously slow. When I changed jobs I was amazed
> at how fast 'normal' 2400 tape drives ran.
>
> What amazed me was how easy it was to install spooling on the S/360-40
> (DOS Rel 26). I didn't think it would be compatible with our
> Autocoder Emulation jobs, but it was. There was very little tweaking
> involved.

univ. had 709 with a 1401 "front-end" ... ran MPIO unit record
front-end for 709, i.e. card reader->tape & tape->printer/punch.
tapes had to be manually moved between 709 and 1401 tape drives

as part of transition from 709/1401 (ibsys) to tss/360 on 360/67, the
1401 was initially replaced with 360/30. The 360/30 could run MPIO in
1401 hardware emulation mode ... but they gave me a student job to
rewrite MPIO in 360 assembler to run natively on 360/30 (I guess as part
of getting acquainted with 360).

They would let me have the datacenter on the weekends (8am sat until 8am
mon ... 48hrs w/o sleep made monday classes interesting). I got to
design my own monitor, dispatcher, interrupt handlers, device drivers,
storage management, error recovery, etc. Eventually had 2000 (box) cards
with assembler switch for generating "stand-alone" version and a os/360
version with system services i/o macros and "DCBs". The stand-alone
version took about 25 minutes elapsed time to assemble (circa os/360 pcp
release 6) and the os/360 version took approx. an hour to assemble
(light pattern on 360/30 front panel seem to indicate that each DCB
macro took approx. 5 minutes elapsed time to assemble).

Later 360/67 came in to replace 709-360/30 combo ... tss/360 never quite
made it to production level use ... so the machine ran in 360/65 mode
majority of time. Now student fortran jobs were taking under second
elapsed time under ibsys tape->tape on 709. Initial throughput on os/360
they were taking well over a minute elapsed time. About this time, the
univ. let me have support responsibility for os/360 ... and eventually I
got HASP spooling ... which brought elapsed time down to almost
30seconds. I then did lots of optimization of os/360 sysgen ... to
carefully order where things were placed on disk (reducing avg. arm seek
distance) ... getting elapsed time down to under 13 seconds (almost
another factor of 3times improvement).

Old post with part of presenetation that I gave at fall '68 SHARE
meeting on the os/360 work ... also I got to play with cp67 on the
weekends and had rewritten lots of cp67 kernel code ... some test
summary also appears in the presentation
http://www.garlic.com/~lynn/94.html#18

However, it wasn't until we got WATFOR at the univ. that student fortran
job elapsed time drop below the sub-second that they ran on ibsys 709.

misc. recent posts mentioning WATFOR:
http://www.garlic.com/~lynn/2010b.html#61 Source code for s/360 [PUBLIC]
http://www.garlic.com/~lynn/2010e.html#54 search engine history, was Happy DEC-10 Day
http://www.garlic.com/~lynn/2010f.html#28 floating point, was history of RPG, Fortran

http://www.garlic.com/~lynn/2010l.html#61 Mainframe Slang terms

http://www.garlic.com/~lynn/2010n.html#66 PL/1 as first language
http://www.garlic.com/~lynn/2011g.html#44 My first mainframe experience
http://www.garlic.com/~lynn/2011g.html#50 My first mainframe experience
http://www.garlic.com/~lynn/2011h.html#17 Is the magic and romance killed by Windows (and Linux)?
http://www.garlic.com/~lynn/2011j.html#13 program coding pads
http://www.garlic.com/~lynn/2011k.html#17 Last card reader?
http://www.garlic.com/~lynn/2011o.html#34 Data Areas?
http://www.garlic.com/~lynn/2011p.html#5 Why are organizations sticking with mainframes?
http://www.garlic.com/~lynn/2012.html#36 Who originated the phrase "user-friendly"?
http://www.garlic.com/~lynn/2012.html#43 Who originated the phrase "user-friendly"?
http://www.garlic.com/~lynn/2012d.html#7 PCP - memory lane

[ken...@cix.compulink.co.uk]

In article <jm9opv$aan$1...@dont-email.me>, SF...@alumni.cmu.edu.invalid

(Stephen Fuld) wrote:

> where Univac backed the wrong technology.

Vector graphics hung on for a long time. IIRC they were used in GEM. I
can remember when Windows 3.1 came out people were moaning about the
limitations of bit mapped fonts. Vector fonts scaled properly while to
get a decent result with bit mapped fonts you really needed to actually
create fonts in various sizes.

Ken Young

[Stan Barr]

I remember playing with a terminal that scanned about 25 lines and
built the characters by "spot wobbling", is that the sort of thing you
mean? (Can't remember the make, but I remember reading the technical
manual to find out how it worked)

--
Cheers,
Stan Barr plan.b .at. dsl .dot. pipex .dot. com

The future was never like this!

[Scott Lurndal]

hanc...@bbs.cpcn.com writes:

>On Apr 13, 4:37=A0pm, David Dyer-Bennet <d...@dd-b.net> wrote:
>
>> My very first job, at a very small IBM shop (nearly all the programmers
>> were part-time students; I was hired while I was still in highschool, 15
>> yeras old), my first assignment was "go talk to the director of
>> admissions, find out what he wants in this cross-tabulating counting

>> program, and write it." =A0I only learned the job title "programmer

>> analyst" some time later.
>
>I used to think those days and opportunities were gone forever, but I
>heard of two guys who got jobs in a small outfit where they do pretty
>much everything. Of course, in today's world both guys were
>experienced, not at all kids. (One guy was grateful to have any job
>since he was out of work.)
>
>I do think kids coming out of school today will have it _harder_ than
>those who graduated in the 1970s. IMHO, there are fewer jobs,
>companies are fussier, and salaries and benefits crappy.

That doesn't seem to apply in the valley - jobs are plentiful for
those with the proper skillsets, salaries and benefits are quite
good, for the most part. Google and Apple in particular will
snap up competent software engineers in a minute; both have good
packages, and that raises the packages for the rest of the valley.

Of course, the medical packages aren't as comprehensive as they were
in the 70's and 80's, but then there was no such thing as a stent,
nor were there Magnetic Resonance Imaging, Computed Tomography,
Laproscopic surgery, angioplasty and bypass surgery was just becoming
possible. And the scumbag lawyers weren't allowed to advertise
(just watch overnight cable channels for the incessant lawyer advertising
drug and asbestos lawsuits). And drug companies weren't allowed to
advertise, either.

scott

[Dan Espen]

Vector mapped fonts (usually called outline fonts) are not the same
thing as vector displays.

In a vector display, instead of scanning the beam side to side, the beam
follows the outline of the object being drawn. The most famous vector
display is the one used for the video game Asteroids.

--
Dan Espen

[Stephen Fuld]

On 4/14/2012 8:19 AM, Stan Barr wrote:
> On Fri, 13 Apr 2012 13:10:26 -0700 (PDT), hanc...@bbs.cpcn.com
> <hanc...@bbs.cpcn.com> wrote:
>> On Apr 13, 1:46 pm, Stephen Fuld<SF...@alumni.cmu.edu.invalid> wrote:
>>
>>> Yes, They were vector displays. Each character was a set of "vectors",
>>> i.e. lines with a start point a length and a direction. This technology
>>> was frequently used for graphics terminals in those days. Just another
>>> example (along with Drum storage, and relevant to this thread, drum
>>> printers) where Univac backed the wrong technology.
>>
>> Ah, that explains it. Thanks for the clarification.
>
> I remember playing with a terminal that scanned about 25 lines and
> built the characters by "spot wobbling", is that the sort of thing you
> mean? (Can't remember the make, but I remember reading the technical
> manual to find out how it worked)

I've never heard of "spot wobbling" so I can't comment on it. For a
better example of a "vector" type display, think of an old oscilloscope.
A variable voltage applied to the plates within the CRT moves the "rays"
of electrons horizontally (the time sweep) and vertically (the applied
signal). You could use a precise combination of varying voltages
applied to horizontal and vertical plates to "draw" characters.

This is in contrast to a raster display where the sweep of the beam is
fixed in the design and characters are "drawn" by turning the beam on
and off at various fixed locations (i.e. dots) on the screen.




--
- Stephen Fuld
(e-mail address disguised to prevent spam)

[Joe Morris]

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

> Never messed with the slow tape drives.
> High speed tapes were pretty cool to watch.

True...but the 2415 (and its ancestor, the 7330) were disgusting. The 7330
ran at 15 inches/second; the faster (sort-of) 2415 ran at 18.75 ips.

The thing that frosted me was the lack of a high-speed rewind. The drive
would do a high-speed rewind/unload, but if you were at the end of a 2400'
reel and issued a rewind command, the tape would run backwards at rated
speed. (The 729, 2420, 3420 drives, if a rewind was decoded and the tape
was more than a few hundred feed from load point, would unload the vacuum
columns, spin directly reel-to-reel until close to the load point, reload
the vacuum columns, and only then run backwards at normal speed, looking for
the BOT reflector.

Joe

[Joe Morris]

"Anne & Lynn Wheeler" <ly...@garlic.com> wrote:

> univ. had 709 with a 1401 "front-end" ... ran MPIO unit record
> front-end for 709, i.e. card reader->tape & tape->printer/punch.
> tapes had to be manually moved between 709 and 1401 tape drives

This was standard for the big systems since it offloaded the slow unit
record operations to the 1401.

The 7040/7044 had the ability to directly attach a 1401 (as the "S" channel)
but I never heard of a facility with that configuration.

Joe

[Jim Haynes]

On 2012-04-13, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:
> (mentioned previously). I visited Univac's Blue Bell HQ several
> times. In terms of technological ability and training, I did not feel
> the Univac people were as well trained as IBMers at IBM facilities.
> But the Univac people were much more down to earth and "real"; people
> you could hang out with. While at IBM, everyone was just so perfectly
> mannered and dressed, everything was in perfect order; I always felt
> self conscious of making a faux pas. I knew of managers who preferred
> non-IBM equipment for that reason--they did not like IBM's "polish".
>

> Also, very roughly speaking, it seemed that the users of non-IBM
> machines tended to be more informal and friendly than users of IBM
> machines, but of course there were exceptions. (The boss at my Univac
> job was very stuffy.)

And, to bring the topic back to the B5500...now my experience with that
machine was in its twilight years, but it was still a lot of fun. And
what seemed to me was that the B5500 was designed so you could get your
work done, wherease the IBM 360 was designed for the "control freak"
who wanted to specify exactly where everything was done. Just comparing
the job control language - with Burroughs you just said what you wanted
it to do and that was that. With IBM you had to tell it to execute the
compiler, and you had to specify where all the disk space was coming from
and how it was arranged, etc. Of course the removable disk packs of IBM
came at a high price in complexity compared with the non-removable disk
storage of the B5500. As did using the overlaying loader of the IBM
versus the automatic overlaying of the Burroughs. And the Burroughs
protection against exceeding array bounds - now today it seems like our
#1 problem is buffer overflowing.

[Walter Bushell]

In article <QbmdnZjJA5kyGhTS...@giganews.com>,

Nowadays we store the fonts in vector format and display on bitmapped
displays.

--
This space unintentionally left blank.

[sidd]

On Fri, 13 Apr 2012 10:46:40 -0700, Stephen Fuld wrote:

snip--

> Yes, They were vector displays. Each character was a set of "vectors",
> i.e. lines with a start point a length and a direction. This technology
> was frequently used for graphics terminals in those days.

tektronix for one. i see that gnuplot still will do tek4014, and xterm
still has the 'show tek window' thing.

not quite the same as that oldtime green screen

sidd

[Peter Flass]

Postscript and TruType fonts are vectors. The have to be rasterized to
display and print on current equipment.

--
Pete

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

On Apr 13, 5:17 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:

> 3211 was 2000 lpm and programmable loadable "forms control" ... rather

> than control tape.http://bitsavers.org/pdf/ibm/38xx/3811/GA24-3543-0_3211_Printer_3811_...

I think IBM even marketed the rubber cement used to glue the control
tape together, in a nice blue and white can; along with IBM brand
light oil and IBM cleaning fluid for the machines.

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

On Apr 13, 7:43 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:


> ibm also took its copier3 and added computer interface as 6670 for
> departmental printer. san jose research then modifications as sherpa or
> apa6670 (all points addressable).

IBM made nice copying machines, IMHO, the print quality was superior
to Xerox copiers. But I don't know how price or reliability compared.

The 6670 was a nice machine.

> we were having a corporate security audit and in a battle over "demo
> programs" (aka "games") on the system. We had gotten the guidelines
> rewritten so the logon 3270 screen no longer said "for business use
> only" to "for management approved uses only" (which included demo
> programs). In show down, demo programs were upheld.

When our aforementioned Univac was installed, it came with some "demo"
programs (games). I gave a co-worker a demonstration of them.
Management was furious that I did so saying I violated security and
confidentiality policy. But, there was nothing loaded on the machine,
and, the person I gave the demo to was the user who would be working
on the planned application, so he had clearance, and none of the data
was confidential anyway. I did not miss working there and was glad to
move on.

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

On Apr 14, 8:39 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> I'll never forget the load "honk" when the things loaded a tape.  My
> original acquaintance with tape was 2415s.  Unfortunately, one of the
> first times I saw a 2480 it loaded a tape and the take-up reel came off.

Oh yes, the honk.

On my first time on a 'real' tape drive, I thought it was in fast
forward mode, but it was just reading the tape at its normal speed.
My 2415 tapes were 1600 bpi, but the real machine was 6250.

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

On Apr 14, 11:53 am, sc...@slp53.sl.home (Scott Lurndal) wrote:

> Of course, the medical packages aren't as comprehensive as they were
> in the 70's and 80's, but then there was no such thing as a stent,
> nor were there Magnetic Resonance Imaging, Computed Tomography,
> Laproscopic surgery, angioplasty and bypass surgery was just becoming
> possible.   And the scumbag lawyers weren't allowed to advertise
> (just watch overnight cable channels for the incessant lawyer advertising
> drug and asbestos lawsuits).  And drug companies weren't allowed to
> advertise, either.

Daytime TV ads by lawyers are pretty horrendus, too.

Drug companies always advertised, but I think their old ads (the ones
I've seen at least) were more general promoting the company overall as
opposed to specific drugs. For decades they pushed their stuff on
doctors and hospitals and pharmacists and had treats for them.

Drug companies aggressively advertised over-the-counter products.

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

On Apr 14, 12:48 pm, Jim Haynes <jhay...@alumni.uark.edu> wrote:

> And, to bring the topic back to the B5500...now my experience with that
> machine was in its twilight years, but it was still a lot of fun.  And
> what seemed to me was that the B5500 was designed so you could get your
> work done, wherease the IBM 360 was designed for the "control freak"
> who wanted to specify exactly where everything was done.  Just comparing
> the job control language - with Burroughs you just said what you wanted
> it to do and that was that.  With IBM you had to tell it to execute the
> compiler, and you had to specify where all the disk space was coming from
> and how it was arranged, etc.  Of course the removable disk packs of IBM
> came at a high price in complexity compared with the non-removable disk
> storage of the B5500.  As did using the overlaying loader of the IBM
> versus the automatic overlaying of the Burroughs.  And the Burroughs
> protection against exceeding array bounds - now today it seems like our
> #1 problem is buffer overflowing.

I believe Mr. Brooks, the author of IBM OS JCL, himself said it was a
lousy approach.

I believe the purpose of IBM JCL was to provide great flexibility, and
this was important in large organizations with complex systems. One
important feature was device independence from the application
program--you did not have to recompile your program to change I/O
devices. Many shops have multiple types of tapes and disks, and of
course over time upgraded these units. In some cases only JCL had to
be changed, but JCL could refer to generic devices (eg "DISK") instead
of "3330", so JCL changes wouldn't even be needed, and of course no
program changes--even when the machine itself was changed.

There were other features like PROCs which were useful in punched card
days, though still useful today.

Admittedly JCL had a lot of esoteric features most people never heard
of or used.

[Scott Lurndal]

hanc...@bbs.cpcn.com writes:

>On Apr 14, 12:48=A0pm, Jim Haynes <jhay...@alumni.uark.edu> wrote:
>
>> And, to bring the topic back to the B5500...now my experience with that

>> machine was in its twilight years, but it was still a lot of fun. =A0And

>> what seemed to me was that the B5500 was designed so you could get your
>> work done, wherease the IBM 360 was designed for the "control freak"

>> who wanted to specify exactly where everything was done. =A0Just comparin=

>g
>> the job control language - with Burroughs you just said what you wanted

>> it to do and that was that. =A0With IBM you had to tell it to execute the

>> compiler, and you had to specify where all the disk space was coming from

>> and how it was arranged, etc. =A0Of course the removable disk packs of IB=

>M
>> came at a high price in complexity compared with the non-removable disk

>> storage of the B5500. =A0As did using the overlaying loader of the IBM
>> versus the automatic overlaying of the Burroughs. =A0And the Burroughs

>> protection against exceeding array bounds - now today it seems like our
>> #1 problem is buffer overflowing.
>
>I believe Mr. Brooks, the author of IBM OS JCL, himself said it was a
>lousy approach.
>
>I believe the purpose of IBM JCL was to provide great flexibility, and
>this was important in large organizations with complex systems. One
>important feature was device independence from the application
>program--you did not have to recompile your program to change I/O
>devices.

All the burroughs systems had this from day one. The program would
open a tape file and the operator would assign it to the correct
device (for output). For input, the MCP would read the tape label
and automatically assign the tape to the program when it opened
the tape file. If the tape wasn't ready, the program would go
into a waiting state and when the tape was ready, the MCP would
reinstate the program with the drive assigned to the program until
the program closed the tape file.

This also worked for printers and card readers (and psuedo-card readers
which were card decks spooled to disk in advance of need).

scott

[Joe Morris]

"Jim Haynes" <jha...@alumni.uark.edu> wrote:

> wherease the IBM 360 was designed for the "control freak"
> who wanted to specify exactly where everything was done. Just comparing
> the job control language - with Burroughs you just said what you wanted
> it to do and that was that. With IBM you had to tell it to execute the
> compiler, and you had to specify where all the disk space was coming from
> and how it was arranged, etc.

Not necessarily, although you could do that if you wanted to. Under OS/360
a competently configured system included "cataloged procedures" -
essentially JCL macros. You want to compile, link, and run a FORTRAN
program? Let's see if I can recall a sample JCL stream:

//SAMPLE JOB <accounting info>
//DEMO EXEC FORTGCLG
//FORT.SYSIN DD *
PRINT 10
10 FORMAT ("1HELLO, WORLD")
STOP
END
/*

Even if you don't invoke a cataloged procedure (here, FORTGCLG; FORTran
level G Compile, Link, and Go) you could ask for generic resources (example:
any available disk space UNIT=SYSDA) so that in most cases you described
your resource in generic terms and let the system figure out where to put
it. You could, however, be quite specific if necessary, and use
device-dependent settings for optimization.

Nobody ever described JCL as "user-friendly."

Joe

[Peter Flass]

On 4/14/2012 9:17 PM, hanc...@bbs.cpcn.com wrote:
>
> I believe the purpose of IBM JCL was to provide great flexibility, and
> this was important in large organizations with complex systems. One
> important feature was device independence from the application
> program--you did not have to recompile your program to change I/O
> devices. Many shops have multiple types of tapes and disks, and of
> course over time upgraded these units. In some cases only JCL had to
> be changed, but JCL could refer to generic devices (eg "DISK") instead
> of "3330", so JCL changes wouldn't even be needed, and of course no
> program changes--even when the machine itself was changed.

Burroughs MCP was a lot more device-independent right out of the box.
As I recall, though it's been a couple of years, the (COBOL) program
specified DISK, TAPE, CARD-READER, etc., but there was some sort of JCL
- not called that and very rarely used - that could change the assignment.

>
> Admittedly JCL had a lot of esoteric features most people never heard
> of or used.
>

As someone said, if you were a control freak you loved it. I was, and I
at least liked it.

--
Pete

[Peter Flass]

On 4/15/2012 8:11 AM, Joe Morris wrote:
>
> Nobody ever described JCL as "user-friendly."
>

I was thinking of this, for some reason, and my mind drifted to DOS/360
JCL [DLBL], and also such competitors as UNIVAC [@ASGN, IIRC], whose JCL
used a lot of positional parameters, as opposed to OS's mostly-keyword
approach. You'd have to code such abominations as (made-up exammple)
"!ASSIGN INPUT,TAPE,,,,,REWIND",
and dog help you if you miscounted the commas. OS had some traces to
this in, for example, the UNIT parameter where you might need to say
"UNIT=(,RETAIN)" but fortunately it was mostly keywords. There was one
parameter which I don't recall just now where I had to code, I think,
three commas.


--
Pete

[Paul Kimpel]

It is. Except on the Unisys MCP machines that are descendants of the
B5500 which do a considerably better job than the B5500 of bounds
protection. They also do overlay essentially the same way as the B5500
did, but there's so much physical memory on most systems today that it
hardly matters.

[jmfbahciv]

Sounds like an UNLOAD and then remounting the tape would be faster.

/BAH

[Joe Morris]

"jmfbahciv" <See....@aol.com> wrote

It would in theory, but that might result in an operations nightmare:

* Scratch tapes are expected to be up, at load point, and in ready status at
the start of each job. Assuming a batch-processing environment, if a job
issues a RUN instead of a REW to the tape drive and then terminates, the
next job (and thus the entire computer) may have to sit idle while the
operator remounts the tape - all the time with the billable clock running at
several hundred dollars per wallclock hour. The same comment applies to a
private tape. This assumes that there's an operator watching the system
closely, which in many shops wasn't a valid assumption. [*]

* A job is generally expected to use RUN only when it's finished using a
private tape, so in the absence of special instructions on the job ticket
(and special instructions in some shops would cause a job to be put into an
overnight schedule instead of "next SYSIN tape) when a private tape is
unloaded the operator might normally remove it from the drive and return it
to the tape library. If the tape is needed in the same job then you're back
to the very expensive wasted time problem.

[*] The 7040 hardware mod I mentioned in a recent posting was designed to
address this: it was connected to the instruction decoder circuits, and rang
a bell every time a halt instruction was encountered, thus calling attention
to the need for an operator's attention. For some reason I never got arount
to investigating, the IBM linear programming program (IBLP40) would trigger
the bell circuit several times every time it inverted a matrix...

The problem was that the 7330 was incapable of automatically loading the
vacuum columns, and a high-speed rewind can't be performed if the tape is in
the columns. Although I don't recall the numbers, however, the 7330/2415 did
offer a critical advantage to smaller shops over the 729/24xx/34xx drives:
price.

Joe

[Jim Haynes]

On 2012-04-15, Paul Kimpel <paul....@digm.com> wrote:
>
> did, but there's so much physical memory on most systems today that it
> hardly matters.

Yes, elegance went out the window when it became economically feasible to
just throw more memory at every problem.

[Freddy1X]

Stan Barr wrote:

> On Fri, 13 Apr 2012 13:10:26 -0700 (PDT), hanc...@bbs.cpcn.com

( cuts )

>
> I remember playing with a terminal that scanned about 25 lines and
> built the characters by "spot wobbling", is that the sort of thing you
> mean? (Can't remember the make, but I remember reading the technical
> manual to find out how it worked)
>

Early Datapoint terminals and processors used this method. There were 3
sweep coils mounted on the CRT. They were vertical, horizontal, and
dither. Dither added to the vertical deflection enough movement to draw
the height of the characters. V and H were left to position the characters
on the screen. I suspect that it was done in order to reduce the
horizontal sweep frequency and resulting dot bit rate to a level that
available at the tine logic parts could handle. Because of the lower
horizontal rate, they had to use a separate HV power supply, not the usual
one derived from flyback.

Freddy,
running at lower bit rates these days.
--
1.Push in 2.Pull back 3.Tear off.



/|>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\|

/| I may be demented \|

/| but I'm not crazy! \|

/|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<\|

* SPAyM trap: there is no X in my address *

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

On Apr 15, 8:54 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> I was thinking of this, for some reason, and my mind drifted to DOS/360
> JCL [DLBL], and also such competitors as UNIVAC [@ASGN, IIRC], whose JCL
> used a lot of positional parameters, as opposed to OS's mostly-keyword
> approach.  You'd have to code such abominations as (made-up exammple)
> "!ASSIGN INPUT,TAPE,,,,,REWIND",
> and dog help you if you miscounted the commas.  OS had some traces to
> this in, for example, the UNIT parameter where you might need to say
> "UNIT=(,RETAIN)" but fortunately it was mostly keywords. There was one
> parameter which I don't recall just now where I had to code, I think,
> three commas.

There were a few relatively common uses of OS JCL where there were a
few commas, but I forgot what. In essence, it was actually a shortcut
in that you did not have to code the parameter if you didn't need it,
and just used a comma to mark its place. (Maybe it was when there
were multiple files on a tape reel, which, IIRC, was a pain.)

OS could get tricky for the inexperienced to remember all the keywords
and where they properly belonged. For instance, in creating a new
file:

//FILEOUT DD DSN=NEWFILE,DISP=(NEW,CATLG,DELETE),
// UNIT=DISK,SPACE=(CYL,(50,10),RLSE),
// DCB=(RECFM=FB,BLKSIZE=0,LRECL=256)

As an example of OS JCL's flexibility, the SPACE parameter above could
be simpler or more complex. Above I defined my units in Cylinders,
with a start of 50 and an extension of 10, and to release unused
space. There were more optins.


DOS JCL was much simpler than OS JCL but it wasn't device
independent. In DOS, the COBOL programmer specified things like the
block size and unit type in the program, while in OS they were
specified in JCL. This allowed I/O units t o be shifted around as
needed without recompiling the program.

Of course, DOS shops tended to have smaller configurations, perhaps
just one printer and card reader, one kind of disk drive and tape
drive, so there was less need for flexibility.

There were third-party PROCS (macros) for DOS.

I don't remember Univac 90/30 JCL except that it was still device
dependent like 360-DOS, but still more flexible and had spooling built
in.

I also remember that while our Univac had up to five partians to run
jobs, running more than one at a time usually ran very slow due to
disk head contention. That is, it would've been faster to run two
jobs back to back than both at the same time. The disk drive would
shake like a washing machine handling a pair of heavy jeans.

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

On Apr 15, 10:38 am, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> * Scratch tapes are expected to be up, at load point, and in ready status at
> the start of each job.  Assuming a batch-processing environment, if a job
> issues a RUN instead of a REW to the tape drive and then terminates, the
> next job (and thus the entire computer) may have to sit idle while the
> operator remounts the tape - all the time with the billable clock running at
> several hundred dollars per wallclock hour.  The same comment applies to a
> private tape.  This assumes that there's an operator watching the system
> closely, which in many shops wasn't a valid assumption. [*]

For OS 360 there were numerous JCL options for tapes to keep things
fluid and efficient. Often a tape would be used for subsequent job
steps, so it was desired to only rewind the tape but not unload it,
otherwise the operator had an unnecessary remount to do. Sometimes
tapes were used on subsequent jobs, too.

Indeed, in the early days of disks 3330s were demountable and they had
to be handled as well.

Today tape cartridges are kept in automatic silos and disks are
permanently mounted. As others mentioned, the ton of cheap core and
tape/disk memory has changed how we do things.

[Harry Vaderchi]

And Battelzone - now available as a flash game!
http://www.atari.com/arcade/arcade/battlezone
--
[dash dash space newline 4line sig]

Albi CNU

[Harry Vaderchi]

But it was horrible to code conditional steps it all depended on reverse
returncode checking IIRC.

[Joe Morris]

"Stephen Fuld" <SF...@alumni.cmu.edu.invalid> wrote:
> hanc...@bbs.cpcn.com wrote:

>> the console screen was an older model than the other screens.
>> I think they used different technologies to "paint" the data on the
>> screen.

>
> Yes, They were vector displays. Each character was a set of "vectors",
> i.e. lines with a start point a length and a direction. This technology

> was frequently used for graphics terminals in those days. Just another
> example (along with Drum storage, and relevant to this thread, drum

> printers) where Univac backed the wrong technology.

I don't recall that the PDP-1 display had any hardware glyph generation
ability; if you want to display text you figured out the vectors necessary
and painted them.

Caveat: my PDP-1 programming never used involved the CRT and I can't recall
where I last stashed the PDP-1 hardware documentation so I'm relying on my
(non-parity-checked) memory. I did use the tube (running, for example, Pete
Sampson's Expensive Typewriter and, of course, Spacewar) but never had a
need (or time) to learn how to best use the "Precision Display" to display
text.

Joe

[Dan Espen]

Yep, and one more that got really popular and used color...
Okay, found it. Tempest.

--
Dan Espen

[Joe keane]

In article <jm6j2d$al0$1...@dont-email.me>,
Peter Flass <Peter...@Yahoo.com> wrote:
>My theory is that the 1403 printer is solely responsible for IBM's
>success.

I think printers are the most boggling part of 1960s technology.

Building a CPU from transistors is impressive, although ultimately a
matter of time and patience [and if someone is paying you ~$1M per unit
you can have both].

Mag tapes are impressive. Hard drives are impressive.

The printers are more like 'How the ---- did you guys do that???!!!'.

I mean the output is literally shooting into the air at several pages
per second...

[Walter Bushell]

In article <jmfos5$ios$1...@reader1.panix.com>,

j...@panix.com (Joe keane) wrote:

> In article <jm6j2d$al0$1...@dont-email.me>,
> Peter Flass <Peter...@Yahoo.com> wrote:
> >My theory is that the 1403 printer is solely responsible for IBM's
> >success.
>
> I think printers are the most boggling part of 1960s technology.

Wrapping wires around tiny metallic doughnuts is impressive like 36
times 2^15-> 1.179648E+6.

>
> Building a CPU from transistors is impressive, although ultimately a
> matter of time and patience [and if someone is paying you ~$1M per unit
> you can have both].
>
> Mag tapes are impressive. Hard drives are impressive.
>
> The printers are more like 'How the ---- did you guys do that???!!!'.
>
> I mean the output is literally shooting into the air at several pages
> per second...

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

On Apr 15, 8:24 pm, j...@panix.com (Joe keane) wrote:

> I think printers are the most boggling part of 1960s technology. . . .

> I mean the output is literally shooting into the air at several pages
> per second...

Oh yes.

I remember watching a job run on our non-spooled S/360-40. The 1,000
card per minute reader was flying away along with the1,000 line/minute
printer. A card would be read, a variety of calculations performed,
and the output printed. Watching this run was just amazing. And--
jobs like this without spooling were actually wasteful--they didn't
even use much CPU! (On S/360 we had a CPU/wait status lamp we could
watch, it was dark when work was being done.)


As mentioned separately, the tapes and printer were a big part of that
old movie. Though the CRT played a role--it kept saying "ILLEGAL
PROCEDURE".

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

On Apr 15, 4:46 pm, "Harry Vaderchi" <ad...@127.0.0.1> wrote:

> But it was horrible to code conditional steps it all depended on reverse
> returncode checking IIRC.

Yes, the "COND=(0,NE)" clause is confusing as heck. One can do all
sorts of things with it--testing for a specific return code in a
specific jobstep, or LT/GT tests. The above reference is commonly
used, meaning run the step if there were no problems previously.

[Joe Morris]

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

>I remember watching a job run on our non-spooled S/360-40. The 1,000
>card per minute reader was flying away along with the1,000 line/minute
>printer. A card would be read, a variety of calculations performed,
>and the output printed. Watching this run was just amazing. And--
>jobs like this without spooling were actually wasteful--they didn't
>even use much CPU! (On S/360 we had a CPU/wait status lamp we could
>watch, it was dark when work was being done.)

Um...are you sure you're interpreting the indicators correctly? The S/360
line (with the possible exception of the /20 and /44, which I never used)
had the same design for the "Operator Control Panel", which occupied the
lower right corner of the system control panel.

The OCP contained four buttons, five lights, and three rotary switches.

The rotary switches selected the IPL (boot) device address.

The buttons were
Power On
Power Off
Interrupt
IPL

and, more applicable to this thread, the lights were [*]

SYSTEM (the CPU meter is running
MANUAL (CPU stopped)
WAIT (The current PSW has the WAIT bit set)
TEST (CE switches are not in normal position)
LOAD (IPL in progress)

So...the "Wait" light being dark implies 100% CPU utilization. Admittedly,
even though I used a /40 for many years I can't recall whether any of the
rollers provided an inverse indication of CPU wait state.

Some shops removed the lamp from the WAIT light holder and plugged in a
mechanical voltmeter. The mechanical movement provided a reading of the
average duty cycle, so the operator could get a numerical value of the CPU
utilization.

[*] Sigh. It's been so long since I worked with an S/360 that I had to dig
out my old S/360/65 FETOM to make sure I had the lamp list and definitions
correct.

Joe

[Peter Flass]

On 4/15/2012 1:37 PM, hanc...@bbs.cpcn.com wrote:
>
> For OS 360 there were numerous JCL options for tapes to keep things
> fluid and efficient. Often a tape would be used for subsequent job
> steps, so it was desired to only rewind the tape but not unload it,
> otherwise the operator had an unnecessary remount to do.

Assuming the operator was there and paying attention, not on the john,
talking to his girlfriend on the phone, or out getting "lunch" at 3:00am.

--
Pete

[Peter Flass]

On 4/15/2012 5:21 PM, Joe Morris wrote:
> "Stephen Fuld"<SF...@alumni.cmu.edu.invalid> wrote:
>> hanc...@bbs.cpcn.com wrote:
>
>>> the console screen was an older model than the other screens.
>>> I think they used different technologies to "paint" the data on the
>>> screen.
>>
>> Yes, They were vector displays. Each character was a set of "vectors",
>> i.e. lines with a start point a length and a direction. This technology
>> was frequently used for graphics terminals in those days. Just another
>> example (along with Drum storage, and relevant to this thread, drum
>> printers) where Univac backed the wrong technology.
>
> I don't recall that the PDP-1 display had any hardware glyph generation
> ability; if you want to display text you figured out the vectors necessary
> and painted them.
>

Only some 2250's had this. I believe originally it was "do it
yourself", and the character generator was an option.

--
Pete

[Peter Flass]

On 4/15/2012 8:54 PM, Walter Bushell wrote:
> In article<jmfos5$ios$1...@reader1.panix.com>,
> j...@panix.com (Joe keane) wrote:
>
>> In article<jm6j2d$al0$1...@dont-email.me>,
>> Peter Flass<Peter...@Yahoo.com> wrote:
>>> My theory is that the 1403 printer is solely responsible for IBM's
>>> success.
>>
>> I think printers are the most boggling part of 1960s technology.
>
> Wrapping wires around tiny metallic doughnuts is impressive like 36
> times 2^15-> 1.179648E+6.

Originally it was all done by hand. If you're talking core and not
transformers, I don't think the wires were "wrapped." I think they were
threaded thru left, right, and diagonally, so women with small hands and
sewing skills would have been good at it.


--
Pete

[Anne & Lynn Wheeler]

hanc...@bbs.cpcn.com writes:
> I remember watching a job run on our non-spooled S/360-40. The 1,000
> card per minute reader was flying away along with the1,000 line/minute
> printer. A card would be read, a variety of calculations performed,
> and the output printed. Watching this run was just amazing. And--
> jobs like this without spooling were actually wasteful--they didn't
> even use much CPU! (On S/360 we had a CPU/wait status lamp we could
> watch, it was dark when work was being done.)

recent post about "system meter" ... 360s being leased and there was
base 1st shift (8hrs/work-day) charge per month ... up to running
constantly ... based on the system meter. the system meter ran whenever
the processor and/or channels were active.
http://www.garlic.com/~lynn/2012e.html#83 Why are organizations sticking with mainframes

one of the challenges for cp67 providing 7x24 online access was leaving
the system up ... but allowing the system meter to come to stop ... even
with channels "preped" for incoming terminal input. objective was to try
and cover costs of operation by use charges ... but early non-1st shift
use very limited. very chicken&egg ... needed offshift use to justify
leaving machine up 7x24 ... but couldn't have large lease charges when
system wasn't being used.

used "PREPARE" channel command word ... which would allow channel to go
idle ... but the controller was still be waiting for terminal input and
then signal channel to start transferring data. this allowed the system
to be up&running and available for work ... but the system meter not
running when there wasn't actual activity.

one of the issues was that the system meter could "coast" for 400millis
before actual coming to stop ... so both processor and channels (I/O)
had to be idle for more than 400millis.

misc. past posts about virtual machine based online time-sharing ...
including some of the issues being able to provide 7x24
http://www.garlic.com/~lynn/submain.html#timeshare

i've previously mentioned that patterns of (roller) lights on 360/30 ...
could recognize when it was handling DCB macro ... very solid that was
different than more varied/random pattern when it was doing other
stutff.
http://www.garlic.com/~lynn/2012e.html#98 Burroughs B5000, B5500, B6500 videos

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

[Walter Bushell]

In article <jmh0dc$snf$3...@dont-email.me>,

Peter Flass <Peter...@Yahoo.com> wrote:

> On 4/15/2012 8:54 PM, Walter Bushell wrote:
> > In article<jmfos5$ios$1...@reader1.panix.com>,
> > j...@panix.com (Joe keane) wrote:
> >
> >> In article<jm6j2d$al0$1...@dont-email.me>,
> >> Peter Flass<Peter...@Yahoo.com> wrote:
> >>> My theory is that the 1403 printer is solely responsible for IBM's
> >>> success.
> >>
> >> I think printers are the most boggling part of 1960s technology.
> >
> > Wrapping wires around tiny metallic doughnuts is impressive like 36
> > times 2^15-> 1.179648E+6.
>
> Originally it was all done by hand. If you're talking core and not
> transformers, I don't think the wires were "wrapped." I think they were
> threaded thru left, right, and diagonally, so women with small hands and
> sewing skills would have been good at it.

Doing it by hand was the impressive part, for me at least.

[David Dyer-Bennet]

hanc...@bbs.cpcn.com writes:

> On Apr 13, 4:37 pm, David Dyer-Bennet <d...@dd-b.net> wrote:
>
>> My very first job, at a very small IBM shop (nearly all the programmers
>> were part-time students; I was hired while I was still in highschool, 15
>> yeras old), my first assignment was "go talk to the director of
>> admissions, find out what he wants in this cross-tabulating counting
>> program, and write it."  I only learned the job title "programmer
>> analyst" some time later.
>
> I used to think those days and opportunities were gone forever, but I
> heard of two guys who got jobs in a small outfit where they do pretty
> much everything. Of course, in today's world both guys were
> experienced, not at all kids. (One guy was grateful to have any job
> since he was out of work.)

Two people did the first 6 years of software at my current company.
Also both experienced.

> I do think kids coming out of school today will have it _harder_ than
> those who graduated in the 1970s. IMHO, there are fewer jobs,
> companies are fussier, and salaries and benefits crappy.

Depends what school, what degree, what kind of job. A friend never did
quite finish his final degree, worked at one startup that was later
bought by Sun, worked at Sun for a while, and is now a founder at a new
startup.
--
David Dyer-Bennet, dd...@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

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

On Apr 16, 7:40 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> Originally it was all done by hand.  If you're talking core and not
> transformers, I don't think the wires were "wrapped."  I think they were
> threaded thru left, right, and diagonally, so women with small hands and
> sewing skills would have been good at it.

IBM developed core threading machines. I'm not sure if this was the
late 1950s or early 1960s, but IBM's demand for cores was so great
that they contracted work out to Asia to have it done by hands. They
found the productivity as good as their machines.

In our gigabyte and terabyte world, could you imagine how much core
would we need to support it? We'd have school kids doing it all day.

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

On Apr 16, 7:35 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> > For OS 360 there were numerous JCL options for tapes to keep things
> > fluid and efficient.  Often a tape would be used for subsequent job
> > steps, so it was desired to only rewind the tape but not unload it,
> > otherwise the operator had an unnecessary remount to do.
>
> Assuming the operator was there and paying attention, not on the john,
> talking to his girlfriend on the phone, or out getting "lunch" at 3:00am.

Our 370 MVS (360-OS) years ago required a number of operators:
--console operator
--tape mounter
--printer tender
--disk mounter
--online CICS network calls

Various job mixes required varying degrees of attention, and a shift
was planned accordingly. Perhaps two guys would be handling tapes for
some runs, then two guys handling the printers for other runs. Then,
if some piece of equipment was down, things had to be juggled.

In addition, there was a tape library and staff.

IIRC, when cartridges came out, there were compact enough to be stored
within the computer room, yet held more data eliminating files that
went on multiple reels. They also didn't need cleaning or other
servicing that tapes sometimes required. We also had an automated
tape management system. (The DOS shop kept tape records in a
looseleaf book.)

[Jim Haynes]

But then IBM did it by machine, turning memory into a price umbrella
the competitors couldn't match. We tend to be in awe of IBM's sales
ability, but their manufacturing engineering was mighty impressive too.

[Peter Flass]

On 4/16/2012 9:44 AM, Walter Bushell wrote:
> In article<jmh0dc$snf$3...@dont-email.me>,

Pugh says IBM invented the threading machines when they started to fall
behind on core for the 360.

--
Pete

[Charlie Gibbs]

In article <jmaf9...@news1.newsguy.com>, j.c.m...@verizon.net
(Joe Morris) writes:

> Of course, not all branches worked that way. At my current POE (which
> ceased using IBM equipment almost 20 years ago) one night we had a
> failure of the floppy reader in a 3880, and the IBM dispatcher was
> absolutely floored when I gave her the FRU number that the CE would
> need to bring...apparently she had no clue that a mere customer could
> figure that out...

A timing belt on our card reader broke. Before calling it in I dug
out the maintenance manual from the CE cabinet, found the illustrated
parts breakdown, and looked up the replacement part number. When I
called the CE department and reported a broken belt, I almost heard
a sigh as the person on the other end prepared to begin the game of
"twenty questions" in an attempt to determine which belt was broken.
You could hear his face light up over the phone as I read him the
part number.

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

[Charlie Gibbs]

In article
<184c4a6b-f543-4b73...@i2g2000vbd.googlegroups.com>,

hanc...@bbs.cpcn.com (hancock4) writes:

> I don't remember Univac 90/30 JCL except that it was still device
> dependent like 360-DOS, but still more flexible and had spooling
> built in.

Toward the end I started including code in my programs that probed
the system, determined what kind of device it was attached to, and
selected appropriate code to deal with it. For sequential files,
you could have the JCL point to a card, tape, or disc unit and my
program would quite happily run. Highly non-standard, but fun when
showing what some good hacking can do.

> I also remember that while our Univac had up to five partians to run
> jobs, running more than one at a time usually ran very slow due to
> disk head contention. That is, it would've been faster to run two
> jobs back to back than both at the same time. The disk drive would
> shake like a washing machine handling a pair of heavy jeans.

With the job mixes we had, I found the point of diminishing returns
was three concurrent jobs. But I tried to program a good mix of
I/O and CPU usage.

Speaking of CPU usage, one of OS/3's weaknesses was that it didn't
time-slice jobs of equal priority. If you ran a CPU-bound program,
all other jobs of equal or lower priority waited for your program
to relinquish control (e.g. by waiting for I/O). This wasn't
considered a big thing, probably because most commercial programs
are I/O-bound - but things like large sorts would throw a wrench
in the works. It did, however, make it easy to spot when your
program went into a loop.

One shop got quite psychotic at payroll time. (Yes, a lot of them
do, but these guys were special.) Whenever the payroll was running,
the operator would kick the payroll program up to top priority -
even if nothing else was running - in the belief that this would
somehow make it run faster. One day I was copying a large file to
tape. It was a straight copy with neglegible CPU usage, and the
drive was running flat-out. A payroll program was using the other
tape drive, and it was so CPU-bound that it would only write one
block every 5 seconds or so. When the operator raised the payroll
program's priority, my tape drive ground to a halt. The payroll
program's tape drive, on the other hand, continued to write one
block every 5 seconds. Whenever the operator's back was turned
I'd reduce the payroll program's priority to normal - my tape copy
would take off, while the payroll program continued running at the
same speed, eagerly drinking up every available CPU cycle. (Why
this program was so CPU-bound is another topic for another time.)

[Charlie Gibbs]

In article <9utiru...@mid.individual.net>, pla...@dsl.pipex.com

(Stan Barr) writes:

> I remember playing with a terminal that scanned about 25 lines and
> built the characters by "spot wobbling", is that the sort of thing you
> mean? (Can't remember the make, but I remember reading the technical
> manual to find out how it worked)

While browsing through the library stacks in my university days,
I recall coming across a magazine article describing a character
display that a group hacked together. They worked out the movements
required to draw various characters, ran Fourier analysis on the
waveforms, and started winding coils for filters and building
circuitry to wobble an electron beam as required. The prototype
apparently filled a floor-standing cabinet.

[Charlie Gibbs]

In article
<b32efd2e-d369-41c2...@w5g2000vbp.googlegroups.com>,

hanc...@bbs.cpcn.com (hancock4) writes:

> I believe the purpose of IBM JCL was to provide great flexibility,

I always said that the purpose of JCL was to give you something to
debug once you got your program working.

[Charlie Gibbs]

In article <jmbr13$7a8$1...@dont-email.me>, Peter...@Yahoo.com
(Peter Flass) writes:

> On 4/13/2012 10:55 PM, hanc...@bbs.cpcn.com wrote:
>
>> On Apr 13, 9:17 pm, "Charlie Gibbs"<cgi...@kltpzyxm.invalid> wrote:
>>
>> Thanks for the Uniscope information. I was curious as to how they
>> worked.
>>
>>>> Anyone of any idea of how many Univac 90/xx series they sold?
>>>
>>> A lot. They were all over Vancouver in the early '80s; I worked
>>> at a couple of sites that had them, and when I was working for
>>> Sperry I visited most of the local sites. My job consisted mostly
>>> of converting customers from 9300 and 9400 systems to the 90/30
>>> (and later the System 80).

>I've been meaning to ask, was the 90/ series the old RCA Spectra-70?

Yes and no. The 90/60 and 90/70 evolved from the RCA machines; they
ran VS/9, which was based on RCA's VMOS. The 90/30 (and its siblings
90/25 and 90/40) had no connection to the RCA line; they evolved
from the 9300 and 9400 and ran OS/3, which was developed at Univac.

[Charlie Gibbs]

In article
<1a34dacb-bd70-4639...@z38g2000vbu.googlegroups.com>,
hanc...@bbs.cpcn.com (hancock4) writes:

> I don't know what RPG version they used. On IBM's S/3x series, they
> upgraded RPG and got away from using the built-in "cycle"--RPG IV was
> totally different than the RPG used in the old days. Today they have
> Visual RPG, but I know nothing about it.

One of my nightmare conversions was from an IBM S/3x to a System 80.
The programs - ostensibly RPG - were 3000-line monsters that worked
with interactive terminals; we had to make them run under Sperry's
equivalent of CICS. Mercifully, I've forgotten most of the details -
but I never stopped saying that one of IBM's problems was that they
forgot what RPG stands for.

[Charles Richmond]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote in message
news:1023.524T4...@kltpzyxm.invalid...

> In article <9utiru...@mid.individual.net>, pla...@dsl.pipex.com
> (Stan Barr) writes:
>
>> I remember playing with a terminal that scanned about 25 lines and
>> built the characters by "spot wobbling", is that the sort of thing you
>> mean? (Can't remember the make, but I remember reading the technical
>> manual to find out how it worked)
>
> While browsing through the library stacks in my university days,
> I recall coming across a magazine article describing a character
> display that a group hacked together. They worked out the movements
> required to draw various characters, ran Fourier analysis on the
> waveforms, and started winding coils for filters and building
> circuitry to wobble an electron beam as required. The prototype
> apparently filled a floor-standing cabinet.
>

This sounds like the hardware equivalent of True Type fonts... where each
character is created from a mathematical description. There's *no* fixed
bit map, so when the character is scaled up, you don't get the jaggies. And
when the character is scaled down, the shape can be altered slightly to make
it more readable.


--
+<><><><><><><><><><><><><><><><><><><>+
| Charles Richmond nume...@aquaporin4.com |
+<><><><><><><><><><><><><><><><><><><>+

[Rich Alderson]

"Charles Richmond" <net...@aquaporin4.com> writes:

> This sounds like the hardware equivalent of True Type fonts... where each
> character is created from a mathematical description. There's *no* fixed
> bit map, so when the character is scaled up, you don't get the jaggies. And
> when the character is scaled down, the shape can be altered slightly to make
> it more readable.

Adobe Type 1 ("Postscript") fonts as well. The difference between T1 and TT
is in the use of cubic vs. quadratic beziers, respectively.

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

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

On Apr 16, 2:29 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:

> One of my nightmare conversions was from an IBM S/3x to a System 80.
> The programs - ostensibly RPG - were 3000-line monsters that worked
> with interactive terminals; we had to make them run under Sperry's
> equivalent of CICS.  Mercifully, I've forgotten most of the details -
> but I never stopped saying that one of IBM's problems was that they
> forgot what RPG stands for.

That would've been quite horrendous. The RPG for the S/3x series was
very different than old RPG; I think by that point they abandoned the
built in 'cycle' and pretty much did everything by C statements. I
believe the on-line processing of the S/3x was very different than the
mainframe CICS world--a lot simpler. Unless the Univac RPG evolved at
the same time in the same way as S/3X RPG, I can't imagine how the
conversion would've been completed, other than by basically rewriting
all the programs from scratch.

Modern versions of RPG appear to have worked out very well in the AS/
400 (mid-range) world. I am not an RPG nor mid-range fan, but it does
seem IBM did it right.


When I worked at that Univac shop (90/30) they were heading toward on-
line applications via COBOL. We were sent to Univac for training, but
the stuff was a total mystery. It was much more low level than CICS
was at that time and very cumbersome. My co-worker, who was the point
man on it, struggled just to get an "Hello World" trial application
out to a screen. I left that job shortly thereafter.

Even though we were out at Blue Bell HQ, Univac wasn't very well
organized in coordinating machine time with classroom time. We also
had to unexpectedly go to two different locations and also go in the
evening which was cumbersome; and we didn't know about it in advance
(which caused a problem for some of the students who had family
responsibilities). IIRC, I didn't think the instructors were very
good, but maybe that was me.

Not too much longer after I left that employer they got in another
machine (Burroughs?). The people I worked with all left, too, so I
don't know how applications were handled or if another conversion was
required.

I have no memory of what the 90/30's equivalent package was for CICS,
but I wonder if bitsavers has any manuals on it. I'm just curious as
to what I was supposedly learning.


Speaking of conversions--at the above shop I was assigned a 4,000 line
COBOL program to be converted to our machine. COBOL is COBOL, right?
Nope. The 90/30 was a byte oriented machine following IBM S/360
design. That meant two critical details: a numeric field could not
have a space in it, and, a carriage control character was required for
print lines. That program had a great many WRITE statements and print
lines to be reformmatted and changes--something I assumed would be
easy turned out to be tough. The program also routinely assigned and
tested for spaces as a valid value in numeric fields, and all those
had to be changed as well. When there's 4,000 lines of that mess,
it's not so easy. The manager, who had no S/360 experience, didn't
understand the challenge.

Like I said, I didn't like working there.

[David Dyer-Bennet]

Rich Alderson <ne...@alderson.users.panix.com> writes:

> "Charles Richmond" <net...@aquaporin4.com> writes:
>
>> This sounds like the hardware equivalent of True Type fonts... where each
>> character is created from a mathematical description. There's *no* fixed
>> bit map, so when the character is scaled up, you don't get the jaggies. And
>> when the character is scaled down, the shape can be altered slightly to make
>> it more readable.
>
> Adobe Type 1 ("Postscript") fonts as well. The difference between T1 and TT
> is in the use of cubic vs. quadratic beziers, respectively.

Oh, there really is a basic difference at the core? Interesting.
(Obviously there are innumerable detail differences around the edges,
too.)

[Charlie Gibbs]

In article
<27455114-a55c-4c41...@r13g2000vbg.googlegroups.com>,

hanc...@bbs.cpcn.com (hancock4) writes:

> On Apr 16, 2:29 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>
>> One of my nightmare conversions was from an IBM S/3x to a System 80.
>> The programs - ostensibly RPG - were 3000-line monsters that worked
>> with interactive terminals; we had to make them run under Sperry's
>> equivalent of CICS.  Mercifully, I've forgotten most of the details -
>> but I never stopped saying that one of IBM's problems was that they
>> forgot what RPG stands for.
>
> That would've been quite horrendous. The RPG for the S/3x series was
> very different than old RPG; I think by that point they abandoned the
> built in 'cycle' and pretty much did everything by C statements. I
> believe the on-line processing of the S/3x was very different than the
> mainframe CICS world--a lot simpler. Unless the Univac RPG evolved at
> the same time in the same way as S/3X RPG, I can't imagine how the
> conversion would've been completed, other than by basically rewriting
> all the programs from scratch.

I think Univac's RPG had some sort of fill-in-the-blanks forms handler
that interfaced with their equivalent of CICS and preserved most of
RPG's I/O characteristics.

> Modern versions of RPG appear to have worked out very well in the AS/
> 400 (mid-range) world. I am not an RPG nor mid-range fan, but it does
> seem IBM did it right.

Perhaps, but it always sounded like they were trying to force RPG
to do things it really wansn't intended to do. Given my druthers,
I'd write COBOL instead.

> When I worked at that Univac shop (90/30) they were heading toward on-
> line applications via COBOL. We were sent to Univac for training, but
> the stuff was a total mystery. It was much more low level than CICS
> was at that time and very cumbersome. My co-worker, who was the point
> man on it, struggled just to get an "Hello World" trial application
> out to a screen. I left that job shortly thereafter.

He was probably writing directly to the APIs of ICAM (Integrated
Communications Access Method), which varied in nastiness depending
on which of the several incompatible interfaces you used. Then
you had to do an ICAMgen in which you defined the layout of your
terminal network, which portions used which interface, etc. If
your configuration file contained anything but the most egregious
errors, you wouldn't get any diagnostic messages, just an ICAM that
mysteriously failed to work.

Even for those of us were supposedly the local Univac gurus,
the standard procedure for setting up a new site was to copy
a configuration file from an existing site and tweak it as
necessary, rather than daring to create one from scratch.

There was only person I knew of who really understood ICAM (he was
probably the only one in Canada). A couple of times we flew him out
from Montreal to help us with something we just couldn't get to work,
like setting up a bisync interface to an IBM machine. One afternoon,
after he managed to get us going, we were sitting in an office at the
customer's site shooting the bull. While this fellow was carrying on
a conversation with us, he was scrambling and unscrambling a Rubik's
cube. That's the kind of mind it took to understand ICAM.

> Even though we were out at Blue Bell HQ, Univac wasn't very well
> organized in coordinating machine time with classroom time. We also
> had to unexpectedly go to two different locations and also go in the
> evening which was cumbersome; and we didn't know about it in advance
> (which caused a problem for some of the students who had family
> responsibilities). IIRC, I didn't think the instructors were very
> good, but maybe that was me.

Getting machine time was always a problem. I worked a lot of
afternoon shifts at customer sites that normally worked only one
shift; that was the only way we could get time to do conversion
work for a new customer that didn't have their own machine yet.

One day we got a machine at the branch office. It was paradise.
We could do our work - and CEs could test and diagnose hardware -
during office hours without going hat in hand to customers. But
then we hired more salesmen - and the machine was sold and its
room partitioned to make offices for them.

> Not too much longer after I left that employer they got in another
> machine (Burroughs?). The people I worked with all left, too, so I
> don't know how applications were handled or if another conversion was
> required.
>
> I have no memory of what the 90/30's equivalent package was for CICS,
> but I wonder if bitsavers has any manuals on it. I'm just curious as
> to what I was supposedly learning.

It was called IMS/90 (Information Management System for Series 90,
later shortened to simply IMS). But unlike IBM's IMS, it wasn't a
database manager. I remember visiting a friend at an IBM shop and
saw a CICS manual. I started leafing through it and all the terms
looked familiar. That's when I realized how Univac had managed to
come up with such a (ahem) baroque architecture.

I still have a full set of manuals for this stuff - if they aren't
already up on Bitsavers I should really get them scanned and uploaded.

> Speaking of conversions--at the above shop I was assigned a 4,000 line
> COBOL program to be converted to our machine. COBOL is COBOL, right?
> Nope. The 90/30 was a byte oriented machine following IBM S/360
> design. That meant two critical details: a numeric field could not
> have a space in it, and, a carriage control character was required for
> print lines. That program had a great many WRITE statements and print
> lines to be reformmatted and changes--something I assumed would be
> easy turned out to be tough. The program also routinely assigned and
> tested for spaces as a valid value in numeric fields, and all those
> had to be changed as well. When there's 4,000 lines of that mess,
> it's not so easy. The manager, who had no S/360 experience, didn't
> understand the challenge.

Arrgh. For the space-filled numeric fields I'd do something like:
02 NUMFLD-X.
03 NUMFLD PIC 9(5).
and either check NUMFLD-X for spaces, or do arithmetic on NUMFLD.

I don't recall being saddled with carriage control characters.
Maybe that was an option I was able to avoid somehow.

> Like I said, I didn't like working there.

Sometimes the worst thing about such places is if the people there
don't see anything wrong with such programming abominations.

[Joe Morris]

An unnecessary tape mount is still an unnecessary tape mount that occupies
the operator's time when something else might also need attention...and (as
I noted upthread) the billable wallclock time continues to run while the
operator remounts the tape.

And yes, I'll concede that when you're talking about 2400' tapes rewinding
at 15 ips on a (barf) 7330, it might still be less expensive to have the
tape do a high-speed RUN and have the (probably poorly written by the user,
and then misinterpreted by the operator) special instructions tell the
operator to remount it.

The obvious solution: get rid of the 7330s and install *real* tape drives.
The 1401 could attach 729 (200 ips, with high-speed rewind) drives.
Unfortunately, reality, in the form of $$$$, sometimes made the "obvious"
solution a non-starter.

Joe

[Joe Morris]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
> (Joe Morris) writes:

>> Of course, not all branches worked that way. At my current POE (which
>> ceased using IBM equipment almost 20 years ago) one night we had a
>> failure of the floppy reader in a 3880, and the IBM dispatcher was
>> absolutely floored when I gave her the FRU number that the CE would
>> need to bring...apparently she had no clue that a mere customer could
>> figure that out...

> A timing belt on our card reader broke. Before calling it in I dug
> out the maintenance manual from the CE cabinet, found the illustrated
> parts breakdown, and looked up the replacement part number. When I
> called the CE department and reported a broken belt, I almost heard
> a sigh as the person on the other end prepared to begin the game of
> "twenty questions" in an attempt to determine which belt was broken.
> You could hear his face light up over the phone as I read him the
> part number.

One thing a good field engineer - for any line of business - should do is
cultivate the geeks in the customers' staff. Not only does that help
provide the vendor with a friendly contact that might help later sales, but
it also provides the FE staff with an unpaid assistant who can (as in the
above examples) reduce the MTTR.

And sometimes it results in a recruiting lead for the vendor. At my PPOE
one of the sysprogs (who could squeeze more function into 4K of 1401 memory
than anyone I ever met) went to work as an IBM CE - and was, I'm told,
sometimes irritating to the other CEs, because at a large site he would
finish his tasks early, then go over and kibitz the other CEs, offering
suggestions that were usually spot-on. He gained the nickname of
"Super-CE" - and at a BO skit one year wore a sign with that printed on it.
(He's the guy I mentioned upthread who designed a hardware mod for our
7040 - that was before he left to become a CE.)

Joe

[Joe Morris]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:

> One of my nightmare conversions was from an IBM S/3x to a System 80.
> The programs - ostensibly RPG - were 3000-line monsters that worked
> with interactive terminals; we had to make them run under Sperry's
> equivalent of CICS. Mercifully, I've forgotten most of the details -
> but I never stopped saying that one of IBM's problems was that they
> forgot what RPG stands for.

Role-Playing Game? <grin> Or some other words inappropriate for a PG-rated
newsgroup?

Joe

[Ahem A Rivet's Shot]

Rocket Propelled Grenade ?

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

[Ben Pfaff]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> writes:

> One of my nightmare conversions was from an IBM S/3x to a System 80.
> The programs - ostensibly RPG - were 3000-line monsters that worked
> with interactive terminals; we had to make them run under Sperry's
> equivalent of CICS. Mercifully, I've forgotten most of the details -
> but I never stopped saying that one of IBM's problems was that they
> forgot what RPG stands for.

I've never heard 3000 lines described as a "monster program".