junking CKD; was "Social Security Confronts IT Obsolescence"
Bill Fairchild
Bill Fairchild
Rocket Software
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Anne & Lynn Wheeler
Sent: Tuesday, March 22, 2011 7:03 AM
To: IBM-...@bama.ua.edu
Subject: Re: "Social Security Confronts IT Obsolescence"
for other drift ... recent thread in (linkedin) Mainframe group about Oracle on zLinux under zVM having bad thruput on "CKD" disks (before moving to non-CKD) ... "CKD" should have been junked several decades ago. misc past posts on the subject:
http://www.garlic.com/~lynn/submain.html#dasd
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
Anne & Lynn Wheeler
> It was. ECKD was announced in the early- to mid-80s, which was 25+
> years ago, which is several decades ago. Not all users respond
> quickly.
re:
http://www.garlic.com/~lynn/2011e.html#31 "Social Security Confronts IT Obsolescence"
oh, the missing linkedin URL reference:
http://lnkd.in/ajGuA2
reference was to "CKD" disks didn't change ... controllers added some
extra stuff (eckd) ... originally for "Calypso" ... the 3880 controller
speed-matching buffer ... allowing 3380/3880 3mbyte connenction to
(370/168 2880) 1.5mbyte channels ... which had enormous problems (that
wouldn't/don't exist w/FBA).
old email discussing calypso (eckd) and how bad the problems were
(several severity ones in the field):
http://www.garlic.com/~lynn/2007e.html#email820907b
above also mentions the dismal prognosis of ever getting MVS to support
FBA (I've periodically mentioned in the past about being told that even
if I provided MVS with fully integrated & tested FBA support, I still
needed $26M business case to cover education and pubs ... and I
couldn't use lifecycle savings ... only incremental new sales).
past posts with references to calypso/eckd:
http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant
http://www.garlic.com/~lynn/2008q.html#40 TOPS-10
http://www.garlic.com/~lynn/2009k.html#44 Z/VM support for FBA devices was Re: z/OS support of HMC's 3270 emulation?
http://www.garlic.com/~lynn/2009p.html#11 Secret Service plans IT reboot
http://www.garlic.com/~lynn/2010e.html#36 What was old is new again (water chilled)
http://www.garlic.com/~lynn/2010h.html#30 45 years of Mainframe
http://www.garlic.com/~lynn/2010n.html#14 Mainframe Slang terms
--
virtualization experience starting Jan1968, online at home since Mar1970
Bill Fairchild
I signed in to LinkedIn and was unable to find the reference, so thanks for including the URL for the missing LinkedIn reference. I read through that reference and saw 16 comments, only one of which mentioned very bad throughput for CKD disks. No technical explanation was given for the bad throughput; i.e., was it hardware limitations in CKD, software limitations in Oracle, etc.? This comment was posted 23 days ago, ca. 28 years after IBM first announced ECKD and forward-thinking users began planning to junk their CKD by going to ECKD.
I remember many problems with ECKD when first implemented, just as there were many problems with OS/360 in the late 1960s, with MVS in the late 1970s, with the new VSAM catalog structure in the early 1980s, etc. But all those problems were addressed, code and hardware were redesigned, etc. I still stand by my earlier post - most users DID junk their CKD several decades ago. Why was this one shop still using CKD 28 years after CKD's replacement first appeared? Is this installation also running with a 28-year-old version of their operating system? I also sent this same question-comment into the LinkedIn thread.
Bill Fairchild
Rocket Software
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Anne & Lynn Wheeler
Anne & Lynn Wheeler
Bi...@MAINSTAR.COM (Bill Fairchild) writes:
> I signed in to LinkedIn and was unable to find the reference, so
> thanks for including the URL for the missing LinkedIn reference. I
> read through that reference and saw 16 comments, only one of which
> mentioned very bad throughput for CKD disks. No technical explanation
> was given for the bad throughput; i.e., was it hardware limitations in
> CKD, software limitations in Oracle, etc.? This comment was posted 23
> days ago, ca. 28 years after IBM first announced ECKD and
> forward-thinking users began planning to junk their CKD by going to
> ECKD.
re:
http://www.garlic.com/~lynn/2011e.html#31 "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#35 junking CKD; was "Social Security Confronts IT Obsolescence"
I'm still waiting for followup ... it says zVM, zLinux and Oracle ...
so presumably it is relatively current hardware, processors, disks,
software, etc. The reference is that bad performance was rectified
moving off CKD to some flavor of FBA (presumably some recent flavor of
ECKD, lots of users may qualify CKD/FBA ... but I can understand lots of
current users not bothering to make the CKD/ECKD distinction; I can't
imagine any existing "z" mainframe with "real" pre-ECKD disks)
That don't mention it as an age or legacy issue ... the zVM & zLinux
aren't that old. There always is some possibility that zVM, zLinux,
and/or current Oracle never bothered to optimize their (e)ckd support as
well as they have FBA.
pure conjecture ... a possible motivation for not bothering with
fine-tuning any (e)ckd support is that these days all (e)ckd devices are
really some form of FBA device with an additional eckd simulation layer
on top. Given native FBA device support ... going directly to the native
FBA device eliminates an extraneous eckd simulation layer (aka for any
eckd device, an equivalent native FBA device could be used w/o the
additional, unnecessary eckd layer).
the ckd/eckd simulation layer continues to live on because MVS (& its
descendants) have been unable to support the native devices.
misc. past posts mentioning fba, ckd, multi-track search, etc
http://www.garlic.com/~lynn/submain.html#dasd
Anne & Lynn Wheeler
> Lynn,
>
> I signed in to LinkedIn and was unable to find the reference, so
> thanks for including the URL for the missing LinkedIn reference. I
> read through that reference and saw 16 comments, only one of which
> mentioned very bad throughput for CKD disks. No technical explanation
> was given for the bad throughput; i.e., was it hardware limitations in
> CKD, software limitations in Oracle, etc.? This comment was posted 23
> days ago, ca. 28 years after IBM first announced ECKD and
> forward-thinking users began planning to junk their CKD by going to
> ECKD.
re:
http://www.garlic.com/~lynn/2011e.html#31 "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#35 junking CKD; was "Social Security Confronts IT Obsolescence"
I'm still waiting for followup ... it says zVM, zLinux and Oracle ...
so presumably it is relatively current hardware, processors, disks,
software, etc. The reference is that bad performance was rectified
moving off CKD to some flavor of FBA (presumably some recent flavor of
ECKD, lots of users may qualify CKD/FBA ... but I can understand lots of
current users not bothering to make the CKD/ECKD distinction; I can't
imagine any existing "z" mainframe with "real" pre-ECKD disks)
That don't mention it as an age or legacy issue ... the zVM & zLinux
aren't that old. There always is some possibility that zVM, zLinux,
and/or current Oracle never bothered to optimize their (e)ckd support as
well as they have FBA.
pure conjecture ... a possible motivation for not bothering with
fine-tuning any (e)ckd support is that these days all (e)ckd devices are
really some form of FBA device with an additional eckd simulation layer
on top. Given native FBA device support ... going directly to the native
FBA device eliminates an extraneous eckd simulation layer (aka for any
eckd device, an equivalent native FBA device could be used w/o the
additional, unnecessary eckd layer).
the ckd/eckd simulation layer continues to live on because MVS (& its
descendants) have been unable to support the native devices.
misc. past posts mentioning fba, ckd, multi-track search, etc
http://www.garlic.com/~lynn/submain.html#dasd
--
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of Anne & Lynn Wheeler
>
> [ snip ]
>
> pure conjecture ... a possible motivation for not bothering with
> fine-tuning any (e)ckd support is that these days all (e)ckd devices
are
> really some form of FBA device with an additional eckd simulation
layer
> on top. Given native FBA device support ... going directly to the
native
> FBA device eliminates an extraneous eckd simulation layer (aka for any
> eckd device, an equivalent native FBA device could be used w/o the
> additional, unnecessary eckd layer).
>
> the ckd/eckd simulation layer continues to live on because MVS (& its
> descendants) have been unable to support the native devices.
"Unable", or "unwilling"? Many of your own posts on the topic suggest
the latter.
-jc-
Ed Gould
From: Bill Fairchild <Bi...@MAINSTAR.COM>
To: IBM-...@bama.ua.edu
Sent: Tue, March 22, 2011 1:28:00 PM
Subject: Re: junking CKD; was "Social Security Confronts IT Obsolescence"
Lyn:
I bow to your expertize and have not read your paper on the 3725.
My sort of well lets say home grown experience with trial and error (sigh a lot
of errorr).
Gut instinct said the limiting factor was the byte channel (which I understood)
was the vast majority of channel hook ups for the box.
My experience later on on the 3745 was that it seemed to perform well as we
really hit it with a *LOT* of data (we essentially ran shadow copy of our system
out to NY from Chicago) through it everynight. We had one nasty bug that turned
out to be non IBM related but that is a different issue.
I do not think we really ever ran into a software issue on the PEP. I didn't
want to run PEP but some of our customers sold the idea to my management over my
strong objections. I wish MVS was as bug free as was PEP (at least for us).
The thing just worked period. That is why I liked it so much.
Ed
Anne & Lynn Wheeler
> Lyn:
>
> I bow to your expertize and have not read your paper on the 3725.
>
> My sort of well lets say home grown experience with trial and error (sigh a lot
> of errorr).
> Gut instinct said the limiting factor was the byte channel (which I understood)
> was the vast majority of channel hook ups for the box.
re:
http://www.garlic.com/~lynn/2011e.html#31 "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#35 junking CKD; was "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#37 junking CKD; was "Social Security Confronts IT Obsolescence"
you must have strayed from the archived ckd/eckd posts into archived
sna/vtam misinformation thread (in a.f.c. newsgroup):
http://www.garlic.com/~lynn/2011e.html#32 SNA/VTAM Misinformation
http://www.garlic.com/~lynn/2011e.html#34 SNA/VTAM Misinformation
the above also references more in (linkedin) "Greater IBM" group thread.
note that in the above ... series/1 NCP emulation involved a channel
interface board that attached to mainframe on same exact channel as 3725
and appeared to the mainframe exactly as a 3725 (slight of hand was that
it told all the mainframes that resources were cross-domain ... "owned"
by somebody else). Since the interface board and channel appeared
identical ... then any related limitation was identical for 3725 and
series/1.
slight topic drift ... long ago and far away ... there was an internal
effort to convince the communication group to use "peachtree" (processor
for series/1) as being significantly more capable than the processor
chosen for 37x5.
additional topic drift ... even longer ago, as undergraduate in the 60s
... i added tty/ascii terminal support to cp67. cp67 had 1052 & 2741
support with fancy automatic terminal recognition ... fancy use of 2702
SAD command to re-associate different line-scanner to port. I then
intergrated TTY/ASCII ... supporting automatic terminal identification
(and re-associating different line-scanner with 2702 SAD command). It
worked fine for leased line ... but i wanted to do single dial-up phone
number (& hunt group) for all dial-up terminals ... where it
broke. While 2702 allowed changing line-scanner on port ... 2702 took
shortcut and hardwired oscillator/line-speed on each port. This was
somewhat the motivation for the univ. to start clone controller project,
reverse engineering mainframe channel interface, building mainframe
channel board for interdata/3 and programming interdate/3 to simulate
2702 ... but also doing automatic line-speed operation. four of us get
written up as being responsible for (some part of) clone controller
business ... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#360pcm
decade or so ago, was in large datacenter with a many generation
descendent of that box handling large percentage of dial-up POS
cardswipe terminals in the country ... claim was that the channel
interface board hadn't changed ... although it was a many times
descendent of interdate/3 (including name change when perkin/elmer
bought interdata).
Anne & Lynn Wheeler
> Lyn:
>
> I bow to your expertize and have not read your paper on the 3725.
>
> My sort of well lets say home grown experience with trial and error (sigh a lot
> of errorr).
> Gut instinct said the limiting factor was the byte channel (which I understood)
> was the vast majority of channel hook ups for the box.
re:
--
virtualization experience starting Jan1968, online at home since Mar1970
----------------------------------------------------------------------
McKown, John
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Chase, John
> Sent: Tuesday, March 22, 2011 2:36 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: junking CKD; was "Social Security Confronts IT
> Obsolescence"
>
Anne & Lynn Wheeler
> Perhaps "not financially viable". "We" complain about how much z/OS
> costs right now. Imagine the howls of rage if IBM were to increase the
> cost of z/OS by 10% (to pick a round, random, number) and say that it
> was to allow z/OS to use FBA devices. PDSes are a integral part of
> z/OS (like it or not). Many people still dislike PDSEs. PDSs can't
> exist without CKD. So to go "pure" FBA (to remove the dependency on
> ECKD) would require a huge investment. Now, to add FBA support for
> access methods which are inherently FBA compatible (VSAM et al.) would
> likely be easier.
as I've mentioned a number of times before ... long ago and far away the
group told me that even if I provided them fully integrated and tested
FBA support ... I still needed a $26M business case to cover training
and documentation ... and I could only use incremental new sales in the
business case (say $200M-$300M additional disk sales) ... and wasn't
able to use life-cycle cost savings (that were enormous ... both for the
company as well as customers ... totally dwarfing everything
else). misc. past posts mentioning ckd, fba, multi-track search, etc
http://www.garlic.com/~lynn/submain.html#dasd
recent "MVM" thread ... from the definition in IBM Jargon as the
original name for MVS, there was an enormous simulation layer added
going from MVT to OS/VS2 ... basically, initially CCWTRANS was imported
from CP67 (virtual machine vm370 percusor on 360/67)into EXCP processing
which had to scan the passed channel program and build a duplicate with
real addresses for execution.
http://www.garlic.com/~lynn/2011d.html#71 Multiple Virtual Memory
http://www.garlic.com/~lynn/2011d.html#72 Multiple Virtual Memory
http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory
Now since all the "real" CKD disks have been FBA for a long time, then
for decades, there has been a fairly large simulation layer (in the
controller) that takes channel programs and perform emulated CKD
function. There is roughly equivalent in various of the 370 simulators
that run on intel & other platforms, with their own software layer
simulating CKD function on FBA devices.
So possible transition phase (decades ago) would have been to enhance
official access methods to support native FBA ... ... and then include
a multi-track search emulation layer in the EXCP channel program
translation ... doing the same exact function currently performed in the
lower layers, since *ALL* disks have been native *FBA* for some time
(somebody has to be doing all that simulation). That would go a long way
to accelerating weaning the dependency off multi-track search.
--
virtualization experience starting Jan1968, online at home since Mar1970
----------------------------------------------------------------------
Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2011e.html#31 "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#35 junking CKD; was "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#37 junking CKD; was "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#43 junking CKD; was "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#44 junking CKD; was "Social Security Confronts IT Obsolescence"
there is also some possibility that the opposition to my providing FBA
support was simply POK favorite son operating system campaign against
me.
after transferring to the west coast, they let me wander around and get
into trouble. In the disk development and test labs (bldg. 14 & 15 on
san jose plant site) ... they were doing stand-alone, dedicated time,
around the clock, 7x24 scheduled testings. They mentioned that they had
tried MVS ... hoping to do multiple concurrent testing in operating
system enviornment ... but even with just a single 'testcell"
(development device), MVS had 15min MTBF.
I offerred to redo IOS to make it absolute bullet proof & never fail
... providing them with multiple concurrent, "on-demand" testing
(significantly increasing development productivity since they now could
test anytime they needed w/o having to wait for scheduled, dedicated
time). I did an internal report on many of the items which happened to
make passing reference to the MVS 15min MTBF.
I was then called by somebody from the POK favorite son operating system
... and foolish me, I thot it was going to be about getting all the
enhances incorporated, but they were bringing down their forces on my
head ... wanting to know who my manager was ... and trying to make sure
I never mentioned anything about them again (preferrably even no longer
being an employee).
Ferguson & Morris 1993 book describes that in the wake of FS failure,
the corporate culture had been replaced with sycophancy and "make no
waves" ... or in Boyd terms having to make a career choice between "To
Be or To Do" ... from dedication of Boyd Hall at Air Force Weapons
School, 17Sep1999 ... reference
http://www.garlic.com/~lynn/2000e.html#35
This is discussed recently in (linkedin) former/current IBM group ... in
IBM Jargon definition of "fast track" (sub)thread:
http://www.garlic.com/~lynn/2011d.html#12 I actually miss working at IBM
http://www.garlic.com/~lynn/2011d.html#13 I actually miss working at IBM
http://www.garlic.com/~lynn/2011d.html#15 I actually miss working at IBM
http://www.garlic.com/~lynn/2011d.html#16 I actually miss working at IBM
http://www.garlic.com/~lynn/2011d.html#78 I actually miss working at IBM
http://www.garlic.com/~lynn/2011e.html#7 I actually miss working at IBM
http://www.garlic.com/~lynn/2011e.html#9 I actually miss working at IBM
since they were already doing their worst ... it didn't matter later,
related to 3380 ship (had been announced Jun80) ... I send email about
standard collection of error tests (to be expected at customers) ...
MVS was failing in all cases & in 2/3rds of the cases, there was no
indication of what forced the re-ipl ... old email:
http://www.garlic.com/~lynn/2007.html#email801015
misc. past posts getting to play disk engineer in bldgs 14&15 (which
still exist at the plant site, although many others have been plowed
under)
http://www.garlic.com/~lynn/subtopic.html#disk
... footnote ... I had sponsored Boyd's briefings at IBM ... misc.
past posts
http://www.garlic.com/~lynn/subboyd.html
--
virtualization experience starting Jan1968, online at home since Mar1970
----------------------------------------------------------------------
Elardus Engelbrecht
>I was then called by somebody from the POK favorite son operating system
'son operating system' ?????
Uhhhh, I may be a dumb <excrement> ( :-D ), but please excuse my
ignorance, but what is that?
(I certainly know what is POK)
Groete / Greetings
Elardus Engelbrecht
Bill Fairchild
Bill Fairchild
Rocket Software
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Elardus Engelbrecht
Sent: Wednesday, March 23, 2011 12:57 PM
To: IBM-...@bama.ua.edu
Anne & Lynn Wheeler
> It was. ECKD was announced in the early- to mid-80s, which was 25+
> years ago, which is several decades ago. Not all users respond
> quickly.
as expected ... they were using "eckd" ... and just not bothering to
fully qualify ... since the transition occured so many decades ago ...
it possibly appeared superfluous at this point for the distinction
(unless in legacy discussion that specifically is about differences).
past posts in thread:
http://www.garlic.com/~lynn/2011e.html#31 "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#35 junking CKD; was "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#37 junking CKD; was "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#43 junking CKD; was "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#44 junking CKD; was "Social Security Confronts IT Obsolescence"
http://www.garlic.com/~lynn/2011e.html#45 junking CKD; was "Social Security Confronts IT Obsolescence"
--
virtualization experience starting Jan1968, online at home since Mar1970
----------------------------------------------------------------------
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht
>
> Anne & Lynn Wheeler wrote:
> >I was then called by somebody from the POK favorite son operating
system
>
> 'son operating system' ?????
>
> Uhhhh, I may be a dumb <excrement> ( :-D ), but please excuse my
> ignorance, but what is that?
>
> (I certainly know what is POK)
Actually, it's "favorite son" operating system; as in "most favored" or
"takes precedence over all others" or "gets all the attention". Might
also be an oblique reference to the dead "Future System" that was to be
the "be all and end all" of operating systems.
-jc-
Shmuel Metz , Seymour J.
on 03/23/2011
at 07:04 AM, "McKown, John" <John....@HEALTHMARKETS.COM> said:
>PDSs can't exist without CKD.
Neither can PS. But why can't something exist on FBA that looks to the
programmer like PO and PS?
BTW, TSS/360 managed to provide PDS[1] functionality on page-formatted
volumes almost half a century ago.
[1] Only better.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Shmuel Metz , Seymour J.
<77142D37C0C3C34DA0D7...@nwt-s-mbx2.rocketsoftware.com>,
on 03/22/2011
at 06:28 PM, Bill Fairchild <Bi...@MAINSTAR.COM> said:
>most users DID junk their CKD several decades ago.
ECKD is still CKD format. Only VM and VSE users had the option to
ditch it; MVS users are still stuck with it.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Anne & Lynn Wheeler
> Actually, it's "favorite son" operating system; as in "most favored"
> or "takes precedence over all others" or "gets all the attention".
> Might also be an oblique reference to the dead "Future System" that
> was to be the "be all and end all" of operating systems.
re:
http://www.garlic.com/~lynn/2011e.html#45 junking CKD; was "Social Security Confronts IT Obsolescence"
in the wake of FS demise ... there was mad rush to get stuff back into
the 370 hardware & software product pipelines (there are claims that the
distraction of FS allowed clone processors to gain market foothold)
... doing 303x (3031 was 158, 3032 was 168, 3033 started out 168
wiring/layout with faster chips) in parallel with 370/xa ... some
discussion of FS, 303x, and 3081
http://www.jfsowa.com/computer/memo125.htm
POK managed to convince corporate to kill vm370, shutdown the vm370
development group and move all the people to pok to support mvs/xa
development (or otherwise mvs/xa wouldn't be able to meet ship
schedule). Endicott managed to save vm370 product mission ... but had to
reconstitute a development group from scratch.
The shutdown strategy for the vm370 product group was to not inform them
until the very last possible minute ... minimizing the number of people
that might find something else. The information was leaked ... resulting
in witch hunt to find the person responsible (extremely paranoid
atmosphere in the bldg. during that period). There was joke about the
head of POK was major contributor to vax/vms ... because so many of the
development group went to work on vms.
the MVM upthread historical reference:
http://www.garlic.com/~lynn/2011d.html#73
has os/vs2 release 1 (SVS) plus delta for os/vs2 release 2 (MVS) on
"glide path" to os/vs2 release 3 (FS). Also mentioned, simpson (from
hasp, aka jes2) did RASP ... basically paged-mapped MFT. He then left,
and was redoing RASP from scratch (in clean room), at Amdahl.
as an aside ... one of the "nails" in the FS coffin was that if ACP
(TPF) were run on FS machine built out of the fastest circuits then
available (370/195) it would have the throughput of 370/145 ... 1/20 to
1/30 the thruput of eastern acp/SystemOne (on 370/195).
misc. past posts mentioning ckd, fba, multi-track search
http://www.garlic.com/~lynn/submain.html#dasd
misc. past posts mentioning FS
http://www.garlic.com/~lynn/submain.html#futuresys
another FS reference:
http://www.cs.clemson.edu/~mark/fs.html
--
virtualization experience starting Jan1968, online at home since Mar1970
----------------------------------------------------------------------
Elardus Engelbrecht
Thanks to all who cared to educate me. That will teach me a good lesson! ;-)
Yeah, if I am not learning something new now and then, I should retire... :-D
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 10:33 PM, Anne & Lynn Wheeler <ly...@GARLIC.COM> said:
>in the wake of FS demise
Parenthetical note. The Hebrew word 'efes means "nothing"; when I
first heard for Future Systems, I thought the acronym FS to be
extremely humorous; I didn't realize that it was also prophetic.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Anne & Lynn Wheeler
> Parenthetical note. The Hebrew word 'efes means "nothing"; when I
> first heard for Future Systems, I thought the acronym FS to be
> extremely humorous; I didn't realize that it was also prophetic.
from long ago and far away, IBM Jargon:
FS - n. Future System. A synonym for dreams that didn't come true.
That project will be another FS. Note that FS is also the
abbreviation for functionally stabilized, and, in Hebrew, means zero,
or nothing. Also known as False Start, etc.
... snip ...
I have a random signature setting that I periodically turn on ...
randomly selects an entry from one of three randomly selected files ...
IBMJARGON, 6670 sayings (file of quotations, we had modified the 6670
print driver to include random selection for output on the separator
page), and zippy the pin head.
Anne & Lynn Wheeler
FS - n. Future System. A synonym for dreams that didn't come true.
That project will be another FS. Note that FS is also the
abbreviation for functionally stabilized, and, in Hebrew, means zero,
or nothing. Also known as False Start, etc.
... snip ...
I have a random signature setting that I periodically turn on ...
randomly selects an entry from one of three randomly selected files ...
IBMJARGON, 6670 sayings (file of quotations, we had modified the 6670
print driver to include random selection for output on the separator
page), and zippy the pin head.
--
virtualization experience starting Jan1968, online at home since Mar1970
----------------------------------------------------------------------