VSAM ERROR CODE 44

[MIKELEIBO]

While not exactly a COBOL question, problem is occuring in a COBOL program...

According to everywhere I search, a code 44 means a VSAM rewrite where the length was changed or a write of a record that isn't within the specified file sizes, (too short/too long).

However, the problem is occuring on a write to a VSAM file with two alternate keys defined unique where the record has a fixed length, (in the COBOL FD).

I'm guessing the problem is actually a duplicate key on the 2nd alternate key - has anyone experienced this problem? If my guess is incorrect, what could cause the problem?

Thanks, Mike

 

[Dimandja]

A couple of questions:

1. Can you show your SELECT and FD statements?

2. Has this IO ever worked before? Is this a new program (first run)?

3. Why do you think the problem is "a duplicate key on the 2nd alternate key"?

 

[MIKELEIBO]

thanks for asking... and helping...
3. Because I am guessing and the 44 makes no sense for
other reasons.
1. It is a program that has worked without change for a
long time...
2. SELECT ACCOUNT-OUTPUT-FILE ASSIGN TO ACCTOUT
ORGANIZATION INDEXED
ACCESS dYNAMIC
FILE STATUS FILE-STATUS
RECORD KEY ACCTOUT-PRIM-KEY
ALTERNATE KEY ACCTOUT-KEY-1
ALTERNATE KEY ACCTOUT-KEY-2.

FD ACCOUNT-OUTPUT-FILE.
01 ACCTOUT-REC.
03 ACCTOUT-PRIM-KEY.
05 ACCTOUT-OPCO PIC X(02).
05 ACCTOUT-AGENT-NUMBER PIC X(05).
05 ACCTOUT-TRANS-AMT PIC S9(11) COMP-3.
05 ACCTOUT-ENTRY-DATE X(06).
05 ACCTOUT-POLNUM PIC X(08).
05 ACCTOUT-CYCLE-DATE PIC 9(07) COMP-3.
05 ACCTOUT-COUNTER PIC 9(07) COMP-3.
03 ACCTOUT-ALT-KEY-R REDEFINES ACCTOUT-PRIM-KEY.
05 FILLER PIC X(07).
05 ACCTOUT-KEY-1 PIC X(28).
03 ACCTOUT-ALT-KEY-2R REDEFINES ACCTOUT-ALT-KEY-R.
05 FILLER PIC X(19).
05 ACCTOUT-KEY-2 PIC X(16).
03 ACCTOUT-ACCOUNT-NUMBER PIC 9(07) COMP-3.
03 ACCTOUT-VOUCHER PIC X(06).
03 ACCTOUT-DBT-CRD-IND PIC X(01).
03 ACCTOUT-CLASS-IND PIC X(01).
03 ACCTOUT-DESC PIC X(25).
03 ACCTOUT-FILLER PIC X(05).

 

[Dimandja]

Another question, you say "Error Code", is this really a file status code?

 

[MIKELEIBO]

yes - file-status

 

[Dimandja]

Ok. If the file was not reorganized either, then look at your data; particularly the numeric fields in your primary key. Namely these two fields:

05 ACCTOUT-CYCLE-DATE PIC 9(07) COMP-3.
05 ACCTOUT-COUNTER PIC 9(07) COMP-3.

Set a breakpoint and look at your record content before you WRITE and get the error.

My suspicion is that some (numeric ?) fields are corrupt.

 

[Dimandja]

MIKELEIBO,

Any luck?

 

[3gm]

Hmmm - this is a tough one. The presence of garbage in COMP-3 fields is not causing the problem. My suspicion is that there is a problem with one of the two alternate indices. I'd look at space allocation for those. If you haven't reorganized the file and its indices, you should do that.

Other thoughts:

Can you recreate the problem on a subset of the file?

Can you confirm the alternate indices do indeed match the File Definition for offset and length?

Is there any possibility to remove the alternate keys from the program to see if the error is in the base cluster or the alternate indices?

Any chance the File Status you're examining is not the one returned by the suspected WRITE but is from IO to another file in the program?

Let us know how you make out.

Regards.

Glenn

 

[MIKELEIBO]

I fixed it and my guess about a duplicate key was correct, (but lucky).

This file had three different indices - prinmary and two secondary keys, all defined as unique.

I managed to establish a test environment (many DB2 tables and VSAM files). I then ran under expeditor and put a stop in the program where it finds a FILE-STATUS other than '00'. It stopped on the abending record that had displayed. I changed the spaces in the secondary key to
random characters and restarted the program at the write and it worked but failed on the next occurance where there were spaces as part of the tertiary key. I then deleted all of the records with spaces in that field and the program ran fine...

Now, all i have to do, is determine if I can remove the "unique" on the secondary key(s), or find a way to identify these problem records way before it gets to this point in the system...

Thanks for your help and interest.

PS. VSAM doesn't check for validity of numeric fIelds but it was a good guess.

 

[Dimandja]

>Now, all i have to do, is determine if I can remove the "unique" on the secondary key(s), ...

I wouldn't do this without first finding out why it was made to be unique in the first place. Editing the data before writing it to the file is what everyone should be doing.