MVSFORUMS.com

misi01

We already use this program in various COBOL programs to allocate and free datasets dynamically.

Reading the manuals here https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/bpx1rx81.htm I get the impression that a COBOL program can use BPXWDYN to get the dataset name allocated to a DD-name.

Does anyone have an example of the calling parms needed ? (The manual is a bit confusing since it talks a lot about accessing the program from Rexx, but not Cobol). The following is what I've tried

William Collins · Supermod Joined: 03 Jun 2012 Posts: 437 Topics: 0

That's a dynamic CALL, and 05 aa-inrtdsn pic x(44). is only known to anything, the compiler, at compile time.

So that's not going to work. It won't work with a static CALL either, since the COBOL compiler is entirely unaware of what any CALLed program does, and takes no differentiating action on them at all.

kolusu · Posted: Tue Sep 22, 2015 10:14 am Post subject: Re: BPXWDYN

allmonr · Beginner Joined: 22 Jun 2017 Posts: 2 Topics: 0

This BPXWDYN program in fact does support function INFO and does return data when called from REXX. We are trying to get this to work in Enterprise COBOL. Does anyone know how to code the parameter area in COBOL to make this utility work for COBOL ?

kolusu · Posted: Tue Jun 27, 2017 11:27 am Post subject:

allmonr,

what kind of info are you trying to fetch from BPXWDYN. Can you post your REXX code?
_________________
Kolusu
www.linkedin.com/in/kolusu

allmonr · Beginner Joined: 22 Jun 2017 Posts: 2 Topics: 0

Sure. But I need to do this in COBOL.

kolusu · Posted: Tue Jun 27, 2017 5:11 pm Post subject:

allmonr,

You need to zero out R0 for the INFO call to work with BPXWDYN and COBOL does not have the mechanism of zeroing out the registers. In REXX R0 points to the REXX environment. You need an Assembler stub to zero out the R0 before you invoke the BPXWDYN within COBOL.
_________________
Kolusu
www.linkedin.com/in/kolusu

kolusu · Posted: Fri Jun 29, 2018 1:19 pm Post subject:

misi01,

It seems that BPXWDYN is enhanced to provide an alternate entry point, BPXWDY2, that:
(1) Preserves the invoker program mask, and
(2) Better facilitates invocation by a high-level language call by clearing register 0 as required by the BPXWDYN interface.

https://www-01.ibm.com/support/docview.wss?rs=63&uid=isg1OA51807

So here is a COBOL program that will get the INFO for an existing dataset.

misi01 · Posted: Sat Jun 30, 2018 1:02 am Post subject:

Excellent, thanks Kolusu
_________________
Michael

bauer · Posted: Tue Jul 03, 2018 6:13 am Post subject:

Dear all,

very interesting topic. Several years ago I had a similar problem (find out dataset information for datsets which are allocated by dd namens per JCL).

Here is my PL/1 solution. Perhaps it might help anybody who reads this post, or give a first impression how to retrieve information from the mvs (z/OS) system control blocks.

The first pointer for documentation is this IBM Manual: MVS Data Areas,
Volume 1 (ABEP - DAIT), GA22-7581-01 and the volumes 2,3,4,5.

kolusu · Posted: Tue Jul 03, 2018 9:12 am Post subject:

bauer,

Thanks for sharing the PL/1 code. Much appreciated.
_________________
Kolusu
www.linkedin.com/in/kolusu

misi01 · Posted: Wed Oct 24, 2018 6:22 am Post subject:

Thanks for the code Kolusu. It solved the following problem we had here.

We have a batch program that allocates a number of private DL/1 databases. Trouble is, there's no guarantee that the actual databases exist (privately), so to avoid a JCL error, we allocate them as DUMMY.
All well and good, until the program attempts to read them and fails with a return code AI. Now, theoretically we could simply analyze that return code and process it as if it were a GE.

Instead, I ran your code above using 2 databases, the first one existed, the second one was allocated a DUMMY. Here are the surprising (?) results.