SVC 26 (locate) with GDG datasets
George
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.
Vernooij, CP - SPLXM
"George" <jiri.a...@ca.com> wrote in message
news:<bff74657-e6dc-4185...@f16g2000yqm.googlegroups.com>
...
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 list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
J R
This ensures that the latest generation (+0) is always
located first.
_________________________________________________________________
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/
J R
> Date: Fri, 20 Nov 2009 09:09:51 -0500
> From: jaya...@HOTMAIL.COM
> Subject: Re: SVC 26 (locate) with GDG datasets
> To: IBM-...@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
Vernooij, CP - SPLXM
Yes, until z/OS 1.8.
Kees.
"J R" <jaya...@HOTMAIL.COM> wrote in message
news:<BLU137-W103F36A40...@phx.gbl>...
**********************************************************************
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
**********************************************************************
----------------------------------------------------------------------
David Andrews
> 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 9999 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....@duda.com
George
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?
J R
I have not yet been able to find documentation of the
change in behavior.
> 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.V...@KLM.COM
> > Subject: Re: SVC 26 (locate) with GDG datasets
> > To: IBM-...@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/
----------------------------------------------------------------------
Vernooij, CP - SPLXM
Have a look at APAR II14517, this describes the z/OS 1.8 new behaviour
for GDGs.
Kees.
"J R" <jaya...@HOTMAIL.COM> wrote in message
news:<BLU137-W18CDBBC29...@phx.gbl>...
> 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.a...@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.V...@KLM.COM
> > > Subject: Re: SVC 26 (locate) with GDG datasets
> > > To: IBM-...@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 list...@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
**********************************************************************
----------------------------------------------------------------------
rpace
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
J R
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.V...@KLM.COM
> Subject: Re: SVC 26 (locate) with GDG datasets
> To: IBM-...@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
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 00000000 003E0E60 05000000 *..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 40000000 * ...*
If you can find any problem in it, please let me know.
Thanks a lot!
Richard Pace
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
George
Sounds good. This could be the reason for this behavior.
Anyway I would like to get the same output as I can see in the ISPF. I
have to find a way to do that.
Good ideas are welcome.:)