HP3000-L Archives

May 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:
Tom Hula <[log in to unmask]>
Reply To:
Date:
Thu, 25 May 2000 14:38:31 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (25 lines)
"Johnson, Tracy" wrote:

> Our company bought Hourglass, software that sets the local time zone for an ACCCOUNT,
> USER, or other specified configuration.  From what I understand, it merely sets
> the local time while the user qualifies to have it's time changed according to
> his configuration file.
>
> But if within this configuration, my perception was that if a user were to use the
> AT= parameter in the STREAM command, the user must use the system time instead.
> Or at least that's what I "think" it does.

I have used Hourglass quite a bit and also noticed that the use of AT= and such like stream parameters are based on the system time, even if the job itself is set to
logon as of a completely different time/date. It can get rather confusing. The JINHERIT feature works very well to have a job inherit your local Allegro clock, but the
scheduling parameters don't work that way.

Actually, I can see why they didn't mess with that. If it is 3am, but when your job logs on, it will think it is 11pm and you then stream with the AT= ... when is it,
actually, that you want it to run? Do you want it to run at 3am, thinking it is 11pm, or do you actually want it to run at 11pm. It would take some thought to even
know what you would want the product to do with the scheduling parms. But I do agree that it does lead to some rather interesting results at times.

--

        Tom Hula
        Victor S. Barnes Company
        616.361.7351  x173

ATOM RSS1 RSS2