360 programs on a z/10
Lindy Mayfield
Has to be at least one (IEFBR14). (-:
Kind regards
Lindy
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Blaicher, Chris
Chris Blaicher
Phone: 512-340-6154
Mobile: 512-627-3803
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Lindy Mayfield
> Sent: Thursday, December 17, 2009 11:06 AM
> To: IBM-...@bama.ua.edu
> Subject: 360 programs on a z/10
>
> still run on a z/10. Is this true? Some? Most? All?
>
> Has to be at least one (IEFBR14). (-:
>
> Kind regards
> Lindy
So long as they conform to the restrictions, they should. Now, if they use priviliged instructions, they may not because of changes in the hardware and z/OS. But if they are normal programs, then yes. Oh, if written in an HLL, you might need an appropriate run-time. E.g. if the code was written in ANSI COBOL, I doubt the executable will still run as there is no ANSI COBOL compatable run-time anymore. The same with any system type assembler macros. So, I'd go with some to most, depending.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
P S
> I have not done much testing, but I have an old (1972?) program that still
> works. Original object code.
>
Way cool! Timestamp intact in the object deck? Or is it a load module? (NOT
challenging it, just wondering!)
I have a Windows program from 2007 that...oh, darn, it won't run any more
since the last Windows patches were applied. O well.
Lindy Mayfield
Tom Marchant
>I've often heard that programs that ran on the IBM 360 will still
>run on a z/10. Is this true? Some? Most? All?
True, with very few exceptions.
John already mentioned privileged instructions. I/O instructions, for
example, were completely replaced with XA in the early 1980's. Normal
problem-state programs do not use these instructions though. They rely on
the operating system to do their I/O for them.
The operating system has carefully maintained this application program
compatibility as well. Of course, it was always possible to design a
program so that it was dependent on particular machine characteristics. If
you had a cpu loop that was designed to cause your processing to wait for a
period of time, it would end much sooner today. Or if you had a program
that depended on the track and cylinder size of a 2314, you'd be out of luck
today.
Another case is the ASCII bit. Bit 12 of the 360 PSW was the ASCII bit,
which caused certain decimal instructions to behave a little differently
with regard to the sign nybble. If your 360 program depended on that, it
would not work correctly.
--
Tom Marchant
Mike Myers
The 360 instruction set is wholly contained in the z/Series instruction
set and many system constructs were extended in such a way as to make
them backward compatible.
Some system functions (like the ISAM access method) no longer exist, and
some things you could get away with in the early days (think OS/360)
were closed as security or reliability loopholes in MVS.
Most macros are backward compatible as well, although some may require
re-assembling to work correctly today (but offhand, I can't think of any
examples).
It is not unlikely that a 360 program will still work on a z/Series
machine, but the more vanilla the program, the better the chance that it
will.
Some ancient programs like DEBE and Ditto still run on a z/Series
machine under z/OS, although they may have been reworked to do so. I
don't still have any of my ancient programs to try out myself.
Mike Myers
Chris Craddock
> wrote:
> I've often heard that programs that ran on the IBM 360 will still run on a
> z/10. Is this true? Some? Most? All?
>
> Has to be at least one (IEFBR14). (-:
>
>
Application programs still run fine as long as they don't use archaic system
services that are no longer supported or depend on ancient runtime functions
also out of support.
On the other hand, systems software might or might not work, depending on
the nature of what they do. On average most old systems software would not
work.
--
This email might be from the
artist formerly known as CC
(or not) You be the judge.
Finley, Frank
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Lindy Mayfield
Rick Fochtman
I've often heard that programs that ran on the IBM 360 will still run on
a z/10. Is this true? Some? Most? All?
Has to be at least one (IEFBR14). (-:
------------------------------<unsnip>------------------------------
I've never found a program that can't run on a z/10, but a very few that
won't run under z/OS. Those failures I've encountered are because they
exploited "holes" in OS/360 that have been subsequently closed. One of
those "holes" that I used to exploit on a regular basis was vie the
FREEDBUF SVC, mostly used by BDAM.
As always, YMMV.
Rick
Rick Fochtman
The 360 instruction set is wholly contained in the z/Series instruction
set and many system constructs were extended in such a way as to make
them backward compatible.
Not strictly true; SIO/HIO/TIO are no more than fond memories today.
There might be a very few others, but these are the ones I remember most.
------------------------------<snip>--------------------------------------------
Some system functions (like the ISAM access method) no longer exist, and
some things you could get away with in the early days (think OS/360)
were closed as security or reliability loopholes in MVS.
----------------------------<unsnip>----------------------------------------
ISAM is no great loss, but I don't know if the ISAM Compatability
Interface is still available to convert ISAM calls to the equivalent
VSAM mechanisms.
---------------------------------<snip>------------------------------------
Most macros are backward compatible as well, although some may require
re-assembling to work correctly today (but offhand, I can't think of any
examples).
----------------------------------<unsnip>--------------------------------
AFAIK, only some macros that require a few specialized systems services
are incompatable. Just about everything that application are expected to
use are pretty much unchanged, or at least compatible.
-----------------------------------<snip>--------------------------------
Some ancient programs like DEBE and Ditto still run on a z/Series
machine under z/OS, although they may have been reworked to do so. I
don't still have any of my ancient programs to try out myself.
-------------------------------------<unsnip>-----------------------------
Any old stand-alone programs that do ANY I/O will need to be reworked,
because of the loss of SIO/TIO/HIO instructions and changes in the
overall architecture in this area. Also programs that expect to use
certain areas of the first 2K of storage.
In my experience, very few surviving OS/360 application programs will
fail on z/10 machines. Providing you have access to the correct run-time
libraries.
Rick
Mike Myers
Yes, I had forgotten about SIO/HIO/TIO and was reminded of those by your
first post. I can't recall if I ever personally wrote a SIO instruction.
Most of the channel programming I ever did was at the EXCP level, so i
don't recall writing a SSCH instruction either.
As for the ISAM compatibility interface in VSAM, I think that went out
around the same time as ICF catalogs came along.
I agree that most vanilla application level programs written for S/360
would probably run on a z10 today. IBM took great pains to maintain
backward compatibility.
Mike Myers
Robert Heffner
workstations (remember those?). The program that was used to extract data
from the 3791 was called BTP (Batch Transfer Program, I think). BTP 'talked'
to VTAM and thus was full of VTAM macros (ACB, GENCB, etc etc). The
program had last been assembled and linked in 1978. After one MVS upgrade
(don't remember which one), the program would intermittently end with CC=2.
It would otherwise do what it was supposed to do, so we weren't too
concerned about it. Then after another software upgrade (I think it was
DFSMS 1.1), BTP started failing hard with 0C4, and IBM told us to reassemble
the program, which took care of the 0C4 abends and also the CC=2. BTP ran
flawlessly for the rest of the time that the 3790/3760's were there.
Another program assembled and linkedited in 1968 had problems loading at
execution time. I don't remember the specific error, but all I had to do was
relinkedit the program, and it worked fine.
The point is, sometimes a problem can be resolved by a reassemble and/or
relink. But like the other posters have said, it depends on what the program is
doing.
Rick Fochtman
> Rick:
>
> Yes, I had forgotten about SIO/HIO/TIO and was reminded of those by
> your first post. I can't recall if I ever personally wrote a SIO
> instruction. Most of the channel programming I ever did was at the
> EXCP level, so i don't recall writing a SSCH instruction either.
>
> As for the ISAM compatibility interface in VSAM, I think that went out
> around the same time as ICF catalogs came along.
>
> I agree that most vanilla application level programs written for S/360
> would probably run on a z10 today. IBM took great pains to maintain
> backward compatibility.
>
> Mike Myers
DEBE is one that I remember particularly, because of the acronym DEBE:
"Does Everything But Eat". But I only remember it as a stand-alone program.
Anne & Lynn Wheeler
mi...@MENTOR-SERVICES.COM (Mike Myers) writes:
> Yes, I had forgotten about SIO/HIO/TIO and was reminded of those by
> your first post. I can't recall if I ever personally wrote a SIO
> instruction. Most of the channel programming I ever did was at the
> EXCP level, so i don't recall writing a SSCH instruction either.
re:
http://www.garlic.com/~lynn/2009r.html#14 "Portable" data centers
http://www.garlic.com/~lynn/2009r.html#18 "Portable" data centers
http://www.garlic.com/~lynn/2009r.html#49 "Portable" data centers
http://www.garlic.com/~lynn/2009r.html#50 "Portable" data centers
http://www.garlic.com/~lynn/2009r.html#51 "Portable" data centers
370 introduced options for SIO/HIO ... SIO fast, Halt device, and Halt
channel.
when i was building an extremely robust operating systems for the disk
engineering and product test labs ... one of the things was getting a
controller or the 303x channel director to reset/re-impl ... as part of
"severe" recovery process (never take down the system ... and require
minimum of manual operations).
it turns out that most controllers would reset/re-impl if you very
quickly hit all of the controller's subchannel addresses with HDV
(basically couple instruction loop). A 303x channel director would also
reset/re-impl ... if you hit all six channel addresses with halt
channel.
misc. past posts mentioning getting to play disk engineer in bldgs.
14 & 15
http://www.garlic.com/~lynn/subtopic.html#disk
in the move from 360/370 "real storage" to 370 virtual memory ... all
the channel programs required to be hit. most access methods built
channel programs with "real" storage addresses and then would execute
EXCP. The 360 & 370 channels executed channel programs assuming all the
addresses were "real".
moving to 370 virtual memory ... all the channel programs built in
application space would be referring to virtual addresses ... not real
addresses. When this was passed to kernel with EXCP ... EXCP had to
build shadow/duplicate channel program that substituted real addresses
for the virtual addresses (as well as some housekeeping to pin the
virtual pages at the real address).
In cp67, this had been going on for some time ... taking the channel
program from the virtual machine SIO ... and building a shadow/duplicate
channel program with real addresses ... rather than virtual addresses.
The routine in cp67 that performed this function was CCWTRANS. The
initial work on os360 to move to 370 virtual memory ... borrowed a copy
of CCWTRANS (out of cp67) to do the shadow/duplicate channel program.
Part of the justification for SSCH was help with the enormous pathlength
in MVS for I/O redrive ... after taking an interrupt (leaving device
idle during the period). One of the other things I did for operating
system for bldg. 14&15 ... was highly optimized the I/O redrive
pathlength.
This ran into problem with early (internal) work with 3880 disk
controller. There was some early performance product acceptance test of
the 3880 that met with no problem. However, when they swapped a 3830
disk controller with an early 3880 on 3033 in bldg15 (had a string of 16
3330 drives) ... things completely fell apart. I was getting yelled at
that it was my fault. Turns out that 3830 had fast horizontal microcode
engine ... and the 3880 had a much slower vertical microcode engine.
There was some additional hardware paths in the 3880 (to handle 3mbyte
data transfer) but commands and control operations were much slower. As
part of making the 3880 appear as fast as the 3830 ... the 3880 started
presented operation complete early ... before it was completely
finished. 3880 assumed that it could finish in the delay that it took
the processor to handle the interrupt ... do the other operating system
gorp ... before getting back to redrive the 3880 with new operation. My
optimized pathlength was hitting the controller with redrive in much
shorter period ... before it had finished its cleanup. This resulted in
having to present CC=1 to the SIO with SM+BUSY (controller busy). The
processing then had to requeue the operation that it attempt to start
(and go off and do something else). Later the 3880 had to present an
additional CUE interrupt (to indicate it was no longer busy ... because
of having presenting the earlier controller busy). This added all sorts
of additional overhead and delay ... compared to the identical workload
& 3330s using 3830 controller (instead of 3880 controller).
recent post mentioning the SM+BUSY scenario and redrive latency
(dedicated processor being able to handle queued i/o and much lower
latency redrive operation).
http://www.garlic.com/~lynn/2009q.html#74 Now is time for banks to replace core system according to Accenture
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
Timothy Sipples
>ISAM is no great loss, but I don't know if the ISAM Compatability
>Interface is still available to convert ISAM calls to the equivalent
>VSAM mechanisms.
Yes, the ISAM interface is still available, so such applications continue
to run (with minor caveats). See (for example) the z/OS 1.11 "DFSMS Using
Data Sets" guide, particularly Appendix E:
http://publibz.boulder.ibm.com/epubs/pdf/dgt2d480.pdf
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Based in Tokyo, Serving IBM Japan / Asia-Pacific
E-Mail: timothy...@us.ibm.com
Timothy Sipples
All but two -- I think that's correct -- are substantially z/OS-based.
Was there anything IBM said that might cause you to assume otherwise about
the Solution Edition offerings? If so, maybe that's something I could look
into. I've previously highlighted in this forum that they are
heavily/substantially z/OS-based (if that's of concern and/or curiosity).
Although I don't speak for IBM, I will confirm the press release details,
that BC Card has selected very nice z/OS-based infrastructure, including
(as the press release says) CICS Transaction Server. DB2 and WebSphere
Application Server are also on z/OS, as are several other software
products. I'm not even sure if there is any Linux-based content at this
point in time, though there could be. z/OS and Linux on System z complement
each other quite well and certainly don't particularly compete with one
another.
BC Card was founded in 1982. They have never had a mainframe before -- not
anything of MVS heritage anyway. It is the largest credit card company in
Korea.
My congratulations (and thanks) to BC Card. We look forward to many
mutually beneficial years working together.
Tom Marchant
>
>Yes, I had forgotten about SIO/HIO/TIO and was reminded of those by your
>first post. I can't recall if I ever personally wrote a SIO instruction.
>Most of the channel programming I ever did was at the EXCP level, so i
>don't recall writing a SSCH instruction either.
SIO was a privileged instruction, so you wouldn't have done that unless you
were running in supervisor state. Same with SSCH.
>As for the ISAM compatibility interface in VSAM, I think that went out
>around the same time as ICF catalogs came along.
No. Not even close. IIRC, you could even use actual ISAM until 2000. ICF
catalogs were out long before 1990. Support for ISAM applications is still
in VSAM. I've never heard any statement that it will be withdrawn.
--
Tom Marchant
Mike Myers
Well, actually I did write some privileged code. I believe that my code
contained the only (if not one of the very few) PTLB (Purge Translate
Lookaside Buffer) instructions in MVS.
I had (may still have?) a fair amount of code in the nucleus in the
Virtual and Real Storage Manager components (quickcell and paging
services).
I thought there was some version of DFP where they finally removed the
ISAM compatibility code, but I don't remember any official declaration
of that, just that the use of ISAM phased out on its own after the
introduction of VSAM in MVS.
ISAM did some pretty interesting channel programming. It was back in the
late '60s and early '70s while teaching the internals of ISAM and BDAM
to Program Support Reps that I learned about self-modifying channel
programs (fun stuff).
Mike
Tom Marchant wrote:
> On Thu, 17 Dec 2009 16:27:10 -0500, Mike Myers wrote:
>
>> Yes, I had forgotten about SIO/HIO/TIO and was reminded of those by your
>> first post. I can't recall if I ever personally wrote a SIO instruction.
>> Most of the channel programming I ever did was at the EXCP level, so i
>> don't recall writing a SSCH instruction either.
>>
>
> SIO was a privileged instruction, so you wouldn't have done that unless you
> were running in supervisor state. Same with SSCH.
>
>
>> As for the ISAM compatibility interface in VSAM, I think that went out
>> around the same time as ICF catalogs came along.
>>
>
> No. Not even close. IIRC, you could even use actual ISAM until 2000. ICF
> catalogs were out long before 1990. Support for ISAM applications is still
> in VSAM. I've never heard any statement that it will be withdrawn.
>
>
----------------------------------------------------------------------
Anne & Lynn Wheeler
mi...@MENTOR-SERVICES.COM (Mike Myers) writes:
> ISAM did some pretty interesting channel programming. It was back in
> the late '60s and early '70s while teaching the internals of ISAM and
> BDAM to Program Support Reps that I learned about self-modifying
> channel programs (fun stuff).
re:
http://www.garlic.com/~lynn/2009r.html#52 360 programs on a z/10
not long after joining the science center ... I got sent out to Denver
on cp67 customer support call ... King Resources was trying to get a
large ISAM application running under cp67 ... and I spent a week
working 3rd shift in their datacenters. This was when machine room
was still a "show place" (1st floor downtown office building with
outside glass floor-to-ceiling) ...
as mentioned here
http://www.garlic.com/~lynn/2009r.html#21 Small Server Mob Advantage
channel programs built in a "virtual environment" (whether the virtual
machine or from application virtual address space) got "translated" into
shadow/copy channel programs (with real addresses) that were the ones
that really executed.
lots of ISAM "self-modifying" was reading/writting BBCCHHR values which
were later used by other CCWs in the same channel program.
additional challenge for cp67 was "minidisks" ... disk spaces that
"virtual cylinder zero" that was other than "real cylinder zero"
... which required translating "CC" field also (so seek BBCCHH fields
were copied also & translated also). Since the real seek was then
pointing to the copied value ... when a read operation read in a new
"BBCCHHR" ... it was into the virtual location ... not the location
pointed to by the seek actually executed. After doing all sorts of
fiddling ... trying to recognize ISAM channel programs and reads that
were fetching BBCCHH field ... the eventual solution was to recognize
"full-pack" virtual disks that didn't do the fiddling with seek BBCCHH
(and hope noboby really wanted to run ISAM channel programs on
minidisks).
Charlie Gibbs
(Anne & Lynn Wheeler) writes:
> As part of making the 3880 appear as fast as the 3830 ... the
> 3880 started presented operation complete early ... before it
> was completely finished.
I _hate_ machines that lie to me...
> 3880 assumed that it could finish in the delay that it took the
> processor to handle the interrupt ... do the other operating system
> gorp ... before getting back to redrive the 3880 with new operation.
> My optimized pathlength was hitting the controller with redrive in
> much shorter period ... before it had finished its cleanup.
...because sooner or later the lie gets found out.
--
/~\ 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!
Don Higgins
ISAM was used at Florida Power for the customer master file before VSAM
before DB2. Assembler subroutines were called by COBOL to access the file
either sequentially or randomly and with or without update. The initial reason
for using assembler was lack of variable length in COBOL initially, but it was a
useful choice as it isolated the applicaiton from both software and hardware
changes such as moving from data cell to pizza ovens etc. Interestingly the
DB2 version implemented in 1995 used assembler compression/decompression
to reduce network traffic by 50%
Anyway I remember studying the channel programs used by ISAM and
although they were designed to maximize I/O speed, they were severely
hampered by the lack of VSAM CA/CI indexing which resulted in exceedly long
sequential chains of overflow records which could runs for hours if the file was
not unloaded and reloaded to restore evenly distributed overflow track space.
Don Higgins
d...@higgins.net
Farley, Peter x23353
> Sent: Saturday, December 19, 2009 7:24 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: 360 programs on a z/10
<Snipped>
> Anyway I remember studying the channel programs used by ISAM and
> although they were designed to maximize I/O speed, they were severely
> hampered by the lack of VSAM CA/CI indexing which resulted in exceedly
> long sequential chains of overflow records which could runs for hours
> if the file was not unloaded and reloaded to restore evenly
> distributed overflow track space.
Which was why in the day I remember sorting input batch files in reverse
(descending) key sequence so that the ISAM I/O would find the "next"
insertion point without traversing the entire overflow chain. Ideally,
if the "next" point was at the start of an overflow chain, *none* of the
chain had to be read to do the next insertion.
Ah yes, those were the days... (not!).
Peter
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
Rick Fochtman
Which was why in the day I remember sorting input batch files in reverse
(descending) key sequence so that the ISAM I/O would find the "next"
insertion point without traversing the entire overflow chain. Ideally,
if the "next" point was at the start of an overflow chain, *none* of the
chain had to be read to do the next insertion.
Ah yes, those were the days... (not!).
-----------------------------<unsnip>-------------------------------
ISTR doing the same thing, sorting into descending order the names of
members to be deleted from a large PDS. In that case, the overhead of
rewriting the directory after the deletion point made my decision MUCH
easier. Still works well with large PDS's today. I learned it initially
when cleaning up an old SYS1.UADS dataset. :-)
Rick
Paul Gilmartin
>
>ISTR doing the same thing, sorting into descending order the names of
>members to be deleted from a large PDS. In that case, the overhead of
>rewriting the directory after the deletion point made my decision MUCH
>easier. Still works well with large PDS's today. I learned it initially
>when cleaning up an old SYS1.UADS dataset. :-)
>
-- gil
Gabe Goldberg
---
VM/370 security retrofit program
http://portal.acm.org/citation.cfm?id=1124634&dl=GUIDE&coll=GUIDE&CFID=67357903&CFTOKEN=73885624
the feasibility of adding a security kernel to VM/370 was studied and a kernel ..... such as those used by OS/360 ISAM. Certain VM/370 penetrations{l} ...
and
VM/370 Security Retrofit Program-Detailed Design and Implementation Phase
Authors: B. D. Gold; R. R. Linde; M. Schaefer; W. M. Shasberger; D. H. Thompson; SYSTEM DEVELOPMENT CORP SANTA MONICA CA
Abstract: This report describes a design strategy for performing a retrofit to IBM Corporation's Virtual Machine 370 (VM/370) system that will provide a time- shared environment in which user processes bearing differing military classification levels may be operated simultaneously without compromise to military security. The strategy entails drawing together into a secure kernel those system functions that may be exploited to violate security. This report finalizes the results of the first two years of an ongoing research and development program.
http://www.stormingmedia.us/61/6139/A613901.html
---
into creating a demonstrably secure VM. I experimented with KVM for a while at Mitre.
Mike Myers said:
ISAM did some pretty interesting channel programming. It was back in the
late '60s and early '70s while teaching the internals of ISAM and BDAM
to Program Support Reps that I learned about self-modifying channel
programs (fun stuff).
--
Gabriel Goldberg, Computers and Publishing, Inc. (703) 204-0433
3401 Silver Maple Place, Falls Church, VA 22042 ga...@gabegold.com
LinkedIn: http://www.linkedin.com/in/gabegold
Anne & Lynn Wheeler
ga...@GABEGOLD.COM (Gabe Goldberg) writes:
> Speaking of ISAM doing interesting channel programming -- ISAM was
> implicated in a very early VM security/integrity threat. Details elude
> me and I sadly don't have the program which used ISAM to penetrate VM,
> but it was discussed in this research
re:
http://www.garlic.com/~lynn/2009r.html#52 360 programs on a z/10
http://www.garlic.com/~lynn/2009r.html#57 360 programs on a z/10
ISAM and other kinds of (looping) channel programs were demonstrated
being able to do denial-of-service attack (hanging channel).
one of the things I did in paging access method on cp67 ... demonstrate
that run-of-mill virtual machines (w/o special privileges for channel
programs) could still do all of their disk access w/o needing channel
programming capability.
http://www.garlic.com/~lynn/submain.html#mmap
it also significantly raised the abstraction ... eliminating the
"overhead" of channel program abstraction ... and significantly reduced
the overhead. Also with the higher level abstraction ... I could do
significantly higher level of optimization (under the covers). In the
80s, some (otherwise on identical) CMS benchmarks against standard
filesystem on same hardware configuration and same 3380 drives ... I
could show three times thruput improvement with moderately i/o intensive
workload.
the higher level abstraction also enabled being able doing other kinds
of optimization with trivially sharing executable code and other stuff.
some old email about moving page-mapped stuff (and other things)
from cp67 to vm370:
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430
as undergraduate in the 60s ... i was doing lots of different cp67 stuff
... some of which shipped in standard product. I would also periodically
get reguests for doing various kinds of enhancements from the vendor.
Although I didn't hear about these guys until much later:
http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml
in retrospect, some of the requested features may have originated from
that market segment.
At the science center there, was some interesting security issues with
the cp67 "service" ... since there was student and other non-employee
access from various educational institutions in the boston and cambridge
area.
One such was the science center had ported APL\360 to CMS for CMS\APL
... redoing internal storage management so that it operated much more
efficiently with multi-megabyte workspaces in a virtual memory
environment ... as well as added function to access CMS system services
(which caused some uproar with the APL purists as violating APL). In
any case, it opened up APL use to a whole new class of applications
(large modeling & "what-if" things ... some of the things that are done
with spreadsheets today). In any case, some of the corporate business
planning people had the highest classified and most valuable of
corporate assets loaded on the cambridge system (complete cuostmer
details) so they could run business modeling remote from Armonk.
The security had to demonstarte that students and other non-employees
(and in fact, non-authorized employees) couldn't access the most
valuable of corporate assets.
Something similar was required in the joint exercise with Endicott
... applying changes to cp67 to add simulation of 370 virtual memory
"virtual machines" (long before virtual memory for 370 was announced).
There was requirement that even the very existance of the activity to
support 370 virtual memory virtual machines (on the cambridge cp67
360/67) didn't leak to student users and other non-employees in any way.
Note that various of the cp67 & vm370 commercial time-sharing service
bureaus provided other kinds of limitations on virtual machine
capabilities to eliminate deminal-of-service kinds of exploits. Some of
them had moved up to value stream into lots of online financial
information ... and would have lots of customers from competing wall
street firms (where potentially there was very large sums of money
involved).
Much later there was folklore about certain class of gov. customers
requesting *ALL* the MVS source that (exactly) corresponded to specific
executing MVS system (as part of a certain kind of MVS certification).
Supposedly there was a corporate task force that spent $5m dollars
studying the issue ... before concluding that it wasn't practical.
for other drift, this is post with tale about the FS effort implementing
a DRM facility for all "future system" documents ... no hard copies
... and detailed control for authorization and access:
http://www.garlic.com/~lynn/2009r.html#41 While watching Biography about Bill Gates on CNBC last Night
and security related precursor post
http://www.garlic.com/~lynn/2009r.html#39 While watching Biography about Bill Gates on CNBC last Night
Anne & Lynn Wheeler
re:
http://www.garlic.com/~lynn/2009r.html#52 360 programs on a z/10
http://www.garlic.com/~lynn/2009r.html#57 360 programs on a z/10
some of the CTSS people went to the science center on the 4th
flr ... some refs:
http://www.garlic.com/~lynn/subtopic.html#545tech
and others went to Multics on the 5th flr. one of the things
that the Multics group prided themselves on was the
customer associated with this
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#43 another 30 year thing
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation
related to customer mentioned in these posts (and about changing from a
20 vm/4341 order to 210 ... old email:
http://www.garlic.com/~lynn/2001m.html#email790404
http://www.garlic.com/~lynn/2001m.html#email790404b
in these posts
http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
i've mentioned before that it wasn't fair to compare total number of
multics installations to total number of vm installations ... or
even the total number of interla corporate vm installations ...
but mention of csc/vm in these old posts:
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430
and one of my hobbies was providing & supporting highly customized
(csc/vm) systems to internal datacenters ... and at one point I had
internal customer set that was larger than the aggregate number of
multics installations ... reference at the bottom of this page:
http://www.multicians.org/multics.html
also shown here:
http://www.multicians.org/site-timeline.html
working on some financial standards group in the early to mid
90s ... there were some members that had email that went
thru here:
http://www.multicians.org/site-dockmaster.html
above mentions docmaster is now property of:
http://www.nsa.gov/about/cryptologic_heritage/museum/
for other topic drift ... the above use to show (maybe still does) a
MISSI/MLS video tape. I talked them into letting me have a physical copy
of the video tape ... because I wanted to produce a voice-over
spoof/satire on MLS.
Lloyd Fuller
Was this using the old Formatted File System? The military used lots of this for awhile.
Lloyd
--- On Sat, 12/19/09, Don Higgins <d...@HIGGINS.NET> wrote:
Shmuel Metz , Seymour J.
12/17/2009
at 02:09 PM, P S <zos...@GMAIL.COM> said:
>Way cool! Timestamp intact in the object deck? Or is it a load module?
If it was compiled and linked under OS/360, and it wasn't a really old
release, there would be a timestamp in the IDR data.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Shmuel Metz , Seymour J.
12/17/2009
at 06:06 PM, Lindy Mayfield <lindy.m...@SSF.SAS.COM> said:
>I've often heard that programs that ran on the IBM 360 will still run on
>a z/10. Is this true?
Stand-alone S/360 programs will only run in S/370 mode, which hasn't been
available for a long time. I vaguely recall that the 3090 was the last
machine to support it, but it might have been the ES/9000 series.
As for programs that run under an OS, they will often run under a
successor OS, but there are some incompatibilities.
ASCII mode is probably a non-issue; I'm not aware of any OS that supported
it.
If your program depends on getting a program interrupt code 6 on an
alignment error, you will have problems.
If an OS/360 program depends on getting a system ABEND 0C5 for invalid
addresses, it will have problems. Similarly if assumes that only
protection violations will cause an 0C4.
Some system interfaces have changed.
Lots of security holes have been plugged.
BillD
> I've often heard that programs that ran on the IBM 360 will still run on a z/10. Is this true? Some? Most? All?
>
> Has to be at least one (IEFBR14). (-:
>
> Lindy
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> Search the archives athttp://bama.ua.edu/archives/ibm-main.html
I can tell you this. The worst that can happen by running an old
program on a newer operating system is a system crash! A long time
ago, I crashed the global JES system of a major bank processor three
times before they figured out it was me running an old object module
on their new release, OS/VS2 I think.
Those were the good old days!
John Kim
This is a first victory for the IBM mainframe since downsizing to
distributed platform tended to be an epidemic in South Korea for more
than a decade.
There were no clear reasons to give up a mainframe for them although
they were victimizing an IBM mainframe cost driven. To be honest
political atmosphere was pervasive over the RFP selection and IBM was
loosing a battle against open system invasion because of;
More political connections for the open system distributors - CEOs or
there lobbyists are parachuted, and linked to the government
IBM didn't agree to have an unfair game or not getting used - may
be....
I know how it went, and worked.... I worked as a senior systems
programming team lead for the one of BC members (XX BANK), and selected
RFP from the political pressure.
I hope BC card case changes the IT direction with no more political
game, may be it could be already changed. If they already did, just
disregard a criticism from old comrade, and Congrat them! Have no clue
I haven't been there a decade either...
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Timothy Sipples
Sent: Friday, December 18, 2009 1:31 AM
To: IBM-...@bama.ua.edu
The information transmitted is intended only for the addressee and may contain confidential, proprietary and/or privileged material. Any unauthorized review, distribution or other use of or the taking of any action in reliance upon this information is prohibited. If you receive this in error, please contact the sender and delete or destroy this message and any copies.
Ed Gould
From: P S <zos...@GMAIL.COM>
To: IBM-...@bama.ua.edu
Sent: Thu, December 17, 2009 1:09:05 PM
Subject: Re: 360 programs on a z/10
There are some restrictions about doing so (ISAM and a few other BTAM and some code that was device dependent (like 2314 etc)).
Just earlier this year I found a load module that was linked in 1972 and it still worked.
The other sort of gotcha is date issues might have to be handled slightly different (ie 4 digit years) but all in all a simple cobol/assembler/fortran probably will still work unchanged.
All in all a darn good dependable upwardly compatible (for the most part). IBM in my opinion has done a great service to the user community with OS - z/os.
I count 38 years (probably more) in simple code compatibility. Now I will not say that with IBM and *ANY* COBOL (for this and that) or Language environment, but pretty much all areas are excellent.
Ed
hanc...@bbs.cpcn.com
> m...@MENTOR-SERVICES.COM (Mike Myers) writes:
> > Yes, I had forgotten about SIO/HIO/TIO and was reminded of those by
> > your first post. I can't recall if I ever personally wrote a SIO
> > instruction. Most of the channel programming I ever did was at the
> > EXCP level, so i don't recall writing a SSCH instruction either.
AFAIK, there is no reason that an application program from the System/
360, written using standard conventions, could not be run on a modern
Z series. Assembler programs that "play tricks" may require
conversion to modern standards. I don't know about specialty _system_
programs.
COBOL has changed somewhat, but I don't think a load module would need
to be recompiled. I also believe one could still compile using old
compilers. VS COBOL was supposed to be converted to COBOL II and then
COBOL-for-MVS, but I think if some modules were overlooked they still
ran.
Please correct me if I'm wrong on this.
Peter Flass
As far as I know you're right. We are running some stuff that's using
BDAM, for heaven's sake, and it still runs fine. I think QTAM support
was ripped out a while ago.
Tony Harding
> ________________________________
> From: P S <zos...@GMAIL.COM>
> To: IBM-...@bama.ua.edu
> Sent: Thu, December 17, 2009 1:09:05 PM
> Subject: Re: 360 programs on a z/10
>
> There are some restrictions about doing so (ISAM and a few other BTAM and some code that was device dependent (like 2314 etc)).
> Just earlier this year I found a load module that was linked in 1972 and it still worked.
>
> The other sort of gotcha is date issues might have to be handled slightly different (ie 4 digit years) but all in all a simple cobol/assembler/fortran probably will still work unchanged.
>
> All in all a darn good dependable upwardly compatible (for the most part). IBM in my opinion has done a great service to the user community with OS - z/os.
Amen to that, Ed! I worked in the field for IBM 1965-70, and the
overriding word there regarding a major software conversion like 2nd
generation boxes to S/360 was "never again".
Bill
Anne & Lynn Wheeler
Tony Harding <toh...@universalexports.bogus.net> writes:
> Amen to that, Ed! I worked in the field for IBM 1965-70, and the
> overriding word there regarding a major software conversion like 2nd
> generation boxes to S/360 was "never again".
but that wasn't the refrain during the future system period in the 90s
... FS was going to be as different from s/360 ... and s/360 had been
from what had gone before. misc. past posts mentioning future system
effort:
http://www.garlic.com/~lynn/submain.html#futuresys
now amdahl claims that he never knew about future system effort ... he
left because they were going to build his advanced 360 computers.
however, he gave a talk in (large) MIT auditorium in the 70s. One of the
questions from the audience was how did he convince people to invest in
his clone processors. His reply was ... that even if IBM were to totally
walk away from 370 ... customers had already something like $200B
invested in 360/370 software ... which would keep him in business
through the end of the century (aka might be considered a veiled
reference to future system effort that was going on at the time). some
of that is made in this reference (including copy of old memo doing some
analysis of FS):
http://www.jfsowa.com/computer/memo125.htm
from above:
Of course, IBM could have delivered a machine with similar or better
performance in 1975 instead of 1977, if they hadn't killed all the
System/370 design projects to avoid competition with the FS fantasy.
... snip ...
the distraction/fantsy of FS ... allowed 370 product pipelines to go dry
... which has been used to explain how clone processors gained such a
market foothold.
another reference with some reference to FS:
http://www.ecole.org/Crisis_and_change_1995_1.htm
from above:
IBM tried to react by launching a major project called the 'Future
System' (FS) in the early 1970's. The idea was to get so far ahead
that the competition would never be able to keep up, and to have such
a high level of integration that it would be impossible for
competitors to follow a compatible niche strategy. However, the
project failed because the objectives were too ambitious for the
available technology. Many of the ideas that were developed were
nevertheless adapted for later generations. Once IBM had acknowledged
this failure, it launched its 'box strategy', which called for
competitiveness with all the different types of compatible
sub-systems. But this proved to be difficult because of IBM's cost
structure and its R&D spending, and the strategy only resulted in a
partial narrowing of the price gap between IBM and its rivals.
... snip ...
this has some reference to FS discussion from Morris & Fergus book:
http://www.garlic.com/~lynn/2001f.html#33
partial quote from Morris & Fergus comments
Basically they say that so much energy went into FS that s370 was
neglected, hence Japanese plug-compatibles got a good foothold in the
market; after FS's collapse a tribe of technical folks left IBM or when
into corporate seclusion; and perhaps most damaging, the old culture
under Watson Snr and Jr of free and vigourous debate was replaced with
sycophancy and "make no waves" under Opel and Akers. It's claimed that
thereafter, IBM lived in the shadow of defeat (by the FS failure)
... snip ...
hanc...@bbs.cpcn.com
>partial quote from Morris & Fergus comments
> Basically they say that so much energy went into FS that s370 was
> neglected, hence Japanese plug-compatibles got a good foothold in the
> market; after FS's collapse a tribe of technical folks left IBM or when
> into corporate seclusion; and perhaps most damaging, the old culture
> under Watson Snr and Jr of free and vigourous debate was replaced with
> sycophancy and "make no waves" under Opel and Akers. It's claimed that
> thereafter, IBM lived in the shadow of defeat (by the FS failure)
After reading Tom Watson's memoir ("Father Son & Co") I wonder how
much "free and vigorous debate" there actually was within IBM. Watson
Jr strongly implies his father was an autocrat, taking a strong
personal interest in all the company's activities, freely giving
orders as he saw fit, and not necessarily good ones.
Then Watson Jr liked to portray himself as more 'democratic' but he
too had a very strong temper and set attitudes. He admitted that his
fury over the CDC "janitor memo" contributed to IBM's promising 'paper
machines', and that he didn't treat the developer of the advanced
Stretch system properly. In other books, even favorable ones, they
talk about his nastiness. His push to get S/360 out the door before
it was ready hurt the careers of many employees, and even some of the
employees themselves with nervous breakdowns.
In the history of System/360, IBM jumped on his engineers for not
using more advanced ICs, even though his engineers were 100% correct
in what they chose and how they utilized it. (The more advanced ICs
simply weren't ready.)
I can't help but suspect that kind of leadership led to a chilling
effect when subsequent CEOs took over. Watson Jr claimed IBM was open
and didn't fire people, but getting on his bad side would surely mean
assignment to oblivion.
I think Watson's leadership also contributed to many IBMers eventually
leaving the company and going to the competition to build peripherals
and the like.
Anne & Lynn Wheeler
> I think Watson's leadership also contributed to many IBMers eventually
> leaving the company and going to the competition to build peripherals
> and the like.
re:
http://www.garlic.com/~lynn/2009s.html#60 360 programs on a z/10
I didn't have any knowledge of that. As undergraduate ... and doing
tty/ascii support for cp67 ... tried to get the 2702 to do something, it
couldn't quite do ... helped led to motivation to build clone controller
using Interdata/3 (four of us at the univ, later getting blamed for that
clone controller business) ... mentioned in a couple recent threads:
http://www.garlic.com/~lynn/2009s.html#29 channels, was Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2009s.html#53 DEC-10 SOS Editor Intra-Line Editing
Later at SJR (before research moved up the hill to almaden, was in
bldg. 28 on the main disk division plant site) ... i got involved doing
various things in the disk division & got to play disk engineer.
Among other things ... I would get requested to participate in
conference calls with channel engineers in POK. I once asked why I was
getting sucked into ... and was told that that had been previously been
handled by senior engineers ... but most of them had been hired
away. The atmosphere around silicon valley was startups offering lots of
compensation for experienced people ... not necessarily just larger
salaries ... but frequently also promises of large equity.
Disk division silicon valley during the go-go years ... was quite a bit
different from many other corporate locations (for instance, there were
some of us that would periodically go by Tandem on friday afternoons, to
see Jim, or the monthly baybunch user group meetings ... where there
would also be people from Amdahl and maybe NAS). People could change
employers several times w/o ever having to move.
There was some of that in boston area ... but not nearly as much. There
is the scenario where head of POK is considered a major contributer to
VMS ... because of convincing corporate to kill off vm370, shutdown
burlington mall development group and move everybody to POK (as
necessary to making the mvs/xa ship schedule) ... some number of people
left and went to work for DEC (on VMS) instead (Endicott eventually
managed to save the vm370 product mission but had to reconstitute a
group from scratch).
In any case, some of the other discussions about Future Systems claim a
major motivation for FS was the rise of the clone controllers (and
then the distraction of FS gave clone processors their opening)
http://www.garlic.com/~lynn/subtopic.html#futuresys
in the early 80s ... there was a mini-version ... after some number of
the 801/risc projects were being killed off, people were leaving (AMD,
HP, etc). some old email
http://www.garlic.com/~lynn/2003e.html#email811006
http://www.garlic.com/~lynn/2003e.html#email811006b
http://www.garlic.com/~lynn/2003e.html#email811113
http://www.garlic.com/~lynn/2003e.html#email811115
in this post
http://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
there were references wondering why I wasn't part of the exodus
... especially since info about this scenario had got some
dissemination
http://www.garlic.com/~lynn/2009r.htmL#50 "Portable" data centers
Charles Richmond
> On Dec 31 2009, 10:38 am, Anne & Lynn Wheeler <l...@garlic.com> wrote:
>> partial quote from Morris & Fergus comments
>> Basically they say that so much energy went into FS that s370 was
>> neglected, hence Japanese plug-compatibles got a good foothold in the
>> market; after FS's collapse a tribe of technical folks left IBM or when
>> into corporate seclusion; and perhaps most damaging, the old culture
>> under Watson Snr and Jr of free and vigourous debate was replaced with
>> sycophancy and "make no waves" under Opel and Akers. It's claimed that
>> thereafter, IBM lived in the shadow of defeat (by the FS failure)
>
> After reading Tom Watson's memoir ("Father Son & Co") I wonder how
> much "free and vigorous debate" there actually was within IBM. Watson
> Jr strongly implies his father was an autocrat, taking a strong
> personal interest in all the company's activities, freely giving
> orders as he saw fit, and not necessarily good ones.
>
> Then Watson Jr liked to portray himself as more 'democratic' but he
> too had a very strong temper and set attitudes. He admitted that his
> fury over the CDC "janitor memo" contributed to IBM's promising 'paper
> machines', and that he didn't treat the developer of the advanced
> Stretch system properly. In other books, even favorable ones, they
> talk about his nastiness. His push to get S/360 out the door before
> it was ready hurt the careers of many employees, and even some of the
> employees themselves with nervous breakdowns.
>
I have read an apocryphal story about Watson, Jr. being in a bad
mood, and calling in his managers to complain about the managers
wasting *paper* *clips*.
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
William Hamblen
<fri...@tx.rr.com> wrote:
>I have read an apocryphal story about Watson, Jr. being in a bad
>mood, and calling in his managers to complain about the managers
>wasting *paper* *clips*.
Alfred P Sloan is supposed to have sent GM execs a memo telling them
to use staples instead of paper clips, the reason being that paper
clips either dropped pages or picked up pages they weren't supposed
to.
Bud
Anne & Lynn Wheeler
William Hamblen <william...@earthlink.net> writes:
> Alfred P Sloan is supposed to have sent GM execs a memo telling them
> to use staples instead of paper clips, the reason being that paper
> clips either dropped pages or picked up pages they weren't supposed
> to.
there was some line about it costing GM >$270 some to process a purchase
order ... even if it involved a dozen pencils or box of paper clips (GM
had/has something like 60k suppliers).
this was motivation for business purchase cards ... basically a credit
card ... that had some additional tailored business rules on the backend
... as well as driver for level3 data for transactions.
basic credit card transaction for straight-forward authorization is
around 60 bytes; can include merchant code (merchant type) ... simplest
business rule is purchase card limited to specific kind of merchant
and/or max. value per transaction (in addition to standard credit
limit). level3 data would have the full itemized purchase with SKU
codes. business rules with level3 data could limit purchases to
specific (quantities) of product (in addition to specific merchant type,
specific merchant, and/or even specific merchant location).
to help cut the purchase order expense for GM ... as part of cost
reduction driving thru business purchase card ... credit (purchase) card
statements was converted to EDI and delivered to GM in (large batch)
electronic form directly into their standard EDI processing system.
Charlie Gibbs
william...@earthlink.net (William Hamblen) writes:
At least there was a somewhat reasonable excuse. At one PPOE I recall
that my boss and his boss would regularly spend $100 worth of time
arguing over a $10 item in the budget.
Patrick Scheible
> In article <v5tuj5l33t0l51ngb...@4ax.com>,
> william...@earthlink.net (William Hamblen) writes:
>
> > On Fri, 01 Jan 2010 18:49:43 -0600, Charles Richmond
> > <fri...@tx.rr.com> wrote:
> >
> >> I have read an apocryphal story about Watson, Jr. being in a bad
> >> mood, and calling in his managers to complain about the managers
> >> wasting *paper* *clips*.
> >
> > Alfred P Sloan is supposed to have sent GM execs a memo telling them
> > to use staples instead of paper clips, the reason being that paper
> > clips either dropped pages or picked up pages they weren't supposed
> > to.
>
> At least there was a somewhat reasonable excuse. At one PPOE I recall
> that my boss and his boss would regularly spend $100 worth of time
> arguing over a $10 item in the budget.
At my institution we are required to sign a statement that every long
distance call we made is work-related. We enter a long-distance call
authorization code when we make the call. Then our budget officer,
who makes professional wages, xeroxes off each person's section of the
long-distance bill and mails it to us with a form to sign. Probably
$20 worth of the budget officer's time, the caller's time, and paper,
even if the caller has only a couple of cents worth of calls. I
expect it's a leftover state-mandated policy from when long distance
was really expensive.
-- Patrick
Anne & Lynn Wheeler
Patrick Scheible <k...@zipcon.net> writes:
> At my institution we are required to sign a statement that every long
> distance call we made is work-related. We enter a long-distance call
> authorization code when we make the call. Then our budget officer,
> who makes professional wages, xeroxes off each person's section of the
> long-distance bill and mails it to us with a form to sign. Probably
> $20 worth of the budget officer's time, the caller's time, and paper,
> even if the caller has only a couple of cents worth of calls. I
> expect it's a leftover state-mandated policy from when long distance
> was really expensive.
when vp sign-off was required to get 3270 terminal on desk ... i showed
that 3yr capital depreciation for 3270 was about same as monthly cost of
business phone ... which came standard on everybodys' desk ... w/o
2nd thot. some recent posts:
http://www.garlic.com/~lynn/2009l.html#41 another item related to ASCII vs. EBCDIC
http://www.garlic.com/~lynn/2009q.html#49 The 50th Anniversary of the Legendary IBM 1401
http://www.garlic.com/~lynn/2009q.html#50 The 50th Anniversary of the Legendary IBM 1401
a lot of 3270s were actually in use for 6-10 yrs
recent reference to jim's "mip envy"
http://www.garlic.com/~lynn/2009q.html#49 The 50th Anniversary of the Legendary IBM 1401
20sep80 version of jim's "mip envy"
http://www.garlic.com/~lynn/2007d.html#email800920
and a 24sep80 version
http://research.microsoft.com/~gray/papers/CritiqueOfIBM%27sCSResearch.doc
3270 capital planning was also part of annual budget planning ... which
was problem when management/executives decided that they needed (annual)
3270 terminals rerouted to their desk ... recent reference:
http://www.garlic.com/~lynn/2010.html#5 DEC-10 SOS Editor Intra-Line Editing
other posts in this thread:
http://www.garlic.com/~lynn/2009r.html#52 360 programs on a z/10
http://www.garlic.com/~lynn/2009r.html#57 360 programs on a z/10
http://www.garlic.com/~lynn/2009r.html#68 360 programs on a z/10
http://www.garlic.com/~lynn/2009r.html#69 360 programs on a z/10
http://www.garlic.com/~lynn/2009s.html#60 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#4 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#9 360 programs on a z/10
misc. other posts mentioning mip envy:
http://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
http://www.garlic.com/~lynn/2002k.html#39 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002o.html#73 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2002o.html#75 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2004c.html#15 If there had been no MS-DOS
http://www.garlic.com/~lynn/2004l.html#28 Shipwrecks
http://www.garlic.com/~lynn/2004l.html#31 Shipwrecks
http://www.garlic.com/~lynn/2005c.html#50 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005u.html#41 Mainframe Applications and Records Keeping?
http://www.garlic.com/~lynn/2006n.html#26 sorting was: The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006o.html#50 When Does Folklore Begin???
http://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing
http://www.garlic.com/~lynn/2007d.html#45 Is computer history taugh now?
http://www.garlic.com/~lynn/2007d.html#63 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#50 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#13 Why is switch to DSL so traumatic?
http://www.garlic.com/~lynn/2007f.html#70 Is computer history taught now?
http://www.garlic.com/~lynn/2009l.html#41 another item related to ASCII vs. EBCDIC
http://www.garlic.com/~lynn/2009p.html#8 WSJ.com - IBM Puts Executive on Leave
Walter Bushell
Patrick Scheible <k...@zipcon.net> wrote:
Maybe, if you do work for the government. Cheaper would be an unlimited
cell phone. But yes, I remember when a long distance call was a *big*
deal, my parents would place long distance calls on holidays. But stamps
were 3 cents, now a 3 cent stamp costs like 50 cents.
--
A computer without Microsoft is like a chocolate cake without mustard.
Anne & Lynn Wheeler
Walter Bushell <pr...@panix.com> writes:
> Maybe, if you do work for the government. Cheaper would be an unlimited
> cell phone. But yes, I remember when a long distance call was a *big*
> deal, my parents would place long distance calls on holidays. But stamps
> were 3 cents, now a 3 cent stamp costs like 50 cents.
and hotels had 300% surchange on long distance calls. i remember making
a $40 call from hotel in Germany in the early 70s ... and the hotel
billed over $100 for it.
Anne & Lynn Wheeler
Anne & Lynn Wheeler <ly...@garlic.com> writes:
> but that wasn't the refrain during the future system period in the 90s
> ... FS was going to be as different from s/360 ... and s/360 had been
> from what had gone before. misc. past posts mentioning future system
> effort:
> http://www.garlic.com/~lynn/submain.html#futuresys
re:
http://www.garlic.com/~lynn/2009s.html#60 360 programs on a z/10
during future system years ... I would sometimes draw parallels
between FS effort and a cult film that had been playing down
in central sq. for several years.
later when I sponsored Boyd's briefings at IBM ... Boyd would tell this
story about reviewing the specs on the airforce air-to-air missile that
would be used in vietnam ... which seemed to carry some fantasy
aspect ... similar to some of others comments about FS
http://www.jfsowa.com/computer/memo125.htm
partial retelling of the (vietnam airforce air-to-air missile) story:
http://www.garlic.com/~lynn/2008c.html#52 Current Officers
which also had more than a little "fantasy" aspect to it.
other recent reference to Boyd:
http://www.garlic.com/~lynn/2009r.html#50 "Portable" data centers
past posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd1
misc. URLs from around the web mentioning Boyd (&/or his OODA-loops):
http://www.garlic.com/~lynn/subboyd.html#boyd2
Walter Bushell
Anne & Lynn Wheeler <ly...@garlic.com> wrote:
> Walter Bushell <pr...@panix.com> writes:
> > Maybe, if you do work for the government. Cheaper would be an unlimited
> > cell phone. But yes, I remember when a long distance call was a *big*
> > deal, my parents would place long distance calls on holidays. But stamps
> > were 3 cents, now a 3 cent stamp costs like 50 cents.
>
> and hotels had 300% surchange on long distance calls. i remember making
> a $40 call from hotel in Germany in the early 70s ... and the hotel
> billed over $100 for it.
And the more you pay for a hotel room the bigger the charges for such
services like phone or internet. I suppose if you are paying $300+ for a
room they can gouge you, Motel 8 not so much.
Anne & Lynn Wheeler
Walter Bushell <pr...@panix.com> writes:
> And the more you pay for a hotel room the bigger the charges for such
> services like phone or internet. I suppose if you are paying $300+ for a
> room they can gouge you, Motel 8 not so much.
re:
http://www.garlic.com/~lynn/2010.html#16 360 programs on a z/10
early 70s, it was relatively new 3-4 story bldg. in residential section
of sindelfingen (outside stuttgart, near boeblingen plant site), seemed
to be "business" person hotel ... almost no english spoken (look out
window in the morning and see the children on the way to school). in the
80s there were a number of american businesses that had been established
in the boeblingen/sindelfingen area ... and even "american" brand hotels
... but not in the early 70s.
such exorbitant surcharges was common back then ... could easily be
larger than daily room rate. I vaguely remember something ... possibly
in the late 80s ... when there was big push back against such huge hotel
long distance surcharges.
beoblingen was paying my way over to talk to them about vm370 systems.
while I was there I got a call asking if I could stop by paris on my way
back ... and look at the (vm370-based) HONE system going in (it was part
of transfer of EMEA hdqtrs from westchester to europe).
EMEA hdqtrs HONE was going into brand new three office bldg. complex in
La Defense (two of the bldgs. hadn't been finished and landscaping
hadn't even been started). Since there was no other facilities in the
area yet ... they put me up in Paris hotel within a block or two of RER
station (& the opera, and american express office) and I would take
train over to the La Defense & walk.
misc. past posts mentioning (virtual machine based) HONE system
http://www.garlic.com/~lynn/subtopic.html#hone
Charles Richmond
> On 2010-01-02, Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>> In article <v5tuj5l33t0l51ngb...@4ax.com>,
>> william...@earthlink.net (William Hamblen) writes:
>>
>>> On Fri, 01 Jan 2010 18:49:43 -0600, Charles Richmond
>>> <fri...@tx.rr.com> wrote:
>>>
>>>> I have read an apocryphal story about Watson, Jr. being in a bad
>>>> mood, and calling in his managers to complain about the managers
>>>> wasting *paper* *clips*.
>>> Alfred P Sloan is supposed to have sent GM execs a memo telling them
>>> to use staples instead of paper clips, the reason being that paper
>>> clips either dropped pages or picked up pages they weren't supposed
>>> to.
>> At least there was a somewhat reasonable excuse. At one PPOE I recall
>> that my boss and his boss would regularly spend $100 worth of time
>> arguing over a $10 item in the budget.
>
> query a 20c discrepancy on my expenses.
>
>
<story>
Worker: "At some point, you're just going to have to trust people."
Boss: "That's funny. That's exactly what the private detective said."
</story>
Charles Richmond
:-)
My mom and dad stopped at a Dairy Queen in the 80's.
Mom: What do you want???
Dad: How much is a fifteen cent cone??? (That used to be the
largest size.)
Mom: Eighty-five cents.
Dad: Okay, I'll take a fifteen cent cone.
Long distance calls *were* expensive and they were used for
"important" things: the birth of a child, the death of a
grandfather, the illness of an aunt, occasionally a Merry
Christmas or a Happy Birthday. If you received a long distance
call, you *knew* it was something significant.
hanc...@bbs.cpcn.com
> I have read an apocryphal story about Watson, Jr. being in a bad
> mood, and calling in his managers to complain about the managers
> wasting *paper* *clips*.
I read a real story that might have been the basis of that.
Watson Jr was visiting a branch office which was a very nicely
furnished space. The branch mgrs were showing him all the niceties.
He picked up some paper clips out of the wastebasket, played with them
a bit, then asked, "tell me, do you people do any work around
here?" (Forgot the book, but it was a pro-IBM method writeup).
I think evaluating Watson Jr is like evaluating General Patton.
Obviously, like Patton, Watson had many talents and accomplished a
great deal. Whether he took the best path to greatness is debatable.
As to Patton, some say he was reckless with the lives of his men since
he pushed too hard. But others say his aggressive pushing saved more
men in the long run as it was a better strategy. Who's right?
Hindsight is 20/20.
Note that both Patton and Montgomery agreed that the best approach was
a spearhead across Europe into Germany. They disagreed on who should
lead it, each wanted to be the sole leader of the action. Eisenhower
overruled both and ordered a broad approach. Was Eisenhower or Patton
correct? Again, Hindsight is 20/20.
Back to Watson, should he have delayed his System/360 announcement
about a year to allow the development to proceed in a more orderly
fashion? Or maybe it worked out better the way it did, squeezing out
a DOS real quick that turned out to be a great os for smaller users?
hanc...@bbs.cpcn.com
> there was some line about it costing GM >$270 some to process a purchase
> order ... even if it involved a dozen pencils or box of paper clips (GM
> had/has something like 60k suppliers).
An average number like that is meaningless and deceiving.
First, I strongly suspect if a particular office at GM was out of
paper clips, someone ran out to a store and buy some out of petty
cash.
Second, that figure is an average of all procurement, so it's not only
a box of paperclips, but also an enormous amount of steel, glass, and
other raw materials in which procurement was a negotiated effort with
the suppliers, and cost a heck of a lot more than $270.
A more accurate figure would be the percentage of the purchase price
procurement efforts cost.
hanc...@bbs.cpcn.com
> At my institution we are required to sign a statement that every long
> distance call we made is work-related. . . .
> I expect it's a leftover state-mandated policy from when long distance
> was really expensive.
Do they _still_ do that today? At one time years ago that was
standard procedure at all companies, but in the last ten years or so
that procedure was dropped when long distance calls cost 2c a minute
or less.
hanc...@bbs.cpcn.com
> Maybe, if you do work for the government. Cheaper would be an unlimited
> cell phone. But yes, I remember when a long distance call was a *big*
> deal, my parents would place long distance calls on holidays. But stamps
> were 3 cents, now a 3 cent stamp costs like 50 cents.
Just a precaution--some cell phone carriers today consider holidays as
regular day rate, not offpeak weekend rates, as many people assume.
If your cellphone has peak minutes limits, be careful on holidays.
Going back to the 1950s, it was cheaper to send a telegram than make a
long distance telephone call. Around 1960 telephone toll charges
dropped while telegraph rates went up changing the break even point in
favor of the long distance call. In 1960 Western Union realized the
classic message telegram was obsolete and was focusing on other
communications, such as fax and data.
Anne & Lynn Wheeler
> An average number like that is meaningless and deceiving.
>
> First, I strongly suspect if a particular office at GM was out of
> paper clips, someone ran out to a store and buy some out of petty
> cash.
>
> Second, that figure is an average of all procurement, so it's not only
> a box of paperclips, but also an enormous amount of steel, glass, and
> other raw materials in which procurement was a negotiated effort with
> the suppliers, and cost a heck of a lot more than $270.
>
> A more accurate figure would be the percentage of the purchase price
> procurement efforts cost.
re:
http://www.garlic.com/~lynn/2010.html#9 360 programs on a z/10
i was told that it had been the base cost of doing purchase order
processing ... all the other stuff would have been on top of the base
processing.
it was major motivation for commercial purchase cards
some discussions of purchase cards and level 2/3 data
http://www.gotmerchant.com/level3_credit_card_processing.php
Purchase cards, GSA SmartPay, and Level 2 & 3 credit
card processing ("feds save $1B in 2006 using p-cards")
http://www.braintreepaymentsolutions.com/blog/purchase-cards-gsa-smartpay-and-level-2-3-credit-card-processing/
as mentioned ... one of the "special" things done for GM was converting
(commercial/payment) credit card statements into (GMs) EDI 8x0 records
... vendor web pages talking about gm edi solutions:
http://www.dicentral.com/general_motor_edi/
http://www.123edi.com/partners/edi-general-motors.asp
http://www.edipipeline.com/General_Motors.asp
http://www.infoconn.com/EDI/Partners/General_Motors.htm
hanc...@bbs.cpcn.com
> Long distance calls *were* expensive and they were used for
> "important" things: the birth of a child, the death of a
> grandfather, the illness of an aunt, occasionally a Merry
> Christmas or a Happy Birthday. If you received a long distance
> call, you *knew* it was something significant.
After the end of WW II, the old Bell System implemented numerous
technological improvements to the long distance network in terms of
both switching and transmission that significantly lowered the cost
per call. The rates to the public were lowered, too, which included
reduced rates at night and on weekends (when the plant wasn't tied up
with business calls).
It's hard to believe but at one time long distance calls were placed
by advance appointment since network capacity was so limited.
Microwave and coax allowed high capacity lines, and automated toll
switching eliminated expensive labor intensive operator handling. It
took time to implement all this nation wide.
By the mid 1960s rates had dropped enough so that people were using
long distance for some social conversation. Obviously this was done
more with relatives who lived 50 miles away than with those 3,000
miles away as toll rates varied by distance.
Around 1971 the Bell System implemented a major rate reduction and
rate structure change. All dialed direct calls became a minute
minimum instead of three minutes. Weekend and late-night calls dialed
direct calls became quite cheap, as low as 5c a minute for short
distances. This was a boon to college kids who were often up late at
night. (If direct dialing wasn't available the rates still applied).
For businesses, in addition to the above, rates for inward and outward
WATS dropped and new private switched trunking arrangements were
offered.
Around 1960 both the Bell System and IBM had introduced regular
products for computers to "talk" to each other. Specialty products
had been available for a while. I remember my savings bank updating
our passbooks with an IBM Selectric terminal and our commercial bank
getting current account balances via a Touch Tone pad and audio
responses in 1965-1966. (The TT pad was separate next to a regular
dial phone; our neighborhood didn't have TT service yet.) As
mentioned, in the 1960s Western Union sought hard to be part of data
communications but things didn't work out for them.
Anne & Lynn Wheeler
> as mentioned ... one of the "special" things done for GM was converting
> (commercial/payment) credit card statements into (GMs) EDI 8x0 records
> ... vendor web pages talking about gm edi solutions:
> http://www.dicentral.com/general_motor_edi/
> http://www.123edi.com/partners/edi-general-motors.asp
> http://www.edipipeline.com/General_Motors.asp
> http://www.infoconn.com/EDI/Partners/General_Motors.htm
re:
http://www.garlic.com/~lynn/2010.html#9 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#24 360 programs on a z/10
lots of business pushed to have things all done thru EDI 8x0 records
... significantly reducing cost of processing.
however, there was still a lot of transactions with suppliers that
weren't setup to do things via EDI ... like local retail outlets.
the commercial/purchase credit cards ... could be setup with real-time
authorization business rules (based on level 2&3 dat) ... and have the
credit card issuer do the conversion of credit card statements into EDI
8x0 records.
the credit card processors got new transactions (and fees) ... and the
businesses got real-time authorization business rules ... and conversion
of lots of stuff to EDI ... that had been resistant/difficult otherwise.
merchant POS terminals had to be upgraded to supply level 2 (& possibly
level 3) data ... but it wasn't as if it was data that they weren't
already processing (for other reasons).
EDI wiki page
http://en.wikipedia.org/wiki/Electronic_Data_Interchange
X12 EDIFACT Mapping
http://en.wikipedia.org/wiki/X12_EDIFACT_Mapping
EDI standards body
http://www.x12.org/x12org/index.cfm
Joe Pfeiffer
>
> Note that both Patton and Montgomery agreed that the best approach was
> a spearhead across Europe into Germany. They disagreed on who should
> lead it, each wanted to be the sole leader of the action. Eisenhower
> overruled both and ordered a broad approach. Was Eisenhower or Patton
> correct? Again, Hindsight is 20/20.
And we do know that Eisenhower was correct "enough". And that's what
really counts.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
Charles Richmond
> hanc...@bbs.cpcn.com writes:
>> Note that both Patton and Montgomery agreed that the best approach was
>> a spearhead across Europe into Germany. They disagreed on who should
>> lead it, each wanted to be the sole leader of the action. Eisenhower
>> overruled both and ordered a broad approach. Was Eisenhower or Patton
>> correct? Again, Hindsight is 20/20.
>
> And we do know that Eisenhower was correct "enough". And that's what
> really counts.
Is it really enough??? If *many* more lives could have been saved
by doing things a different way and *still* succeeding... would
that *not* have been better???
Patrick Scheible
> On Jan 2, 7:36=A0pm, Patrick Scheible <k...@zipcon.net> wrote:
>
> > At my institution we are required to sign a statement that every long
> > distance call we made is work-related. =A0. . .
> > I expect it's a leftover state-mandated policy from when long distance
> > was really expensive.
>
> Do they _still_ do that today? At one time years ago that was
> standard procedure at all companies, but in the last ten years or so
> that procedure was dropped when long distance calls cost 2c a minute
> or less.
As of a couple of months ago, they do. Since then I haven't had any
long distance calls.
It's crazy.
-- Patrick
Joe Pfeiffer
> Joe Pfeiffer wrote:
>> hanc...@bbs.cpcn.com writes:
>>> Note that both Patton and Montgomery agreed that the best approach was
>>> a spearhead across Europe into Germany. They disagreed on who should
>>> lead it, each wanted to be the sole leader of the action. Eisenhower
>>> overruled both and ordered a broad approach. Was Eisenhower or Patton
>>> correct? Again, Hindsight is 20/20.
>>
>> And we do know that Eisenhower was correct "enough". And that's what
>> really counts.
>
> Is it really enough??? If *many* more lives could have been saved by
> doing things a different way and *still* succeeding... would that
> *not* have been better???
Of course it would. But that really was a situation where winning at
pretty much any cost was infinitely better than losing. Even if it
could be established that either the Patton or Montgomery strategies
would have cost 1/100th the lives, Eisenhower would still have been
right enough.
Morten Reistad
<hanc...@bbs.cpcn.com> wrote:
>On Jan 3, 8:40�pm, Charles Richmond <friz...@tx.rr.com> wrote:
>
>> Long distance calls *were* expensive and they were used for
>> "important" things: �the birth of a child, the death of a
>> grandfather, the illness of an aunt, occasionally a Merry
>> Christmas or a Happy Birthday. If you received a long distance
>> call, you *knew* it was something significant.
My grand uncle, Michael Eide, emigrated to the US in 1922, and
used to call back to relatives every Christmas from approx 1950
until his death in 1972. He was on the phone for about one hour,
taking hist time with everyone. Those calls must have cost a fortune,
and they became an important part of Christmas celebrations.
There was significant radio noise on the calls, so it must have
been troposcatter or shortwave transmissions. In the middle of
the winter the conditions for these are usually very good across the
Arctic.
>After the end of WW II, the old Bell System implemented numerous
>technological improvements to the long distance network in terms of
>both switching and transmission that significantly lowered the cost
>per call. The rates to the public were lowered, too, which included
>reduced rates at night and on weekends (when the plant wasn't tied up
>with business calls).
>
>It's hard to believe but at one time long distance calls were placed
>by advance appointment since network capacity was so limited.
Uncle Michel ended every Christmas call by making an appointment
for NEXT Christmas, and that was barely in time some years.
>Microwave and coax allowed high capacity lines, and automated toll
>switching eliminated expensive labor intensive operator handling. It
>took time to implement all this nation wide.
But for outlying regions and overseas traffic shortwave and troposcatter
remained important technologies until the implementation of transocean
fiber links around 1990.
-- mrr
Anne & Lynn Wheeler
Charles Richmond <fri...@tx.rr.com> writes:
> Is it really enough??? If *many* more lives could have been saved by
> doing things a different way and *still* succeeding... would that
> *not* have been better???
one of boyd's stories about ww2 ... was US running ww2 on mass hordes,
overwhelming resources, and logistics (because it didn't people to run
it based on "skills"). one example he used was sherman tank that was
significantly overmatched ... but US could produce them at ten times the
rate of german tanks ... and so could win via attrition (modulo issue
with morale among tank crews that were being used as cannon fodder).
i had uncle that spent couple yrs during ww2 in europe as tank mechanic
... he was big ... which is possibly reason that ruled him out as being
co'opted for tank crew (stories about everybody being co'opted for tank
crew, including cooks ... they lost lots of crews and tanks ... but
apparently the new tanks kept arriving faster than they could find
replacement crews).
misc. past posts mentioning boyd (&/or ooda-loops)
http://www.garlic.com/~lynn/subboyd.html
misc. past posts mentioning boyd's sherman story:
http://www.garlic.com/~lynn/2000c.html#85 V-Man's Patton Quote (LONG) (Pronafity)
http://www.garlic.com/~lynn/2001.html#30 Review of Steve McConnell's AFTER THE GOLD RUSH
http://www.garlic.com/~lynn/2001m.html#3 mainframe question
http://www.garlic.com/~lynn/2001m.html#10 mainframe question
http://www.garlic.com/~lynn/2001m.html#11 mainframe question
http://www.garlic.com/~lynn/2001m.html#16 mainframe question
http://www.garlic.com/~lynn/2003n.html#27 Controversial paper - Good response article on ZDNet
http://www.garlic.com/~lynn/2004b.html#24 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004g.html#53 Chained I/O's
http://www.garlic.com/~lynn/2004l.html#19 FW: Looking for Disk Calc program/Exec (long)
http://www.garlic.com/~lynn/2005j.html#11 The 8008
http://www.garlic.com/~lynn/2005j.html#14 The 8008
http://www.garlic.com/~lynn/2006f.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006q.html#28 was change headers: The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2008g.html#21 WWII supplies
http://www.garlic.com/~lynn/2008j.html#11 To: Graymouse -- Ireland and the EU, What in the H... is all this about?
http://www.garlic.com/~lynn/2008j.html#21 To: Graymouse -- Ireland and the EU, What in the H... is all this about?
http://www.garlic.com/~lynn/2008q.html#17 realtors (and GM, too!)
Anne & Lynn Wheeler
> overwhelming resources, and logistics (because it didn't people to run
> it based on "skills"). one example he used was sherman tank that was
> significantly overmatched ... but US could produce them at ten times the
> rate of german tanks ... and so could win via attrition (modulo issue
> with morale among tank crews that were being used as cannon fodder).
re:
http://www.garlic.com/~lynn/2010.html#28 360 programs on a z/10
there are various stories that for "desert storm" (previous middle east
conflict) boyd's battle plan won out against up-the-middle tank battle &
slug it out until last man standing (as well as some quotes about
problem with current conflict was that boyd had died in '97) ...
http://findarticles.com/p/articles/mi_m1571/is_32_18/ai_91210683/
http://www.freerepublic.com/focus/news/732364/posts
http://www.statemaster.com/encyclopedia/John-Boyd-%28military-strategist%29
Anne & Lynn Wheeler
Boyd's tactics and Operation Iraqi Freedom (illuminating background on
Iraq strategy)
http://www.freerepublic.com/focus/news/899525/posts
from above:
Lamb: What part of the Gulf War in 1991 plan did John Boyd have some responsibility for?
Coram: All of it. The multiple thrust, the feints, the ambiguity, the Marine feint, the ...
Lamb: You mean the landing in Kuwait, the early landing?
Coram: Yes. Yes.
Lamb: That was his idea?
Coram: It was his idea. He was behind every bit of it.
... snip ..
jmfbahciv
> Joe Pfeiffer wrote:
>> hanc...@bbs.cpcn.com writes:
>>> Note that both Patton and Montgomery agreed that the best approach was
>>> a spearhead across Europe into Germany. They disagreed on who should
>>> lead it, each wanted to be the sole leader of the action. Eisenhower
>>> overruled both and ordered a broad approach. Was Eisenhower or Patton
>>> correct? Again, Hindsight is 20/20.
>>
>> And we do know that Eisenhower was correct "enough". And that's what
>> really counts.
>
> Is it really enough??? If *many* more lives could have been saved by
> doing things a different way and *still* succeeding... would that *not*
> have been better???
>
You are unbelievable. Do you really wish that Europe dithered until
after Germany had the atomic bomb?
/BAH
Howard Brazee
wrote:
>At least there was a somewhat reasonable excuse. At one PPOE I recall
>that my boss and his boss would regularly spend $100 worth of time
>arguing over a $10 item in the budget.
Sometimes that is a worthwhile investment, when we include the benefit
of getting them out of the workers' way.
Howard Brazee
>Around 1971 the Bell System implemented a major rate reduction and
>rate structure change. All dialed direct calls became a minute
>minimum instead of three minutes. Weekend and late-night calls dialed
>direct calls became quite cheap, as low as 5c a minute for short
>distances. This was a boon to college kids who were often up late at
>night. (If direct dialing wasn't available the rates still applied).
The competition of "free" long distance calls for cellular phones and
Internet phones hasn't yet finished this process.
Howard Brazee
>When I worked for Xerox, my boss made an international telephone call to
>query a 20c discrepancy on my expenses.
When I worked for EDS, I got called up because my meal expenses were
whole dollar amounts. We were expected to calculate tips to the
penny instead of rounding them. Who does that?
Howard Brazee
<pfei...@cs.nmsu.edu> wrote:
>> Note that both Patton and Montgomery agreed that the best approach was
>> a spearhead across Europe into Germany. They disagreed on who should
>> lead it, each wanted to be the sole leader of the action. Eisenhower
>> overruled both and ordered a broad approach. Was Eisenhower or Patton
>> correct? Again, Hindsight is 20/20.
>
>And we do know that Eisenhower was correct "enough". And that's what
>really counts.
Unless we were one of the casualties who might have been better off
with a "better" way.
Howard Brazee
<ly...@garlic.com> wrote:
>one of boyd's stories about ww2 ... was US running ww2 on mass hordes,
>overwhelming resources, and logistics (because it didn't people to run
>it based on "skills"). one example he used was sherman tank that was
>significantly overmatched ... but US could produce them at ten times the
>rate of german tanks ... and so could win via attrition (modulo issue
>with morale among tank crews that were being used as cannon fodder).
Even more important than out-tanking the enemy was out-Jeeping them.
Morten Reistad
Charles Richmond <fri...@tx.rr.com> wrote:
>Joe Pfeiffer wrote:
>> hanc...@bbs.cpcn.com writes:
>>> Note that both Patton and Montgomery agreed that the best approach was
>>> a spearhead across Europe into Germany. They disagreed on who should
>>> lead it, each wanted to be the sole leader of the action. Eisenhower
>>> overruled both and ordered a broad approach. Was Eisenhower or Patton
>>> correct? Again, Hindsight is 20/20.
>>
>> And we do know that Eisenhower was correct "enough". And that's what
>> really counts.
>
>Is it really enough??? If *many* more lives could have been saved
>by doing things a different way and *still* succeeding... would
>that *not* have been better???
The Germans could offer significant resistance until January of
1945. Go read what the Ardenner offensive did to Eisenhower's
broad front. Now imagine what it would do to Patton's forces,
or Monty's for that matter if they had indeed done such a spearhead.
The path through the lower German-French part of the Rhine was the
only thinkable one; paths through BeNeLux would have dragged the
fighting there. The Germans did their best to acheive just that,
and bog the allied fighting down on what was allied territory.
Further up would have led them on a long forest detour. WW2 had
too many detours already by that time.
So, with hindsight, we can go for Eisenhower's call.
-- mrr
hanc...@bbs.cpcn.com
> My grand uncle, Michael Eide, emigrated to the US in 1922, and
> used to call back to relatives every Christmas from approx 1950
> until his death in 1972. He was on the phone for about one hour,
> taking hist time with everyone. Those calls must have cost a fortune,
> and they became an important part of Christmas celebrations.
If you're talking about an overseas call in 1950, the cost was about
$4/minute, so a 60 minute call was $240, roughly $3,000 in today's
dollars. Awfully expensive.
> There was significant radio noise on the calls, so it must have
> been troposcatter or shortwave transmissions. In the middle of
> the winter the conditions for these are usually very good across the
> Arctic.
The History of Eng & Sci in the Bell System describes the radio
telephone system used for overseas calls. It was a combination of
shortwave and longwave depending on the best atmospheric conditions
available when the call was placed. It appears every call had to be
hand-monitored by technicians to maximize transmission quality. There
was a crude encryption applied to the calls so that a casual radio
listener couldn't understand the conversation.
About 1956 Bell completed a trans-oceanic cable which increased
capacity and reduced noise.
> Uncle Michel ended every Christmas call by making an appointment
> for NEXT Christmas, and that was barely in time some years.
In the 1960s more cables were laid and satellites were implemented.
By the 1970s capacity had increased to the extent that appointments
for calls to certain places were no longer necessary. Technology
improved so that local operators could place certain calls (eg
Britain, France) without going through an overseas operator.
(However, in the 1970s calls to 3rd world and communist countries
required some set up.)
Continued added capacity and cost reduction allowed for dramatic
reductions in overseas call rates. New technology allowed callers to
dial their own calls directly to certain overseas points.
I don't think they even have overseas operators today.
> But for outlying regions and overseas traffic shortwave and troposcatter
> remained important technologies until the implementation of transocean
> fiber links around 1990.
I believe shortwave radio was eliminated once the underseas cable were
confirmed to be superior and shut down in the 1950s.
Gene Wirchenko
>On Jan 2, 11:54�am, Anne & Lynn Wheeler <l...@garlic.com> wrote:
>
>> there was some line about it costing GM >$270 some to process a purchase
>> order ... even if it involved a dozen pencils or box of paper clips (GM
>> had/has something like 60k suppliers).
Why would GM buy a box of paperclips on one PO? They probably
bought thousands of boxes at once.
>An average number like that is meaningless and deceiving.
>
>First, I strongly suspect if a particular office at GM was out of
>paper clips, someone ran out to a store and buy some out of petty
>cash.
More likely for an operation that size that they would go to
Supplies.
[snip]
Sincerely,
Gene Wirchenko
Howard Brazee
>>>> Note that both Patton and Montgomery agreed that the best approach was
>>>> a spearhead across Europe into Germany. They disagreed on who should
>>>> lead it, each wanted to be the sole leader of the action. Eisenhower
>>>> overruled both and ordered a broad approach. Was Eisenhower or Patton
>>>> correct? Again, Hindsight is 20/20.
>>>
>>> And we do know that Eisenhower was correct "enough". And that's what
>>> really counts.
>>
>> Is it really enough??? If *many* more lives could have been saved by
>> doing things a different way and *still* succeeding... would that *not*
>> have been better???
>>
>
>You are unbelievable. Do you really wish that Europe dithered until
>after Germany had the atomic bomb?
He implied nothing of the kind. The question was - if, say, Patton
and Montgomery were right, that the war could have been won quicker
with fewer casualties - wouldn't that have been better?
Anne & Lynn Wheeler
Howard Brazee <howard...@cusys.edu> writes:
> Even more important than out-tanking the enemy was out-Jeeping them.
re:
http://www.garlic.com/~lynn/2010.html#17 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#28 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#29 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#30 360 programs on a z/10
there was story about marines being forced into some number of
Abrams. the issue was that Abrams contract called for per tank discount
above some minimum number ... which the army didn't quite justify ... in
order to get the total up to the minimum, the marines had to take
a few. ... this mentions 4796 for the army and 221 for the marines
(would 5000 have been contract minimum for discount?)
http://www.army-technology.com/projects/abrams/
the problem for the marines is that they traditionally have a very
different mission profile than the army ... well over 90% of their
mission profiles are in areas with 30-35ton load limit ... and the
Abrams runs 65-70 tons. they had to spend big part of their budget on
something they couldn't use (other than as supporting some army
operation), as well as the people needed to populate the tank corp, as
well as not buying what they really needed (trivial example, I remember
a relative commenting that their army unit had larger computer
allocation than the whole marine corp).
along the lines of earmarks and directed appropriations ... not so bad
if there is actual additional money ... but can get really bad when
department isn't allocated any additional money ... but is directed on
how they spend their existing money. in the mid-90s we visited
department that had built large, new, expensive marble bldg ... which
was mostly empty. People that were there complained that they didn't
need the bldg ... they needed their regular budget to do things that the
department was suppose to do. Instead, congress had directed that major
portion of departments budget go for the new building (subsidy by some
congressman to builder in his state that got the contract).
Charlie Gibbs
(Patrick Scheible) writes:
Today's hardware and software makes call tracking so easy that
many bureaucrats do it for the same reason that dogs lick their
balls: because they can. I can't complain too much, though -
it's my bread and butter. And there are good uses for call
data recording, e.g. efficient allocation of resources. As
the Firesign Theatre once said, it's "a power so great it can
only be used for good or evil."
--
/~\ 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
howard...@cusys.edu (Howard Brazee) writes:
<chuckle>
One of my fondest fantasies is to be able to isolate all politicians
in a world of their own, where they can pass silly bills, filibuster,
and play all of their other little games without affecting the rest
of us.
Charlie Gibbs
(Anne & Lynn Wheeler) writes:
> Walter Bushell <pr...@panix.com> writes:
>
>> Maybe, if you do work for the government. Cheaper would be an
>> unlimited cell phone. But yes, I remember when a long distance
>> call was a *big* deal, my parents would place long distance
>> calls on holidays. But stamps were 3 cents, now a 3 cent stamp
>> costs like 50 cents.
>
> and hotels had 300% surchange on long distance calls. i remember
> making a $40 call from hotel in Germany in the early 70s ... and
> the hotel billed over $100 for it.
This still happens a lot. Our software does this sort of number
crunching at a lot of hotels; we provide a table in which they can
fill in whatever markups and surcharges they want, and the values
some of them put in are pretty stiff. In fact, if there's a problem
with the software (unlikely) or the data feeds (more likely), they
usually call us much faster than our office customers, since it's
an actual revenue source.
It's starting to backfire, though - now that cell phones are so
widespread (and rates are dropping), more and more people choose
to use their cell phone instead of the room phone.
Charlie Gibbs
<d8fbedf2-811c-488d...@m25g2000yqc.googlegroups.com>,
hanc...@bbs.cpcn.com (hancock4) writes:
> If you're talking about an overseas call in 1950, the cost was about
> $4/minute, so a 60 minute call was $240, roughly $3,000 in today's
> dollars. Awfully expensive.
I was paying three or four dollars a minute to call from B.C. to
the UK in the late '70s - and that was direct dialed.
Calls from one end of Canada to the other were $1.10/minute in 1985.
Patrick Scheible
If they could tell that for sure, yes, but nothing is certain in war.
If Patton ran into trouble, Eisenhower could have put more into
Montgomery's army and still finished Germany in '45. Or vice versa if
Montgomery got into trouble.
-- Patrick
hanc...@bbs.cpcn.com
> > and hotels had 300% surchange on long distance calls. i remember
> > making a $40 call from hotel in Germany in the early 70s ... and
> > the hotel billed over $100 for it.
>
> This still happens a lot. Our software does this sort of number
> crunching at a lot of hotels; we provide a table in which they can
> fill in whatever markups and surcharges they want, and the values
> some of them put in are pretty stiff. In fact, if there's a problem
> with the software (unlikely) or the data feeds (more likely), they
> usually call us much faster than our office customers, since it's
> an actual revenue source.
Many government agencies add very hefty surcharges to collect calls
placed by inmates in jails and prisons. They claim it's to cover
security costs but IMHO it's just a way to raise revenue. Usually
the families of prison inmates are quite poor. Even if they weren't
poor to start with, the loss of the main breadwinner to prison makes
them poor.
Family contacts go a long way to reduce re-offending. Making such
contacts harder increases the chances an inmate will re-offend when he
gets out. Not smart policy.
> It's starting to backfire, though - now that cell phones are so
> widespread (and rates are dropping), more and more people choose
> to use their cell phone instead of the room phone.
Smuggled cell phones is a security problem in prisons. They let
gangsters conduct business while on the inside.
Howard Brazee
>Many government agencies add very hefty surcharges to collect calls
>placed by inmates in jails and prisons. They claim it's to cover
>security costs but IMHO it's just a way to raise revenue. Usually
>the families of prison inmates are quite poor. Even if they weren't
>poor to start with, the loss of the main breadwinner to prison makes
>them poor.
>
>Family contacts go a long way to reduce re-offending. Making such
>contacts harder increases the chances an inmate will re-offend when he
>gets out. Not smart policy.
>
>
>> It's starting to backfire, though - now that cell phones are so
>> widespread (and rates are dropping), more and more people choose
>> to use their cell phone instead of the room phone.
>
>Smuggled cell phones is a security problem in prisons. They let
>gangsters conduct business while on the inside.
Could it be that making such contacts harder decreases the chance that
an inmate will re-offend when he gets out?
Peter Flass
>
> Long distance calls *were* expensive and they were used for "important"
> things: the birth of a child, the death of a grandfather, the illness
> of an aunt, occasionally a Merry Christmas or a Happy Birthday. If you
> received a long distance call, you *knew* it was something significant.
>
See _It's a Wonderful Life_.
Peter Flass
> Charles Richmond <fri...@tx.rr.com> writes:
>> Is it really enough??? If *many* more lives could have been saved by
>> doing things a different way and *still* succeeding... would that
>> *not* have been better???
>
> one of boyd's stories about ww2 ... was US running ww2 on mass hordes,
> overwhelming resources, and logistics (because it didn't people to run
> it based on "skills"). one example he used was sherman tank that was
> significantly overmatched ... but US could produce them at ten times the
> rate of german tanks ... and so could win via attrition (modulo issue
> with morale among tank crews that were being used as cannon fodder).
>
> i had uncle that spent couple yrs during ww2 in europe as tank mechanic
> ... he was big ... which is possibly reason that ruled him out as being
> co'opted for tank crew (stories about everybody being co'opted for tank
> crew, including cooks ... they lost lots of crews and tanks ... but
> apparently the new tanks kept arriving faster than they could find
> replacement crews).
Or repair them faster. Somewhere I read someone's recollections (maybe
here?) of reconditioning Shermans that took a hit. I'm told the next
crew was very unhappy, because they never could clean out the smell of
death from the previous crew.
jmfbahciv
First of all, Montgomery was a jerk and Patton and Montgomery were
not right. So speculating that "it would have been better" is
nonsense. The goal of a war is to win to the point of changing
the mindset of the enemy, especially the populace.
/BAH
hanc...@bbs.cpcn.com
> First of all, Montgomery was a jerk and Patton and Montgomery were
> not right. So speculating that "it would have been better" is
> nonsense.
Actually, "speculating what would've been better" is a good exercise
for future battles. The military studies former battles in detail in
war college to avoid past mistakes and come up with new ideas.
(Unfortunately, the general public fails to do so. For instance, many
people criticize the use of the atomic bomb and focus their study on
the last few months of the war. If such people are truly against war,
they should instead focus their efforts on the failed diplomatic
efforts of the 1930s).
Likewise, analyzing the decisions made in development and marketing
System/360 hardware and software would be useful in future efforts.
There are lessons to be learned. I myself don't know--maybe Watson
was 100% correct in driving his people so hard and shoving S/360 out
the door before it was ready; maybe a more leisurely effort wouldn't
have been as good. Developing DOS, for example, out of panic when
they discovered OS couldn't run on low end machines, turned out to be
a big asset in selling the low end S/360s, which were far more popular
in volume than the high end units.
>The goal of a war is to win to the point of changing
> the mindset of the enemy, especially the populace.
I'm not sure the goal of war is to "change the mindset" of the enemy,
especially given that so many enemies (like Germany and Japan and
modern terrorists) are horribly irrational people willing to fight to
the death and destroy their countries and people along with them.
Indeed, the mindset of the leaders of Germany and Japan was never
changed: Hitler and his crew committed suicide and the emperor of
Japan overruled his military rulers. As both countries were
totalitarian dictatorships, the populace had no say in the matter.
Both Germany and Japan were clearly defeated long before they actually
surrended.
As to IBM and competition, both Watsons had the attitude that they
'earned' and thus 'owned' or 'deserved' 100% of the information
processing machine marketplace because they were the best and worked
very hard to build up their customer base. They deeply resented
intrusions onto their marketshare. That attitude led to anti-trust
troubles for both of them.
Watson pushed S/360 out the door so fast partly because his product
line was stale and competitors were gaining on him. Honeywell was
'stealing' his 1401 customers with their machine and Watson couldn't
stand that fact. On the one hand, we can see that competition was
good in that it pushed for improved technology and support that S/360
offered. On the other hand, was the competition bad in that a machine
was announced before its time*?
[*I keep thing of Orson Wells and the wine commercials, "we will sell
no wine before its time."]
Howard Brazee
>As to IBM and competition, both Watsons had the attitude that they
>'earned' and thus 'owned' or 'deserved' 100% of the information
>processing machine marketplace because they were the best and worked
>very hard to build up their customer base. They deeply resented
>intrusions onto their marketshare. That attitude led to anti-trust
>troubles for both of them.
>
>Watson pushed S/360 out the door so fast partly because his product
>line was stale and competitors were gaining on him. Honeywell was
>'stealing' his 1401 customers with their machine and Watson couldn't
>stand that fact. On the one hand, we can see that competition was
>good in that it pushed for improved technology and support that S/360
>offered. On the other hand, was the competition bad in that a machine
>was announced before its time*?
>
>
>[*I keep thing of Orson Wells and the wine commercials, "we will sell
>no wine before its time."]
And I keep thinking of the book and movie
_Enron: The Smartest Guys in the Room_
Michael Wojcik
Rachel Ray did that on her show "$40 a Day". Drove me crazy. I
understand it was important to the concept of the show - which was
basically to stretch a $40 budget for dining out - but even so tipping
a server something like $3.87 seems a bit insulting. "Eh, your
service wasn't quite worth those last thirteen cents."
Micro Focus caps the tips we can be reimbursed for to a certain
percentage (the exact percentage depends on the country where the meal
is purchased, since tipping customs vary), but if we tip over the
amount they just reduce the expense reimbursement a bit. That's fine
by me; if I decide to hand over a little extra for good service, it
ought to come out of my pocket. (In fact, I often don't expense tips
anyway. I figure if MF has me traveling, they can pay for my
sustenance, but a tip is a way I can thank the server - so I ought to
pay it.)
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Joe Pfeiffer
> Micro Focus caps the tips we can be reimbursed for to a certain
> percentage (the exact percentage depends on the country where the meal
> is purchased, since tipping customs vary), but if we tip over the
> amount they just reduce the expense reimbursement a bit. That's fine
> by me; if I decide to hand over a little extra for good service, it
> ought to come out of my pocket. (In fact, I often don't expense tips
> anyway. I figure if MF has me traveling, they can pay for my
> sustenance, but a tip is a way I can thank the server - so I ought to
> pay it.)
That ought to be the case (and tips ought to be rare), but it isn't.
The server's salary is set on the assumption they will be receiving
tips, so your tip is really paying a cost that should have been built
into the price of the meal.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
Howard Brazee
wrote:
>The Germans could offer significant resistance until January of
>1945. Go read what the Ardenner offensive did to Eisenhower's
>broad front. Now imagine what it would do to Patton's forces,
>or Monty's for that matter if they had indeed done such a spearhead.
I'm not suggesting one way is better than the other. My objection
is to the following statement in this thread:
>And we do know that Eisenhower was correct "enough". And that's what
>really counts.
Yeah, the Nazis didn't win. But that is insufficient reason to
assume our choice was optimal. Same thing with Tom Watson Jr's
management styles, or IBMs mainframe strategy or my career choices.
"Good enough" isn't an optimal strategy.
Gene Wirchenko
wrote:
[snip]
>It's starting to backfire, though - now that cell phones are so
>widespread (and rates are dropping), more and more people choose
>to use their cell phone instead of the room phone.
The charges that I have seen are so high that I avoid all of it
out of fear of getting gouged.
Sincerely,
Gene Wirchenko
Anne & Lynn Wheeler
hanc...@bbs.cpcn.com writes:
> Watson pushed S/360 out the door so fast partly because his product
> line was stale and competitors were gaining on him. Honeywell was
> 'stealing' his 1401 customers with their machine and Watson couldn't
> stand that fact. On the one hand, we can see that competition was
> good in that it pushed for improved technology and support that S/360
> offered. On the other hand, was the competition bad in that a machine
> was announced before its time*?
2nd hand tale of some of the competitors testimony in gov./ibm
anti-trust trial ... all computer manufacturers knew by the late 50s
that the single most important factor in the market place was to have a
compatible architecture across the whole machine line ... and they
weren't able to get all the different plant managers to toe the line
... different plant managers responsible for different models would do
various optimizations for the particular technology that they were
using. Only Watson prevailed in forcing all the plant managers
(responbile for the different models) to toe the 360 architecture
comptability line.
this was raised recently in this thread by comments about the pain
various customers had in migrating from earlier machines to 360 (and
never wanting to ever do that again).
http://www.garlic.com/~lynn/2009s.html#60 360 programs on a z/10
also mentioned in the thread ... that lesson/concept got temporarily
lost in the future system detour
http://www.garlic.com/~lynn/submain.html#futuresys
there was a corollary ... that being the only vendor getting the single
most important thing right ... it might be able to get lots of other
things wrong ... and still dominate the market.
part of the issue back then was that software was somewhat simpler and
tended to have machine/architecture dependeancies exposed. there has
been some software progress in 40yrs being able to better abstract
hardware features.
other posts in this thread:
http://www.garlic.com/~lynn/2009r.html#52 360 programs on a z/10
http://www.garlic.com/~lynn/2009r.html#57 360 programs on a z/10
http://www.garlic.com/~lynn/2009r.html#68 360 programs on a z/10
http://www.garlic.com/~lynn/2009r.html#69 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#4 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#9 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#13 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#16 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#17 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#20 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#24 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#26 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#28 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#29 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#30 360 programs on a z/10
http://www.garlic.com/~lynn/2010.html#34 360 programs on a z/10
Howard Brazee
<ly...@garlic.com> wrote:
>2nd hand tale of some of the competitors testimony in gov./ibm
>anti-trust trial ... all computer manufacturers knew by the late 50s
>that the single most important factor in the market place was to have a
>compatible architecture across the whole machine line ...
Of course that doesn't mean it's good to only have one machine line.
hanc...@bbs.cpcn.com
> 2nd hand tale of some of the competitors testimony in gov./ibm
> anti-trust trial ... all computer manufacturers knew by the late 50s
> that the single most important factor in the market place was to have a
> compatible architecture across the whole machine line ... and they
> weren't able to get all the different plant managers to toe the line
> ... different plant managers responsible for different models would do
> various optimizations for the particular technology that they were
> using. Only Watson prevailed in forcing all the plant managers
> (responbile for the different models) to toe the 360 architecture
> comptability line.
There was one IBM manager who wanted to use the latest electronics to
make a 'super' 1401 and pushed hard to do so. Watson forced him to
toe the line.
But it wasn't just office politics. A unified architecture would mean
that a low end machine would have to reserve space in the address
field for large addresses, which would be wasted. System/360 solved
with this the base-register-displacement method (much better described
in the S/360 history). This was a significant innovation, IMHO.
Further, S/360 architecture was able to be modified to support much
higher levels of addressing never conceived in 1964. (Was there ever
System/360 machine with a full 16 meg of memory? I don't think 16 meg
came around until well into the S/370 era.)