On 2014-09-30 16:56, Farley, Peter x23353 wrote: >> >> Does STCK + STCKCONV yield UTC? I suspect not, but IBM refuses to >> document what it does, calling it "common knowledge", even though >> your common knowledge appears to differ from my suspicion. > > It seems obvious to me that when the LPAR you are on is using the recommended > UTC value for the hardware clock, of course UTC is what you are going to get > from STCK + STCKCONV. ISTR it has been stated more than once that STCKCONV > knows nothing about the CVT offset fields. > It may have been stated here; I find it in no IBM documentation, and my RCF was rejected; "common knowledge".
As I read the P[ro]Op, the recommended setting is not UTC, but TAI-10 seconds. >> Ours does local time. You probably set to GMT (the default) or omitted >> one of the N-1 too many ways to specify the offset. > > Yes, we use hardware clock = UTC here. I don't get to specify time zone > handling, so I have no idea what may or may not have been missed. > Us, too. We tried IBM's recommendation and it broke too much vendor software (including IBM's). I tried as an experiment to pull (GET) from the z/OS side rather than to push (PUT) from the outside. In that case: o FTP honored LOCSITE SPFSTATS (at least some of the time; it may depend on data set attributes). o FTP honored my personal setting of the TZ environment variable when defining the ISPF member stats; no need to be a sysprog. (But GET as opposed to PUT may not meet your needs.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
