on 10-29-2007 12:44 PM
NA does not set the clocks back until next weekend, however we ran in to a strange case today with out making any changes to our environments.
First, our Production servers are working fine. The problem only exists in our DEV/QAS systems. They are two independent 400's.
SAP is generating numerous short dumps, ZDATE_LARGE_TIME_DIFF and thinking our server is set to UTC. This is not the case we should be UTC minus 4 hours. Our QTIMZON is QN0400UTCS and our QUTCOFFSET is -04:00. These are the same on our Production box.
When I log in as QASOFR and do a WRKENVVAR I find PASE_TZ set to 'UTC:S4' not '<UTC-04x00S>4' which is set for PRD.
I can manually change the value for QAS and then the time is represented correctly (when I CALL QP2TERM and type DATE) however the value does not stay because it is set by R3INLPGM.
The other thing I find odd is on our production box I can CALL QP2TERM and type DATE to get the correct time as QSECOFR that does not have PASE_TZ set at all.
Thank you for any advice.
Thank you Volker for your suggestions.
The problem was resolved by loading the most recent HIPER (SF99539 56). I am not sure which PTF did the trick, as we were down a couple levels.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Erick,
you could add the following:
ADDENVVAR ENVVAR(PASE_TZ) VALUE('<UTC-04x00S>4') LEVEL(*SYS)
Then it should work (as workaround) on Q as well ...
I guess, there is an error in the r3inlpgm ... did you update to the latest version ?
Regards
Volker Gueldenpfennig, consolut international ag
http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
83 | |
24 | |
12 | |
9 | |
7 | |
6 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.