The few times I have had it wrap, you can check the highest record returned, it will be 9999 (if the -1 is 9998 you are there as well ) and then you can do a search from the bottom looking for the “Hole” in the numbering. I have had to do it a few times, but it is so infrequent (took our shop 20+ years to start wrapping GDGs) that I usually leave the search out, but I still think it is faster then calling an external module. Also, the GDGs that wrapped, only had this issue for a short while (then you could no longer tell they were wrapped).
My next choice would be BPXWDYN to allocate the relative DSN I am looking for and get the INFO. I like this because it works everywhere, (MVS, TSO, USS, SystemREXX, ….) and it is part of the Base System. Getting “extensions” out into the system sometimes is the most difficult option. As consultant, I have had situations where this was turned down automatically, as they did not want to verify the harmlessness of the program and they did not want to support the code. Yes, there is no difference between the what the REXX could do vs an non-AC(1) program in a non-APF authorized location and they had to support the REXX code anyway … sometimes you cannot win that argument. _______________ Al Ferguson | mailto:[email protected] Milwaukee, WI USA | http://www.neptunescove.org Dulcius ex Asperis > On 21 August 2019, at 14:55, Al Ferguson <[email protected]> wrote: > > Another option would be to use the Catalog Search Interface (CSI). I have an > example in CBTTape.org <http://cbttape.org/> File #960 (the DSNLIST REXX). If > you are going for just the G00V000s, then the value of the just subtract the > Relative DSN from the number of records returned take that record. For > example if you get 32 records returned, and you want the “-1”th relative DSN, > then the (32-1) or 31st record will have you full DSN. > > This does no allocations and just returns values from the Catalog, about as > efficient as you are going to get. No need to load the RXLOCATE Module, > initialize LE, and return the value, as the CSI is always available and > running. > > > _______________ > > Al Ferguson | mailto:[email protected] > <mailto:[email protected]> > Milwaukee, WI USA | http://www.neptunescove.org > > Dulcius ex Asperis > >> On 21 August 2019, at 13:19, Kirk Wolf <[email protected] >> <mailto:[email protected]>> wrote: >> >> Using LOCATE/CAMLST seems better than using SVC99/BPXWDYN to resolve >> relative->absolute since it doesn't require allocation of the data set, >> which might fail. >> >> One question that I have is (I assume) that LOCATE/CAMLST will always use >> the latest generations ("GDGNT"), so that if what you want is a stable >> "current" generation then it won't do the job. With SVC99/BPXWDYN, you >> can set or not set the "GDGNT" flag. >> >> Does anyone know how to resolve relative->absolute without allocation >> without "GDGNT" ? >> >> >> On Sun, Jul 28, 2019 at 4:01 PM Dan D <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Sam just updated my CBT file today (File 452 in the Updates). >>> >>> I had a tool called RXLOCATE that simply does a CAMLST LOCATE for a dsname >>> in LOCDSN variable. >>> >>> /*rexx*/ >>> LOCDSN = 'userid.GDG(-1)' */ >>> address LINK "RXLOCATE" >>> say LOCDSN 'RC=' rc >>> Exit >>> >>> After the LINK to RXLOCATE the LOCDSN variable will have the absolute name >>> or true name. >>> >>> Dan >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [email protected] <mailto:[email protected]> >>> with the message: INFO IBM-MAIN >>> >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] <mailto:[email protected]> >> with the message: INFO IBM-MAIN >> > > > > _______________ > > Al Ferguson | mailto:[email protected] > Milwaukee, WI USA | http://www.neptunescove.org > > Dulcius ex Asperis > > > ---------------------------------------------------------------------- > 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
