This is by no means complete. I picked what I hope are relevant parts from
a larger exec that did a bunch more.
This should help demonstrate the hocus pocus though! :-)
/*Rexx -------------------------------------------------------------*/
/* Setup a loop to process the members of the DSN. */
/*------------------------------------------------------------------*/
ADDRESS 'ISPEXEC'
"LMINIT DATAID(DATAIDO) DATASET('"dsn"') ENQ(SHR)"
"LMOPEN DATAID("dataido")"
do until iRC > 0 /* start members */
ADDRESS 'ISPEXEC'
"LMMLIST DATAID("dataido") OPTION(LIST) MEMBER(MEMBER) STATS(YES)"
iRC=RC
ADDRESS "ISPEXEC"
"LMMSTATS DATAID("dataido") MEMBER("member") VERSION("newver")",
"MODLEVEL(01) MODTIME("zlmtime") INITSIZE("zlinorc")",
"MODRECS("zlmnorc") USER("zluser") CREATED4("zlc4date")",
"MODDATE4("zlm4date")"
end
ADDRESS "ISPEXEC"
"LMMLIST DATAID("dataido") OPTION(FREE)"
"LMCLOSE DATAID("dataido")"
On Tue, Sep 30, 2014 at 7:42 PM, Tony's Basement Computer <
tbabo...@comcast.net> wrote:
> Years ago, I'm guessing maybe 10, I wanted to do exactly that, create a
> PDS or PDSE, by writing a bunch of members, then in the next job step reset
> all the stats, just to get record counts. Being too lazy to go 3.5 or S *
> G, I posted this request to the list. Some kind REXXer sent in a reply, I
> believe LMxxx hocus pocus was involved. I went through the exercise of
> wrapping JCL around the REXX and used it for years. Sadly it was lost in
> one of my many previous layoffs. An archive search might just turn it up.
> Time frame would be 2001-2011 more or less.
>
>
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Tuesday, September 30, 2014 5:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nims,Alva John (Al)
> Sent: Tuesday, September 30, 2014 3:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Tuesday, September 30, 2014 2:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nims,Alva John (Al)
> Sent: Tuesday, September 30, 2014 1:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Tuesday, September 30, 2014 12:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 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
>
> 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 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
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
