Newsgroups: comp.org.usenix
Path: sparky!uunet!destroyer!cs.ubc.ca!newsserver.sfu.ca!sfu.ca!vanepp
From: van...@fraser.sfu.ca (Peter Van Epp)
Subject: LISA VI massive migrations (highjacked to MVS conversions) Workshop Not
Message-ID: <vanepp.720249546@sfu.ca>
Summary: Session notes from LISA VI workshop on massive migrations 
Sender: ne...@sfu.ca
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Wed, 28 Oct 1992 05:19:06 GMT
Lines: 155


	Since I, with the help of several people from other sites (who shall
remain nameless unless they wish to identify themselves) more or less highjacked
this workshop track session, I guess it is only fair that I write up the session
notes (and I haven't heard from any of the rest of you, but feel free to jump 
in and correct me!).
	A little bit of background to set the stage, my site has spent the last
year and a bit converting from our mainframe to UNIX. Ian Reddy and myself 
hosted one of these workshop sessions last year hoping to find other sites that
knew all the answers (instead, we got invited back to tell everybody how we did,
which we did, see "Dropping The Mainframe Without Crushing The Users, etc" in
the proceedings). The folks at SAS had done a migration from Apollos to HP 7xx
series machines in the same time frame, and Helen Harrison of SAS invited me
to co host a workshop session on "massive migrations" on the alternate track.
In the mean time, several people from other sites found me in the hallways and
bars, and asked about the administrative processing at our site, since their
sites were either talking about or going about moving their admin stuff from
MVS to UNIX. There were two different times published for the start of the
alternate session (1:30 and 2PM) and since I had been telling people 1:30,
I showed up at 1:30 and started an informal discussion (on guess what topic!)
to keep us amused until the bulk of the people came in at 2 pm. As it happened
the first person to arrive was yet another site that had been told to move the
MVS applications to UNIX and the discussion was on.
	I have spent 6.5 years in a mainframe airline site (in fact working
on the reservations system, that management is even more paranoid about than
the MVS system!), with sometimes 3 and sometimes 4 mainframes running the
full catalog of TLA systems (MVS, IMS, SNA, VM etc). I'd tell you where
it was, but they gave me a lobotomy when I left and I don't remember ...
The next 5 years I spent running the Michigan Terminal System on a mainframe
at SFU, and UNIX has been uh, shoved down my throat? for the last year
(just so my biases are clear!). Our administrative applications run on a DEC
VAX under VMS (they are being converted off a mainframe running OS/MVT, the
mother of MVS), and there is no connection (other than an SMTP mail gateway)
between our TCP/IP backbone and the VAX. All connections to the VAX are through
telephone pairs to terminal servers in the machine room or for part of the 
admin building where the VAX lives, on an isolated (and fairly short) dedicated
fibre based TCP/IP network. I believe that our VMS systems programmer (and
my coauthor) has convinced upper management that Ethernets that the general 
public (and in particular students!) can get to are no place for confidential 
data. I expect that a copy of beholder and a PC on the Ethernet would be enough
at your site too (are you on good enough terms with the local crackers that 
you are sure that they will make sure you are paid what you are really worth, 
in that last paycheck before the place goes bankrupt?)
	Given this, my answer to the proposition "Should we replace our secure 
and robust (if really, really expensive) MVS system with a UNIX workstation and
allow the users to connect to it over the campus backbone that is connected
to the Internet" is pretty obvious, "Just Say NO!" (the folks at my site will
tell you this is my answer to almost everything!).
	There are several sites (and feel free to jump in and identify
yourselves!) where this hasn't worked, they are being told that UNIX is 
cheaper than MVS (undeniably true!) so the admin stuff is being moved.
Given that there is no choice, you have to do it, what is there to look 
out for?
	Security is of course the first thing that leaps to my mind, if
your financial data is running on a UNIX box, and someone breaks in and
breaks root and is good enough to cover their tracks, you run the risk
of big losses from fraud (at least potentially). One of the sites moving
this way described an incident on their MVS based system: a student broke
in to the registrars office, and found a password under a keyboard and 
logged in to the MVS system. He typed the password that he had found wrong
once, and as a result (and I expect because of the strange hour) the
MVS security system (RACF or Top Secret, don't remember which) flagged 
the access, resulting in a sting operation that caught the student. Think
about if this had been UNIX, probably no log of the mistyped password
(UNIX folks: feel free to jump in and correct me!), if he had also been
able to break root, all trace of his entry removed, marks changed invisibly.
	There was some discussion about whether a B1 rated UNIX system would
help with this. Presumably in order to get the B1 rating, root access must
be restricted, because otherwise all the audit logging and access control
would be subject to modification by a person that had broken root. No one
present seemed to be to sure (or I may have missed it), someone did however
point out that, this was no longer a simple and cheap UNIX system, and it
was going to need a lot of disk to hold all the log files. Something I didn't
toss in then, but will now, is at the Usenix Security conference last month
(which by the way brings up the question I meant to ask in my presentation:
Where were you all? There were only around 280 people there, and I have
experimental proof that a lot more of you should have been!), tools are
needed (but don't seem to exist yet) to extract useful information from the
sea of audit files from a B1 system. Maybe all the money you spend for MVS
($20,000 a month for the software only on a single CPU 10 years ago, anybody
have a current price?) and RACF (an add on probably not more that a couple
of thousand a month) really does buy you something: useful, usable information
(and dare I say it? reasonable security!).
	When comtemplating a move like this, I think that the following 
questions of the vendor that is trying to sell you a solution is in order: 
How many employees are there in your company? What kind of computing system 
produces the pay checks at your company? (any bets that you hear a lot of MVS 
or VMS as answers?) If they aren't willing to trust their paychecks to the 
hardware that they are trying to sell you, why should you? I expect that there 
are vendors of the larger type UNIX boxes out there that really do run their
paychecks off on their UNIX boxes, I know if I didn't have a choice, I would
try for one of them (but I bet it isn't going to be cheap ...)
	Think about the hidden costs (you are going to end up paying them 
whether you see them or not!). Is the exact same accounting package you use
on MVS availible on UNIX (the mind boggles a JES3 system ported to UNIX ...)?
How about your production job scheduling package? Your bank accepts payroll
tapes on 8 mm tapes (every bank mainframe should obviously have a channel 
connected Exabyte after all ...) right? You have that optional UNIX package
"write_this_IBM_tape_for_the_bank" don't you? If the answer to even some of
these questions is no, then there is going to be a retraining cost here.
How disrupted is your business or campus going to get while you convert?
Are your users (and yourself!) going to understand if there is a few 
weeks delay in getting out the paychecks?
	Have you thought about those trees and trees worth of reports that are
so near and dear to managements hearts? At least one site had a Xerox 4050
printer, which as I recall is around 50 pages per minite duplex. Our site
has a Xerox 4090 (92 pages per minite duplex), in the mainframe days, it 
loafed along at 600,000 pages a month (it is rated for 1.5 million pages 
a month). It was and is shared between academic printing (MTS on the mainframe
then and UNIX via a Sun workstation now) and the admin VAX (through a 
parallel port to IBM channel converter from Xerox). It currently is having
a good month when we get 200,000 pages through it (and many of those are
probably from the VAX). To be fair, a large part of the reason is that the 
printing load is now spread among six HP3SI printers distributed around
campus (17 ppm, 50,000 pages a month duty cycle, but cheap!). In times 
past (before telereg), the registrars office needed to print forms for 
all the students either overnight or at most in a day or two, and drove
the printer at full speed. Do you still have such a requirement? How is 
a UNIX box going to meet it if you do?
	The bottom line at the end of this hour and a half of discussion
was (at least to my mind) lots of questions, not many answers. To me this
feels much like Ian and I felt last year, and I would repeat what we 
were told: those sites that are doing this type of conversion, come back
next year and tell us how it went and what you learned (after all maybe
this downsizing nonsense is catching and my management will get infected!)
	A stray thought that struck after the session: for those of you that
think this is a bad idea, but are having trouble convincing management, two
suggestions, put your objections in writing to your manager (and keep a copy),
and slip a copy (anonymously if you have to) to the auditor for your institution
or company. I remember a case at the airline, where the auditor didn't like 
something about the MVS operation. You would be amazed at how high a priority
fixing whatever it was got when the auditor said that it got fixed or the 
company got a qualified audit report ... Security problems and possible 
fraud losses are to a typical auditor like a red flag to a bull (and probably
at least worth a try).
	I also urge any of you reading this (whether you were at the session
of not) to share your experiences if you have them, tell me that I am so
full of it my eyes are going brown (but make sure to offer your solution to the 
problems if so!), correct anything I have misstated (I warned you that he
who writes the history makes it ...), or missed. I will send mail to those
of you who I recognized (and I urge anyone else there to point other 
attendees or interested parties to this post as well). Maybe somebody else
out there has the answers these sites need (although I probably shouldn't
say it, in some cases that may be a new job in a sensible shop, in my
opinion, someone bailing out is showing remarkable good sense and would
probably be a good hire, at least you know that he or she thinks ahead ...)

	I should probably also say these are my personel views and may not
be shared by my employer (although as I said, our admin stuff is on a VAX,
so maybe they do ...).  I certainly had a good time at this session and 
look forward to a similar one next year, and hope that all of you that 
were there found it useful and fun too. 

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada