Thread View: bit.listserv.tsorexx
10 messages
10 total messages
Started by Harold Mains
Tue, 07 May 2013 21:32
LISTDSI for tape datasets
Author: Harold Mains
Date: Tue, 07 May 2013 21:32
Date: Tue, 07 May 2013 21:32
19 lines
1968 bytes
1968 bytes
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 LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: LISTDSI for tape datasets
Author: Paul Gilmartin
Date: Tue, 07 May 2013 21:39
Date: Tue, 07 May 2013 21:39
20 lines
2353 bytes
2353 bytes
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 ---------------------------------------------------------------------- For TSO-REXX subscribe / signoff / archive access instructions, send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: LISTDSI for tape datasets
Author: Harold Mains
Date: Tue, 07 May 2013 22:56
Date: Tue, 07 May 2013 22:56
40 lines
3336 bytes
3336 bytes
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 -----Original Message----- From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, May 07, 2013 2:39 PM To: TSO-REXX@VM.MARIST.EDU Subject: Re: [TSO-REXX] LISTDSI for tape datasets 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 ---------------------------------------------------------------------- For TSO-REXX subscribe / signoff / archive access instructions, send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX ---------------------------------------------------------------------- For TSO-REXX subscribe / signoff / archive access instructions, send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: LISTDSI for tape datasets
Author: Paul Gilmartin
Date: Tue, 07 May 2013 23:55
Date: Tue, 07 May 2013 23:55
17 lines
2461 bytes
2461 bytes
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
-- gil
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: LISTDSI for tape datasets
Author: Harold Mains
Date: Wed, 08 May 2013 00:24
Date: Wed, 08 May 2013 00:24
34 lines
2891 bytes
2891 bytes
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:PaulGBoulder@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
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
-- gil
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: LISTDSI for tape datasets
Author: Harold Mains
Date: Fri, 10 May 2013 00:14
Date: Fri, 10 May 2013 00:14
35 lines
3409 bytes
3409 bytes
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:PaulGBoulder@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
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
-- gil
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: LISTDSI for tape datasets
Author: Bill Schoen
Date: Fri, 10 May 2013 01:44
Date: Fri, 10 May 2013 01:44
50 lines
4010 bytes
4010 bytes
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
On 5/9/2013 8:13 PM, Harold Mains wrote:
> 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:PaulGBoulder@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
>
> 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
>
> -- gil
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
>
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: LISTDSI for tape datasets
Author: Farley, Peter x23353
Date: Fri, 10 May 2013 16:30
Date: Fri, 10 May 2013 16:30
26 lines
3470 bytes
3470 bytes
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-REXX@vm.marist.edu] On Behalf Of Bill Schoen Sent: Thursday, May 09, 2013 9:45 PM To: TSO-REXX@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. ---------------------------------------------------------------------- For TSO-REXX subscribe / signoff / archive access instructions, send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: LISTDSI for tape datasets
Author: Farley, Peter x23353
Date: Fri, 10 May 2013 20:14
Date: Fri, 10 May 2013 20:14
174 lines
13547 bytes
13547 bytes
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
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-REXX@vm.marist.edu] On Behalf Of Farley, Peter x23353
Sent: Friday, May 10, 2013 12:30 PM
To: TSO-REXX@vm.marist.edu
Subject: Re: LISTDSI for tape datasets
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-REXX@vm.marist.edu] On Behalf Of Bill Schoen
Sent: Thursday, May 09, 2013 9:45 PM
To: TSO-REXX@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.
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Re: LISTDSI for tape datasets
Author: Paul Gilmartin
Date: Sat, 11 May 2013 03:07
Date: Sat, 11 May 2013 03:07
11 lines
2534 bytes
2534 bytes
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 ---------------------------------------------------------------------- For TSO-REXX subscribe / signoff / archive access instructions, send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads