Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

LISTDSI for tape datasets

652 views
Skip to first unread message

Harold Mains

unread,
May 7, 2013, 5:32:38 PM5/7/13
to
In a batch job, in a REXX program, given a DDname found in the JCL, I can invoke LISTDSI as follows to obtain the DSN for that DDname:

X = LISTDSI(ddname FILE)

But LISTDSI in general and this code in particular fails when the DSN is for a tape dataset.

Is there any equivalent REXX-invokable command that will provide the DSN in the JCL for a tape dataset?


Thanks,

Harold Mains
California State Controller's Office
ISD Enterprise Systems Support
Phone (916) 324-7284

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

Paul Gilmartin

unread,
May 7, 2013, 5:39:21 PM5/7/13
to
On 2013-05-07 15:32, Harold Mains wrote:
> In a batch job, in a REXX program, given a DDname found in the JCL, I can invoke LISTDSI as follows to obtain the DSN for that DDname:
>
> X = LISTDSI(ddname FILE)
>
> But LISTDSI in general and this code in particular fails when the DSN is for a tape dataset.
>
> Is there any equivalent REXX-invokable command that will provide the DSN in the JCL for a tape dataset?
>
Try BPXWDYN( 'info ...' )

LISTDSI is brain-dead. It also will not provide information on
allocated UNIX files nor on JES data sets. And the information
it returns does _not_ take into account overriding DCB parameters.

-- gil

Harold Mains

unread,
May 7, 2013, 6:56:33 PM5/7/13
to
From what I can see of BPXWDYN, it allows me to allocate datasets to a DDname.

What is need is to be able to see the DSN of a tape dataset that was already allocated to a DDname in the JCL of the job that I am at this moment executing. This is what X = LISTDSI(ddname FILE) with its FILE parameter allows me to do for DASD datasets.
Can BPXWDYN do this? What does the command look like to do this?


Thanks,

Harold Mains
California State Controller's Office
ISD Enterprise Systems Support
Phone (916) 324-7284

Paul Gilmartin

unread,
May 7, 2013, 7:55:24 PM5/7/13
to
On 2013-05-07 16:56, Harold Mains wrote:
> From what I can see of BPXWDYN, it allows me to allocate datasets to a DDname.
>
> What is need is to be able to see the DSN of a tape dataset that was already allocated to a DDname in the JCL of the job that I am at this moment executing. This is what X = LISTDSI(ddname FILE) with its FILE parameter allows me to do for DASD datasets.
> Can BPXWDYN do this? What does the command look like to do this?
>
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB6A0/6.9

Title: z/OS V1R12.0 Using REXX and z/OS UNIX System Services
Document Number: SA22-7806-13
6.9 Requesting allocation information

Harold Mains

unread,
May 7, 2013, 8:24:00 PM5/7/13
to
This will work just fine.

Thanks,

Harold Mains
California State Controller's Office
ISD Enterprise Systems Support
Phone (916) 324-7284


-----Original Message-----
From: Paul Gilmartin [mailto:PaulGB...@AIM.com]
Sent: Tuesday, May 07, 2013 4:55 PM
To: TSO REXX Discussion List
Cc: Mains, Harold
Subject: Re: [TSO-REXX] LISTDSI for tape datasets

Harold Mains

unread,
May 9, 2013, 8:14:10 PM5/9/13
to
Out of scope, I know, but is there example code somewhere on how to call BPXWDYN from a batch COBOL program to obtain DSN for a DDNAME in the JCL of the job being executed. In REXX, as you told me, the following works: RCODE = BPXWDYN("INFO FI("DDNAME") INRTDSN(DSNAME)") with DSNAME receiving the dsn result, but it is not obvious to me and not found in any of my searches how INRTDSN(DSNAME) equivalent would be coded in COBOL. In other words, where the DSN would be returned.



Thanks,

Harold Mains
California State Controller's Office
ISD Enterprise Systems Support
Phone (916) 324-7284

-----Original Message-----
From: Paul Gilmartin [mailto:PaulGB...@AIM.com]
Sent: Tuesday, May 07, 2013 4:55 PM
To: TSO REXX Discussion List
Cc: Mains, Harold
Subject: Re: [TSO-REXX] LISTDSI for tape datasets

Bill Schoen

unread,
May 9, 2013, 9:44:58 PM5/9/13
to
For a C example see
http://vm.marist.edu/htbin/wlvtype?TSO-REXX.22173
You will have to translate that to cobol.
Something not shown in the example is R0 must be 0. C takes care of
that. I don't know if cobol has that same external calling convention.

Bill Schoen

Farley, Peter x23353

unread,
May 10, 2013, 12:30:31 PM5/10/13
to
Bill, are you sure of that requirement for R0 to be 0? I would think that because the regular C implementation produces an LE-structured program that R0 would not be specially treated for any function or subroutine call, even for a fetched program.

If the requirement is real, current COBOL (maybe not the new V5.1, but certainly any prior release) will likely not be able to use it, requiring an assembler (or Metal C) stub to make the call.

Peter

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Bill Schoen
Sent: Thursday, May 09, 2013 9:45 PM
To: TSO-...@vm.marist.edu
Subject: Re: LISTDSI for tape datasets

For a C example see
http://vm.marist.edu/htbin/wlvtype?TSO-REXX.22173
You will have to translate that to cobol.
Something not shown in the example is R0 must be 0. C takes care of
that. I don't know if cobol has that same external calling convention.

Bill Schoen
--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

Farley, Peter x23353

unread,
May 10, 2013, 4:14:36 PM5/10/13
to
Replying to my own post to verify that Bill's note about R0 is accurate, and that COBOL does NOT set R0 = 0 before invoking the module. If called directly BPXWDYN returns RC=20, invalid parameter list. I had to write an assembler subroutine to call BPXWDYN from a COBOL program (tested with Enterprise COBOL V4.1).

I am pasting the COBOL and assembler source here but if it doesn't format correctly write to me privately (NOT on the list please) and I will send you text files.

A better solution might be to code an LE-enabled assembler subroutine and take advantage of the CEE library routines. I leave that as an exercise for the reader.

Note that an extra first parameter (fullword binary) needs to be passed to the assembler module to store the actual BPXWDYN return code. If R15 from BPXWDYN is returned to COBOL directly in R15, COBOL code makes the value positive, which hides the possibly negative return code values that BPXWDYN can produce.

HTH

Peter


COBOL code to invoke the assembler module and call BPXWDYN dynamically:

ID DIVISION.
PROGRAM-ID. TESTWDYN.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-WORK-AREA.
05 WS-SUB PIC S9(4) BINARY.
05 WS-MSG-CNT PIC S9(4) BINARY.
05 WS-RC PIC S9(8) BINARY.
05 WS-RC-D PIC +(7)9.
05 WS-BPXWDYN PIC X(8) VALUE 'CBPXWDYN'.

01 WDYN-PARM.
05 WDYN-LENGTH PIC S9(4) BINARY VALUE 17.
05 WDYN-VALUE PIC X(016) VALUE
'ALLOC NEW DELETE'.
05 WDYN-NULL PIC X(001) VALUE LOW-VALUES.

01 DDNAME.
05 DDNAME-LENGTH PIC S9(4) BINARY VALUE 9.
05 DDNAME-VALUE.
15 FILLER PIC X(005) VALUE 'RTDDN'.
15 FILLER PIC X(003) VALUE LOW-VALUES.
05 DDNAME-NULL PIC X(001) VALUE LOW-VALUES.

01 DSNAME.
05 DSNAME-LENGTH PIC S9(4) BINARY VALUE 45.
05 DSNAME-VALUE.
15 FILLER PIC X(005) VALUE 'RTDSN'.
15 FILLER PIC X(039) VALUE LOW-VALUES.
05 DSNAME-NULL PIC X(001) VALUE LOW-VALUES.

01 MSG-0.
05 MSG-0-LENGTH PIC S9(4) BINARY VALUE 3.
05 MSG-0-VALUE PIC X(003) VALUE 'MSG'.
05 MSG-0-NULL PIC X(001) VALUE LOW-VALUES.

01 MSG-TABLE.
05 MSG OCCURS 9 TIMES.
10 MSG-X-LENGTH PIC S9(4) BINARY VALUE 258.
10 MSG-X-VALUE.
15 FILLER PIC X(004) VALUE 'MSG.'.
15 MSG-X-NO PIC 9(001) VALUE 1.
15 FILLER PIC X(252) VALUE LOW-VALUES.
10 MSG-X-NULL PIC X(001) VALUE LOW-VALUES.

PROCEDURE DIVISION.

PERFORM VARYING WS-SUB FROM 2 BY 1 UNTIL WS-SUB > 9
MOVE WS-SUB TO MSG-X-NO (WS-SUB)
END-PERFORM

CALL WS-BPXWDYN USING WS-RC, WDYN-VALUE, DDNAME, DSNAME,
MSG-0, MSG (1), MSG (2), MSG (3), MSG (4).

MOVE WS-RC TO WS-RC-D
DISPLAY WS-BPXWDYN ' RETURNED RC = ' WS-RC-D
DISPLAY WS-BPXWDYN ' DDNAME LENG = ' DDNAME-LENGTH
', DDNAME = ' DDNAME-VALUE
DISPLAY WS-BPXWDYN ' DSNAME LENG = ' DSNAME-LENGTH
', DSNAME = ' DSNAME-VALUE
DISPLAY WS-BPXWDYN ' MSG-0 LENG = ' MSG-0-LENGTH
', MSG-0 = ' MSG-0-VALUE

IF MSG-0-VALUE IS NUMERIC AND MSG-0-VALUE > '00'
MOVE MSG-0-VALUE TO WS-MSG-CNT
PERFORM VARYING WS-SUB FROM 1 BY 1
UNTIL WS-SUB > WS-MSG-CNT OR WS-SUB > 9
DISPLAY WS-BPXWDYN ' MSG(' WS-SUB ') LENGTH = '
MSG-X-LENGTH (WS-SUB)
', VALUE = '
MSG-X-VALUE (WS-SUB)
END-PERFORM
END-IF

GOBACK.

Assembler stub code:

CBPXWDYN CSECT ,
CCBXWDYN AMODE 31
CCBXWDYN RMODE ANY
YREGS ,
SYSSTATE ARCHLVL=2
STM R14,R2,12(R13) SAVE CALLER'S REGISTERS 14 TO 2
* THIS IS A STUB TO INVOKE THE Z/OS UNIX SERVICES SUBROUTINE BPXWDYN
* FROM COBOL WITH R0 = 0 AS REQUIRED BY BPXWDYN.
* HOWEVER MANY PARAMETERS ARE PASSED TO THIS STUB ARE PASSED TO
* BPXWDYN WITHOUT ALTERATION.
* RETURNS THE RETURN CODE FROM BPXWDYN TO THE CALLING COBOL PROGRAM
* IN THE FIRST PASSED PARAMETER.
* RETURNS RC = -3 IF BPXWDYN CANNOT BE FOUND
LARL R2,ABPXWDYN LOAD A(BPXWDYN) IF WE HAVE IT
L R15,0(,R2)
LTR R15,R15 DO WE HAVE IT?
JNZ CALLWDYN GO CALL IF WE ALREADY HAVE IT
LARL R0,BPXWDYN LOAD A(NAME OF MODULE TO LOAD)
LOAD EPLOC=(0),ERRET=NOTFOUND
LR R15,R0 SET UP FOR CALL TO BPXWDYN
LA R15,0(,R15) CLEAR HIGH-ORDER BIT
ST R15,0(,R2) SAVE A(BPXWDYN) FOR FUTURE CALLS
J CALLWDYN GO CALL NOW THAT WE HAVE IT
NOTFOUND LHI R15,-3 SIGNAL PROGRAM NOT FOUND
L R1,24(,R13) RELOAD ORIGINAL R1
L R2,0(,R1) GET A(RETURN CODE PARAMETER)
J GOBACK AND EXIT TO CALLER
CALLWDYN DS 0H
L R1,24(,R13) RELOAD ORIGINAL R1
L R2,0(,R1) GET A(RETURN CODE PARAMETER)
LA R1,4(,R1) BYPASS RETURN CODE PARAMETER
LARL R14,SAVEAREA SET UP NEW SAVE AREA FOR BPXWDYN
ST R13,4(,R14) LINK NEW SAVE TO OLD SAVE
ST R14,8(,R13) LINK OLD SAVE TO NEW SAVE
LR R13,R14 SET NEW SAVE AREA FOR BPXWDYN
SR R0,R0 SET R0 = 0 AS REQUIRED BY BPXWDYN
BASR R14,R15 CALL BPXWDYN
L R13,4(,R13) RELOAD A(CALLER SAVE AREA)
GOBACK ST R15,0(,R2) GIVE RETURN CODE TO CALLER
LM R0,R2,20(R13) RESTORE CALLER'S REGISTERS 0 TO 2
SR R15,R15 SET COBOL RETURN-CODE TO ZERO
L R14,12(,R13) RESTORE CALLER'S REGISTER 14
BR R14 RETURN TO CALLER
SAVEAREA DC 18F'0' 18-WORD SAVE AREA
BPXWDYN DC CL8'BPXWDYN '
ABPXWDYN DC A(0)
END

Paul Gilmartin

unread,
May 10, 2013, 11:07:58 PM5/10/13
to
On 2013-05-10, at 14:14, Farley, Peter x23353 wrote:
>
> Note that an extra first parameter (fullword binary) needs to be passed to the assembler module to store the actual BPXWDYN return code. If R15 from BPXWDYN is returned to COBOL directly in R15, COBOL code makes the value positive, which hides the possibly negative return code values that BPXWDYN can produce.
>
It's only trying to help you.

-- gil
0 new messages