Deep desk drawers
"The nightly backup keeps taking longer and longer, and as long as the backup is running user logins are disabled. When they come in early in the morning they often can't login for an hour or more. Do Something About That."
Trying to get an initial understanding of the backup process I already find that it's a nearly intractable tangle of VMS command files. Files whose names are 3-digit numbers. So in the logging you see something like 618.com calling 237.com and 491.com, then 762.com to ready the lot for writing to tape. Which is done by yet another command file, started at a time when the previous steps must really surely definitely totally have finished, plus an hour extra for good measure. This delay could easily be eliminated by several methods, one of which is the standard VMS function 'sync', which starts a batch job on completion of another (which can be on another queue or even on another cluster member; a single job queue isn't always the right solution).
This I propose.
"Our script maintainer will evaluate this."
Weeks pass. Weeks in which calls are logged by users who can't start working because the backup is still running. Calls which end up on my desk. Requesting a status of the evaluation I get some non-committal "Still evaluating"
Weeks pass. Same shit, same inaction. I start thinking the solution is too straightforward to get his tangled brain around.
Weeks become months, and after some more rounds of the above finally there's a verdict. "We're afraid we can't maintain your solution after you've left."
Balderdash. It's a standard VMS function, documented as those functions all are and widely used at just about every site using batch queues in more than utterly trivial ways. So this was someone who had used his script-writing skills to build an impenetrable fortress around his job.
Well, good bye and good riddance.