HP3000-L Archives

October 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Stigers, Greg [And]" <[log in to unmask]>
Reply To:
Stigers, Greg [And]
Date:
Fri, 27 Oct 2000 12:43:31 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (47 lines)
X-no-Archive:yes
Tom Emerson wrote:
> I think if you lower the limit so that jobs cannot log on [and suspend any
> "job schedulers" you might have], then issue the timezone change,

FWIW, we use Nobix JobPak on our production system. Normally, our EOM full
backups are running at 2AM Sunday, and we have an hourly diagnostic schedule
of jobs. While Nobix advises against doing this, we use their product to
schedule the time change job. I * believe * that the reason they advise
against doing this is because their stdlist archiving component uses time to
track what it does with archived stdlists, and the time change can confuse
it. We have seen no real problems changing the time during the backup, or
while other scheduled jobs are being streamed or are running, and only one
anomaly.

While we do have a job to shutdown and restart the scheduler (which we have
scheduled in the scheduler to run once a month), our time change job first
issues diagnostic time commands. It invokes and exits the command line
scheduler interface to see the time displayed in its banner, as well as
running DATE.HPBIN.SYS and SHOWCLOCK. It then changes the time, and reissues
all three diagnostics, to prove that this isn't as crazy a thing to do as it
sounds.

The only problem I have seen is that JobPak has already planned its jobs for
the rest of the day, and will run those jobs "uncorrected". So when we "fall
back", the backup runs an hour later than it should. This is not a real
problem for us on a Sunday. It's an even bigger surprise in the spring when
they run an hour early, but no more of a problem. After midnight for the
next day, everything runs as expected. We could have the scheduler reload
its schedule, and so plan its jobs to completely avoid this were it
necessary. I do not believe that a simple suspend and resume would make a
difference for us here.

!JOB STTIME,MANAGER.SYS
!COMMENT this job sets the system time to standard time (fall)
!SCOMXL.JPAK.NSD;PARM=4;INFO="EXIT"
!DATE.HPBIN.SYS
!SHOWCLOCK
!SETCLOCK TIMEZONE=W5:00
!DATE.HPBIN.SYS
!SHOWCLOCK
!SCOMXL.JPAK.NSD;PARM=4;INFO="EXIT"
!EOJ

Greg Stigers
http://www.cgiusa.com

ATOM RSS1 RSS2