On 2014-09-30 12:23, Farley, Peter x23353 wrote: > That explains the behavior I saw, though it does not excuse it. My tests > used LRECL=1028. Why in the world does LRECL have anything at all to do with > whether ISPF statistics are recorded or not? That just makes no sense to me > whatsoever. > I just created a member (VB,1100) with NFS, and ISPF stats were created. Probably FTP (IBM) presumes that with records so big you'll have a shortage of space on the volume for directory metadata. IBM knows best. "What's good for General Bullmoose is good for America." The full employment policy for tech writers?
> Another sad fact is that when the z/OS FTP server does set the ISPF > statistics, it seems to use a simple-minded STCK + STCKCONV algorithm, since > in my tests the date and time are set to UTC instead of setting them to the > local time using the CVT time zone values. It makes the ISPFSTATS option a > lot less useful, IMHO. There ought to exist another SITE option to change > that behavior when the receiving z/OS system is known a priori to be using > UTC time in the hardware clock. I would suggest ISPFSTATS[=UTC|LOCAL] if I > could, where "LOCAL" means use the CVT values to adjust the STCK time before > STCKCONV. > 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. 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. Underreacher. Such timestamps should unconditionally be stored as GMT (UTC. TAI. (E)TOD. Whatever) and converted only for display by applying the offset in effect at the file creation time in the locale selected by the user (not the system administrator). There are more than two time zones. It's mind-boggling that in this 21st Century customers cling dearly to an OS that doesn't uniformly record file timestamps and sizes. From any other vendor to which they weren't locked in by legacy strictures, they simply wouldn't buy. And IBM missed an opportunity to fix it at the dawn of PDSE. At that time the directory metadata could have been specified to include sizes and timestamps, and an API provided to extract or set it. (Perhaps it already exists; but secretly.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
