Loading a VSAM Cluster from V-form file

[rexxhead]

I'm having a hard time loading a variable-length file to a newly-built KSDS. It looks like REPRO is considering the 4-byte RDW as part of the record. As soon as it encounters a record shorter than the one before, it blows up with an I/O error (IDC3351I rc=108).

I've tried offsetting the key by 4 but that didn't work. I'm beginning to think it's not possible to load a cluster from a V-form dataset, and that strikes me as 'improbable'. What am I not seeing?

Frank Clarke
--America's source for adverse opinions since 1943.

 

[papadba]

Yup, IDCAMS sees the whole record.

Are all of the records the same length even though the sequential file has an RDW and is "VB"?

Preprodcessing (with the system Sort product) the file and removing the RDW should get around the problem with REPRO.

 

[rexxhead]

The records are different lengths, although they fall into 'families': there are x-length records and y-length records, but no z-length records.

If I convert the data to fixed-length records of the maximum necessary length, the REPRO works fine.

Isn't it odd that a V-form record would cause a problem?



Frank Clarke
--America's source for adverse opinions since 1943.

 

[papadba]

First - i'd like to be sure i understand our terminology. In this dialog, does V-form mean the same thing as RECFM=VB or RECFM=V. If not V-form is not a term with which i'm familiar.

If you have access to tso/ispf, please go to 3.4 and bring up the Info about the dataset - then copy that info into a reply.

Many of our systems use repro to load variable data into vsam files.

 

[rexxhead]

The DCB is RECFM=VB,LRECL=4096. If I convert it to RECFM=FB,LRECL=4096, REPRO does not object even though RECSIZE is specified as (256,4096) in the DEFINE. If I leave it as VB, REPRO loads one record, then barfs. I suspect IDCAMS is seeing the 4-byte length indicator as 'data' and objecting to loading a record out of sequence (because the 2nd record is shorter). I further suspect that if every one of those variable-length records were forced to be the same length (as by inserting a character into position 3500, say), the file would load correctly.

Frank Clarke
--America's source for adverse opinions since 1943.

 

[papadba]

How was the file created? If you view the file in tso/ispf, is the RDW visable or is the "first" byte shown the first part of the actual data?

What happens if the load is done using the system sort rather than REPRO?

 

[rexxhead]

In ISPF EDIT/VIEW, the RDW is not visible.

I haven't tried SORT, but I'm going there right now.

Frank Clarke
--America's source for adverse opinions since 1943.

 

[rexxhead]

[tt]SYSIN :
SORT FIELDS(5,50,CH,A)
WER276B SYSDIAG= 6579872, 11333652, 11333652, 10539900
WER164B 24,604K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 0 BYTES RESERVE REQUESTED, 24,556K BYTES USED
WER146B 20K BYTES OF EMERGENCY SPACE ALLOCATED
WER108I SORTIN : RECFM=VB ; LRECL= 4096; BLKSIZE= 27998
WER110I SORTOUT : RECFM=V ; LRECL= 4096; CISIZE = 18432
WER410B 23,576K BYTES OF VIRTUAL STORAGE AVAILABLE ABOVE THE 16MEG LINE,
WER410B 0 BYTES RESERVE REQUESTED, 23,576K BYTES USED
WER036B G=575
WER147I CONTROL FIELD GT REC LEN, POSSIBLE OUT OF SEQ REC
WER177I TURNAROUND SORT PERFORMED
WER255A VSAM LOGICAL ERROR 6C ON OUTPUT
WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000[/tt]

Frank Clarke
--America's source for adverse opinions since 1943.

 

[papadba]

Here is a write-up about the 6C return code:
X'6C 108
Return Code=04 Action=OPEN
The system timestamps of the data of a file and its index do not match; this indicates that either the data of the index has been undated separately and that data integrity problems may result if the file is processed now. PROGRAMMER ACTION: If data integrity problem arise, revert to a valid backup copy of the file. Return Code=08 Action=Request
The RECLEN value specified in the RPL was one of the following: - Larger than the allowed maximum. - Equal to zero. - Smaller than to record (slot) size specified for a relative-record file. For alternate index upgrade processing, the alternate index contains too many duplicate keys. Increase the maximum record length to accommodate more keys.

Before trying to load the data, was the vsam delete/defined? Also, if the data is in key sequence, the SORT statement can be changed to SORT FIELDS=COPY.

Has the file ever been successfully loaded and read?

 

[rexxhead]

Problem solved.

KEYS( 50 , 0 )
but when the file is created (by reformatting an input file) one of the input records is empty except for a dataset name, so the key field winds up with a short DSN and nothing else, and the remainder of the record is empty. EXECIO sets the RDW to something less than 50 and when IDCAMS tries to write it ... BOOM!

The reformatter has been altered to force-fill one field in the body of the record and the file now loads perfectly.

(grumble)

Frank Clarke
--America's source for adverse opinions since 1943.

 

[papadba]

Good to hear it is working! Thanks for posting the resolution