1st about being Lazy, I hear ya, queue up "There's No Business Like Show Business" and Marilyn Monroe (yes I am showing my age, a little).
In #357 is member, @LOADLIB, this is a XMIT of the author's LOADLIB, so receive it to recreate the LOADLIB data set, touch is in there already compiled. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 Sent: Tuesday, September 30, 2014 6:44 PM To: [email protected] Subject: Re: Any standard IBM tool to set ISPF statistics in a batch step? I did see the TOUCH program in # 357 but I missed COPYISPF in # 720. Unfortunately I don't have access to a PL/I compiler for TOUCH. By its description, COPYISPF is actually a Rexx program with assembler subroutines. As I said originally, I know I can do this myself in Rexx using the ISPF LMxxx functions, and I probably have enough code and JCL lying around that uses ISPF and LMxxx functions to code up an ADDSTAT routine. I was just hoping there was an existing alternative to writing it (besides PDS86). However, I was intrigued by the ISPF 3.5 function you mentioned. I never even noticed that function existed (3.4, 3.12 to 3.15 and 3.17 are about all I ever use). Good question, why can't it be done in batch? This is an interesting line of research. Thank you for pointing it out. If I do figure out the secrets I'll post them. Thanks for chiming in, you were very helpful. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Nims,Alva John (Al) Sent: Tuesday, September 30, 2014 3:53 PM To: [email protected] Subject: Re: Any standard IBM tool to set ISPF statistics in a batch step? To further my contribution to this discussion, I was looking for a way to run the ISPF opt 3.5 in batch last year, when I was working as a contractor to IBM, but never did figure out the way to do so. Gee, they give us a way to SuperC Compare (3.12) in batch, why can't IBM give us 3.5! :) Now I know you asked for "Any standard IBM tool....", but if you don't mind, there are a couple of tools on the CBTTAPE (www.cbttape.org) that you might want to take a look into; File 357 has "TOUCH" a PL/I based program to modify ISPF Statistics. File 720 has "COPYISPF" which copies from one PDS to another while updating the ISPF Stats in the process. This is not exactly what you want, the author writes out some fixed information, but you might be able to modify to use current date/time information during the copy process. Just trying to be helpful. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 Sent: Tuesday, September 30, 2014 2:24 PM To: [email protected] Subject: Re: Any standard IBM tool to set ISPF statistics in a batch step? 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. Thank you for the RTFM pointer. 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. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Nims,Alva John (Al) Sent: Tuesday, September 30, 2014 1:41 PM To: [email protected] Subject: Re: Any standard IBM tool to set ISPF statistics in a batch step? For your VB data set, is the LRECL less than 256 (e.g.: 255 or less?). From "IP User's Guide and Commands v1.13 (SC31-8780-11)" it states on page 98: Note: ISPFStats is ignored for sequential data sets. Also, the record format must be either variable or fixed, and the record length must be less than 256. ----------------------------------------------------------------------------------- Transferring PDS member to PDS member in block mode or in compress mode differs in behavior from transferring in stream mode. If the user wants to preserve the statistics of a PDS member that already has the statistics and have the same statistics copied over to the target PDS member, transferring in block mode or in compress mode is required. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Tuesday, September 30, 2014 12:29 PM To: [email protected] Subject: Re: Any standard IBM tool to set ISPF statistics in a batch step? On Tue, 30 Sep 2014 11:54:54 -0400, Farley, Peter x23353 wrote: > >The motivation for this is the sad fact that the IBM FTP server does not set >statistics for RECFM=VB PDS/E members even when the SITE ISPFSTATS toggle is >set. It only does it for RECFM=FB PDS/E members, even at the z/OS V2.1 level. > WTF!? And why? I hadn't noticed that. Is it because it's easier to count lines if RECFM=FB (count bytes and divide by LRECL)? Or because revision level is/isn't available as the last two characters of the sequence numbers (shouldn't matter). Is this documented? Does NFS have the same behavior? I'll need to test. I know that "touch" via NFS fails to update the time stamp. Can the programmer enable/disable stats with NFS? If the data originate from a z/OS (or CMS) system, it might be better to use TRANSMIT (SENDFILE)/RECEIVE. If you want to copy to/from a UNIX (etc.) system and replicate timestamps, you're probably SOL. (TRANSMIT/RECEIVE may have a 1-hour skew if a Daylight Saving boundary (or the Equator) is between. They could have done better.) -- 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
