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! >>> email@example.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" <firstname.lastname@example.org> To: <email@example.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 (firstname.lastname@example.org 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-Lemail@example.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-Lfirstname.lastname@example.org 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.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.