How can I increase the length of variable-length record beyond 32760?

Question

The maximum record-length for variable-length QSAM records is 32,760 bytes.

The current record-length of our file is OK for us, but in order to tackle some more info we have to expand this file which will have it's length beyond 32K (LRECL > 32760).

Splitting the record is not good option for us as it will impact our existing system.

I'm not sure whether using SPANNED records with VSAM here will solve this problem.

//DEFINE EXEC PGM=IDCAMS
//SYSPRINT  DD SYSOUT=A
//SYSIN     DD *

  DEFINE CLUSTER (NAME(dsname.K1719) INDEXED VOLUMES(xxxxxx) -
         TRACKS(1) KEYS(17 19) RECORDSIZE(40 110) SPANNED) -
         DATA (NAME(dsname.K1719.DATA)) INDEX (NAME(dsname.K1719.INDEX))
/*
//

Will this will solve our problem?

Answer 1

If you use Unix System Services files, you are not subject to the 32K limitation on LRECL. There are downstream effects.

• If you are using COBOL to process the file you can use LINE SEQUENTIAL in the ORGANIZATION clause, but then you are limited to 1M LRECL.
• If you are using COBOL to process the file you can eschew COBOL I/O
  and use C fopen() and so forth to get around the 1M LRECL limitation mentioned above, but then you are adding something a bit foreign to an admittedly hypothetical COBOL application. C would have no trouble with such files, I cannot speak to PL/I.
• Not all DFSMS and third-party utilities are completely conscious of Unix System Services files.
• JCL constructs for Unix System Services files have a relatively short learning curve, but there is a bit of learning required.
• Security for Unix System Services files may be off-putting to your Security Administrator(s). You may find yourselves having to set up Access Control Lists via setfacl and other new concepts.

Answer 2

@cschneid answer is interesting.

With out knowing more about the file / application it is difficult to give specific answers. Following are idea's that may be useful.

You could:

• break the copybook up into several sub records
• add an extra byte to the key

so instead of having

<key><a record>

you would have

<key><sub-key-1><part-1-of-record>
<key><sub-key-2><part-2-of-record>
<key><sub-key-3><part-3-of-record>
 ...

---

If you have a single File-Driver program that interacts with the file, you can hide the details of how the data is stored from your application. So you can have multiple physical records for each logical record and your application does nod need to know about it. You can also have multiple files if you need to as well

Remember you can add space at the end of the new copybook that does not need to be stored in the file. This comes in handy when you need to add fields to the file - can save recompiling lots of programs

---

Does the file hold logically different data (say sales and orders etc), does every program that accesses the file use the whole record ???

If so, you could add a request-type to the call of the File-Driver-Program:

   Call "FilePgm" using GET-ORDER  Order-Copybook
or 
   Call "FilePgm" using GET-SALES  Sales-Copybook 
or
   Call "FilePgm" using GET-EVERYTHING  Everything-Copybook 

The advantage in having multiple call types/copybooks is if the Order-Copybook changes, programs only using the Sales-Copybook do not need to be recompiled and vice versa. This will make changing the file easier in the future.

---

Finally there is Database Option !!!, either a

• a full rewrite

• or the use of binary-blobs. These have a limit of 2gb on binary blobs

  With DB2 you can use Compression which can be useful. Large record often have high compression ratio's. The advantage with compression is not the space savings but reduced IO.