mirror-textfiles.com/humor/COMPUTER/the_main.env

                      NEW EMPLOYEE ORIENTATION:
                      The Mainframe Environment
                     From a Training Perspective

                                 by

                            Kerry Galgano
                       <<kgalgano@cerfnet.com>>




     "Ladies and Gentlemen, on behalf of the management of Behemoth
Software International, let me welcome you to the company.  I'm sure
Mr. Brinksman would like to welcome you in person, but he is attending
a stress delegation seminar in Fiji.  Do you all have your orientation
packages in front of you?  Good.  This session is designed to acquaint
new employees with the data processing world as it relates to our
product: educational software for the mainframe environment.

We believe that an increased awareness of the realities of the DP
environment promotes a better understanding of our customers and their
needs.  Now, if you will follow along in your handbooks, we will begin...


The Mainframe Environment


Operating systems can be murky and treacherous places, depending
upon what options, interfaces and site-specific standards each
company has scotch-taped onto them.  Every data center does things
differently.  The atavistic impulse to incise one's name on a smooth
rock has found its modern expression in software engineers who feel
compelled to customize a perfectly good program beyond all
recognition.  From coast to coast, yea, even unto the UK, the DP
professional's motto is, 'I tinker, therefore, I am.'  Yet, our
product is expected to load flawlessly and interface perfectly with the
stupefying array of ornaments our customers have chosen to hang, like
so many leeches, on their mainframes.  The odds are that those of you
who are coming aboard on the Help Desk will be on Thorazine drip within
six months.

But, we digress.  Let us direct our attention first to the operating
system.  What is it?  How does it work?  As the Marquis de Valmont
said as he embarked on one of his dangerous liaisons, 'I think we
should begin with one or two Latin terms...'


VM and MVS


A number of years ago, a breakthrough in computing was achieved
with the development of Virtual Machine (VM).  The use of 'virtual' in
this context is 'appearance without reality'.  When you logon to a
virtual operating system, you are given every indication that you have
the entire system to yourself.  Sadly, this isn't the case.  VM, with
perfect equanimity, simulates a full environment for everyone,
regardless of mental acuity.  You are sharing the system with people
who think 'Beavis and Butthead' is a documentary.  Don't panic.  Just
change your link passwords frequently.

The ubiquitous term 'virtual' has given rise to a number of jokes in the
industry, most of which are variations on the theme of 'Virtual Support':
a support organization which appears on the org chart, but whose members
can be located only on days when Trout Vindaloo is served in the data
center cafeteria.

Another popular term is 'Virtual Manager', a sort of Flying Dutchman
who appears on the org chart -- and nowhere else.  The more common
definition of 'Virtual Manager' is the administrator who has all the
acumen and verve of plankton.  You will find this type of manager
abundantly represented in our industry.

VM, long cherished for its simplicity and straightforward command
structure, is rapidly becoming a thing of the past as more CEOs are
persuaded that complex problems require ever more complex solutions.

MVS, or Multiple Virtual Systems, is the industry's answer to today's
need for added complexity.  It offers users an astounding variety of
ways to screw up.  However, it compensates for this by providing a
maze of dataset naming conventions behind which any number of screw-ups
can remain undiscovered for decades.

Through the use of CMS in VM or TSO in MVS, users are able to
conduct concurrent sessions, though each user's job competes with
other programs for CPU time.  Processing time is at a premium in
every company, especially in the production environment.


Production vs. Test Environment


When we speak of a production environment, we mean 'the real world'
(a phrase you will quickly tire of).  This is the place where programs
are in actual use to conduct the business of the company.

The antonym of production is 'test'.  This is the environment where
programs are thoroughly vetted to make sure they are functional,
reliable and compatible with the system environment before they are
migrated to production, where they invariably abend.  Abends are the
leading cause of liver disease in the data processing industry today.


Scheduling


There is always competition for system resources between the
production and test environments.  When the production area is down
or is slow, the company loses money.  Many companies schedule
special hours for test jobs to alleviate congestion and reinforce
resentment for production priorities.  In addition, most sites institute
job classifications which specify priorities in terms of 'production' or
'test' and schedule jobs accordingly.  The programmer who runs a
lengthy test job during production hours is a carefree, oblivious soul
who does not have long to live.

In many companies, test jobs are run in the wee hours, when production
is not usually an issue and there is less competition for processing
time.  Most programmers welcome this shift, as it affords them a chance
to roam deserted hallways, turning abstract paintings upside down and
drawing horns and a goatee on the Employee of the Month.

Some companies run batch jobs at night to provide current data for the
next day's business.  Test jobs which interfere with production batch
processing are greeted with all the warmth and affability of the
Spanish Inquisition.  Apparently, nobody expects the Spanish Inquisition,
as many production schedules are festooned with poorly disguised test
jobs.


Change Control


Many companies have implemented a standard, called 'change control',
to regulate system changes, minimize impact on production and thwart
productivity in general.

Change control procedures vary.  For some sites, it can be as simple
as filling out a twelve-page form and nurturing it through channels
(minimum time required: four weeks).  For other sites, the change
control process can require a bewildering variety of procedures, each
with its attendant documentation rituals (pledges of offspring, signing
over of life insurance, oaths of fealty, etc.).  In this case, the
minimum processing time is six to eight months (if you happen to have
extra Super Bowl tickets, five months and fourteen days).


Migration


The implementation of new products or programs (the act of migrating
them from the test environment to production) normally takes place
over weekends or holidays.  This practice embraces the wild,
unfounded hope that, should a fatal flaw in the new program be
discovered, there will be ample time to back it out before production is
affected.  There are two schools of thought as to what constitutes the
proper method of ensuring a smooth migration.  Some programmers begin
each product installation with a prayer to St. Binar, the patron saint
of data processing professionals.  However, most veteran programmers
know the secret of a successful implementation is to wave a dead chicken
over the operations console when no one is looking.

Black boxes recovered from the smoking ruins of unsuccessful software
implementations have revealed that the last words most often spoken by
programmers are: 'Just give it another five minutes.  It worked on the
test volume.  Are there any buffalo wings left?'  The last words uttered
by operations managers are generally unprintable, usually a rapid and
astonishingly imaginative stream of sibilant consonants and rich, fruity
vowels.


The Role of Training


Where does training fit in?  Well... nowhere, really.  Computer training,
whether it resides in the Information Center, Technical Training or
Management Information Services department, operates as a highly
specialized and universally ignored area.  It is expected to do the
important work of training employees to be productive and efficient...
using none of the company's resources.

Another dismal fact is that most training departments are not involved
in the decision-making process concerning new products or budgetary
considerations for implementing these products.  Often, the news is
broken to the Training Manager in a late-afternoon phone call from the
Project Manager.  The video you are about to see depicts the typical
conversation.  Can you roll that tape, Phil?  Somebody get the lights,
please."



PROJECT MANAGER:  Margaret, this is Paul.  We just signed a five-
year contract for WHOMPIT!  How soon can you have the training in
place?

TRAINING MANAGER:  What's a WHOMPIT?

PROJECT MANAGER:  Workflow Hierarchical On-line Management
Productivity...um...Initialization...uh...Thingie.

TRAINING MANAGER:  What does it do?

PROJECT MANAGER:  Oh, it's guaranteed to knock our ECU down to
12 percent.

TRAINING MANAGER:  ECU?  Is that another new acro--oh, never
mind.  What does WAMPUM do?

PROJECT MANAGER:  WHOMPIT!  Operations is really excited about
the reduced I/Os.

TRAINING MANAGER:  Uh-HUNH.  But what does it DO?

PROJECT MANAGER:  You've never seen such pretty colors.

TRAINING MANAGER:  I'm beginning to see red.  Come on, Paul,
what...

PROJECT MANAGER:  So!  How soon can you get training off the
ground?  We're putting it into production in two weeks.

TRAINING MANAGER:  Two WEEKS!  But, there's so much we need
to know!  First, my people need to get together with the... uh...
WHAPIT?...people to determine...

PROJECT MANAGER:  WHOMPIT!  Oh, we've already done all that.

TRAINING MANAGER:  You have?

PROJECT MANAGER:  Sure!  We got together with their sales rep
over lunch at Chez Frais.  We hammered out all the details.  It's all
worked out.

TRAINING MANAGER:  Oh, REALLY?

PROJECT MANAGER:  Oh, yeah!  We had it up in test for about six
months so the SEs could give it a good workout.  Then, the
applications people had a look at it for a few weeks.  Then, Fred's
people wanted to make sure it would interface with READNWEEP.  And,
naturally, Kate had to check it out for compatibility with...

TRAINING MANAGER:  Paul...

PROJECT MANAGER:  ...BLATTWARE.  Then, of course, Clarence
had to run it out to the remote site in Pinkley to make sure there
weren't any access problems with...

TRAINING MANAGER:  Paul...

PROJECT MANAGER:  ...DRAG-NET.  Oh, drat!  I don't think Billy-
Bob in Shipping has seen it yet.  That's a dreadful oversight on my
part.  Maybe we should put the project on hold for a few weeks so he
can...

TRAINING MANAGER:  PAUL!

PROJECT MANAGER:  What?

TRAINING MANAGER:  I suggest you take your WHOMPIT and put it
where Billy-Bob can give it a REALLY good workout.  Furthermore-

PROJECT MANAGER:  Uh...um...GOSH, look at the time!  I'm late for
a meeting!  Gotta run, Margaret.  Tell you what, I'll have Wally assign
you some training IDs in the morning, OK?  Great!  GOOD to talk with
you!  Bye, now.

TRAINING MANAGER:  (Sigh)



   "Now that you have a feel for the dilemma facing our customers, you
may find your way to your new cubicles.  Oh, sorry - one more thing -
please pick up your WHOMPIT manuals from Wally at the door.  Training
will begin in three weeks...more or less."