Gil,
Thank you for your time.
Adding the login option in BPXWUNIX did the trick.
Now i can see the correct time difference in Rexx.
This whole email was an attempt to search the cause of this same problem (wrong
time difference local/GMT) of a batch C program. I have supposed that the cause
of Rexx problem was the same of the C program.
This C program is supposed to present the time as localtime, but there is a 2
hour difference when time is printed.
To correct it, I had to include CEEOPTS DD card as below :
//CEEOPTS DD *
ENVAR('TZ=GMT-2')
It did the trick, but i still don't know why this time difference, since z/OS D
T command show me the correct timezone.
Best Regards
Ituriel
Em terça-feira, 1 de fevereiro de 2022 15:10:13 BRT, Paul Gilmartin
<[email protected]> escreveu:
On Tue, 1 Feb 2022 17:46:58 +0000, Ituriel do Neto wrote:
>
>The batch processing was tested with both IKJEFT* and IRXJCL, presenting the
>same results.
>Here follows the result of "echo $TZ; env" for batch processing :
>Tue Feb 1 17:12:14 2022 <=== blank
>line_=/bin/env Tue Feb 1 17:12:14 2022
>And in TSO OMVS, i got the following :
>GMT+2
> ...
You'll probably get more repeatable results if you use LOGIN=1:
<https://www.ibm.com/docs/en/zos/2.5.0?topic=functions-bpxwunix>.
But if you publish your code you'll probably get complaints from
subscribers with bogus TZ values in their profiles. You can only
tell them, "You broke it; you fix it!"
--
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN