Many things have been said and I won't repeat them. But most go beyond
what I'd consider a "pure COBOL" solution. I would break your question
down into two parts. The first is how to get a list of the names of
members in a particular PDS or PDSE data set. The second is how to
then read each member. HLASM uses BPAM. The DESERV macro can give you
a list of the member names. You could then use POINT to select a
member for processing, and READ to read the records. "Pure" COBOL does
not have that ability.
I will not address how to get a list of member using "pure" COBOL
beyond stating, as others have, that you can read and decode the
directory as it it were a PS data set with LRECL=256 BLKSIZE=256.
Doing this in COBOL should be possible, but tedious. And I'm at home
today. I may code this up on Monday and post it when I get it
debugged.
One thing not mentioned yet by anybody, and a possible pointer to a
solution, is that COBOL can now do dynamic allocation to allocate a
DSN with many different parameters. Or you could call BPXWDYN. This
requires a loop where you set up the DSN to be allocated; OPEN; READ
until EOF; CLOSE, and repeat.
The dynamic allocation is don by not having a DD for the DD specified
in the ASSIGN clause. You set up an "environment variable". This can
be done with the PUTENV routine. Short example (clips, not complete
code sequences). In example, the DSN is passed in via the PARM as the
only thing in the PARM.
FILE-CONTROL.
SELECT CONTROL-CARD ASSIGN TO DSNAME
ORGANIZATION IS SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS CONTROL-CARD-FILE-STATUS-1.
LOCAL-STORAGE SECTION.
77 RETURN-DATA PIC X(4).
01 ENV-DATA.
05 FILLER PIC X(11) VALUE 'DSNAME=DSN('.
05 DSN PIC X(110) VALUE IS LOW-VALUES.
01 P POINTER.
01 RC PIC S9(9) BINARY.
LINKAGE SECTION.
01 MVS-PARM.
05 MVS-PARM-LENGTH PIC S999 USAGE BINARY.
05 MVS-PARM-VALUE PIC X(120) .
PROCEDURE DIVISION USING MVS-PARM.
START-UP.
IF MVS-PARM-LENGTH > +100 THEN
DISPLAY 'INPUT PARM TOO LONG > 100' UPON SYSOUT
MOVE +8 TO RETURN-CODE
STOP RUN
END-IF
MOVE MVS-PARM-VALUE(1:MVS-PARM-LENGTH) TO
DSN(1:MVS-PARM-LENGTH)
MOVE ') SHR' TO DSN(MVS-PARM-LENGTH + 1:5)
MOVE LOW-VALUES TO DSN(MVS-PARM-LENGTH + 6:1)
SET P TO ADDRESS OF ENV-DATA
CALL 'PUTENV' USING BY VALUE P RETURNING RC
IF RC > 0 THEN
DISPLAY 'PUTENV FAILED RC=' RC UPON SYSOUT
MOVE +8 TO RETURN-CODE
STOP RUN
END-IF
In the above code DSNAME is the name of the environment variable in
the ASSIGN TO clause. It is set via the PUTENV by passing "DSNAME=..."
The "DSNAME" portion is the name of the environment variable to set.
This is just like a UNIX export command: export DSNAME='...' except
that the value does not need to be inside ' marks and must be
delimited with a LOW-VALUES (0x00, or x'00').
The COBOL documentation on this starts here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/4.2.3.1
Or it may be conceptually easier to use BPXWDYN as the subroutine to
do an ALLOCATE and free. That's up to you. Personally, I prefer the
PUTENV approach. But that's just me.
On Sat, Jul 6, 2013 at 10:31 PM, Ze'ev Atlas <[email protected]> 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 [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
