from:"Lynn Wheeler"


[EMAIL PROTECTED] (Mark Post) writes:

That's still probably too much, if only by a little.  The idea is to
force Linux to use as little storage as possible for buffers and
cache, and page out any programs, etc., that haven't been used very
recently.  Letting z/VM handle this via expanded storage, and paging
some things out to real disk turns out to work very well in a shared
environment.  Other techniques, such as having the kernel in a Named
Saved Segment, and executable userspace code in a DCSS using the
eXecute In Place file system helps even more.


previous posts in this thread:
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#46 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#47 Virtual Storage implementation

for more archeological topic drift with regard to DCSS. i had
originally started what i called "virtual memory management"
on cp67 platform at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

this included mapping the cms filesystem to a paged mapped
infrastructure
http://www.garlic.com/~lynn/subtopic.html#mmap

which included a lot of fancy options about moving pages
to/from virtual address space and disk storage. i then
ported this to a vm370/cms environment with a lot of
options for sharing of segments. a variety of some of this
was used in some of the original relation/sql dbms work
... all done on vm370 platform
http://www.garlic.com/~lynn/subtopic.html#systemr

in the early 70s, there was a project called future system
http://www.garlic.com/~lynn/subtopic.html#futuresys

which was going to replace 360/370 with a radically different machine
architecture. this effort absorbed significant corporate resources and
when it was finally canceled (w/o even being announced) there was
significant scrambling to get all sort of items back into the
370 hardware and software product pipeline. 


The resulting mad scramble open opportunity to get a lot of
work  ... that had continued at the science center 
http://www.garlic.com/~lynn/subtopic.html#545tech


on 370s into vm370 product ... including my resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare

that included a large amount of other work not strictly
related to resource management, things like lots of kernel
reorganization for multiprocessor support
http://www.garlic.com/~lynn/subtopic.html#smp

part of that opportunity resulted in releasing an extremely
small subset of the "virtual memory management" work
as DCSS (and the generalized paged mapped infrastructure was
not included). for additional topic drift ... some discussions
of various problems trying to reconcile generalized virtual
memory management features with os/360 address constant convention
http://www.garlic.com/~lynn/subtopic.html#adcon

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Virtual Storage implementation


[EMAIL PROTECTED] (Thompson, Steve) writes:

VSE, as I recall, was told that it had 32MB (or something similar) and
VM then took care of the paging (because VSE didn't page in that case)
-- must understand the memory system used by VSE (similar to VS1).


recent posts in this thread:
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation
http://www.garlic.com/~lynn/2007o.html#46 Virtual Storage implementation

the handshaking had earlier been implemented in cp67 with mvt by
one of the university cp67 installations.

a similar implementation was done for vm370 somewhat in conjunction
with the ecps microcode assist ... for a little topic drift a
recent post in comp.arch mentioning ecps (as well as sie)
http://www.garlic.com/~lynn/2007o.html#42 mainframe performance, was Is a RISC 
chip more expensive?

vs1 typically ran with something like a 4mbyte virtual address space ... 
something
akin to the initial move of mvt to os/vs2 svs which ran with a 16mbyte virtual
address space.

for vs1 handshaking, vm370 gave the vs1 guest virtual machine a 4mbyte machine.
then vs1 mapped its 4mbyte virtual address space one-for-one to the 4mbyte
virtual machine address space (at first glance vs1 had 4mbyte virtual
address space to a 4mbyte machine so it would never get any "guest"
page faults). all the page faults would be happening at the vm370 level,
which would then schedule a psuedo page-fault interrupt for the vs1 guest
while it performed the page replacement operation. This would allow
vs1 to switch to a different task/application ... so that the whole virtual
machine execution wouldn't be blocked just waiting on page fault processing
for a specific task/application. When page fetch had been completed,
vm370 would post a psuedo page fetch completion interrupt to VS1
guest ... so that it might choose to re-enable that faulted
task for execution.

the assumption was that the virtual machine guest is multitasking lots
of different workload and is capable of doing a task switch and continue
execution when a specific task has a missing page.

I had highly optimized both the native vm370 page processing
pathlength as well as selection of code paths to be moved to
microcode as part of the ECPS effort. As a result, it was actually
possible for VS1 to have higher thruput under vm370 than running
stand-alone on the same hardware (w/o vm370; my pathlength for doing page
processing was significantly better than VS1's ... as well as
my page replacement implementation).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Virtual Storage implementation


[EMAIL PROTECTED] (Mark Post) writes:

Oh, and if you create a 64GB z/VM guest, shame on you.  As someone who
is very heavy into z/VM performance once told me, "z/VM is very good
at managing large numbers of small things.  It's not so good at
managing a smaller number of very large things."  I tend to agree.
The z/VM scheduler isn't too happy about guests with large working
sets.


the issue may not so much be a scheduling problem and/or specifically
a "large" working set problem ... as somewhat mentioned in this post:
http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation

there is an implicit assumption in paged virtual memory and working
sets with regard to least-recently-used page replacement algorithms
... which assumes that the page/buffer that has been least-recently-used
in the past is likely to be least-recently-used in the future. however,
virtual guests and various subsystems (which manage storage with
their own least-recently-used algorithm) or likely to exhibit just
the opposite behavior ... the page/buffer that has been least-recently-used
in the past ... is the page/buffer that the virtual guest/subsystem
is going to select for replacement and start using. 


Having a multi-level least-recently-used replacement strategy can
exhibit pathelogical behavior where the next lower level management
has removed the page/buffer  which is going to be the higher level
management operation is most likely to select to start using (the
"hypervisor" closest to the hardware is the lowest level).

lots of past posts mentioning page replacement algorithms and
virtual storage management
http://www.garlic.com/~lynn/subtopic.html#wsclock

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Virtual Storage implementation


[EMAIL PROTECTED] (Ted MacNEIL) writes:

Also, sub-systems like DB2 are getting to the point where you
should/could/would not like it to page.  Sort of throws the concept
out the window, doesn't it?


previous post in thread
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation

one of the things that can happen is if you run a subsystem doing
LRU-like activity management in a virtual address space that is
also being managed with a LRU-like activity management.

I first noticed this in the 70s ... when some of the os/360 migrated to
virtual storage support and were in turn run in a virtual machine.
vm370 was managing the virtual address space (of the virtual machine)
with an LRU-like algorithm  while the guest operating system
was also managing (what it thot to be real storage) with a 
LRU-like algorithm.


if the virtual quest took a page fault ... it would examine its
available storage for the least-recently used page to "replace".  if the
vm370 hypervisor was also paging ... it will also have used the same
criteria to remove the least-recently used page from real storage
... however, this would possibly also going to be the most likely next
page that the virtual guest was going to start using (when it did its
own paging).

dbms subsystems tends to have large buffer storage ... that are managed
in a manner analogous to virtual storage ... i.e. the least recently
used buffer is likely to be replaced with the latest requested record.
A heavily used dbms subsystem is likely going to use the maximum storage
available to it (because it is going to replace its least recently used
buffers with the most recently requested records).

one of my statements from the 70s was that running an LRU-like algorithm
under a LRU-like algorithm can result in very pathelogical behavior and
the virtualized quest/subystem can exhibit exact opposite of behavior of
assumptions that are the foundation of LRU implementations (the least
recently used page is the least likely to be needed in the near future,
a "virtual" LRU-like algorithm is most likely to use the least recently
used page).

lots of past posts mentioning virtual storage page replacement and/or
page/buffer replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#clock

misc. past posts mentioning original rdbms & sql implementation
(originally all done on vm370 platform)
http://www.garlic.com/~lynn/subtopic.html#systemr

including tech. transfer from bldg. 28 to endicott for sql/ds.

for other topic drift one of the people in the meeting mentioned in the
following post claimed to have handled large part of the technology
transfer from endicott to bldg. 90 for DB2
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15

above meeting was related to turning out ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

and other old email related to working on ha/cmp scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

another scenaro of running subsystem in a paged virtual address
space ... which believed that the virtual address space was really
memory was when the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

originally did the port of apl\360 to cms for cms\apl. The problem
was that apl\360 believed its "workspace" was resident real storage
and had a storage allocation strategy that would assign a new storage
location for every assignment statement ... until it had exhausted
the available (workspace) available storage ... at which point
it would do garbage collection and collapse all allocated locations
into contiguous memory ... and then starting all over again. It
wasn't too bad to repeatedly use all of a (real storage) 16kbyte
swapped workspace. However, in cms virtual address space environment,
the available workspace could easily be several mbytes (or even
nearly all of 16mbytes). this would be under cp67 on a 360/67
with typically 512kbytes to 1mbyte of real storage. very quickly it was realized
that the apl\360 storage management and garbage collection implementation
had to be significantly reworked to move it to a virtual memory
environment.

Turns out one of the early major uses of cms\apl on the cambridge
cp67 machine was the business planning people in armonk. prior to
cms\apl, apl\360 with only 16kbyte-32kbyte workspace sizes didn't
provide much room for working on any real world problems. significantly
opening up the apl workspace size with cms\apl allowed for work
on some real world problems. the business planning people loaded
the most sensitive corporate information ... detailed customer
information ... on the cambridge machine and ran sophisticated
business modeling applications implemented in apl.

for other drift, this represented some interested security
issues ... since the cambridge system was also being used
by numerous students and others from colleges and universities
in the cambridge area. recent post on that particular topic
drift:
http://www.garlic.com/~lyn

Re: Virtual Storage implementation

2007-08-30 Thread Anne & Lynn Wheeler


[EMAIL PROTECTED] (Rugen, Len) writes:

Virtual storage isn't exclusive to MVS - z/OS.  One on of the best
presentations I recall was in a VM Performance and Tuning class. 


Together with storage protection keys, page tables can be built to allow
different "users" to have various parts of private, shared for read and
shared for update storage.  (At least update if you're friendly with the
think king and he lets you in key 0).


360/67 was machine that came with virtual memory as standard ... it
could be viewed somewhat as 360/65 with DAT box bolted on to the side
... although the 360/67 multiprocessor was significantly more sophisticated
that 360/65 multiprocessor (for instance, all 360/67 processors in a
multiprocessor complex could address all channels ... which wasn't true
of 360/65 multiprocessors) ... some multiprocessor digression from
a recent thread
http://www.garlic.com/~lynn/2007o.html#37 Each CPU usage

some of the people at the science center 
http://www.garlic.com/~lynn/subtopic.html#545tech


were worried about some of the virtual memory issues ... some historical
comment that atlas virtual memory never worked well ... misc. past posts
mentioning atlas
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate 
CISC? designs)
http://www.garlic.com/~lynn/2001h.html#10 VM: checking some myths.
http://www.garlic.com/~lynn/2001h.html#26 TECO Critique
http://www.garlic.com/~lynn/2003b.html#1 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003m.html#34 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2005o.html#4 Robert Creasy, RIP
http://www.garlic.com/~lynn/2006i.html#30 virtual memory
http://www.garlic.com/~lynn/2007e.html#1 Designing database tables for 
performance?
http://www.garlic.com/~lynn/2007g.html#36 Wylbur and Paging

also reference to cp67 and vm370 historical paper
http://www.princeton.edu/~melinda/

anyway, as result of the concerns about virtual memory, cambridge
modified a 360/40 with custom virtual memory hardware ... prior to
360/67 availability. cp/40 virtual machine system was built for the
custom 360/40 ... which was remapped to cp/67 when 360/67 machines
became available.

virtual memory hardware support was eventually going to be made available
on 370s ... although only 24-bit virtual memory addressing ... 360/67
had support for both 24-bit virtual memory addressing as well as 32-bit
virtual memory addressing.

originally 370 virtual memory was going to have a lot more features.
the translation of the cp67 virtual machine system to vm370 virtual
machine system was going to include use of some of these additional
features. one specific feature that was going to be used was virtual
memory shared segment  allowing the same shared segment to appear
in multiple different virtual address spaces ... and be read/only
protected.

retrofitting 370 virtual memory hardware support to 370/165 ran into
some schedule delays ... in order to make up those delays, lots of
370 virtual memory features were dropped ... and the other machines
that had implemented the full 370 virtual memory support had to
remove the additional features. in escalation meetings about
the trade-off delaying 370 virtual memory availability by
six more months (because of hardware implementation issues for
370/165) or shipping a subset six months earlier ... the favorite
son operating system took the position that they didn't need
any of the additional features.

this had a fairly big impact on vm370 implementation which including
coming up with a emulation of shared segment protection using a
kludge involving storage keys. 


the initial translation of os/360 MVT to virtual memory environment
(for os/vs2 svs) involved creating a single 16mbyte virtual
address space and hacking a simple paging support into the side
of MVT. Then CCWTRANS (from cp67) was integrated into the MVT kernel
to provide for channel program translation (i.e. handle all
the stuff of taking the application space channel program that
had been created with virtual address ... creating a copy substituting
real addresses, pinning the associated pages, and all the
rest of the gorp).

misc. past posts mentioning the 370/165 virtual memory implementation
schedule problems and impact on vm370 implementation
http://www.garlic.com/~lynn/2000.html#59 Multithreading underlies new 
development paradigm
http://www.garlic.com/~lynn/2003d.html#53 Reviving Multics
http://www.garlic.com/~lynn/2003f.html#14 Alpha performance, why?
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment 
protection hack
http://www.garlic.com/~lynn/2004p.html#9 vm/370 smp support and shared segment 
protection hack
http://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment 
protection hack
http://www.garlic.com/~lynn/2004p.html#14 vm/370 smp support and shared segment 
protection hack
http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005.

Re: Each CPU usage

2007-08-29 Thread Anne & Lynn Wheeler


[EMAIL PROTECTED] (Thompson, Steve) writes:

Imagine, you have a 3081 at 100% and you upgraded to a 3084 (basically
you added the other 3081) and you are still at 100%. Or you have a 3033
and you went to a 470/V8. [I'm not saying these were the systems, just
using them as examples.]


3081 was two processor ... and 3084 was pair of 3081s (four-processors).

the basic 370/3033/308x multiprocessor cache coherency started out
slowing the processor speed by 10% to allow for cross-cache chatter
(i.e. raw two-processor thruput was 1.8 times raw single processor
thruput). this is independent of any actual cache invalidates that
were occuring (i.e. just providing for basic cross-cache
communication). 3084 was even worse since each processor cache had to
listen for x-cache chatter from three other processors (rather than
just one other processor).

308x wasn't even going to have a single processor version ... however,
eventually a single processor, 3083 did ship. This was primarily
motivated by ACP/TPF which didn't have multiprocessor at the time
(base 3083 processor was almost 15percent faster than one of the
3081 processors since the multiprocessor x-cache chatter slowdown
was eliminated)

in the 3081 time-frame ... both vm and mvs had kernel storage re-org
to carefully align storage on cache-line boundaries (and multiples of
cache lines). this was to eliminate a lot of cache-line "trashing"
where two different storage locations overlapped in the same
cache-line (and different processors could be simultaneously operating
on the two storage locations). This kernel storage re-org was claimed
to improve system thruput by something over five percent.

the other example was a major restructuring of the vm multiprocessor
support between r6 and sp1. the issue was that since acp/tpf didn't
have multiprocessor support, there was a lot of acp/tpf running under
vm370 on 3081s. for the dedicated acp/tpf, 3081 operations that met
that they ran two copies of acp/tpf (in two different virtual
machines) and/or that one of the processors sat idle most of the time.
for the later case, the multiprocessor restructuring attempting to get
(some amount of) virtual machine kernel processing running on the
"idle" processor (overlapped with acp/tpf execution on the other
processor). This involved introducing a lot of signal processor
instructions to wake the possibly idle processor to get busy on some
execution and return to executing the (acp/tpf) virtual machine
(specific scenario was overlapping siof instruction emulation and
channel program translation with the acp/tpf virtual machine
execution).

the standard virtual machine multiprocessor support was designed for
efficiently handling lots of totally operations. the sp1
reorganization (for acp/tpf overlapped execution) was generic for all
possible execution environments ... and introduced quite a bit of
overhead (in the acp/tpf scenario it was justified on the basis that
it improved overall thruput ... since there was an otherwise idle
processor).

a lot of existing customers moving from r6 multiprocessor support to
sp1 multprocessor support found significant increase in multiprocessor
overhead ... a combination of the significant increase in signal
processor instructions, the corresponding interrupts and a lot of new
"spin-lock" activities (just the "new" "spin-locks" measured as much
as ten percent of each processor).

"spin-locks" were typically used to provide exclusive execution for
lots of kernel code. global kernel "spin-locks" were typical of lot of
60s, 70s and even 80s operating systems (i.e. a single kernel lock
that kernel would attempt to obtain at entry into kernel mode
... interrupt routines, etc ... and spin/loop until it obtain the
lock).

at the science center, 
http://www.garlic.com/~lynn/subtopic.html#545tech


charlie was working on fine-grain multiprocessing kernel locks (lots
of short execution paths rather than the whole kernal) for cp67 when
he invented the compare-and-swap instruction (CAS mnemonic chosen
because they are charlie's initials ... compare-and-swap designation had
to be invented to have something that matched CAS). the attempt to get 
CAS added to 370 architecture was initially rebuffed ... the favorite 
son operating system considered the test&set locking instruction (used 
for os/360 multiprocessor kernel spin-locks) more than sufficient for 370

multiprocessing support. the challenge was to come up with a
non-multiprocessor use for the compare-and-swap instruction ... in
order to get it included in 370 architecture. lots of past posts
mentioning multiprocessor and/or compare-and-swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

this is where the use for a lot of multithreaded application software
(regardless of whether running on multiprocessor hardware) was
invented ..  as well as the programming notes that now appear
in appendix of principles of operation ... i.e.

A.6 Multiprogramming and Multiprocessing Examples
http://publ

Outsourcing loosing steam?

2007-08-19 Thread Anne & Lynn Wheeler


On Aug 15, 11:11 am, [EMAIL PROTECTED] (daver++) wrote:

"Around 1:30 p.m., the CPB experienced problems accessing its database
containing information on international travelers. Assuming this to be a
wide-area network problem, CBP called Sprint, its carrier, to test the
lines. After three fruitless hours of remote testing, Sprint finally
sent technicians on-site. Another three hours passed before Sprint
finally concluded that transmission lines were not the problem, meaning
the problem was inside the CBP local network. After more hours of
troubleshooting, the issue was finally resolved at 11:45 p.m. The real
culprit: a failed router."http://blogs.zdnet.com/projectfailures/?p=346

20,000 stranded because it took over ten hours to diagnose and replace a
failed router. I used to be a mainframe guy that inherited the network
side, so they cut me some slack. BUT- I can guarantee that there wasn't
anywhere near enough slack for me to get off with taking that long to
replace a router. I would have been tarred, feathered and run out of
town. It seems like basic due diligence wasn't even followed. Yes,
Sprint added to the problem, but Sprint never should have been called.
Why call Sprint before determining that the problem isn't on _your_ end?
It is all a bit silly, and it frightens me a bit that our airlines have
this level of quality.


note that inadequate processes in packet networks contribute significantly to
diagnosing the problems. some of the older protocols were much more
circuit oriented ... and could much more rely on telco circuit diagnostics
to identify problems. 


we experience this when we were building reliable network based
infrastructures in the 80s ... and attempting to do some work on
NSFNET infrastructure  misc. collected old emails
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

and to some extent met with quite a bit of corporate resistance ... somewhat
highlighted in this old email:
http://www.garlic.com/~lynn/2006w.html#email870109
in this post
http://www.garlic.com/~lynn/2006w.html#21

note that while tcp/ip is the technology basis for the modern internet, nsfnet
was the operational basis (interconnections of networks, i.e. internetworking),
and cix was the business basis. in the above reference there is somebody in
corporation proposing that sna could be proposed for basis for nsfnet ...
the main issue was the ability to providing internetworking ... interconnection
of large number of different networks.

we later investigated several of the issues in more detail when we were
doing the ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

which required a detailed threat and vulnerability study for high availability
environments. 


we later got to use some of that experience when we were called in to consult
with a small client/server company that wanted to do payments on their server
http://www.garlic.com/~lynn/subnetwork.html#gateway

they had this technology called SSL and the effort is now frequently referred
to as electronic commerce. the initial simple obvious solution was to 
move the payment transaction message formats from their existing circuit-based

environment to a packet-based enviornment. however, that totally ignored much
of the availability, diagnostic, and recovery processews that were available in
the circuit based environment. We eventually developed a set of compensating
processes and procedures attempting to make the availability of the packet-based
environment somewhat compareable to the existing circuit-based environment.

for a little topic drift ... recent comment on availability, diagnosing
and recovery in one of the ATC modernization efforts
http://www.garlic.com/~lynn/2007o.html#18

misc past posts on estimated of 4-10 times the effort to take a well written
application and turn it into an industrial strength service (in the case
of the payment gateway, it was closer to ten times, including inventing
various diagnostic and recovery process to compensate for moving payment
gateway to a packet-based environment)
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap 
(CS)
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- 
Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
http://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding
http://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
http://www.garlic.com/~lynn/2004k.html#20 Vintage computers are better than 
modern crap !
http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both 
crypto and non-crypto?
http://www.garlic.com/~lynn/2004m.html#51 stop worrying about it offshoring - 
it's doing fine
http://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications 
software definit

Re: some questions about System z PR/SM.

2007-08-11 Thread Anne & Lynn Wheeler

[EMAIL PROTECTED] (R.S.) writes:

No.
PR/SM is microcode - a code under OS. Sometimes called "firmware.
z/OS runs in LPAR. Although it can obtaine i.e. LPAR name, it is still
"unaware" from PR/SM and LPARs features. z/OS works in "virtual
machine" (Logical PARtition) and does know that machine.
However some z/OS application, called HCD allows you to define
"hardware configuration" - a set of I/O definitions ("manual Plug and
Play") as well as division of CPC into LPARs. However the resulting
file is simply transmitted to Support Element (notebook inside CPC)
and it is interpreted by PR/SM. Just to complement: Another part of
the file is also read by z/OS during IPL process (however this file is
read from regular DASD, not SE).
The prepared LPAR can be further customized on SE and can be used for Linux.

originally pr/sm was done on 3090 ... somewhat in response to amdahl's hypervisor. it basically is a subset
of virtual machine capability moved into "microcode". in the amdahl scenario ... amdahl had added a
variation called "macrocode" ... which was a 370 instruction variation that sat part way between
the "real" microcode and standard 370 machine instructions. it significantly simplified migrating
virtual machine 370 code into the native machine.

by comparison, 3090 pr/sm was a much more difficult task since it involved implementation
directly in the 3090 microcode. however, much of pr/sm actually leveraged the SIE
instruction which was used by virtual machine operating system to implement virtual
machine mode. pr/sm evolved into supporting multiple concurrent hypervisors as
"LPAR"

for some topic drift ... some old email discussing amdahl hypervisor and
macrocode
http://www.garlic.com/~lynn/2006b.html#email810318

in this post
http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode

some old email somewhat comparing 3081 sie and 3090 sie
http://www.garlic.com/~lynn/2006j.html#email810630

in this post
http://www.garlic.com/~lynn/2006j.html#27 virtual memory

above posts also includes numerous other references to sie, pr/sm, lpars, etc

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI Compliance - Encryption of all non-console administrative access.

2007-08-06 Thread Anne & Lynn Wheeler


Lynn Wheeler <[EMAIL PROTECTED]> writes:

for some topic drift ... part of the issue is that the majority of
such compromises have involved data-at-rest ... not data-in-transit
... and lots of implementations don't provide the access control that
may be found in mainframe installations ... so encrypting the data at
risk might be viewed as compensating process for inadequate access
control. the other part of it is that studies have something like 70
percent of such compromises have involved insiders (who already may
have some level of access).


re:
http://www.garlic.com/~lynn/2007n.html#85 PCI Compliance - Encryption of all 
non-console administrative access.

... above post may have only made it to the newsgroup, not the mailing list

for some additional drift, a recent post in ongoing financial crypto blog 
thread on (effectively) decline in security and assurance over the past several 
decades
http://www.garlic.com/~lynn/aadsm27.htm#53 Doom and Gloom spreads, security revisionism 
suggests "H6.5: Be an adept!"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How old are you?

2007-08-06 Thread Anne & Lynn Wheeler


[EMAIL PROTECTED] (Robert Fake) writes:

I'm 46 years old now.  I started Assembler programming on a 360 when I was
18.  Best move I ever made.  I've always thought that the mainframes were
here to stay and the move to "non-mainframe" platforms was driven
significantly by the trade rags in the 90's.  Our product and services
business is dedicated to support of the mainframe, so I hope it will be
around for many, many more years.


i was undergraduate and had been invited to the spring '68 share meeting for 
cp67 announcement ... 40 yrs next spring ... recent references:

http://www.garlic.com/~lynn/2007n.html#91 Combining VM list threads
http://www.garlic.com/~lynn/2007n.html#92 vm 35th b'day at share in san diego 
next week

i got to present some of the work i had been doing on total rework of os/360
stage2 sysgen and some early rework that i had done on cp67. i also got to
give a more detailed presentation at the aug68 share meeting in boston,
misc. past references:
http://www.garlic.com/~lynn/93.html#1 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions 
about OS/360)
http://www.garlic.com/~lynn/99.html#93 MVS vs HASP vs JES (was 2821)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM obsoleting mainframe hardware

2007-07-01 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Chris Mason) writes:
> One of the presentations was someone from a big UK bank who defended
> IBM having made the 155 and 165 available and relatively shortly
> afterwards having announced the 158 and 168 - together with the
> relatively expensive DAT box extension to the 155 and 165. I hope I'm
> remembering the details about right.
>
> I heard about this only second-hand but I believe the argument was
> that IBM was right to offer the enhanced performance of the 155 and
> 165 as soon as it could in spite of the fact that it knew that the
> virtual storage models were well advanced in development. I guess
> there was a shadow of the "it's illegal to preannounce" principle
> hanging over this.

re:
http://www.garlic.com/~lynn/2007n.html#31 IBM obsoleting mainframe hardware
http://www.garlic.com/~lynn/2007n.html#34 IBM obsoleting mainframe hardware

370/165 ... announce jun70
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3165.html

370/168 ... announce aug72
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3168.html

for virtual memory ... hacking virtual memory support into MVT (for
VS2/SVS) was needed in addition to the virtual memory hardware
retrofitted to 165s (there were significant software as well as hardware
schedules). 

this is similar to previous comments about *crash* program to try and
get out 370-xa (after FS project was killed) and POK in 1976, convincing
the corporation to shutdown vm370 product and transfer all the
developers to POK as part of being able to make mvs/xa (software)
schedule (although Endicott was eventually able to save part of the
vm370 product mission).

i've mentioned before about (370 virtual memory) prototype work that
went on in pok, using 360/67s and hacking "single address space" virtual
memory into the side of MVT ... as well as cobbling in cp67's (ccw
translation) CCWTRAN into MVT ... i.e. cp67 had started out having to
build "shadow" channel programs with real addresses ... for the virtual
machine's channel programs; all the (MVT) channel programs passed via
EXCP ... would be equivalent "virtual address" channel programs
... requiring similar translation (and misc. other things like page
locking/pinning)

recent posts about using CP67's CCWTRANS as part of turning MVT into
os2/svs
http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007f.html#33 Historical curiosity question

The other part ... was that there was a lot of work to retrofit virtual
memory to 165 ... so much so that they ran into schedule problems.  In
order to buy back six months in the 165 virtual memory schedule, there
was an escalation dropping several features from the original 370
virtual memory architecture. Once the 165 engineers had won that battle,
then all the other processors (that had already completed their virtual
memory implementations) ... had to go back and remove the dropped
features.

recent posts mentioning 165-ii schedule issues and impact on dropping
features from original 370 virtual memory architecture
http://www.garlic.com/~lynn/2007f.html#7 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007f.html#16 more shared segment archeology
http://www.garlic.com/~lynn/2007j.html#43 z/VM usability
http://www.garlic.com/~lynn/2007k.html#28 IBM 360 Model 20 Questions

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM obsoleting mainframe hardware

2007-06-29 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Rick Fochtman) writes:
> If the business needs are being satisfied, with reasonable economy,
> who cares whether the box is "the lastest and greatest"? Future
> business needs may or may not dictate upgrades. YMMV

a little search engine mainframe surfing for vm/4341 turned up this story
about a vm/4341 keeping the nyse running will thru the 80s
... apparently with an old mvt system that had been moved from 360/50s
http://www.raylsaunders.com/asmwork.html
that i mentioned in this recent post:
http://www.garlic.com/~lynn/2007n.html#26 VM system kept NYSE running

a quick check just this moment, turns up some problem with the URL
... but (as always) the wayback machine knows
http://web.archive.org/web/20060220161415/http://raylsaunders.com/asmwork.html

for other topic drift ... we spent some amount of time in the early
90s talking to SIAC about using ha/cmp for much of the work that
the tandems were doing (see mainframe MDS-II being
replaced with tandem MDS-IIIs in the above reference) ... lots of
ha/cmp references:
http://www.garlic.com/~lynn/subtopic.html#hacmp

this was in the period that we were also working on ha/cmp
and trying to cram as much computing into dense footprint,
old email references:
http://www.garlic.com/~lynn/lhwemail.html#medusa

I had actually attempted to do something similar nearly a decade
earlier with trying to cram as many 370 chipsets (had about
168-3 thruput) as possible into racks.

the old 8-10 yr cycle for mainframe generations (and obsolescence)
really showed up when the early 70s FS project was killed
http://www.garlic.com/~lynn/subtopic.html#futuresys

since it was going to be something completely different, much of the
work on 370 related stuff pretty much went away. after FS was killed,
there was a scramble to get stuff back into the 370 product pipeline.
370-xa/3081 was going to take eight yrs (early 80s) ... so they had to
find something else that could be done in possibly half that time.

the resulting 303x was quite a bit of warmed over 370. they took the
intergrated channel microcode from 158 and made it stand-alone box
called channel director. Then 158 paired with a channel director became
3031 (with integrated channel microcode running on different
processor). 168 became 3032 repackaged to work with channel
director. 3033 started out as 168 wiring diagram implemented with faster
chip technology. straight-forward mapping would have just been 20percent
faster than 168 ... other tweaks done during development got 3033 up to
1.5times 168.

part of the issue was that up to the 80s, lots of technology was on
7-10yr cycle ... where in the 80s, the rate of change started to
accelerate, for a time, leaving some mainframe technology in the dust.

note that it wasn't just mainframes. circa 1990, there US automobile
(C4) task force looked at being able to accelerate (cut in half) us
automobile product cycle from 7-8yrs (in attempt to get on level playing
field with some of the imports). it was interesting to watch what the
mainframe people were saying in the meetings (since they were
effectively in the same boat). 

one of the things that the automobile industry had been doing would run
parallel new product projects offset by four yrs (so it appeared that
something new was coming out every four yrs). the analogy for mainframes
... was as soon as 3033 was out the door, they started on 3090 (8yr
overlap with 3081 with 4yr offset). in fairly stable industry this
worked since consumer tastes weren't signicantly changing. However the
8yr lag could become significant if there was any significant change in
what the market place was looking for (giving vendors that had much
shorter product cycle a competitive edge).

some recent references to C4 effort circa 1990 ... attempting to
improve competitive footing vis-a-vis several imports:
http://www.garlic.com/~lynn/2007f.html#50 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#29 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#34 U.S. Cedes Top Spot in Global IT 
Competitiveness
http://www.garlic.com/~lynn/2007g.html#52 U.S. Cedes Top Spot in Global IT 
Competitiveness
http://www.garlic.com/~lynn/2007i.html#13 U.S. Cedes Top Spot in Global IT 
Competitiveness
http://www.garlic.com/~lynn/2007j.html#33 IBM Unionization

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Eugene Miya) writes:
> No, the most difficult competition was and is against the IBM PC.
>
> If it did so well, we'd see more evidence of it being around.
> They are not even museum pieces.

re:
http://www.garlic.com/~lynn/2007n.html#20 The Development of the Vital IBM PC 
in Spite of the Corporate Culture of IBM

you didn't read the zillion previous posts mentioning that mid-range
market for both vax/vms and 43xx volumes in departmental server market
started to move to workstations and larger PCs in the mid-80s. above
reference post ... mentions the previous post in the thread ... which made
the same point one more time (and then later the workstations started
to also loose out to PCs).
http://www.garlic.com/~lynn/2007n.html#18 The Development of the Vital IBM PC 
in Spite of the Corporate Culture of IBM

for instance, the 4361/4381 which were expecting similar large volume
sales as seen for 4331/4341 ... never happened. similar numbers can be
seen for vax/vms numbers ... where vax did do some volumes in the
mid-80s with micro-vax ... also readily seen in the repeated references
to decade of vax/vms numbers, sliced & diced by model, yr, domestic,
world-wide, etc
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction

 ... the 4331s/4341s and other mid-market players in the departmental
servers had very little PCs to compete with (late 70s and early 80s)
... it wasn't until you get to the followon machines; 4361s/4381s (and
later vax) that you start to see the workstation/PC effect in the
departmental server market.

one of the contributions to the PCs in the departmental server market
was a project called DataHub which was being done by the san jose disk
division.  Part of the software implementation was being done under
work-for-hire subcontract by a group in Provo (one of the people from
San Jose commuted to Provo nearly every week). At some point, the
company decided to kill the DataHub project and allowed the Provo group
to retain rights to everything that they had done under the
work-for-hire contract.  Not too long later, there was a company out of
Provo with a PC server offering.

misc. past posts mentioning DataHub project:
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/2000g.html#40 No more innovation?  Get serious
http://www.garlic.com/~lynn/2002f.html#19 When will IBM buy Sun?
http://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002o.html#33 Over-the-shoulder effect
http://www.garlic.com/~lynn/2003e.html#26 MP cost effectiveness
http://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
http://www.garlic.com/~lynn/2004f.html#16 Infiniband - practicalities for small 
clusters
http://www.garlic.com/~lynn/2005p.html#23 What ever happened to Tandem and 
NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#9 What ever happened to Tandem and 
NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#36 Intel strikes back with a parallel 
x86 design
http://www.garlic.com/~lynn/2006l.html#39 Token-ring vs Ethernet - 10 years 
later
http://www.garlic.com/~lynn/2006y.html#31 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007f.html#17 Is computer history taught now?
http://www.garlic.com/~lynn/2007j.html#49 How difficult would it be for a 
SYSPROG ?

in the mean time, the communication division had seen a huge install
base of communication controllers grow based on terminal emulation 
http://www.garlic.com/~lynn/subnetwork.html#emulation

which was started to break away into various kinds of client/server ...
they came up with SAA ... somewhat positioned at helping preserve their
communication controller market (and countermeasure to client/server).
A problem we had in this period was that we were making some number of
customer executive presentations on 3-tier (network) architecture ...
and taking flames & barbs from the SAA factions
http://www.garlic.com/~lynn/subnetwork.html#3tier

other recent posts in this same thread:
http://www.garlic.com/~lynn/2007m.html#42 The Development of the Vital IBM PC 
in Spite of  the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007m.html#44 The Development of the Vital IBM PC 
in Spite of  the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007m.html#45 The Development of the Vital IBM PC 
in Spite of  the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007m.html#48 The Development of the Vital IBM PC 
in Spite of the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007m.html#50 The Development of the Vital IBM PC 
in Spite of the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007m.html#57 The Development of the Vital IBM PC 
in Spite of the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007m.html#63 The Development of the Vital IBM PC 
in Spite of

Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


re:
http://www.garlic.com/~lynn/2007n.html#18 The Development of the Vital IBM PC 
in Spite of the Corporate Culture of IBM

the place that 43xx had the most difficult competition against vax/vms
was in the single (at a time) departmental servers (as some of the SHARE
studies highlighted). cost of mid-range computers had dropped below a
threshold that made them very cost-effective in departmental settings
... however scarce people skills and costs then started to dominate as
market inhibitor.

43xx did do very well in large number of departmental server orders
(especially with distributed, networked operation) ... where people
support skill/costs could be amortized across large number of machines.

clusters of 43xx also started to impact 3033. at one point (traditional
internal politics), the head of pok, manipulated east fishkill to cut
the allocation in half of a critical component needed for 43xx
manufacturing. later the same person gave a talk to a large public
audience and made some statement that something like 11,000 vax/vms
orders should have been 43xx ... also referenced in this old post
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

and old email mentioning various 43xx issues ... including moving
workload off 3033 boxes onto 4341 clusters ... and large distributed
departmental server operations.
http://www.garlic.com/~lynn/lhwemail.html#43xx

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Phil Smith III) writes:
> Re RISC vs. 68K:
> Anyone who thinks the RISC chips killed the 68K is off base.  They
> just need to check the dates.  Intel killed the 68K.  Motorola allied
> with IBM on RISC only after Intel had destroyed Motorola's market for
> the 68K.

801 was originally targeted (very) low-end ... ROMP chip was targeted to
be used in a displaywriter follow-in ... when that project was killed,
the group looked around for something to save the effort ... and hit on
the unix workstation market (with the displaywriter follow-on morphing
into unix workstation). lots of unix workstation market place is very
numerical and power hungry ... somewhat as a result ... the followon to
ROMP for that market was large, power-hungry RIOS chipset (i.e. POWER,
announced in RS/6000).  Paperweight on my desk (from original) has six
chips, and says 150 million OPS, 60 million FLOPS, and 7 million
transistors.

somerset was combined ibm, motorola, apple project to do a single chip,
801 PC-level implementation ... the executive we reported to when we
were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

went over to head up somerset. part of somerset including infusing
power/pc with some of motorola's 88k (risc) technology. ROMP and RIOS
were single processer implementations with no provision for
multi-processor cache consistency. power/pc was going to be able to
support cache consistency and multiprocessor operation.

lots of past 801 posts
http://www.garlic.com/~lynn/subtopic.html#801

68k was still hanging in there in 89/90 time-frame ... a couple posts
with some old references from the period (raw chip volumes, business
analysis, etc)
http://www.garlic.com/~lynn/2005q.html#35 Intel strickes back with a parallel 
x86 design
http://www.garlic.com/~lynn/2005q.html#44 Intel strickes back with a parallel 
x86 design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Phil Smith III) writes:
> Re VAX vs. IBM:
> I was a central, low level member of the 4300 series.  I also led the
> engineering side of the fight against the VAX.  We never approached
> the installed base of the VAX machines.  Never.

approach the size of the install base in number of customers or number
of machines or competitive marketing approaching the customers that
bought vaxes?

past post giving decade of vax install numbers sliced and diced by
model, yr, domestic, non-domestic, etc:
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction

both 43xx and vaxes saw huge uptake in the early 80s with the growth of
the department market ... which was starting to move into workstations
and PCs by the mid-80s. as above, the big volumes for VAXes in the
mid-80s were from micro-vax ... not traditional 780 machines.

lots of vaxes were customer orders for one or a very few. vaxes had an
advantage here since their installation and support required a lot less
effort (something that 43xx was constantly fighting ... there were even
some SHARE reports highlighting the resource requirement differences in
competitive environment).

however, there were some number of large customers that ordered 43xx
boxes large lots (hundreds, even large hundreds). the resource support
requirement competitive advantage (in small shops) was mitigated when
amortized across a large number of boxes.

old email about specific customer ordering in hundreds (customer
initially thot 20, but order was finally for 210): 
http://www.garlic.com/2001m.html#email790404
in this post also discussing other "departmental computing" issues from
the period
http://www.garlic.com/~lynn/2001m.html#15 departmental server

lots of old email discussing various aspects of 43xx ... use for
clustering and/or distributed, departmental computing
http://www.garlic.com/~lynn/lhwemail.html#43xx

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Operating systems are old and busted

2007-06-23 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


another article on the same theme:

Leopard and Vista: Last Gasp of the Big OS? 
http://news.yahoo.com/s/pcworld/133276

from above:

Twenty years from now a new generation of computer users will look back
on the operating systems of today with the same bemused smile we look
back at the cars of the late 1950s and early 60s. They had huge fins,
were the size of a small yacht and burned up just about as much gas.

... snip ...

a few similar articles over the past yr:

Windows Vista: The last Of Microsoft's Supersized Operating Systems?
http://www.informationweek.com/blog/main/archives/2006/08/windows_vista_t.html
Windows Vista the last of its kind
http://www.techworld.com/news/index.cfm?NewsID=6718
Vista: The Last Microsoft Operating System that will Matter
http://www.realtime-websecurity.com/articles_and_analysis/2007/01/vista_the_last_microsoft_opera.html
Vista is the last of the dinosaurs
http://www.theinquirer.net/default.aspx?article=36155


other recent posts in this thread:
http://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#66 Off Topic But Concept should be Known 
To All
http://www.garlic.com/~lynn/2007m.html#67 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#68 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#69 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#73 Operating systems are old and busted

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is Parallel Programming Just Too Hard?

2007-06-23 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

Morten Reistad <[EMAIL PROTECTED]> writes:
> Also, log structured file systems, the jfs and contributions to efs3, 
> and huge improvements to the irq and dma routing; including some work
> in processor affinities.

metadata logging is slightly different from log structured file systems.

one of the problems with log structured file systems is the periodic
"garbage collection" done to consolidate files, making their records
sequential and contiguous. for other drift ... during work
on HA/CMP
http://www.garlic.com/~lynn/subtopic.html#hacmp

we hired one of the people responsible for doing the BSD log structured
filesystem implement to consult on doing a "geographically distributed
filesystem".

JFS was originally done by people working on 801/AIXV3. 801 early on had
definition/implementation for "database memory" ... i.e. hardware could
keep track of fine-grain changes (size on the order of cache-lines).
Just load up data into memory mapped infrastructure ... provide the
COMMIT boundaries ... and eliminate needing to sprinkle "log" calls
thruout the code. At commit, just run thru the changed memory
indications ... collecting data-lines needing logging.

There had been various kinds of conflict between the unix development
group in palo alto and the group in austin. The palo alto group took JFS
and ported it to non-801 platforms ... having to retrofit the logging
calls to the software (since they lacked database memory hardware).  It
turns out that the version with explicit logging calls ran faster than
the original implementation (even on the same 801 hardware platform) ...
the commit time scanning of memory for changes tended to be higher
overhead than the explicit log calls.

Then the remaining justification for database memory is the
implementation simplification ... somewhat akin to some of the pushes
for parallel programming (except parallel programming is frequently
explicitly about performance; not trying to trade-off performance
against simplicity).

some of the database memory stuff can be found under the heading of
transactional memory ...  some posts mentioning transactional memory:
http://www.garlic.com/~lynn/2005r.html#27 transactional memory question
http://www.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM 
Journal of R&D
http://www.garlic.com/~lynn/2007b.html#44 Why so little parallelism?

misc. past posts mentioning log structured filesystems
http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/93.html#29 Log Structured filesystems -- think twice
http://www.garlic.com/~lynn/2000c.html#24 Hard disks, one year ago today
http://www.garlic.com/~lynn/2001f.html#59 JFSes: are they really needed?
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction 
count instead of timer
http://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2004g.html#22 Infiniband - practicalities for small 
clusters
http://www.garlic.com/~lynn/2005l.html#41 25% Pageds utilization on 3390-09?
http://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
http://www.garlic.com/~lynn/2006j.html#3 virtual memory
http://www.garlic.com/~lynn/2006j.html#10 The Chant of the Trolloc Hordes
http://www.garlic.com/~lynn/2007.html#30 V2X2 vs. Shark (SnapShot v. FlashCopy)
http://www.garlic.com/~lynn/2007i.html#27 John W. Backus, 82, Fortran 
developer, dies

some past posts mentioning database memory
http://www.garlic.com/~lynn/2002b.html#33 Does it support "Journaling"?
http://www.garlic.com/~lynn/2002b.html#34 Does it support "Journaling"?
http://www.garlic.com/~lynn/2003c.html#49 Filesystems
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2005n.html#20 Why? (Was: US Military Dead during 
Iraq War
http://www.garlic.com/~lynn/2005n.html#32 Why? (Was: US Military Dead during 
Iraq War
http://www.garlic.com/~lynn/2006o.html#26 Cache-Size vs Performance
http://www.garlic.com/~lynn/2006y.html#36 Multiple mappings
http://www.garlic.com/~lynn/2007i.html#27 John W. Backus, 82, Fortran 
developer, dies

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM

2007-06-22 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Phil Smith III) writes:
> Which is the end of the story, boys and girls.  For, while so many
> people focus on how the PC has damaged the mainframe, the mainframe
> still stands tall.  What the PC was meant to destroy, it did destroy -
> the minis and superminis.  DEC went from top of the heap (Queen
> Elizabeth in Boston harbor for DECWorld) to non-existence in less than
> 10 years.  DG is no more.  Wang is no more.  The PC destroyed them
> all.

we were spending some time in SCI (as well as FCS and HIPPI) meetings.

both Sequent and DG would build an SCI machine with four (intel)
processor boards ... for 256process numa machine (convex built an sci
machine with two hp/risc processor board ... for 128processor numa
machine). both DG and sequent are gone ... sequent being absorbed by ibm
... and some recent references that the only surviving sequent
technology may be found in some contributions to linux. HP's superdome
may or may not be considered to be the exemplar follow-on. a couple
recent posts on sci/numa machines:
http://www.garlic.com/~lynn/2007g.html#3 University rank of Computer 
Architecture
http://www.garlic.com/~lynn/2007m.html#13 Is Parallel Programming Just Too Hard?

wang signed a deal with austin (and some of the austin people actually
left and went to work for wang) to use rs/6000 as their hardware
platform (getting out of the hardware business).

in some of the a.f.c. posts, i've frequently pointed out that the late
70s and early 80s saw a significant uptake of mid-range machines in the
departmental server market segment ... both vm/43xx and vax/vms ... with
vm/43xx actually having larger install base than vax/vms (in part
because there were numerous large customer orders for multiple hundred
43xx machines at a time). by the mid-80s that market segment was
starting to be taken over by workstations and large PCs (with
corresponding drop-off in sales of 43xx and vax machines). Later the
more powerful PCs would also take over much of the workstation market.

misc. old email mentioning various happenings around 43xx
http://www.garlic.com/~lynn/lhwemail.html#43xx

there had been anticipation that the introduction of the 4361/4381 would
see compareable uptake to 4331/4341 ... but by then, the market was
already starting to move to workstations and larger PCs.

a couple past posts given domestic and world-wide vax numbers, sliced &
diced by model and yr (post 85, the numbers are primarily micro-vax):
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction
http://www.garlic.com/~lynn/2005f.html#37 Where should the type information be: 
in tags and descriptors
http://www.garlic.com/~lynn/2006k.html#31 PDP-1

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Operating systems are old and busted

2007-06-22 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.

[EMAIL PROTECTED] (Chris Mason) writes:
> ... and thereby put the wait light out[1]. Having been brought up with
> DOS (the original DOS), and, generally, S/360 Model 30s, I was used to
> knowing how busy the machine was by observing the flickering of the
> wait light.

my first undergraduate programming job was to port MPIO from 1401 to
360/30. MPIO provided tape<->unitrecord/printer/punch front-end for
university 709 running ibsys.

it was possible to operate the 360/30 in 1401 emulation mode ...  so i
conjecture that the exercise was purely to get familiarity with new 360
... which would eventually replace both the 709 and the front-end
machine with 360/67.

i got to design and implement my own monitor, device drivers, interrupt
handlers, storage management, consol interface, etc ... and eventually
had assembler program with approx. 2000 cards.

running os/360 pcp (r6) ... the "stand-alone" version assembled in
about 20-25 minutes elapsed time. I had conditional assembly that would
also generate program that would run under PCP and used open/close and
DCB macros. There were five DCB macros and you could tell from the wait
light pattern when the assembler was processing a DCB macro ... and each
one took 5-6 minutes elapsed time ... the os/360 conditional assembly
version took an extra 30minutes (making the assembly nearly an hr
total).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is Parallel Programming Just Too Hard?

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Scott Lurndal) writes:
> Sure there are.  Start with WindRiver.  Then progress to MCP/AS, z/OS,
> Exec/1100 and so forth.   The whole world isn't microsoft, you know.

the person at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

that did the technology that was used in the internetal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

and part of the technology that was used by customers and
in bitnet
http://www.garlic.com/~lynn/subnetwork.html#bitnet

... aka the base technology was extremely layered with effectively
something akin to gateway like function ... it not only deployed
peer-to-peer networking ... but easily provided emulators that could
also talk to HASP/JES2 ... lots of posts mentioning hasp/jes2
http://www.garlic.com/~lynn/subtopic.html#hasp

... a recent x-over reference:
http://www.garlic.com/~lynn/2007m.html#69 Operating systems are old and busted

so by the time of bitnet time-frame ... internal corporate politics was
such that it was restricting shipping support for just the HASP/JES2
interfaces ... even tho the native peer-to-peer implementations were
much more efficient (and still continued to be used internally for some
time).

in any case, the implementation was one of those service virtual
machines (virtual appliances) ... more x-over
http://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#66 Off Topic But Concept should be Known 
To All
http://www.garlic.com/~lynn/2007m.html#67 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#68 Operating systems are old and busted

and included in the implementation was a very small & tightly coded
multitasking monitor (for dispatch/scheduling).

now many yrs later the person had opportunity to be involved in project
that involved one of the major RTOS ... and he happened to be looking
thru the C-source which seemed to be familiar. Eventually checking an
old listing of the multitasking monitor ... it was apparent that they
had done a nearly line-by-line translation of his 360 assembler code
into C ... including preserving all the original comments.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Operating systems are old and busted

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] writes:
> This is fascinating history, Lynn.  I remember using the Prepare  command in 
> channel programs for the 2701 that we used in the TUCC network ca.  1967 on.
>  
> Speaking of old, busted systems and ones that were killed (like FS),  does 
> anybody know anything about the new operating system that Amdahl was trying  
> to 
> build?  I had a phone interview with an Amdahl person in SEP 1987 who  
> mentioned this OS and I started salivating at the prospect of working on that 
>  
> project.  The next thing I knew the project had been killed.

re:
http://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#66 Off Topic But Concept should be Known 
To All
http://www.garlic.com/~lynn/2007m.html#67 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#68 Operating systems are old and busted

Simpson (of HASP fame) ... misc. old posts mentioning hasp
http://www.garlic.com/~lynn/subtopic.html#hasp

including observation that the much of the source for HASP/JES2 internal
networking support (before being released as project) carried the
letters "TUCC" in cols. 68-71. misc. past posts mentioning internal
network (which was mostly vm370 based ... with a few mvs/jes2 around the
perimeter)
http://www.garlic.com/~lynn/subnetwork.html#internalnet

had left the HASP group and started an internal operating system project
called RASP.  It had some of the characteristics of TSS/360, being an
extremely paged mapped oriented operating system (shared some
characteristics of FS, s/38, as/400) ... but purely 370 based.

Later, he left and became an Amdahl fellow in Dallas ... starting a
similar project. There was some litigation as a result that included
some code reviews (to see if any RASP code had leaked out). Some of this
overlapped with the developed of Au/GOLD (aka UTS) ... and there was
appeared to be some amount of anbivalence between the two
groups. Knowing some of the people in both organizations ... I even
tried to do some mediation (ignore for the moment that i didn't work for
them and knew about unannounced, internal projects).

One of the examples I tried to use was the UNIX TSS370 (SSUP) effort
that was being done for internal AT&T use. A lot of the 370 UNIX being
done in the 80s was all being done under VM ... not so much because of
the point in the original subject of this thread ... but because VM370
would provide for hardware EREP (if necessary) on behalf of operating
system in virtual machine ... and an effort to fit UNIX with 370 EREP
was several times larger than any of the efforts just porting UNIX to
370. The TSS370/SSUP strategy being done for AT&T ... had all the
low-level TSS/370 kernel hardware support ... but with UNIX layered
ontop (an alternative approach to giving unix environment a large amount
of 370 EREP).

In any case, I suggested that the two groups might be able to form a
marriage of convenience doing something similar. Didn't happen.

misc. past posts mentioning tss370/ssup, rasp, aspen, au/gold/uts, etc
http://www.garlic.com/~lynn/95.html#1 pathlengths
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/98.html#11 S/360 operating systems geneaology
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again
http://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the 
IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate 
CISC? designs)
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate 
CISC? designs)
http://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate 
CISC? designs)
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001e.html#19 SIMTICS
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001f.html#47 any 70's era supercomputers that ran 
as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001l.html#7 mainframe question
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#9 mainframe question
http://www.garlic.com/~lynn/2001l.html#11 mainframe question
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001l.html#18 mainframe question
http://www.garlic.com/~lynn/2001l.html#20 mainframe question
http://www.garlic.com/~lynn/2002d.htm

Re: Operating systems are old and busted

The following message is a courtesy copy of an article
that has been posted to alt.folklore.computers,bit.listserv.ibm-main as well.


re:
http://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#66 Off Topic But Concept should be Known 
To All
http://www.garlic.com/~lynn/2007m.html#67 Operating systems are old and busted

part of the timesharing issue was whether the off-shift useage charges
(or just plain useage) could justify the off-shift operational costs
... since useage tended to decline significantly offshift and weekends
(although I finally got my home machine for dial-up access mar70 ... it
was 2741 selectric, and have effectively had online access at home ever
since). lots of past posts about timesharing services ... including
commercial (cp67 & vm370) timesharing service bureaus in the 60s & 70s.
http://www.garlic.com/~lynn/subtopic.html#timeshare

in the 60s & thru some of the 70s, machines tended to be leased ... and
there was system meter ... which would rackup charges as the machine was
used ... even when the machine was in "wait" state ... but I/O was
active. The 2702 "prepare" command was mechanism to leave the terminal
lines "prepared" for any terminal operation ... w/o actually having an
active I/O apparent to the system meter.

the incremental machine lease charges and costs having people/operators
present ... was one of the inhibitors for justifying/providing
around-the-clock, 7x24 timesharing operation (since offshift useage
could be extremely spotty).

eliminating system meter running ... when the system wasn't actually
doing anything (just available for doing something) ... and being able
to run with dark-room, unattended operation ... would significantly
lower the off-shift useage threashold that was necessary to justify
leaving the system up, available and operational (significantly helped
in transition for providing production around-the-clock, 7x24
operation).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Operating systems are old and busted

The following message is a courtesy copy of an article
that has been posted to alt.folklore.computers,bit.listserv.ibm-main as well.


re:
http://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted
http://www.garlic.com/~lynn/2007m.html#66 Off Topic But Concept should be Known 
To All

part of the new, old things are called "virtual appliances" ... but in
the good old 60s & 70s ... they were called "service virtual machines"

some recent posts mentioning the virtual appliance genre
http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC
http://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC
http://www.garlic.com/~lynn/2006x.html#6 Multics on Vmware ?
http://www.garlic.com/~lynn/2006x.html#8 vmshare
http://www.garlic.com/~lynn/2007i.html#36 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
http://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran 
developer, dies

cp67 had fairly early implemented fast, automated dump&reboot. That
along with the change-over to using 2702 "prepare" command helped
contribute to round-the-clock, 24x7 cp67/cms online, timesharing
services. The issue was that 360/67 were leased ... and charge for was
based on system meter running ... and having the system up 3rd/4th shift
might have the meter running ... but light load charges might not be
able to cover the off-shift lease rate. The system "meter" would run,
even when the operating system was in wait state, but there was I/O
"active". The use of the 2702 "prepare" command for terminal I/O would
effectively suspend "I/O" and the system "meter" would stop. The other
part as the fast, automated dump&reboot helped make practical to run
cp67 3rd&4th shifts w/o any human (operator) present (aka "dark room")
... eliminating another expense that light-load offshift useage might
not cover. The combination helped encourage both internal 7x24,
around-the-clock online, timesharing cp67 operation ... as well
as help make various commercial cp67 timesharing offerings more
viable
http://www.garlic.com/~lynn/subtopic.html#timeshare

however, one of the short-comings with unattended, offshift operation
was that the "service virtual machines" still required human
intervention.

as part of lots of work on performance tuning, dynamic adaptive
dispatch/scheduling, virtual memory optimization, workload profiling
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

and other stuff I was doing at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

I was having to do a lot of benchmarking
http://www.garlic.com/~lynn/subtopic.html#benchmark

and as part of the benchmarking, I worked on being able to automate the
whole process. One of the issues was being able to generate a
new/different kernel and automatically reboot ... and start the next
sequence of benchmarks. cp67 had morphed into vm370 and inherited the
automatic reboot operation. The issue then was how to get all the
benchmarks kicked off. I created a "autolog" command that emulated the
manual login process ... and added one such command late in the system
bringup/boot process. The resulting process that was automatically
logged on then could execute scripts with autolog commands for large
number of other processes. I initially used it for implementing the
benchmarking process. For instance, in the final sequence before release
of the "resource manager" ... there was a sequence of something like
2000 (automated) benchmarks that took 3months elapsed time to run.

However, it was quickly realized that the autolog process (for
benchmarking) ... would also extremely useful for automating the startup
of "service virtual machines" ... as part of automated system reboot.

The burlington development group was one of the organizations that had
been distracted by the future system project
http://www.garlic.com/~lynn/subtopic.html#futuresys

after FS was killed (and before burlington was put on notice that they
were being shutdown and everybody being transferred to POK to support
mvs/xa development) ... they had crash program to turn out items in
vm370 release 3 ... and picked up a lot of stuff from the science center
(including the autolog command) where we had continued to work on
(360/370) virtual machine activity.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Off Topic But Concept should be Known To All

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.

[EMAIL PROTECTED] (Ken Brick) writes:
> http://www.theregister.com/2007/06/20/usenix_07_opening_keynote/

the new, 40yr old theme, curtesy of the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

related post here
http://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted

a lot of technology evolved in that environment ... 

GML, precursor to SGML, HTML, XML, aka the markup stuff
http://www.garlic.com/~lynn/subtopic.html#sgml

the internal network ... which was larger than the arpanet/internet
from just about the beginning until possibly sometime mid-85
http://www.garlic.com/~lynn/subnetwork.html#internalnet

and as mentioned in this recent thread:
http://www.garlic.com/~lynn/2007m.html#47 Capacity and Relational Database
http://www.garlic.com/~lynn/2007m.html#55 Capacity and Relational Database
http://www.garlic.com/~lynn/2007m.html#56 Capacity and Relational Database

relational/sql was first created in that environment
http://www.garlic.com/~lynn/subtopic.html#systemr

a lot of virtual memory and dispatch/scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

among other things, it provides a fantastic incubator for R&D and new
technology ... which has been somewhat alluded to in parts of a recent
thread:
http://www.garlic.com/~lynn/2007m.html#15 Patents, Copyrights, Profits, Flex 
and Hercules
http://www.garlic.com/~lynn/2007m.html#20 Patents, Copyrights, Profits, Flex 
and Hercules
http://www.garlic.com/~lynn/2007m.html#32 Patents, Copyrights, Profits, Flex 
and Hercules

in fact, after the corporation had canceled the failed Future System
project
http://www.garlic.com/~lynn/subtopic.html#futuresys

and realized that it had to throw resources back into the 370 product
line ... POK was able to convince the corporation that the vm370 product
had to be killed ... because they needed to transfer the all the
(relatively few) people in the burlington mall development group to POK
to provide support getting the mvs/xa development effort on schedule.
Eventually, Endicott was able to salvage some of the product mission.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Capacity and Relational Database

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

IBMsysProg wrote:
> From a software architecture standpoint, Multi Regions, Independent
> locking (IRLM), Automated Recovery (DBRC), and DASD Logging became the
> foundations of IBMs second relational data base system and its first
> SQL based system called at its introduction DB2.  IBMs first
> relational database system pre dated wide use of DASD and long
> historys could be written about it alone ...  "Bill of Material
> Program called at various times BOMP T-BOMP for TAPE BOMP and D-BOMP
> for DISK BOMP.  BOMP was probably used more for applications like
> payroll than manufacturing.

re:
http://www.garlic.com/~lynn/2007m.html#47 Capacity and Relational Database
http://www.garlic.com/~lynn/2007m.html#55 Capacity and Relational Database

lots of postings about sql/relational database system/r
done at sjr/bldg.28
http://www.garlic.com/~lynn/subtopic.html#systemr

including mentioning doing work on system/r and handling technology
transfer of system/r from sjr to endicott for sql/ds.

another source of a lot of old archeological references:
http://www.mcjones.org/System_R

now system/r was all done in vm370 virtual machines ... technology out
of the science center ... 4th flr, 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech

on the 5th flr, 545 tech sq was multics ... which had done an even
earlier relational implementation. recent posting (in
comp.databases.theory)
http://www.garlic.com/~lynn/2007e.html#1 Designing database tables for 
performance?
with multics MRDS reference:
http://www.multicians.org/mgm.html#MRDS
http://www.mcjones.org/System_R/mrds.html

now the seminal work on relational was done by Codd at SJR,

A relational Model of Data for Large Shared Data Banks, 
ACM, v13n6, june 1970
http://www.acm.org/classics/nov95/toc.html

wiki reference:
http://en.wikipedia.org/wiki/Edgar_F._Codd

minor pt in the above reference ... sjr was in bldg. 28 on the san jose
plant site, the almaden facility wasn't built until the mid-80s.

now one of the people in the meeting referenced here
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15

mentioned that he had handled a lot of technology transfer from sql/ds &
endicott back to STL for DB2 (even tho bldg. 28 and bldg. 90 are only
about ten miles apart ... i would even periodically do the commute on my
bike).

for lots of topic drift ... two of the other people in that same meeting
... were later at a small client/server startup responsible for
something called the commerce server and we were called in to consult on
being able to do payment transactions on their server
... misc. collected postings mentioning putting together payment
transaction infrastructure for what is now frequently referred to as
electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is Parallel Programming Just Too Hard?

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

Peter Flass <[EMAIL PROTECTED]> writes:
> Well, unix is unix (or Linux).  The problems come from the basic
> design; if you changed the design, it wouldn't be unix.  The best you
> can do is mitigate the problems.  This is the case with every OS -
> some fundamental decisions made during the initial design can't be
> changed without modifying the OS out of existence.
>
> This is just like programming languages.  You can add "improvements",
> but some initial design decisions are set in stone.

virtual machines has periodically been used over the past 40yrs to
address various limitations in operating systems ... rather than trying
to stress a particular operating system past its design point
... attempting to consolidate more and more applications on a single
operating system platform ... go to a two (multi) level paradigm ...
where you have a virtual machine environment, timesharing multiple
virtual machines concurrently on common platform ... and then within
each virtual machine ... allow is doing its own thing (i.e. a little
peter principle ... not pushing an operating system to rise past its
level of competence).

this is somewhat optimization at a more macro level ... while making
some micro-level optimization sacrifices (i.e. the overhead of the
virtual machine capability).

re:
http://www.garlic.com/~lynn/2007m.html#51 Is Parallel Progrmaming Just Too Hard?
http://www.garlic.com/~lynn/2007m.html#52 Is Parallel Progrmaming Just Too Hard?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Capacity and Relational Database

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


re:
http://www.garlic.com/~lynn/2007m.html##47 Capacity and Relational Database

for some additional past history 

the university i was at was selected to be beta-test for original CICS
... it was an ONR, online library funded project. It also got a 2321,
datacell as part of the project. One of my responsibilities got to be
shooting bugs in this early CICS (before first official product
ship). One specific bug I remember was that the customer installation
that CICS had grown out of had been using a specific set of BDAM
options. For whatever reason, the university library chose to use some
other combination of BDAM options ... resulting in CICS
failures. ... misc. past posts mentioning cics &/or bdam (and having to
shoot CICS and BDAM bugs)
http://www.garlic.com/~lynn/subtopic.html#bdam

one of the IMS things in the mid-70s was transition to virtual memory
environment. The science center 
http://www.garlic.com/~lynn/subtopic.html#545tech

had done much of the early stuff on virtual memory as part of both
CP67 and VM370. Some of the work involved extensive performance
monitoring, performance modeling, workload profiling and the early
stuff leading to capacity planning.
http://www.garlic.com/~lynn/subtopic.html#benchmark

One of these efforts was instruction tracing and modeling virtual
memory useage.  This was used extensively in many applications moving
from real storage environment to virtual memory operation. One of the
earliest was in was significant benefit as part of rewritting the
whole APL storage management when the science center did the port of
apl\360 to cms\apl (and expanding APL workspaces from typical 16k-32k
real memory to allow maximum virtual memory sizes) ... various past
posts mentioning APL and/or one of its heaviest users ... the HONE
system
http://www.garlic.com/~lynn/subtopic.html#hone

In the mid-70s, one of the major internal users of this tracing and
modeling application (from the science center) was the IMS group
... tracing and monitoring both general IMS performance operation
... as well as optimization for virtual memory operation. The science
center also added semi-automated program re-organization to the
application and the science center announced it as "VS/REPACK" product
in 1976.

And here is old email reference about getting pushed as general
consultant to the IMS development group in STL (mentions luncheon with
the IMS deevelopment people)
http://www.garlic.com/~lynn/2007.html#email801016

this independent of the previous mention about working on some of
system/r ... the original relational/sql implementation
http://www.garlic.com/~lynn/subtopic.html#systemr

for other drift ... lots of past posts about doing lots of stuff
for virtual memory optimization and replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock

Now, when my wife was con'ed into going to POK to be in charge of
loosely-coupled architecture ... she originated "peer-coupled shared
data" architecture (and a lot of the mainframe distributed/global
locking stuff)
http://www.garlic.com/~lynn/subtopic.html#shareddata

which saw very little uptake until sysplex ... except for IMS
and especially IMS hot-standby effort

for somewhat other topic drift ... lots of past posts about being
allowed to play disk engineer in bldg. 14&15
http://www.garlic.com/~lynn/subtopic.html#disk

at one time there was joke about working 4hr shift week, 1st shift in
bldg28/sjr, 2nd shift in bldgs. 14&15, 3rd shift in bldg90/stl, and 4th
shift (aka weekends) at HONE.

later when we were doing our HA/CMP product
http://www.garlic.com/~lynn/subtopic.html#hacmp

and scaleup for distributed databased operation ... along with scaleup
for distributed lock manager (as well as massive distributed
recovery) ... some email references here
http://www.garlic.com/~lynn/lhwemail.html#medusa

and minor reference in these posts 
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15

the people in STL complained that if we were allowed to ship the
support for the commercial DBMS stuff ... we would be at least five
yrs ahead of where they were.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is Parallel Programming Just Too Hard?

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> with the advent of PCs ... a lot of the cms personal computing migrated
> to PCs ...  although the (mainframe) virtual machine operating system
> continues to survive ... and even had seen some resurgent in the early
> part of this decade supporting large numbers of virtual machines running
> linux ... somewhat in the "server consolidation" market segment
>
> recently, "server consolidation" has become something of a more widely
> recognized buzzword ... pushing a combination of virtual machine
> capability migrated to PC hardware platforms possibly in combination
> with large BLADE form-factors farms ... where a business with hundreds,
> thousands, or even tens of thousands of servers are consolidating into
> much smaller space.

re:
http://www.garlic.com/~lynn/2007m.html#51 Is Parallel Programming Just Too Hard?

note that in the 80s, there started to be the possibility of two-level
"timesharing" dispatch/scheduling when some amount of the virtual
machine capability migrated into the mainframe "hardware", ... commingly
referred to now as LPARS (logical partitions). The hardware had to
schedule/dispatch timeshare the virtual machine LPARS ...  and within an
LPAR could be a virtual machine operating system, also having to
schedule/dispatch timeshare its virtual machines.

something similar has to be going on the emerging PC-based genre of
virtual machine implementations.

one of the interesting dispatch/schedule evolution starts with single
processor virtual machines running on single processor hardware ... then
moving to single processor virtual machines running on multiple
processor hardware ...  things can get more complex when having to run
multiple processor virtual machines running on multiple processsor
hardware ... and it may not be possible to independently
dispatch/schedule the different virtual processors of a virtual machine
... having possibly needing to dispatch/schedule multiple virtual
processors (of a virtual machine) concurrently on multiple real
processors.

lots of past posts about multiprocessors, tightly-coupled, and/or
compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is Parallel Programming Just Too Hard?

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] writes:
> When?  I never considered IBM world and its batch environment 
> timesharing.  Timesharing does not do large data processing tasks
> well; and it's not supposed to.

there were somewhat distinct, different environments ... one was
commercial dataprocessing and the other was interactive computing and
timesharing.

the commercial, batch, production environment was oriented towards
business dataprocessing ... it wasn't computing done on behalf of some
specific person ... it was computing done on behalf of some business
operation ... like the organizations payroll and printing checks. the
requirement was that the business dataprocessing be done ... frequently
on very determined scheduled ... independent of any specific
person. over time, there was lots of batch technology evolved to
guarentee that specific operations could be done reliably, predictably,
and deterministicly independent of any human involvement.

much of the interactive and virtual machine paradigm evolved totally
independently at the science center ... first with cp40/cms, morphing
into cp67/cms, followed by vm370/cms (even tho during the 70s, the batch
infrastructure and the timesharing infastructure shared a common 370
hardware platform):
http://www.garlic.com/~lynn/subtopic.html#545tech

both multics (on the 5th flr) and science center (on the 4th flr) could
trace common heritage back to ctss (and unix traces some heritage back
to multics).

even tho there was a relatively large timesharing install base (in most
cases larger than any other vendor's timesharing install base that might
be more commonly associated with timesharing) ... in the period, it was
dwarfed by the commerical batch install base. I've joked before that at
one period, the installed commercial customer install base was much
larger than the timesharing customer install base, and the timesharing
customer install base was much larger than the timesharing internal
install base, and the timesharing internal install base was much larger
than the internal installations that I directly supported (built,
distributed, fixed bugs, on highly customized/modified kernel and
services). However, at one point the number of internal installations
that I directly supported was as large as the total number of Multics
installations that ever existed. lots of past posts mentioning the
timesharing environment
http://www.garlic.com/~lynn/subtopic.html#timeshare

much of that timesharing install base was cms personal computing ...
while other was mixed-mode operation with cms personal computing and
other kinds of operating systems in virtual machines ... aka the same
timesharing infrastructure supporting both interactive cms personal
computing as well as production (frequently batch) guest operating
systems. this required a timesharing dispatching/scheduling policy
infrastructure that could support a broad range of requirements.
for a little topic drift, slightly related recent post:
http://www.garlic.com/~lynn/2007m.html#46 Rate Monotonic scheduling (RMS) vs. 
OS Scheduling

also coming out of the science center in the period (besides virtual
machines, a lot of timesharing and interactive/personal computer)
... somewhat reflecting the timesharing and personal computing
orientation was much of the internal networking technology
http://www.garlic.com/~lynn/subnetwork.html#internalnet

as well as things like the invention of GML, precusor to SGML, HTML,
XML, etc
http://www.garlic.com/~lynn/subtopic.html#sgml

with the advent of PCs ... a lot of the cms personal computing migrated
to PCs ...  although the (mainframe) virtual machine operating system
continues to survive ... and even had seen some resurgent in the early
part of this decade supporting large numbers of virtual machines running
linux ... somewhat in the "server consolidation" market segment

recently, "server consolidation" has become something of a more widely
recognized buzzword ... pushing a combination of virtual machine
capability migrated to PC hardware platforms possibly in combination
with large BLADE form-factors farms ... where a business with hundreds,
thousands, or even tens of thousands of servers are consolidating into
much smaller space.

Microsoft Looks to Stop Internal Server Sprawl
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=296360

from above:

The profile of Microsoft Corp.’s in-house server farm is similar to
those of many other companies: one application per server, with less
than 20% peak server utilization on average. But Devin Murray,
Microsoft’s group manager of utility services, is working to change
that. Murray’s team manages about 17,000 servers that support 40,000 of
Microsoft’s end users worldwide.

... snip ...

--
For IBM-MAIN subscribe / sign

Re: Capacity and Relational Database

2007-06-18 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (IBMsysProg) writes:
> Memory.
> Over the years the first exploiters of architecture changes to allow more
> address spaces, more real memory, and more virtual memory have always been
> DBMS systems.  At this time I would suggest allocating at least 2 gig of
> additional real memory to your future DBMS.  DBMS system address spaces in
> general are intolerant of paging.  This is because a page in results in a
> wait for the entire address space and to make things worse DBMS address
> spaces serve many concurrent users.

i've related before the discussion between IMS group and (original
SQL/System/r group about pros & cons.
http://www.garlic.com/~lynn/subtopic.html#systemr

IMS has/had direct pointers ... which significantly cut down processing
overhead ... but significantly increased development, maintenance, and
administrative costs. System/r abstracted away the direct pointers
... at the cost of implicit overhead of automatically maintained index.
The "argument" back then was that the (RDBMS) automatically maintained
index, doubled the physical disk space and significantly increased the
number of disk i/os (as part of processing the index) ... offset by
significantly reduced human resources & skills.

going into the 80s ... disk price/bit came down significantly (muting
the disk price/bit argument) and (relative) significant increases in
system "real" memory allowed much of the indexes to be cashed
(eliminated lots of the increased index disk i/os). The index overhead
then somewhat shifted from the amount of disk i/os ... to just CPU
overhead. In any case, the price and availability of system resources
changes that went on in the 80s ... changed the trade-off between the
human skill/resources and system price-resources ... significantly
enabling the wider use of RDBMS.

Virtual memory and high-end DBMS don't mesh very well. High-end DBMS
tends to have lots of their own managed cache ... typically with some
sort of LRU type algorithm.

I first noticed that running an LRU storage managed algorithm under an
LRU storage managed algorithm could be a bad idea ... in the mid-70s
with SVS/MVS running in virtual machine (virtual memory). It was
possible to get in extremely pathelogical situation where MVS would
select one of the pages (at a location it believed to be "its"
real-memory) to be replaced ... at about the same time that the virtual
machine hypervisor also decided that the corresponding virtual page
should be replaced (since they were both looking at effectively the same
useage patterns as basis for replacement decision). As a result, a
LRU-based strategy ... running in a virtual memory, can start to look
like an MRU strategy (the next most likely page to be used ... is the
one that has been least recently used).

lots of past posts about page replacement algorithms ... including
some difference of opinion of some of the "internally" implemented
MVS strategies
http://www.garlic.com/~lynn/subtopic.html#wsclock

as well as some "old" email on various aspects of the subject
http://www.garlic.com/~lynn/lhwemail.html#globallru

In any case, when running high-end DBMS that have their own cache
implementation ... in a virtual memory operating system environment
... there tends to be a lot of "tuning" options ... to minimize the
conflict between the DBMS cache replacement strategy (typically some
sort of LRU-based) and the operating sysetm virtual memory replacement
strategy (typically also some sort of LRU-based). 

There is also the possibility of things analogous to the old
"VS1-handshaking", where VM370 would present a psuedo page fault
interrupt to VS1 (running in a virtual machine) ... enabling VS1 to do a
task switch (instead of blocking the whole VS1 whenever any page fault
occured for a virtual machine page).

note that one of the progression of large real storage has resulted in
DBMS "memory" implementations ... rather than assuming that the DBMS
natively resides on disk and there is a lot of processor overhead
related to the assumed DBMS operation. The assumption is that nearly
everything is memory resident and managed with memory pointers ... with
periodic snap-shots to disk for commits/integrity. Given the same amount
of large real storage ... there are claims that the switch to a RDBMS
memory-based paradigm can run ten times faster than a RDBMS disk-based
paradigm that was fully cached and otherwise doing little disk i/o (and
both running nearly identical SQL-based applications).

misc. recent posts mentioning old "interactions" between IMS
and System/r organizations regarding various pros and cons
http://www.garlic.com/~lynn/2007e.html#1 Designing database tables for 
performance?
http://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#31 Quote from comp.object
http://www.garlic.com/~lynn/2007e.h

Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM

2007-06-18 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

Frank McCoy <[EMAIL PROTECTED]> writes:
> Yup ... As *would* have happened with the PC itself if they'd been
> that tight-assed with it.  They just didn't *get* the fact that the
> open bus and configuration was what made the PC popular.  IOW, it was
> the *competition* that made it such a huge success.

re:
http://www.garlic.com/~lynn/2007m.html#42 The Development of the Vital IBM PC 
in Spite of  the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007m.html#44 The Development of the Vital IBM PC 
in Spite of  the Corporate Culture of IBM

as i've mentioned before ... the other market force was that the
previous personal computers had been do-it-yourself and hobbiest market.
individuals had to justify the cost of the box for their own personal
interest ... that included a lot of the software ... not a lot of
off-the-shelf stuff ... so individuals had to do that themselves also.

big break-out for ibm/pc was selling it into terminal emulation market
at businesses. business that had justified buying a couple thousand or
tens of thousand (3270) terminals ... for about the same amount of money
that provided both local computing and terminal emulation in a single
desktop footprint. instead of selling one at a time to a very limited
market ... orders were being taken for thousands at a time. these
(business) install base motivated a lot of the business users and
software entrepreneurs to write software applications for the install
base. having growing library of useful software tools for the market
segment ... made it easier to justify spending the money to buy the
machine. the combination of growing install base and growing available
application creates snowball effect (positive feedback). misc. past
posts mentioning various aspects of the terminal emulation theme
http://www.garlic.com/~lynn/subnetwork.html#emulation

the business market potential significantly motivated the clone makers
... something that had been happening in the mainframe dataprocessing
business market since at least the late 60s (and so wasn't that unique
of a concept).  misc. past posts mentioning (mainframe) plug compatible
(clone)
http://www.garlic.com/~lynn/subtopic.html#360pcm

this was enormous synergistic effect ... that wouldn't happen in the
purely home/hobbiest market ... since the purchase price for strictly
individuals was still fairly significant with not a large number of
"solutions" to attact a big following. possibly one of the biggest
drivers of personal computers into the home/personal market was the
internet ... the volumes from the business world were driving down the
price point and the combination of the price-point and internet as a
"personal" use (for the computers) ... then helped explode the sales
into the home market (aka killer app/silver bullet for personal,
personal computer use).

recent references:
http://www.garlic.com/~lynn/2007j.html#11 Newbie question on table design
http://www.garlic.com/~lynn/2007j.html#71 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007k.html#68 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007l.html#37 Friday musings on the future of 3270 
applications

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM

2007-06-17 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] writes:
> The public history of the PC began in August 1981, when IBM first
> announced 'The IBM Personal Computer.' . This was The original
> PC. The time period for the development of this landmark, legacy
> product was approximately a year. It must be remembered that IBM was a
> centralized committee paper top down organization at the
> time. Everything went by snail mail and paper, communication was slow
> and lines of communication as well as the necessary and ...
>
> Read full article at 
> http://www.knowledgefield.com/articles/the-development-of-the-vital-ibm-pc-in-spite-of-the-corporate-culture-of-ibm.shtml

trolling?

how 'bout the internal network ... world-wide
http://www.garlic.com/~lynn/subnetwork.html#internalnet

larger than the arpanet/internet from just about the beginning 
until possibly mid-85
http://www.garlic.com/~lynn/subnetwork.html#internet

the great switch-over from arpanet (host-to-host with homogeneous IMP
front-ends) to internetworking protocol was on 1jan83. internet was
somewhere between 100-250 nodes at the time (depending on how things
were counted). the internal network was far past that ... passing 1000
nodes that summer
http://www.garlic.com/~lynn/internet.htm#22
http://www.garlic.com/~lynn/99.html#112
http://www.garlic.com/~lynn/2006k.html#8 

various old email on a variety of subjects from the 70s & 80s
http://www.garlic.com/~lynn/lhwemail.html

after the 23jun69 unbundling announced, there was an effort to deploy
(360/67) cp67 machines in various datacenters to give branch office
technical people an opportunity to practice with operating systems
running in (the remote) cp67 virtual machines (logon from terminals in
the branch office to cp67 machines at remote datacenters). this was
called "HONE" (aka hands-on network experience). however, it was soon
taken over by applications (mostly written in APL) supporting the branch
office sales/marketing people (and the use by SEs for operating system
experience eventually was dropped). when EMEA hdqtrs moved from the US
to Paris in the early 70s ... I was called in to help with their HONE
installation. At that time, it still took a little ingenuity to read
email back in the states.
http://www.garlic.com/~lynn/subtopic.html#hone

note that the "5150 computer" announced aug81 was predated by the "5100
computer" from the palo alto science center ... 5100 demo'ed 1973
http://www-03.ibm.com/ibm/history/exhibits/pc/pc_1.html
http://www-03.ibm.com/ibm/history/exhibits/pc/pc_2.html

also, note that the boca group doing the development was designated IBU
... independent business unit ... where some amount of corporate culture
command&control was much more relaxed ... for instance the standard A&R
(announce and review) product process requiring sign-off from possibly
nearly 500 executives from around the corporation.

The birth of the IBM PC
http://www-03.ibm.com/ibm/history/exhibits/pc25/pc25_birth.html

misc. old posts:
http://www.garlic.com/~lynn/2000.html#69 APL on PalmOS ???
http://www.garlic.com/~lynn/2000.html#70 APL on PalmOS ???
http://www.garlic.com/~lynn/2000d.html#15 APL version in IBM 5100 (Was: 
Resurrecting the IBM 1130)
http://www.garlic.com/~lynn/2002b.html#39 IBM 5100 [Was: First DESKTOP Unix 
Box?]
http://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix 
Box?]
http://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP Unix 
Box?]
http://www.garlic.com/~lynn/2002b.html#47 IBM 5100 [Was: First DESKTOP Unix 
Box?]
http://www.garlic.com/~lynn/2003i.html#79 IBM 5100
http://www.garlic.com/~lynn/2003i.html#82 IBM 5100
http://www.garlic.com/~lynn/2003i.html#84 IBM 5100
http://www.garlic.com/~lynn/2003j.html#0 IBM 5100
http://www.garlic.com/~lynn/2003n.html#6 The IBM 5100 and John Titor
http://www.garlic.com/~lynn/2003n.html#8 The IBM 5100 and John Titor
http://www.garlic.com/~lynn/2005m.html#2 IBM 5100 luggable computer with APL
http://www.garlic.com/~lynn/2005m.html#3 IBM 5100 luggable computer with APL

parts of thread from last yr that might have some interest:
http://www.garlic.com/~lynn/2006o.html#43 "25th Anniversary of the Personal 
Computer"
http://www.garlic.com/~lynn/2006o.html#45 "25th Anniversary of the Personal 
Computer"
http://www.garlic.com/~lynn/2006o.html#46 "25th Anniversary of the Personal 
Computer"
http://www.garlic.com/~lynn/2006o.html#65 "25th Anniversary of the Personal 
Computer"
http://www.garlic.com/~lynn/2006o.html#66 "25th Anniversary of the Personal 
Computer"
http://www.garlic.com/~lynn/2006p.html#15 "25th Anniversary of the Personal 
Computer"
http://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the Personal 
Computer"
http://www.garlic.com/~lynn/2006p.html#34 "25th Anniversary of the Personal 
Computer"
http://www.garlic.com/~lynn/2006p.html#36 "25th Anniversary of the Personal 
Computer"
http://www.

Re: Patents, Copyrights, Profits, Flex and Hercules

2007-06-14 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Bruce Black) writes:
> ASM2 was eventually acquired by CA and become CA-DISK, then
> Brightstore CA-DISK, and now CA Disk Backup and Restore.  I think
> there was an intermediate acquisition that I have forgotten about.

for other folklore ... a couple people that worked on AIX system
management left and formed a company called tivoli. eventually tivoli
was bought up ... and when adstar was sold off ... some of the adstar
software packages (as well as other software products) were moved over
to tivoli ... for instance ADSM (adstar storage management) became TSM
(tivoli storage management).

i had done the original backup/archive implementation in the late 70s
which was deployed at some number of internal datacenters ... and went
thru a number of versions with various other people helping with the
work.

one of the people involved left ... and worked on a number of
backup/archive implementations for other companies ... some of these
other implementations may currently be sold by sterling(?).

my original backup/archive internal implementation first saw product
release as workstation datasave facility which then morphed into ADSM
(before being renamed TSM). some old email on the subject
http://www.garlic.com/~lynn/lhwemail.html#cmsback
and numerous posts mentioning backup/archive
http://www.garlic.com/~lynn/subtopic.html#backup

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Patents, Copyrights, Profits, Flex and Hercules

2007-06-12 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (R.S.) writes:
> Key-based solutions exist on mianframe as well as on other systems.
>
> I think it is rather technical, not ethical or organisational issue:
> It is *easy* to have illegal software on PC, sometimes you are even
> unaware of it. I mean a lot of small but usefull tools like Windows
> Commander, archivizers, DVD-burning software etc. etc.
>
> Even if you have some "tools" for z/OS it is simply not so easy to
> install it on the host - usually several persons are involed, usually
> someone could ask - "Did we buy it ? How did you get it ?".
>
> From the other hand, people are interested in having some bells &
> whistles on *their* PC (even company owned), while mainframe is not
> *their*. It is not *personal*. It's "common".

re:
http://www.garlic.com/~lynn/2007m.html#15 Patents, Copyrights, Profits, Flex 
and Hercules

slightly related recent posts about looking at software piracy (DRM) in
the mainframe and PC market space
http://www.garlic.com/~lynn/2007b.html#59 Peter Gutmann Rips Windows Vista 
Content Protection
http://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. 
Traditional Encryption Tools

old email about "new" apple lisa announcement and conjecture about the
processor serial number being used for software licensing (and
piracy countermeasure).
http://www.garlic.com/~lynn/2007b.html#email830213
http://www.garlic.com/~lynn/2007b.html#email830213b
in this recent post
http://www.garlic.com/~lynn/2007b.html#56 old lisa info

part of the mainframe was being able to show in court that something out
of the ordinary had to have been done to subvert the licensing
provisions (value was worth taking to court). in the PC case, the value
of individual copy makes it difficult to justify investigation and
bringing to court every individual case.

TPM is the one of the latest in pirarcy countermeasure (as well as
suppose to be countermeasure to software compromises). misc. past
posts mentioning giving an assurance talk in trusted computing
track at intel developers conference
http://www.garlic.com/~lynn/aadsm5.htm#asrn1 Assurance, e-commerce, and some 
x9.59
http://www.garlic.com/~lynn/aadsm21.htm#3 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil 
or good idea?
http://www.garlic.com/~lynn/2005g.html#36 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
http://www.garlic.com/~lynn/2006p.html#48 Device Authentication - The answer to 
attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2006w.html#37 What does a patent do that copyright 
does not?
http://www.garlic.com/~lynn/2007g.html#61 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#63 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007l.html#42 My Dream PC -- Chip-Based

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Patents, Copyrights, Profits, Flex and Hercules

2007-06-11 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Clem Clarke) writes:
> It's a shame, but unless IBM does do a big rethink on this, and allows
> small developers some sort of inexpensive or free access to the
> mainframes, they will die.   Allowing a "hobbyist" license for Z/OS,
> VM and VSE on Hercules would be one way, and what does IBM really have
> to lose?  And the gain would be that they could have many people
> working at no cost on these systems developing tools and applications
> to make them better and better.

some related thread drift from another n.g.
http://www.garlic.com/~lynn/2007m.html#3 nouns and adjectives

that in the 60s and much of the 70s ... lots of the innovation came out
of customer installations & datacenters ... since it was the customers
that understood the need and requirement ... things like cics, ims, etc.
later they were transferred to "development" organizations for product
support. in many cases, this is misnomer ... since those "development"
organizations are responsible for product maintenance ... not the
products "development" (maybe doing plus/minus five percent changes per
annum). I've periodically made facetious comments referencing the "term"
inflation in using the word "development" applied to organizations that
are primarily product "maintenance".

something similar happened with the introduction of the ibm/pc ... large
proportion of the "products" originated from end-users (that were faced
with the actual problems and understood what kind of solution was
needed). vendor product operations tend to have people like software
engineers that understand issues about software maintenance ... but
rarely have people with the necessary experience that they could see
what solution was originally needed.

even before ibm/pc came out ... there were some that had jump shipped
from vm/cms (that had been providing mainframe-based personal computing
environment) and were implementing some number of CMS applications on
other early personal computers. These weren't ports of CMS applications
(because the implementation details tended to be totally different), but
frequently the look&feel and the solution they provided were the same.

the "OCO-wars" were especially hard on the vm/cms community ... because
not only was full source available ... but even maintenance, fixes, etc
for customers were shipped as source updates ... based on CMS
multi-level source maintenance facilities. Some studies from their
period even claimed the number of system (source) updates done at
customer datacenters (aka aggregate lines-of-code) was actually larger
than the source lines-of-code in the base system.

the high-end of the market is where the (quarterly) revenue/profit
... but all the innovation tends to originate at the low-end & mid-range
... in part innovation requires quite a bit of experimentation,
trial&error, etc ... and the high-end is rarely made available for such
experimentation.

As a result, some of the other vendors found a need that could filled in
the entry/low-end market segment (and long term ... it is frequently the
entry/low-end that tends to feed the high-end with the applications that
keep the high-end quarterly revenue sustained).

the pre-occupation with quarterly results has been a sporadic topic for
at least the last 40 yrs. during periods when there was significant
general economic growth ... the generational issues appeared to almost
take care of themselves ... allowing the perception that executives
could solely concentrate on the quarterly issues. however, this approach
somewhat came to roost. i've mentioned before about being at a talk at
MIT in the early 70s where Amdahl was asked how he was able to convince
the money people to support his new clone computer company. His reply
was that there was already something like $200b that customers had
invested in 360 applications ... that even if IBM were to totally walk
away from 360/370 ... which might be considered a vieled reference to
the future system project
http:///www.garlic.com/~lynn/subtopic.html#futuresys

... (just) that (existing) software application base could keep him in
business thru the end of the century.

starting in the early 70s, i had been heavily involved with HONE
deployment ... first its original objective to provied "hands-on"
experience to branch office SEs with operating systems running in
virtual machines ... and then the transition to being primarily an
online, interactive environment deploying applications (mostly
implemented in cms\apl) supporting sales & marketing worldwide.
http://www.garlic.com/~lynn/subtopic.html#hone

in the mid-70s, I got con'ed into helping with the virgil/tully
microcode assists ... including spending time off & on over a period of
a year running around the world with the product managers, meeting with
business planning & forcasting groups positioning the processors

Re: mainframe = superserver

2007-06-07 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.


[EMAIL PROTECTED] writes:
> I realize that this has probably been asked before, but google didn't
> give me an answer.  Before I asked my question let me state that I
> know that windows server 2003 and longhorn won't run on an IBM
> mainframe.  There is the endian issue and the ascii vs ebcidic
> issues.  Is there a medium to large IBM box that can run a couple
> hundred of virtual windows 2003 servers?  And said box can scale up to
> approximately 1000+ virtual windows servers?  Given that all current
> servers are dell and hp servers with 2 intel core 2 duo processors and
> a total of 150TB of storage?
>
> I am doing research for the possible replacement of 200+ windows
> server in our datacenter.  We need to add servers, but there is
> literally no more power.  My thinking is if IBM can get windows
> servers to run on their something like their mainframes it would save
> electricity and space.  Everyone would win.

recent cross-over from another thread:
http://www.garlic.com/~lynn/2007l.html#63 Is Parallel Programming Just Too Hard?

mentioning that blades are also being sold into commercial market,
frequently in combination with virtualization, for server consolidation

and another mention here ... in slightly older thread/post:
http://www.garlic.com/~lynn/2007h.html#2 The Mainframe in 10 Years

and mention in this thread
http://www.garlic.com/~lynn/2007k.html#22 Another "migration" from the mainframe
http://www.garlic.com/~lynn/2007k.html#23 Another "migration" from the mainframe

some references from above thread

CIO Challenge: Energy Efficiency
http://www.wallstreetandtech.com/showArticle.jhtml?articleID=192202377
IBM Unveils New Energy-Efficient Blades
http://www.hpcwire.com/hpc/1379801.html
IBM to focus on energy efficiency
http://www.bladewatch.com/2007/05/10/ibm-to-focus-on-energy-efficiency/
Blade innovations highlight energy efficiency opportunities
http://www.it-director.com/business/content.php?cid=9135
IBM defends blades' energy efficiency
http://green.itweek.co.uk/2006/10/ibm_defends_bla.html
IBM Data Center and Facilities Strategy Services - high density
computing data center readiness assessment
http://www-935.ibm.com/services/us/index.wss/offering/its/a1025605
Lots of Blade Server articles
http://www.eweek.com/category2/0,1874,1658862,00.asp
IBM Grid Computing Solutions - financial industry
http://www-03.ibm.com/grid/solutions/by_industry/financial.shtml
Grid Computing for Financial Services 2007
http://www.iqpc.com/cgi-bin/templates/genevent.html?topic=233&event=12603&;
Grid computing: Accelerating the search for revenue and profit for financial 
markets
http://www-03.ibm.com/industries/financialservices/doc/content/landing/973028103.html

the previously mentioned scaleup activity was in large part about
physical packaging and issues like power and cooling
http://www.garlic.com/~lynn/lhwemail.html#medusa

but the server consolidation is now frequently blades/grid technology
in combination with virtualization  curtesy of science center
from mid-60s, first with cp40 and then when 360/67 became available,
morphed into cp67 (precursor to vm370) ... misc past posts mentioning
science center
http://www.garlic.com/~lynn/subtopic.html#545tech

besides virtualization and virtual machines being invented at the
science center ... compare&swap instruction for
multi-thread/multi-processor was also invented at the science center
http://www.garlic.com/~lynn/subtopic.html#smp

and also GML (later morphed into sgml, html, xml, etc)
http://www.garlic.com/~lynn/subtopic.html#sgml

and most of the internal network 
http://www.garlic.com/~lynn/subnetwork.html#internalnet

which was also seen outside in deployments like bitnet and
earn
http://www.garlic.com/~lynn/subnetwork.html#bitnet

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is Parallel Programming Just Too Hard?

2007-06-07 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Shane) writes:
> M - seems to be just a "warming over" of the multi-programming
> versus parallel discussion.
> With the exception of that last link, I'd need serious convincing any of
> them are "parallel programming".
>
> I suspect in the not too distant future, "multi-threaded" will supplant
> (in the common vernacular) all notions of "parallel".
>
> If not already ...

re:
http://www.garlic.com/~lynn/2007l.html#60 Is Parallel Programming Just Too Hard?

multi-threaded tends to be used in conjunction with tightly-coupled,
shared-memory multiprocessing (and the current buzzword
"multi-core"). lots of past posts mentioning shared-memory
multiprocessing and/or compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

compare&swap instruction had been invented by Charlie (CAS are Charlie's
initials) at the science center ... working on fine-grain multiprocessor
locking for cp67
http://www.garlic.com/~lynn/subtopic.html#545tech

in order to get the instruction justified for 370, had to come up with
the description of its use in multi-threaded/multi-programming
operation, which was included (originally) in the (370) principles of
operation ... a more recent version
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/A.6?DT=20040504121320

parallel has been used in reference to both (tightly-coupled)
multi-threaded operation, as well as loosely-coupled &/or cluster
multiprocessing operation

misc. past posts mentioning doing high availability, cluster
multiprocessing product
http://www.garlic.com/~lynn/subtopic.html#hacmp

some old email references about working on cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

a couple old posts specifically about working on applying distributed
lock manager and cluster scaleup to parallel oracle
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15

recent post mentioning my wife had been con'ed into going to
POK to be in charge of loosely-coupled architecture
http://www.garlic.com/~lynn/2007l.html#62 Friday musings on the future of 3270 
applications

a lot of the "blades" stuff has been physical packaging originally done
for (numerical intensive cluster) "GRIDs" (getting more & more computing
into smaller and smaller footprint). some amount of GRID/blades are now
being pitched into commercial sector. some of it isn't strictly
loosely-coupled/cluster operation ... but it is also being used
(frequently in combination with virtualization) for server
consolidation.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Friday musings on the future of 3270 applications

2007-06-06 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computer as well.

[EMAIL PROTECTED] (Patrick O'Keefe) writes:
> At times like this I sorely miss my long lost APPN "Formats and Protocols"
> bible.  I believe official sources claim that an APPN CP and an LU were 
> different kinds of NAUs because they were different chunks of code.
> (Or at least the same chunk of code implementing 2 different FSMs.)

re:
http://www.garlic.com/~lynn/2007l.html#37 Friday musings on the future of 3270 
applications

As undergraduate at the univ, I had done TTY/ascii terminal support for
cp67 ... and attempted to make the 2702 do something that it couldn't
quite do. that somewhat prompted a univ. project to build our own clone
controller (originally using an Interdata/3). This was subsequently a
writeup ... blaiming us (at least in part) for clone controller business
(interdata was subsequently bought by perkin-elmer and the box was sold
under PE logo well thru the 80s ... apparently with the same channel
interface card that was designed at the univ. in the 60s)
http://www.garlic.com/~lynn/subtopic.html#360pcm

the clone controller business was supposedly a major motivation behind
the future system project
http://www.garlic.com/~lynn/subtopic.html#futuresys

... recent FS reference/post (with some quotation by one of
the executives involved in FS)
http://www.garlic.com/~lynn/2007l.html#10 John W. Backus, 82, Fortran 
developer, dies

one might claim that when FS was killed, that SNA attempted to still
meet some of the FS objectives with the PU4/PU5 interface for advanced
terminal control infrastructure.

in the same time that SNA was starting, my wife co-authored peer-to-peer
networking (AWP39) ... that defined real networking ... rather than
complex terminal control. Possibly there was some amount of semantic
confusion lingered on because the term "SNA" contained the word
"network". Later, when my wife was con'ed into going to POK to be in
charge of loosely-coupled architecture, she created peer-coupled shared
data architecture (... and except for IMS hot-standby, didn't see a lot
of uptake until sysplex)
http://www.garlic.com/~lynn/subtopic.html#shareddata

she had lots of battles with the SNA organization over peer-coupled
shared data ... eventually there was temporary truce with my wife
being able to specify peer-couple operation as long as it was within
the walls of the same/single machine room (datacenter) ... but SNA
was mandated if it "crossed" the walls of the machine room.

much later, APPN was specified in AWP164 and when there was an attempt
to announce/release APPN, the SNA organization non-concurred (at the
time, the person responsible for APPN and I reported to the same
executive).  The APPN announcement was escalated and eventually the
announcement letter was carefully rewritten to not imply that APPN had
any relationship at all to SNA.

misc. past posts mentioning AWP39 and/or AWP164:
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?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED

Re: Is Parallel Programming Just Too Hard?

2007-06-06 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


a couple recent items:

The death of single threaded development
http://blogs.zdnet.com/Ou/?p=519
Google Acquires Multicore Programming Startup PeakStream --
Multithreaded Programming
http://www.informationweek.com/news/showArticle.jhtml?articleID=199901501
Intel updates compilers for multicore era
http://arstechnica.com/news.ars/post/20070605-intel-updates-compilers-for-multicore-era.html
Sun Updates Studio For Multi-core Development
http://itmanagement.earthweb.com/entdev/article.php/3681151
Sun stresses multicore chips, Linux with dev tool
http://news.yahoo.com/s/infoworld/20070604/tc_infoworld/89028
Scots firm demonstrates parallelizing compiler at MPF
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=199700792

recent posts on the subject:
http://www.garlic.com/~lynn/2007.html#3 The Future of CPUs: What's After 
Multi-Core?
http://www.garlic.com/~lynn/2007g.html#3 University rank of Computer 
Architecture
http://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case 
of VM being penetrated by hackers?
http://www.garlic.com/~lynn/2007i.html#78 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007l.html#19 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007l.html#24 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007l.html#26 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007l.html#34 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007l.html#38 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007l.html#42 My Dream PC -- Chip-Based

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is Parallel Programming Just Too Hard?

2007-06-01 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


re:
http://www.garlic.com/~lynn/2007l.html#24 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007l.html#26 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007l.html#34 Is Parallel Programming Just Too Hard?

recent news items

Intel Pledges 80 Core Processor in 5 Years
http://hardware.slashdot.org/hardware/06/09/26/1937237.shtml
Intel shows off 80-core processor
http://news.com.com/Intel+shows+off+80-core+processor/2100-1006_3-6158181.html
Next Windows To Get Multicore Redesign
http://developers.slashdot.org/article.pl?sid=07/05/31/1257231

part of the issue is that a lot of the parallel processing has been
limited to high-end market ... where highly skilled programming could be
used to manage large amount of shared resources ... effectively
concurrently working on different activity from independent sources.

as parallel hardware has started to move downstream into standard
consumer market ... issues in the past couple yrs is how to change the
(mostly) sequential programming paradigm to better utilize the
independent/parallel hardware resources that are available.

the hardware technology motivation is that as components are shrinking
... things like signal latency and syncronized, serial operation are
starting to represent a significant limiting factor ... going to
asyncronous operation ... even across the distances involved in a
typical chip ... can contributed to significant thruput increases.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Friday musings on the future of 3270 applications

2007-06-01 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Rich Smrcina) writes:
> If I understand what your asking there are products on the market that
> can do this today.
>
> As long as there is a 3270 on the back end (specifically TN3270), a web
> interface or a web service is presented on the front end.

part of this is some of the whole history about terminal emulation.
3270 terminal emulation contributed significantly to early uptake of
ibm/pc ... i.e. businesses that had already allocated money for 3270
terminal ... it became nearly no-brainer ... to switch to an ibm/pc
... price was about the same ... and in single desktop footprint the
business got both 3270 terminal and some possibly added-value local
computing.
http://www.garlic.com/~lynn/subnetwork.html#emulation

this contributed to significant install base of 3270 terminal
and terminal emulation products.

in the later part of the 80s ... were had come up with 3-tier
architecture (as an enhancement to client/server)
http://www.garlic.com/~lynn/subnetwork.html#3tier

and were out doing some amount of customer executive presentations
... and taking a lot of heat from the T/R and SAA forces(to some extent
SAA could be viewed as attempting to help preserve the terminal
emulation paradigm and inhibit the spread of client/server ... and
especially this new fangled 3-tier stuff).

we also were taking some amount of heat working with organizations
around the nsfnet backbone effort (i.e. tcp/ip is considered the
technology basis for the modern internet but nsfnet backbone would be
considered the operational basis for the modern internet). some old
email from the period on the topic
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

and after starting to cancel our meetings with outside entities
... then there was suggestion that they should start proposing
SNA/VTAM as the basis for nsfnet backbone ... specific old
email reference
http://www.garlic.com/~lynn/2006w.html#email870109
in this post
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

one of the side happenings in all this was we did get an
NSF audit of high-speed backbone we had running internally
http://www.garlic.com/~lynn/subnetwork.html#internalnet

which concluded that what we had running was at least five yrs ahead of
all NSFNET backbone bids (to build something new)

and for some topic drift ... tagential reference here
http://www.garlic.com/~lynn/2007l.html#14 Sueprconductors and computing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Questions to the list

2007-06-01 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.

[EMAIL PROTECTED] (Tom Schmidt) writes:
> It seems to me that only a few years ago (and probably in many of the
> hundreds of recycled "I remember when..." threads lately) we were, as
> a group, lamenting that we were all getting older and there was little
> new blood being introduced to the mainframe.  We were also having
> 'sour grapes' discussions about workload moving off the mainframe and
> companies abandoning the mainframe altogether.

one of the issues ... especially on the usenet side ... was that the
start of each new semester ... there would be a some new flurry of
homework questions ... as individuals taking a computer class and
getting possibly their first exposure to terminals and online
infrastructures.  as online infrastructures starting to permeate the
whole culture ... it is now possible to find homework questions
happening all thru the yr.

there is some balance between answering questions where the askee has
actually made some attempt to learn something ... or is using the list
in lieu of having to learn anything.

misc. past posts mentioning homework issue:
http://www.garlic.com/~lynn/2000.html#28 Homework: Negative side of MVS?
http://www.garlic.com/~lynn/2000.html#32 Homework: Negative side of MVS?
http://www.garlic.com/~lynn/2001.html#70 what is interrupt mask register?
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001c.html#11 Memory management - Page replacement
http://www.garlic.com/~lynn/2001c.html#25 Use of ICM
http://www.garlic.com/~lynn/2001k.html#75 Disappointed
http://www.garlic.com/~lynn/2001l.html#0 Disappointed
http://www.garlic.com/~lynn/2001m.html#0 7.2 Install "upgrade to ext3"  LOSES 
DATA
http://www.garlic.com/~lynn/2001m.html#32 Number of combinations in five digit 
lock? (or: Help, my brain hurts)
http://www.garlic.com/~lynn/2002c.html#2 Need article on Cache schemes
http://www.garlic.com/~lynn/2002f.html#32 Biometric Encryption: the solution 
for network intruders?
http://www.garlic.com/~lynn/2002f.html#40 e-commerce future
http://www.garlic.com/~lynn/2002g.html#83 Questions about computer security
http://www.garlic.com/~lynn/2002l.html#58 Spin Loop?
http://www.garlic.com/~lynn/2002l.html#59 Spin Loop?
http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID 
card?
http://www.garlic.com/~lynn/2002o.html#35 META: Newsgroup cliques?
http://www.garlic.com/~lynn/2003d.html#27 [urgent] which OSI layer is SSL 
located?
http://www.garlic.com/~lynn/2003j.html#34 Interrupt in an IBM mainframe
http://www.garlic.com/~lynn/2003m.html#41 Issues in Using Virtual Address for 
addressing the Cache
http://www.garlic.com/~lynn/2003m.html#46 OSI protocol header
http://www.garlic.com/~lynn/2003n.html#4 Dual Signature
http://www.garlic.com/~lynn/2004f.html#43 can a program be run withour main 
memory ?
http://www.garlic.com/~lynn/2004f.html#51 before execution does it require 
whole program 2 b loaded in
http://www.garlic.com/~lynn/2004f.html#61 Infiniband - practicalities for small 
clusters
http://www.garlic.com/~lynn/2004h.html#47 very basic quextions: public key 
encryption
http://www.garlic.com/~lynn/2004k.html#34 August 23, 1957
http://www.garlic.com/~lynn/2005h.html#1 Single System Image questions
http://www.garlic.com/~lynn/2005m.html#50 Cluster computing drawbacks
http://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?
http://www.garlic.com/~lynn/2006b.html#2 Mount a tape
http://www.garlic.com/~lynn/2006h.html#40 Mainframe vs. xSeries
http://www.garlic.com/~lynn/2006l.html#54 Memory Mapped I/O Vs I/O Mapped I/O
http://www.garlic.com/~lynn/2007f.html#16 more shared segment archeology

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is Parallel Programming Just Too Hard?

2007-05-30 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> long ago and far away, this was one of the battles getting the
> compare&swap instruction into 370 architecture. test&set had been around
> in the 60s and was used fro 360/65 multiprocessor support with global
> kernel spin-locks (set the lock and everybody else spins, untill the
> lock is cleared).
> ...
> somewhat implicit in a lot of compare&swap uses is that there can be
> concurrent threads executing in the same instruction sequences
> simultaneously. the inital forey into POK attempting to get compare&swap
> justified was unsuccesful, in large part because the favorite son
> operating system felt that test&set was just fine for multiprocessor
> support (the 360/65 smp global spin lock paradigm). the challenge was to
> create justification for compare&swap instruction that was applicable to
> single processor deployment. Thus was born the programming notes that
> can be found in principles of operation describing how the "atomic"
> characteristics of comapre&swap can be leveraged in single processor
> environment for multithreaded applications (like DBMS) ... these aren't
> necessarily concurrent multithreads ... but multiple threads that might
> be interrupted and so atomic operations can be applied to both
> simultaneous concurrent multithread operation as well as possibly
> non-simultaneous (but interrruptable) multithreaded operation.

re:
http://www.garlic.com/~lynn/2007l.html#24 Is Parallel Programming Just Too Hard?

misc. past posts mentioning smp and/or compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

in the mid-70s i was working on a 5-way SMP implementation it involved
one of the lower-end 370 processor designs ... and was moving lots of
features into microcode. for one reason or another that project got
killed, misc. past posts discussing the effort
http://www.garlic.com/~lynn/subtopic.html#bounce

shortly after that got killed, there was another project started for
16-way smp involving higher-end processors. we even co-opted the spare
time from some of the processor engineers furiously attempting to
complete the 3033. in general, most people that looked at it thought it
was a really great idea ... until it came to the attention of the head
of POK that it would possible be decades before the POK favorite son
operating system would be able to support the machine. At which time,
the 3033 engineers were instructed to get their noses back to the
grindstone and some people were invited to never show up in POK again.

misc. past references:
http://www.garlic.com/~lynn/95.html#5 Who started RISC? (was: 64 bit Linux?)
http://www.garlic.com/~lynn/95.html#6 801
http://www.garlic.com/~lynn/95.html#11 801 & power/pc
http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2001e.html#5 SIMTICS
http://www.garlic.com/~lynn/2001h.html#33 D
http://www.garlic.com/~lynn/2002i.html#82 HONE
http://www.garlic.com/~lynn/2003.html#4 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small 
clusters
http://www.garlic.com/~lynn/2004f.html#26 command line switches [Re: [REALLY 
OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004j.html#45 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004m.html#53 4GHz is the glass ceiling?
http://www.garlic.com/~lynn/2005k.html#45 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005m.html#48 Code density and performance?
http://www.garlic.com/~lynn/2005p.html#39 What ever happened to Tandem and 
NonStop OS ?
http://www.garlic.com/~lynn/2006c.html#40 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006l.html#30 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006n.html#37 History: How did Forth get its stacks?
http://www.garlic.com/~lynn/2006r.html#22 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006t.html#7 32 or even 64 registers for x86-64?
http://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?
http://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of SLT for 
ICs?
http://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is 
falling!!!the sky is falling!!)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is Parallel Programming Just Too Hard?

2007-05-30 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Howard Brazee) writes:
> Depending on one's definition of parallel programming, we have been
> doing to various degrees since before they started off-loading the
> paper-tape reading to the paper-tape reader.Video cards on PCs are
> powerful computers that work in parallel with the program's main
> logic. Our operating systems have allowed us to run payroll and
> accounts payable at the same time, and central databases have expanded
> on this ability.

lots of comments about this in the past couple yrs is that technology in
support of parallel programming has not really changed in at least the
past 20yrs ... as a result, the actual use has been limited to very
specialized implementations.

there has been lots of stuff in multiprogramming and multithreading in
the same processor complex (single processor and/or shared-memory
multiprocessor).

multiprogramming was managing lots of independent & different tasks
on the same processor complex.

multithreading was program managing different tasks. 

application implementation of multithreading isn't necessarily very
pervasive. some number of DBMS implementation have used things like
transaction model ... to provide "independent" operations ... that they
multithread. In this sense, DBMS kernels are somewhat more like
operating system kernels ... highly specialized ... and not a lot of
end-users implementing their own DBMS kernels.

in a lot of multiprocessor kernel support ... a "global" kernel lock was
used ... which only allowed a single thread to be executing in the
kernel at a time. it was somewhat painful experience for a lot of kernel
implementations to make the transition from single thread (at a time)
executing in a multiprocessor kernel to multiple concurrent threads
executing in same parts of the kernel.

long ago and far away, this was one of the battles getting the
compare&swap instruction into 370 architecture. test&set had been around
in the 60s and was used fro 360/65 multiprocessor support with global
kernel spin-locks (set the lock and everybody else spins, untill the
lock is cleared).

at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

Charlie had been doing a lot of work in fine-grain lock for the cp67
kernel and invented the compare&swap instruction (mnemonic chosen
because "CAS" are charlie's initials). misc. past posts mentioning
SMPs and/or compare&swap 
http://www.garlic.com/~lynn/subtopic.html#smp

somewhat implicit in a lot of compare&swap uses is that there can be
concurrent threads executing in the same instruction sequences
simultaneously. the inital forey into POK attempting to get compare&swap
justified was unsuccesful, in large part because the favorite son
operating system felt that test&set was just fine for multiprocessor
support (the 360/65 smp global spin lock paradigm). the challenge was to
create justification for compare&swap instruction that was applicable to
single processor deployment. Thus was born the programming notes that
can be found in principles of operation describing how the "atomic"
characteristics of comapre&swap can be leveraged in single processor
environment for multithreaded applications (like DBMS) ... these aren't
necessarily concurrent multithreads ... but multiple threads that might
be interrupted and so atomic operations can be applied to both
simultaneous concurrent multithread operation as well as possibly
non-simultaneous (but interrruptable) multithreaded operation.

the advances in concurrent, parallel technology into
loosely-coupled/cluster deployments is even more limited than the
proliferation in tightly-coupled environments.

we had done a scallable distributed lock manager in support of
our ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

and the "medusa" cluster-in-a-rack activity ... old email
http://www.garlic.com/~lynn/lhwemail.html#medusa

and somewhat referenced in these postings about old meeting
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15

... but again ... it tended to be directly used by a very limited amount
of specailized code ... there wasn't a huge number of different
applications directly implementing semantics of highly parallel
operation (for either tightly-coupled or loosely-coupled
configurations).

a couple recent posts in another thread/fora on the subject
http://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007l.html#19 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007l.html#23 John W. Backus, 82, Fortran 
developer, dies

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http:

Re: Non-Standard Mainframe Language?

2007-05-29 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

Dan Espen <[EMAIL PROTECTED]> writes:
> No, in the sense that C was pretty close to the assembler for
> the machine UNIX was first developed on.
>
> It would have been interesting if K&R went on to implement UNIX
> on a 360 type machine.  I assume they would have extended the
> C language and library functions to better exploit the hardware.

re:
http://www.garlic.com/~lynn/2007l.html#18 Non-Standard Mainframe Language?

when i was undergraudate, i had added tty/ascii terminal support to cp67
... in the process of doing that ... came up with some difficiencies in
the 2702 terminal controller ... that somewhat prompted project to build
our own clone controller out of interdata/3 ... which had somewhat
360-like instruction set. recent post making reference:
http://www.garlic.com/~lynn/2007l.html#11 John W. Backus, 82, Fortran 
developer, dies

there was some article blaiming us (at least in part) for the clone
controller business.  lots of past posts mentioning clone controllers
http://www.garlic.com/~lynn/subtopic.html#360pcm

all the references I've seen regarding redoing C & UNIX for portability
make mention of (later) interdata machines (again 360-like)

The First Unix Port
http://www.usenix.org/publications/library/proceedings/usenix98/invited_talks/miller.ps
Version 6 Unix - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Version_6_Unix
Interdata_v6
http://minnie.tuhs.org/UnixTree/Interdata_v6/
Anecdotes
http://doi.ieeecomputersociety.org/10.1109/MAHC.1989.10025
The Daemon, the GNU and the Penguin - Chapter 2 and 3
http://www.icims.csl.uiuc.edu/~lheal/doc/dgp/chapter02_03.html

of course these machines were quite a bit after interdata/3

Interdata 7/32 and 8/32
http://en.wikipedia.org/wiki/Interdata_7/32

in the above ... references to perkin-elmer having bought interdata and
quite a bit of success in "defense and aerospace" industries. people
i've talked to since, have said that a lot of the sales involved
attaching to ibm mainframe ... and the channel attach board didn't
appear to have been redesigned since our original (still wire-wrap).

Interdata Simulator Configuration
http://simh.trailing-edge.com/interdata.html

from above:

Interdata was founded in the mid 1960's. It produced a family of 16b
minicomputers loosely modeled on the IBM 360
architecture. Microprogramming allowed a steady increase in the
functionality of successive models.

* Interdata 3
* Interdata 4 (autoload, floating point)
* Interdata 5 (list processing, microcoded automatic I/O channel)
* Interdata 70, 74, 80
* Interdata 6/16, 7/16
* Interdata 8/16, 8/16e (double precision floating point, extended memory) 

In the early 1970's, Interdata was purchased by Perkin-Elmer. In 1974,
it introduced one of the first 32b minicomputers, the 7/32. Several
generations of 32b systems followed:

* Interdata 7/32
* Interdata 8/32
* Perkin-Elmer 3205, 3210, 3220
* Perkin-Elmer 3250 

Interdata was spun out of Perkin-Elmer as Concurrent Computer
Corporation.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Non-Standard Mainframe Language?

2007-05-28 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Paul Gilmartin) writes:
> Much of this is due to the reliance on null-terminated strings, which
> are not peculiar to C, but are rooted in the UNIX continuum between
> applications programming and systems programming.

i've actually had this discussion with some of the people involved, null
allowed for one byte overhead for arbitrary lengths ... somewhat the y2k
phenomena ... as opposed to the two byte explicit length overhead (for
up to 64k).

x-over post on the subject from today in another fora
http://www.garlic.com/~lynn/2007l.html#11 John W. Backus, 82, Fortran 
developer, dies

lots of posts on the subject of exploits/failures related to the
characteristic
http://www.garlic.com/~lynn/subintegrity.html#overflow

i had been monitoring some of the statistics thru the 90s ... but more
recently there were much fewer ... so i had to do some analysis myself
... looking at some of the exploit databases. part of the problem (that
I complained about) was that many of the descriptions were somewhat
freeform and could be ambiguous ... which i complained about a number of
times. there were some more recent announcements that they would be
attempting to better classify/categorize exploits.

old posts with some attempts at classification/categorization based
on analysis of some of the exploit databases
http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
http://www.garlic.com/~lynn/2004j.html#58 Vintage computers are better than 
modern crap !
http://www.garlic.com/~lynn/2005c.html#32 [Lit.] Buffer overruns

and this one mentions an article in early 2005 quoting a NIST
study that came up with similar statistics that I had come up
with nearly a year earlier:
http://www.garlic.com/~lynn/2005b.html#43 [Lit.] Buffer overruns

note part of the mentioned efforts was in support of my merged
security taxonomy and glossary ... some notes here:
http://www.garlic.com/~lynn/index.html#glosnote

past posts in this thread:
http://www.garlic.com/~lynn/2007k.html#65 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#73 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#74 Non-Standard Mainframe Language?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Non-Standard Mainframe Language?

2007-05-24 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Shmuel  Metz , Seymour J.) writes:
> The were also assists for OS/VS1 and MVS/SE, to say nothing of the
> infamous ECPS:VSE.

re:
http://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#70 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#73 Non-Standard Mainframe Language?

the 145/148 ... for lots of typical kernel instruction paths ... there
was approximately a one-for-one byte translation from 370 into
microcode. 145 allowed for scavanging part of processor memory for
microcode. that was changed in 148 ... and after the OS/VS1 microcode
assist was done for 148 ... there was only 6kbytes left in dedicated 148
microcode storage for VM370 ECPS.

This somewhat contributed to us doing a significantly better job of
choosing the highest used vm370 instruction paths (vis-a-vis the
vs1 effort) for dropping into microcode. basically all the instruction
paths thru the vm370 kernel were carefully profiled and then ranked
as per use ... and then the top 6k bytes were chosen for migration
to 148 m'code ... refs:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist

MVS/SE microcode assist would have been much more problamatical since it
was applied to the high-end horizontal m'code machines ... where there
was already nearly one-for-one between 370 execution and microcode
execution; it wouldn't have been possibly to pick up the 10:1
improvement that you found in the low & mid-ranged microcoded machines
(and in some cases, trying to do straight-forward one-for-one movement
of blocks of 370 instructions to horizontal microcode, would actually
increase processing time).

The place where the vm370 virtual machine microcode assists worked
across the whole machine line ... was being able to eliminate the
priv. op interrupts into the vm370 kernel ... that 370 supervisor state
instruction emulation, when running in special "virtual machine" problem
state ... executed the instructions directly. This wasn't a one-for-one
movement of kernel instructions to microcode instruction ... this was
the total elimination of the interrupt processing, context switch, and a
bunch of other kernel overhead stuff.

This was further demonstrated when Amdahl implemented hypervisor in
their "macrocode" ... a sort of 370 instruction set running in special
hardware mode. The response was PR/SM on the 3090 (which was a much more
difficult undertaking since it was native horizontal microcode
programming).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Non-Standard Mainframe Language?

2007-05-24 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Shmuel  Metz , Seymour J.) writes:
> Dont forget APL Shared Variables.

re:
http://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#70 Non-Standard Mainframe Language?

yes, i skipped over some of the intermediate folklore.

there was a big uproar created with the phili science center apl\360
group when the cambridge science center did cms\apl and added "system
services calls" ...  the claim was that it totally violated spirit of
apl language ...  although as i've referenced before, removing the
trivial workspace size limits of apl\360 and providing for access to
system services (like being able to do file read/writes) ... really
opened up being able to use cms\apl for real world applications.

Eventually, APL shared variables was the effective come-back from the
APL language purists on how to be able to access system services ... w/o
corrupting the purity of the APL language.

misc. past posts mentioning apl shared variable
http://www.garlic.com/~lynn/97.html#4 Mythical beasts (was IBM... mainframe)
http://www.garlic.com/~lynn/2002c.html#30 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002n.html#66 Mainframe Spreadsheets - 1980's 
History
http://www.garlic.com/~lynn/2003n.html#8 The IBM 5100 and John Titor
http://www.garlic.com/~lynn/2004c.html#7 IBM operating systems
http://www.garlic.com/~lynn/2004n.html#37 passing of iverson
http://www.garlic.com/~lynn/2005f.html#63 Moving assembler programs above the 
line
http://www.garlic.com/~lynn/2005n.html#50 APL, J or K?
http://www.garlic.com/~lynn/2006o.html#13 The SEL 840 computer

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Non-Standard Mainframe Language?

2007-05-24 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Craddock, Chris) writes:
> I never actually met a processor with the (mythical?) APL assist
> feature. However, I did write mountains of APL throughout the 1980s. APL
> was always thought of as a resource hog. IMHO it could be very efficient
> or grotesque, depending on your data structures and algorithms. If you
> wrote programs in the style of 3 GLs, it was typically a dog. 

re:
http://www.garlic.com/~lynn/2007k.html#65 Non-Standard Mainframe Language?

APL microcode assist was done for the 370/145 by the Palo Alto Science
Center ... sort of as part of their doing APL\CMS. This was also made
available on 370/148.

As mentioned, the Cambridge Science Center had originally done the port
of APL\360 to CMS for CMS\APL (i.e. back when it was Cambridge Monitor
System for CP67; as part of the morph of CP67 to VM370 they "renamed"
CMS the Conversational Monitor System).

APL microcode assist gave APL\CMS applications on 370/145 about the same
processor thruput as same APL\CMS application running on 370/168 (nearly
ten times thruput increase).

When the HONE datacenters were consolidated in silicon valley (actually
across the back parking lot from the Palo Alto Science Center) ... they
looked at whether they take any of their APL application intensive
workload and move them off 168s to 145s. The problem was not only were
their applications quite processor intensive (which 145 microcode assist
would have given about equivalence) but also real storage and I/O
intensive (which would have severely degraded if they had moved from 168
to 145/148).

For nearly 15 yrs, i provided highly modified/customized versions of
cp67 kernel and later vm370 kernels for HONE (and large number of other
internal datacenters). I also periodically got involved in reviewing
various APL applications from performance tuning standpoint ... aka
majority of the applications that provided world-wide support for sales
and marketing were implemented in APL running on CMS. Lots of past posts
mentioning HONE and/or APL
http://www.garlic.com/~lynn/subtopic.html#hone

Eventually there was a APL language development group formed in STL
which picked up APL\CMS responsibility as well as making it available on
MVS ... renaming it VS\APL (and later APL2).

Trivia ... in the early to mid 80s, the manager of the APL group in STL
transferred to Palo Alto to head up a new group doing a port of BSD Unix
to 370. I got to attend some of the design sessions and also help obtain
a 370 C compiler for the effort. Before that specific implementation
shipped, the group had their BSD porting efforts retargeted to the PC/RT
... eventually shipping "AOS" (the C compiler vendor being used had to
retarget the backend from 370 to ROMP).

misc. past posts mentioning 801/ROMP as well as risc, Iliad, RIOS,
rs/6000, power/pc, etc
http://www.garlic.com/~lynn/subtopic.html#801

The APL microcode assist was not made available on other processors.
The 145/148 microcode engine was a vertical microcode engine and
executing approx. 10 microcode instructions per every 370 instruction
(some of the modern i86-based 370 simulators have similar ratio
characteristics). 

The 370/165 had a horizontal microcode engine ... and achieved an
avg. of 2.1 machine cycles per 370 instruction ... which was improved to
1.6 machine cycles per 370 instruction (and hit nearly 1:1 with 3033).
Since 370 instructions were executing very close to hardware speed on
the high-end processors ... there was frequently very little performance
benefit of doing a 1-for-1 translation of 370 instruction into native
hardware. The exception was virtual machine microcode assists on the
high-end processors ... however these weren't the 1:1 translation of 370
instructions to native instructions. In the virtual machine assists, the
instruction emulation for privilege instruction was modified to directly
perform the privilege operation while in problem state (but according to
"virtual machine" execution rules ... sort of a "3rd" machine state).
This avoided the interrupt into the kernel, having to save registers and
other state change overhead ... redecode the operation in software and
perform the necessary operation, and then switch back to virtual machine
problem state execution.

In addition to stuff like APL microcode assist done for 145/148
... there was the VM kernel assist "ECPS" done for both 138 & 148.  This
took about 6k bytes of vm370 370 kernel code and moved it into native
microcode of the machines (again getting about 10:1 thruput
improvement).

some old posts about how we went about selecting what parts of the
kernel code were moved into microcode (some of the initial work involved
help from some of the same people involved in doing the 145 APL microcode 
assist)
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.

Re: Non-Standard Mainframe Language?

2007-05-23 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Gerhard Postpischil) writes:
> Back in the seventies I was in charge of the systems group at a
> service bureau. One of our customers was from a local university,
> running an APL application that tracked students vs. classes, and a
> few other things. It was gold mine - whenever it ran, the CPU went
> 100% busy and stayed that way for a long time. The same thing written
> in another language might have cost one or two percent as much.

recent post mentioning world-wide hone system
http://www.garlic.com/~lynn/2007.html#30 V2X2 vs. Shark (SnapShot v. FlashCopy)
http://www.garlic.com/~lynn/2007.html#31 V2X2 vs. Shark (SnapShot v. FlashCopy)
http://www.garlic.com/~lynn/2007.html#46 How many 36-bit Unix ports in the old 
days?
http://www.garlic.com/~lynn/2007b.html#51 Special characters in passwords was 
Re: RACF - Password rules
http://www.garlic.com/~lynn/2007d.html#39 old tapes
http://www.garlic.com/~lynn/2007e.html#38 FBA rant
http://www.garlic.com/~lynn/2007e.html#41 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007f.html#12 FBA rant
http://www.garlic.com/~lynn/2007f.html#20 Historical curiosity question
http://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
http://www.garlic.com/~lynn/2007i.html#34 Internal DASD Pathing
http://www.garlic.com/~lynn/2007i.html#77 Sizing CPU
http://www.garlic.com/~lynn/2007j.html#65 Help settle a job title/role debate
http://www.garlic.com/~lynn/2007k.html#60 3350 failures

HONE ("hands-on") started out in the US with cp67 ... sort of to allow
branch office SEs to have "hands-on" with various operating sysetms
(running in virtual machines). prior to 23jun69 unbundling announcement
http://www.garlic.com/~lynn/subtopic.html#unbundle

a lot of SEs got much of their "hands-on" experience in their customer
accounts. after the unbundling announcement, SE time was being charged
for ... and not a lot of customers were interested in paying to have SEs
learn.

however, the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

in addition to doing virtual machines, cms, inventing GML (precursor
to SGML, HTML, XML, etc)
http://www.garlic.com/~lynn/subtopic.html#sgml

and the internal networking technology
http://www.garlic.com/~lynn/subnetwork.html#internalnet

which was also used in bitnet and earn
http://www.garlic.com/~lynn/subnetwork.html#bitnet

also did a port of apl\360 to cms (cms\apl). apl\360 had its own
monitor, scheduler, workspace swapping, terminal handler, etc ... all of
which could be discarded in the port for cms\apl. also in moving from
the 16kbyte (sometimes 32kbyte) "real" workspace sizes  to CMS
... where the workspace size could be all of virtual memory ... the
whole way that APL managed storage had to be reworked (the real storage
stategy resulted in enormous page thrashing).

part of cms\apl was also the ability to access system services (things
like read/write files) ... something that apl didn't previously
have. the combination of really large workspace sizes and the access to
system services ... opened up APL for a lot of real-world problems. A
lot of modeling off all kinds was done ... as well as a lot of stuff
that these days are implementing with spreadsheets.

One of the early "big" APL uses (at cambride) were a number of business
planners from corporate hdqtrs in armonk. they forwarded a tape to
cambridge with all of the most sensitive corporate customer business
data ... and would do significant amount of business modeling and
planning. this created an interested "security" scenario for the service
at cambridge since there were a lot of non-employees using the system
from various educational institutions in the cambridge area.

one instance is this slightly related DNS trivia topic drift ... more
than a decade before DNS
http://www.garlic.com/~lynn/2007k.html#33 Even worse than Unix

Before long there were a significant number of CMS\APL applications
written that supported sales & marketing and deployed on the HONE system
... effectively taking over its whole use for sales & marketing (and
eliminating the original "hands-on" use for SEs). Before long, sales
couldn't even submit customer orders that hadn't been processed by some
CMS\APL application. HONE transitioned from cp67 to vm370-based platform
and from cms\apl to apl\cms (enhancements done by the palo alto science
center ... including the 370/145 apl microcode assist) ... and clones of
(US) HONE system were sprouting up all over the world (some of the early
ones i even got to handle ... like when EMEA hdqtrs moved from the US to
Paris).

lots of other posts mentioning HONE and/or APL
http://www.garlic.com/~lynn/subtopic.html#hone

in the mid-70s, the US HONE datacenters were consolidated in silicon
valley. The large customer base (all US sales and marketing) drove the
requirement for large disk farm

Re: [META] Is WaveMind spamming entire IBM-MAIN readership?

2007-05-23 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.


me too

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3350 failures

2007-05-22 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] writes:
> I don't remember any 3350 problems as this device type was my first 
> performance charge with doing internal pathing/volume placement based on 
> performance metrics at timeshare NVIP back in the early 80's. I do however 
> remember the 3350 to 3380 migration project which turned ugly when we were 
> informed, post migration, that we needed plenum replacements on our 3380 
> E's/K's. IIRC the plenum connected to 2 different HDA's but I could be 
> wrong on this point.  Lots of long weekends with the media folks deciding 
> how to play musical chairs with strings of DASD.

re:
http://www.garlic.com/~lynn/2007k.html#58 3350 failures
http://www.garlic.com/~lynn/2007k.html#60 3350 failures

old email
http://www.garlic.com/~lynn/2007b.html#email800402

talks about problem executing HIO/HDV to 3350 when (3880) control unit
was busy (which may have also existing in 3830) ... and software
fix was to i/o supervisor to "not do that".

one of the 3350 to 3380 migration issues was that the 3380 had more data
under each arm (proportional in excess in any increase in 3380 thruput
improvement).

internally we had some performance monitoring and modeling tools that
would identify what 3350 data to move to what 3380  and some
recommendations (in heavily loaded environment) to leave 3380 10-20
percent empty/idle (in order to have same thruput as 3350
configuration).

there was a facetious proposal (even discussed at SHARE) for a special
3380 "feature" in the 3880 controller ... that would define extra priced
3380 drives that were "faster" (by reducing the number of cylinders that
could be accessed). This was for shops where the administrators couldn't
resist completely filling a 3380 as cost effective measure (however,
they would feel comfortable with paying extra for feature that prevented
them from completely filling a 3380).

misc. past posts about getting to play dasd engineer in the disk
engineering lab (bldg. 14) and the disk product test lab (bldg. 15).
http://www.garlic.com/~lynn/subtopic.html#disk

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3350 failures

2007-05-22 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Ted MacNEIL) writes:
> I started with 3330's.
> And, I remember when STK (STC) showed us their first ICEBERG, and the
> size of the device was that of a standard conference table, weighed
> less and had the capacity of an order (or 2) of magnitude larger than
> the 3330 farm I first tended.
>
> That 3330 farm was less than 50 GB, and we were considered a medium to large 
> site.
> (Running on a 3081-D)

re:
http://www.garlic.com/~lynn/2007k.html#58 3350 failures

silicon valley area had at least three fairly large vm370 customer
datacenters with good sized disk farms ... there was SLAC (lots of
collection from the accelerator) and both Tymshare and internal HONE
operation ... both extensive online, timesharing services
http://www.garlic.com/~lynn/subtopic.html#timeshare

HONE had somewhat started out with a number of cp67 installations to
provide "hands-on" virtual machine use for branch office SEs. recent
reference:
http://www.garlic.com/~lynn/2007j.html#65 Help settle a job title/role debate

It then transitioned to vm370 and lots of online, interactive APL
applications supporting sales & marketing ... i.e. at some point early
in 370 timeframe, there was transition where machine orders couldn't
even be submitted w/o having first being processed by a HONE
configuration.

In the mid-70s, the various (US) HONE datacenters were consolidated in
silicon valley area ... with what was possibly the largest single-system
configuration in the world at the time (large datafarm with load
balancing across large number of processors in loosely-coupled
configuration).
http://www.garlic.com/~lynn/subtopic.html#hone

another large datacenter in silicon valley was Lockheed's DIALOG (online
library titles and abstracts which has gone thru a number of owners
since that time) ... which had something like 300(?) 3330-clones in their
data farm (the basic service was MVS ... but lots of it was run under VM
... on clone processors).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3350 failures

2007-05-21 Thread Anne & Lynn Wheeler

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.

[EMAIL PROTECTED] writes:
> IBM 3880 - 1 or 2 (IBM DASD and Control Units Facts Folder G520-3075-2)

old email with reference to finding bug in the 3350 support in
3880 controller (and possibility of same bug having been in 3830
controller)
http://www.garlic.com/~lynn/2007b.html#email800402
in this recent post
http://www.garlic.com/~lynn/2007b.html#28 What is "command reject" trying to 
tell me?

above post also references early 3880 MVS RAS testing in this post
http://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style" 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Another "migration" from the mainframe

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.


re:
http://www.garlic.com/~lynn/2007k.html#18 Another "migration" from the mainframe
http://www.garlic.com/~lynn/2007k.html#19 Another "migration" from the mainframe
http://www.garlic.com/~lynn/2007k.html#22 Another "migration" from the mainframe

lots of old posts mentioning working on our ha/cmp product ... and/or
some loosely-coupled (dating back to at least when my wife had been con'ed
into going to POK to be in charge of loosely-coupled architecture)
http://www.garlic.com/~lynn/subtopic.html#hacmp

when she was in POK, in charge of loosely-coupled architecture, she
developed peer-coupled shared data architecture, which didn't see a lot
of uptake (except for ims-hotstandby) until parallel sysplex
http://www.garlic.com/~lynn/subtopic.html#shareddata


and a little followup of financial industry using blades/grids at the
high-end ... including enabling them to do "real-time" trading
algorithms ...  something that they haven't been able to do before

Lots of Blade Server articles
http://www.eweek.com/category2/0,1874,1658862,00.asp

IBM Grid Computing Solutions - financial industry
http://www-03.ibm.com/grid/solutions/by_industry/financial.shtml

from above:

Optimized Analytic Infrastructure
Drive higher margins and revenue growth by:

* Turning creative quantitative insight into tested, supported, tradable
  investment products

* Achieving near real-time and intraday decision making for on demand
  valuations and complex risk reporting in minutes

* Reducing costs and enhancing standardization of existing analytic
  infrastructures

... snip ... 

Grid Computing for Financial Services 2007
http://www.iqpc.com/cgi-bin/templates/genevent.html?topic=233&event=12603&;

from above:

"70% of firms now deploy enterprise grids in key business areas" to
maximise CPU power and business capability – but are you really driving
its development forward in your IT strategy?

... snip ... 

Grid computing: Accelerating the search for revenue and profit for financial 
markets
http://www-03.ibm.com/industries/financialservices/doc/content/landing/973028103.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Another "migration" from the mainframe

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.


re:
http://www.garlic.com/~lynn/2007k.html#18 Another "migration" from the mainframe
http://www.garlic.com/~lynn/2007k.html#19 Another "migration" from the mainframe

as an aside ... all the vendors that support server farms at least in
the form of blade/GRID technology have done significant amounts of work
on energy and cooling efficiency.

in fact, cooling was one of major concerns working on ha/cmp scaleup
related to these old emails
http://www.garlic.com/~lynn/lhwemail.html#medusa

small sample re blade/grid energy efficiency

CIO Challenge: Energy Efficiency
http://www.wallstreetandtech.com/showArticle.jhtml?articleID=192202377

from above:

Like Fidelity, Wachovia has been targeting energy efficiency initiatives
for the last 12 to 18 months or so. The initial spur was a move by the
firm's traders in January to a new building in New York. "The three
trading floors have relatively low ceiling heights, where it was not
possible to put in a lot of air distribution, which meant we had to
think creatively to ensure we don't have an unhealthy environment for
the traders,"

... snip ...

and:

IBM Unveils New Energy-Efficient Blades
http://www.hpcwire.com/hpc/1379801.html
IBM to focus on energy efficiency
http://www.bladewatch.com/2007/05/10/ibm-to-focus-on-energy-efficiency/
Blade innovations highlight energy efficiency opportunities
http://www.it-director.com/business/content.php?cid=9135
IBM defends blades' energy efficiency
http://green.itweek.co.uk/2006/10/ibm_defends_bla.html
IBM Data Center and Facilities Strategy Services - high density
computing data center readiness assessment
http://www-935.ibm.com/services/us/index.wss/offering/its/a1025605#spotligt-data-center

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Another "migration" from the mainframe

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.

[EMAIL PROTECTED] (Howard Brazee) writes:
> I'd also like to see that with politics, but politician's pay is
> power, and that cannot be deferred.But it is more important for a
> President's policy to work for the long term than for a CEO's policy.
> Neither should be measured by "not on my term", but both should be
> measured by leaving a legacy that lasts.Build for the future -
> when the other guys are running the company/country.

i think that the comptroller general has suggested something similar for
legislation ... that metrics are defined associated for any claimed
benefits justifying some legislation ... and if the results fail to meet
the metrics ... poof, its gone.

however, in speeches that the comptroller general has given over the
past yr or so on some aspects of medicare/medicaid legislation ... he
has commented that he doesn't believe any congressman in the last fifty
yrs has been capable of middle-school arithmatic.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Another "migration" from the mainframe