> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Paul Gilmartin > Sent: Tuesday, September 30, 2014 4:41 PM > To: [email protected] > Subject: Re: Any standard IBM tool to set ISPF statistics in a batch step? > > > 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. 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. > 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. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
