On 10/07/2013 1:51 AM, Kirk Wolf wrote:
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()

IIRC, you already had a very neat idea of how to implement BPAM using freopen() https://groups.google.com/d/msg/bit.listserv.ibm-main/QvIsxXkemPc/3PeObd_3mhUJ.


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

----------------------------------------------------------------------
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