This technique also works in C or Java.

Unfortunately, the overhead of allocate/open/close/free for each member
does not yield good performance if that matters for your application.

It is a pity, IMO, that the C library does not include BPAM extensions to
fopen()

Kirk Wolf
Dovetailed Technologies
http://dovetail.com


On Tue, Jul 9, 2013 at 12:16 PM, Rick Arellanes <arell...@us.ibm.com> wrote:

> The answer is yes, you can use COBOL to read a PDS directory and process
> each member separately. Define 2 files: 1 (PDS-DIR) to read the PDS
> directory and one (PDS-FILE) to read each member. The one to read the
> directory (PDS-DIR) is RECORDING MODE U with a record of PIC X(256). The
> other (PDS-FILE) is to read the member (e.g., RECORDING MODE F with a
> record of PIC X(80)). Define a LINKAGE SECTION item to map the PDS
> directory layout (you can find this in the DFSMS books).
>
> Now, use the COBOL built-in dynamic allocation support to open the PDS
> directory (do not define a DD statement in the JCL for these files since
> COBOL's dynamic allocation support will be bypassed if a DD already exists):
> MOVE z"PDSDIR" TO ENV-NAME
> MOVE z"DSN(HLQ.PDSTEST).SHR" TO ENV-VALUE
> MOVE 1 TO ENV-OVERWRITE
> CALL "setenv" USING ENV-NAME, ENV-VALUE, ENV-OVERWRITE
> OPEN INPUT PDS-DIR
> Loop to read the PDS directory to get each member name and process the
> memberl stop when you reach the end
>
> To process each member:
> MOVE z"PDSFILE" TO ENV-NAME
> Use INSPECT and STRING to build the PDS data set name with member name in
> ENV-VALUE in the form of DSN(HLQ.PDSTEST(MEMBER)),SHR" with a null
> termination
> MOVE 1 TO ENV-OVERWRITE
> CALL "setenv" USING ENV-NAME, ENV-VALUE, ENV-OVERWRITE
> OPEN INPUT PDS-FILE
> Read each record until EOF
> CLOSE PDS-FILE
> and repeat the processing with the next member
>
> CLOSE PDS-DIR
>
> When you change the ENV-VALUE for each DD name, COBOL will do the dynamic
> deallocation and dynamic allocation again using the new values.
>
> The ENV-xxx values are defined as:
> 01 ENV-VARS.
>    05 ENV-NAME                      PIC X(9).
>    05 ENV-VALUE                     PIC X(100).
>    05 ENV-OVERWRITE            PIC S9(8) COMP.
>
> Rick Arellanes (IBM COBOL Development)
>
> On Sat, 6 Jul 2013 22:31:22 -0500, Ze'ev Atlas <zatl...@yahoo.com> wrote:
>
> >Hi All
> >I would assume that this question was asked many times before, but I
> could not have yet find the answer.
> >
> >I need to write a native z/OS COBOL program and it cannot be done in any
> of the other popular languages or environments for the reasons enumerated
> below.  The program should be a driver that gets a PDS or PDSE library
> name, reads the directory of that library and then opens each member in
> turn in a loop and reads it and apply some process that uses calls to some
> LE package.  Could that be done and is there any freely available sample
> code?
> >
> >
> >Reasons why I cannot use other solutions
> >I know that there are other GREAT solutions, by far better then my
> solution.  I agree in advance with anybody who has a better solution, but I
> am not interested:
> >I do not know PL/I well enough and am not interested in improving my
> knowledge.
> >Rexx would not cut it in this case because Rexx interface with persistent
> LE environment is complicated
> >I know how to do it in Assembler but I am refraining from coding in
> Assembler any more
> >It cannot be using USS as the whole purpose of the project is doing
> something from within native z/OS.
> >I am not interested in the existing IBM (or vendor) utilities since I
> need  to apply my process to each member and each line in that member.
>  Also, vendor utilities may not be available to everybody.
> >
> >
> >The only solution other then COBOL driver that I could consider is if it
> could be done from within the SORT utility (as the driver) because of its
> ubiquity, but I could not figure out whether and how it could be done.
> >
> >Thanks
> >ZA
> >
> >----------------------------------------------------------------------
> >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
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to