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 <0000000433f07816-dmarc-requ...@listserv.ua.edu> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN