Small Server Mob Advantage
Warner Mach
in the ongoing mainframe vs distributed servers debate. I
call this the 'small server mob advantage.'
.
We all know that the ratio of technical people to end users
is much higher with the smaller servers. I consider the
small servers to be a primary driver of IT employment. At
first glance it might seem that the lower ratio for mainframe
support would put the mainframe at an advantage in the eyes
of management ... But, as it turns out, what happens is that,
over the course of time, the number of people in small server
support greatly exceeds the number of people in mainframe
support and they form a group that actively lobbies to move
everything off of the mainframe. This is the 'small server
mob advantage.'
.
Once a conversion effort is finished and it becomes apparent
that people costs now far exceed the mainframe hardware and
software costs, the deed is done. To go back would require
that management admit an error ... So I would advise that
the mainframe folks console themselves with the fact that
their small server brothers and sisters are able to find
gainful employment.
Email disclaimer:
This email is intended only for the use of the addressee(s) named herein. It may contain legally privileged and confidential information. If you are not the intended recipient, or an authorized representative, consider this notification that any review, copying, or distribution of this email or attachments is prohibited. If this email was received in error, please immediately notify the sender by return email and delete the email. Thank you.
----------------------------------------------------------------------
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
Steve Comstock
> I believe that I have identified an interesting phenomenon
> in the ongoing mainframe vs distributed servers debate. I
> call this the 'small server mob advantage.'
> .
> We all know that the ratio of technical people to end users
> is much higher with the smaller servers. I consider the
> small servers to be a primary driver of IT employment. At
> first glance it might seem that the lower ratio for mainframe
> support would put the mainframe at an advantage in the eyes
> of management ... But, as it turns out, what happens is that,
> over the course of time, the number of people in small server
> support greatly exceeds the number of people in mainframe
> support and they form a group that actively lobbies to move
> everything off of the mainframe. This is the 'small server
> mob advantage.'
> .
> Once a conversion effort is finished and it becomes apparent
> that people costs now far exceed the mainframe hardware and
> software costs, the deed is done. To go back would require
> that management admit an error ... So I would advise that
> the mainframe folks console themselves with the fact that
> their small server brothers and sisters are able to find
> gainful employment.
Hmmmm. I would advise the mainframe folks to be alert and
fight the battle early, then. We need to stand up and be
counted (although we may have to do it subtley / indirectly
for political reasons). Your points are exactly the kind
of information that needs to be promulgated before it's
too late. Although it may already be too late.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
Chase, John
A similar observation might be made regarding Java vs. COBOL. Two
"reasons" I hear frequently for abandoning COBOL in favor of Java are
(1) "COBOL is arcane" and (2) "Java programmers are far less expensive
than COBOL programmers".
-jc-
Chase, John
Frequently the problem is not that the information is not promulgated
timely, but rather that the information is ignored.
-jc-
Steve Comstock
I hate ignorance! :-)
How do you overcome that? (In a way that is not job threatening?)
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
----------------------------------------------------------------------
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Steve Comstock
To: IBM-...@bama.ua.edu
Subject: Re: Small Server Mob Advantage
Chase, John wrote:
<SNIPPAGE>
> Frequently the problem is not that the information is not promulgated
> timely, but rather that the information is ignored.
>
> -jc-
I hate ignorance! :-)
How do you overcome that? (In a way that is not job threatening?)
<SNIPPAGE>
Perhaps what needs to be done is point out that what they are really
trying to get away from is the expense of z/OS or z/VSE, etc. But what
they really need is the low cost of Linux that runs on z/ARCH with z/VM
managing.
The end result is RAPID recovery in a BCP (Biz Continuity Plan) test
with business processes running and available much quicker.
Also, less power consumption, with greater throughput because of the
integrated I/O that z/Architecture provides under the covers to an
operating system.
Just my opinion having been though more than one, "We gotta get off the
mainframe" projects (most of which were abysmal failures costing MEGA
$$).
Regards,
Steve Thompson
-- Opinions expressed by this poster may not reflect those held by
poster's employer --
Anne & Lynn Wheeler
ma...@RESA.NET (Warner Mach) writes:
> I believe that I have identified an interesting phenomenon
> in the ongoing mainframe vs distributed servers debate. I
> call this the 'small server mob advantage.'
there are numerous situations (not just servers) were there can be
smaller upfront/initial costs ... but scale less well.
an earlier version of this was huge proliferation in 4341s
(actually mid-range, dec/vax experienced something similar in
the same market).
cluster of six 4341s were cheaper than 3033, had more aggregate mips,
more aggregate storage, and more aggregate channels and more aggregate
i/o capacity. some of the big customers would order 4341s in multiples
of a hundred at a time (something that dec/vax didn't really see).
misc. old 4341 related email
http://www.garlic.com/~lynn/lhwemail.html#4341
going into mid-80s ... there was some anticipation that 4381s would see
similar success ... however, by that time, the mid-range market was
starting to shift to workstations & large PCs.
SHARE had some statements that 4341s would have seen even larger
penetration (at expense of dec/vax) ... but dec/vax had lower entry
care&feeding costs (i.e. less effort and lower skill level).
At the time, some internal locations were bursting at the seams in terms
of raised floor and 4341s were solution to installing additional
computing power ... out in department areas (at some locations,
conference rooms became a very scarce resource ... because so many were
being taken over for 4341s).
The other big (distributed 4341) innovation was much easier/faster to
roll-out new feature/function ... compared to datacenter.
Moving more of the virtual machine function into the hardware ... for
LPARs ... was partially response to Amdahl's hypervisor .... but it also
provided some capability to helping testing new feature/function in
(single) large consolidated mainframe resource environment (that had
enormous barriers to change/adapting).
A relatively "funny" joke from the period ... was that JES2 networking
tables effectively was part of large system change control. The internal
network had significantly more nodes than could be defined in JES2
... and so most MVS systems were restricted to edge nodes. Internal
users that actually tried to do things from MVS systems were constantly
attempting to deal with those network nodes that were currently defined
in that particular system (and just getting change to the JES2 network
table frequently would take a month or two ... as part of the next MVS
system load/test) ... this was aggrevated by JES2 tossing traffic if it
didn't have the destination node defined (in case the traffic might have
to go someplace else) ... but also would toss traffic if it didn't have
the originating node defined.
This was in an environment when not only were there much large number of
network nodes ... than could be defined in JES2 ... but one or more new
network nodes might be coming online everyday (someplace in the world)
... old reference to list of internal locations that had one or more new
networking nodes in 1983 (internal network had more nodes than
arpanet/internet from just about the beginning until possibly late '85
or early '86)
http://www.garlic.com/~lynn/2006k.html#8
misc. past posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
Joel Wolpert
understanding of small servers than MF so they naturally gravitate to this.
As much as the MF people try to make a case the natural bias of management
always comes out, which affects the decision. Also, the people cost is
usually hidden in separate buckets so that the people making the decision to
move from the MF to UNIX/LINUX servers still get gold stars for saving
costs.
Joel Wolpert
Performance and Capacity Planning consultant
WEBSITE: www.perfconsultant.com
Paul Gilmartin
>
>A relatively "funny" joke from the period ... was that JES2 networking
>tables effectively was part of large system change control. The internal
>network had significantly more nodes than could be defined in JES2
>... and so most MVS systems were restricted to edge nodes. Internal
>users that actually tried to do things from MVS systems were constantly
>attempting to deal with those network nodes that were currently defined
>in that particular system (and just getting change to the JES2 network
>table frequently would take a month or two ... as part of the next MVS
>system load/test) ... this was aggrevated by JES2 tossing traffic if it
>didn't have the destination node defined (in case the traffic might have
>to go someplace else) ... but also would toss traffic if it didn't have
>the originating node defined.
>
that SNA didn't provide a facility with the scalability of DNS.
-- gil
Tom Longfellow
>
> I hate ignorance! :-)
>
> How do you overcome that? (In a way that is not job threatening?)
>
active avoidance of any fact that does not support the preconceived view.
People who do this (look at any sucessful politician) end up believing that
saying 'make it so' is all it takes to make it so.
I am still waiting for the 'Repeal of Gravity Act' from our politcal
leaders.
Anne & Lynn Wheeler
PaulGB...@AIM.COM (Paul Gilmartin) writes:
> I often wonder whether a reason TCP/IP triumphed over SNA was
> that SNA didn't provide a facility with the scalability of DNS.
re:
http://www.garlic.com/~lynn/2009q.html#82
in some ways ... SNA is even less general than the arpanet
implementation prior to the cut-over to internetworking on 1/1/83
... which DNS is one part of.
misc. trivia ... the person responsible for DNS had earlier spent some
time at the science center ... some science center posts
http://www.garlic.com/~lynn/subtopic.html#545tech
when the person was student at mit.
tcp/ip was the technology basis for the modern internet ... nsfnet
backbone was the operational basis for the modern internet and cix was
the business basis for the modern internet. misc. old email related
to nsfnet backbone:
http://www.garlic.com/~lynn/lhwemail.html#nsfnet
one of the things that the internal networking technology did was a kind
of gateway facility in every node ... somethat that was also was a
feature of internetworking. misc. past posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
JES2 had other significant issues ... having muddled what was job
control and what was networking. as a result ... JES2 systems at
different levels and with incompatible headers ... could crash each
other ... and bring down the whole system (there was infamous case of
some internal jes2 systems in san jose which were bringing down hursley
mvs systems).
the major internal networking technology was able to have "native"
drivers ... but also install "jes2" drivers for communicating with jes2
systems (and allow jes2/mvs systems to participate in the internal
network). this feature evolved into these (non-native) jes2 drives
adding features to try and rewrite jes2 headers to that they were always
compatible with the direclty connected jes2/mvs systems (as
countermeasure to have high frequency of jes2/mvs crashing all over the
world). the internal technology got blaimed for not preventing the
hursley mvs systems from crashing (since the internet network technology
hadn't been upgraded to filter some of the new san jose jes2 fields
... from reaching the hursley jes2 systems). misc. past posts mentioning
hasp, jes2, and/or jes2 networking
http://www.garlic.com/~lynn/submain.html#hasp
dislcaimer: my wife did a stint in the jes group (among other things
acted as one of the catchers for asp->jes3 ... and did a design document
for merged jes2/jes3 product) ... before getting con'ed into going to
pok to be in charge of loosely-coupled architecture.
my wife was also co-author of internal architecture document (AWP39) in
the early days of SNA called peer-to-peer networking (which SNA group
possible viewed as competition to their master/terminal-control
architecture). she also had numerous battles in POK with the SNA
organization over not using SNA for her "peer-coupled shared data
architecture" (which, except for ims hot-standby, saw very little uptake
until sysplex) ... some past references:
http://www.garlic.com/~lynn/submain.html#shareddata
there were temporary truces with the SNA organization over her not
having to use SNA within the walls/boundaries of the datacenter ... but
SNA had to be used if something involved crossing the datacenter walls.
later i would needle the person responsible for APPN (AWP164) to stop
trying to prop up SNA (they weren't going to appreciate it) and come
work on real networking ... if fact, the SNA organization non-concurred
with announcing APPN ... and it was held up for several weeks while the
announcement letter was careful to not even imply that there was any
connection between APPN and SNA.
misc. past posts mentioning AWP39, AWP164 &/or AAPN
http://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment
http://www.garlic.com/~lynn/2004p.html#31 IBM 3705 and UC.5
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005p.html#17 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005u.html#23 Channel Distances
http://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
http://www.garlic.com/~lynn/2006k.html#9 Arpa address
http://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
http://www.garlic.com/~lynn/2006o.html#62 Greatest Software, System R
http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#9 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#28 Assembler question
http://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?
http://www.garlic.com/~lynn/2007b.html#9 Mainframe vs. "Server" (Was Just another example of mainframe
http://www.garlic.com/~lynn/2007b.html#48 6400 impact printer
http://www.garlic.com/~lynn/2007b.html#49 6400 impact printer
http://www.garlic.com/~lynn/2007d.html#55 Is computer history taugh now?
http://www.garlic.com/~lynn/2007h.html#35 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#39 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007l.html#62 Friday musings on the future of 3270 applications
http://www.garlic.com/~lynn/2007o.html#72 FICON tape drive?
http://www.garlic.com/~lynn/2007p.html#12 JES2 or JES3, Which one is older?
http://www.garlic.com/~lynn/2007p.html#23 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007q.html#46 Are there tasks that don't play by WLM's rules
http://www.garlic.com/~lynn/2007r.html#10 IBM System/3 & 3277-1
http://www.garlic.com/~lynn/2007v.html#53 folklore indeed
http://www.garlic.com/~lynn/2008b.html#42 windows time service
http://www.garlic.com/~lynn/2008d.html#71 Interesting ibm about the myths of the Mainframe
http://www.garlic.com/~lynn/2008e.html#73 Convergent Technologies vs Sun
http://www.garlic.com/~lynn/2008i.html#97 We're losing the battle
http://www.garlic.com/~lynn/2009e.html#56 When did "client server" become part of the language?
http://www.garlic.com/~lynn/2009i.html#26 Why are z/OS people reluctant to use z/OS UNIX?
http://www.garlic.com/~lynn/2009l.html#3 VTAM security issue
http://www.garlic.com/~lynn/2009l.html#7 VTAM security issue
Morten Reistad
Anne & Lynn Wheeler <ly...@garlic.com> wrote:
>
>PaulGB...@AIM.COM (Paul Gilmartin) writes:
>> I often wonder whether a reason TCP/IP triumphed over SNA was
>> that SNA didn't provide a facility with the scalability of DNS.
>
>re:
>http://www.garlic.com/~lynn/2009q.html#82
>
>in some ways ... SNA is even less general than the arpanet
>implementation prior to the cut-over to internetworking on 1/1/83
>... which DNS is one part of.
.. and SNA didn't have real internetworking. THAT is what made
TCP/IP the success it has been. You can run it over anything,
see all the rfcs. Even tcp/ip over carrier pigeons has been
implemented.
So, in the start the existing hardware of Arcnet, X.25, Frame
Relay, ethernet, T1s/E1s etc could be used more or less as is,
even if they were never designed with tcp/ip in mind.
Then came a next generation of "tcp/ip aware" networks, like
ATM, MPLS, various higher speed and longer range ethernets,
and Sonet.
This allowed the internetwork to grow organically. Now almost
all the corporate networks are embraced by the internet, or runs
parallell to it with the same technology. And the legacy networks
run happily on top of the Internet. Still, 0.4% of the exchange
traffic we have measured is X.25. Nearly 2% is frame relay.
This nature of friendlyness and non-combative approaches to
other networks is the reason for TCP/IPs success. And it scales.
Way beyond the design. We really need to be going with ipv6 (and
it needs some fixing) now. The last two large projects I worked
for used 15-20% of the resources on various address translation
and interworking schemes to compensate for the lack of end to
end addressing.
>misc. trivia ... the person responsible for DNS had earlier spent some
>time at the science center ... some science center posts
>http://www.garlic.com/~lynn/subtopic.html#545tech
>
>when the person was student at mit.
>
>tcp/ip was the technology basis for the modern internet ... nsfnet
>backbone was the operational basis for the modern internet and cix was
>the business basis for the modern internet. misc. old email related
>to nsfnet backbone:
>http://www.garlic.com/~lynn/lhwemail.html#nsfnet
But there was fierce resistance at every point.
>one of the things that the internal networking technology did was a kind
>of gateway facility in every node ... somethat that was also was a
>feature of internetworking. misc. past posts mentioning internal network
>http://www.garlic.com/~lynn/subnetwork.html#internalnet
>
>JES2 had other significant issues ... having muddled what was job
>control and what was networking. as a result ... JES2 systems at
>different levels and with incompatible headers ... could crash each
>other ... and bring down the whole system (there was infamous case of
>some internal jes2 systems in san jose which were bringing down hursley
>mvs systems).
>
>the major internal networking technology was able to have "native"
>drivers ... but also install "jes2" drivers for communicating with jes2
>systems (and allow jes2/mvs systems to participate in the internal
>network). this feature evolved into these (non-native) jes2 drives
>adding features to try and rewrite jes2 headers to that they were always
>compatible with the direclty connected jes2/mvs systems (as
>countermeasure to have high frequency of jes2/mvs crashing all over the
>world). the internal technology got blaimed for not preventing the
>hursley mvs systems from crashing (since the internet network technology
>hadn't been upgraded to filter some of the new san jose jes2 fields
>... from reaching the hursley jes2 systems). misc. past posts mentioning
>hasp, jes2, and/or jes2 networking
>http://www.garlic.com/~lynn/submain.html#hasp
Instead we now do this over a common internetworking layer. Young people
cannot really comprehend how messy pre-1990 cross-platform networking
really was.
>dislcaimer: my wife did a stint in the jes group (among other things
>acted as one of the catchers for asp->jes3 ... and did a design document
>for merged jes2/jes3 product) ... before getting con'ed into going to
>pok to be in charge of loosely-coupled architecture.
>
>my wife was also co-author of internal architecture document (AWP39) in
>the early days of SNA called peer-to-peer networking (which SNA group
>possible viewed as competition to their master/terminal-control
>architecture). she also had numerous battles in POK with the SNA
>organization over not using SNA for her "peer-coupled shared data
>architecture" (which, except for ims hot-standby, saw very little uptake
>until sysplex) ... some past references:
>http://www.garlic.com/~lynn/submain.html#shareddata
It wasn't just IBM. It was everyone. At least there was a comprehensive
effort inside IBM to fix this culture, even if it saw little uptake.
DG, Prime, DEC, and the seven swarves kept locking people into their
fiefdoms.
>there were temporary truces with the SNA organization over her not
>having to use SNA within the walls/boundaries of the datacenter ... but
>SNA had to be used if something involved crossing the datacenter walls.
>
>later i would needle the person responsible for APPN (AWP164) to stop
>trying to prop up SNA (they weren't going to appreciate it) and come
>work on real networking ... if fact, the SNA organization non-concurred
>with announcing APPN ... and it was held up for several weeks while the
>announcement letter was careful to not even imply that there was any
>connection between APPN and SNA.
SNA never embraced TCP/IP. Many others did, and the protocols survive
on top of the Internet.
-- mrr
Anne & Lynn Wheeler
> SNA never embraced TCP/IP. Many others did, and the protocols survive
> on top of the Internet.
re:
http://www.garlic.com/~lynn/2009q.html#82 Small Server Mob Advantage
http://www.garlic.com/~lynn/2009q.html#83 Small Server Mob Advantage
misc. old nsfnet related email
http://www.garlic.com/~lynn/2006s.html#email860417
recently going thru some boxes found copy of the letter referenced in
the above ... dated 03apr86 .. recent reference:
http://www.garlic.com/~lynn/2009q.html#42
this is prefix to package of appended emails that were forwarded to us
regarding communication group thinking that NSF might have a use for
VTAM (& SNA):
http://www.garlic.com/~lynn/2006w.html#email870109
our nsfnet backbone activities & meetings had gotten canceled ... and we
were prevented from bidding on the nsfnet backbone ... even tho there
was some statement that what we already had running was at least five
yrs ahead of all bid submissions.
there is folklore about an outside consultant hired to do a tcp/ip
implementation in vtam. when it was turned in ... it ran faster than
lu6.2 ... they were then supposedly told that "everybody knows that a
correct tcp/ip implementation would run much slower than lu6.2 and only
a correct implementation would be accepted"
this old references working on trying to turn out a product that would
simulate NCP/pu4 to host systems ... simulating activity as
"cross-domain" ... but all resources were actually owned by the
networking infrastructure ... and sna RUs then carried in "real"
networking infrastructure (old posts from decade ago):
http://www.garlic.com/~lynn/99.html#66
http://www.garlic.com/~lynn/99.html#67
http://www.garlic.com/~lynn/99.html#70
there were various kinds of internal politics that got involved and it
never made it to announce/ship.
Walter Bushell
Morten Reistad <fi...@last.name> wrote:
> .. and SNA didn't have real internetworking. THAT is what made
> TCP/IP the success it has been. You can run it over anything,
> see all the rfcs. Even tcp/ip over carrier pigeons has been
> implemented.
I bet a pigeon could carry a 32 gigabyte chip maybe more, giving high
bandwidth high latency service.
--
A computer without Microsoft is like a chocolate cake without mustard.
Anne & Lynn Wheeler
PaulGB...@AIM.COM (Paul Gilmartin) writes:
> I often wonder whether a reason TCP/IP triumphed over SNA was
> that SNA didn't provide a facility with the scalability of DNS.
re:
http://www.garlic.com/~lynn/2009q.html#82 Small Server Mob Advantage
http://www.garlic.com/~lynn/2009q.html#83 Small Server Mob Advantage
http://www.garlic.com/~lynn/2009r.html#0 Small Server Mob Advantage
for other topic drift ... I've frequently pontificated on possible
"catch-22" implications that DNSSEC might have for the domain name
certification authority industry:
http://www.garlic.com/~lynn/subpubkey.html#catch22
some recent DNS news for slightly other topic drift:
Google Public DNS: But Is It Safe?
http://www.internetnews.com/security/article.php/3851101/Google+Public+DNS+But+Is+It+Safe.htm
Geez, Google Wants to Take Over DNS, Too
http://www.wired.com/threatlevel/2009/12/geez-google-wants-to-take-over-dns-too/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+wired27b+%28Blog+-+27B+Stroke+6+%28Threat+Level%29%29
Google Public DNS and Your Privacy
http://www.pcworld.com/article/183671/google_public_dns_and_your_privacy.html
Google Public DNS: What It Means For Your Privacy
http://www.networkworld.com/news/2009/120309-google-public-dns-what-it.html
Google To Boost Internet Speed With New Public DNS Resolver
http://www.crn.com/security/222000590
Google Public DNS offers speed, few features
http://blogs.computerworld.com/15193/google_dns
Google wants to unclog Net's DNS plumbing Deep Tech
http://news.cnet.com/8301-30685_3-10408624-264.html
Google Introduces Public DNS Service
http://www.domainnamenews.com/search-engines/google-introduces-public-dns-service/6747
Google expands plan to run own internet
http://www.theregister.co.uk/2009/12/03/google_public_dns/
Google Public DNS: Wonderful Freebie or Big New Menace?
http://www.networkworld.com/news/2009/120309-google-public-dns-wonderful-freebie.html
Google launches free public DNS
http://www.networkworld.com/news/2009/120309-google-launches-free-public.html
Google Launches Free Public DNS
http://www.pcworld.com/article/183643/google_launches_free_public_dns.html
Google launches free public DNS
http://www.macworld.com/article/144716/google_dns.html
Charlie Gibbs
(Anne & Lynn Wheeler) writes:
> At the time, some internal locations were bursting at the seams in
> terms of raised floor and 4341s were solution to installing additional
> computing power ... out in department areas (at some locations,
> conference rooms became a very scarce resource ... because so many
> were being taken over for 4341s).
A friend of mine worked in a place like that - except they were
switching from a Burroughs 17xx to a System/3, and didn't want
to cram it into the machine room (and Burroughs' face) until the
conversion was complete. IBM was only too glad to help, since it
was a flagship for them: the first model 15D in Vancouver. So the
conference table was taken apart and leaned against the wall, sheets
of plywood were laid on the carpet, power cables magically appeared
from somewhere, and the conference room became a machine room.
--
/~\ 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!
DaveC
> SNA never embraced TCP/IP. Many others did, and the protocols survive
> on top of the Internet.
>
lessons of how SNA ran over IP networks for modern datacentres:
http://etherealmind.com/why-does-iscsi-use-tcp/
Dave
jmfbahciv
> In article <m3638nd...@garlic.com>, ly...@garlic.com
> (Anne & Lynn Wheeler) writes:
>
>> At the time, some internal locations were bursting at the seams in
>> terms of raised floor and 4341s were solution to installing additional
>> computing power ... out in department areas (at some locations,
>> conference rooms became a very scarce resource ... because so many
>> were being taken over for 4341s).
>
> A friend of mine worked in a place like that - except they were
> switching from a Burroughs 17xx to a System/3, and didn't want
> to cram it into the machine room (and Burroughs' face) until the
> conversion was complete. IBM was only too glad to help, since it
> was a flagship for them: the first model 15D in Vancouver. So the
> conference table was taken apart and leaned against the wall, sheets
> of plywood were laid on the carpet, power cables magically appeared
> from somewhere, and the conference room became a machine room.
>
Leave work one day and the next day you find new ropes to trip over.
/BAH
Charles Richmond
I always thought cables were nocturnal, and reproduced at night.
Kind of like the coat hangers in your closet. ;-)
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
jmfbahciv
> jmfbahciv wrote:
>> Charlie Gibbs wrote:
>>> In article <m3638nd...@garlic.com>, ly...@garlic.com
>>> (Anne & Lynn Wheeler) writes:
>>>
>>>> At the time, some internal locations were bursting at the seams in
>>>> terms of raised floor and 4341s were solution to installing additional
>>>> computing power ... out in department areas (at some locations,
>>>> conference rooms became a very scarce resource ... because so many
>>>> were being taken over for 4341s).
>>>
>>> A friend of mine worked in a place like that - except they were
>>> switching from a Burroughs 17xx to a System/3, and didn't want
>>> to cram it into the machine room (and Burroughs' face) until the
>>> conversion was complete. IBM was only too glad to help, since it
>>> was a flagship for them: the first model 15D in Vancouver. So the
>>> conference table was taken apart and leaned against the wall, sheets
>>> of plywood were laid on the carpet, power cables magically appeared
>>> from somewhere, and the conference room became a machine room.
>>>
>> kewl :-). I always wondered about the magic which produced cables.
>>
>> Leave work one day and the next day you find new ropes to trip over.
>>
>
> I always thought cables were nocturnal, and reproduced at night. Kind of
> like the coat hangers in your closet. ;-)
>
>
/BAH
Charlie Gibbs
writes:
Coat hangers are produced by breeding paper clips, which seem
to disappear at roughly the same rate as coat hangers appear.
I wonder what breeds cables.
>I worked an 04:00 to noon shift. They didn't reproduce then.
Not when you were looking, anyway. Like people (and coat hangers)
they tend to be secretive about such things.
jmfbahciv
Perhaps cables are the roads the paper clips take to get into
the closet.
>
>> I worked an 04:00 to noon shift. They didn't reproduce then.
>
> Not when you were looking, anyway. Like people (and coat hangers)
> they tend to be secretive about such things.
>
No shit. I remember one of our managers taking a look above the
ceiling tiles in our area. There must have been miles and miles
and miles of wire up there. A couple of guys tried to trace
a plug back to find out which system it was wired to. It took
them all night, maybe more.
When I was in one of the facilities at Oak Ridge, I looked up.
The ceiling was about 50' above me and the wire I saw awed me.
There were people who strung each and every one of them over
the years.
/BAH
Anne & Lynn Wheeler
> At the time, some internal locations were bursting at the seams in terms
> of raised floor and 4341s were solution to installing additional
> computing power ... out in department areas (at some locations,
> conference rooms became a very scarce resource ... because so many were
> being taken over for 4341s).
re:
http://www.garlic.com/~lynn/2009q.html#82 Small Server Mob Advantage
http://www.garlic.com/~lynn/2009q.html#83 Small Server Mob Advantage
http://www.garlic.com/~lynn/2009r.html#0 Small Server Mob Advantage
http://www.garlic.com/~lynn/2009r.html#1 Small Server Mob Advantage
alternative to taking over all the conference rooms (something that
happened with big spike in 4341 installs a couple decades ago)
IBM thinks outside the box with containerized data centres
http://www.theregister.co.uk/2009/12/07/ibm_data_center_containers/
from above:
The idea of putting servers, storage, and networking gear into metal
shipping containers and linking them together into a data centre cluster
is not a new idea - Sun Microsystems was the first to propose the idea
back in October 2006 - but it is catching on enough that IBM is
endorsing the concept and shipping a product.
... snip ...
Anne & Lynn Wheeler
> drivers ... but also install "jes2" drivers for communicating with jes2
> systems (and allow jes2/mvs systems to participate in the internal
> network). this feature evolved into these (non-native) jes2 drives
> adding features to try and rewrite jes2 headers to that they were always
> compatible with the direclty connected jes2/mvs systems (as
> countermeasure to have high frequency of jes2/mvs crashing all over the
> world). the internal technology got blaimed for not preventing the
> hursley mvs systems from crashing (since the internet network technology
> hadn't been upgraded to filter some of the new san jose jes2 fields
> ... from reaching the hursley jes2 systems). misc. past posts mentioning
> hasp, jes2, and/or jes2 networking
> http://www.garlic.com/~lynn/submain.html#hasp
>
> dislcaimer: my wife did a stint in the jes group (among other things
> acted as one of the catchers for asp->jes3 ... and did a design document
> for merged jes2/jes3 product) ... before getting con'ed into going to
> pok to be in charge of loosely-coupled architecture.
re:
http://www.garlic.com/~lynn/2009q.html#83 Small Server Mob Advantage
I recently reminded my wife about the problem with adverse interaction
between jes2 networking at different release levels (resulting in mvs
system crashes) ... and (infamous) incident with hursley systems
crashing ... and being blamed on vnet. she quoted some chinese proberb if
you ever save somebody ... you are responsible for them for life. she
also mentioned somebody in the jes2 group that may have been primarily
responsible.
I reminded her that a lot of the characteristics of jes2 networking was
inherited from the HASP implementation ... which carried the characters
"TUCC" on the (networking) source code changes.
Chase, John
> From: IBM Mainframe Discussion List [On Behalf Of Anne & Lynn Wheeler
>
> [ snip ]
>
> IBM thinks outside the box with containerized data centres
> http://www.theregister.co.uk/2009/12/07/ibm_data_center_containers/
>
> from above:
>
> The idea of putting servers, storage, and networking gear into metal
> shipping containers and linking them together into a data centre
cluster
> is not a new idea - Sun Microsystems was the first to propose the idea
> back in October 2006 - but it is catching on enough that IBM is
> endorsing the concept and shipping a product.
<Yawn>.... The USMC has had "portable" air traffic control facilities
of this nature since at least 1965. Still cheaper than IBM's "portable"
data centers:
http://www.governmentcontractswon.com/department/defense/an-tsq-18-landi
ng-cntrl-cntr.asp?yr=00
-jc-
Lloyd Fuller
The US Army used 360/30 and 360/40s in 18-wheel trailers back in the early 1960s - 40 years before Sun "thought" of the idea. The Army even had those in Vietnam for the division data centers.
Lloyd
--- On Mon, 12/7/09, Chase, John <jch...@USSCO.COM> wrote:
Thompson, Steve
Sent: Monday, December 07, 2009 2:57 PM
To: IBM-...@bama.ua.edu
Subject: Re: "Portable" data centers (was RE: Small Server Mob
Advantage)
What do you mean Sun was the first?
The US Army used 360/30 and 360/40s in 18-wheel trailers back in the
early 1960s - 40 years before Sun "thought" of the idea. The Army even
had those in Vietnam for the division data centers.
Lloyd
<snip>
Yeah, and they had 600' of channel cables attached to a jeep to use as a
mouse.
Sorry, I just couldn't get this cartoon out of my mind of the original
mouse...
Regards,
Steve Thompson
-- Standard disclaimer applies --
Lloyd Fuller
They did have lots of cable and the installations that I saw were REAL careful about what kind of traffic even came close to the trailers. In fact even foot traffic was discouraged!
Lloyd
--- On Mon, 12/7/09, Thompson, Steve <Steve_T...@STERCOMM.COM> wrote:
> From: Thompson, Steve <Steve_T...@STERCOMM.COM>
> Subject: Re: "Portable" data centers (was RE: Small Server Mob Advantage)
Anne & Lynn Wheeler
lefu...@SBCGLOBAL.NET (Lloyd Fuller) writes:
> What do you mean Sun was the first?
>
> The US Army used 360/30 and 360/40s in 18-wheel trailers back in the
> early 1960s - 40 years before Sun "thought" of the idea. The Army
> even had those in Vietnam for the division data centers.
re:
http://www.garlic.com/~lynn/2009r.html#12 Small Server Mob Advantage
maybe mid-60s?? 360 announce 7apr64.
http://en.wikipedia.org/wiki/IBM_System/360
360/30 FCS jun65, 360/40 FCS apr65
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360.html
... maybe a 1401?
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP1401.html
or 1620?
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP1620.html
there was recent celebration of 50th anniv. of 1401 at computer history
museum ... there is also this article ... which includes comment from
somebody mentioning working on a 1401 located in marine truck in vietnam
(1967)
http://spectrum.ieee.org/computing/hardware/rebuilding-the-ibm-1401
I had sponsored Boyd's briefings at IBM in the 80s. Boyd's biographies
has him in 1970 doing a year stint in charge of "spook base" ... a
$2.5B(!) windfall for IBM ... although even that was probably not enuf
to offset the cost of the failed future system effort
http://www.garlic.com/~lynn/submain.html#futuresys
and/or the resulting impact that the failure had on the corporate
culture.
misc. past posts mentioning Boyd:
http://www.garlic.com/~lynn/subboyd.html#boyd1
misc. URLs from around the web mentioning Boyd:
http://www.garlic.com/~lynn/subboyd.html#boyd2
Howard Brazee
Steve) wrote:
>What do you mean Sun was the first?
>
>The US Army used 360/30 and 360/40s in 18-wheel trailers back in the
>early 1960s - 40 years before Sun "thought" of the idea. The Army even
>had those in Vietnam for the division data centers.
How big were those, compared to an iPod?
Morten Reistad
They need proper finding tools. A lineman's set with tracer beep,
line seeker and test device is invaluable when you try to trace
cables.
>When I was in one of the facilities at Oak Ridge, I looked up.
>The ceiling was about 50' above me and the wire I saw awed me.
>There were people who strung each and every one of them over
>the years.
How do you think phones and terminals are connected?
-- mrr
Anne & Lynn Wheeler
> No shit. I remember one of our managers taking a look above the
> ceiling tiles in our area. There must have been miles and miles
> and miles of wire up there. A couple of guys tried to trace
> a plug back to find out which system it was wired to. It took
> them all night, maybe more.
>
> When I was in one of the facilities at Oak Ridge, I looked up.
> The ceiling was about 50' above me and the wire I saw awed me.
> There were people who strung each and every one of them over
> the years.
there were old stories about 3270 coax cables exceeding flr loading
limit in some bldgs. (single cable from datacenter to each 3270
terminal). in the 80s standard effort to run a new set of 3270 coax
cables had default/standard cost estimate of $1000/cable.
theoritically ... a major purpose for token-ring was single cable to
each wiring closet ... then with wires running from MAU boxes in local
wiring closets to the terminals (by this time PCs running terminal
emulation). one of the design points for terminal emulation paradigm was
300 or more "terminals" per token-ring LAN ... so each individual
adapter card had design of very low thruput per card.
the pc/rt had 16bit (AT/ISA) bus and had done their own 4mbit token-ring
adapter card ... with design point that individual adapter cards could
burst at near maximum thruput of the lan. for rs/6000, they were
"forced" to use the PS2 microchannel 16mbit token-ring adapter card ...
however a PC/RT 4mbit token-ring adapter card had higher thruput than
the PS2 microchannel 16mbit token-ring adatper card.
the los gatos lab was a showplace bldg. built in the 60s ... at the time
of bldg. had 2-3 times the normal pairs of phone twisted-pairs going to
each office. it was usually possible to find existing unused
twisted-pair to do unshielded twisted-pair 10mbit ethernet into each
office.
the almaden lab was built in the mid-80s with lots of cat5
... presumably anticipating token-ring use. however, it was found that
shielded twisted-pair 10mbit enet had higher per adapter card thruput,
higher aggregate thruput, and lower latency than using the cat5 for
16mbit token-ring (basically instead of having token-ring MAUs in local
wiring closet ... there were enet switches or routers).
misc. past posts mentioning 3270 coax flr loading:
http://www.garlic.com/~lynn/2002f.html#7 Blade architectures
http://www.garlic.com/~lynn/2002f.html#11 Blade architectures
http://www.garlic.com/~lynn/2006k.html#42 Arpa address
http://www.garlic.com/~lynn/2006l.html#38 Token-ring vs Ethernet - 10 years later
http://www.garlic.com/~lynn/2008s.html#6 Memory Instrumentation - was "largest parallel sysplex around?"
Lloyd Fuller
> that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
>
>
> lefu...@SBCGLOBAL.NET (Lloyd Fuller) writes:
>> What do you mean Sun was the first?
>>
>> The US Army used 360/30 and 360/40s in 18-wheel trailers back in the
>> early 1960s - 40 years before Sun "thought" of the idea. The Army
>> even had those in Vietnam for the division data centers.
>
> re:
> http://www.garlic.com/~lynn/2009r.html#12 Small Server Mob Advantage
>
> maybe mid-60s?? 360 announce 7apr64.
> http://en.wikipedia.org/wiki/IBM_System/360
>
> 360/30 FCS jun65, 360/40 FCS apr65
> http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360.html
>
360/40s. The first one that I saw was in Vietnam in 1966. I later
worked for a Sergeant that had worked on the prototypes some place in
New England.
The CPU and memory along with the 2540(?) and console were in one
trailer. The disk (2314s) in a second and maybe third, and the tape
drives in another trailer. There was also a generator trailer.
Lloyd
> ... maybe a 1401?
> http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP1401.html
> or 1620?
> http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP1620.html
>
> there was recent celebration of 50th anniv. of 1401 at computer history
> museum ... there is also this article ... which includes comment from
> somebody mentioning working on a 1401 located in marine truck in vietnam
> (1967)
> http://spectrum.ieee.org/computing/hardware/rebuilding-the-ibm-1401
>
> I had sponsored Boyd's briefings at IBM in the 80s. Boyd's biographies
> has him in 1970 doing a year stint in charge of "spook base" ... a
> $2.5B(!) windfall for IBM ... although even that was probably not enuf
> to offset the cost of the failed future system effort
> http://www.garlic.com/~lynn/submain.html#futuresys
>
> and/or the resulting impact that the failure had on the corporate
> culture.
>
> misc. past posts mentioning Boyd:
> http://www.garlic.com/~lynn/subboyd.html#boyd1
> misc. URLs from around the web mentioning Boyd:
> http://www.garlic.com/~lynn/subboyd.html#boyd2
>
----------------------------------------------------------------------
Lloyd Fuller
Let's put it this way: even Shrek could not have put it into a shirt
pocket like I can mine. These were full 18wheeler trailers - 30 foot or
maybe more?
Lloyd
Linda Mooney
I started with my current employer in 1984. Couple of months later, we were putting in a new mainframe. A full sized 18 wheeler (probably a 65 footer) pulled up along side the building, along with another one with generators to run the mainframe in the first. Our data center was pretty small and in order to swap out the mainframe the workload was moved on to the machine in the truck while we did a push/pull in the data center. We ran the better part of a week like that, then we cut over to the new machine in the data c enter. Changed out the mainframe with only 2 IPLs worth of outage. Pretty fine. Not SUN , IBM.
Linda Mooney
----- Original Message -----
From: "Lloyd Fuller" <lefu...@SBCGLOBAL.NET>
To: IBM-...@bama.ua.edu
Sent: Monday, December 7, 2009 5:42:57 PM GMT -08:00 US/Canada Pacific
Subject: Re: "Portable" data centers (was RE: Small Server Mob Advantage)
Ahem A Rivet's Shot
jmfbahciv <jmfbahciv@aol> wrote:
> No shit. I remember one of our managers taking a look above the
> ceiling tiles in our area. There must have been miles and miles
> and miles of wire up there. A couple of guys tried to trace
> a plug back to find out which system it was wired to. It took
> them all night, maybe more.
I can *not* be the only person in this group who has traced a
network cable through walls and ceilings to find the switch at the end of
it in a disused cupboard that had been papered over.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Chase, John
Probably like battleship::kayak.
-jc-
jmfbahciv
/BAH
jmfbahciv
>> No shit. I remember one of our managers taking a look above the
>> ceiling tiles in our area. There must have been miles and miles
>> and miles of wire up there. A couple of guys tried to trace
>> a plug back to find out which system it was wired to. It took
>> them all night, maybe more.
>>
>> When I was in one of the facilities at Oak Ridge, I looked up.
>> The ceiling was about 50' above me and the wire I saw awed me.
>> There were people who strung each and every one of them over
>> the years.
>
> there were old stories about 3270 coax cables exceeding flr loading
> limit in some bldgs.
Good grief! :-)
>(single cable from datacenter to each 3270
> terminal). in the 80s standard effort to run a new set of 3270 coax
> cables had default/standard cost estimate of $1000/cable.
>
I remember something which looked like an aluminum ladder being put
up in the ceiling so that all that cabling didn't fall on our heads.
I visited a science lab about 10 years ago. I was introduced to their
network closet. I was struck by how little space was needed compared
to when I was working on the -10s for comm.
/BAH
jmfbahciv
> On Mon, 07 Dec 2009 08:29:22 -0500
> jmfbahciv <jmfbahciv@aol> wrote:
>
>> No shit. I remember one of our managers taking a look above the
>> ceiling tiles in our area. There must have been miles and miles
>> and miles of wire up there. A couple of guys tried to trace
>> a plug back to find out which system it was wired to. It took
>> them all night, maybe more.
>
> I can *not* be the only person in this group who has traced a
> network cable through walls and ceilings to find the switch at the end of
> it in a disused cupboard that had been papered over.
>
Wire was a "guy thing". I did not do that kind of work :-).
/BAH
Howard Brazee
>> How big were those, compared to an iPod?
>
>Probably like battleship::kayak.
Physical size. How about capacity?
Eric Chomko
> Charles Richmond wrote:
> > jmfbahciv wrote:
> >> Charlie Gibbs wrote:
It was during lunchtime of that shift.
Gene Wirchenko
But did you choose wallpaper? <BEG>
Has anyone ever done something innocently which ended up creating
such a situation?
Sincerely,
Gene Wirchenko
Morten Reostad
Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>On Mon, 07 Dec 2009 08:29:22 -0500
>jmfbahciv <jmfbahciv@aol> wrote:
>
>> No shit. I remember one of our managers taking a look above the
>> ceiling tiles in our area. There must have been miles and miles
>> and miles of wire up there. A couple of guys tried to trace
>> a plug back to find out which system it was wired to. It took
>> them all night, maybe more.
>
> I can *not* be the only person in this group who has traced a
>network cable through walls and ceilings to find the switch at the end of
>it in a disused cupboard that had been papered over.
The most extreme one was the cupoard containing three important
Linux and BSD servers, a couple of ethernet switches, a KVM,
a large UPS (constidering it only powered the three small 1U
and tower servers plus the switches). Plastered over as a part of
"improving" ventilation. Noone noticed before they were to move
three years later, and noone found the servers. One was a primary
DNS for a large domain.
They were all up and running, NMS happy, everything monitored and
in the best order; and everyone used the KVM when rebooting them.
Story personally verified from three independet sources.
-- mrr
Lloyd Fuller
360/30s with < 256K. Full 2314 = 8 x 800K. I am not sure how many tape
drives, but they were the old 7-track probably 800 BPI.
One or two of them might have been 360/40s. But all of the ones that I
saw in trailers were mod 30s. As far as I know, they all ran DOS: the
first DOS not DOS/VS since they were 306s. I think they ran Power, but
I am not sure.
Lloyd
Scott Rowe
>>> Lloyd Fuller <lefu...@SBCGLOBAL.NET> 12/08/09 8:37 PM >>>
Lloyd
CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you.
Rick Fochtman
>>>How big were those, compared to an iPod?
>>>
>>>
>>Probably like battleship::kayak.
>>
>>
>
>Physical size. How about capacity?
>
>
-------------------------<unsnip>---------------------------------
How about CRAY-1 vs. Slide Rule? :-)
Rick
William Donzelli
> �drives, but they were the old 7-track probably 800 BPI.
>
> One or two of them might have been 360/40s. �But all of the ones that I saw
> in trailers were mod 30s. �As far as I know, they all ran DOS: �the first
> DOS not DOS/VS since they were 306s. �I think they ran Power, but I am not
> sure.
I know this is probably way too obscure, but does anyone know the
JETDS nomenclature of these systems? AN/mumblefoo?
--
Will
Anne & Lynn Wheeler
lefu...@SBCGLOBAL.NET (Lloyd Fuller) writes:
> 360/30s with < 256K. Full 2314 = 8 x 800K. I am not sure how many
> tape drives, but they were the old 7-track probably 800 BPI.
>
> One or two of them might have been 360/40s. But all of the ones that
> I saw in trailers were mod 30s. As far as I know, they all ran DOS:
> the first DOS not DOS/VS since they were 306s. I think they ran
> Power, but I am not sure.
re:
http://www.garlic.com/~lynn/2009r.html#14 "Portable" data centers
previously referenced page (announce & FCS):
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360.html
"page 2" for above:
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360B.html
available store sizes
360/30 ... 16k-64k
360/40 ... 32k-256k
2311s were single drive ... top loader, picture here:
http://en.wikipedia.org/wiki/Early_IBM_disk_storage
1316 disk pack for 2311 ... 7.25mbytes (above says same disk pack used
in earlier 1311 drives)
2314 had 9 drives ... only 8 addressable ... each pack was 29.2mbytes
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2314.html
there were address "plugs" ... possible to open drawer for 9th/spare
drive, put in new pack ... get it powered up ... and pop out the address
plug from one of the other drives and pop it into drive with newly
mounted disk. slightly reduced latency that the system saw when changing
packs.
2400 tape drives, 9trk 800bpi ... could order 7trk model (for handling
older tapes) ... 7trk could select 200bpi, 556bpi, & 800bpi.
http://en.wikipedia.org/wiki/IBM_7_track
360/30 system details with 2400 tapes and 2311 disk drives
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2030.html
i made some contributions to an "online" version of the green card
(sense bytes section) ... done in ios3270. except for the A220
information, the sense information was taken from the 360/67 "blue" card
(had information about features unique to 360/67 ... and rest filled out
with sense information).
I've done a q&d hack on the ios3270 to html
http://www.garlic.com/~lynn/gcard.html
360 channel program tape command codes
http://www.garlic.com/~lynn/gcard.html#25
above has "mode-set" for 7track.
ios3270 was standard package on vm370/cms.
for the 3090 service processor ... it started out with 4331 running a
highly customized version of vm370 release6 with the service panels all
done in (cms) ios3270. by first-customer-ship ... the "4331" service
processor had been upgraded to a pair of 4361s.
DOS/VS was for virtual storage. 370 was initially announced w/o virtual
memory (just a few new instructions, TOD-clock, a few other things).
for entry & mid-range machines, it wasn't too bad to add virtual memory
... but the hardware to add virtual memory to 370/165 became a real
problem. Eventually there was a proposal to eliminate some number of
the original 370 virtual memory features ... which would buy 370/165
schedule six months (concurrent announce and ship of virtual memory for
all models at the same time). The problem then became, for the other 370
models ... to go back and remove the 370 virtual memory features that
were being dropped for 370/165 (and any software that had already been
written to utilize the dropped features had to be rewritten).
for other drift ... "spook base" ... from Boyd biographies ... or
"NKP" discussion
http://www.airforce-magazine.com/MagazineArchive/Pages/2004/November%202004/1104igloo.aspx
the above only mentions two 360/65s ... which could hardly account for
the $2.5B mentioned in Boyd biographies. The above also mentions frogs
generating false positives ... but i've heard stories of other animals
also.
another NKP reference
http://home.att.net/~c.jeppeson/igloo_white.html
Boyd references his stint at NKP in his "Organic Design for Command and Control"
http://www.d-n-i.net/dni/john-r-boyd/
power point version
http://www.d-n-i.net/boyd/organic_design.ppt
above states it is taken from "original" 1987 version scan'ed to pdf.
I believe the original, original version was given at 1983 briefing I
sponsored at ibm ... from which I still have several hardcopies ... a
few pages I transcribed in this old posting (including NKP reference)
http://www.garlic.com/~lynn/94.html#8
i've done some quick searches for other references to use of mainframes
in that time & place ... but not a whole lot show up.
james smith
Had on old Ops manager from Dallas TX who regaled me with stories of these
'portable machine rooms' in Vietnam.
How big they were is irrelevant - they did a job at the time.
jmfbahciv
Couldn't be. There weren't any system crashes caused by
growing cabling.
/BAH
jmfbahciv
> On Tue, 08 Dec 2009 08:32:22 -0500, jmfbahciv <jmfbahciv@aol> wrote:
>
>> Ahem A Rivet's Shot wrote:
>>> On Mon, 07 Dec 2009 08:29:22 -0500
>>> jmfbahciv <jmfbahciv@aol> wrote:
>>>
>>>> No shit. I remember one of our managers taking a look above the
>>>> ceiling tiles in our area. There must have been miles and miles
>>>> and miles of wire up there. A couple of guys tried to trace
>>>> a plug back to find out which system it was wired to. It took
>>>> them all night, maybe more.
>>> I can *not* be the only person in this group who has traced a
>>> network cable through walls and ceilings to find the switch at the end of
>>> it in a disused cupboard that had been papered over.
>>>
>> Wire was a "guy thing". I did not do that kind of work :-).
>
> But did you choose wallpaper? <BEG>
Only when I needed the extra desk space for my listings.
>
> Has anyone ever done something innocently which ended up creating
> such a situation?
>
/BAH
Paul
news:hfljo...@news1.newsguy.com:
> I remember something which looked like an aluminum ladder being
> put up in the ceiling so that all that cabling didn't fall on our
> heads.
Cable trays -- standard practice now, once thought of as an "extra
expense" -- besides, a lot of those cables were probably thought to
be "temporary."
--
Paul
Anne & Lynn Wheeler
Anne & Lynn Wheeler <ly...@garlic.com> writes:
> this old references working on trying to turn out a product that would
> simulate NCP/pu4 to host systems ... simulating activity as
> "cross-domain" ... but all resources were actually owned by the
> networking infrastructure ... and sna RUs then carried in "real"
> networking infrastructure (old posts from decade ago):
> http://www.garlic.com/~lynn/99.html#66
> http://www.garlic.com/~lynn/99.html#67
> http://www.garlic.com/~lynn/99.html#70
re:
http://www.garlic.com/~lynn/2009r.html#0 Small Sever Mob Advantage
a little recent x-over from (linkedin) payment network (part
of long-winded set of comments)
http://www.garlic.com/~lynn/2009r.html#20 70 Years of ATM Innovation
referenced in above
http://en.wikipedia.org/wiki/IBM_Information_Management_System
from above:
much of the world's banking industry relies on IMS, including the
U.S. Federal Reserve. For example, chances are that withdrawing money
from an automated teller machine (ATM) will trigger an IMS
transaction. Several Chinese banks have recently purchased IMS to
support that country's burgeoning financial industry.
... snip ...
also IMS hot-standby ... with respect to the intersection between the
IMS hot-standby work and the "real" networking work was some non-linear
scaling issues with VTAM session re-stablishment ... while IMS
hot-standby was effectively immediately back ... it might take hrs to
get tens of thousands of device/terminal sessions re-established. The
scenario was that the (real) networking would do simulated SNA at
boundaries (as necessary) but was distributed and replicated internally
... and so IMS hot-standby saw opportunity to do shadow sessions on the
standby(s) ... to avoid the long delay getting all the SNA sessions
re-established.
Peter Flass
Probably are. We'll all be wireless before too long. I can see the
day coming when young'uns won't believe people were unable to access the
internet from the middle of the desert, or on top of a mountain.
They'll hear about Shackelton's expedition and say "why didn't they just
text for help?"
Howard Brazee
<Peter...@Yahoo.com> wrote:
>Probably are. We'll all be wireless before too long. I can see the
>day coming when young'uns won't believe people were unable to access the
>internet from the middle of the desert, or on top of a mountain.
>They'll hear about Shackelton's expedition and say "why didn't they just
>text for help?"
Before Samuel Morse, they were all wireless.
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Howard Brazee
To: IBM-...@bama.ua.edu
Subject: Re: Small Server Mob Advantage
<SNIPPAGE>
Before Samuel Morse, they were all wireless.
<SNIP>
We are coming to a time where there are people who have absolutely no
idea who Samuel was or why this is funny.
-- Sent from my BC clam phone --
Patrick Scheible
My wife thinks I'd be safer hiking in the mountains if I took a
cell phone along. I try to tell her, in hilly country the range from
an antenna is maybe a mile, but does she believe me? No....
-- Patrick
Morten Reistad
Howard Brazee <howard...@cusys.edu> wrote:
>On Wed, 09 Dec 2009 13:52:39 -0500, Peter Flass
><Peter...@Yahoo.com> wrote:
>
>>Probably are. We'll all be wireless before too long. I can see the
>>day coming when young'uns won't believe people were unable to access the
>>internet from the middle of the desert, or on top of a mountain.
>>They'll hear about Shackelton's expedition and say "why didn't they just
>>text for help?"
You seem to make the fallacy that a consumer interface without cables
does not require any. Plain wrong. We are squeezing in more and more
signal into the same bandwitth all the time; in WiFi, WiMax (less, still),
GSM etc. The noise floor keeps creeping up, and the bandwidth per hertz
keeps going up. This means lots of smaller cells, and more, way more,
not less, cabling needed to hold it all together.
-- mrr
Charles Richmond
Get a "satellite cell phone". You can call your wife from the top
of Mt. Everest with one of those.
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
Patrick Scheible
> Patrick Scheible wrote:
> > Peter Flass <Peter...@Yahoo.com> writes:
> >
> >> Paul wrote:
> >>> jmfbahciv <jmfbahciv@aol> wrote in
> >>> news:hfljo...@news1.newsguy.com:
> >>>
> >>>> I remember something which looked like an aluminum ladder being
> >>>> put up in the ceiling so that all that cabling didn't fall on our
> >>>> heads.
> >>> Cable trays -- standard practice now, once thought of as an "extra
> >>> expense" -- besides, a lot of those cables were probably thought to
> >>> be "temporary."
> >>>
> >> Probably are. We'll all be wireless before too long. I can see the
> >> day coming when young'uns won't believe people were unable to access the
> >> internet from the middle of the desert, or on top of a mountain.
> >> They'll hear about Shackelton's expedition and say "why didn't they just
> >> text for help?"
> >
> > My wife thinks I'd be safer hiking in the mountains if I took a
> > cell phone along. I try to tell her, in hilly country the range from
> > an antenna is maybe a mile, but does she believe me? No....
> >
>
> Get a "satellite cell phone". You can call your wife from the top
> of Mt. Everest with one of those.
They're still pretty big to take in a backpack though. Not to mention
expensive. There are ones that just send a distress signal to the
authorities with your GPS coordinates, the prices on them are coming
down.
A more fundamental problem is that if you're on a mountaintop, you're
on your own for at least several hours no matter how good your phone
is. Possibly a lot longer if the weather is bad.
-- Patrick
jmfbahciv
/BAH
Paul
news:hfqpn...@news1.newsguy.com:
Yes, at least most of the ones I have seen.
--
Paul
Howard Brazee
>>> I remember something which looked like an aluminum ladder being
>>> put up in the ceiling so that all that cabling didn't fall on our
>>> heads.
>>
>> Cable trays -- standard practice now, once thought of as an "extra
>> expense" -- besides, a lot of those cables were probably thought to
>> be "temporary."
>>
>Thanks. Were they aluminum?
I imagine because light is good - especially if the ceiling wasn't
designed to support weight.
Ed Finnell
In a message dated 12/10/2009 9:42:45 A.M. Central Standard Time,
howard...@CUSYS.EDU writes:
I imagine because light is good - especially if the ceiling wasn't
designed to support weight.
>>
Many fire codes prohibit aluminum conduit and trays. Varies by city...
Scott Lurndal
Most of the ones I've seen, and those we have in our datacenter are
constructed from steel tubing.
Called "ladder rack".
http://www.connectworld.net/data_center/cable_ladder_rack.html
scott
jmfbahciv
That's the reason the ladders, or cable trays, were put up there;
so the weight would be distributed over the whole ceiling.
/BAH
jmfbahciv
seeing if any of ours were attached to a support column.
I would doubt it since there were maybe two or four in our office
area.
/BAH
Shmuel Metz , Seymour J.
at 11:11 PM, Anne & Lynn Wheeler <ly...@GARLIC.COM> said:
>for the 3090 service processor ... it started out with 4331 running a
>highly customized version of vm370 release6
ITYM VM/SP R6; I don't believe that IBM was still using VMF/370 (free VM)
internally by the time the 3090 came out.
>DOS/VS was for virtual storage. 370 was initially announced w/o virtual
>memory (just a few new instructions, TOD-clock, a few other things).
But there were strong indications that the 370/145 had paging. The
implementation of the DOS Emulator Feature only made sense if the hardware
was designed for paging.
--
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.
at 12:56 PM, Lloyd Fuller <lefu...@SBCGLOBAL.NET> said:
>What do you mean Sun was the first?
>The US Army used 360/30 and 360/40s in 18-wheel trailers back in the
>early 1960s - 40 years before Sun "thought" of the idea. The Army even
>had those in Vietnam for the division data centers.
And MOBIDIC (sp?) was earlier than that.
Staller, Allan
<snip>
>What do you mean Sun was the first?
>The US Army used 360/30 and 360/40s in 18-wheel trailers back in the
>early 1960s - 40 years before Sun "thought" of the idea. The Army even
>had those in Vietnam for the division data centers.
And MOBIDIC (sp?) was earlier than that.
</snip>
Anne & Lynn Wheeler
>>for the 3090 service processor ... it started out with 4331 running a
>>highly customized version of vm370 release6
>
> ITYM VM/SP R6; I don't believe that IBM was still using VMF/370 (free VM)
> internally by the time the 3090 came out.
>
>>DOS/VS was for virtual storage. 370 was initially announced w/o virtual
>>memory (just a few new instructions, TOD-clock, a few other things).
>
> But there were strong indications that the 370/145 had paging. The
> implementation of the DOS Emulator Feature only made sense if the hardware
> was designed for paging.
re:
http://www.garlic.com/~lynn/2009r.html#18 "Portable" data centers
the modifications for vm370 release 6 to be service processor started
well before 3090 came out. it was a copy of standard vm370 release 6
(predates vm/sp) and then "frozen" (with respect to the standard
product) and then various enhancements added ... like interfaces to all
the diagnostic hardware that was going to be in the 3090. i provided
some number of tools and other stuff, supporting the effort. Some of the
stuff was things I had done for the disk engineering & product test labs
... to eliminate large class of failures (they had been running
stand-alone with trivial monitor ... after having tried to use MVS and
experienced 15min MTBF with a single "testcell"):
http://www.garlic.com/~lynn/subtopic.html#disk
At the time they had started the effort ... they gathered up as much
stuff as they could ... anticipating that vm370 release 6 ... would not
be current thru the lifetime of the 3090; TROUT ... some past posts with
other old email from TROUT period:
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
i was blamed for onlined computer conferencing on the internal network
in the late 70s and early 80s. The POK engineering manager that headed
up the 3090 service processor ... had observed all the issues with the
3081 service processor ... having to write everything from scratch and
was a big proponent of using as much as possible readily available tools
(i.e. 3090 service processor screens were actually CMS IOS3270). In any
case, the guy heading up the effort also became somewhat active in some
of the computer conferencing and took some amount of hits for the
activity (although not nearly as much as I did). He also took hits on
scope-creep in the effort and growing demand for people and resources.
DOS Emulator feature had base/bound (significantly simpler than all the
segment and page table stuff; just check the address against the "bound"
... and then add in the "base") ... not for paging but for address
translation ... like some LPAR implementations ... still required a
contiguous amount of real-memory.
I was undergraduate in the 60s ... but still doing a lot of work on both
os/360 (responsible for academic and administrative system at the
univ. ... including doing highly customized os/360 system for careful
placement of datasets and PDS members to optimize arm seek & getting
approx three times thruput improvement for student jobs). I was also
allowed to do a lot of cp67 ... rewritting lots of the kernel code.
Anycase, recent posts about Boeing trying to move all of their
dataprocessing into BCS (fledging BCS started out in boeing
corporate hdqtrs administrative ... which had single 360/30
for payroll):
http://www.garlic.com/~lynn/2009r.html#43 Boeings New Dreamliner Ready For Maiden Voyage
http://www.garlic.com/~lynn/2009r.html#44 Boeings New Dreamliner Ready For Maiden Voyage
http://www.garlic.com/~lynn/2009r.html#45 Boeings New Dreamliner Ready For Maiden Voyage
and I got dragged into it. I was con'ed into giving one week class
(during spring break, '69) to the fledging BCS technical staff (and the
ibm technical support team). I was then brought in as full-time BCS
employee for the summer of '69. Part of responsibility was installing
cp67 operation in corporate hdqtrs machine room (which until then just
had a 360/30 for payroll). Part of BCS was to take over the renton
datacenter (a little corporate internal politics) ... which was the
largest operation I had seen ... summer of '69 there were always pieces
for 2-3 360/65s staged around in the hallways ... because 360/65s were
arriving faster than they could be installed.
In any case, after 370s were available ... but not yet with virtual
memory support ... one of the IBM SEs on the boeing account did a
"hacked" version of cp67 to use 370 DOS Emulator (aka address
base+bound, contiguous real storage) ... again much more like LPAR
support. He did do complete swap of a virtual machine address space
(i.e. virtual machine size had to match the base+bound contiguous area)
... so could run more virtual machines that there was total real storage
available.
As mentioned in the above ... summer of '69 ... Boeing also moved the
360/67 multiprocessor from Huntsville to Seattle (this was separate from
the 360/67 uniprocessor installed in corporate hdqtrs). Huntsville had
been using it to run a highly modified version of MVT release 13.
Problem was that MVT had significant problem with storage fragmentation
with long running jobs. Huntsville had a large collection of 2250s with
long running graphics application. Hack to MVT was to use the 360/67
address translation hardware to re-arrange real storage to appear
"contiguous" (no paging) ... this was different than the early 370 hack
to cp67 to use the base+bound (instead of full address translation) and
real contiguous storage for primitive virtual machine swapping.
Before virtual memory was announced, 370/145s weren't shipped with the
microcode-load to support virtual memory ... however, the front panel
"rollers" for the PSW ... had a "xlate" label for one of the bit/lights.
for other topic drift, recent post about science center working with
endicott on support 370 virtual memory architecture ... before hardware
was even available:
http://www.garlic.com/~lynn/2009r.html#38 While watching Biography about Bill Gates on CNBC last Night
http://www.garlic.com/~lynn/2009r.html#39 While watching Biography about Bill Gates on CNBC last Night
http://www.garlic.com/~lynn/2009r.html#40 While watching Biography about Bill Gates on CNBC last Night
science center worked with endicott to modify cp67 (running on 360/67)
to provide support for 370 virtual machines. This required having a
"370" option ... and then simulating new instructions and misc. other
stuff for "370" virtual machinesl
Then a "different" cp67 was modified to run in those "370" virtual
machines (rather than on 360/67, this "CP67I" was regularly running in
370 virtual machine a year before hardware became available). This
370'ized cp67 was used by endicott for testing ... when they had an
engineering 370/145 with first virtual memory hardware working.
other lore ... unbundling announcement was 23jun69 ... misc. past
posts
http://www.garlic.com/~lynn/submain.html#unbundle
and they started charging for application software, SE services, other
stuff ... but managed to make the case that kernel software was still
free.
one of the things I did as undergraduate at the univ. was add tty/ascii
support to cp67. Part of that was trying to make the 2702 do something
that it couldn't really do. Somewhat as a result, the univ. started
a clone controller effort ... where the channel interface was reverse
engineered and channel interface board built for an Interdata/3. The
Interdata/3 was then programmed to simulate 2702 (but with the
additional stuff I wanted to do). This got written up, blaming four
of us for clone controller business
http://www.garlic.com/~lynn/subtopic.html#360pcm
Clone controller business has been cited as major motivation for the
"future system" effort ... which was going to completely 360/370 ...
and as different from 360/370 as 360 had been from prior generations.
some past posts
http://www.garlic.com/~lynn/submain.html#futuresys
Eventually FS effort was killed ... but during the effort ... the 370
product pipeline was allowed to dry up (since it was going to be
completely replace) ... and when it was killed there was mad rush to get
stuff back into (hardware & software) 370 product pipeline. The lack of
products was also credited with allowing clone processors to gain a
foothold in the market.
I had done a lot of stuff for cp67 as undergraudate ... that was picked
up and shipped in the product. For the morph from cp67->vm370 much of
that was dropped as "simplification". Now, all during the future system
effort, I continued to do 370 stuff (and ridiculed pieces of the FS
activity ... which wasn't exactly a career enhancing thing to do, since
the senior executives were still senior executives after the dust
cleared). Misc. old email about 370 stuff:
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430
so the mad rush to get stuff back into the product pipeline, included
picking up some stuff that I had continued to do (a lot that had been
dropped in the morph from cp67->vm370). Some of it was incorporate in
standard product releases ... however a portion was selected to be
release as a separate "resource manager" component. And then, somewhat
motivated by the clone processors foothold in the market ... it was
decided to start transition to charging for kernel software ... and my
"resource manager" was selected to be the guinea pig. As a result I had
to spend some amount of time with lawyers and busines people about
kernel software charging policies.
vm370 release 6 "product" then was towards the end of this transition
... the base product was free ... but there was BSEPP (entry &
mid-range, aka endicott machines) & SEPP (high-end, pok machines)
chared-for "add-ons".
In any case, There was no vm370 release 7 ... the next release was all
"charged for" and called VM/SP release 1 (no separate kernel free and
non-free, it was all non-free). Then the next stage was the OCO-wars
... not only charged-for ... but no longer shipping full source ... and
providing full source maintenance on monthly PLC service tapes.
Another result of the unbundling announcement ... was major blow to SE
education ... basically apprentice type operation as parge of SE team at
customer account (couldn't figure out how to justify charges for this
activity ... but required to). This was original motiviation for
HONE ... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#hone
... allow SEs in the branch office to play with operating systems in
cp67 virtual machines. After initial 370 announcement ... the
non-virtual memory 370 "changes" (few new instructions, other stuff) was
incorporated into the HONE cp67 systems (allowing ipl of 370 operating
systems gen'ed to use the new instructions).
Anne & Lynn Wheeler
> up and shipped in the product. For the morph from cp67->vm370 much of
> that was dropped as "simplification". Now, all during the future system
> effort, I continued to do 370 stuff (and ridiculed pieces of the FS
> activity ... which wasn't exactly a career enhancing thing to do, since
> the senior executives were still senior executives after the dust
> cleared). Misc. old email about 370 stuff:
> http://www.garlic.com/~lynn/2006v.html#email731212
> http://www.garlic.com/~lynn/2006w.html#email750102
> http://www.garlic.com/~lynn/2006w.html#email750430
re:
http://www.garlic.com/~lynn/2009r.html#49 "Portable" data centers
in the early 80s, I wrote a "open door" about my salary and being
underpayed. After a couple weeks, I got back a written response from HR
saying that they had studied my completely employee history and I was
being payed exactly what I was suppose to.
This was about the time I was being asked to interview new hires
... supposedly to work in a new group under my (technical)
direction. They told me what HR was offering them as starting salaries.
I then wrote I follow-up to HR's response ... pointing out that they
were offering starting salaries to these new hires that was 1/3rd more
than I was currently making.
A couple weeks later I got the first of a series of raises that would
eventually bring me up level to starting salaries that HR was offering
the new hires that I was interviewing. It was (then) fairly obvious that
HR's initial response wasn't true.
old post mentioning being told "never forgive you for being right"
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
misc. recent posts referencing "business ethics is oxymoron", Boyd's "to
be or to do", and/or the "never forgive you for being right" quote:
http://www.garlic.com/~lynn/2009.html#53 CROOKS and NANNIES: what would Boyd do?
http://www.garlic.com/~lynn/2009b.html#25 The recently revealed excesses of John Thain, the former CEO of Merrill Lynch, while the firm was receiving $25 Billion in TARP funds makes me sick
http://www.garlic.com/~lynn/2009e.html#37 How do you see ethics playing a role in your organizations current or past?
http://www.garlic.com/~lynn/2009g.html#56 Old-school programming techniques you probably don't miss
http://www.garlic.com/~lynn/2009h.html#5 mainframe replacement (Z/Journal Does it Again)
http://www.garlic.com/~lynn/2009h.html#71 My Vintage Dream PC
http://www.garlic.com/~lynn/2009h.html#74 My Vintage Dream PC
http://www.garlic.com/~lynn/2009k.html#73 And, 40 years of IBM midrange
http://www.garlic.com/~lynn/2009o.html#47 U.S. begins inquiry of IBM in mainframe market
http://www.garlic.com/~lynn/2009o.html#52 Revisiting CHARACTER and BUSINESS ETHICS
http://www.garlic.com/~lynn/2009o.html#57 U.S. begins inquiry of IBM in mainframe market
http://www.garlic.com/~lynn/2009p.html#34 big iron mainframe vs. x86 servers
http://www.garlic.com/~lynn/2009p.html#60 MasPar compiler and simulator
http://www.garlic.com/~lynn/2009q.html#37 The 50th Anniversary of the Legendary IBM 1401
http://www.garlic.com/~lynn/2009q.html#38 The 50th Anniversary of the Legendary IBM 1401
http://www.garlic.com/~lynn/2009r.html#6 Have you ever though about taking a sabbatical?
Rick Fochtman
But there were strong indications that the 370/145 had paging. The
implementation of the DOS Emulator Feature only made sense if the
hardware was designed for paging.
IIRC, the DAT box was optional on the 370/145 and became standard on the
370/148. Ditto the 370/155 and 370/158 and 370/165 and 370/168. The 168
was unique in the 370 series because it used outboard channels; as I
recall , it was the only 370 that did so.
Rick
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Rick Fochtman
> Sent: Thursday, December 17, 2009 2:11 PM
> To: IBM-...@bama.ua.edu
>
> --------------------------<snip>-----------------------------
> But there were strong indications that the 370/145 had paging. The
> implementation of the DOS Emulator Feature only made sense if the
> hardware was designed for paging.
> --------------------------<unsnip>---------------------------
> IIRC, the DAT box was optional on the 370/145 and became
> standard on the
> 370/148. Ditto the 370/155 and 370/158 and 370/165 and
> 370/168. The 168
> was unique in the 370 series because it used outboard channels; as I
> recall , it was the only 370 that did so.
>
> Rick
We ran DOS/VS and OS/VS1 on a couple of 145s at the City of Fort Worth in the late 1970s. It was my first job out of college.
--
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
Rick Fochtman
And MOBIDIC (sp?) was earlier than that.
Are you sure that MOBIDIC isn't a social disease ??? :-)
Rick
Anne & Lynn Wheeler
rfoc...@YNC.NET (Rick Fochtman) writes:
> IIRC, the DAT box was optional on the 370/145 and became standard on
> the 370/148. Ditto the 370/155 and 370/158 and 370/165 and
> 370/168. The 168 was unique in the 370 series because it used outboard
> channels; as I recall , it was the only 370 that did so.
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
most 370/145s could have 370 virtual memory enabled with just
a different microcode load.
the real bear was all the hardware needed to upgrade a 370/165 for
virtual memory. this was so difficult that 370 virtual memory
announcement was slipping ... finally there was a case made to drop
several features from the 370 virtual memory architecture ... in order
to buy back some of the 370/165 schedule slippage. this required other
models that already had full virtual memory running ... to remove the
dropped features. also software that had already been written to utilize
the full 370 virtual memory features had to be redone.
370/148 (& 138) had additional storage for microcode and there was big
push to add operating system microcode enhancments ... to help
differentiate the 138/148 from some of the clones (especially in world
trade countries). As referenced in these recent posts ... I got
talked into doing a lot of the work for ECPS
http://www.garlic.com/~lynn/2009r.html#17 How to reduce the overall monthly cost on a System z environment?
http://www.garlic.com/~lynn/2009r.htmL#38 While watching Biography about Bill Gates on CNBC last Night
this old post has some of the kernel analysis that was used in choosing
what went into ECPS microcode:
http://www.garlic.com/~lynn/94.html#21
I also got dragged into lots of the product planning meetings for
138/148 with business meetings at various world trade locations
(positioning 138/148 against clones in foreign markets). endicott was on
its way to making 370/148 a product offering that came with vm370
pre-installed with everything running under vm370 (regardless of
whatever else the customer ran ... a little like current LPAR
environment). this was vetoed by corporate hdqtrs when POK convince
corporate that vm370 product was to be killed, the burlington mall
development group shutdown and all the people moved to POK ... as
necessary in order to make the mvx/xa ship schedule. endicott eventually
managed to save the vm370 product mission ... but essentially had to
reconstruct a development group from scratch (but too late to make vm370
come preinstalled on all 148s).
the issue in the entry & mid-range machines was that 370 instructions
were simulated in native micro-engine instructions ... tended to
avg. approx. ten native instructions for every 370 instruction. ECPS was
able to drop 370 kernel instructions into native instructions at nearly
1:1 ... resulting in ten times speedup. In some cases, when something
similar was attempt for POK "high-end" machines ... there were cases
where it actually ran slower ... the problem was that the hardware had
been optimized to the point that 370 instructions were running at nearly
full hardware speed (already). Even the later SIE had some scenarios
where it would run slower than direct kernel 370 code. Some of this
is touched on in this previously mentioned old email
http://www.garlic.com/~lynn/2006j.html#email810630
in this post
http://www.garlic.com/~lynn/2006j.html#27 virtual memory
that discusses some of the difference between the 3081 SIE and 3090 SIE
implementation. There was even scenarios were the 3081 service processor
had to perform "microcode" paging operations (using a 3310/piccolo FBA
device).
there was 370/195 with outboard channels (basically an upgraded of
360/195 with few additional instructions ... but never got any of the
virtual memory support upgrade).
165 & 168 had outboard channels. 370/158 had integrated channels. for
303x ... the 303x (outboard channel) channel director was a 370/158
engine with the integrated channel microcode ... but w/o the 370
instruction set microcode. A 3031 ... then was two 370/158 engines ...
one with the integrated channel microcode (but w/o 370 instruction set
microcode) and a processor (with the 370 instruction set microcode but
no integrated channel microcode). A 3032 ... was a 370/168 with new
covers ... and reconfiguration to use the 303x channel director as its
outboard channels. A 3033 started out being 370/168 wiring diagram
mappped to chips that were about 20% faster (which would have resulted
in machine about 20% faster than 168-3). The chips also had about ten
times the circuits per chip ... that were going to be left
unused. Before 3033 shipped there was effort to redo critical sections
of 168 logic to better utilize the extra circuits (picking up speed by
doing more things "on-chip" ... rather than the latency of going
"off-chip). The 3033 eventually shipped about 50% faster than 168-3.
sjr/bldg.28 was still running an aging MVT 370/195 system when the
bldg.15 disk product test lab got an early engineering 3033. Carefully
pipelined ... 370/195 would peak at about twice 3033 sustained thruput
... however most codes ran about same thruput on 370/195 as 3033. The
batch turn-around on the MVT system could be a couple weeks ... even for
some things like the air-bearing simulation program that was part of
3380 disk head design. getting to play disk engineer in both bldg14 disk
engineering and bldg15 disk product test ... and providing them an
operating system ... so they could do on-demand testing of multiple
testcells simulataneously ... allowed me some latitude in running other
types of applications on those machines (even several testcell testing
load was only couple percent of processor ... since it was strictly i/o
intensive) ... aka previously disk testcell testing, running
stand-alone, was prescheduled around the clock, one testcell at a time.
In any case, was able to move the air-bearing simulation work over to
the 3033 in bldg15 ... and provide on-demand compute intensive service.
misc. past posts mentioning getting to play disk engineer
http://www.garlic.com/~lynn/subtopic.html#disk
Anne & Lynn Wheeler
> 138/148 with business meetings at various world trade locations
> (positioning 138/148 against clones in foreign markets). endicott was on
> its way to making 370/148 a product offering that came with vm370
> pre-installed with everything running under vm370 (regardless of
> whatever else the customer ran ... a little like current LPAR
> environment). this was vetoed by corporate hdqtrs when POK convince
> corporate that vm370 product was to be killed, the burlington mall
> development group shutdown and all the people moved to POK ... as
> necessary in order to make the mvx/xa ship schedule. endicott eventually
> managed to save the vm370 product mission ... but essentially had to
> reconstruct a development group from scratch (but too late to make vm370
> come preinstalled on all 148s).
re:
http://www.garlic.com/~lynn/2009r.html#51 "Portable" data centers
there was a joke about the head of POK being a major contributor to
vax/vms ... because so many people didn't move to POK (when burlington
mall location was shutdown) ... but left and went to work for DEC.
other trivia ... the cp67 group split off from the science center ... on
4th flr of 545 tech
http://www.garlic.com/~lynn/subtopic.html#545tech
and took over the (IBM) boston programming group on the 3rd flr (both
space and many of the people). As it expanded into vm370, it outgrew the
3rd flr and moved out into the vacated SBC bldg in burlington mall (had
become vacant as part of the transfer of service bureau corporation to
CDC).
IBM boston programming group only had a portion of the 3rd flr ... the
rest of it was occupied by a group listed on the bldg. directory as a
law firm. However, the phone closet for the 3rd flr was on the IBM side
of the flr ... and the phone company had written the organizations name
on the boxes ... and the other side of the 3rd flr as listed as a
3-letter fed. gov. agency.
this was back in the days of lots of demonstrations in the boston and
cambridge area. One day, one of the groups phoned the FBI office in
boston and said that there was a bomb in the boston area office bldg
that had certain "3-letter" gov agency. they then had people stationed
all over the area on the lookout for what bldg. got evacuated.
jmfbahciv
<snip ref-list>
There were a couple of people who left DEC, worked for a year and
then were rehired back for the sole purpose of getting a "raise".
/BAH
Anne & Lynn Wheeler
> 360/195 with few additional instructions ... but never got any of the
> virtual memory support upgrade).
> sjr/bldg.28 was still running an aging MVT 370/195 system when the
> bldg.15 disk product test lab got an early engineering 3033. Carefully
> pipelined ... 370/195 would peak at about twice 3033 sustained thruput
> ... however most codes ran about same thruput on 370/195 as 3033. The
re:
http://www.garlic.com/~lynn/2009r.html#51 "Portable" data centers
370/195 was pipelined and to get peak sustained thruput ... just about
had to be carefully constructed loops totally within the pipeline.
370/195 didn't have branch prediction or speculative execution ... so
(a non-carefully constructed pipeline looping branch) would drain the
pipeline. most codes had frequent branches keeping the pipeline from
being more than half-full and running at half peak thruput (or about the
same as 3033).
the 370/195 group came up with idea for hyperthreading ... basically
emulate two processor smp ... with two PSWs, two sets of registers, etc.
... but no additional pipeline or execution units. the idea was if
single execution stream only kept the pipeline half-full at half-thruput
... then two independent execution streams might be able to keep the
pipeline full and the execution units fully busy.
i got invited to participate because of other work on smp. however,
the effort never got as far as even being announced.
for other drift ... one of the nails in the "future system" coffin
http://www.garlic.com/~lynn/submain.html#futuresys
was analysis that if a FS machine was built from 195 technology
... applications running on such a machine would have thruput of 370/145
(that was one of the FS sections that had a complete enuf definition
that analysis could be perform ... lots of the other FS was so
inadequately defined that couldn't be analyzed). The actual comparison
was Eastern Airlines reservation system (System/one), optimized for
running on 370/195 ... the comparison pointed out that the best thruput
it could expect to achieve (on the highest performance FS system) was
that of running on 370/145
another site of some hardware & FS discussion from
the FS period:
http://www.jfsowa.com/computer/memo125.htm
a few misc. tidbits from above:
Whereas the Model 168 had required 40 months to evolve from development
to initial shipment, the 3033 was shipped to its first customer after
only 28 months in development." IBM achieved that feat by remapping the
Model 168 design into the circuitry intended for VANDERBILT and making a
number of tweaks in the design to improve performance. 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 ...
later the Eastern Airline res system was the basis for Amadeus ... and
my wife severed a short stint as chief architect. Unfortunately she
sided with the selection of x.25 (over sna) ... and the SNA forces
managed to have her replaced. However, it didn't do them any good, since
Amadeus went with x.25 anyway ... a couple recent posts mentioning
Amadeus
http://www.garlic.com/~lynn/2009j.html#33 IBM touts encryption innovation
http://www.garlic.com/~lynn/2009l.html#55 IBM halves mainframe Linux engine prices
Shmuel Metz , Seymour J.
at 02:10 PM, Rick Fochtman <rfoc...@YNC.NET> said:
>IIRC, the DAT box was optional on the 370/145 and became standard on the
>370/148.
No; the "upgrade" on the 370/145 was a new floppy disk.
>Ditto the 370/155 and 370/158 and 370/165 and 370/168.
No; the DAT boxes on the 370/155 and 370/165 were post-delivery field
upgrades[1], not options that you could order. At $200K (155) and $400K
(165), it wouldn't have made economic sense either to offer or to order a
370/155 II or 370/165 II once the 158 and 168 were announced.
>The 168 was unique in the 370 series because it used outboard
>channels; as I recall , it was the only 370 that did so.
The 165, 165 II, 168 and 195 all had outboard channels; I don't know
whether you consider the 370/195 to be a true S/370.
[1] There was no field upgrade from a 165 to a 168, and we had one.
--
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.
at 02:16 PM, Rick Fochtman <rfoc...@YNC.NET> said:
>Are you sure that MOBIDIC isn't a social disease ??? :-)
Ask Herman. AFAIK it also wasn't a big white whale.
--
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)
----------------------------------------------------------------------
Chris Mason
A story concerning the 370/145:
A certain financial institution of a specialised nature much in the news
recently - as a major component of a larger group and then another larger
group just before the crisis - got hold of an early 145 to run alongside and
replace an older machine, probably a 360/50.
Two things conspired together resulting in a catastrophe:
1. They fell out with the SE who used to hold their hand - as SEs did in the
early '70s
2. They got exited about this new-fangled thing called "virtual storage" (VS)
which looked like a "free lunch"
The precise details are hazy but I believe they had the CE install the VS
microcode, they installed a suitable version/release of the operating system
and they transferred their business-critical online application to the new
machine from the old machine.
Unfortunately, the 370/145 did not have as much real storage as the older
machine - but, hey, that's what VS is all about isn't it?
Disaster!
If anyone remembers a cartoon of a skeleton with its bony hand on a 3270,
the equivalent here would be of a skeleton with a bony hand feeding a pass
book into a financial terminal.
Naturally, they wanted to know what had gone wrong. Since it all appeared to
have happened because of the new operating system, they called in the
regional "OS" specialist, a colleague of mine in the same centre.
I might have been called in also as supposedly the regional "teleprocessing"
specialist but I was in the US supporting a most unusual - "online" -
benchmark in K Street, Washington DC, the only location where 2260s were
available for such activity. Or I might at the time of the disaster have taken
up the opportunity to take a holiday in Florida - Daytona Beach - driving on
the sand - that sort of thing!
When I returned, after work I went over to the pub with my thankfully highly
technical boss and my "OS" colleague. There I heard about the disaster with
the online application. Instantly the penny dropped: raw "VS" and raw online
applications are incompatible.
I say raw "VS" but I don't know what adjustments were ever made to make VS
operating systems more friendly to online applications. I do know that the
online application enabling systems such as CICS and IMS got themselves
a "/VS" suffix implying that they were better prepared for a "VS" environment.
Meantime, the recommendation was to limit severely the extent to which you
were able to "over-commit" online applications, vastly less than was possible
with batch applications.
The customer probably reverted to running the application either on the old
machine for a while and then in a probably very greedy - close to 100% -
"working set" if under a "VS" operating system. Given the rather special
enabling software and the rather special financial terminals they were using,
they may well have had to wait until they had migrated to more mainstream
products before finally realising the benefits of "VS" for their online application.
-
> No; the DAT boxes on the 370/155 and 370/165 were post-delivery field
upgrades[1], not options that you could order. At $200K (155) and $400K
(165), it wouldn't have made economic sense either to offer or to order a
370/155 II or 370/165 II once the 158 and 168 were announced.
> [1] There was no field upgrade from a 165 to a 168, and we had one.
At a recognition event in Madrid in 1971, a chief honcho from another financial
institution - also in the news recently for the same reasons as above and also
in a merged form - explained why it was good for IBM customers that they had
made the 370/155 and 370/165 available with IBM knowing full well that the
real excitement, namely "VS", was about to be available fairly shortly - can
anyone fill that in? - afterwards. Bundles of "stick" had been thrown IBM's way
over this and so the event organisers had pushed this eminent gentleman
forward in order to provide the counterargument.
I believe it really worked only if the customer had ordered and taken delivery
of the said machine types at or shortly after announcement. Any who had
ordered and taken delivery just before the 370/158 and 370/168 were
announced was still entitled to be spitting blood.
I actually missed that presentation since the Prado was so much more
interesting.
Chris Mason
On Sun, 20 Dec 2009 11:57:11 -0500, Shmuel Metz (Seymour J.)
<shmuel+...@PATRIOT.NET> wrote:
>In <4B2A904F...@ync.net>, on 12/17/2009
> at 02:10 PM, Rick Fochtman <rfoc...@YNC.NET> said:
>
>>IIRC, the DAT box was optional on the 370/145 and became standard on the
>>370/148.
>
>No; the "upgrade" on the 370/145 was a new floppy disk.
>
>>Ditto the 370/155 and 370/158 and 370/165 and 370/168.
>
>No; the DAT boxes on the 370/155 and 370/165 were post-delivery field
>upgrades[1], not options that you could order. At $200K (155) and $400K
>(165), it wouldn't have made economic sense either to offer or to order a
>370/155 II or 370/165 II once the 158 and 168 were announced.
>
>>The 168 was unique in the 370 series because it used outboard
>>channels; as I recall , it was the only 370 that did so.
>
>The 165, 165 II, 168 and 195 all had outboard channels; I don't know
>whether you consider the 370/195 to be a true S/370.
>
>[1] There was no field upgrade from a 165 to a 168, and we had one.
>
Chris Mason
>...> The US Army used 360/30 and 360/40s in 18-wheel trailers back in the
early 1960s ...
That'll be the *late* '60s.
> These were batch machines running DOS/VS.
... and it will have been DOS/360 not DOS/VS. "VS" did not burst onto
the "360 GT" (370) commercial customer scene until 1972.
Chris Mason
On Mon, 7 Dec 2009 13:05:16 -0800, Lloyd Fuller <lefu...@SBCGLOBAL.NET>
wrote:
>Mouse? the only stinking mouse was the one eating the punch cards! These
were batch machines running DOS/VS.
>
>They did have lots of cable and the installations that I saw were REAL
careful about what kind of traffic even came close to the trailers. In fact
even foot traffic was discouraged!
>
>Lloyd
>
>--- On Mon, 12/7/09, Thompson, Steve
<Steve_T...@STERCOMM.COM> wrote:
>
>> From: Thompson, Steve <Steve_T...@STERCOMM.COM>
>> Subject: Re: "Portable" data centers (was RE: Small Server Mob
Advantage)
>> To: IBM-...@bama.ua.edu
>> Date: Monday, December 7, 2009, 4:00 PM
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu]
>> On
>> Behalf Of Lloyd Fuller
>> Sent: Monday, December 07, 2009 2:57 PM
>> To: IBM-...@bama.ua.edu
>> Subject: Re: "Portable" data centers (was RE: Small Server
>> Mob
>> Advantage)
>>
>> What do you mean Sun was the first?
>>
>> The US Army used 360/30 and 360/40s in 18-wheel trailers
>> back in the
>> early 1960s - 40 years before Sun "thought" of the
>> idea.� The Army even
>> had those in Vietnam for the division data centers.
>>
>> Lloyd
>> <snip>
>>
>> Yeah, and they had 600' of channel cables attached to a
>> jeep to use as a
>> mouse.
>>
>> Sorry, I just couldn't get this cartoon out of my mind of
>> the original
>> mouse...
>>
>> Regards,
>> Steve Thompson
Chris Mason
> 360/30s with < 256K.
The 360/30s I used to support in my trainee days, around 1968, were typically
32K. Indeed DOS/360 was often just called "16K BOS" - if my memory serves
me correctly. The *really* big 360/30s had 64K - wow!
As for DASD, 4 x 2311 was typical. Tape was for the bigger installations, 2 or
4 drives.[1]
> I think they ran Power, but I am not sure.
POWER, the spooling function in DOS/360, was first talked about in about
1969. It came out about the time I migrated from DOS/360 to OS/360.
Chris Mason
[1] At one installation, I tried to impress one of the system programmers by
persuading her to try a COBOL compilation with work files assigned to tape -
something I had just read was possible from the DOS COBOL Guide manual.
Well, I thought it was impressive; I could have watched it all day and it
seemed just the sort of thing films ought to use when they wanted to show "a
computer".
On Tue, 8 Dec 2009 20:37:07 -0500, Lloyd Fuller <lefu...@SBCGLOBAL.NET>
wrote:
>Howard Brazee wrote:
>> On 8 Dec 2009 05:02:00 -0800, jch...@USSCO.COM (Chase, John) wrote:
>>
>>>> How big were those, compared to an iPod?
>>> Probably like battleship::kayak.
>>
>> Physical size. How about capacity?
>>
>
>360/30s with < 256K. Full 2314 = 8 x 800K. I am not sure how many tape
> drives, but they were the old 7-track probably 800 BPI.
>
>One or two of them might have been 360/40s. But all of the ones that I
>saw in trailers were mod 30s. As far as I know, they all ran DOS: the
>first DOS not DOS/VS since they were 306s. I think they ran Power, but
>I am not sure.
>
>Lloyd
William Bishop
The data center was actualy a set of vans connected by a wooden walkway.
Thanks
Bill Bishop
Specialist
Mainframe Support Group
Server Development & Support
Toyota Motor Engineering & Manufacturing North America, Inc.
bill....@tema.toyota.com
(502) 570-6143
Chris Mason <chris...@BELGACOM.NET>
Sent by: IBM Mainframe Discussion List <IBM-...@bama.ua.edu>
12/21/2009 10:22 AM
Please respond to
IBM Mainframe Discussion List <IBM-...@bama.ua.edu>
Anne & Lynn Wheeler
chris...@BELGACOM.NET (Chris Mason) writes:
> I believe it really worked only if the customer had ordered and taken delivery
> of the said machine types at or shortly after announcement. Any who had
> ordered and taken delivery just before the 370/158 and 370/168 were
> announced was still entitled to be spitting blood.
big problem was that 370/165 hardware changes to add virtual memory was
turning out to much bigger job ... and it was holding up virtual memory
announcement. eventually they had to drop several features in the
original 370 virtual memory architecture ... in order to help out the
370/165 hardware implementation and speed up the announcement. then the
other hardware groups had to eliminate the dropped features ... and some
of the software groups that had done implementations using the new
features ... had to go back and figure out other ways of doing things.
big change going from 155/165 to 158/168 was different real storage
technology that was more compact/smaller and about 4-5 times faster.
The 168 microcode engineers also point out that they reduced the
avg. machine cycle/370 instruction from (370/165) 2.1 machine cycles to
(370/168) 1.6 machine cycles.
the faster memory met than when there was a cache miss ... that
the machine waited shorter time for the data.
the low/mid range 370s had "vertical microcode" engines ... more like
familiar computers ... and implementation tended to avg. ten native
instructions per 370 instruction (some simularity to current day
software mainframe simulators running on intel platforms).
high end 370s had "horizontal microcde" engines ... where the "native"
instruction could start lots of different operations in parallel ... as
a result there was some amount of overlap in things that were going on
... and so instead of measure native instructions per 370 instruction
... it was avg. machine cycles per 370 instruction.
part of the issue was that there was an early joint project between the
science center and endicott to modify cp67 to provide full 370 (virtual
memory) virtual machines running on 360/67 (i.e. some of the new
instructures and some format differences between 360/67 virtual memory
tables and 370 virtual memory tables). This was "cp67h" system (running
on 360/67). Then there was modifications to cp67 to run on 370 virtual
memory ("cp67i"). The cp67i system was regularly running in 370 virtual
machine a year before any real 370 virtual memory hardware became
available. In fact, booting/ipling cp67i was originally used to verify
very first engineering machine with virtual memory hardware (370/145).
for a long period it was cp67i that was running on all of the increasing
nuumbers of internal 370/145s with virtual memory (and later "cp67sj"
... which as "cp67i" with support for 3330 & 2305 devices ... added by
san jose).
recent x-over post from a.f.c about this early period with cp67i
http://www.garlic.com/~lynn/2009s.html#1 PDP-10s and Unix
Chris Mason
You may have missed the point I was making here. Lloyd was claiming to be
playing with 360/30s in the *early* '60s and I was adjusting that to
necessarily being the *late* '60s since it could not possibly have been the
early '60s. I was not intending to limit the lifetime of the 360/30 to that
hallucinogenic era.
Indeed I remember hearing about a 360/30 in one customer site where I did
some work sometime in the early '70s which was being retained purely to
perform 1401 emulation! I don't expect it was the only one.
Chris Mason
Lester, Bob
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Chris Mason
Sent: Monday, December 21, 2009 9:21 AM
To: IBM-...@bama.ua.edu
Subject: Re: "Portable" data centers (was RE: Small Server Mob
Advantage)
Indeed I remember hearing about a 360/30 in one customer site where I
did
some work sometime in the early '70s which was being retained purely to
perform 1401 emulation! I don't expect it was the only one.
Chris Mason
Hi Chris,
In 1979-1981, we had a 360/30 as a development box. The production
box at that time was a 360/75J.
BobL
------------------------------------------------------------------------------
This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications.
==============================================================================
Ed Finnell
In a message dated 12/21/2009 9:28:28 A.M. Central Standard Time,
bill....@TEMA.TOYOTA.COM writes:
The data center was actualy a set of vans connected by a wooden walkway.
>>
We flunked a Reforger, cause an M60 ran over the bus/tags connecting the
vans. I don't know why it was there, but it did. There was a spare, but it
pulled the receptacle out the side....
Rick Fochtman
>>IIRC, the DAT box was optional on the 370/145 and became standard on the
>>370/148.
>>
>>
>
>No; the "upgrade" on the 370/145 was a new floppy disk.
>
>
--------------------------<unsnip>----------------------------
Isn't that also an upgrade???
----------------------------<snip>----------------------------------
>>Ditto the 370/155 and 370/158 and 370/165 and 370/168.
>>
>>
>
>No; the DAT boxes on the 370/155 and 370/165 were post-delivery field
>upgrades[1], not options that you could order. At $200K (155) and $400K
>(165), it wouldn't have made economic sense either to offer or to order a
>370/155 II or 370/165 II once the 158 and 168 were announced.
>
<>---------------------<unsnip>-----------------------
Aren't the 155/a55 II/158 "group" the same basic processor, within that
"group"? And aren't the 165/165 II/168 "group" also the same basic
processor, within that group?
--------------------------<snip>------------------------------
>>The 168 was unique in the 370 series because it used outboard
>>channels; as I recall , it was the only 370 that did so.
>>
>>
>
>The 165, 165 II, 168 and 195 all had outboard channels; I don't know
>whether you consider the 370/195 to be a true S/370.
>
>
-------------------------<unsnip>----------------------------------
In re the 165, 165 II and 168, you're quite right. I don't consider the
370/195 to be a true s/370, inspite of the marketting blurbs.
Is it worthwhile to split the hairs so finely? As long as the general
idea gets across? This is all ancient history, mostly of interest to us
"old timers".
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of Ed Finnell
>
>
>
> In a message dated 12/21/2009 9:28:28 A.M. Central Standard Time,
> bill....@TEMA.TOYOTA.COM writes:
>
> The data center was actualy a set of vans connected by a wooden
walkway.
>
>
> >>
> We flunked a Reforger, cause an M60 ran over the bus/tags connecting
the
> vans. I don't know why it was there, but it did. There was a spare,
but it
> pulled the receptacle out the side....
???
M60 is a "portable" machine gun....
-jc-
Lloyd Fuller
Lloyd
--- On Mon, 12/21/09, Chase, John <jch...@USSCO.COM> wrote:
> From: Chase, John <jch...@USSCO.COM>
> Subject: Re: "Portable" data centers (was RE: Small Server Mob Advantage)
Ed Finnell
In a message dated 12/21/2009 2:35:46 P.M. Central Standard Time,
lefu...@SBCGLOBAL.NET writes:
also a tank before .
>>
That's the one! Weighs over 60 tons, doesn't stop for much. Have a good
one....85% first round hits too.
Anne & Lynn Wheeler
rfoc...@YNC.NET (Rick Fochtman) writes:
> In re the 165, 165 II and 168, you're quite right. I don't consider
> the 370/195 to be a true s/370, inspite of the marketting blurbs.
>
> Is it worthwhile to split the hairs so finely? As long as the general
> idea gets across? This is all ancient history, mostly of interest to
> us "old timers".
360/195 to 370/195 added the new instructions for the original 370
announcement. it also added some amount of (370) instruction retry (that
wasn't in 360 flavor ... justification was that 195 had so many discrete
components that even fairly reliable MTBF individual items ... there was
so many ... that the MTBF probability for any piece became
problematical. instruction retry significantly helped with some number
of transient errors. the 195 group feed me all this when I was con'ed in
to helping them look at doing a "SMP" (actually hyperthread) 370/195.
retrofitting virtual memory to 370/165 was extremely difficult ... in
fact, some number of features in 370 virtual memory had to be dropped to
make 370/165 easier/possible/timely.
retrofitting virtual memory to 370/195 would have been significantly
more difficult.
misc. recent posts mentioning 370/195
http://www.garlic.com/~lynn/2009m.html#34 IBM Poughkeepsie?
http://www.garlic.com/~lynn/2009m.html#75 Continous Systems Modelling Package
http://www.garlic.com/~lynn/2009o.html#11 Microprocessors with Definable MIcrocode
http://www.garlic.com/~lynn/2009p.html#82 What would be a truly relational operating system ?
http://www.garlic.com/~lynn/2009r.html#51 "Portable" data centers
http://www.garlic.com/~lynn/2009r.html#59 "Portable" data centers
Rick Fochtman
105mm Main Gun.
Rick
----------------------------------------------------------
Chase, John wrote:
>.
Shmuel Metz , Seymour J.
at 12:34 PM, Lloyd Fuller <lefu...@SBCGLOBAL.NET> said:
>It was also a tank before the M1 Abrams.
Yes, but there was an M1 rifle before there was an M1 tank ;-)
I suspect that M1 and M60 are not the only numbers that the US Army
recycled.
--
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.
at 01:46 PM, Rick Fochtman <rfoc...@YNC.NET> said:
>Aren't the 155/a55 II/158 "group" the same basic processor, within that
>"group"? And aren't the 165/165 II/168 "group" also the same basic
>processor, within that group?
The microinstruction architecture was the same for the 3085, 3155, 3155
II, 3158 and 3031. The E-unit microinstruction architecture[1] was the
same for the 3165, 3165 II, 3168, 3032 and 3033. The consoles for the
3085, 3165, 3165 II and 3168 were almost identical.
>I don't consider the 370/195 to be a true s/370,
The 370/195 had enough S/370 features not present in the 360/195 to at
least raise the question, although I can't quarrel with your answer.
[1] The I/O engines for the 303x processors used the microinstruction
architecture of the 3155.
--
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)
----------------------------------------------------------------------
Rick Fochtman
>In <632703....@web82206.mail.mud.yahoo.com>, on 12/21/2009
> at 12:34 PM, Lloyd Fuller <lefu...@SBCGLOBAL.NET> said:
>
>
>
>>It was also a tank before the M1 Abrams.
>>
>>
>
>Yes, but there was an M1 rifle before there was an M1 tank ;-)
>
>I suspect that M1 and M60 are not the only numbers that the US Army
>recycled.
>
>
>
M60 was also a "General Purpose Machine Gun" (GPMG). I can't tell you
how many I had to repair because of "probably user error" (Closing the
cover with the bolt forward!)
D*** rookies never learned! :-)
Rick
---
A Happy, Healthy and Prosperous New Year to all.