Homework: Negative side of MVS?
Date: Thu, 13 Jan 2000 23:20:14 -0600
From: David Alcock
Organization: The Internet Connection - ticnet.com (using Airnews.net!)
Subject: Homework: Negative side of MVS?
Because I have a MVS web site I often get email like the following:
> I am writing a paper for a class on MVS. I am suppose to do a
> "pro and con" type paper. I can find info on the positive side
> of MVS, yet I am having a hard time finding info on the negative
> side of the OS. Any help would be appreciated.
>
> Thanks, Charles - louis@en.com
Anybody want to help this guy out with his homework? I almost hate to
give him any ammunition.
Date: Fri, 14 Jan 2000 13:20:11 +0800
From: "Ambat, Ravi Nair (SG-SGO)"
Subject: Re: Homework: Negative side of MVS?
positive side:
1. it's fun
2. no blue-screen-of-death
- ravi.
Date: Fri, 14 Jan 2000 07:14:18 -0600
From: Rick Fochtman
Organization: Board of Trade Clearing Corporation
Subject: Re: Homework: Negative side of MVS?
1. Complexity of overall system.
2. DASD Space requirements (still trivial compared to M$ Windoze)
PRO:
1. Diversity. MVS can serve the broadest community of users, with a wide
spectrum of features and capabilities.
2. Reliability. As was previously stated, "No blue screen of death."
3. Serviceability. Modularity and excellent tracking mechanisms make
service relatively easy and conflict-free.
4. Security. Ever hear of a mainframe being infected by a Web virus? Or a
Hacker breaking into a mainframe and wreaking havoc? Granted, it COULD
happen, but MVS security can prevent it better than any other platform in
common use today.
5. Support. The MVS support team in a particular shop can be fairly small
and still function very well because of the support structures within IBM,
as well as groups like this one, IBM-MAIN, where we can share experiences
and knowledge and help each other out. The "Old Boy Network" is alive, well
and highly functional, in spite of occaissional lapses when we "wax
historical".
Con:
1. Complexity. To become a true MVS "System Programmer" takes years of
training, learning and experience. And lots of mistakes along the way.
2. Size. MVS DASD space requirements aren't trivial, between the code,
page space, catalogs, security databases, spools, etc.
3. Cost. Byte-for-byte, MVS is still far and away the biggest bang for the
buck, but a full-blown MVS system with a reasonable number of bells and
whistles can still add up to some serious dollars. Businesses will pay
those dollars because of the function they're buying, but it's still a
consideration.
Date: Fri, 14 Jan 2000 14:32:24 +0100
From: "Yera Fachal, Ignacio"
Subject: Re: Homework: Negative side of MVS?
MVSs costs are very low compared to Windows's.
(at equal performance, including software and hardware,
storage,maintenance, people... costs, especialy
money we lose when NT servers hang)
When was working with NT I thought that MVS's cost were
much more than what rearly are.
I know what I'm talking about (looking at real numbers).
---------------------------------------------------------------
Nacho Yera
Microsoft Certified Systems Engineer
Softgal, Servicios de Software de Galicia.
http://www.softgal.com
Date: Fri, 14 Jan 2000 14:51:29 +0000
From: Simon Wheeler
Subject: Re: Homework: Negative side of MVS?
Hi,
I'd certainly agree with what's been said so far, but I think aside from the
technical issues, MVS has/had an image problem. I'm sure many people have had to
deal with the "I didn't think any one used mainframes any more" comments, but
with the changes to the OS and morphing into OS/390, all close to the coal face
know that things are looking healthy.
I'm sure there are loads of managers that have discovered the hard way that
centralisation around the OS/390 server is often the best option in large
organisations.
Cheers,
Simon Wheeler
Date: Fri, 14 Jan 2000 07:30:31 -0800
From: Bill Becker
Subject: Re: Homework: Negative side of MVS?
I think he answered his own question. There really isn't
anything negative one can say?
Kind of goes along with a bumper sticker I have:
"IMS - The world Depends on It!"
Date: Fri, 14 Jan 2000 15:37:12 +0000
From: John Cousins
Subject: Homework: Negative side of MVS? -Reply
Hi
There must have been numerous arguments against MVS
relevent to the situation at the end of the 1980's, such as:
hardware/software costs(Unix boxes were small and cheap),
complexity of software(Unix had nothing like the richness of
MVS and therefore was simple & unreliable).
Cost of hardware meant that IT departments were
centralised (Unix boxes were cheap could be installed in
office environment and could be purchased away from the
control of IT managers, so every department in the
corporation could have its own IT section, and suddenly
become IT experts)
no open communications (unlike Unix with TCP/IP).
large IT departments were slow to respond to the
requirements of the end-user (with a Unix box in your office
and salesman selling you cheap packages, who needs an IT
department?)
In the UK, training on mainframes was provided by
IBM/Amdahl/etc. at a high cost to the users (unlike Unix
training, which was provided by all the Universities who
spewed out spotty techies in droves, and were cheap to
hire).
I think the damage has been done, IBM have changed the
mainframe beyond all recognition, and argue for its
reliability, scalability and availability, but I think IBM have
forgotten about the loss of skills in IT departments since the
Unix explosion. There are a few voices in the wilderness who
can remember how to run a tight IT department (with skills
like change control, capacity planning, performance
management) but who listens any more?
have a good week-end....
John Cousins, Bristol, England
Date: Fri, 14 Jan 2000 10:48:15 -0500
From: "Bentley, Richard J"
Subject: Re: Homework: Negative side of MVS? -Reply
I agree. I have been in the IT field for about 20 years and in the last 7-8
years I have tried to find a Assembler course to no avail. The assembler I
know is just what I've had to learn on my own. Any one out there that knows
of a basic class being offered.
Rick
Date: Fri, 14 Jan 2000 09:58:20 -0600
From: "Cox, Steve"
Subject: Re: Homework: Negative side of MVS?
OS/390 has a very difficult user interface, almost as bad as the UNIX
interface. It is still largely command driven and the commands are
frequently unusual abbreviations of the command name. While there has
been an attempt to layer "fill-in-the-blank" panels over the commands, these
panels are quirky and idiosyncratic.
This is a very real negative issue for occasional users of OS/390.
Date: Fri, 14 Jan 2000 10:48:15 +0100
From: FALISSARD
Organization: etic
Subject: Re: Homework: Negative side of MVS?
I don't know of any negative side of MVS, except
there is no mouse to play with... (this is why my son,
age 6, does not like MVS).
@ < http://os390-mvs.hypermart.net >
@ ("Is there life after MVS ?")
Date: Fri, 14 Jan 2000 09:02:26 -0700
From: Richard Combest
Subject: Re: Homework: Negative side of MVS?
would not an occasional user of ANY OS have difficulty? i wouldn't consider
that negative.
-----Original Message-----
From: Cox, Steve [mailto:Steve_Cox@BMC.COM]
Sent: Friday, January 14, 2000 8:58 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Homework: Negative side of MVS?
OS/390 has a very difficult user interface, almost as bad as the UNIX
interface. It is still largely command driven and the commands are
frequently unusual abbreviations of the command name. While there has
been an attempt to layer "fill-in-the-blank" panels over the commands, these
panels are quirky and idiosyncratic.
This is a very real negative issue for occasional users of OS/390.
Date: Fri, 14 Jan 2000 09:17:50 -0700
From: Bruce Baumgart
Subject: Re: Homework: Negative side of MVS?
In-Reply-To:
At 09:58 AM 01/14/2000 -0600, "Cox, Steve" wrote:
>OS/390 has a very difficult user interface, almost as bad as the UNIX
>interface. It is still largely command driven and the commands are
>frequently unusual abbreviations of the command name. While there has
>been an attempt to layer "fill-in-the-blank" panels over the commands, these
>panels are quirky and idiosyncratic.
>This is a very real negative issue for occasional users of OS/390.
>
Except that I don't believe that there are occasional users of OS/390
that would be at the TSO/E or CICS command line level. If the panel-entry
type applications are quirky and idiosyncratic, that's a fault of the
developers, not the operating system. I believe that the lack of some
of the windows (note lower-case, also refering to *nix full screen stuff)
features; cut-and-paste,drag-n-drop,window scrolling,etc; is a big part
of the problem.
--
Bruce Baumgart This space intentionally left blank.
Bechtel BWXT Idaho, LLC
Date: Fri, 14 Jan 2000 11:15:00 -0500
From: Bob Young
Subject: Assembler Class (Was: Homework: Negative side of MVS?
Comments: To: "Bentley; Richard J"
IBM Education offers "Assembler Language Coding Workshop [K3600]". Go to
http://www-3.ibm.com/services/learning/us/ and search on k3600 for details.
Bob Young
Capital One Open Systems Technical Support
Internal Zip 12036-0150
4871 Cox Rd.
Glen Allen, VA 23060 USA
Tel: 804-968-2348
mailto:bob.young@capitalone.com
Date: Fri, 14 Jan 2000 11:18:51 -0500
From: Scott Harder
Subject: Re: Homework: Negative side of MVS?
I love all these responses, but why not reply to the kid with the homework
assignment:
Charles - louis@en.com
Date: Fri, 14 Jan 2000 11:23:46 -0500
From: Jim Harrison
Subject: Re: Homework: Negative side of MVS? -Reply
Your best bet is to check your local community colleges. IBM has a page
listing colleges it knows about that teach mainframe courses:
http://www.s390.ibm.com/education/schools.html
I'm sure there are others not listed as I think our local CC is still
teaching COBOL but I didn't see Assembler listed.
At 10:48 AM 1/14/00 -0500, you wrote:
>I agree. I have been in the IT field for about 20 years and in the last 7-8
>years I have tried to find a Assembler course to no avail. The assembler I
>know is just what I've had to learn on my own. Any one out there that knows
>of a basic class being offered.
>Rick
Date: Fri, 14 Jan 2000 10:23:15 -0600
From: "Cox, Steve"
Subject: Re: Homework: Negative side of MVS?
Well, I would say that Mac, Next, and Windows are all designed to help you
do "occasional" tasks. MVS and UNIX aren't. They're definitely oriented
towards the power user. I do consider it a negative thing since we live in
a time in which the casual user of an operating system is becoming more
common.
-----Original Message-----
From: Richard Combest [mailto:Richard.Combest@CSDINC.COM]
Sent: Friday, January 14, 2000 11:02 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Homework: Negative side of MVS?
would not an occasional user of ANY OS have difficulty? i wouldn't consider
that negative.
Date: Fri, 14 Jan 2000 16:28:06 -0000
From: "Griffin, John (London)"
Subject: Re: Homework: Negative side of MVS? -Reply
I did a beginners assembler course about3-4 years ago and the
advanced one more recently. Both were provided by Amdahl, I believe they are
still doing them.
Kind Regards
John Griffin (MVS Systems Programmer)
Tel : (W) - 0171-867-2709
(M) - 0468-557781
Email : J_Griffin@ML.COM
Date: Fri, 14 Jan 2000 11:33:59 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
De gustibus non disputandem est! I haven't used Next, but I have used Mac
and 'doze, and saw no signs that either was designed to help the occasional
user. Each has nasty surprises for the user who is not already familiar with
their idiosyncrasies, and sometimes even has ugly surprises for the power
user.
As to Eunix , I'd have to ask "What is Unix?" Certainly the Unix CLI is
almost as intimidating to newbies as the 'doze Registry, but are GNOME, KDE
or MOTIF not just as suitable to the casual user as 'doze or the Mac?
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Cox, Steve [SMTP:Steve_Cox@BMC.COM]
> Sent: Friday, January 14, 2000 11:23 AM
>
> Well, I would say that Mac, Next, and Windows are all designed to help you
> do "occasional" tasks.
Date: Fri, 14 Jan 2000 10:36:10 -0600
From: "Cox, Steve"
Subject: Re: Homework: Negative side of MVS?
You may not believe in them, but I was surrounded by about twenty of them on
my last job. Extremely well educated, competent software engineers who were
trying to port Oracle/Sybase/SQL Server code to work on DB2 in a shop with
UNIX, Linux, AIX, MVS, and NT. I actually had an easier time with UNIX than
they did with MVS.
Yes, the panels are layered on by the applications. It's a shame that
OS/390 doesn't have a native interface something like the AS/400 does.
Date: Fri, 14 Jan 2000 09:45:55 -0700
From: Bruce Baumgart
Subject: Re: Homework: Negative side of MVS?
In-Reply-To:
At 10:36 AM 01/14/2000 -0600, you wrote:
>
>Yes, the panels are layered on by the applications. It's a shame that
>OS/390 doesn't have a native interface something like the AS/400 does.
>
It does, ISPF :)
(We're talking OS/390, not MVS)
--
Bruce Baumgart This space intentionally left blank.
Bechtel BWXT Idaho, LLC
Date: Fri, 14 Jan 2000 10:48:42 -0600
From: "McKown, John"
Subject: Re: Homework: Negative side of MVS?
[McKown, John] The negative side of MVS? It doesn't crash. This
means that you must actually plan and schedule installation of fixes to the
base system. You can't just stage them and then "wait for the daily reboot"
. Getting time to install new system level software (if it requires an
IPL), is a real pain. For some reason, businesses which will endure a 24
hour outage on a production NT server (which disables all corporate email)
will scream like a gut shot panther if you want to just reIPL a 24x7 OS/390
system running 200 production CICS regions.
Installing and maintaining MVS requires knowledge. You can't just
put in a CD and have it autoconfigure and start running. Granted, the
current OS/390 installation by IBM is almost that easy. This means that you
can't hire a teenager off the street, but must find and pay for some
relatively expensive, knowledgeable people.
You must know how big your files are likely to be. On a PC (and
UNIX), a file can grow until it eats up an entire partition/filesystem.
Under MVS, you get x37 abends. Again, recent advances in OS/390 and other
products such as STOPX37 (Pro:SMS) help address this issue.
Batch JCL stinks compared even to simple BAT files. Compared to UNIX
shell scripts, it really stinks! Of course, you could, in theory, rewrite
your JCL into REXX. But then the automated job restart products won't work
.
Worst drawback? Cost. Although the TCO of OS/390 is very low
per-user, the absolute cost for even a small production OS/390 system is
quite high. So, if you're not going to have a 100+ users, it just won't be
cost-effective. I'm speaking mainly of software costs. Especially for some
software companies whom I will NOT name.
Date: Fri, 14 Jan 2000 11:54:46 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
I beg to differ. Have you ever had to use BAT? Admittedly OS/360 JCL is
still ugly in its OS/390 incarnation, but at least it can handle keyword
parameters. The first time that I saw BAT, I though that I had been
kidnapped by a time traveler and taken into the 16th Century :-(
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: McKown, John [SMTP:JMckown@INSURDATA.COM]
> Sent: Friday, January 14, 2000 11:49 AM
>
> Batch JCL stinks compared even to simple BAT files.
Date: Fri, 14 Jan 2000 11:36:55 -0500
From: Jon Brock
Subject: Re: Homework: Negative side of MVS?
<< Yes, the panels are layered on by the applications. It's a shame that
OS/390 doesn't have a native interface something like the AS/400 does.>>
I could buy that if you end the sentence after the word "interface."
Jon
Date: Fri, 14 Jan 2000 17:31:30 GMT
From: Sipho Gumede
Subject: Re: Homework: Negative side of MVS?
Negative side of MVS? Having to deal with ISVs.
Sipho
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Date: Fri, 14 Jan 2000 12:28:24 -0600
From: "Miller, Pat"
Subject: Re: Homework: Negative side of MVS?
I'm dumbfounded that no one has mentioned that artificial 16MB boundary.
Granted it's been quite a while since IBM came up with a "work around," but
it still causes plenty of headaches now and then. Tried running transaction
isolation in a shop with a lot of legacy COBOL apps? Not to mention that
it's nothing less than embarrassing to explain to anyone unfamiliar with
S/390 architecture.
-----Original Message-----
From: Sipho Gumede [mailto:sgumede@HOTMAIL.COM]
Sent: Friday, January 14, 2000 11:32 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Homework: Negative side of MVS?
Negative side of MVS? Having to deal with ISVs.
Sipho
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Date: Fri, 14 Jan 2000 12:38:27 -0600
From: "Chase, John"
Subject: Re: Homework: Negative side of MVS?
On Friday, January 14, 2000 12:28 PM, Miller, Pat
[SMTP:Pat.Miller@TRS.STATE.TX.US] wrote:
> I'm dumbfounded that no one has mentioned that artificial 16MB boundary.
> Granted it's been quite a while since IBM came up with a "work around,"
> but it still causes plenty of headaches now and then. Tried running
> transaction isolation in a shop with a lot of legacy COBOL apps? Not to
mention
> that it's nothing less than embarrassing to explain to anyone unfamiliar
with
> S/390 architecture.
How/why is it embarrassing to explain why operating system upgrades usually
don't "break" applications?
-jc-
Date: Fri, 14 Jan 2000 19:41:20 +0100
From: Richard Lazar
Subject: Re: Homework: Negative side of MVS?
Do you mean OS/VS COBOL ?
Migrate to COBOL-II, set Options RENT,DATA(31) and don't call any AMODE(24)
progam.
What is a 16 MB boundary ? ;-)
> Von: Miller, Pat [SMTP:Pat.Miller@TRS.STATE.TX.US]
> Gesendet am: Freitag, 14. Januar 2000 19:28
> An: IBM-MAIN@BAMA.UA.EDU
> Betreff: Re: Homework: Negative side of MVS?
>
> > I'm dumbfounded that no one has mentioned that artificial 16MB boundary.
> > ....
> > Tried running transaction isolation in a shop with a lot of legacy COBOL
> apps?
>
Date: Fri, 14 Jan 2000 12:46:19 -0600
From: "William M. Klein"
Subject: Re: Homework: Negative side of MVS?
Could the comment about 16MB be assuming that this is asking about the
problems with "MVS" (aka MVS/SP) - NOT MVS/XA or MVS/ESA or OS/390? If that
is the case, then there really is a 16MB "issue" with MVS.
After all, some of us on this list are "old enough" to remember
"when MVS was MVS"
Bill Klein
wmklein ix.netcom.com
Date: Fri, 14 Jan 2000 13:57:37 -0500
From: "Sawyer, Gregg"
Subject: Re: Homework: Negative side of MVS?
Prompts me to forward a question from a friend, seeking the official
definition of "MVS" vis-a-vis "OS/390". I've been around long enough to
remember SP, but even IBM seem to be confused about the distinction.
Anyone want to take a shot?
On the original question, EBCDIC springs to mind as an undesirable feature,
albeit minor and technical. Aside from the proprietary issue, it is just
more awkward than ASCII (e.g. discontinuous alphabet codes).
Gregg
-----Original Message-----
Sent: Friday, January 14, 2000 1:46 PM
Could the comment about 16MB be assuming that this is asking about the
problems with "MVS" (aka MVS/SP) - NOT MVS/XA or MVS/ESA or OS/390? If that
is the case, then there really is a 16MB "issue" with MVS.
After all, some of us on this list are "old enough" to remember
"when MVS was MVS"
Bill Klein
wmklein ix.netcom.com
Date: Fri, 14 Jan 2000 13:01:24 -0600
From: "Miller, Pat"
Subject: Re: Homework: Negative side of MVS?
Whether you're running MVS/SE, SP, XA, ESA, or Os/390, the 16MB line is
still there. Otherwise why does virtually every area or control block have
one piece below the line and an "extension" above it?
Date: Fri, 14 Jan 2000 13:23:42 -0600
From: "Edward(Ed) J. Finnell, III"
Organization: Seebeck Computer Center
Subject: Re: Homework: Negative side of MVS?
In-Reply-To:
Some of us are old to enough to remember when Bill Gates said "I
can't see why anybody would need more than 640K!"
Edward(Ed) J. Finnell, III
Enterprise Systems/Proj. Mgr.
url:www.ua.edu
Date: Fri, 14 Jan 2000 14:27:06 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
Do you mean that 'dpze NT won't load in 640KB? I loaded OS/360 MVT in less
memory than that!
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Edward(Ed) J. Finnell, III [SMTP:efinnell@SEEBECK.UA.EDU]
> Sent: Friday, January 14, 2000 2:24 PM
>
> Some of us are old to enough to remember when Bill Gates said "I
> can't see why anybody would need more than 640K!"
> Edward(Ed) J. Finnell, III
> Enterprise Systems/Proj. Mgr.
> url:www.ua.edu
Date: Fri, 14 Jan 2000 13:51:53 -0500
From: James Antognini
Organization: IBM Global Services North -- Burlington, Vermont, USA
Subject: Re: Homework: Negative side of MVS?
Oh? In my book, disabled wait state = BSOD.
--
James Antognini
IBM Watson Research
Date: Fri, 14 Jan 2000 13:49:33 -0500
From: James Antognini
Organization: IBM Global Services North -- Burlington, Vermont, USA
Subject: Re: Homework: Negative side of MVS? -Reply
There simply isn't much demand for Assembler. That is true of the x86 world,
too.
By the way, if you know S/390 Assembler basics, "Advanced Asssembler Language
and MVS Interfaces," second editon, by Carmine A Canntello, Wiley, 1999, covers
a lot of systems-programming ground.
--
James Antognini
IBM Watson Research
Date: Fri, 14 Jan 2000 14:25:03 -0500
From: Gilbert Saint-flour
Subject: Re: Homework: Negative side of MVS?
In-Reply-To: <0058222C20AAD3118B6D0008C75631193E9A2B@mail.trs.state.tx.us>
On 14 Jan 2000 at 13:01, "Miller, Pat" said:
>Whether you're running MVS/SE, SP, XA, ESA, or Os/390, the 16MB line is
>still there.
Of course, it's there, just like the 640k line is there in Windows when
you run DOS applications. For over 15 years, IBM has provided ways to
render the 16MB line invisible to most applications; installations which
elect to keep on using 1970s compilers shouldn't complain about it.
>Otherwise why does virtually every area or control block
>have one piece below the line and an "extension" above it?
It's there for compatibility with the older releases of the OS; this is a
mixed blessing, but IMHO, it's more of a blessing than a curse. Can you
imagine the uproar if the 16MB all of a sudden disappeared?
Gilbert Saint-flour
http://members.home.net/gsf/
Date: Fri, 14 Jan 2000 13:34:10 -0600
From: "Chase, John"
Subject: Re: Homework: Negative side of MVS?
On Friday, January 14, 2000 1:27 PM, Metz, Seymour [SMTP:smetz@NSF.GOV]
wrote:
> Do you mean that 'dpze NT won't load in 640KB?
Load?? Shewt, that's not even enough space for it to *laugh* at you!
-jc-
Date: Fri, 14 Jan 2000 13:36:08 -0600
From: "Chase, John"
Subject: Re: Homework: Negative side of MVS?
On Friday, January 14, 2000 12:52 PM, James Antognini
[SMTP:antognini@US.IBM.COM] wrote:
> Oh? In my book, disabled wait state = BSOD.
Yeah, but I can count the number of DWS I've seen in the past three years on
one finger. ;-)
-jc-
Date: Fri, 14 Jan 2000 14:37:13 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
I believe that the original point was that there was no excuse or the line
in the first place; by the time the S/360 was designed it was obvious to
anyone without blinders that memory prices were falling and that 24 bits
wouldn't be adequate for long. The same thing applies to the use of real
addresses; all of the major competitors had at least block relocation and
some had paging.
BTW, I was horrified when I saw a draft first edition of S/360 PoOps; I felt
that it lacked vision, and, IMHO, subsequent events have shown my reaction
to have been correct.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Gilbert Saint-flour [SMTP:gsf@IBM.NET]
> Sent: Friday, January 14, 2000 2:25 PM
>
> Of course, it's there, just like the 640k line is there in Windows when
> you run DOS applications. For over 15 years, IBM has provided ways to
> render the 16MB line invisible to most applications; installations which
> elect to keep on using 1970s compilers shouldn't complain about it.
Date: Fri, 14 Jan 2000 14:36:38 -0500
From: Zoltan Forray
Subject: Re: Homework: Negative side of MVS?
In-Reply-To: <200001141923.NAA27198@bama.ua.edu>
There is another quote he made, when refering to OS/2. Something about folks
not wanting a PC that took 2-3 minutes to boot.
Anyone timed W98 or NT bootup lately ?
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@BAMA.UA.EDU]On
> Behalf Of Edward(Ed) J. Finnell, III
> Sent: Friday, January 14, 2000 2:24 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Homework: Negative side of MVS?
>
>
> Some of us are old to enough to remember when Bill Gates said "I
> can't see why anybody would need more than 640K!"
> Edward(Ed) J. Finnell, III
> Enterprise Systems/Proj. Mgr.
> url:www.ua.edu
>
Date: Fri, 14 Jan 2000 14:38:37 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
"Humor is such a subjective thing!" That was my point.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Chase, John [SMTP:jchase@USSCO.COM]
> Sent: Friday, January 14, 2000 2:34 PM
>
> On Friday, January 14, 2000 1:27 PM, Metz, Seymour [SMTP:smetz@NSF.GOV]
> wrote:
> > Do you mean that 'dpze NT won't load in 640KB?
>
> Load?? Shewt, that's not even enough space for it to *laugh* at you!
Date: Fri, 14 Jan 2000 14:40:06 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
I get a DWS every time I issue a QUIESCE command
.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Chase, John [SMTP:jchase@USSCO.COM]
> Sent: Friday, January 14, 2000 2:36 PM
>
> Yeah, but I can count the number of DWS I've seen in the past three years
> on
> one finger. ;-)
Date: Fri, 14 Jan 2000 14:43:35 -0500
From: boe.franklin@DB.COM
Subject: Re: Assembler Class (Was: Homework: Negative side of MVS?
I've seen several in the past year,
http://www.trainersfriend.com/CourseIndex.htm
shows 3 courses on assembler.
Thanks,
Boe Franklin
410-308-6796
Technical Services, Atrium
Deutsche Banc Alex. Brown
Date: Fri, 14 Jan 2000 14:45:29 -0500
From: "Hall, Ken (ECSS)"
Subject: Re: Homework: Negative side of MVS?
My old XT with 640K took about the same amount of time to boot DOS as my
Pentium does to boot NT. It takes about the same amount of time to IPL a
"basic" MVS system.
It's been my position all along that the bigger and faster you make the
machine, the longer it takes to do anything useful, so it all evens out in
the end.
> -----Original Message-----
> From: Zoltan Forray [SMTP:ZForray@SATURN.VCU.EDU]
> Sent: Friday, January 14, 2000 2:37 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Homework: Negative side of MVS?
>
> There is another quote he made, when refering to OS/2. Something about
> folks
> not wanting a PC that took 2-3 minutes to boot.
>
> Anyone timed W98 or NT bootup lately ?
>
Date: Fri, 14 Jan 2000 13:57:20 -0600
From: Mark Zelden
Organization: 3D Business Solutions
Subject: Assembler course (was Re: Homework: Negative side of MVS? -Reply)
"Bentley, Richard J" wrote:
>
> I agree. I have been in the IT field for about 20 years and in the last 7-8
> years I have tried to find a Assembler course to no avail. The assembler I
> know is just what I've had to learn on my own. Any one out there that knows
> of a basic class being offered.
> Rick
Techknowledge (formerly Amdahl) still teaches a basic class.
see - http://www.techknowledge.com/Public/public.html
--
+--------------------------------+--------------------------------+
| Mark Zelden | OS/390 Consultant |
| http://www.flash.net/~mzelden/ | 3D Business Solutions |
| mailto:mzelden@flash.net | mailto:mzelden@3dsolutions.com |
+--------------------------------+--------------------------------+
Check out my MVS utilities page at:
http://www.flash.net/~mzelden/mvsutil.html
Date: Fri, 14 Jan 2000 14:58:11 -0500
From: Bob Rutledge
Subject: Re: Homework: Negative side of MVS?
Yeah. But how can you make a disabled wait state happen from an application?
Bob
James Antognini wrote:
>
> Oh? In my book, disabled wait state = BSOD.
>
> --
> James Antognini
> IBM Watson Research
Date: Fri, 14 Jan 2000 15:40:15 -0500
From: Scott Harder
Subject: Re: Homework: Negative side of MVS?
Anyone time Win2k? Beta version here, and I take a break at the beginning
of every day.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@BAMA.UA.EDU]On
> Behalf Of Zoltan Forray
> Sent: Friday, January 14, 2000 2:37 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Homework: Negative side of MVS?
>
>
> There is another quote he made, when refering to OS/2.
> Something about folks
> not wanting a PC that took 2-3 minutes to boot.
>
> Anyone timed W98 or NT bootup lately ?
Date: Fri, 14 Jan 2000 15:23:07 -0600
From: "Edward(Ed) J. Finnell, III"
Organization: Seebeck Computer Center
Subject: Re: Homework: Negative side of MVS?
In-Reply-To: <0D93FE5CA0BED11194CB00A0C99D5B09037BC3C0@nsfmail01.nsf.gov>
When I was in the service, think all but a few of the bases(60+)
standard issue was a 360/30 w/128k. Programs were limited to 64k
period, no exceptions. Would never even make it out of Melpar.
Edward(Ed) J. Finnell, III
Enterprise Systems/Proj. Mgr.
url:www.ua.edu
Date: Fri, 14 Jan 2000 15:29:56 -0600
From: Rick Fochtman
Organization: Board of Trade Clearing Corporation
Subject: Re: Homework: Negative side of MVS?
> Do you mean that 'dpze NT won't load in 640KB? I loaded OS/360 MVT in less
> memory than that!
>
>
We ran MFT, HASP and 2,000 Student jobs a day, from 8:00 AM to 10:00 PM, in a
256k 360/44!
Date: Fri, 14 Jan 2000 16:31:46 -0500
From: "Beinert, William"
Subject: Re: Homework: Negative side of MVS?
But I bet you didn't have any dancing paper clips...
> -----Original Message-----
> From: Rick Fochtman [SMTP:Rick.Fochtman@BOTCC.COM]
> Sent: Friday, January 14, 2000 4:30 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Homework: Negative side of MVS?
>
>
>
> > Do you mean that 'dpze NT won't load in 640KB? I loaded OS/360 MVT in
> less
> > memory than that!
> >
> >
>
> We ran MFT, HASP and 2,000 Student jobs a day, from 8:00 AM to 10:00 PM,
> in a
> 256k 360/44!
>
Date: Fri, 14 Jan 2000 16:47:19 -0500
From: James Antognini
Organization: IBM Global Services North -- Burlington, Vermont, USA
Subject: Re: Homework: Negative side of MVS?
Same way on OS/390 as on WinNT: User-mode program calls system function which
screws up. All too familiar.
--
James Antognini
IBM Watson Research
Date: Fri, 14 Jan 2000 16:15:00 -0500
From: "Robert A. Rosenberg"
Subject: Re: Homework: Negative side of MVS?
In-Reply-To:
At 12:46 PM 01/14/2000 -0600, William M. Klein wrote:
>Could the comment about 16MB be assuming that this is asking about the
>problems with "MVS" (aka MVS/SP) - NOT MVS/XA or MVS/ESA or OS/390? If that
>is the case, then there really is a 16MB "issue" with MVS.
>
>After all, some of us on this list are "old enough" to remember
> "when MVS was MVS"
I'm old enough to remember when 16MB mean all the memory that was available
to SHARE with other programs (ie: If a program wanted 6Meg, there was only
10Meg left for the Operating System and the other programs). That was when
MVS was still called MV_T_ (or MFT).
Date: Fri, 14 Jan 2000 21:19:58 GMT
From: Robert Ngan
Organization: CSC Financial Services Group Banking Division
Subject: Re: Homework: Negative side of MVS?
This really only affects oboslete compilers and assembler programmers.
With DOS/Windows, you have the 640K boundary, 1MB boundary 16MB boundary
(for some Windows 3.1 stuff I believe), 64MB boundary (cache line limits)
so OS/390 is not all that bad!
In article <0058222C20AAD3118B6D0008C75631193E9A2A@mail.trs.state.tx.us>,
Pat.Miller@TRS.STATE.TX.US says...
> I'm dumbfounded that no one has mentioned that artificial 16MB boundary.
> Granted it's been quite a while since IBM came up with a "work around," but
> it still causes plenty of headaches now and then. Tried running transaction
> isolation in a shop with a lot of legacy COBOL apps? Not to mention that
> it's nothing less than embarrassing to explain to anyone unfamiliar with
> S/390 architecture.
--
Robert Ngan
CSC Financial Services Group
Date: Fri, 14 Jan 2000 21:13:31 GMT
From: Robert Ngan
Organization: CSC Financial Services Group Banking Division
Subject: Re: Homework: Negative side of MVS?
User interface? That depends on what the user is doing i.e.
TSO
ISPF
CICS
IMS
ROSCOE
TPX/Netview/Supersession
etc.
There is no "real" OS/390 user interface
In article <962A7B1E7538D3118CC100104B07532F0E0D12@abq-mail.csdinc.com>,
Richard.Combest@CSDINC.COM says...
> would not an occasional user of ANY OS have difficulty? i wouldn't consider
> that negative.
>
> -----Original Message-----
> From: Cox, Steve [mailto:Steve_Cox@BMC.COM]
> Sent: Friday, January 14, 2000 8:58 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Homework: Negative side of MVS?
>
>
> OS/390 has a very difficult user interface, almost as bad as the UNIX
> interface. It is still largely command driven and the commands are
> frequently unusual abbreviations of the command name. While there has
> been an attempt to layer "fill-in-the-blank" panels over the commands, these
> panels are quirky and idiosyncratic.
> This is a very real negative issue for occasional users of OS/390.
>
[snip]
--
Robert Ngan
CSC Financial Services Group
Date: Fri, 14 Jan 2000 16:50:51 -0500
From: James Antognini
Organization: IBM Global Services North -- Burlington, Vermont, USA
Subject: Re: Homework: Negative side of MVS?
Oh, that.
--
James Antognini
IBM Watson Research
Date: Sat, 15 Jan 2000 09:29:56 +0800
From: Kok Theng KOH
Subject: Re: HOMEWORK: NEGATIVE SIDE OF MVS?
Having to deal with the ISVs on the high software charges imposed whenever we
upgrade the CPU, is a concern. The additional software charges (you do not get
any additional service out of it, probably a new password ?) which one needs to
incur is getting more than the CPU hardware upgrade cost. All these charges are
driving the mainframe cost of computing up.
Anyone out there aware of any mainframe ISVs who charges their software based on
usage ? Charging based on usage would be more equitable since when a CPU is
upgraded, it does not necessarily translate to an increase in the usage of the
software.
Regards.
Date: Sat, 15 Jan 2000 00:53:36 GMT
From: Bill Planer
Organization: MindSpring Enterprises
Subject: Re: Homework: Negative side of MVS?
I work with 15 MVS images. The number of total MVS system failures I see
in a year that are not hardware induced is a two digit binary number. My
NT workstation craps out at least once a week.
James Antognini wrote in article
<387F9967.7E8FF1A4@us.ibm.com>...
> Same way on OS/390 as on WinNT: User-mode program calls system function
which
> screws up. All too familiar.
>
> --
> James Antognini
> IBM Watson Research
>
>
>
Date: Fri, 14 Jan 2000 22:27:17 -0400
From: Clark Morris
Organization: CFM Technical Programming Services
Subject: 16 meg line, was Re: Homework: Negative side of MVS?
If you have a shop that calls Assembler sub-routines that do non-VSAM
I-O, you may well have to worry about the 16 meg line. My last shop
used a vendor package that remained 24 bit. Having looked at the
aggravation involved in making a couple of old assembler main programs
31 bit capable, I can understand why they put off making the
sub-routines 31 bit capable. The abysmal support for 31 bit non-VSAM
I-O made it not worth the effort on the main programs since they run
fine below the line. However, I would have made the effort to make
sub-routines 31 bit capable. What IBM should have done when the ACB
was designed is make it and GENCB capable of handling ALL data set
organizations and frozen the DCB. Maybe they'll get it right with 64
bit addressing control blocks.
Clark Morris, CFM Technical Programming Services Inc. cfmtech@istar.ca
"Miller, Pat" wrote:
>
> Whether you're running MVS/SE, SP, XA, ESA, or Os/390, the 16MB line is
> still there. Otherwise why does virtually every area or control block have
> one piece below the line and an "extension" above it?
>
Date: Sat, 15 Jan 2000 15:32:25 -0500
From: Bob Rutledge
Subject: Re: 16 meg line, was Re: Homework: Negative side of MVS?
Actually, I *just* rewrote a 20+-year-old assembler subroutine to handle BDAM
access for COBOL-for-this'n'that callers in 31-bit. Yes, BDAM! It was pretty
trivial; the only things that had to be moved "below" were the DCBs and the
DECBs.
What other architecture is going to let you only have to modify such low-level
stuff only once every 20 years? Or even every 20 months? Or even ...
Bob
Clark Morris wrote:
>
> If you have a shop that calls Assembler sub-routines that do non-VSAM
> I-O, you may well have to worry about the 16 meg line. My last shop
> used a vendor package that remained 24 bit. Having looked at the
> aggravation involved in making a couple of old assembler main programs
> 31 bit capable, I can understand why they put off making the
> sub-routines 31 bit capable. The abysmal support for 31 bit non-VSAM
> I-O made it not worth the effort on the main programs since they run
> fine below the line. However, I would have made the effort to make
> sub-routines 31 bit capable. What IBM should have done when the ACB
> was designed is make it and GENCB capable of handling ALL data set
> organizations and frozen the DCB. Maybe they'll get it right with 64
> bit addressing control blocks.
>
> Clark Morris, CFM Technical Programming Services Inc. cfmtech@istar.ca
Date: Sat, 15 Jan 2000 23:01:19 ASIA/TEL_AVIV
From: Giliad Wilf
Subject: Re: HOMEWORK: NEGATIVE SIDE OF MVS?
On Sat, 15 Jan 2000, Stephen Mednick wrote:
>
> I'd be interested in knowing what IBM system and program products
> are charged on a usage basis rather than on some measure of machine
> size. You can rest assured that if IBM were to charge for all of
> their products on a usage basis then most of the ISVs would follow
> suite.
>
Look at the below URL:
www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/IEA1R108/1%2e1%2e5%2e1
--
Giliad Wilf giliadw@netvision.net.il
Systems - Technical Support Phone: +972-3-5634471
Mehish, 15 Lincoln St., 67134 Tel-Aviv, Israel Fax: +972-3-5623717
Disclaimer: This e-mail may contain spelling, or grammatical errors..
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
Date: Sun, 16 Jan 2000 10:13:21 +1100
From: Stephen Mednick
Subject: Re: HOMEWORK: NEGATIVE SIDE OF MVS?
Comments: To: giliadw@USA.NET
In-Reply-To: <20000115230119.24749.qmail@nwcst287.netaddress.usa.net>
For some reason it doesn't appear that you can go directly to the link
you've quoted.
Stephen Mednick
Computer Supervisory Services
Sydney, Australia
> On Sat, 15 Jan 2000, Stephen Mednick wrote:
> >
> > I'd be interested in knowing what IBM system and program products
> > are charged on a usage basis rather than on some measure of machine
> > size. You can rest assured that if IBM were to charge for all of
> > their products on a usage basis then most of the ISVs would follow
> > suite.
> >
>
> Look at the below URL:
> www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/IEA1R108/1%2e1%2e5%2e1
> --
> Giliad Wilf giliadw@netvision.net.il
> Systems - Technical Support Phone: +972-3-5634471
> Mehish, 15 Lincoln St., 67134 Tel-Aviv, Israel Fax: +972-3-5623717
>
>
Date: Sat, 15 Jan 2000 23:24:34 ASIA/TEL_AVIV
From: Giliad Wilf
Subject: Re: HOMEWORK: NEGATIVE SIDE OF MVS?
On Sun, 16 Jan 2000, Stephen Mednick wrote:
>
> For some reason it doesn't appear that you can go directly to the
> link you've quoted.
>
I omitted the "http://" prefix on purpose, to make it as close to 70
chars long as possible. This is why you may have to cut & paste the
below string into your browser's "location" window.
www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/IEA1R108/1%2e1%2e5%2e1
--
Giliad Wilf giliadw@netvision.net.il
Systems - Technical Support Phone: +972-3-5634471
Mehish, 15 Lincoln St., 67134 Tel-Aviv, Israel Fax: +972-3-5623717
Disclaimer: This e-mail may contain spelling, or grammatical errors..
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
Date: Sat, 15 Jan 2000 23:45:20 ASIA/TEL_AVIV
From: Giliad Wilf
Subject: Re: HOMEWORK: NEGATIVE SIDE OF MVS?
Stephen,
Depending on your release, you may have to install PTF(s) per OW36295,
to have usage reports generated in a format required by IBM.
--
Giliad Wilf giliadw@netvision.net.il
Systems - Technical Support Phone: +972-3-5634471
Mehish, 15 Lincoln St., 67134 Tel-Aviv, Israel Fax: +972-3-5623717
Disclaimer: This e-mail may contain spelling, or grammatical errors..
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
Date: Sat, 15 Jan 2000 19:37:03 -0500
From: Neil Stutz
Subject: Re: HOMEWORK: NEGATIVE SIDE OF MVS?
I use Outlook Express (IE 4.01) and had no problem just clicking on the
URL in Giliad's earlier email. I went right to the site.
Neil Stutz
-----Original Message-----
From: Giliad Wilf
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Date: Saturday, January 15, 2000 6:24 PM
Subject: Re: HOMEWORK: NEGATIVE SIDE OF MVS?
Date: Sun, 16 Jan 2000 20:15:00 +1100
From: Stephen Mednick
Subject: Usage Based Pricing (formerly: HOMEWORK: NEGATIVE SIDE OF MVS?)
In-Reply-To: <20000115232434.7964.qmail@nw177.netaddress.usa.net>
I managed to access the URL address showing the list of IBM products that
provide for charging based on usage. I have to say the list is extremely
small, mainly CICS, IMS & DB2 products.
I would imagine that if IBM ever start introducing charging based on usage
for the base OS/390 components, DFSMSxxx products, TSO/E, ISPF, SDSF
etc,etc, etc... then maybe you'll start to see ISV's start to introduce
usage based charging. If an ISV is not offering usage based charging for
CICS, DB2 & IMS related products then maybe then the ISV has a case to
answer for. However I would say that in some respects it's unfair to get
into ISV-bashing about their lack of pricing options to include usage based
charging when in the main IBM don't offer the option either for their
mainstream product set.
Stephen Mednick
Computer Supervisory Services
Sydney, Australia
>
Date: Sun, 16 Jan 2000 16:43:10 GMT
From: S Comstock
Organization: AOL http://www.aol.com
Subject: Re: Assembler Class (Was: Homework: Negative side of MVS?
We offer Assembler classes, but we need a company to host it, since we don't
have our own data center / ed center. Check the website in my signature for
details.
If anyone wants to host our C215 and C216 courses I would be delighted, as
Assembler remains my favorite language.
Regards,
Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com
email: steve@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA
Date: Sun, 16 Jan 2000 17:02:38 ASIA/TEL_AVIV
From: Giliad Wilf
Subject: Re: Usage Based Pricing (formerly: HOMEWORK: NEGATIVE SIDE OF
MVS?)
On Sun, 16 Jan 2000, Stephen Mednick wrote:
>
> I managed to access the URL address showing the list of IBM products
> that provide for charging based on usage. I have to say the list is
> extremely small, mainly CICS, IMS & DB2 products.
>
> I would imagine that if IBM ever start introducing charging based
> on usage for the base OS/390 components, DFSMSxxx products, TSO/E,
> ISPF, SDSF etc,etc, etc... then maybe you'll start to see ISV's
> start to introduce usage based charging. If an ISV is not offering
> usage based charging for CICS, DB2 & IMS related products then maybe
> then the ISV has a case to answer for. However I would say that in
> some respects it's unfair to get into ISV-bashing about their lack
> of pricing options to include usage based charging when in the main
> IBM don't offer the option either for their mainstream product set.
>
Stephen,
It may take some time. Each product must undergo some modifications.
It has to identify itself to OS/390 (register itself), and request
the measurement function(s).
--
Giliad Wilf giliadw@netvision.net.il
Systems - Technical Support Phone: +972-3-5634471
Mehish, 15 Lincoln St., 67134 Tel-Aviv, Israel Fax: +972-3-5623717
Disclaimer: This e-mail may contain spelling, or grammatical errors..
Date: Mon, 17 Jan 2000 08:30:04 +0200
From: Nimesh Bhaga
Subject: Re: Homework: Negative side of MVS?
Negative side of MVS ?
- Trying to explain to people what I do for a JOB !
Date: Mon, 17 Jan 2000 11:31:53 +0000
From: John Cousins
Subject: Re: Homework: Negative side of MVS? -Reply
Or even old enough to remember MVT, MFT II, MFT, PCP,
1401..........
>>> "William M. Klein" 14/January/2000 06:46pm >>>
Could the comment about 16MB be assuming that this is asking about the
problems with "MVS" (aka MVS/SP) - NOT MVS/XA or MVS/ESA or OS/390? If that
is the case, then there really is a 16MB "issue" with MVS.
After all, some of us on this list are "old enough" to remember
"when MVS was MVS"
Bill Klein
wmklein ix.netcom.com
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@BAMA.UA.EDU]On
> Behalf Of Richard Lazar
> Sent: Friday, January 14, 2000 12:41 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Homework: Negative side of MVS?
>
>
> Do you mean OS/VS COBOL ?
> Migrate to COBOL-II, set Options RENT,DATA(31) and don't call any AMODE(24)
> progam.
> What is a 16 MB boundary ? ;-)
>
Date: Mon, 17 Jan 2000 09:41:53 -0500
From: Jon Brock
Subject: Re: Homework: Negative side of MVS?
Lord preserve us . . .
-----Original Message-----
From: Beinert, William [SMTP:BEINERTW@CONED.COM]
Sent: Friday, January 14, 2000 4:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Homework: Negative side of MVS?
But I bet you didn't have any dancing paper clips...
Date: Mon, 17 Jan 2000 07:23:24 -0800
From: Bob Richards
Subject: Re: Usage Based Pricing (formerly: HOMEWORK: NEGATIVE SIDE OF
MVS?)
Giliad and Steve,
It would be pointless to offer MULC for DFSMS components, as they are
necessary for the life of the IPL. Unless, of course, you just want
them available, without using them . And while I'm at it, most of
the other base products fall under the same criteria.
JES2? What, by batch job?
TSO/E - Do you really want to pay for its usage when a lot of
programmers have figured out ways to bypass timeout?
VTAM? - Do you want to wait while a node fires up?
Granted, my views are based on the perspective of working in larger
shops...some MULC could be warranted for smaller shops, but I believe
IBM have other offerings to meet their needs (Multiprise, etc.)
Just my $.02 worth.
--- Giliad Wilf wrote:
> On Sun, 16 Jan 2000, Stephen Mednick wrote:
snip
> > I would imagine that if IBM ever start introducing charging based
> > on usage for the base OS/390 components, DFSMSxxx products, TSO/E,
> > ISPF, SDSF etc,etc, etc... then maybe you'll start to see ISV's
> > start to introduce usage based charging.
snip
=====
Bob Richards, OS/390 Consultant Internet: richardsrb@yahoo.com
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Date: Mon, 17 Jan 2000 15:37:26 +0000
From: Jim McAlpine
Subject: FW: Assembler Class (Was: Homework: Negative side of MVS?
There is a basic assembler course on the web at the Western Illinois
University web site -
http://www.wiu.edu/users/mflll/cs310/head.html
Date: Mon, 17 Jan 2000 19:13:23 ASIA/TEL_AVIV
From: Giliad Wilf
Subject: Re: Usage Based Pricing (formerly: HOMEWORK: NEGATIVE SIDE OF
MVS?)
On Mon, 17 Jan 2000, Bob Richards wrote:
>
> It would be pointless to offer MULC for DFSMS components, as they
> are necessary for the life of the IPL. Unless, of course, you just
> want them available, without using them . And while I'm at
> it, most of the other base products fall under the same criteria.
>
> JES2? What, by batch job?
> TSO/E - Do you really want to pay for its usage when a lot of
> programmers have figured out ways to bypass timeout?
> VTAM? - Do you want to wait while a node fires up?
>
>
>
I think I once saw TSO/E on a measured usage pricing scheme somewhere,
and I know I've seen CPCS on such a scheme too (we were looking for
alternatives to home grown magnetic cheques processing programs).
--
Giliad Wilf giliadw@netvision.net.il
Systems - Technical Support Phone: +972-3-5634471
Mehish, 15 Lincoln St., 67134 Tel-Aviv, Israel Fax: +972-3-5623717
Disclaimer: This e-mail may contain spelling, or grammatical errors..
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
Date: Mon, 17 Jan 2000 09:44:34 -0500
From: Jon Brock
Subject: Re: Homework: Negative side of MVS?
I always just tell people that I "work with computers" or "in the computer
department at the hospital system." If they start asking PC questions (and
they usually do), I go ahead and mention that I work with the mainframe
computers or big computers. It gets the information across and - I hope -
keeps me from becoming too tedious with them.
-----Original Message-----
From: Nimesh Bhaga [SMTP:NBhaga@EDGARS.CO.ZA]
Sent: Monday, January 17, 2000 1:30 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Homework: Negative side of MVS?
Negative side of MVS ?
- Trying to explain to people what I do for a JOB !
Date: Tue, 18 Jan 2000 11:33:55 -0600
From: Tom Schmidt
Organization: OAS Software, Inc.
Subject: Re: Homework: Negative side of MVS?
Comments: cc: Anne & Lynn Wheeler
In-Reply-To:
I don't doubt that you were told this as the reason but I don't believe
it to be a valid reason. Consider that they knowingly replaced
something that worked well with something else not as good because they
couldn't hire replacements. Why wouldn't they attempt to grow the
talent in-house? If they *did* attempt it and failed, why did they
fail? My bet is that they were attempting to keep the salaries
artificially low - much lower than the local or regional competition.
I'm entertained by the suggestion that local financial organizations
were paying better, since most financial organizations pay lower in my
experience. (Banks think they understand money so they don't give it
away, manufacturing companies think they understand their product so
they don't give it away, etc.)
I've only met one decent HR person in my 25+ year career. The rest were
hacks who did more damage to their company than anyone in IT ever could.
Tom Schmidt
Madison, WI
On Fri, 14 Jan 2000 19:28:07 GMT, in bit.listserv.ibm-main Anne & Lynn
Wheeler wrote:
>I've talked to a number of large organizations that retired MVS and
>converted to something else not as good. Reason given was that their
>MVS staff was retiring and they weren't able to backfill the slots.
>
>In many cases, they found they weren't able to compete with financial
>organizations for scarce resource. Even in some financial
>organizations, they identify in the top five business risks critical
>MVS staff with over 30 years (nearing retirement age, kids are all
>thru school, house paid for, and it is getting difficult to motivate,
>even with significant salary raises).
Date: Tue, 18 Jan 2000 12:48:41 -0500
From: JE Thinnes
Subject: Retire MVS was Re: Homework: Negative side of MVS?
I did not see the origianl post - However, I was told at my last position
(National Distillers, aka Quantum Chemical aka Millennium Petrochemical ) by an
IBMer that no large MVS (in US?) shop had been able to 'retire' MVS. My
relocation proves otherwise - MPI now runs SAP on NT servers. IBM hardware was
mothballed about a year ago.
I would like to know who the 'number of large organizations' were. In
Millennium's case - it was a way to handle a huge
YR2000 mess. In house COBOL code - no source . . .
Tom Schmidt on 01/18/2000 12:33:55 PM
Please respond to Tom.Schmidt@OASsoftware.com
To: IBM-MAIN@BAMA.UA.EDU
cc:
Subject: Re: Homework: Negative side of MVS?
I don't doubt that you were told this as the reason but I don't believe
it to be a valid reason. Consider that they knowingly replaced
something that worked well with something else not as good because they
couldn't hire replacements. Why wouldn't they attempt to grow the
talent in-house? If they *did* attempt it and failed, why did they
fail? My bet is that they were attempting to keep the salaries
artificially low - much lower than the local or regional competition.
I'm entertained by the suggestion that local financial organizations
were paying better, since most financial organizations pay lower in my
experience. (Banks think they understand money so they don't give it
away, manufacturing companies think they understand their product so
they don't give it away, etc.)
I've only met one decent HR person in my 25+ year career. The rest were
hacks who did more damage to their company than anyone in IT ever could.
Tom Schmidt
Madison, WI
On Fri, 14 Jan 2000 19:28:07 GMT, in bit.listserv.ibm-main Anne & Lynn
Wheeler wrote:
>I've talked to a number of large organizations that retired MVS and
>converted to something else not as good. Reason given was that their
>MVS staff was retiring and they weren't able to backfill the slots.
>
>In many cases, they found they weren't able to compete with financial
>organizations for scarce resource. Even in some financial
>organizations, they identify in the top five business risks critical
>MVS staff with over 30 years (nearing retirement age, kids are all
>thru school, house paid for, and it is getting difficult to motivate,
>even with significant salary raises).
Date: Tue, 18 Jan 2000 17:49:42 GMT
From: Robert Ngan
Organization: CSC Financial Services Group Banking Division
Subject: Re: 16 meg line, was Re: Homework: Negative side of MVS?
Most of the non-VSAM macros support both AMODE=31 and RMODE=ANY today.
About the only ones (of significance) that don't are DCBs and EXLSTs.
In article <387FDB05.359B4533@istar.ca>, cfmtech@ISTAR.CA says...
> If you have a shop that calls Assembler sub-routines that do non-VSAM
> I-O, you may well have to worry about the 16 meg line. My last shop
> used a vendor package that remained 24 bit. Having looked at the
> aggravation involved in making a couple of old assembler main programs
> 31 bit capable, I can understand why they put off making the
> sub-routines 31 bit capable. The abysmal support for 31 bit non-VSAM
> I-O made it not worth the effort on the main programs since they run
> fine below the line. However, I would have made the effort to make
> sub-routines 31 bit capable. What IBM should have done when the ACB
> was designed is make it and GENCB capable of handling ALL data set
> organizations and frozen the DCB. Maybe they'll get it right with 64
> bit addressing control blocks.
>
> Clark Morris, CFM Technical Programming Services Inc. cfmtech@istar.ca
>
[snip]
--
Robert Ngan
CSC Financial Services Group
Date: Tue, 18 Jan 2000 12:53:03 -0500
From: "Connie Schlosser (TPA)"
Subject: Re: Homework: Negative side of MVS?
I'm inclined to agree with Tom. The appearance from this end is that
businesses are trying to save on salaries by attempting to replace MVS and
us lovable ole' dinosaurs with kids fresh out of college, whether it's a
logical or viable thing to do....with the "new technology" chant as their
justification.
Then when they get into trouble, they try to claim that there aren't enough
of us still around, and they "had" to.
Personally, I get amused when they try to take people who learned C++ and
Unix and stick them on COBOL and MVS. JCL will make them *really* twitchy.
Honestly, I've found it easier to train mainframers in client-server than
client-server types in mainframe. I've had about a 50-60% drop out rate
trying to get people from client-server to mainframe....but only about 10%
going the other way.
IMHO, no offense to the kids (having been one myself once or twice),
businesses not only lose on the technical edge, but lose worse in the
"business sense". If you've been in the biz awhile you develop instincts on
where to get information and what questions to ask....something you can't
teach...and what they really mean versus what they say....and how to get it
in writing without annoying everyone.
I found when they started calling it HR instead of Personnel, it stopped
being for the employees and was just another management tool to annoy the
worker bees.
Connie
Tom Schmidt on 01/18/2000 12:33:55 PM
Please respond to Tom.Schmidt@OASsoftware.com
To: IBM-MAIN@BAMA.UA.EDU
cc:
Subject: Re: Homework: Negative side of MVS?
I don't doubt that you were told this as the reason but I don't believe
it to be a valid reason. Consider that they knowingly replaced
something that worked well with something else not as good because they
couldn't hire replacements. Why wouldn't they attempt to grow the
talent in-house? If they *did* attempt it and failed, why did they
fail? My bet is that they were attempting to keep the salaries
artificially low - much lower than the local or regional competition.
I'm entertained by the suggestion that local financial organizations
were paying better, since most financial organizations pay lower in my
experience. (Banks think they understand money so they don't give it
away, manufacturing companies think they understand their product so
they don't give it away, etc.)
I've only met one decent HR person in my 25+ year career. The rest were
hacks who did more damage to their company than anyone in IT ever could.
Tom Schmidt
Madison, WI
On Fri, 14 Jan 2000 19:28:07 GMT, in bit.listserv.ibm-main Anne & Lynn
Wheeler wrote:
>I've talked to a number of large organizations that retired MVS and
>converted to something else not as good. Reason given was that their
>MVS staff was retiring and they weren't able to backfill the slots.
>
>In many cases, they found they weren't able to compete with financial
>organizations for scarce resource. Even in some financial
>organizations, they identify in the top five business risks critical
>MVS staff with over 30 years (nearing retirement age, kids are all
>thru school, house paid for, and it is getting difficult to motivate,
>even with significant salary raises).
Date: Tue, 18 Jan 2000 13:28:57 -0500
From: LeeWarriner
Subject: Re: Homework: Negative side of MVS?
I wonder who these large organizations are. We have had several customers who
have or are in the process of moving there work back to the OS390 from a
distributed mode. They are saying better service, more availability and better
performance and cost. Note that these are large on-line and batch workloads.
Yes MVS staffing is an issue.
______________________________ Reply Separator _________________________________
On Fri, 14 Jan 2000 19:28:07 GMT, in bit.listserv.ibm-main Anne & Lynn
Wheeler wrote:
>I've talked to a number of large organizations that retired MVS and
>converted to something else not as good. Reason given was that their
>MVS staff was retiring and they weren't able to backfill the slots.
>
>In many cases, they found they weren't able to compete with financial
>organizations for scarce resource. Even in some financial
>organizations, they identify in the top five business risks critical
>MVS staff with over 30 years (nearing retirement age, kids are all
>thru school, house paid for, and it is getting difficult to motivate,
>even with significant salary raises).
Date: Tue, 18 Jan 2000 16:44:16 -0500
From: Bruce Black
Organization: Innovation Data Processing
Subject: Re: Retire MVS was Re: Homework: Negative side of MVS?
> However, I was told at my last position
> (National Distillers, aka Quantum Chemical aka Millennium Petrochemical ) by an
> IBMer that no large MVS (in US?) shop had been able to 'retire' MVS.
I find that hard to believe. In recent years we have had a lot of FDR
maintenance agreements cancelled. Many were because of data center
consolidations, but a significant number were because they retired their MVS
systems. I can't tell you how many were "large" shops.
--
Bruce A. Black
Senior Software Developer for
FDR, CPK, ABR, SOS, UPSTREAM, FATS/FATAR
Innovation Data Processing
Little Falls, NJ 07424
973-890-7300
personal: bblack@fdrinnovation.com
sales info: sales@fdrinnovation.com
tech support: support@fdrinnovation.com
Date: Tue, 18 Jan 2000 22:31:29 -0500
From: Joe Zitzelberger
Subject: Re: Homework: Negative side of MVS?
>>=Connie Schlosser (TPA) at Connie.Schlosser@DCICORP.COM said on 1/18/00
12:53=<<
>[snip]
>Personally, I get amused when they try to take people who learned C++ and
>Unix and stick them on COBOL and MVS. JCL will make them *really* twitchy.
>[snip]
Huh? Just tell the its a J-shell script...they'll pick it right up...
-=Psychedelic Harry=-
http://ldl.net/~zberger/
-----
The "free" lunch is usually at the expense of the people who were
robbed by Big Brotherment to pay for it...
Date: Wed, 19 Jan 2000 09:18:14 GMT
From: reza heydarpour
Subject: Re: Retire MVS was Re: Homework: Negative side of MVS?
Bruce,
Could u pls elaborate on this: the 'large' shops:
1- how large is 'large' ?
2- they had many LPARs, but moved applic from some to non-MF
so they ended up having less LPARs ?
3- they moved off MF completely ?
4- when was this (early 90's , ... ?)
...Reza
>>>
I find that hard to believe. In recent years we have had a lot of FDR
maintenance agreements cancelled. Many were because of data center
consolidations, but a significant number were because they retired their MVS
systems. I can't tell you how many were "large" shops.
--
Bruce A. Black
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Date: Wed, 19 Jan 2000 07:32:04 -0500
From: William Ball
Subject: Re: Retire MVS was Re: Homework: Negative side of MVS?
In-Reply-To: <3884DEB0.F9DCB93C@fdrinnovation.com>
The subject line here should be "negative side of unix(c)". I have no doubt
that there are STILL some companies that haven't learned (the hard way)
that MVS and mainfames are cheaper and more reliable in the long run. I
hear in staff meetings "we need a box (unix of course) to do something"
(pick an application) and before the meeting is over it's grown from 1 box
to 3 or more.
I've read article after article where companies have tryed to "retire MVS"
but I have not seen 1 article that didn't say they couldn't make it work,
or in worse case it cost them a LOT more than they ever imagined (and
certainly a more than a mainframe solution would have been).
I believe what you are saying Bruce about loosing contracts and I'm sure a
portion of them are because there are STILL companies out there that
believe or want to believe that those cute little black boxes have all the
answers for them without them doing anything but plugging them in. Worse
yet. Where are they going to get mainframe people. Colleges and
universities have beat it into kids heads for a couple of decades that unix
is the ONLY true God. The problem with all this is it's costing companies
more to try to do the same job they were doing with that lowly mainframe,
when it can be done at all.
I find it hard to believe that a company of most any size with a mainframe
would even consider trying to "retire MVS". They should be trying to get
unix applications to talk to their mainframe to cut the bottom line costs.
This really seems like the spin doctor is hard at work again. SOSDW.
At 04:44 PM 01/18/2000 -0500, you wrote:
>> However, I was told at my last position
>> (National Distillers, aka Quantum Chemical aka Millennium Petrochemical
) by an
>> IBMer that no large MVS (in US?) shop had been able to 'retire' MVS.
>
>I find that hard to believe. In recent years we have had a lot of FDR
>maintenance agreements cancelled. Many were because of data center
>consolidations, but a significant number were because they retired their MVS
>systems. I can't tell you how many were "large" shops.
>
>--
>Bruce A. Black
>Senior Software Developer for
>FDR, CPK, ABR, SOS, UPSTREAM, FATS/FATAR
>Innovation Data Processing
>Little Falls, NJ 07424
>973-890-7300
>personal: bblack@fdrinnovation.com
>sales info: sales@fdrinnovation.com
>tech support: support@fdrinnovation.com
>
Bill Ball
WBALL@KENT.EDU
Kent State University
University Information Systems
Date: Wed, 19 Jan 2000 09:10:59 -0500
From: Dan Sullivan
Subject: Re: Retire MVS was Re: Homework: Negative side of MVS?
Bill,
I agree! One of the biggest mutual fund / investing companies if not the
biggest in Boston spent over $350 Million to try and go the the Unix/Server way
and
finally opting back to IBM's OS/390 Enterprise Servers (oops! Mainframe, sorry).
I guess these companies would have to spend a bundle of money to see the forest
through the trees. Dan
Date: Tue, 18 Jan 2000 18:26:04 -0800
From: Tom Bishop
Subject: Re: Homework: Negative side of MVS? -Reply
Reminds me of a comment I just heard on the radio. When this college professor
is asked a medical question, he says "I'm a real doctor. What you want is a
mechanic".
>>> Jon Brock 01/17 6:44 am >>>
I always just tell people that I "work with computers" or "in the computer
department at the hospital system." If they start asking PC questions (and
they usually do), I go ahead and mention that I work with the mainframe
computers or big computers. It gets the information across and - I hope -
keeps me from becoming too tedious with them.
-----Original Message-----
From: Nimesh Bhaga [SMTP:NBhaga@EDGARS.CO.ZA]
Sent: Monday, January 17, 2000 1:30 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Homework: Negative side of MVS?
Negative side of MVS ?
- Trying to explain to people what I do for a JOB !
Date: Wed, 19 Jan 2000 14:49:53 -0500
From: Jeffrey Broido
Subject: Re: Homework: Negative side of MVS?
Folks,
I have been working with mainframe and other computers since 1966 (OS/360
MFT) and professionally as a Systems Programmer since 1970 (OS/360 MVT R18 and
onward through OS/390 2.5). I am still a mainframe Systems Programmer and I
still enjoy my job immensely, so, obviously, I think that the strengths of the
OS/360 extended family of operating systems greatly outweigh their weaknesses.
Still, these weaknesses do exist, and I am sure there are even more weaknesses
as seen through the eyes of others than I would list.
The major weakness of OS/390, I think, is its age and its set of
age-related problems. OS/360 was written in Assembler, starting in the late
'50s, by thousands of programmers, most of them recent college graduates who had
never done any programming (see "Mythical Man-Month" by Frederick P. Brooks, the
head of the OS/360 development project,
http://www.amazon.com/exec/obidos/ISBN%3D0201835959/002-3332110-4780220 ).
Despite its age, there is actually some code in OS/390 left over from those
early days. Most of it, of course, has been rewritten. Even so, much of the
current code is a fossil of the original, having been rewritten and rewritten
over the years to add function, change the language to PL/S, PASCAL, C, etc.,
but the basic function is often transferred intact from version to version. As
a result of this, the system is top heavy and a good deal larger than if it had
been written today, even for the original 1957 S/360 system architecture. Even
this weakness is something of a strength, for it represents IBM's committment,
in general, to maintain backward compatibility, something they do better than
any other software vendor in my experience.
Another weakness is more recent: IBM's Object-Code-Only policy. Originally
and for decades following the initial release of OS/360 PCP in the mid '60s, IBM
supplied all source code for the operating system, utilities, language
translators, etc. The only code which remained secret was the microcode, and
even this could be found with a little digging. Now, not only is the source
code disappearing, and at an alarming rate, but the data area definitions are
one by one being hidden. IBM has many publicly stated reasons for this policy.
The most compelling of these is that the less Systems Programmers know the less
we will change, and this makes the operating system much less expensive to
support. The trouble is that despite the fact that IBM's support is still
unparalleled, it is not what it once was and I fear that it will get worse
before it gets better. Last year, for the first time, in response to my demand
that IBM fix a critical problem, I was told that "it would cost too much to make
the product work as designed in all cases." We never would have heard this
fifteen years ago. In light of this perceived trend, I see the Object-Code-Only
policy as a roadblock on the path to stability, not an aid to stability as IBM
claims.
Yet another weakness is the lack of a full GUI. Sure, there have been
half-hearted attempts, including the ISPF Workstation Agent and its
predecessors, still a minimal and marginally useable work in progress, and IBM's
very few X-Windows clients for USS, but what we need is a full-fledged,
fully-customizable GUI interface to everything, and I fear we have a long time
to wait.
There are many more weaknesses, and I'll probably think of a few more after
I post this, but, for the most part, I still feel that the system is so strong
that the weaknesses are almost meaningless in the face of its strengths.
Jeff Broido
Date: Wed, 19 Jan 2000 15:21:10 -0500
From: "Hall, Ken (ECSS)"
Subject: Re: Homework: Negative side of MVS?
Sounds like a good justification for Linux/390!
Date: Wed, 19 Jan 2000 15:05:08 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
I suspect that less has been rewritten then you were hoping.
AFAIK none of the MVS code was ever written in Pascal; perhaps you were
thinking of TCP/IP rather than MVS. Also, I don't know when IBM started, but
1957 sounds way to early.
"OCO, just say no!" IBM had a prime marketing asset and discarded it without
ever realizing its value. Well, the Linux folks understand the importance of
making the source code universally accessible.
BTW, the microcode was *not* secret; anyone who wanted to could purchase the
hardware manuals that documented the programming for their model of
interest. If you wanted to get a copy of the actual microcode, you had to
supply a serial number, since the code was tied to a specific EC level, but
that didn't add a significant amount of time to the order cycle. What IBM
would not give or sell you was the compiler (e.g., CAS, MLS) used to
translate the "microcode" from a symbolic form to a numeric form.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Jeffrey Broido [SMTP:jbroido@PERSHING.COM]
> Sent: Wednesday, January 19, 2000 2:50 PM
>
>
> Despite its age, there is actually some code in OS/390 left over from
> those
> early days. Most of it, of course, has been rewritten. Even so, much
> of the
> current code is a fossil of the original, having been rewritten and
> rewritten
> over the years to add function, change the language to PL/S, PASCAL, C,
> etc.,
> but the basic function is often transferred intact from version to
> version. As
> a result of this, the system is top heavy and a good deal larger than if
> it had
> been written today, even for the original 1957 S/360 system architecture.
>
>
...
> Another weakness is more recent: IBM's Object-Code-Only policy.
> Originally
> and for decades following the initial release of OS/360 PCP in the mid
> '60s, IBM
> supplied all source code for the operating system, utilities,
> language
> translators, etc. The only code which remained secret was the
> microcode, and
> even this could be found with a little digging.
Date: Wed, 19 Jan 2000 17:25:58 -0500
From: James Antognini
Organization: IBM Global Services North -- Burlington, Vermont, USA
Subject: Re: Homework: Negative side of MVS?
>> As a result of this, the system is top heavy and a good deal larger than if
it had been written today, even for the original 1957 S/360 system architecture.
Ummm .... "Top heavy"? "A good deal larger"? And your reasons for the
assertion?
And even if we stipulate that you are correct, you've not shown that for
performance paths or even "standard" paths (whatever those might be) OS/390's
history comes into play in a detrimental way.
I'm not going to say you're wrong. You've simply not demonstrated your case but
merely averred that it is true.
--
James Antognini
IBM Watson Research
Date: Wed, 19 Jan 2000 14:45:19 -0800
From: Mark Thomen
Organization: DFSMS Development - Catalog, VSAM, IDCAMS
Subject: Re: Homework: Negative side of MVS?
Jeffrey Broido wrote:
> The major weakness of OS/390, I think, is its age and its set of
> age-related problems.
That's funny; I view its "maturity" as one of its assets, not a weakness. (I'm
personally a little sensitive of the use of the word "age", and prefer "maturity").
> OS/360 was written in Assembler, starting in the late '50s, by thousands of
> programmers, most of them recent college graduates who had never done any
> programming
And of course, neither had anyone else in the industry (such that it even was at
that point)...
> Despite its age, there is actually some code in OS/390 left over from those
> early days. Most of it, of course, has been rewritten. Even so, much of the
> current code is a fossil of the original, having been rewritten and rewritten
> over the years to add function, change the language to PL/S, PASCAL, C, etc.,
> but the basic function is often transferred intact from version to version.
This is a weakness? You don't really want "basic function" to change from version
to version, do you?
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
"Technical Database")
or http://knowledge.storage.ibm.com/
Date: Wed, 19 Jan 2000 14:39:51 -0800
From: Mark Thomen
Organization: DFSMS Development - Catalog, VSAM, IDCAMS
Subject: Re: Homework: Negative side of MVS?
Metz, Seymour wrote:
> "OCO, just say no!" IBM had a prime marketing asset and discarded it without
> ever realizing its value. Well, the Linux folks understand the importance of
> making the source code universally accessible.
"Universally accessible" is not necessarily good; I understand the rationale for
doing it (e.g. encourage customer-created features for Linux), but there's a
dark side too, especially when it's totally uncontrolled as in the Linux case.
As a former customer (from back in the pre-OCO days) I have mixed feelings. I
enjoyed the ability to work on problems concurrently with IBM Service, and to
learn more about how the system worked; however, I did do as IBM feared, being
one of those people who "fixed" things my shop didn't like. It worked great,
until it drove our workload up as we went from PUT tape to PUT tape, release to
release.
It quickly became a nightmare.
As an IBMer, I can tell you that it's a nightmare when customers or products
"intercept" or otherwise "hook" into our code, do things, and then continue. We
have no way to recognize that what the user did is NOT what got passed to us, or
that what WE did in module A was not what made it to module B. We spend hours
debugging problems, looking for coding errors, running traces, taking dumps
(much to the customers displeasure), and EVENTUALLY we find out "Hey, what's
this thing that's issuing xxx calls when our module is running" and we discover
the existence of the change to our logic.
Imagine what will happen when each shop decides to "customize" Linux for its own
special needs, and then people want to start sharing applications, or even each
installation site of a company grows its own mods so the same application can't
even run at a backup site. It can (and based on history, will) happen. Don't
forget that when they say every cloud has a silver lining, that there is STILL a
cloud there...
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
"Technical Database")
or http://knowledge.storage.ibm.com/
Date: Wed, 19 Jan 2000 22:03:07 -0500
From: Joe Zitzelberger
Subject: Re: Homework: Negative side of MVS?
>>=Jeffrey Broido at jbroido@PERSHING.COM said on 1/19/00 14:49=<<
>As
>a result of this, the system is top heavy and a good deal larger than if
>it had
>been written today, even for the original 1957 S/360 system architecture.
But if it were written today it would come on 35 high density DVDs and
have a dancing paper-clip!
-=Psychedelic Harry=-
http://ldl.net/~zberger/
-----
The "free" lunch is usually at the expense of the people who were
robbed by Big Brotherment to pay for it...
Date: Thu, 20 Jan 2000 10:12:29 +0100
From: Barbara Nitz
Subject: Antwort: Re: Homework: Negative side of MVS?
As an IBMer, I can tell you that it's a nightmare when customers or
products
"intercept" or otherwise "hook" into our code, do things, and then
continue. We
have no way to recognize that what the user did is NOT what got passed to
us, or
that what WE did in module A was not what made it to module B. We spend
hours
debugging problems, looking for coding errors, running traces, taking dumps
(much to the customers displeasure), and EVENTUALLY we find out "Hey,
what's
this thing that's issuing xxx calls when our module is running" and we
discover
the existence of the change to our logic.
Having worked in IBM software support, I have seen my share of exactly
these problems that Mark describes: Days spend debugging sadumps to find
out what went wrong! About 50% of the problems I encountered were caused by
non-IBM code intercepting/hooking into IBM code and doing things improperly
instead of using the available interfaces. (About 45% of the problems were
caused by the sysprog not reading the manual,and only 5% were actual IBM
code problems. Now I am one of the sysprogs not reading the manual!)
While I agree that the user MVS interfaces are missing in parts, I have
seen lots of cases where they are just not used!
Barbara Nitz
BfG Bank AG
Date: Thu, 20 Jan 2000 07:02:46 -0600
From: Rick Fochtman
Organization: Board of Trade Clearing Corporation
Subject: Re: Homework: Negative side of MVS?
> Ummm .... "Top heavy"? "A good deal larger"? And your reasons for the
> assertion?
>
> And even if we stipulate that you are correct, you've not shown that for
> performance paths or even "standard" paths (whatever those might be) OS/390's
> history comes into play in a detrimental way.
>
> I'm not going to say you're wrong. You've simply not demonstrated your case but
> merely averred that it is true.
>
I have to agree that OS/390 is considerably larger than the original OS/360
operating system. But the functionality has also grown considerably, perhaps beyond
the mere size in bytes would indicate. And the reliability has improved
immeasurably! I have to take the attitude that growth isn't necessarily bad,
although it can be. Top heavy? Perhaps if you're not using all that additional
function, it does seem to be top heavy. On the other hand, if you're using that
function to enhance your business, then it's not top heavy at all.
What I see as the biggest "problem" with OS/390 is this: all these new functions,
etc. are very poorly documented. Guys like me, who have no recourse but to plod our
way through manuals, don't really get a "sense" of how these new functions work, or
how they can be applied to company business. The "rainbow" books are helpful,
sometimes, but often our only resource is the rare IBM'er who's using these things,
or discussion groups like this one. And because so much is now OCO, we can't "pound
our way through the code" to try and see what's going on when things fail. Don't
even suggest going to IBM classes; they're expensive and can only give a very broad
overview in the time alloted. And those classes are getting scarcer and scarcer,
adding travel money to class expenses. While I can't speak for others in the group,
I personally HATE to travel for business; too many bad experiences with airlines
losing luggage, overbooked flights and hotels, etc.
IBM needs to get off its corporate "A.." and start doing a better job of DOCUMENTING
all these new "bells and whistles"; how-to books as well as "what it is" books. And
a wider variety of sample code.
Date: Thu, 20 Jan 2000 07:10:48 -0600
From: Rick Fochtman
Organization: Board of Trade Clearing Corporation
Subject: Re: Homework: Negative side of MVS?
Mark Thomen wrote:
> ...........
> Don't forget that when they say every cloud has a silver lining, that there is
> STILL a cloud there...
Mark, while I've never been a IBM'er, I sympathize with some of your experiences
with "customer mods". But until IBM can provide better external interfaces in some
of these problem areas, these types of problems are going to continue. Things are
improving slowly, with a wider variety of exit points, etc. but there's still a
significant gap between customer "wish lists" and exit capabilities.
Date: Thu, 20 Jan 2000 07:54:25 -0600
From: "Chase, John"
Subject: Re: Homework: Negative side of MVS?
On Wednesday, January 19, 2000 9:03 PM, Joe Zitzelberger
[SMTP:zberger@KNOLOGY.NET] wrote:
> >>=Jeffrey Broido at jbroido@PERSHING.COM said on 1/19/00 14:49=<<
> >As a result of this, the system is top heavy and a good deal larger than
> >if it had been written today, even for the original 1957 S/360 system
> >architecture.
>
> But if it were written today it would come on 35 high density DVDs and
> have a dancing paper-clip!
More likely a "friendly octopus". ;-)
-jc-
Date: Thu, 20 Jan 2000 14:29:49 GMT
From: reza heydarpour
Subject: Re: Homework: Negative side of MVS?
'age' is only regarded 'bad' in the west, a lot of people associate
age with 'wisdom' & 'maturity' & respect it.
...Reza
>>The major weakness of OS/390, I think, is its age and its set of
>>age-related problems.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Date: Thu, 20 Jan 2000 10:02:22 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
What's the problem? IBM promised us that they would provide good
documentation prior to going OCO.
Forget the customer: IBM could make things a lot better by at least giving
their own personnel adequate documentation and training.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Rick Fochtman [SMTP:Rick.Fochtman@BOTCC.COM]
> Sent: Thursday, January 20, 2000 8:03 AM
>
> IBM needs to get off its corporate "A.." and start doing a better job of
> DOCUMENTING
> all these new "bells and whistles"; how-to books as well as "what it is"
> books. And
> a wider variety of sample code.
>
Date: Thu, 20 Jan 2000 09:50:23 -0600
From: Craig Otway
Subject: Re: Homework: Negative side of MVS? / Late night
AMEN. Being four years into the systems side of 390 that has been the =
most frustrating aspect of this learning curve. My boss, the almost =
retired mentor, does an excellent job with assignments that speed up the =
process but, if you want to attract the younger crowd we must make the =
curve more obtainable. I represent the small shop customizing and =
supporting DB2, CICS, RACF, VTAM, NT stuff... Vendors help on their =
installs buy saying more in the books than "Now see the RACF sysprog =
and do that". The Vendors also hurt us with the MSU/MIPS/MODEL cap. We =
need more horsepower to do what IBM is asking but can't afford to go up =
to another machine without all of the existing third party software =
that's already running costing twice as much. If they want to compete =
with SUN then why does the C compiler cost so much? I could do NT, UNIX =
or network stuff all day because the documentation is available, and =
some days I wish I had. Most of the network kids I talk too today don't =
know what MVS is, or care, but if you say "CISCO" well, your cool. Lets =
have less e-commercials and more E xcellent-doc/cookbooks.
"Rick Fochtman" wrote in message =
news:38870776.C20291F2@BOTCC.com...
> What I see as the biggest "problem" with OS/390 is this: all these new =
functions,
> etc. are very poorly documented. Guys like me, who have no recourse =
but to plod our
> way through manuals, don't really get a "sense" of how these new =
functions work, or
> how they can be applied to company business. The "rainbow" books are =
helpful,
> sometimes, but often our only resource is the rare IBM'er who's using =
these things,
> or discussion groups like this one. And because so much is now OCO, =
we can't "pound
> our way through the code" to try and see what's going on when things =
fail. Don't
> even suggest going to IBM classes; they're expensive and can only give =
a very broad
> overview in the time alloted. And those classes are getting scarcer =
and scarcer,
> adding travel money to class expenses. While I can't speak for others =
in the group,
> I personally HATE to travel for business; too many bad experiences =
with airlines
> losing luggage, overbooked flights and hotels, etc.
>=20
> IBM needs to get off its corporate "A.." and start doing a better job =
of DOCUMENTING
> all these new "bells and whistles"; how-to books as well as "what it =
is" books. And
> a wider variety of sample code.
>
>=20
Date: Thu, 20 Jan 2000 11:48:37 -0500
From: Jeffrey Broido
Subject: Homework: Negative side of MVS?
Shmuel,
According to what I have read and verbal history, much of it from Dave
Freeman (the lead developer of the first S/360 assembler and TOS/DOS, referred
to as "Mr. DOS" in old Systems Journals) the working S/360 architecture was
already in place in 1957 and cross development, using an emulator running on
709x systems, had already started.
I was, indeed, thinking of the older versions of TCP/IP when I mentioned
Pascal, though there were rumors in the late 1970s that IBM had, at least, been
toying with it for OS development.
As for the secrecy of microcode, I base my statement upon what I read in
the manuals, themselves. I refer specifically to the hardware manual set, in
oversized blue (what else?) binders generally stored in a wire rack under the
standard oscilloscope cart, for the 360/67 we had at Rutgers University in the
early 1970s. On each page of these manuals, including the ones which listed the
microcode, the function of the DIAGNOSE instruction for that model, etc., was a
footer in large type stating that the material was for IBM eyes only. This was
stated in detail at the front of each manual.
One of IBM's initial marketing assets (aside from the superior quality of
their hardware) was not only open source code but the fact that the software was
bundled with the hardware. All of the software was free in the early days of
OS/360 and, as you certainly know, IBM had to be sued by the Justice Department
to start charging for it (the famous unbundling case of 1975-1982). The result
of IBM's settlement was, indirectly, the independent software market as we know
it today. The result of OCO might well be IBM's next disaster, at least in my
humble opinion.
Jeff
>Date: Wed, 19 Jan 2000 15:05:08 -0500
>From: "Metz, Seymour"
>Subject: Re: Homework: Negative side of MVS?
>I suspect that less has been rewritten then you were hoping.
>AFAIK none of the MVS code was ever written in Pascal; perhaps you were
>thinking of TCP/IP rather than MVS. Also, I don't know when IBM started, but
>1957 sounds way to early.
>"OCO, just say no!" IBM had a prime marketing asset and discarded it without
>ever realizing its value. Well, the Linux folks understand the importance of
>making the source code universally accessible.
>BTW, the microcode was *not* secret; anyone who wanted to could purchase the
>hardware manuals that documented the programming for their model of
>interest. If you wanted to get a copy of the actual microcode, you had to
>supply a serial number, since the code was tied to a specific EC level, but
>that didn't add a significant amount of time to the order cycle. What IBM
>would not give or sell you was the compiler (e.g., CAS, MLS) used to
>translate the "microcode" from a symbolic form to a numeric form.
>Shmuel (Seymour J.) Metz
Date: Thu, 20 Jan 2000 12:41:38 -0500
From: James Antognini
Organization: IBM Global Services North -- Burlington, Vermont, USA
Subject: Re: Homework: Negative side of MVS?
Ah, documentation. Always a sore point with me. Let's expand the discussion to
electronic documentation to include CDs.
I use BookManager Read to view IBM CDs. For looking up a particular piece of
information, it's pretty good, especially because I can search for a string,
even across a bookshelf. So I'm not at the mercy of whoever wrote the index and
the table of contents.
But I find studying material electronically presented way too hard. For that (I
mean reading a lot of material, perhaps flipping back and forth), paper is
easier. Too bad the IBM CDs don't include .pdf or .ps copies of the books, which
one could print. (I find the quality of printing of sections in BookManager Read
not good.)
What I find more troubling than the "quality of experience" with electronic
documentation is the quality of information, its organization, detail, etc. IBM
at least has a history of good materials, so that carries forward in its
electronic documentation in OS/390. I've the feeling that other companies,
however, are much less demanding, that the electronic media somehow invite a
cavalier attitude in producing (paying for) documentation. In cases like that,
not only does the user have to struggle with OCO, but the docs verge on and even
amble well into the realm of the egregious.
--
James Antognini
IBM Watson Research
Date: Thu, 20 Jan 2000 13:06:19 -0500
From: Jeffrey Broido
Subject: Homework: Negative side of MVS?
Mr. Antognini,
Indeed, I concede that I have demonstrated nothing. On the other hand, the
opinion pieces in this forum have rarely been proved; they are just that,
opinions. Still, I maintain this opinion.
Do not confuse this with a vehement criticism; I am still a big fan of this
operating system family and, even more, the quality of IBM's hardware. I've
seen and worked with a lot of computers in my time, including mainframes and
supposed mainframes from other vendors such as Univac, Burroughs, RCA, DEC, GE,
Honeywell, among others, and I never found anything to touch the hem of IBM's
hardware quality (partisan issues of competing mainframe architecture issues
notwithstanding). Indeed, this, too, is unsubstantiated opinion, but I expect
you'll let me get away with it as it is blushingly uncritical.
Jeff Broido
>Date: Wed, 19 Jan 2000 17:25:58 -0500
>From: James Antognini
>Subject: Re: Homework: Negative side of MVS?
>> As a result of this, the system is top heavy and a good deal larger than if
>> it had been written today, even for the original 1957 S/360 system
architecture.
>Ummm .... "Top heavy"? "A good deal larger"? And your reasons for the
>assertion?
>And even if we stipulate that you are correct, you've not shown that for
>performance paths or even "standard" paths (whatever those might be) OS/390's
>history comes into play in a detrimental way.
>I'm not going to say you're wrong. You've simply not demonstrated your case but
>merely averred that it is true.
> James Antognini
> IBM Watson Research
Date: Thu, 20 Jan 2000 13:24:52 -0500
From: Jeffrey Broido
Subject: Homework: Negative side of MVS?
Mark,
Actually, I do agree that OS/PCP/MFT/MVT/VS1/SVS/MVS/XA/ESA/390's maturity
is quite an asset as well as a weakness. I wasn't being arbitrarily negative,
however, when I listed it as a weakness; I was merely responding to the original
request for a list of negative attributes. Nor do I think it odd or
contradictory for an attribute to be considered both a positive and a negative
asset. I just mentioned my opinion regarding the latter aspect in response to
this original request.
Have you read "Mythical Man Month"? In it, Brooks is surprisingly critical
of the way he, himself, managed the project, which is not to say that there
would, at that time, necessarily have been a more effective way to do it.
Specifically, he mentions the minute granularity/modularity of the code and the
fact that, due in part to the unprecedented scope of the project, none of the
coders had any idea of what they were doing beyond satisfying the entry and exit
requirements of their particular small modules.
Again, don't get me wrong. My intent is not to ridicule IBM; far from it.
Nor do I intend to besmirch the current quality of OS/390, which is clearly
better than even OS/MVT 19.6, my ancient benchmark for quality and stability.
Even so, despite the many bugs and frequent crashes in the old days, I would
give my eye teeth and much more to go back and work again in those heady,
pioneering times I experienced thirty plus years ago. Regards,
Jeff Broido
>Date: Wed, 19 Jan 2000 14:45:19 -0800
>From: Mark Thomen
>Subject: Re: Homework: Negative side of MVS?
>Jeffrey Broido wrote:
>> The major weakness of OS/390, I think, is its age and its set
of
>> age-related problems.
>That's funny; I view its "maturity" as one of its assets, not a weakness. (I'm
>personally a little sensitive of the use of the word "age", and prefer
"maturity").
>> OS/360 was written in Assembler, starting in the late '50s, by thousands
of
>> programmers, most of them recent college graduates who had never done any
>> programming
>And of course, neither had anyone else in the industry (such that it even was
at
>that point)...
>> Despite its age, there is actually some code in OS/390 left over from
those
>> early days. Most of it, of course, has been rewritten. Even so, much of
the
>> current code is a fossil of the original, having been rewritten and
rewritten
>> over the years to add function, change the language to PL/S, PASCAL, C,
etc.,
>> but the basic function is often transferred intact from version to version.
>This is a weakness? You don't really want "basic function" to change from
version
>to version, do you?
> Mark Thomen
> DFSMS Development - Catalog, IDCAMS, and VSAM
Date: Thu, 20 Jan 2000 10:36:05 -0500
From: Jon Brock
Subject: Re: Homework: Negative side of MVS?
It's not that age is bad - the alternative is worse - but that the wisdom
and maturity are optional, whereas the aches and pains and deterioration
seem to be mandatory.
Jon
-----Original Message-----
From: reza heydarpour [SMTP:rezahey@HOTMAIL.COM]
Sent: Thursday, January 20, 2000 9:30 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Homework: Negative side of MVS?
'age' is only regarded 'bad' in the west, a lot of people associate
age with 'wisdom' & 'maturity' & respect it.
Date: Thu, 20 Jan 2000 12:28:42 -0600
From: "Edward(Ed) J. Finnell,III"
Organization: The University of Alabama
Subject: Re: Homework: Negative side of MVS?
With OS/390 2.7 your problems should be solved. They ship in .PDF.
James Antognini wrote:
>
> Ah, documentation. Always a sore point with me. Let's expand the discussion to
> electronic documentation to include CDs.
>
> I use BookManager Read to view IBM CDs. For looking up a particular piece of
> information, it's pretty good, especially because I can search for a string,
> even across a bookshelf. So I'm not at the mercy of whoever wrote the index and
> the table of contents.
>
> But I find studying material electronically presented way too hard. For that (I
> mean reading a lot of material, perhaps flipping back and forth), paper is
> easier. Too bad the IBM CDs don't include .pdf or .ps copies of the books, which
> one could print. (I find the quality of printing of sections in BookManager Read
> not good.)
>
> What I find more troubling than the "quality of experience" with electronic
> documentation is the quality of information, its organization, detail, etc. IBM
> at least has a history of good materials, so that carries forward in its
> electronic documentation in OS/390. I've the feeling that other companies,
> however, are much less demanding, that the electronic media somehow invite a
> cavalier attitude in producing (paying for) documentation. In cases like that,
> not only does the user have to struggle with OCO, but the docs verge on and even
> amble well into the realm of the egregious.
>
> --
> James Antognini
> IBM Watson Research
Date: Thu, 20 Jan 2000 10:03:49 -0800
From: Mark Thomen
Organization: DFSMS Development - Catalog, VSAM, IDCAMS
Subject: Re: Homework: Negative side of MVS?
I'll bring the topic up again: Unless we know what you want improved, you're at
someone else's mercy. If you have problems with existing interfaces, open
requirements. If you need new interfaces, open requirements.
You can grumble here all you want, but it doesn't feed into our formal development
process. Don't complain that "it takes too long when we ask for it", because it will
DEFINITELY take longer if you don't even ask. Don't assume someone else has asked for
it, because they assume the same of you. And the more requirements we get on the same
topic/interface, the more likely it will be to get attention.
Rick Fochtman wrote:
>
>
> Mark Thomen wrote:
>
> > ...........
>
> > Don't forget that when they say every cloud has a silver lining, that there is
> > STILL a cloud there...
>
>
>
> Mark, while I've never been a IBM'er, I sympathize with some of your experiences
> with "customer mods". But until IBM can provide better external interfaces in some
> of these problem areas, these types of problems are going to continue. Things are
> improving slowly, with a wider variety of exit points, etc. but there's still a
> significant gap between customer "wish lists" and exit capabilities.
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
"Technical Database")
or http://knowledge.storage.ibm.com/
Date: Thu, 20 Jan 2000 10:06:05 -0800
From: Mark Thomen
Organization: DFSMS Development - Catalog, VSAM, IDCAMS
Subject: Re: Homework: Negative side of MVS?
I'll bring the topic up again: Unless we know what you want improved, you're at someone
else's mercy. If you have problems with existing documentation, open RCFs. If you need
new documents, open RCFs.
You can grumble here all you want, but it doesn't feed into our formal information
development process. Don't complain that "it takes too long when we ask for it",
because it will DEFINITELY take longer if you don't even ask. Don't assume someone else
has asked for it, because they assume the same of you. And the more requirements we get
on the same documentation, the more likely it will be to get attention.
(Yes, this append looks suspiciously like another one, because the principle is the
same...)
Rick Fochtman wrote:
> What I see as the biggest "problem" with OS/390 is this: all these new functions,
> etc. are very poorly documented. Guys like me, who have no recourse but to plod our
> way through manuals, don't really get a "sense" of how these new functions work, or
> how they can be applied to company business. The "rainbow" books are helpful,
> sometimes, but often our only resource is the rare IBM'er who's using these things,
> or discussion groups like this one. And because so much is now OCO, we can't "pound
> our way through the code" to try and see what's going on when things fail. Don't
> even suggest going to IBM classes; they're expensive and can only give a very broad
> overview in the time alloted. And those classes are getting scarcer and scarcer,
> adding travel money to class expenses. While I can't speak for others in the group,
> I personally HATE to travel for business; too many bad experiences with airlines
> losing luggage, overbooked flights and hotels, etc.
>
> IBM needs to get off its corporate "A.." and start doing a better job of DOCUMENTING
> all these new "bells and whistles"; how-to books as well as "what it is" books. And
> a wider variety of sample code.
>
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
"Technical Database")
or http://knowledge.storage.ibm.com/
Date: Thu, 20 Jan 2000 13:55:04 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
While he may have created the impression that he was self critical, the
author at several points blamed external factors for what was actually poor
design. A good case in point is his explanation of why TESTRAN was not
popular, an explanation that was plausible only if one postulates a time
machine.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Jeffrey Broido [SMTP:jbroido@PERSHING.COM]
> Sent: Thursday, January 20, 2000 1:25 PM
>
> Have you read "Mythical Man Month"? In it, Brooks is surprisingly
> critical
> of the way he, himself, managed the project,
Date: Thu, 20 Jan 2000 14:05:56 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
Re 1957; I would have thought that all of the key players would have been
tied up in Project Stretch. There have been published references to the use
of the 7090 for running, e.g., S/360 simulator, CAS.
Re "microcode";
Well, I've never seen the documentation for the microcode on the 2067,
although I would expect it to be nearly identical to the microcode on the
2065. However, I still have documentation on several other S/360 and S/370
models, and not a one of them is a ZZ.
Unbundling was a case of "Please don't throw me in the briar patch." IBM may
have found ADR and DOJ to be convenient scapegoats, but they unbundled
because they were able to take in more revenue that way. IBM would have
unbundled for economic reasons even without those law suits. Also, the
Federal antitrust case was a lost cause by then: DOJ had fumbled it badly.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Jeffrey Broido [SMTP:jbroido@PERSHING.COM]
> Sent: Thursday, January 20, 2000 11:49 AM
>
> According to ... the working S/360 architecture was
> already in place in 1957 and cross development, using an emulator
> running on
> 709x systems, had already started.
>
> As for the secrecy of microcode, I base my statement upon what I
> read in
> the manuals, themselves. I refer specifically to the hardware manual
> set, in
> oversized blue (what else?) binders generally stored in a wire rack
> under the
> standard oscilloscope cart, for the 360/67 we had at Rutgers University
>
> ...
>
> as you certainly know, IBM had to be sued by the Justice Department
> to start charging for it (the famous unbundling case of 1975-1982). The
> result
> of IBM's settlement was, indirectly, the independent software market as
> we know
> it today. The result of OCO might well be IBM's next disaster, at least
> in my
> humble opinion.
Date: Thu, 20 Jan 2000 11:15:03 -0800
From: Bob Halpern
Organization: CPU
Subject: Re: Homework: Negative side of MVS?
My understanding is that from stretch came the circuitry for the 1401,
7044, 7094, etc. I did run SUPPAK, the 360 assembler/simulator on the
7094. I also remember the simulator had SVC 0 for EXIT and SVC 3 for
EXCP. Poor real os did not have a chance with those programs in the
very early days. (I worked on pre-release 1 of os/360).
"Metz, Seymour" wrote:
>
> Re 1957; I would have thought that all of the key players would have been
> tied up in Project Stretch. There have been published references to the use
> of the 7090 for running, e.g., S/360 simulator, CAS.
>
> Re "microcode";
>
> Well, I've never seen the documentation for the microcode on the 2067,
> although I would expect it to be nearly identical to the microcode on the
> 2065. However, I still have documentation on several other S/360 and S/370
> models, and not a one of them is a ZZ.
>
> Unbundling was a case of "Please don't throw me in the briar patch." IBM may
> have found ADR and DOJ to be convenient scapegoats, but they unbundled
> because they were able to take in more revenue that way. IBM would have
> unbundled for economic reasons even without those law suits. Also, the
> Federal antitrust case was a lost cause by then: DOJ had fumbled it badly.
>
> Shmuel (Seymour J.) Metz
>
> > -----Original Message-----
> > From: Jeffrey Broido [SMTP:jbroido@PERSHING.COM]
> > Sent: Thursday, January 20, 2000 11:49 AM
> >
> > According to ... the working S/360 architecture was
> > already in place in 1957 and cross development, using an emulator
> > running on
> > 709x systems, had already started.
> >
> > As for the secrecy of microcode, I base my statement upon what I
> > read in
> > the manuals, themselves. I refer specifically to the hardware manual
> > set, in
> > oversized blue (what else?) binders generally stored in a wire rack
> > under the
> > standard oscilloscope cart, for the 360/67 we had at Rutgers University
> >
> > ...
> >
> > as you certainly know, IBM had to be sued by the Justice Department
> > to start charging for it (the famous unbundling case of 1975-1982). The
> > result
> > of IBM's settlement was, indirectly, the independent software market as
> > we know
> > it today. The result of OCO might well be IBM's next disaster, at least
> > in my
> > humble opinion.
Date: Thu, 20 Jan 2000 14:45:59 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
Project Stretch was undoubtedly the most successful "failure" in the history
of computers; a long laundry list of technologies derived from it, including
a core memory used into the S/360 line, the channel architecture leading up
to the S/360, the (misused in the last few decades) word "byte" and several
families of peripheral devices. It was a rcih harvest indeed. I
can't think of a single IBM computer that I worked on since the 650 that
didn't owe something to Stretch.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Bob Halpern [SMTP:Bob@CPUPERFORM.COM]
> Sent: Thursday, January 20, 2000 2:15 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Homework: Negative side of MVS?
>
> My understanding is that from stretch came the circuitry for the 1401,
> 7044, 7094, etc.
Date: Thu, 20 Jan 2000 12:55:25 -0800
From: Wayne Driscoll
Subject: Re: Homework: Negative side of MVS?
I've been avoiding this, but this one begs for a response...
Specifically, he mentions the minute
granularity/modularity of the code and the
fact that, due in part to the unprecedented scope of the project, none of
the
coders had any idea of what they were doing beyond satisfying the entry and
exit
requirements of their particular small modules.
Correct me if I'm wrong, but isn't the above alleged negative the same
technique that has been pushed for the last 10-15 years as one of the
greatest strengths of "Object Oriented Programming?" Funny how the more
things change, the more they stay the same.
Wayne Driscoll
Product Developer
Quest Software Inc.
wdriscoll@quest.com
Note: All opinions are strictly my own.
Date: Thu, 20 Jan 2000 15:04:39 -0600
From: Rick Fochtman
Organization: Board of Trade Clearing Corporation
Subject: Re: Homework: Negative side of MVS?
I fill out reader comment forms RELIGIOUSLY; and I've made similar comments on closed
ETR's, etc. Maybe I'm just a single voice in the cacaphony of electronic "noise".
Mark Thomen wrote:
> I'll bring the topic up again: Unless we know what you want improved, you're at
> someone else's mercy. If you have problems with existing interfaces, open
> requirements. If you need new interfaces, open requirements.
>
> You can grumble here all you want, but it doesn't feed into our formal development
> process. Don't complain that "it takes too long when we ask for it", because it will
> DEFINITELY take longer if you don't even ask. Don't assume someone else has asked for
> it, because they assume the same of you. And the more requirements we get on the same
> topic/interface, the more likely it will be to get attention.
>
> Rick Fochtman wrote:
>
> >
> >
> > Mark Thomen wrote:
> >
> > > ...........
> >
> > > Don't forget that when they say every cloud has a silver lining, that there is
> > > STILL a cloud there...
> >
> >
> >
> > Mark, while I've never been a IBM'er, I sympathize with some of your experiences
> > with "customer mods". But until IBM can provide better external interfaces in some
> > of these problem areas, these types of problems are going to continue. Things are
> > improving slowly, with a wider variety of exit points, etc. but there's still a
> > significant gap between customer "wish lists" and exit capabilities.
>
> --
> Mark Thomen
> DFSMS Development - Catalog, IDCAMS, and VSAM
>
> Try the Catalog and VSAM Knowledge Base at:
> http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
> "Technical Database")
> or http://knowledge.storage.ibm.com/
Date: Thu, 20 Jan 2000 12:55:40 -0800
From: Mark Thomen
Organization: DFSMS Development - Catalog, VSAM, IDCAMS
Subject: Re: Homework: Negative side of MVS?
And you aren't listening to what I'm telling you: This newsgroup is not, never has been, and
never will be a formal input to the IBM development process requirements.
Michael J Porter wrote:
> In article <38874E8D.18E26D41@us.ibm.com>,
> Mark Thomen wrote:
> =>I'll bring the topic up again: Unless we know what you want improved, you're at someone
> =>else's mercy. If you have problems with existing documentation, open RCFs. If you need
> =>new documents, open RCFs.
> =>
> =>You can grumble here all you want, but it doesn't feed into our formal information
> =>development process.
>
> The sentence above tells me you aren't even listing to what we are
> saying.
>
> Mike
> --
> ===
> Mike Porter
> PGP Fingerprint: F4 AE E1 9F 67 F7 DA EA 2F D2 37 F3 99 ED D1 C2
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click "Technical
Database")
or http://knowledge.storage.ibm.com/
Date: Thu, 20 Jan 2000 15:12:12 -0600
From: Rick Fochtman
Organization: Board of Trade Clearing Corporation
Subject: Re: Homework: Negative side of MVS?
Wasn't STRETCH the 7030?? 72-bit word and all that stuff?
Bob Halpern wrote:
> My understanding is that from stretch came the circuitry for the 1401,
> 7044, 7094, etc. I did run SUPPAK, the 360 assembler/simulator on the
> 7094. I also remember the simulator had SVC 0 for EXIT and SVC 3 for
> EXCP. Poor real os did not have a chance with those programs in the
> very early days. (I worked on pre-release 1 of os/360).
>
> "Metz, Seymour" wrote:
> >
> > Re 1957; I would have thought that all of the key players would have been
> > tied up in Project Stretch. There have been published references to the use
> > of the 7090 for running, e.g., S/360 simulator, CAS.
> >
> > Re "microcode";
> >
> > Well, I've never seen the documentation for the microcode on the 2067,
> > although I would expect it to be nearly identical to the microcode on the
> > 2065. However, I still have documentation on several other S/360 and S/370
> > models, and not a one of them is a ZZ.
> >
> > Unbundling was a case of "Please don't throw me in the briar patch." IBM may
> > have found ADR and DOJ to be convenient scapegoats, but they unbundled
> > because they were able to take in more revenue that way. IBM would have
> > unbundled for economic reasons even without those law suits. Also, the
> > Federal antitrust case was a lost cause by then: DOJ had fumbled it badly.
> >
> > Shmuel (Seymour J.) Metz
> >
> > > -----Original Message-----
> > > From: Jeffrey Broido [SMTP:jbroido@PERSHING.COM]
> > > Sent: Thursday, January 20, 2000 11:49 AM
> > >
> > > According to ... the working S/360 architecture was
> > > already in place in 1957 and cross development, using an emulator
> > > running on
> > > 709x systems, had already started.
> > >
> > > As for the secrecy of microcode, I base my statement upon what I
> > > read in
> > > the manuals, themselves. I refer specifically to the hardware manual
> > > set, in
> > > oversized blue (what else?) binders generally stored in a wire rack
> > > under the
> > > standard oscilloscope cart, for the 360/67 we had at Rutgers University
> > >
> > > ...
> > >
> > > as you certainly know, IBM had to be sued by the Justice Department
> > > to start charging for it (the famous unbundling case of 1975-1982). The
> > > result
> > > of IBM's settlement was, indirectly, the independent software market as
> > > we know
> > > it today. The result of OCO might well be IBM's next disaster, at least
> > > in my
> > > humble opinion.
Date: Thu, 20 Jan 2000 16:18:28 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
Yes. No.
The physical memory was a 72-bit word but that was 64-bit word plus
checking. The same memory was later used you-know where as 2 36-bit words in
one physical 72-bit word. The Exchange was the grand-daddy of the S/360 I/O
architecture, although there were significant shifts in functional
boundaries along the way.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Rick Fochtman [SMTP:Rick.Fochtman@BOTCC.COM]
> Sent: Thursday, January 20, 2000 4:12 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Homework: Negative side of MVS?
>
> Wasn't STRETCH the 7030?? 72-bit word and all that stuff?
Date: Thu, 20 Jan 2000 14:32:34 -0800
From: Wayne White
Subject: Re: Homework: Negative side of MVS?
In-Reply-To: <3887764C.929A4417@us.ibm.com>
Mark:
You are IBM Development?; you make decisions about what is valid, useful
and doable?; I know there are formal mechanisms for talking to IBM, but it
would seem to me that if you were getting input, even from this "informal"
channel, that would be 1 factor in your decision process into what is
designed and implemented. What your response says to me is that this "real
world" info from this group is just chatter to you as a developer, and pro
forma ignored when you make product direction decisions. I wouldn't think
anyone expects that ideas presented here become committed projects for IBM,
but I would like to think that the ideas and requests, even the bitches,
are accepted input, and after your critical analysis, included in your
considerations for product direction if they have merit.
Wayne
At 12:55 PM 01/20/2000 , you wrote:
>And you aren't listening to what I'm telling you: This newsgroup is not,
>never has been, and
>never will be a formal input to the IBM development process requirements.
>
>Michael J Porter wrote:
>
>> In article <38874E8D.18E26D41@us.ibm.com>,
>> Mark Thomen wrote:
>> =>I'll bring the topic up again: Unless we know what you want improved,
>you're at someone
>> =>else's mercy. If you have problems with existing documentation, open
>RCFs. If you need
>> =>new documents, open RCFs.
>> =>
>> =>You can grumble here all you want, but it doesn't feed into our formal
>information
>> =>development process.
>>
>> The sentence above tells me you aren't even listing to what we are
>> saying.
>>
>> Mike
Date: Thu, 20 Jan 2000 17:01:20 -0800
From: Tom Bishop
Subject: Re: Homework: Negative side of MVS? -Reply
Yes , it was the 7030. In Planning a Computer System, a book which describes
the 7030 development, on page 17 it says "A memory word consists of 64
information bits and 8 check bits for automatic single-error and double-error
detection."
Page 40 defines "Byte denotes a group of bits used to encode a character, or
the number of bits transmitted in parallel to and from input-output units.".
Size is not defined and is assumed to be variable.
It also allowed arithmetic operations on fields that crossed a word boundary.
>>> Rick Fochtman 01/20 1:12 pm >>>
Wasn't STRETCH the 7030?? 72-bit word and all that stuff?
Bob Halpern wrote:
> My understanding is that from stretch came the circuitry for the 1401,
> 7044, 7094, etc. I did run SUPPAK, the 360 assembler/simulator on the
> 7094. I also remember the simulator had SVC 0 for EXIT and SVC 3 for
> EXCP. Poor real os did not have a chance with those programs in the
> very early days. (I worked on pre-release 1 of os/360).
>
> "Metz, Seymour" wrote:
> >
> > Re 1957; I would have thought that all of the key players would have been
> > tied up in Project Stretch. There have been published references to the use
> > of the 7090 for running, e.g., S/360 simulator, CAS.
> >
> > Re "microcode";
> >
> > Well, I've never seen the documentation for the microcode on the 2067,
> > although I would expect it to be nearly identical to the microcode on the
> > 2065. However, I still have documentation on several other S/360 and S/370
> > models, and not a one of them is a ZZ.
> >
> > Unbundling was a case of "Please don't throw me in the briar patch." IBM
may
> > have found ADR and DOJ to be convenient scapegoats, but they unbundled
> > because they were able to take in more revenue that way. IBM would have
> > unbundled for economic reasons even without those law suits. Also, the
> > Federal antitrust case was a lost cause by then: DOJ had fumbled it badly.
> >
> > Shmuel (Seymour J.) Metz
> >
> > > -----Original Message-----
> > > From: Jeffrey Broido [SMTP:jbroido@PERSHING.COM]
> > > Sent: Thursday, January 20, 2000 11:49 AM
> > >
> > > According to ... the working S/360 architecture was
> > > already in place in 1957 and cross development, using an emulator
> > > running on
> > > 709x systems, had already started.
> > >
> > > As for the secrecy of microcode, I base my statement upon what I
> > > read in
> > > the manuals, themselves. I refer specifically to the hardware manual
> > > set, in
> > > oversized blue (what else?) binders generally stored in a wire rack
> > > under the
> > > standard oscilloscope cart, for the 360/67 we had at Rutgers University
> > >
> > > ...
> > >
> > > as you certainly know, IBM had to be sued by the Justice Department
> > > to start charging for it (the famous unbundling case of 1975-1982). The
> > > result
> > > of IBM's settlement was, indirectly, the independent software market as
> > > we know
> > > it today. The result of OCO might well be IBM's next disaster, at
least
> > > in my
> > > humble opinion.
Date: Thu, 20 Jan 2000 16:53:21 -0800
From: Mark Thomen
Organization: DFSMS Development - Catalog, VSAM, IDCAMS
Subject: Re: Homework: Negative side of MVS?
Yes, yes, yes, and yes. But you have to understand - no matter how much I *like*
something, or think it should go into the product, I can't just "slip" them in.
Some things I can get away with doing like this, but most I can't. Someone wants
better or more explicit return/reason codes from our interface, I can schedule those
into a release as a serviceability line item. But you want a new interface? I've
got to convince the same "business case" folks that any other external requirement
has to convince. As a result of some of the input here (and yes, the bitching)
there are changes that I've made to some of our plans. But the net of this is that
I am limited by the scope of changes I can make strictly as a result of a random
newsgroup item.
Business case - that's the key term. If I'm going to dedicate a limited resource
(e.g. me, or my team) to putting some enhancement in the product, I have to be able
to justify that it is a more important allocation of the resource than the customer
and corporate requirements that are placed in front of me. So understand: Formal
requirements go through the official process and stand a greater chance of getting
accepted than me trying to do it "on the fly".
The other thing you have to remember is that not all people in IBM that are in a
position to address issues brought up here monitor this newsgroup. And the rest of
us don't have the time to get all these wish-list items off to the right person(s)
in the company. It's simply not possible to do and get our regular jobs done.
So, do I try to do the things I can based on what I hear on this newsgroup? Yes.
But you have to understand, since this is NOT the official mechanism for requesting
product enhancements from IBM, the proper way to ask for those new externals,
externals changes, documentation improvements, etc., etc., is to USE THE OFFICIAL
IBM PROCESSES. Contact your branch office if you want to learn more. Submitting
requirements is not that hard, and you WILL get an official response to them.
Wayne White wrote:
> Mark:
> You are IBM Development?; you make decisions about what is valid, useful
> and doable?; I know there are formal mechanisms for talking to IBM, but it
> would seem to me that if you were getting input, even from this "informal"
> channel, that would be 1 factor in your decision process into what is
> designed and implemented. What your response says to me is that this "real
> world" info from this group is just chatter to you as a developer, and pro
> forma ignored when you make product direction decisions. I wouldn't think
> anyone expects that ideas presented here become committed projects for IBM,
> but I would like to think that the ideas and requests, even the bitches,
> are accepted input, and after your critical analysis, included in your
> considerations for product direction if they have merit.
>
> Wayne
>
> At 12:55 PM 01/20/2000 , you wrote:
> >And you aren't listening to what I'm telling you: This newsgroup is not,
> >never has been, and
> >never will be a formal input to the IBM development process requirements.
> >
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
"Technical Database")
or http://knowledge.storage.ibm.com/
Date: Fri, 21 Jan 2000 09:07:50 -0500
From: Scott Harder
Subject: Re: Homework: Negative side of MVS?
> -----Original Message-----
> From: Behalf Of Wayne White
> Sent: Thursday, January 20, 2000 5:33 PM
>
> Mark:
> You are IBM Development?; you make decisions about
> what is valid, useful
> and doable?; I know there are formal mechanisms for talking
> to IBM, but it
> would seem to me that if you were getting input, even from
> this "informal"
> channel, that would be 1 factor in your decision process into what is
> designed and implemented.
< snip >
Wrong. You cannot hold IBM accountable for anything discussed in this, or
any other, newsgroup. This is not IBM - it's IBM-MAIN. As Mark said, there
are official routes that must be taken. Instead of flaming the IBM'ers we
have that post to this list, we should consider ourselves extremely lucky to
have their input - even though it is unofficial.
Scott
Date: Fri, 21 Jan 2000 09:41:24 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS? -Reply
> That book is old and obsolete; I believe that I can find you someone to
> take
> it off of your hands.
>
> Shmuel (Seymour J.) Metz
>
> > -----Original Message-----
> > From: Tom Bishop [SMTP:Tbishop@ITA.CI.LA.CA.US]
> > Sent: Thursday, January 20, 2000 8:01 PM
> >
> > Yes , it was the 7030. In Planning a Computer System,
Date: Fri, 21 Jan 2000 08:48:43 -0600
From: Rick Fochtman
Organization: Board of Trade Clearing Corporation
Subject: Re: Homework: Negative side of MVS? -Reply
Person found. Pvt. E-Mail and we'll make the arrangements. :-)
"Metz, Seymour" wrote:
> > That book is old and obsolete; I believe that I can find you someone to
> > take
> > it off of your hands.
> >
> > Shmuel (Seymour J.) Metz
> >
> > > -----Original Message-----
> > > From: Tom Bishop [SMTP:Tbishop@ITA.CI.LA.CA.US]
> > > Sent: Thursday, January 20, 2000 8:01 PM
> > >
> > > Yes , it was the 7030. In Planning a Computer System,
Date: Fri, 21 Jan 2000 13:03:51 -0500
From: Bruce Black
Organization: Innovation Data Processing
Subject: Re: Homework: Negative side of MVS?
I think the point is that lists and newsgroups like this cannot be considered a
reliable method of inputing user requirements. Although several IBM developers
like Mark monitor this list, it is (I am sure) an informal thing, not a formal
assignment from their management. There is no guarantee that they will read
every message and see the suggestions. for suggestions outside their area of
expertise, I am sure they don't have the time to identify the proper person and
forward every such email.
But there is a formal method for inputting user requirements, there is a form
(used to called the PASR, I think) for documenting a request and it goes into a
REQUESTS database. SHARE also generates requests; and I think they get a little
more respect since they are voted on by multiple users.
It would be nice if users were able to view the REQUESTs database and comment or
concur. Guess I should make that a formal request .
Wayne White wrote:
>
> Mark:
> You are IBM Development?; you make decisions about what is valid, useful
> and doable?; I know there are formal mechanisms for talking to IBM, but it
> would seem to me that if you were getting input, even from this "informal"
> channel, that would be 1 factor in your decision process into what is
> designed and implemented. What your response says to me is that this "real
> world" info from this group is just chatter to you as a developer, and pro
> forma ignored when you make product direction decisions. I wouldn't think
> anyone expects that ideas presented here become committed projects for IBM,
> but I would like to think that the ideas and requests, even the bitches,
> are accepted input, and after your critical analysis, included in your
> considerations for product direction if they have merit.
>
> Wayne
>
> At 12:55 PM 01/20/2000 , you wrote:
> >And you aren't listening to what I'm telling you: This newsgroup is not,
> >never has been, and
> >never will be a formal input to the IBM development process requirements.
> >
> >Michael J Porter wrote:
> >
> >> In article <38874E8D.18E26D41@us.ibm.com>,
> >> Mark Thomen wrote:
> >> =>I'll bring the topic up again: Unless we know what you want improved,
> >you're at someone
> >> =>else's mercy. If you have problems with existing documentation, open
> >RCFs. If you need
> >> =>new documents, open RCFs.
> >> =>
> >> =>You can grumble here all you want, but it doesn't feed into our formal
> >information
> >> =>development process.
> >>
> >> The sentence above tells me you aren't even listing to what we are
> >> saying.
> >>
> >> Mike
--
Bruce A. Black
Senior Software Developer for
FDR, CPK, ABR, SOS, UPSTREAM, FATS/FATAR
Innovation Data Processing
Little Falls, NJ 07424
973-890-7300
personal: bblack@fdrinnovation.com
sales info: sales@fdrinnovation.com
tech support: support@fdrinnovation.com
Date: Fri, 21 Jan 2000 13:10:17 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
Lists and newsgroups are not appropriate fora for submitting formal
requests. However, they are appropriate fora for canvassing interest and for
researching what related requests have already been made. In particular,
they can be very useful in determining how many customers are "the only
customer" to request a particular change :-(
Of course, after the discussion here, it is up to you to decide whether to
make a formal request and in what venue to make it. I have always been on
the customer side of this particular fence, but I agree that it is
unreasonable to demand that IBM treat discussion here in the same fashion as
a formal request through channels.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Bruce Black [SMTP:bblack@FDRINNOVATION.COM]
> Sent: Friday, January 21, 2000 1:04 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Homework: Negative side of MVS?
>
> I think the point is that lists and newsgroups like this cannot be
> considered a
> reliable method of inputing user requirements.
Date: Fri, 21 Jan 2000 13:24:04 EST
From: "A. Harry Williams"
Organization: Marist College
Subject: Re: Homework: Negative side of MVS?
In-Reply-To: <0D93FE5CA0BED11194CB00A0C99D5B09037BC3FB@nsfmail01.nsf.gov>
On Fri, 21 Jan 2000 13:10:17 -0500 Metz, Seymour said:
>Lists and newsgroups are not appropriate fora for submitting formal
>requests. However, they are appropriate fora for canvassing interest and for
>researching what related requests have already been made. In particular,
>they can be very useful in determining how many customers are "the only
>customer" to request a particular change :-(
>
>Of course, after the discussion here, it is up to you to decide whether to
>make a formal request and in what venue to make it. I have always been on
>the customer side of this particular fence, but I agree that it is
>unreasonable to demand that IBM treat discussion here in the same fashion as
>a formal request through channels.
I agree totally that formal requests through the proper channels should
have priorities, and I think most people here do agree with that.
This is also NOT a IBM support mechanism, and no one should expect
to report problems to IBM through this mechanism. I've been amazed
and impressed with the number of people (both IBM and non-IBM) who
respond to problems, saying that sounds like X, but call the support
center. I suspect that most are like me, they don't want to call
the support center until they're sure it isn't something foolish
that you are doing, especially on newly implemented function.
(One of the hardest things to figure out is that product X doesn't
do function Y that I think it could/should)
With that disclaimer complete, any organization that isn't at
least listening to conversations like the ones here, isn't doing
all they should. It is another source of input, like surveys;
if there are problems, this is the place to hear them early and
deal with them; and this(or others) is a group of vocal users,
and word of mouth, personal relationship is still a strong selling
point.
I would also point out that many items mentioned here(not all),
are from the users point of view, nits; small items that bother
them, or their users. These often end up not being submitted
because they are tactical, or small or ... The Endicott lab,
about a decade ago, took a whole bunch of them as a unit, and
treated them as a line item in their plans. The business case
was customer satisfaction, reduced customer support, and reduced
support center time. The end result was a much better product
and I would suggest that other support structures consider
that as an option. Not to totally re-write, but improve things.
The analogy 10 years ago was, you've built a nice new house, but
are you still using lawn furniture in the living room?
>
>Shmuel (Seymour J.) Metz
/ahw
Date: Fri, 21 Jan 2000 11:57:59 -0800
From: Mark Thomen
Organization: DFSMS Development - Catalog, VSAM, IDCAMS
Subject: Re: Homework: Negative side of MVS?
This is a very good post, and I've added some comments/responses below...
A. Harry Williams wrote:
> I agree totally that formal requests through the proper channels should
> have priorities, and I think most people here do agree with that.
> This is also NOT a IBM support mechanism, and no one should expect
> to report problems to IBM through this mechanism. I've been amazed
> and impressed with the number of people (both IBM and non-IBM) who
> respond to problems, saying that sounds like X, but call the support
> center. I suspect that most are like me, they don't want to call
> the support center until they're sure it isn't something foolish
> that you are doing, especially on newly implemented function.
> (One of the hardest things to figure out is that product X doesn't
> do function Y that I think it could/should)
>
There are a few reasons why at least I make this recommendation: 1) It may be a
known problem that is found on a RETAIN search by the L1/L2 people and you can
get an immediate response, 2) they have additional databases for Q&A-type
questions, 3) they may have operational day-to-day knowledge of how to recover
from some user errors that I don't typically run into, and finally 4) it may be a
legitimate problem that should be reported and APARed.
I can tell you that our NDOP (non-defect oriented problem) rate usually runs
about 70% - that's the percentage of PMRs that represent non-defects in the
code. That means most of them are how-to, errors resulting from misreading (or
unfortunately, NOT reading) the doc, doc errors (including omissions), simple
Q&As. If I had to net this out, I'd say:
1). Try the manual(s) first - if you really can't get the answer(s) you
need, then when you DO get the right answer, submit an RCF. PLEASE! If you
couldn't find what you need, or it was incorrect/misleading, WE NEED TO KNOW TO
FIX IT.
2). Try other resources that are available - the new Catalog and VSAM
Knowledge base (see my sig line) were specifically created to address the NDOPs
and help customers get answers without having to call for service. If your
problem is not resolved by that, LET THE SUPPORT CENTER KNOW - especially if it
ultimately turns out to be an NDOP - we will update the knowledge base to add
your situation for the next user.
3). Call the Support Center - they have the latest info available at their
fingertips, they deal with many of these issues day-to-day, and they may have
additional tools or circumventions.
> With that disclaimer complete, any organization that isn't at
> least listening to conversations like the ones here, isn't doing
> all they should. It is another source of input, like surveys;
> if there are problems, this is the place to hear them early and
> deal with them; and this(or others) is a group of vocal users,
> and word of mouth, personal relationship is still a strong selling
> point.
>
I know that there are IBMers in here listening, and we're doing what we can. It
certainly helps us keep our fingers on the pulse of what's going on. It's tough
for us to do major surgery however when all we have to go on is the pulse.
> I would also point out that many items mentioned here(not all),
> are from the users point of view, nits; small items that bother
> them, or their users. These often end up not being submitted
> because they are tactical, or small or ... The Endicott lab,
> about a decade ago, took a whole bunch of them as a unit, and
> treated them as a line item in their plans. The business case
> was customer satisfaction, reduced customer support, and reduced
> support center time. The end result was a much better product
> and I would suggest that other support structures consider
> that as an option. Not to totally re-write, but improve things.
>
And in Catalog we've had a "Customer Sat" line item in the last three releases
for just this type of thing. We have been reviewing the requirements database,
plus specific prioritized lists of items submitted by our L2 folks and
implementing items in each release. There have been a substantial number of
changes in the last three releases designed to improve RAS and PD/PSI. In
addition, we've removed some previous limits, raised others, and added new
features. I'm sure other components are trying to do the same.
> The analogy 10 years ago was, you've built a nice new house, but
> are you still using lawn furniture in the living room?
Exactly. And one final point: I have NO WAY of knowing how many users or
installations are represented on this newsgroup. If one user asks for a new or
changed interface, how representative is that of what all of our users need? How
should I design that interface; should it be infinitely specifiable through
parameters for maximum flexibility for all users? Or is it a limited-use
interface that only a very small subset of users need, and could therefore be
shipped with certain limitations? What is the impact on the whole community if
I change this interface?
Organizations like SHARE have a clear, documented user base that is represented
in requirements they submit. They have decided among themselves how important a
feature is, and prioritized how fast they want it. It makes it easier for the
business case to be satisfied. I can't apply that test to things posted here,
where there is such a limited (read: unknown) number of actual users
represented. While I read the items and follow the various threads, realize that
I may be able to make some small changes under the guise of "Customer Sat" - but
I can't COMMIT to making them. If you want COMMITTED changes, there is a process
to use, and I encourage you to use it.
>
>
> >
> >Shmuel (Seymour J.) Metz
> /ahw
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
"Technical Database")
or http://knowledge.storage.ibm.com/
Date: Fri, 21 Jan 2000 15:40:19 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
Do you call it NDOP is the information is in the documentation but the
documentation also contains conflicting information? I'd call that a defect.
Also, the manuals don't always have an RCF. Finally, some nondefect calls to
the support center occur because IBM has directed the customer to make the
call, e.g., to pull a bucket prior to an install.
BTW, you quoted my sig in your response, but all of the text that you quoted
was Mr. Williams's rather than mine. Not that I disagree with everything he
said, but he should get the credit for his own contribution.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Mark Thomen [SMTP:thomen@US.IBM.COM]
> Sent: Friday, January 21, 2000 2:58 PM
>
> I can tell you that our NDOP (non-defect oriented problem) rate usually
> runs
> about 70% - that's the percentage of PMRs that represent non-defects in
> the
> code. That means most of them are how-to, errors resulting from
> misreading (or
> unfortunately, NOT reading) the doc, doc errors (including omissions),
> simple
> Q&As. If I had to net this out, I'd say:
>
> 1). Try the manual(s) first - if you really can't get the answer(s)
> you
> need, then when you DO get the right answer, submit an RCF. PLEASE! If
> you
> couldn't find what you need, or it was incorrect/misleading, WE NEED TO
> KNOW TO
> FIX IT.
>
>
>
...
> > >Shmuel (Seymour J.) Metz
> > /ahw
Date: Fri, 21 Jan 2000 14:46:32 -0800
From: Tom Bishop
Subject: Re: Homework: Negative side of MVS? -Reply -Reply
Sorry guys, its one of my treasures. And all for $3.95. I don't seem to find
many books like that is the used book stores. They are mostly "How to get
Program X to work" now.
>>> Rick Fochtman 01/21 6:48 am >>>
Person found. Pvt. E-Mail and we'll make the arrangements. :-)
Date: Sat, 22 Jan 2000 12:01:34 +1100
From: Keith Owens
Subject: Re: Homework: Negative side of MVS?
In-Reply-To: Your message of "Fri, 21 Jan 2000 11:57:59 -0800."
<3888BA46.BEE7D5C@us.ibm.com>
On Fri, 21 Jan 2000 11:57:59 -0800,
Mark Thomen wrote:
> Try the Catalog and VSAM Knowledge Base at:
> http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
>"Technical Database")
> or http://knowledge.storage.ibm.com/
http://knowledge.storage.ibm.com/ gives a blank screen (only the
standard IBM header) on browsers that have javascript disabled. I do
not trust the security on java and javascript so I run with it disabled
by default. If you are going to put up pages that require javascript
to function, please include a test that javascript is functioning and
put out a message instead of no visible output. Like this :-
<noscript>
<h1>JavaScript is required</h1>
<p>
This page requires JavaScript to function. Your browser either does
not support Javascript or it has been disabled. Please use a browser
that supports Javascript.
Date: Sat, 22 Jan 2000 10:41:43 -0600
From: "Eric N. Bielefeld"
Subject: Re: Homework: Negative side of MVS?
Mark,
I too wish more IBMers would take suggestions from this list, but I am grateful
for the what you can do. Most of all, I appreciate the good comments you and
several others from IBM have been giving. When there are conflicting reports
on how to accomplish something, I usually view the IBM source on this list as
a more definitive source who has access to internal IBM documentation and people
that most of us don't. Thanks for all the good comments, and spread the news
about this list among your fellow IBMers. When I first started on this list
a few years ago, I don't think any IBM people responded to it.
Eric Bielefeld
>>> Mark Thomen 01/20/00 06:53pm >>>
Yes, yes, yes, and yes. But you have to understand - no matter how much I *like*
something, or think it should go into the product, I can't just "slip" them in.
Some things I can get away with doing like this, but most I can't. (Snip)
Date: Sun, 23 Jan 2000 09:15:57 GMT
From: reza heydarpour
Subject: Re: Homework: Negative side of MVS?
But I still say that AGE has a big image problem in the west.
I've seen sites where mngr/team-leader is under 40 & goes drinking
with other 'young' members of the group where decisions r made as
who does what & ... Next thing u know over 50 people are left out of
the picture & pushed out of the game.
Or situations where the young, who are put in charge of projects, ask the
old (who are out of the picture in the corner doing real-work) how it's done
& then go do it & get all the credit.
I once worked with a nice sysprog who turned 60, so we signed a card for
him, but some smartass wrote on it: Retire & give your job to a
young guy (I 4got, but it was said in an ugly way (some OZies find
ugly funny & not rude ?))
The assumption seems to be: OLD doesn't know nothing (so must be moved
out to retired home ...)
So comes the assumption that mainframes are old/legacy/dinasours &
should retire ...
I suspect this wasn't always the case& perhaps only started after the
west sold her soul to greed/developemnt/material-things/... & lost
her sprituality/compassion ?
...Reza
MVS: s/w that liveZ
>It's not that age is bad - the alternative is worse - but that the wisdom
>and maturity are optional, whereas the aches and pains and deterioration
>seem to be mandatory.
>>'age' is only regarded 'bad' in the west, a lot of people associate
>>age with 'wisdom' & 'maturity' & respect it.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Date: Sun, 23 Jan 2000 11:03:21 -0600
From: David Alcock
Subject: Re: Return codes when running IKJEFT01 in batch
You know, people ask Frequently Asked Questions all the time. I'll be
adding this one and Mainframe ZIP to the IBM-Main FAQ soon.
http://users.ticnet.com/davea/ibm-main/
I'd like to make a personal apology for starting the Homework thread.
Date: Mon, 24 Jan 2000 09:05:43 -0800
From: Mark Thomen
Organization: DFSMS Development - Catalog, VSAM, IDCAMS
Subject: Re: Homework: Negative side of MVS?
Thanks for your vote of support...
Eric N. Bielefeld wrote:
> Mark,
>
> I too wish more IBMers would take suggestions from this list, but I am grateful (...)
> Eric Bielefeld
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click "Technical Database")
or http://knowledge.storage.ibm.com/
Date: Mon, 24 Jan 2000 09:03:00 -0800
From: Mark Thomen
Organization: DFSMS Development - Catalog, VSAM, IDCAMS
Subject: Re: Homework: Negative side of MVS?
If it's truly incorrect information in a manual, we don't consider it NDOP. If
you know of any manuals that do NOT have an RCF, please let me know and I'll
talk with ID about it.
We don't count those other calls as NDOPS either...
Metz, Seymour wrote:
> Do you call it NDOP is the information is in the documentation but the
> documentation also contains conflicting information? I'd call that a defect.
> Also, the manuals don't always have an RCF. Finally, some nondefect calls to
> the support center occur because IBM has directed the customer to make the
> call, e.g., to pull a bucket prior to an install.
>
> BTW, you quoted my sig in your response, but all of the text that you quoted
> was Mr. Williams's rather than mine. Not that I disagree with everything he
> said, but he should get the credit for his own contribution.
Agreed, sorry - thought I snipped it correctly.
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
"Technical Database")
or http://knowledge.storage.ibm.com/
Date: Mon, 24 Jan 2000 09:04:14 -0800
From: Mark Thomen
Organization: DFSMS Development - Catalog, VSAM, IDCAMS
Subject: Re: Homework: Negative side of MVS?
I've notified the support group and we'll try to get that fixed as soon as possible.
Keith Owens wrote:
> On Fri, 21 Jan 2000 11:57:59 -0800,
> Mark Thomen wrote:
> > Try the Catalog and VSAM Knowledge Base at:
> > http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
> >"Technical Database")
> > or http://knowledge.storage.ibm.com/
>
> http://knowledge.storage.ibm.com/ gives a blank screen (only the
> standard IBM header) on browsers that have javascript disabled. I do
> not trust the security on java and javascript so I run with it disabled
> by default. If you are going to put up pages that require javascript
> to function, please include a test that javascript is functioning and
> put out a message instead of no visible output. Like this :-
>
>
> JavaScript is required
>
> This page requires JavaScript to function. Your browser either does
> not support Javascript or it has been disabled. Please use a browser
> that supports Javascript.
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
"Technical Database")
or http://knowledge.storage.ibm.com/
Date: Mon, 24 Jan 2000 12:47:59 -0500
From: "Metz, Seymour"
Subject: Re: Homework: Negative side of MVS?
I've already reported the ones that I know about. Thanks.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Mark Thomen [SMTP:thomen@US.IBM.COM]
> Sent: Monday, January 24, 2000 12:03 PM
>
> If it's truly incorrect information in a manual, we don't consider it
> NDOP. If
> you know of any manuals that do NOT have an RCF, please let me know and
> I'll
> talk with ID about it.
Back to home page