Newsgroups: bit.listserv.l-vmctr
Date:         Mon, 13 Apr 1992 11:24:36 PDT
From:         Ed Rovera <EJR9006@UCSFVM.BITNET>
Subject:      Re: ESA compatible products -- VMSCHED/E, VMTAPE/E & VMBACKUP/E
              1 Apr 1992 21:41:58 EST from <LENBOYLE@CCVM.SUNYSB.EDU>

On Wed, 1 Apr 1992 21:41:58 EST Leonard Boyle said:
>On Wed, 1 Apr 1992 17:43:27 PST Ed Rovera said:
>>   Is anyone other than me running these three products?  If so, could
>>you folks let me know if you've hit the VMSCHED/E stuff we've found?
>>
>We are running VMSECURE/E and VMTAPE/E with VM/ESA ESA 1.0. So far
>we have found no new problems. Thanks for the warning on VMSCHED.

   Just to let folks know the outcome of my trials and tribulations
with VMSCHED/E, D10955 did *not* correct my truncation problem.  It
seems that VMDEXIT2 running on a VMSCHED/E 1.0 DSVM when you are using
only DIRMAINT, results in truncation errors that surpass those fixed
by D10955.  We were getting clobbered all over the place so I
deactivated VMDEXIT2.  The truncation problem ceased but we exposed
ourselves to the possibility of having VMSCHED mess up the XAUTOLOG
commands.  When that happens, VMSCHED stops issuing the XAUTOLOG
command altogether and every request involving an autolog gets put on
HOLD.  With VMDEXIT2 off, we had to watch VMSCHED like a hawk so that
if he ever said he no longer was authorized to issue the XAUTOLOG,
Operations would have to issue a VMSCHED END and then bring VMSCHED
back up.  By the way, the messages that show up on your Ops console
are:

     VMDAUT226S VMSCHEDULE/E has exceeded the invalid password count.
     VMDAUT227S VMSCHEDULE/E is no longer initiating requests.

   VMSCHED issued the above messages only once and we were able to
recycle VMSCHED quick enough so that only about 3 requests were place
on HOLD.  We had to run like this for almost a week, too, so you can
survive with the password glitch but you have to have diligent
operators who spot the messages and react to them or modify your
automated operator facility to handle this possibility.

   SCI, especially John Sadler, went into overdrive to find a fix for
us and came up with a source change to VMDSYS that I've had running
since Thursday at noon.  I applied the updated VMDSYS MODULE and
reactivated VMDEXIT2 and we haven't seen either the password or the
truncation problem since.

   I recommend that if you are getting ready to upgrade to VMSCHED/E
1.0 and you're *not* running VMSECURE, that you contact SCI and see
when they'll have this source fix incorporated into their maintenance
on VMSCHED/E.  I know it'll bite you if you have only DIRMAINT.
RACF and ACF2 sites may have the same problems but I'm not sure; be
safe and check with the VMSCHED support people.  I know that sites
with VMSECURE do *not* have to worry so Leonard, et al, are safe.

   As a final note, I'd like to stress that even though we got hit
pretty hard by this bug, SCI's support people did everything they
could to correct it.  Between having the ability to send documents to
them directly via IBMMAIL and the support group's efforts to recreate
the problems while I was on the phone and able to guide them, we were
able to locate the problem in a matter of minutes and start working
toward a correction.  Couple this with their willingness to place
developers on call to me personally, and I think SCI's response to
this could only be described as excellent.  I mean, when was the last
time you had a vendor upgrade a call to Sev 1 before you could even
ask for it *and* give you a developer's pager number in case you had
to reach them over the weekend?

                                            - Ed Rovera
                                              (EJR9006@UCSFVM.ucsf.edu)
                                              UCSF ITS Division
                                              415-476-3119
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU