How to accomodate different timezones in a cluster?

[Art Wiens]

We might actually, possibly upgrade our Alpha/VAX environment in the near future (although I won't hold my breath). The plan would be to do a consolidation of several Alpha 800's and DS10's onto a few ES47's (before they stop selling them) and try and make a two site VMS cluster.

The trouble is, this consolidation will "bother" several groups of users who are spread over 4 different timezones. Right now we have three different clusters running in three different timezones. Lots of batch activity and it would require "lots of math" for the "thinking-challenged" users.

I could probably get away with two timezones, but I'm sure there would never be concensus on one.

Can this be made to work?

Art

[Ian Miller.]

I don't think you can run several timezones in a cluster and it certainly is not supported. You may be able to provide some aid to your users when submitting jobs. There could be a DCL procedure which checked which time zone this user wants (defined by an identifier held by the user parhaps) and then did the submit with appropriate changes to the time the job is needed to run.

[Wim Van den Wyngaert]

Yes you can. With the help of datesim. Played with it in 2004. Almost good.
http://www.softwarepartners.com/products/datesim/main.php

Wim

[Wim Van den Wyngaert]

Found back my evaluation mail.

"As expected there might be application problems if e.g. show que output is parsed by a program. This because show que "sees" the system time and not the "system time converted to the user time"".

Overall : very usable but very good testing is needed.

I wanted to use it to run London stuff on our Brussels servers that also run Brussels stuff. The project never started ...

Wim

Wim

[Wim Van den Wyngaert]

In case the dioc is not clear : you add to the login of each user a comamnd that will set him in a special timezone. Then after that all VMS commands have adjusted time.

Example :
$ show time
29-MAR-2004 14:16:53
$ @synch_with_timezone central
$ show time
29-MAR-2004 13:16:59
$ submit/after=14:00 sys$login:login.com
Job LOGIN (queue SYS$BATCH, entry 10) holding until 29-MAR-2004 15:00
SNDPIP => show entry/user=andrew
Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
10 LOGIN ANDREW Holding until 29-MAR-2004
15:00:00
On idle batch queue SYS$BATCH

The real solution is that your application works in GMT and that time is translated correctly to the user depending on a setting per user. 1 applic can have users in many timezones.

Wim

[Robert Gezelter · Accepted solution]

Art,

The comment about running the system in UTC (Zulu or GMT; for those of us who remember) is a good one.

The local time should be a default per user (or per group) with a method of how to override the setting when appropriate is the ideal approach. Some of this context enabling type ofganization is covered in my Technical Journal paper on Inheritance based environments (see http://www.rlgsc.com/publications/vmstechjournal/inheritance.html ) and the summary of my related workshop, "OpenVMS User Environments" at HP World 2004 (see http://www.rlgsc.com/hpworld/2004/N227.html ).

However, auditability is a more complex issue. You also need to ensure that EACH AND EVERY timestamp that is recorded is either recorded in UTC/Zulu/GMT, AND that each time stamp contains the timezone designator (e.g., Z, CET, EDT).

Without the timezone designators, the audit and accountability issues will surface with a vengance (also you should probably get your legal department to consult on the question of time stamps, the time to deal with a time stamp issue is now, not when there is a regulatory action or a court case filed against the organization).

I hope the above is helpful. If I have been unclear, or can something, please let me know, either in this forum or privately.

- Bob Gezelter, http://www.rlgsc.com

[Art Wiens]

Wim, thanks. I have downloaded and installed a demo ... real quick testing last night seems ok except if you submit a job to a stopped queue (and let's test this fancy new ITRC Retain Format feature):

$ show queue/all/full xxxxxx$monitor
Batch queue xxxxxx$MONITOR, stopped, on xxxxxx::
/BASE_PRIORITY=2 /JOB_LIMIT=1 /OWNER=[SYSTEM]
/PROTECTION=(S:RSD,O:RSD,G:RSD,W:RS)

Entry Jobname Username Status
----- ------- -------- ------
10 DATESIM_SUBMIT_JACKET
xxxxx Pending (queue stopped)
Submitted 20-JUN-2006 21:26:09.24 /KEEP /NOTIFY /PARAM=("","","","","",
"0","20200245","_$12$DKB100~0000000121D7000000085429") /NOPRINT
/PRIORITY=100
File: _$12$DKB100:[DATESIM]DATESIM_SUBMIT_JACKET.COM;1

I'm sure the users would call!! ;-)

What about two seperate system disks? I know it defeats part of the purpose of having a cluster, but if there were seperate queue managers using seperate queue databases, and aside from the auditing issues (not trivial, I understand)what other major problems could I really face? In the past, system clocks have certainly drifted apart in between cluster members (granted not by an hour or two) seemingly without issue. There are no "databases" in these apps, indexed RMS files abound.

Cheers,
Art

[Art Wiens]

What formatting did it retain? What I pasted in was from an 80 column wide Kea screen.

If we read what's behind the blue i :

"Checking the box allows you to 'cut-and-paste' snippets of code that has indentation and special formatting for readability. "

12345678901234567890123456789012345678901234

44 Columns before it wraps on my screen

12345678901234567890123456789012345678901234567890123456789012345678901234567890

80 Columns

123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012

132 Columns


Testing Testing,
Art

[Art Wiens]

Wow!

[Jan van den Ende]

Art,


What about two seperate system disks? I know it defeats part of the purpose of having a cluster, but if there were seperate queue managers using seperate queue databases, and aside from the auditing issues (not trivial, I understand)what other major problems could I really face? In the past, system clocks have certainly drifted apart in between cluster members (granted not by an hour or two) seemingly without issue. There are no "databases" in these apps, indexed RMS files abound.


I would expect to see "spectacular" effects if the system with the "backward" clock gets to processing by the "forward-clock" system before the timestamp has been overtaken by the clock as seen by the "backward" system.
"File created in the future" errors etc come to mind...

I would think going to UTC (and some way of delta-timing) are the way to go.

It should have been done properly during the designg of VMS, but if a backporting is feasable??? ISTR it being mentioned before in Hoff's blog (??not sure here) as way to complex, so that pretty much leaves DATESYM as the way to go.

But a native implementation in VMS itself WOULD be nice!

Proost.

Have one on me.

jpe