|
View previous topic :: View next topic
|
| Author |
Message |
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
Hi All,
Say, I have the following file being used in one COBOL program -
| Code: |
| //DD1 DSN=ABCD.EFGH.XYZ,DISP=SHR |
I need to write a piece of code in COBOL which will fetch the value 'ABCD.EFGH.XYZ' for me. I think there is a utility called GOADYN00 which can be used but, I am not sure (and if it is installation-specific).
Please help me out with this.
Regards,
Sumesh |
|
| Back to top |
|
 |
superk
Global Moderator
Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA
|
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| This has been discussed a number of times. Search the forum. |
|
| Back to top |
|
|
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
Hi All,
Thanks for the replies. I tried implementing this as a sub-routine. However, the results are garbled as shown below -
JCL:
| Code: |
//GETFNAME JOB 00124,'GETFNAME',CLASS=4,
// MSGCLASS=Z,REGION=128M,NOTIFY=&SYSUID
//JOBLIB DD DISP=SHR,DSN=S00P.CHGMAND.IPHP.#XXXXXX.LDB
//STEP01 EXEC PGM=GETFNAME
//INFILE DD DISP=SHR,DSN=XXXX.XXXX.XXXX.XXXXXXXX.XXXX.G0279V00
//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSABEND DD SYSOUT=* |
The program output is displayed as -
| Code: |
CALL FILENAME ROUTINE
DDNAME : JOBLIB
DSN : :n::
DDNAME : INFILE
DSN : :: Ø ·´:e: Ø
DDNAME : SYSOUT
DSN : ¡:: Ø :n:::: Ø :n:ü::
DDNAME : SYSUDUMP
DSN : :: Ø
DDNAME : SYSABEND
DSN : ::: Ø ::¢Q:: Ø :n: Ø |
I am not passing any data to the subroutine (just passing an 100 array with DD and DS so that the subroutine doesn't abend with S0C4).
It seems like the DD name is getting picked up correctly as can be seen from the display. However, the DS name is garbled. TIOT Experts!!!!Please help me out here. 
Regards,
Sumesh |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| The TIOT points to the JFCB which contains the datasetname. |
|
| Back to top |
|
|
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
Hi All,
I'm listing out my relevant divisions/sections below -
| Code: |
WORKING-STORAGE SECTION.
01 TCB-ADDRESS-POINTER.
05 TCB-ADDR-POINTER USAGE IS POINTER.
01 TIOT-SEG-POINT.
05 TIOT-SEG-POINTER USAGE IS POINTER.
05 TIOT-SEG-PNT REDEFINES TIOT-SEG-POINTER
PIC S9(9) COMP.
01 JFCB-POINT.
05 JFCB-POINTER USAGE IS POINTER.
05 JFCB-POINT-RED REDEFINES JFCB-POINTER.
10 FILLER PIC X.
10 JFCB-LOW-3 PIC X(3). |
| Code: |
LINKAGE SECTION.
01 DDNAME-DSN-ARRAY.
05 DDNAME-DSN OCCURS 100 TIMES INDEXED BY NDX1.
10 DDA-DDNAME PIC X(8).
10 DDA-DSN PIC X(44).
01 TCB-POINTER USAGE IS POINTER.
01 TCB.
05 FILLER PIC X(12).
05 TIOT-POINTER USAGE IS POINTER.
01 TIOT-START PIC X(24).
01 TIOT-SEG.
05 TIO-LEN PIC X.
05 FILLER PIC X(3).
05 DD-NAME PIC X(8).
05 JFCB-ADDR PIC X(3).
01 JFCB.
05 FILLER PIC X(16).
05 DS-NAME PIC X(44). |
| Code: |
PROCEDURE DIVISION USING DDNAME-DSN-ARRAY.
MOVE LOW-VALUES TO JFCB-POINT.
MOVE X'0000021C' TO TCB-ADDRESS-POINTER.
SET ADDRESS OF TCB-POINTER TO TCB-ADDR-POINTER.
SET ADDRESS OF TCB TO TCB-POINTER.
SET ADDRESS OF TIOT-START TO TIOT-POINTER.
SET TIOT-SEG-POINTER TO TIOT-POINTER.
ADD 24 TO TIOT-SEG-PNT.
SET ADDRESS OF TIOT-SEG TO TIOT-SEG-POINTER.
SET NDX1 TO 1.
PERFORM UNTIL TIO-LEN = LOW-VALUES OR NDX1 > 100
MOVE DD-NAME TO DDA-DDNAME(NDX1)
MOVE JFCB-ADDR TO JFCB-LOW-3
SET ADDRESS OF JFCB TO JFCB-POINTER
MOVE DS-NAME TO DDA-DSN(NDX1)
DISPLAY 'DDNAME : ' DDA-DDNAME(NDX1)
DISPLAY ' DSN : ' DDA-DSN(NDX1)
ADD 20 TO TIOT-SEG-PNT
SET ADDRESS OF TIOT-SEG TO TIOT-SEG-POINTER
SET NDX1 UP BY 1
END-PERFORM.
GOBACK. |
Could you please check the place where the JFCB is getting populated and let me know if there is anything going wrong?.
Regards,
Sumesh |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
An aside: If your compiler supports COMP-5 then define your COMP variables as such. Otherwise, ensure you're using the TRUNC(BIN) compiler option, to avoid truncation.
TRUNC(BIN) has no effect on COMP-5.
Add a second index to the ARRAY and name it NDX1-MAX and compute its value. You can use TALLY as a work-area without concern -
| Code: |
DIVIDE LENGTH OF DDNAME-DSN-ARRAY BY LENGTH OF DDNAME-DSN (1) GIVING TALLY.
SET NDX1-MAX TO TALLY. |
Then, substitute the > 100 with > NDX1-MAX.
Bill |
|
| Back to top |
|
|
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
Hi Bill,
Thanks a lot for your idea. Could you please elaborate on how this will help?.
I think what you are trying to do here is to get the number of elements in the array. How will this help compared to a >100 comparision.
Regards,
Sumesh |
|
| Back to top |
|
|
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
I tried the TRUNC(BIN) option but, it yielded the same result -
| Code: |
CALL FILENAME ROUTINE
DDNAME : JOBLIB
DSN : ::²
DDNAME : INFILE
DSN : ::: Ø :èq::e: Ø
DDNAME : SYSOUT
DSN : ¡:è: Ø :R:È ::
DDNAME : SYSUDUMP
DSN : :: Ø
DDNAME : SYSABEND
DSN : ::: Ø ::¢Q:: Ø :n: Ø |
There is probably some issue while populating JFCB as opposed to TIOT since the DD name is getting displayed properly. Since I have absolutely no idea about the structure/organization of JFCB/TIOT, I have to rely on this code which I got online.
Any material explaining the concepts are not to be found online. Would appreciate if someone had stuff related to these.
Also, please have a look at the piece of code and suggest.
Thanks a lot,
Sumesh |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
I googled on "tiot in cobol" and found at least 2 sources to handle
your case.
All control block layouts are found in the Data Areas IBM manuals. |
|
| Back to top |
|
|
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
Hi Peter,
The code that you see is from one of those forums. As suggested by Bill, I also tried -
| Code: |
DIVIDE LENGTH OF DDNAME-DSN-ARRAY
BY LENGTH OF DDNAME-DSN(1)
GIVING TALLY.
SET NDX1-MAX TO TALLY. |
and
| Code: |
| PERFORM UNTIL TIO-LEN = LOW-VALUES OR NDX1 > NDX1-MAX |
It doesn't seem to work still. I searched for manuals that explain the structures TIOT and JFCB. All I can find are codes related to them, one among which, I have used.
I am not even sure if the structures defined in my program are correct. They seem to be correct for the DD part though .
Regards,
Sumesh |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
| Back to top |
|
|
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
Hi Peter,
Thanks a lot for this information. Let me start working on modifying the code. Will update this section once I get the expected results.
Once again, thanks to all!!!!
Regards,
Sumesh |
|
| Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008
Posts: 400
Location: Mumbai
|
|
|
|
| I haven't reviewed Peter's links, but your problem is most likely that the control blocks you need are moved above the 16MB line so the JFCB-ADDR is not an address. It is a 3 byte token that you need to convert to a 4 byte address. In assembler this is done with the SWAREQ macro. There are examples of simulating SWAREQ in COBOL around. Use Google. I know there are rexx examples (and I have converted them to COBOL in the past so I know it can be done). The original source for the simulation code is the MVS Diagnosis manual, if you want to just go to that for info. Actually, I think I used that as a source instead of the rexx samples around, but either way, it is possible. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
You could in assembler also use the RDJFCB macro to get the jfcb for
the ddname you want info about. |
|
| Back to top |
|
|
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
Hi All,
Got it!!!!!!!!!!!!!!!!! FINALLY!!!!!!!!!!
MBabu, you were right. We need to compute the address above the 16 MEG line using the 3 byte placeholder that once used to address DSN names. Did a search for the same and came upon a cool routine written in pure COBOL. I am presenting it below for reference. It does the same thing the old code used to do, only change being that there is a call to SAWREQ to compute the actual address where the DSN information is stored -
| Code: |
IDENTIFICATION DIVISION.
PROGRAM-ID. FILENAME.
INSTALLATION.
AUTHOR. XYZ.
DATE-WRITTEN. 03/19/2010.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
01 WS-TCB-ADDRESS-POINTER.
05 WS-TCB-ADDR-POINTER USAGE IS POINTER.
01 WS-TIOT-SEG-POINT.
05 WS-TIOT-SEG-POINTER USAGE IS POINTER.
05 WS-TIOT-SEG-PNT REDEFINES WS-TIOT-SEG-POINTER
PIC S9(9) COMP.
01 WS-POINT.
05 WS-POINTER USAGE IS POINTER.
05 WS-PTR REDEFINES WS-POINTER
PIC S9(9) COMP.
05 WS-POINT-RED REDEFINES WS-PTR.
07 FILLER PIC X.
07 WS-LOW-3 PIC X(3).
01 WS-JFCB-POINT.
05 WS-JFCB-POINTER USAGE IS POINTER.
05 WS-JFCB-PTR REDEFINES WS-JFCB-POINTER
PIC S9(9) COMP.
05 WS-JFCB-POINT-RED REDEFINES WS-JFCB-PTR.
07 FILLER PIC X.
07 WS-JFCB-LOW-3 PIC X(3).
01 WS-SWA-POINT.
05 WS-SWA-POINTER USAGE IS POINTER.
05 WS-SWA-PTR REDEFINES WS-SWA-POINTER
PIC S9(9) COMP.
05 WS-SWA-POINT-RED REDEFINES WS-SWA-PTR.
07 FILLER PIC X.
07 WS-SWA-LOW-3 PIC X(3).
01 WS-LEN PIC S9(4) COMP.
01 WS-LENGTH REDEFINES WS-LEN PIC X(02).
01 WS-WORK PIC S9(9) COMP.
01 WS-RIGHT-HEX-DIGIT PIC S9(4) COMP.
01 WS-QMAT-POINT.
05 WS-QMAT-POINTER USAGE IS POINTER.
05 WS-QMAT-PTR REDEFINES WS-QMAT-POINTER
PIC S9(9) COMP.
LINKAGE SECTION.
01 TCB-POINTER USAGE IS POINTER.
01 TCB.
05 FILLER PIC X(08).
05 DEB-ADDR USAGE IS POINTER.
05 TIOT-POINTER USAGE IS POINTER.
05 FILLER PIC X(164).
05 JSCB-POINTER USAGE IS POINTER.
05 FILLER PIC X(128).
05 STCB-POINTER USAGE IS POINTER.
01 TIOT.
05 JOB-NAME PIC X(08).
05 JOB-PROC PIC X(08).
05 JOB-STEP PIC X(08).
01 TIOT-SEG.
05 TIO-LEN PIC X.
05 FILLER PIC X(03).
05 DD-NAME PIC X(08).
05 SWA-V-ADDR PIC X(03).
05 FILLER PIC X(02).
05 UCB-ADDR PIC X(03).
01 JFCB.
05 DS-NAME PIC X(44).
05 FILLER PIC X(74).
05 VOL-SER PIC X(06).
01 JSCB.
05 FILLER PIC X(244).
05 QMPL-POINTER USAGE IS POINTER.
01 QMPL.
05 FILLER PIC X(24).
05 QMAT-POINTER USAGE IS POINTER.
01 QMAT.
05 FILLER PIC X(12).
05 QMAT-NEXT-POINTER USAGE IS POINTER.
01 SWA.
05 JFCB-ADDR USAGE IS POINTER.
PROCEDURE DIVISION.
MOVE X'0000021C' TO WS-TCB-ADDRESS-POINTER.
SET ADDRESS OF TCB-POINTER TO WS-TCB-ADDR-POINTER.
SET ADDRESS OF TCB TO TCB-POINTER.
SET ADDRESS OF TIOT TO TIOT-POINTER.
SET WS-TIOT-SEG-POINTER TO TIOT-POINTER.
ADD 24 TO WS-TIOT-SEG-PNT.
SET ADDRESS OF TIOT-SEG TO WS-TIOT-SEG-POINTER.
PERFORM UNTIL TIO-LEN = LOW-VALUES
MOVE ALL LOW-VALUES TO WS-POINT
MOVE ALL LOW-VALUES TO WS-JFCB-POINT
MOVE ALL LOW-VALUES TO WS-SWA-POINT
MOVE SWA-V-ADDR TO WS-SWA-LOW-3
PERFORM SWAREQ
SET ADDRESS OF JFCB TO WS-POINTER
DISPLAY 'DDNAME=' DD-NAME
DISPLAY 'DSNAME=' DS-NAME
DISPLAY 'VOL=SER=' VOL-SER
DISPLAY '********************************************'
MOVE ZERO TO WS-LEN
MOVE TIO-LEN TO WS-LENGTH(2:1)
ADD WS-LEN TO WS-TIOT-SEG-PNT
SET ADDRESS OF TIOT-SEG TO WS-TIOT-SEG-POINTER
END-PERFORM.
GOBACK.
SWAREQ.
DIVIDE WS-SWA-PTR BY 16
GIVING WS-WORK
REMAINDER WS-RIGHT-HEX-DIGIT.
IF WS-RIGHT-HEX-DIGIT NOT = 15
COMPUTE WS-PTR = WS-SWA-PTR + 16
ELSE
MOVE X'0000021C' TO WS-TCB-ADDRESS-POINTER
SET ADDRESS OF TCB-POINTER TO WS-TCB-ADDR-POINTER
SET ADDRESS OF TCB TO TCB-POINTER
SET ADDRESS OF JSCB TO JSCB-POINTER
SET ADDRESS OF QMPL TO QMPL-POINTER
SET ADDRESS OF QMAT TO QMAT-POINTER
SET WS-QMAT-POINTER TO QMAT-POINTER
PERFORM UNTIL WS-SWA-PTR <= 65536
SET WS-QMAT-POINTER TO QMAT-NEXT-POINTER
SET ADDRESS OF QMAT TO QMAT-NEXT-POINTER
COMPUTE WS-SWA-PTR = WS-SWA-PTR - 65536
END-PERFORM
COMPUTE WS-PTR = WS-SWA-PTR + WS-QMAT-PTR + 1
SET ADDRESS OF SWA TO WS-POINTER
SET WS-POINTER TO JFCB-ADDR
COMPUTE WS-PTR = WS-PTR + 16
END-IF. |
I did get the correct DSN names with the modifications above. However, I will not be presenting the names since those are client-sepcific.
A BIG THANKS TO ALL WHO MADE THIS HAPPEN!!!!!!
I will be back with more questions....Have a good time, yall!!!!
Regards,
Sumesh |
|
| Back to top |
|
|
dcshnier
New User
Joined: 28 Dec 2006
Posts: 27
Location: Baltimore, MD 21215
|
|
|
|
cybertaurean/Sumash (and anyone else familar with JFCB retrieval from a COBOL program)
This question will take you back to 2010 when you (with the help of others) logged the solution to getting the JFCB information in COBOL, with the help of the 'SWAREQ' macro simulation.
First and for most, thanks greatly for your efforts to nail this one down.
I used that solution with the called COBOL module that I have developed to return information from the JFCB.
I am getting the correct values returned for the dataset name (pos. 1-44), PDS member name (positions 45-52) , the catalog indicator (pos 53) file and creation date (pos. 81-83). But I am getting all low-values (X'00') for some of the other attribute fields such as dataset organization (position 99) and record-format (position 101).
I am wondering if you or others have an explanation as to why certain values are just not there.
I return the entire 176 byte JFCB to my calling process, and I even write it to a 176 byte output file to help me debug this anomaly. For my guide, I am using the JFCB map provided in the IBM "Z/OS MVS Data Areas Volume 4" manual (IBM number: GA32-0856-02). I realize that the missing JFCB fields that I have mentioned above (dataset organization and record format) are in a 'COBOL unfriendly' hexadecimal representations of a bit-mask. That is a separate problem that I will have to deal with. But at least, I expect there to be some values (albeit unfriendly) in those positions.
Is it possible that my method of rendering the JFCB information - with the assistance of the SWAREC macro simulation is 'slightly' flawed and that would be causing the missing values? I thought that to be unlikely given that much of the returned JFCB information is present and accurate. Perhaps more likely is the possibility that certain dataset and/or environment specifics affect the JFCB's ability to store all of the information that is presented in the IBM manual?
Any theories ?
thanks
dcshnier |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Have you checked that your z/OS release is that for the manual you are checking to?
Might be worth assembling the macro itself, with the listing produced, so you can check what you actually have.
Have you tried with datasets with different characteristics anyway?
If you access the control blocks through Cobol, you leave yourself open to system changes. If you use Assembler, IBM will change the macros when a control block changes. |
|
| Back to top |
|
|
|
|
