Re: FAMS?
Paul Gilmartin wrote: >o ISPF and NFS show different timestamps. UTC and/or local time? If not, then it is time to submit a formal request to IBM. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FAMS?
On Wed, 20 Jul 2016 08:34:44 -0400, Steve Smith wrote: >ISPF stats are kept in the user data part of the directory entries. >IEBCOPY copies directory entries as-is (except for some updates needed for >load modules & program objects). > >I don't know what NFS is looking at, but it's not ISPF stats. I wouldn't >expect it to, so my guess is everything is working as designed. > NFS doc mentions FAMS, if available, then ISPF stats, then DSCB, then catalog, and last current TOD. I find it hard to believe that it was a design requirement that: o ISPF and NFS show different timestamps. o HSM migrate/recall replicates both timestamps. o IEBCOPY alters the timestamp shown by NFS but not that shown by ISPF. o LMMSTATS updates the timestamp shown by ISPF but not that snown by NFS. There's probably an etc. All this strikes me less as design than as implementation indolence. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FAMS?
ISPF stats are kept in the user data part of the directory entries. IEBCOPY copies directory entries as-is (except for some updates needed for load modules & program objects). I don't know what NFS is looking at, but it's not ISPF stats. I wouldn't expect it to, so my guess is everything is working as designed. sas On Tue, Jul 19, 2016 at 8:09 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Tue, 19 Jul 2016 15:37:03 -0400, Steve Smith wrote: > > >The first rule of FAMS is you don't talk about FAMS. :-) > > > >I don't think that denying its existence is part of the contract, but I > >can't say anything else about it. > > > Hmmm... If I IEBCOPY a PDSE to another PDSE, ISPF member list shows > that the timestamps from SYSUT1 are replicated in SYSUT2. I believe > this is quite deliberate. > > However, NFS shows for SYSUT2 the timestamps as the time of the > IEBCOPY job step, neither the timestamps shown for SYSUT1 nor the > timestamps shown by ISPF. This seems wrong. Is it APARable? > > (If I submit an SR I'll not talk about FAMS. It seems prudent to be > disingenuous here.) > > Perhaps an RCF? > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FAMS?
On Tue, 19 Jul 2016 15:37:03 -0400, Steve Smith wrote: >The first rule of FAMS is you don't talk about FAMS. :-) > >I don't think that denying its existence is part of the contract, but I >can't say anything else about it. > Hmmm... If I IEBCOPY a PDSE to another PDSE, ISPF member list shows that the timestamps from SYSUT1 are replicated in SYSUT2. I believe this is quite deliberate. However, NFS shows for SYSUT2 the timestamps as the time of the IEBCOPY job step, neither the timestamps shown for SYSUT1 nor the timestamps shown by ISPF. This seems wrong. Is it APARable? (If I submit an SR I'll not talk about FAMS. It seems prudent to be disingenuous here.) Perhaps an RCF? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FAMS?
The first rule of FAMS is you don't talk about FAMS. :-) I don't think that denying its existence is part of the contract, but I can't say anything else about it. sas On Tue, Jul 19, 2016 at 12:05 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 18 Jul 2016 23:05:44 -0400, Steve Smith wrote: > > >FAMS is a secret interface. IBM may or may not provide the > >documentation upon receipt of a signed NDA, and presumably, a "nominal" > fee. > > > I'm aghast! You mean IBM has (finally) started keeping timestamps on > (some) files but to see them a customer must sign an NDS and pay for > the privilege (or use NFS)? What century does IBM think this is, anyway!? > > Are you allowed even to tell me it's secret? I suppose that explains the > conspicuous silence here of IBM employees. I wonder whether the > meager information will be removed from future editions of the NFS > description. And from the APARs. > > > On Tue, 19 Jul 2016 07:39:00 -0400, Ken Smith wrote: > > >You probably knew this but if you can run under ISPF, batch or > interactive, > >use LMMSTATS. > > > I believe not. As an experiment, I created a couple PDS members with > IEBGENER, no ISPF involved. NFS shows timestamps consistent with > those in the job log and differing by 0.1995 seconds which I assume is > job step overhead. ISPF member list shows no stats whatever for those > members. Would LMMSTATS in a program show me any different? > If you believe so, I'll try an experiment, but I'm skeptical. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FAMS?
On Mon, 18 Jul 2016 23:05:44 -0400, Steve Smith wrote: >FAMS is a secret interface. IBM may or may not provide the >documentation upon receipt of a signed NDA, and presumably, a "nominal" fee. > I'm aghast! You mean IBM has (finally) started keeping timestamps on (some) files but to see them a customer must sign an NDS and pay for the privilege (or use NFS)? What century does IBM think this is, anyway!? Are you allowed even to tell me it's secret? I suppose that explains the conspicuous silence here of IBM employees. I wonder whether the meager information will be removed from future editions of the NFS description. And from the APARs. On Tue, 19 Jul 2016 07:39:00 -0400, Ken Smith wrote: >You probably knew this but if you can run under ISPF, batch or interactive, >use LMMSTATS. > I believe not. As an experiment, I created a couple PDS members with IEBGENER, no ISPF involved. NFS shows timestamps consistent with those in the job log and differing by 0.1995 seconds which I assume is job step overhead. ISPF member list shows no stats whatever for those members. Would LMMSTATS in a program show me any different? If you believe so, I'll try an experiment, but I'm skeptical. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FAMS?
You probably knew this but if you can run under ISPF, batch or interactive, use LMMSTATS. Otherwise found this on the format of the PDS directory: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54mc00/ispmc28.htm Ken On Mon, Jul 18, 2016 at 12:18 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > After my questions in a couple fora went unanswered, I looked further > into NFS documentation: > > z/OS Network File System Guide and Reference > SC26-7417-13 > > ... File time stamps in UNIX format are part of the attributes required > by the NFS protocol for NFS client/server communication. ... > > 2. MVS maintains the PDSE member create/change time stamp (mtime) in > the > PDSE AX cell. The Server uses a FileAccessMethodService (FAMS) > call ... > > A Google search for FAMS returns the NFS reference, a SHARE presentation, > a RFE, > and several APARs. > > Where is this thing documented? It should be useful. > > Also, from the NFS Guide: > > ... The server uses the following main time stamp sources to generate > UNIX time stamps for MVS z/OS conventional (legacy) file systems: > > DSCB (data set control block) > Master Catalog data set attribute extension (AX) cell > PDSE member attribute extension (AX) cell > ISPF member statistics > TOD (current time_of_day on the server side). > > Rube Goldberg. > > -- gil > > -- > 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
Re: FAMS?
FAMS is a secret interface. IBM may or may not provide the documentation upon receipt of a signed NDA, and presumably, a "nominal" fee. sas On 7/18/2016 12:18, Paul Gilmartin wrote: After my questions in a couple fora went unanswered, I looked further into NFS documentation: z/OS Network File System Guide and Reference SC26-7417-13 ... File time stamps in UNIX format are part of the attributes required by the NFS protocol for NFS client/server communication. ... 2. MVS maintains the PDSE member create/change time stamp (mtime) in the PDSE AX cell. The Server uses a FileAccessMethodService (FAMS) call ... A Google search for FAMS returns the NFS reference, a SHARE presentation, a RFE, and several APARs. Where is this thing documented? It should be useful. Also, from the NFS Guide: ... The server uses the following main time stamp sources to generate UNIX time stamps for MVS z/OS conventional (legacy) file systems: DSCB (data set control block) Master Catalog data set attribute extension (AX) cell PDSE member attribute extension (AX) cell ISPF member statistics TOD (current time_of_day on the server side). Rube Goldberg. -- gil -- 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
FAMS?
After my questions in a couple fora went unanswered, I looked further into NFS documentation: z/OS Network File System Guide and Reference SC26-7417-13 ... File time stamps in UNIX format are part of the attributes required by the NFS protocol for NFS client/server communication. ... 2. MVS maintains the PDSE member create/change time stamp (mtime) in the PDSE AX cell. The Server uses a FileAccessMethodService (FAMS) call ... A Google search for FAMS returns the NFS reference, a SHARE presentation, a RFE, and several APARs. Where is this thing documented? It should be useful. Also, from the NFS Guide: ... The server uses the following main time stamp sources to generate UNIX time stamps for MVS z/OS conventional (legacy) file systems: DSCB (data set control block) Master Catalog data set attribute extension (AX) cell PDSE member attribute extension (AX) cell ISPF member statistics TOD (current time_of_day on the server side). Rube Goldberg. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
