Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
Getting information (RECFM/LRECL/BLKSIZE) about a DD

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Tim Van Holder

New User


Joined: 13 Mar 2018
Posts: 2
Location: Belgium

PostPosted: Wed Mar 14, 2018 2:10 pm    Post subject: Getting information (RECFM/LRECL/BLKSIZE) about a DD
Reply with quote

Not strictly COBOL, as I'm using C at the moment (but there's no C-oriented board).

I need to simulate the following file opening behaviour:
  • if no RECFM specified on the DD (or the dataset if it already exists), use VBA
  • otherwise, if it is specified but does not include A, add A (so if the DD has F, the file gets allocated as FA)
  • if no LRECL specified on the DD (or the dataset if it already exists), use 133 for RECFM=F or MIN(BLKSIZE-4,254) for RECFM=V
  • if no BLKSIZE specified on the DD (or the dataset if it already exists), use 1016 for RECFM=V/U, or the highest integral multiple of LRECL that's <= 1016 for RECFM=F


The main issue I'm facing is that the C runtime already does its own defaulting (with different results from the above).
I can specify RECFM/LRECL/BLKSIZE as part of the fopen() call, but then those override whatever the DD has.

So what I am looking for is some function or callable that gets me the information from the DD statement (and, if that's not already integrated, the information from the file if it already exists), so that I can actually tell what is specified or not. Implementing the rules above then becomes trivial.

The closest the C runtime gives me is fldata(), but that operates on an already-opened file, so is too late (the file would already have been allocated with potentially the wrong attributes).

LE doesn't seem to have anything file-related at all.
BPXWDYN apparently allows information retrieval, but seems limited to the dataset names.

Is there something like that? Or would I need to write an assembler program and use particular macros to get at the information?

Thanks in advance.
Back to top
View user's profile Send private message

steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 664
Location: The Universe

PostPosted: Wed Mar 14, 2018 6:35 pm    Post subject:
Reply with quote

I am talking Assembler here.

Before OPEN, you can retrieve DCB attributes specified by a DD statement from the JFCB control block, or you can retrieve DCB attributes specified for a disk data set from the format 1 DSCB for the data set.

During OPEN, the final DCB attributes are assigned in this order:

  1. DCB attributes specified in the DCB macro or by the DCB open exit supplied by the program.
  2. DCB attributes specified by the DD statement.
  3. DCB attributes specified by the data set label; e.g. the format 1 DSCB for a disk data set, or the HDR2 label for an existing tape data set.
The big unknown here is exactly how the fopen C library function assigns DCB attributes. I assume, though from absolutely no knowledge, that it uses the DCB open exit as I did back in the days before system determined BLKSIZE to assign a BLKSIZE similar to SDB.

You can get the data from the DD statement or the format 1 DSCB rather easily. I do not know any Assembler API to retrieve data from tape HDR labels before OPEN.
Back to top
View user's profile Send private message
enrico-sorichetti

Senior Member


Joined: 14 Mar 2007
Posts: 10515
Location: italy

PostPosted: Wed Mar 14, 2018 6:55 pm    Post subject: Reply to: Getting information (RECFM/LRECL/BLKSIZE) about a DD
Reply with quote

You are looking at things from the wrong perspective ...

good it practices dictate that
both for input and output dataset the APPLICATION/PROGRAM documentation will set the rules
and will have to share that info with the other user/providers of the datasets used

changing the characteristics of an allocated file is a bad practice
it will reflect later on the users of that dataset

the program should not be worried about the blksize, IT WILL ALWAYS BE TRANSPARENT
the program reads records, why should it care about the blksize
Back to top
View user's profile Send private message
Tim Van Holder

New User


Joined: 13 Mar 2018
Posts: 2
Location: Belgium

PostPosted: Wed Mar 14, 2018 7:11 pm    Post subject:
Reply with quote

fopen() creates its own DCB, based on what you specify in its arguments.

This is why I need to be able to get the dd/dataset/vtoc/whatever info, so that I can explicitly specify what I should get, only partially ignoring the existing DCB from the DD.

The C runtime does provide access to SVC99, but it looks like its information retrieval mode returns just about every possible piece of information EXCEPT for RECFM/LRECL/BLKSIZE.

So far, it is indeed looking like an assembler routine will be needed to handle it. Unless I can get to the JFCB by following pointers from the TCB; then I could probably stay in C for that part.

An additional behaviour that I think would definitely require assembler code is that the runtime I'm expected to emulate even changes the RECFM of existing files (so if the JCL has a DD for a RECFM=VB file with DISP=MOD, the original application will happily open it and append to it, but after the step is done, the dataset will be cataloged as VBA).
The C runtime won't allow that; if I ask for VBA on a file already cataloged as VB, I get an error.
I'm going to ignore that for now, as it's unlikely any jobs depend on that behaviour.


Note: I agree that this is all not exactly good practice (especially that last part, where it changes the RECFM of a pre-existing dataset). But we have to preserve the behaviour of an existing system. The block size I am the least worried about, as it should indeed be transparent to all use. But the behaviour for RECFM and LRECL I need to get correct (and since LRECL may need to be computed from the block size, I need to be able to at least retrieve that too). Otherwise later steps can an will fail.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Copy records with unknown LRECL oerdgie DFSORT/ICETOOL 8 Tue Jul 24, 2018 7:50 pm
No new posts Utility to list Data Set Information Auryn JCL & VSAM 6 Tue Jul 17, 2018 5:03 pm
No new posts INVALID RECFM FOR DDNAME SYSLIN AND C... sandeep kumar302 All Other Mainframe Topics 7 Fri Apr 27, 2018 6:07 pm
No new posts Get the list of data sets on DASD and... rakaitn JCL & VSAM 4 Thu Mar 08, 2018 12:38 pm
This topic is locked: you cannot edit posts or make replies. how to get Job information from IOF u... rsshanmugam CLIST & REXX 13 Mon Feb 05, 2018 4:22 pm

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us