18 Nov
2016
18 Nov
'16
6 p.m.
http://vintagecomputer.net/browse_thread.cfm?id=658
Hot business women posing with classic UNIVAC hardware and a link to a very
rare 1968 business proposal by UNIVAC to Philip Morris, an attempt to sell
either a 418-III or 9400, pricing, comparison with IBM 360 models.
Included with the proposal were a handful of product brochures. I scanned
some of my favorite photos.
Bill
18 Nov
18 Nov
8:04 p.m.
On 11/18/2016 10:00 AM, william degnan wrote:
http://vintagecomputer.net/browse_thread.cfm?id=658
Hot business women posing with classic UNIVAC hardware and a link to
a very rare 1968 business proposal by UNIVAC to Philip Morris, an
attempt to sell either a 418-III or 9400, pricing, comparison with
IBM 360 models. Included with the proposal were a handful of product
brochures. I scanned some of my favorite photos.
Models? Wasn't the 9300 basically an instruction-compatible model of
the S/360 Model 20? I think the 9400 was the bottom end 360/30 model
compatible. Calling the Model 20 a "member of the System 360 line" has
always been a bit of a stretch in my book.
So small cheese in terms of sales proposals, but interesting
nonetheless. Thanks!
--Chuck
8:09 p.m.
On Fri, Nov 18, 2016 at 3:04 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 11/18/2016 10:00 AM, william degnan wrote:
The 418-III is a better comparison, of a more powerful 360 than the /20.
The proposal basically says pick between the 418-III or you can buy a 9000
series and if necessary dial into a time sharing system we recommend (see
brochure at the end of the proposal).
Bill
http://vintagecomputer.net/browse_thread.cfm?id=658
Hot business women posing with classic UNIVAC hardware and a link to
a very rare 1968 business proposal by UNIVAC to Philip Morris, an
attempt to sell either a 418-III or 9400, pricing, comparison with
IBM 360 models. Included with the proposal were a handful of product
brochures. I scanned some of my favorite photos.
Models? Wasn't the 9300 basically an instruction-compatible model of
the S/360 Model 20? I think the 9400 was the bottom end 360/30 model
compatible. Calling the Model 20 a "member of the System 360 line" has
always been a bit of a stretch in my book.
So small cheese in terms of sales proposals, but interesting
nonetheless. Thanks!
--Chuck
8:10 p.m.
On Fri, Nov 18, 2016 at 3:09 PM, william degnan <billdegnan at gmail.com>
wrote:
On Fri, Nov 18, 2016 at 3:04 PM, Chuck Guzis <cclist at sydex.com> wrote:
meant to say ,,,time sharing system with a 418-III on the other end.
BIll
On 11/18/2016 10:00 AM, william degnan wrote:
The 418-III is a better comparison, of a more powerful 360 than the /20.
The proposal basically says pick between the 418-III or you can buy a 9000
series and if necessary dial into a time sharing system we recommend (see
brochure at the end of the proposal).
Bill
http://vintagecomputer.net/browse_thread.cfm?id=658
Hot business women posing with classic UNIVAC hardware and a link to
a very rare 1968 business proposal by UNIVAC to Philip Morris, an
attempt to sell either a 418-III or 9400, pricing, comparison with
IBM 360 models. Included with the proposal were a handful of product
brochures. I scanned some of my favorite photos.
Models? Wasn't the 9300 basically an instruction-compatible model of
the S/360 Model 20? I think the 9400 was the bottom end 360/30 model
compatible. Calling the Model 20 a "member of the System 360 line" has
always been a bit of a stretch in my book.
So small cheese in terms of sales proposals, but interesting
nonetheless. Thanks!
--Chuck
11:15 p.m.
On 11/18/2016 02:04 PM, Chuck Guzis wrote:
Models? Wasn't the 9300 basically an
instruction-compatible model of the S/360 Model 20? I
think the 9400 was the bottom end 360/30 model compatible.
Calling the Model 20 a "member of the System 360 line" has
always been a bit of a stretch in my book.
OH, yeah! Besides the limited
instruction set, short
registers only half populated, etc., did you know that the
360/20 did not have an adder? It could only
increment/decrement. The data paths were only 4 bits wide,
so to add a 3 in register A to a 5 in register B, it
decremented A and incremented B until A went negative. It
did this for each nibble. I'm guessing a 16-bit add took
over 100 us. I'd ALMOST reject calling this a COMPUTER!
Jon
19 Nov
19 Nov
12:04 a.m.
On 11/18/2016 03:15 PM, Jon Elson wrote:
OH, yeah! Besides the limited instruction set, short
registers only
half populated, etc., did you know that the 360/20 did not have an
adder? It could only increment/decrement. The data paths were only
4 bits wide, so to add a 3 in register A to a 5 in register B, it
decremented A and incremented B until A went negative. It did this
for each nibble. I'm guessing a 16-bit add took over 100 us. I'd
ALMOST reject calling this a COMPUTER!
So not even as smart as a 1620 CADET, which did arithmetic via TLU?
I guess I could believe that for register arithmetic, but did it do the
same for memory-to-memory packed decimal operations?
--Chuck
3:59 a.m.
On 11/18/2016 06:04 PM, Chuck Guzis wrote:
On 11/18/2016 03:15 PM, Jon Elson wrote:
Right!
OH, yeah! Besides the limited instruction set,
short registers only
half populated, etc., did you know that the 360/20 did not have an
adder? It could only increment/decrement. The data paths were only
4 bits wide, so to add a 3 in register A to a 5 in register B, it
decremented A and incremented B until A went negative. It did this
for each nibble. I'm guessing a 16-bit add took over 100 us. I'd
ALMOST reject calling this a COMPUTER!
So not even as smart as a 1620 CADET, which
did arithmetic via TLU? I guess I could believe that for register arithmetic,
but did it do the
same for memory-to-memory packed decimal operations?
Yes, I think it had to, as it
had no adder. Had to be
incomprehensibly slow. I guess it would load the memory to
an internal register a piece at a time.
Jon
4:17 a.m.
On 11/18/2016 07:59 PM, Jon Elson wrote:
Yes, I think it had to, as it had no adder. Had to
be
incomprehensibly slow. I guess it would load the memory to an
internal register a piece at a time.
The last time I dug around a bit for model 20 software, I was surprised
to find that there was not only a FORTRAN, but a PL/I and a COBOL
written for the thing.
By and large, the only applications that I ever saw were RPG. I can't
begin to imagine how slow a COBOL would be, much less a PL/I.
--Chuck
5:49 p.m.
On 11/18/2016 10:17 PM, Chuck Guzis wrote:
On 11/18/2016 07:59 PM, Jon Elson wrote:
PL/I ?? No, I really can't believe it! Was this a
cross-compiler? Remember, MANY /20s had 4K memory and no
disk. There also was no OS, so no file system support. I
can imagine a cross-compiler being of some use, as small
programs ought to work OK. The only sensible reason for
FORTRAN would be scientific computing, and since the /20 had
no floating point, I can barely imagine how slow a double
precision FP multiply would be. I would have to guess close
to a second! I think a Monroematic calculator could give it
good competition, and some of the early programmable
calculators (Wang and such) could almost certainly outdo it.
I'd rather be hitting myself on the head with a hammer than
try to do serious computing on a 360/20.
It makes even a PDP-8 look like a real workhorse.
Jon
Yes, I think it had to, as it had no adder. Had
to be
incomprehensibly slow. I guess it would load the memory to an
internal register a piece at a time.
The last time I dug around a bit for model 20
software, I was surprised
to find that there was not only a FORTRAN, but a PL/I and a COBOL
written for the thing.
By and large, the only applications that I ever saw were RPG. I can't
begin to imagine how slow a COBOL would be, much less a PL/I.
5:56 p.m.
On Sat, Nov 19, 2016 at 12:49 PM, Jon Elson <elson at pico-systems.com> wrote:
On 11/18/2016 10:17 PM, Chuck Guzis wrote:
True, but for all that I have read about the actual use of the /20 that was
not what it was for. IBM used the /20's as a smart terminal and that kind
of thing. The thing in between the mainframe and something else
operating in a remote location, and so on.
On 11/18/2016 07:59 PM, Jon Elson wrote:
Yes, I think it had to, as it had no adder. Had to be
Remember,
MANY /20s had 4K memory and no disk. There also was no OS, so no
file system support. I can imagine a cross-compiler being of some use, as
small programs ought to work OK. The only sensible reason for FORTRAN
would be scientific computing, and since the /20 had no floating point, I
can barely imagine how slow a double precision FP multiply would be. I
would have to guess close to a second! I think a Monroematic calculator
could give it good competition, and some of the early programmable
calculators (Wang and such) could almost certainly outdo it.
I'd rather be hitting myself on the head with a hammer than try to do
serious computing on a 360/20.
It makes even a PDP-8 look like a real workhorse.
Jon
incomprehensibly slow. I guess it would load the
memory to an
internal register a piece at a time.
The last time I dug around a bit for model 20 software, I was surprised
to find that there was not only a FORTRAN, but a PL/I and a COBOL
written for the thing.
By and large, the only applications that I ever saw were RPG. I can't
begin to imagine how slow a COBOL would be, much less a PL/I.
PL/I ?? No, I really can't believe it! Was this a cross-compiler?
20 Nov
20 Nov
6:53 a.m.
On 11/19/2016 09:56 AM, william degnan wrote:
True, but for all that I have read about the actual
use of the /20
that was not what it was for. IBM used the /20's as a smart terminal
and that kind of thing. The thing in between the mainframe and
something else operating in a remote location, and so on.
The Model 20 could use 2311 disks (model 11 or 12) as well as the 2415
tape drive. And there *was* a disk operating system of sorts: DPS:
http://bitsavers.trailing-edge.com/pdf/ibm/360/model20/C24-9006-4_260-20_Ct…
Even has S/360 type JCL--and note that PL/I is mentioned. Incredible.
One wonders how many "loaded" Model 20 systems were deployed. An awful
lot were sold as unit-record system replacements.
If you had a disk, IBM really tried to squeeze things small. DOS/360,
IIRC, could be shoved into a resident with no more than 8KB. Lots of
transient phases, though.
--Chuck
12:52 p.m.
On Nov 20, 2016 1:54 AM, "Chuck Guzis" <cclist at sydex.com> wrote:
On 11/19/2016 09:56 AM, william degnan wrote:
http://bitsavers.trailing-edge.com/pdf/ibm/360/model20/C24-9006-4_260-20_Ct…
True, but for all that I have read about the
actual use of the /20
that was not what it was for. IBM used the /20's as a smart terminal
and that kind of thing. The thing in between the mainframe and
something else operating in a remote location, and so on.
The Model 20 could use 2311 disks (model 11 or 12) as well as the 2415
tape drive. And there *was* a disk operating system of sorts: DPS:
Even has S/360 type JCL--and note that PL/I is mentioned. Incredible.
One wonders how many "loaded" Model 20 systems were deployed. An awful
lot were sold as unit-record system replacements.
If you had a disk, IBM really tried to squeeze things small. DOS/360,
IIRC, could be shoved into a resident with no more than 8KB. Lots of
transient phases, though.
--Chuck
Theoretical uses of a /20 aside, the Sperry Rand proposal I scanned claims
that a 418-III is a computer with the equivalent performance of a 360/44 or
/50 at /40 prices. Not cheap but you'd save thousands of $$'s. They offer
a , 9400 (and related hardware) system as an option local machine that can
be geared with/paired to time shared 418-III. The teaches us today what
UNIVAC thought back then was a smaet reasonable alternative config should
the customer not want to spend 418-III money.
You don't get this kind of cross-system comparison from the manuals alone.
Considering how they included only 9000 series brochures in the proposal
binder...perhaps it was done to push the 9000 option as a smart "new-way"
alternative, or because everyone already knew about the 418 series stuff,
less so the 9000. At the end of the proposal is the brochure from the time
sharing partner company. Old Computer World's from the time had a lot of
ads for timesharing services.
Bill
8:02 p.m.
On Sun, Nov 20, 2016 at 07:52:20AM -0500, william degnan wrote:
Old Computerworlds from the time had a lot of ads for
timesharing
services.
That was before everyone decided it was far cheaper and saner to own
and administer their own systems.
(ahem.)
Mark "everything old is new again" Linimon
9:32 p.m.
On 11/20/2016 12:02 PM, Mark Linimon wrote:
On Sun, Nov 20, 2016 at 07:52:20AM -0500, william
degnan wrote:
Ahems, aside. There was a definite market for outfits like SBC,
Tymshare and EDS back in the day. They afforded three things that
"owning your own" couldn't quite achieve for most commercial users.
The first was networking (such as it was back then) and remote access by
various branch offices to the same data. ISTR that SBC was the basis
for Ticketron, for example. Networking (over common carrier lines) was
hugely expensive back then.
The second was expertise--the service bureau had experts in DP and could
guide an unsuspecting user through the maze of DP machinations. No need
to write your own applications; the SB probably had something to fit the
bill.
The third was availability of maintained hardware. Sure, you might have
a service contract with IBM or CDC, but when your system went down, all
you could do was stand around fidgeting while your machine was helped
back to its feet. SBs always had spare capacity for your job--and could
expedite (for a fee).
Recall also, that back in the day, much of BDP was batch-oriented, not
interactive.
Interestingly, after a decline, service bureaus are coming back in the
role of 3D printing providers.
--Chuck
Old Computerworlds from the time had a lot of ads
for timesharing
services.
That was before everyone decided it was far cheaper and saner to own
and administer their own systems.
(ahem.) 
10:07 p.m.
New subject: owning the hardware was Re: Interested in UNIVAC 9000 Series (and IBM 360)
Old
Computerworlds from the time had a lot of ads for timesharing
services.
That was before everyone decided it was far cheaper and saner to own
and administer their own systems.
(ahem.) 
11:30 p.m.
On Fri, Nov 18, 2016 at 6:15 PM, Jon Elson <elson at pico-systems.com> wrote:
OH, yeah! Besides the limited instruction set, short
registers only half
populated, etc., did you know that the 360/20 did not have an adder?
This made me curious about how primitive it was, but the FE docs on
bitsavers show a 16bit ALU that can do ADD, AND, OR and XOR and maybe
some logic to help with BCD math.
21 Nov
21 Nov
12:29 a.m.
On 11/20/2016 05:30 PM, Charles Dickman wrote:
On Fri, Nov 18, 2016 at 6:15 PM, Jon Elson <elson
at pico-systems.com> wrote:
OK, in this manual :
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/fe/2020/Z26-5908_3…
They describe the functions available in microcode. They
are REALLY limited!
See Page 1-23, Description, item 4. They have data transfer
and increment and decrement.
Period! I don't see ANYTHING that relates to ALU
functions! Maybe I missed it, it seems really hard to believe.
and then page 1-27 describing what the increment and
decrement commands do. Notably, they note that the
registers contain values from 0-15, ie. a 4-bit field.
Maybe I missed the whole point of what they are describing
here, but this seems to be somewhat consistent with what you
can pack into a 16-bit microinstruction, namely, not a lot.
Take a look in this manual and see if you get a different
impression.
Jon
OH, yeah! Besides the limited instruction set,
short registers only half
populated, etc., did you know that the 360/20 did not have an adder?
This made me
curious about how primitive it was, but the FE docs on
bitsavers show a 16bit ALU that can do ADD, AND, OR and XOR and maybe
some logic to help with BCD math.
6:28 p.m.
On Sun, Nov 20, 2016 at 7:29 PM, Jon Elson <elson at pico-systems.com> wrote:
On 11/20/2016 05:30 PM, Charles Dickman wrote:
I was looking here:
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/fe/2020/Z33-1021-0…
(pdf) pages 45, 46 describe the ALU
And here:
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/fe/2020/SY33-1024-…
(pdf) pages 15 and 38 Data flows and ALU schematic
On Fri, Nov 18, 2016 at 6:15 PM, Jon Elson <elson at pico-systems.com> wrote:
OK, in this manual :
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/fe/2020/Z26-5908_3…
They describe the functions available in microcode. They are REALLY
limited!
See Page 1-23, Description, item 4. They have data transfer and increment
and decrement.
Period! I don't see ANYTHING that relates to ALU functions! Maybe I missed
it, it seems really hard to believe.
and then page 1-27 describing what the increment and decrement commands do.
Notably, they note that the registers contain values from 0-15, ie. a 4-bit
field.
Maybe I missed the whole point of what they are describing here, but this
seems to be somewhat consistent with what you can pack into a 16-bit
microinstruction, namely, not a lot.
Take a look in this manual and see if you get a different impression.
Jon OH, yeah! Besides the limited instruction set,
short registers only half
populated, etc., did you know that the 360/20 did not have an adder?
This made me curious about how primitive it was, but the FE docs on
bitsavers show a 16bit ALU that can do ADD, AND, OR and XOR and maybe
some logic to help with BCD math.
10:17 p.m.
I was looking here:
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/
fe/2020/Z33-1021-0_2020_Processing_Unit_FETOM_May68.pdf
(pdf) pages 45, 46 describe the ALU
I note that the cover page says: "(Machines with serial no. 50,000 and
above)."
Perhaps the ALU is only present on late model machines?
-- Charles
10:38 p.m.
>
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/
> fe/2020/Z33-1021-0_2020_Processing_Unit_FETOM_May68.pdf
> (pdf) pages 45, 46 describe the ALU
On Mon, 21 Nov 2016, Charles Anthony wrote:
I note that the cover page says: "(Machines with
serial no. 50,000 and
above)."
Perhaps the ALU is only present on late model machines?
A nice ROUND number for the model change.
Had they sold 49,999 machines before that model change?
Or was this a machine where the first one sold already had a 5 digit
serial number?
22 Nov
22 Nov
2:29 a.m.
On 11/21/2016 04:17 PM, Charles Anthony wrote:
That would be a HUGE difference between different serial
numbers, so I'd rather doubt it.
Jon
I was looking
here:
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/
fe/2020/Z33-1021-0_2020_Processing_Unit_FETOM_May68.pdf
(pdf) pages 45, 46 describe the ALU
I note that the cover page says: "(Machines with serial no. 50,000 and
above)."
Perhaps the ALU is only present on late model machines?
2:27 a.m.
On 11/21/2016 12:28 PM, Charles Dickman wrote:
I was looking here:
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/fe/2020/Z33-1021-0…
(pdf) pages 45, 46 describe the ALU And here:
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/fe/2020/SY33-1024-…
(pdf) pages 15 and 38 Data flows and ALU schematic
Yes, indeed, it seems to show a
quite different architecture
than what I got from the part I referenced.
I had better stop as I am no expert on a 360/20, and the
text SEEMED to contradict the schematics.
Jon
2959
days inactive
2963
days old
22 comments
9 participants
participants (9)
-
billdegnan＠gmail.com -
cclist＠sydex.com -
charles.unix.pro＠gmail.com -
chd＠chdickman.com -
cisin＠xenosoft.com -
elson＠pico-systems.com -
jwsmail＠jwsss.com -
linimon＠lonesome.com -
spectre＠floodgap.com