Here's my "some fun" entry! Hope you find it entertaining!!!
Many months agao, we encountered a problem with our DB (it's around 9GB).
There were many email/phonemail talks and recently we had converted from
MVS-V2 to MVS-V3 and I asked my support person (which I've changed the name
below for) what I though was a simple question. It coincided with the
timing of us getting an isolated, duplicated environment (Y2K testing) that
I could use to "test" the fix. I got a call and a email from the support
person where he berated me for not having instantly done what he had
suggested. This, to me, is an example of the "support vs. the trenches".
This is what I sent him after our friendly, little conversation (with the
edited name being Mr. Support).
We must note that we all agree that there isn't any way to determine the
length of time it would take to run this APAR. We also agree that we don't
know if the APAR (which is in a range of 1-100% reduction in a full unload)
would fix the problem. We know that a successful unload/load could take as
long as 3-4 days and that a full audit with fix could take as long as an
additional 3-4 days.
Obviously Mr. Support doesn't have a feel for what that would mean to a
production environment in regards to scheduling an outage. Here is what I
would have to present to our users in requesting time for this problem
resolution:
*we need to schedule an outage of the 100 clients production backups
*the outage will be from 1 hour to possibly over a week
*we have "sold you" on the concept of centralized backup and the
inherent comfort of have daily backups of your changed data along with the
management of your media (including the off-site safety)
*you need to find other means of backing up your production data
while we "_TRY_" this procedure
*if this doesn't fix the corruption, we'll be back to ask for
another outage after ADSM support comes up with -ANOTHER- procedure
*I'm sorry, no, we don't know the impact of this error message to
the overall environment, but it must be a bad thing
So, since we would want to have the latest/greatest code running, and we
don't have any idea if this will fix the problem and/or how long it will
run, I have chosen to wait until we had ADSM version 3 and a duplicate &
isolated environment to run with. We now have this scenerio and we tried 1
time but experienced a S0C4 abend that required some LE maintenance. I have
to point out that this also required me to restore the full DB from backups
(FDRABR application backups). We have the LE maintenance available now and
will attempt another try at "testing the fix".
Note: it took us 2.5 hours to do the unload. We had the S0C4 abend
immediately after starting the load so we don't know how long that will
take. If this had been tried in production, we would have scheduled this
outage, been down for at least 6 hours and would have been back to where we
started. We would now have needed to try to schedule another
questionable-length, questionable-success outage.
And, Mr. Support can't understand why we haven't done this a long time
ago???????????????????????????????????????????
A real chuckle, aye?
Note: this is my personal interaction and perspective and isn't necessarily
my companies perspective on things!
Dave Sanders
Sr. Technical Consultant
DSanders AT massmutual DOT com
MassMutual / The Blue Chip Company
1295 State St, E060, Springfield, MA 01111
413-744-5095
|
