Re: SVC 26 (locate) with GDG datasets
On Nov 24, 7:01 am, George wrote: > > George: > > It might help if you give the details of the parameters you are using > > for CTGPL, CTGFL, etc. > > I happened to be working on a different problem in this area, so I > > tried to recreate your problem. > > The returned list is the same regardless of the mask used. > > > Regards, > > Richard > > Hi Richard, > Thanks. I am using this parameters for SVC 26: > > R1 points to (CTGPL): > 003DBA8C 8f 85201108 *e...* > 003DBA90 8f 0006A7B0 003E0E60 0500 *..x-* > > Also this address could be useful: > 0006A7B0 8f 15C8D3D8 F0F0F04B E2D4E24B C7C4C74B *.HLQ000.SMS.GDG.* > 0006A7C0 8f E3C5E2E3 4BC74040 40404040 40404040 *TEST.G * > 0006A7D0 8f 40404040 40404040 40404040 4000 * ...* > > If you can find any problem in it, please let me know. > Thanks a lot! Hi George: I suspect you have an SMS GDG defined with limit 2 and NOSCRATCH. You have two GDS entries in the BASE, 4 and 5. And one data set rolled off but cataloged as G0003V00. So the phenomenon you see is based on the search mask. When you search with "HQL.TEST", catalog returns the GDG base entry first and lists generation 4 and 5. Then returns the catalog entry for HQL.TEST.G0003V00. When you search with "HQL.TEST.", catalog finds, HQL.TEST.G0003V00 first because it has a real catalog entry that matches. And then I presume, because the last character is a period, it then finds the HQL.TEST GDG base and returns generation 4 and 5. When you search with "HQL.TEST.G" catalog only returns "HQL.TEST.G0003V00" because this data set has a real catalog entry. In fact, I setup a GDG just as I described and duplicated your scenario. Regards, Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC 26 (locate) with GDG datasets
Thanks for the reference. However, II14517 and the underlying II14250 seem to deal specifically with IDCAMS LISTCAT being changed to use CSI rather than the base SVC26 LOCATE. "In z/OS V1R8, LISTCAT was modified to use the Catalog Search Interface (CSI). The objects returned from CSI are defined by the CSI interface and may produce different results than the prior generic LOCATE interface rules." The OP implied that he was using the "generic" SVC26 LOCATE which, from the quoted paragraph above, seems not to have changed. Therefore, presumably, GDG ALL has not changed either. > Date: Mon, 23 Nov 2009 16:57:33 +0100 > From: kees.vern...@klm.com > Subject: Re: SVC 26 (locate) with GDG datasets > To: IBM-MAIN@bama.ua.edu > > > Have a look at APAR II14517, this describes the z/OS 1.8 new behaviour > for GDGs. > > Kees. > _ Bing brings you maps, menus, and reviews organized in one place. http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=TEXT_MFESRP_Local_MapsMenu_Resturants_1x1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC 26 (locate) with GDG datasets
On Nov 23, 2:18 am, George wrote: > Thanks a lot for your answers. > > I still don’t understand why I can’t see all datasets when using > 'HLQ.TEST.G' mask. I tried to find any IBM documentation about it but > without any success. Don’t you know where I can find more info about > it? George: It might help if you give the details of the parameters you are using for CTGPL, CTGFL, etc. I happened to be working on a different problem in this area, so I tried to recreate your problem. The returned list is the same regardless of the mask used. Regards, Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC 26 (locate) with GDG datasets
Have a look at APAR II14517, this describes the z/OS 1.8 new behaviour for GDGs. Kees. "J R" wrote in message news:... > Similarly, while I am sure that Kees is right about z/OS 1.8, > I have not yet been able to find documentation of the > change in behavior. > > > > From: George jiri.aich...@ca.com > > Date: Mon, 23 Nov 2009 02:18:01 -0800 > > > Thanks a lot for your answers. > > > I still don't understand why I can't see all datasets when using > > 'HLQ.TEST.G' mask. I tried to find any IBM documentation about it but > > without any success. Don't you know where I can find more info about > > it? > > > > > Date: Fri, 20 Nov 2009 15:49:59 +0100 > > > From: kees.vern...@klm.com > > > Subject: Re: SVC 26 (locate) with GDG datasets > > > To: IBM-MAIN@bama.ua.edu > > > > > > > > > Yes, until z/OS 1.8. > > > > > > Kees. > > > > > > _ > Hotmail: Trusted email with Microsoft's powerful SPAM protection. > http://clk.atdmt.com/GBL/go/177141664/direct/01/ > http://clk.atdmt.com/GBL/go/177141664/direct/01/ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC 26 (locate) with GDG datasets
Similarly, while I am sure that Kees is right about z/OS 1.8, I have not yet been able to find documentation of the change in behavior. > From: George jiri.aich...@ca.com > Date: Mon, 23 Nov 2009 02:18:01 -0800 > Thanks a lot for your answers. > I still don’t understand why I can’t see all datasets when using > 'HLQ.TEST.G' mask. I tried to find any IBM documentation about it but > without any success. Don’t you know where I can find more info about > it? > > Date: Fri, 20 Nov 2009 15:49:59 +0100 > > From: kees.vern...@klm.com > > Subject: Re: SVC 26 (locate) with GDG datasets > > To: IBM-MAIN@bama.ua.edu > > > > > > Yes, until z/OS 1.8. > > > > Kees. > > _ Hotmail: Trusted email with Microsoft's powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141664/direct/01/ http://clk.atdmt.com/GBL/go/177141664/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC 26 (locate) with GDG datasets
On Fri, 2009-11-20 at 08:53 -0500, Vernooij, CP - SPLXM wrote: > This is the case since z/OS 1.8. GDG members are not kept in numerical > order in the catalog anymore and therefor not returned in numerical > order either. The only way to get them returned in numerical order is by > calling a new alias of IDCAMS (I don't have the alias name ready). I know we're discussing Locate, but in 2003 I wrote some code to use the CSI. If you present a base GDG name you can retrieve a list of associations (i.e. generation datasets that are currently active). I experimentally determined that the CSI presents these associations in logical sequence -- if one generation has rolled over from to 0001 for example, the associated datasets will be in chronological sequence. Don't know for sure if that's still the case, but my code hasn't broken recently. I wonder if the OP has to use Locate? -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC 26 (locate) with GDG datasets
Yes, until z/OS 1.8. Kees. "J R" wrote in message news:... > I meant to add that it's been this way since the '60s. > > > > > > Date: Fri, 20 Nov 2009 09:09:51 -0500 > > From: jayare...@hotmail.com > > Subject: Re: SVC 26 (locate) with GDG datasets > > To: IBM-MAIN@bama.ua.edu > > > > GDG member numbers are complemented in the catalog. > > This ensures that the latest generation (+0) is always > > located first. > > > > _ > Windows 7: I wanted simpler, now it's simpler. I'm a rock star. > http://www.microsoft.com/Windows/windows-7/default.aspx?h=myidea?ocid=PI D24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_myidea:112009 > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC 26 (locate) with GDG datasets
I meant to add that it's been this way since the '60s. > Date: Fri, 20 Nov 2009 09:09:51 -0500 > From: jayare...@hotmail.com > Subject: Re: SVC 26 (locate) with GDG datasets > To: IBM-MAIN@bama.ua.edu > > GDG member numbers are complemented in the catalog. > This ensures that the latest generation (+0) is always > located first. > _ Windows 7: I wanted simpler, now it's simpler. I'm a rock star. http://www.microsoft.com/Windows/windows-7/default.aspx?h=myidea?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_myidea:112009 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC 26 (locate) with GDG datasets
GDG member numbers are complemented in the catalog. This ensures that the latest generation (+0) is always located first. > "George" wrote in message > news: > ... > Hello, > I have a question about Locate macro (SVC 26) and GDG datasets. For > example I have these datasets: > HLQ.TEST > HLQ.TEST.G0003V00 > HLQ.TEST.G0004V00 > HLQ.TEST.G0005V00 > > When I use mask 'HLQ.TEST' the output from SVC 26 is: > HLQ.TEST > HLQ.TEST.G0004V00 > HLQ.TEST.G0005V00 > HLQ.TEST.G0003V00 > The problem is that datasets are not in correct (alphabetical) order, > while other datasets are always in the correct order. Is it okay? I > can't find any info about the order of the output. > > When I use mask 'HLQ.TEST.' the output is: > HLQ.TEST.G0003V00 > HLQ.TEST.G0004V00 > HLQ.TEST.G0005V00 > This time the order is correct. Strange... > > When I use mask 'HLQ.TEST.G' the output is: > HLQ.TEST.G0003V00 > This time 2 datasets are not even returned. > > Do you know why this is happening? I am using CTGPL dsect as an input > (superlocate). I would like to know if this is IBM bug or am I just > incorrectly setting the locate macro. This is happening only with GDG > datasets, other datasets are returned always correctly. > -- _ Hotmail: Trusted email with Microsoft's powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141664/direct/01/ http://clk.atdmt.com/GBL/go/177141664/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC 26 (locate) with GDG datasets
"George" wrote in message news: ... Hello, I have a question about Locate macro (SVC 26) and GDG datasets. For example I have these datasets: HLQ.TEST HLQ.TEST.G0003V00 HLQ.TEST.G0004V00 HLQ.TEST.G0005V00 When I use mask 'HLQ.TEST' the output from SVC 26 is: HLQ.TEST HLQ.TEST.G0004V00 HLQ.TEST.G0005V00 HLQ.TEST.G0003V00 The problem is that datasets are not in correct (alphabetical) order, while other datasets are always in the correct order. Is it okay? I can't find any info about the order of the output. When I use mask 'HLQ.TEST.' the output is: HLQ.TEST.G0003V00 HLQ.TEST.G0004V00 HLQ.TEST.G0005V00 This time the order is correct. Strange... When I use mask 'HLQ.TEST.G' the output is: HLQ.TEST.G0003V00 This time 2 datasets are not even returned. Do you know why this is happening? I am using CTGPL dsect as an input (superlocate). I would like to know if this is IBM bug or am I just incorrectly setting the locate macro. This is happening only with GDG datasets, other datasets are returned always correctly. -- This is the case since z/OS 1.8. GDG members are not kept in numerical order in the catalog anymore and therefor not returned in numerical order either. The only way to get them returned in numerical order is by calling a new alias of IDCAMS (I don't have the alias name ready). Kees. PS. This newsgroup is a mirror of a listserver, where the majority of IBM-MAIN reads the articals. See the information attached automagically below. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
