How to identify a VSAM file is FB or VB??

Arunkumar Chandrasekaran · New User Joined: 01 Jun 2010 Posts: 63 Location: India

Hi,

Could anyone please tell how to identify if a VSAM file is FB or VB??

I tried using 'I' and 'S' in ISPF 3.4. But couldn't get the detail. It may be simple but I'm not aware of this. I know RECORDSIZE parameter used when creating VSAM. Once created how to find the same??

I use INSYNC utility to browse on VSAM file.

Thanks,
Arun

expat · Posted: Thu Nov 13, 2014 9:37 pm

LISTCAT

Bill O'Boyle · Posted: Thu Nov 13, 2014 10:03 pm

In the LISTCAT, if keyword RECORDSIZE specifies two different values, such as (256,1024) then the file should be considered variable.

If the file is used in CICS, the FCT entry can specify FIXED or VARIABLE.

HTH....

Terry Heinze · Posted: Fri Nov 14, 2014 12:10 am

I was under the impression that VSAM considers ALL files as V length records even when the average and maximum RECORDSIZEs are the same.

Bill O'Boyle · Posted: Fri Nov 14, 2014 3:06 am

Yup, you're correct, Terry....

Arunkumar Chandrasekaran · New User Joined: 01 Jun 2010 Posts: 63 Location: India

Hi Bill,

Can you please explain me or give me reference for the the below.

Bill Woodger · Posted: Fri Nov 14, 2014 1:14 pm

VSAM does one thing internally, but which doesn't apply to the outside world.

In a COBOL program, you don't have variable-length records because the two lengths on the RECORDSIZE are the same. As Mr Bill has pointed out, CICS likes to know. As you have pointed out DFSORT likes to know.

DFSORT documents well how it decides whether to treat VSAM data as fixed-length or variable-length. If that turns up "wrong" for what you want, or just for clarity, you can tell DEFSORT whether to treat any VSAM file as "fixed" or "variable". If your choice is actually illogical for the file, you'll get truncation or padding.

Externally VSAM files can be considered either as "fixed" or "variable" in the manner originally described (do a LISTCAT, look at the RECORDSIZE).

Internally, for instance, VSAM data does not have an "RDW". Yet the records on a particular file could all be different sizes. The DFSORT documentation is a good starting point if you are keen, if you want to get deeper you'll be heading for the VSAM documentation, have a start with the Redbook VSAM Demystified.

Arunkumar Chandrasekaran · New User Joined: 01 Jun 2010 Posts: 63 Location: India

Thanks for the explanation Bill.

Meanwhile i gone thru one of my old work where I used a VSAM file in SORT step.

When I do LISTCAT the VSAM file I get the below.

Bill Woodger · Posted: Fri Nov 14, 2014 8:46 pm

You need to look at the sysout for the step.

You need to look at the RECORD statement in Chapter 3 of the DFSORT Application Programming Guide. This will make clear what is happening, and what to do if you want to change that.

Arunkumar Chandrasekaran · New User Joined: 01 Jun 2010 Posts: 63 Location: India

Hi,
Thanks for all your inputs.From your post and reference this is my understanding.

(1) There is no RDW in any VSAM file.So,actually (internally) in all VSAM files data bytes start from position 1.

(2)Every record's length is stored in RDF.This can be same or different for all records.If it is same we (outside world) call it as FB (VSAM with Fixed length records) otherwise we call is as VB (VSAM with variable length records)

(3)But RRDS VSAM file always with fixed length records (FB).

(4) While processing a VSAM file as input we should mention TYPE parameter to tell DFSORT if the VSAM file needs processing like Fixed lenght records or variable lenght records.

(5) If we didnt specify DFSORT try to get the TYPE from different details (SORTOUT RECFM,OUTFIL RECFM,VTOF FTOF VFILL).Finally if DFSORT cant identity the TYPE by any means it assumes as FB and do processing as FB.

(6) If we specified or DFSORT identified as the is VB we should give proper control cards(+4).

But in my previous work mentioned above,

(1) I didn't mention the input VSAM TYPE as VB to DFSORT.Also DFSORT cant assume it as VB since OUTPUT and other input files are FB.(QSAM)

(2) Also I didn't add +4 in my control card.So, fixed record processing worked fine.

But I believe since I used only the fields within first 20 bytes for my processing it is working perfectly.If I would have used any truncated field in
short record for DFSORT processing it will be padded or truncated.Luckily I escaped.

Hope all my understandings are good.