Have you looked at the newer DESERV macro? It can fetch the entire directory of a PDS or PDSE "in one gulp". You can then use that information to position to each member as you need (in order or random or ???) using the FIND macro. In this case, the FIND does not read the directory again, but uses the SMDE read by the DESERV to position the TTR to the beginning of the selected member described by the SMDE.
ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.8.7.4.2 <quote> 3.8.7.4.2 FUNC=GET_ALL The GET_ALL function returns SMDEs for all the member names in a PDS, a PDSE, or a concatenation of PDSs and PDSEs. Member level connections can be established for each member found in a PDSE. A caller uses the CONCAT parameter to indicate which data set in the concatenation is to be processed, or whether all of the data sets in the concatenation are to be processed. If the caller requests that *DESERV* GET_ALL return all the SMDE directory entries for an entire concatenation, the SMDEs are returned in sequence as sorted by the SMDE_NAME field without returning duplicate names. As with the GET function, all connections can be associated with a single connect identifier established at the time of the call. This connect identifier can then be used to release all the connections in a single invocation of the RELEASE function. See Figure 138<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.8.7.4.2?SHELF=DGT2BKA0.bks&DT=20100628133137#FIGDESFGAL> for an overview of control blocks related to the GET_ALL function. </quote> On Mon, Mar 25, 2013 at 8:46 AM, Thomas David Rivers <[email protected]>wrote: > I'm reworking some code to avoid multiple OPENs for > reading PDS members.. > > But, I will still be just reading one member at a time, > and I don't know the member names a-priori. > > The DFSMS documentation states that using BLDL + FIND > (and using the ttr,C form for FIND) results in a performance > improvement... over simply pointing FIND at the DCB. > > But - is that still true if the BLDL list is only for one member? > > That is, if you're looking for one member at a time, is there > a reason to prefer BLDL+FIND over a direct FIND of the DCB? > > It seems to me the next BLDL is going to have to read the PDS > directory to find the information; just like a FIND would have > to do??? > > - Thanks - > - Dave Rivers - > > -- > [email protected] Work: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > ------------------------------**------------------------------**---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
