Latest Principles of Operation
John R. Ehrman , 408-463-3543 T/543-
available at
http://publibz.boulder.ibm.com/epubs/pdf/a2278325.pdf
John Ehrman
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Binyamin Dissen
<ehr...@VNET.IBM.COM> wrote:
:>The new updated to the z/Architecture Principles of Operation is now
:>available at
:> http://publibz.boulder.ibm.com/epubs/pdf/a2278325.pdf
Some interesting new instructions.
Of course, I cannot use them until all customers are at the hardware level,
but ....
--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
Tom Schmidt
>The new updated to the z/Architecture Principles of Operation is now
>available
..
So where is the MVCOS instruction? (I was expecting to find it in this
update.)
--
Tom Schmidt
Madison, WI
rkue...@ibm-main.lst
with it on!
IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU> wrote on 04/23/2007
06:13:09 PM:
> On Mon, 23 Apr 2007 14:10:15 -0700, John R. Ehrman wrote:
> >The new updated to the z/Architecture Principles of Operation is now
> >available
> ....
> So where is the MVCOS instruction? (I was expecting to find it in this
> update.)
> Tom Schmidt
> Madison, WI
-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. The information may also constitute a legally
privileged confidential communication. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified
that you have received this communication in error and that any
review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the
contents of this information is strictly prohibited. If you have
received this communication in error, please notify us immediately
by e-mail, and delete the original message. Thank you
Steve Comstock
> On Mon, 23 Apr 2007 14:10:15 -0700, John R. Ehrman wrote:
>
>
>>The new updated to the z/Architecture Principles of Operation is now
>>available
>
>
> So where is the MVCOS instruction? (I was expecting to find it in this
> update.)
>
Good point! I haven't gotten around to checking the
book out, but I, too, was expecting that write up.
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
** Spring Promotion **
10% - 15% off for classes booked by April 30, 2007
to be taught by September 30, 2007
Call or email for details.
** Spring Promotion **
Tom Marchant
>The new updated to the z/Architecture Principles of Operation is now
>available at
>
> http://publibz.boulder.ibm.com/epubs/pdf/a2278325.pdf
Thanks, John. Will it be available as a BookManager book too?
--
Tom Marchant
Tom Marchant
>The new updated to the z/Architecture Principles of Operation is now
>available at
>
> http://publibz.boulder.ibm.com/epubs/pdf/a2278325.pdf
With the new instructions, I now count 751 instructions documented in the
POO. That's up a lot from the (IIRC) 143 for S/360.
Rick Fochtman
>>The new updated to the z/Architecture Principles of Operation is now
>>available at
>>
>> http://publibz.boulder.ibm.com/epubs/pdf/a2278325.pdf
>>
>>
>
>With the new instructions, I now count 751 instructions documented in the
>POO. That's up a lot from the (IIRC) 143 for S/360.
>
>
-------------------------<unsnip>-----------------------
It's called evolution, son. Like it or not, we're stuck with it and it
can be a good thing, in spite of personnal opinions to the contrary.
Tom Marchant
>>
>>With the new instructions, I now count 751 instructions documented in the
>>POO. That's up a lot from the (IIRC) 143 for S/360.
>>
>
>It's called evolution, son. Like it or not, we're stuck with it and it
>can be a good thing, in spite of personnal opinions to the contrary.
That wasn't a complaint. Actually, I do like it, even though it makes being an
Assembler programmer more challenging. It's one of the many details about
this platform that I find to be very impressive.
--
Tom Marchant
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@BAMA.UA.EDU] On Behalf Of Tom Marchant
> Sent: Wednesday, April 25, 2007 2:34 PM
> To: IBM-...@BAMA.UA.EDU
> Subject: Re: Latest Principles of Operation
<snip>
>
> That wasn't a complaint. Actually, I do like it, even though
> it makes being an
> Assembler programmer more challenging. It's one of the many
> details about
> this platform that I find to be very impressive.
>
> --
> Tom Marchant
Perhaps to you, but not true in general according to one article.
Paraphrasing: Having so many instructions will simply confuse the
programmer! Better to have "one, true way" than many.
http://www.oreillynet.com/onlamp/blog/2007/04/the_virtues_of_monoculture
html
This article is basically about why Microsoft is better than Linux in
some ways. Linux has too many competing ways to do something whereas
Microsoft is usually monolithic. And "lack of choice" is superior
because choice leads to confusion.
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.
Howard Brazee
wrote:
>Paraphrasing: Having so many instructions will simply confuse the
>programmer! Better to have "one, true way" than many.
>
>http://www.oreillynet.com/onlamp/blog/2007/04/the_virtues_of_monoculture
>html
>
>This article is basically about why Microsoft is better than Linux in
>some ways. Linux has too many competing ways to do something whereas
>Microsoft is usually monolithic. And "lack of choice" is superior
>because choice leads to confusion.
That makes sense. But continuing that thought, I see Apple, which
doesn't try to make its OS be all things for all people (and hardware
manufacturers). Even if it *is* UNIX.
DASD...@ibm-main.lst
In a message dated 4/25/2007 1:41:31 P.M. Central Daylight Time,
>With the new instructions, I now count 751 instructions documented in the
POO. That's up a lot from the (IIRC) 143 for S/360.
pages. With a PDF version, it is very simple - scroll down to the bottom and
look at PDF's page number. Version -05 is 1218. I remember being very
pleased about seven years ago when I discovered that the first POO that documented
64-bit architecture and grande instructions had 1024 pages, an integral power
of two.
Bill Fairchild
Plainfield, IL
************************************** See what's free at http://www.aol.com.
CICS Guy
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Of (IBM Mainframe Discussion List)
Sent: Wednesday, April 25, 2007 4:07 PM
To: IBM-...@BAMA.UA.EDU
Subject: Re: Latest Principles of Operation
In a message dated 4/25/2007 1:41:31 P.M. Central Daylight Time,
m42tom-...@YAHOO.COM writes:
>With the new instructions, I now count 751 instructions documented in the
POO. That's up a lot from the (IIRC) 143 for S/360.
I do something similar, but less time-consuming. I look at the number of
pages. With a PDF version, it is very simple - scroll down to the bottom
and
look at PDF's page number. Version -05 is 1218. I remember being very
pleased about seven years ago when I discovered that the first POO that
documented
64-bit architecture and grande instructions had 1024 pages, an integral
power
of two.
Bill Fairchild
Plainfield, IL
_________________________________________________________________
The average US Credit Score is 675. The cost to see yours: $0 by Experian.
http://www.freecreditreport.com/pm/default.aspx?sc=660600&bcd=EMAILFOOTERAVERAGE
Efinn...@ibm-main.lst
In a message dated 4/25/2007 3:19:22 P.M. Central Daylight Time,
bst...@HOTMAIL.COM writes:
Gee, the POO I use (paper) tops out at around 175 pages.......
>>
How does it check for floating point decimal?
************************************** See what's free at http://www.aol.com.
----------------------------------------------------------------------
CICS Guy
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Of Ed Finnell
Sent: Wednesday, April 25, 2007 4:24 PM
To: IBM-...@BAMA.UA.EDU
Subject: Re: Latest Principles of Operation
In a message dated 4/25/2007 3:19:22 P.M. Central Daylight Time,
bst...@HOTMAIL.COM writes:
Gee, the POO I use (paper) tops out at around 175 pages.......
>>
How does it check for floating point decimal?
_________________________________________________________________
Need a break? Find your escape route with Live Search Maps.
http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01
Anne & Lynn Wheeler
> That makes sense. But continuing that thought, I see Apple, which
> doesn't try to make its OS be all things for all people (and hardware
> manufacturers). Even if it *is* UNIX.
nominally the argument is that complexity contributes to confusion and
failures ... KISS is frequently better because it minimizes confusion
which can be major source of failures, vulnerabilities, threats and
exploits. however, another argument is that the solution paradigm has to
match the environment ... that there can be enormous amount of
complexity introduced when the solution paradigm is a mismatch for the
environment that it is being applied to.
slightly related thread discussing f18/f14, f16/f15, as well as f20
(with even a little computer related stuff sprinkled in) ... warning
quite a bit of thread drift ... even tho there was a lot of numerical
intensive computing that went into f16, f18, f20, etc:
http://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#6 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#7 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#8 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#10 John W. Backus, 82, Fortran developer, dies
Anne & Lynn Wheeler
> That makes sense. But continuing that thought, I see Apple, which
> doesn't try to make its OS be all things for all people (and hardware
> manufacturers). Even if it *is* UNIX.
re:
http://www.garlic.com/~lynn/2007i.html#25 Latest Principles of Operation
apple os (and next before it) starts out with a MACH "microkernel" basis
... could be considered striving for KISS ... somewhat like the original
CP67, as an extremely well focused microkernel. The morph from CP67 to
VM370 included work by people with much more of traditional operating
system training. Over the years, many found that the extreme simplicity
of the kernel made it easy to change/add/modify on an adhoc basis.
Unfortunately many such years of such adhoc approach to dealing with
something that was suppose to be a microkernel (rather than operating
system) ... eventually results in a lot of bloat and spaghetti code
past reference to comment about simple can be frequently much harder
than complex ... and it should be done with there is nothing left to
remove ... as opposed to it being done when there is nothing left to
add.
http://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#30 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
more recently there have been comments about simple virtual machine
microkernels may be solution to various significant security issues in
the personal computing market place ... dynamically opening up a
traditional operating system in a "padded cell" virtual machine when it
needs to do various kinds of internet/network operations ... and then
collapsing and discarding most of the environment when finished.
lots of past posts referring to various microkernel activities:
http://www.garlic.com/~lynn/94.html#54 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#0 pathlengths
http://www.garlic.com/~lynn/2000e.html#42 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001h.html#11 checking some myths.
http://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan?
http://www.garlic.com/~lynn/2001k.html#45 SMP idea for the future
http://www.garlic.com/~lynn/2001l.html#25 mainframe question
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
http://www.garlic.com/~lynn/2003.html#60 MIDAS
http://www.garlic.com/~lynn/2003h.html#37 Does PowerPC 970 has Tagged TLBs (Address Space Identifiers)
http://www.garlic.com/~lynn/2003j.html#72 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#5 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#24 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#28 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#30 IBM channels, was Re: Microkernels are not "all or nothing"
http://www.garlic.com/~lynn/2003k.html#37 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2005b.html#22 The Mac is like a modern day Betamax
http://www.garlic.com/~lynn/2005c.html#44 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#56 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005c.html#63 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006p.html#11 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#83 IBM to the PCM market
Clark Morris
>On Wed, 25 Apr 2007 14:16:47 -0500, Rick Fochtman wrote:
>
>>>
>>>With the new instructions, I now count 751 instructions documented in the
>>>POO. That's up a lot from the (IIRC) 143 for S/360.
>>>
>>
>>It's called evolution, son. Like it or not, we're stuck with it and it
>>can be a good thing, in spite of personnal opinions to the contrary.
>
>That wasn't a complaint. Actually, I do like it, even though it makes being an
>Assembler programmer more challenging. It's one of the many details about
>this platform that I find to be very impressive.
The frustrating thing is that there is no compiler switch to tell most
of the compilers that these instructions can be used because the
target is known. ISV's normally have to hang back on using these
instructions because the target processor may not have the
instruction.
Of course, my feeling is that COBOL is on life support with no
strategic direction.
Rick Fochtman
nominally the argument is that complexity contributes to confusion and
failures ... KISS is frequently better because it minimizes confusion
which can be major source of failures, vulnerabilities, threats and
exploits. however, another argument is that the solution paradigm has to
match the environment ... that there can be enormous amount of
complexity introduced when the solution paradigm is a mismatch for the
environment that it is being applied to.
That increased instruction set allows for vastly increased capability,
in spite of the perceived complexity. Simple applications can still be
coded using simple instructions, but more complex requirements can be
met more simply and efficiently by using some of those "added
instructions" that seem to lead to complexity.
Complexity is far too often used as an excuse for incompetence or
laziness; not always or even most of the time, but still far too often.
You don't let a carpenter into your house if he doesn't know how to use
his tools, do you????
Edward Jaffe
> The frustrating thing is that there is no compiler switch to tell most
> of the compilers that these instructions can be used because the
> target is known. ISV's normally have to hang back on using these
> instructions because the target processor may not have the
> instruction.
>
ARCH
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcug150/2.3.15.5
TUNE
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcug150/2.3.15.94
ISVs do indeed have to "hang back". And, so do IBM developers. The life
saver is knows as an "Architectural Level Set". Some customers don't
like them because they tend to obsolete affordable hardware processor
models. But, IBM and ISV developers like them because they allow use of
the new facilities. For example, IBM no longer supports anything less
than z/OS 1.6. And, z/OS 1.6 requires z/Architecture. This means that
IBM developers can use z/Architecture instructions for _all_ new code
targeted for z/OS without the need for dual-path, bifurcated, or "lowest
common denominator" instruction paths. The same holds true for any ISV
that follows IBM's support schedule.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
John Eells
> That increased instruction set allows for vastly increased capability,
> in spite of the perceived complexity. Simple applications can still be
> coded using simple instructions, but more complex requirements can be
> met more simply and efficiently by using some of those "added
> instructions" that seem to lead to complexity.
>
> Complexity is far too often used as an excuse for incompetence or
> laziness; not always or even most of the time, but still far too often.
> You don't let a carpenter into your house if he doesn't know how to use
> his tools, do you????
I think it's worth noting that subsystems and compilers (and of
course interpreters) can hide the underlying complexity. The
human-facing interface need not be more complex for the
underlying architecture to have better or more function.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com
Jeffrey D. Smith
> From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
> Behalf Of Edward Jaffe
> Sent: Thursday, April 26, 2007 9:45 AM
> To: IBM-...@BAMA.UA.EDU
> Subject: Re: Latest Principles of Operation
>
> > The frustrating thing is that there is no compiler switch to tell most
> > of the compilers that these instructions can be used because the
> > target is known. ISV's normally have to hang back on using these
> > instructions because the target processor may not have the
> > instruction.
> >
>
>
> ISVs do indeed have to "hang back". And, so do IBM developers. The life
> saver is knows as an "Architectural Level Set". Some customers don't
> like them because they tend to obsolete affordable hardware processor
> models. But, IBM and ISV developers like them because they allow use of
> the new facilities. For example, IBM no longer supports anything less
> than z/OS 1.6. And, z/OS 1.6 requires z/Architecture. This means that
> IBM developers can use z/Architecture instructions for _all_ new code
> targeted for z/OS without the need for dual-path, bifurcated, or "lowest
> common denominator" instruction paths. The same holds true for any ISV
> that follows IBM's support schedule.
>
> --
> Edward E Jaffe
Unfortunately, there are still some customers (at least one that is a
"big name" in the corporate banking world) that uses a 31-bit Amdahl
box with OS/390 R10. I had to write my crypto stuff using some dual
pathing to accommodate them. sigh...
Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
see my résumé at my website (yes, I am looking for employment)
David Andrews
> The frustrating thing is that there is no compiler switch to tell most
> of the compilers that these instructions can be used
The IBMers contributing to GCC have been doing pretty well on this
front. GCC 4.1 uses 34 new instructions for z9 processors.
--
David Andrews
A. Duda and Sons, Inc.
david....@duda.com
Mark H. Young
<jeffre...@EARTHLINK.NET> wrote:
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
>> Behalf Of Edward Jaffe
>> Sent: Thursday, April 26, 2007 9:45 AM
>> To: IBM-...@BAMA.UA.EDU
>> Subject: Re: Latest Principles of Operation
>Unfortunately, there are still some customers (at least one that is a
>"big name" in the corporate banking world) that uses a 31-bit Amdahl
>box with OS/390 R10. I had to write my crypto stuff using some dual
>pathing to accommodate them. sigh...
>
>Jeffrey D. Smith
>Principal Product Architect
>Farsight Systems Corporation
>700 KEN PRATT BLVD. #204-159
>LONGMONT, CO 80501-6452
>303-774-9381 direct
>303-484-6170 FAX
>http://www.farsight-systems.com/
>see my résumé at my website (yes, I am looking for employment)
Speaking of dual pathing.....that brings to mind something I could not
remember recently about 3380 geometry DASD that had "internal pathing"???
Remember those? Anyone know what the device was called from IBM?
Like maybe the model name et al?? I'm experiencing my daily Alzheimer's spell.
We had them back in the day (mid-1980s) at Marriott Corp. in Bethesda, MD,
and had to consider what we placed where so it didn't cause performance
problems.
THANX,
Mark H. Young
Patrick...@ibm-main.lst
was told we had them and most IBM DASD at that time, 1979 or so, at NVIP
but I was not aware of all we had back then. I think the IBM 3380 had 4
internal path selection.
"Mark H. Young" <Mark....@FAIRFAXCOUNTY.GOV>
Sent by: IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU>
04/26/2007 12:10 PM
Please respond to
IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU>
Subject
Re: Latest Principles of Operation
Anne & Lynn Wheeler
> That increased instruction set allows for vastly increased capability,
> in spite of the perceived complexity. Simple applications can still be
> coded using simple instructions, but more complex requirements can be
> met more simply and efficiently by using some of those "added
> instructions" that seem to lead to complexity.
>
> Complexity is far too often used as an excuse for incompetence or
> laziness; not always or even most of the time, but still far too
> often. You don't let a carpenter into your house if he doesn't know
> how to use his tools, do you????
re:
http://www.garlic.com/~lynn/2007i.html#25 Latest Principles of Operation
http://www.garlic.com/~lynn/2007i.html#26 Latest Principles of Operation
well, i remember the hassle to get compare&swap instruction into the 370
architecture. Charlie had invented compare&swap instruction when he was
working on smp knerel fine-grain locking for cp67 at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
the "redbook" 370 architecture owners claimed that everybody (namely the
POK favorite son operating system people) thot that test&set was totally
adequate for all multiprocessor support. in order to justify getting
compare&swap instruction into 370 architecture, we had to come up with a
whole boatload of justifications for compare&swap instruction that
wasn't specific to multiprocessor operation. thus was born the stuff in
principle of operations about using compare&swap instruction for
application multithreaded operation (regardless of whether or not it was
multiprocessor environment). lots of past posts mentioning
multiprocessor support and/or compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp
it is sometimes relative. i've claimed that John came up with risc/801
as part of going to the opposite extreme after the extremely complex
future system project failed ... misc. past posts mentioning failed
future system project
http://www.garlic.com/~lynn/subtopic.html#futuresys
and lots of past post mentioning 801, romp, rios, iliad, fort knox,
somerset, power/pc, etc
http://www.garlic.com/~lynn/subtopic.html#801
and old email with 801 references
http://www.garlic.com/~lynn/lhwemail.html#801
Supposedly future system project was a countermeasure to clone
controllers ... something I got (at least partially) blamed for from a
project that I worked on as undergraduate in the 60s producing our own
clone controller
http://www.garlic.com/~lynn/subtopic.html#360pcm
also some "FS" quotes referenced in this post
http://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
from article by former executive here
http://www.ecole.org/Crisis_and_change_1995_1.htm
The FS effort and subsequent failure ... can also be considered as
contributing to the uptake of clone processors (in part because of the
dearth of items in the 370 product pipeline) a few recent posts
http://www.garlic.com/~lynn/2007g.html#55 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
and after the failure of the FS project ... there was a rush to get
stuff back into the 370 product pipeline. Recent post attributing that
as big part of the reason that the product group shipped so much of my
code (since I continued to develop 370-based software all thru the FS
activity)
http://www.garlic.com/~lynn/2007i.html#21 John W. Backus, 82, Fortran developer, dies
and another recent posting touching on some stuff that went on in the FS era
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#29 Does anyone know of a documented case of VM being penetrated by hackers?
another stop-gap effort to try and quickly fill the 370 product pipeline
was 3033x (after failure of FS project) was 303x. The standard processor
development cycle was 7-8yrs ... and they needed to get something out
much quicker than that ... since starting the 370-xa/3081 wouldn't be
out before the early 80s.
So they took they 370/158 microcode engine ... and stripped out the 370
microcode support ... leaving just the integrated channel microcode and
packaged it as the 303x "channel director". Then the 3031 was a 370/158
microcode engine with just the 370 microcode support (and no integrated
channel microcode) paired with a "channel director". The 3032 was a
370/168-3 repackaged to work with "channel director". The 3033 started
out simply being 168 wiring diagram mapped to newer chip technology.
Recent posts about enormous effort to hurry up and get 303x out the
door after failed FS project:
http://www.garlic.com/~lynn/2007d.html#21 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007d.html#62 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#32 I/O in Emulated Mainframes
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
http://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#73 Is computer history taught now?
http://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#23 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#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007h.html#1 21st Century ISA goals?
the other aftermath of the FS project failure was that POK lab convinced
corporate to shutdown the VM development group, decommit the product,
and transfer all the people to POK in order to work on MVS/XA ... also
attempting to shorten the typical development time. Endicott was
eventually able to salvage the product mission and one or two of the
people.
Clark Morris
wrote:
>Clark Morris wrote:
>> The frustrating thing is that there is no compiler switch to tell most
>> of the compilers that these instructions can be used because the
>> target is known. ISV's normally have to hang back on using these
>> instructions because the target processor may not have the
>> instruction.
>>
>
>ARCH
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcug150/2.3.15.5
>
>TUNE
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcug150/2.3.15.94
Now would it make a difference in COBOL performance if COBOL had those
options and if so why doesn't it. Of course the abysmal performance
of TRUNC(BIN) was due to incredibly bad programming decisions (convert
to and from decimal for the actual arithmetic). And then there is the
ridiculous IEEE to hex floating point conversion done for Java
interface even though there is a CLEAN way to define IEEE floating
point using the 2002 standard.