First, it would be a HUGE mistake to try and get the "local" time into
the database for time and datestamps.  You can see a similar issue
sometimes on this list when a reply shows up before the original message
due to time zone issues.

Approach #1 -- Train the users that the date and time they see on
screens and reports is the time zone of the system.  You might reinforce
it by putting a note on the login screen, and perhaps add the system
time zone to key reports and screens.  This is used successfully by MANY
companies.
--> If the folks in Sydney deal regularly with the folks in New York
than chances are they are already familiar with the issue.

Approach #2 -- Store the time-zone information by user or by
workstation, and modify the critical screens and reports to convert
date/time to that time zone.  Write a single program to manage the
conversions and add calls to it as necessary.  Genyphyr mentioned this
approach in her comments.  The programming is trivial, although the
volume may make it challenging!

Recommendation:  Start with approach #1, (train early, train often),
and adopt approach #2 if necessary.  I think you will find the users
able to cope acceptably well.

Good luck!

>>> novakg@ssax.com 09/13/02 05:52AM >>>
Hello,

Be careful with Al's suggestion. First of all, there is a job date
setting
which is available to alter, but there is no such thing as a job time
setting. There is only system time, and that is what BPCS uses when
calculating any time stamps. Changing the date on a job to test Y2K is
entirely different from trying to achieve a time zone difference of +2
hours, since a +2 hour setting is not available at the job level.

For Australia, you may be able to correct the date in BPCS by changing
the
job date, but the time will remain 'system time' and eventually at
some
point, the date for that job will again be incorrect (if the user
stays
signed on for a long time), if you are using a single system. This
might
cause even more confusion? When job date is used, the other side-effect
is
that the date stays the same for as long as that job is 'alive', it
will
retain the original date setting unless it is altered manually or
unless the
job ends.

Also note that at BPCS release 6102, (or 6100 depending on BMR level),
and
in base of  V8 and higher releases of BPCS there are BMR changes which
cause
the System Date, rather than the Job Date to be used by BPCS programs,
as
the default BPCS 'date stamp' in order to resolve a long standing
enhancement request (i.e., timestamps would always be 'system time',
but
date stamps would retain the original job date, causing jobs crossing
midnight to have illogical date/time stamps on records updated or
created).

This can be overridden with a setting of 'J' in position 456 of the
*LDA so
that job date is used, and a message will be logged into the joblog to
show
that Job Date, rather than System Date is in use. See BMR 43578 (V8
and
higher) and BMR 60060 (V6102) for further details. You would have to
add an
update to that *LDA position before changing the job date if you
expected
BPCS to pick up the changed date.

Note that the time is ALWAYS retrieved from the system time, and this
setting is not something which is available on the CHGJOB command.

You also need to consider if someone in administration etc. needs to
know
when something was done in 'real' system date/time, rather than seeing
the
'local time' on a record -- if 'today' is 'tomorrow' in Australia, will
it
confuse someone in the US to think that something occurred in 'system
time'
a day later than it actually did if trying to review a transaction gone
bad
or some program or system error? If a change to override the date is
only
required in certain programs, or when printing out certain documents
it
would be better if this could be altered via a customized CL that gets
called after the BPCS date/time is retrieved but before the record  in
question is written/printed.

So, there is a lot to think about in trying to cause software on a
single
system to put different date/time stamps on records that are actually
all
creating at the same relative 'real time' on the server.

If you are going to go ahead and do this programmically, I suggest
using
subsystems to divide up your time zone regions, (i.e., have each
region
using a different subsystem to run their jobs). Then you could use an
API or
command to retrieve the job's information as it runs, in order to find
the
subsystem the job is running in (and have a table connecting the
subsystem
to a time zone value of - or +  n HOURS before altering any date/time
stamp
that BPCS has already retrieved). Using workstation or user names to
base
any date/time change upon will result in tables that are large (slow
look-up) and annoying to maintain each time a workstation or user name
changes in your company.

Thanks,

Genyphyr Novak
SSA GT

----- Original Message -----
From: "Al Mac" <macwheel99@sigecom.net>
To: <bpcs-l@midrange.com>
Sent: Wednesday, September 11, 2002 10:34 AM
Subject: Re: World Wide Operations


> Suggestion for where to look.
>
> There is an IBM command to change stuff associated with a particular
work
> session.  We used it in Y2K testing to simulate distant dates to make
sure
> BPCS worked satisfactorily in simulated dates into the future.
>
> When a user signs onto 400 in JOB Description BPCS there is a BPCS
job
that
> runs before anything else to setup library list and other stuff
associated
> with the user's environment.
>
> Let's suppose you modified that, to call a sub-program, to look up a
table
> of work station naming conventions and say "Oh, this is Sydney
Australia,
> or whatever" and from that get parameters to feed into the IBM change
job
> attributes for that work station, so now that user's session is on
their
> local time.
>
> You would have to find someplace that makes sense to store
particulars on
> every work station that you have.  A lot of BPCS software already
has
> framework for creating work station members of files, or data areas
named
> after the work stations, if they do not pre-exist.
>
> Before that modification, you need to do some testing to see what
gets
> impacted.
>
> We had a perceptual problem when we used to do inventory
transactions
dated
> when the transaction actually occurred ... It is Monday and they
keying in
> transactions for work that was done Friday or over the weekend.
History
is
> populated in BPCS in the sequence the transactions actually done,
but
> someone looking at Inventory History is seeing dates jumbled.
>
> Well that means some transactions posted right away and some got
posted
> late, but it is confusing to a lot of users.
>
> >We are on version 6.01.01 mixed mode.
> >
> >We are about to start selling products world wide through different
> >offices throughout the world.  Does anyone know of a way to set date
and
> >times for the different time zones.  The system is located in NY and
we
> >used the system dates and times to process the data, but if our
Sydney
> >Office is running they are 1-day ahead and 14 hours different then
the
> >system date & time.  Any help would be greatly appreciated, thank
you in
> >advance.
>
> -
> Al Macintyre (macwheel99@sigecom.net via Eudora)
> Al's diary http://radio.weblogs.com/0107846/
>
>
>
> _______________________________________________
> This is the SSA's BPCS ERP System (BPCS-L) mailing list
> To post a message email: BPCS-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/bpcs-l
> or email: BPCS-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/bpcs-l.
>
>

_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/bpcs-l
or email: BPCS-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.

THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH 
IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL 
AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW.  If the reader of this message 
is not the intended recipient, or the employee or agent responsible for 
delivering the message to the intended recipient, you are hereby notified that 
any dissemination, distribution, copying, downloading, storing or forwarding of 
this communication is prohibited.  If you have received this communication in 
error, please notify us immediately via email and delete the message from your 
computer files and/or data base.  Thank you.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.