Re: World Wide Operations -- BPCS-L

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.
>
>