CICS eibresp 22 while reading VSAM File Sequentially

abhishek chhawcharia · New User Joined: 21 Mar 2009 Posts: 10 Location: Ohio

HI All,

I am facing a problem of getting a eibresp of 22 while reading a VSAM file. I am doing a STARTBR as I am trying to read the file sequentially.

EXEC CICS
STARTBR
FILE ('PHREVSAM')
RIDFLD(PHREVSAM-KEY)
GTEQ
RESP(RESPONSE-CODE)
END-EXEC.

The response code is coming as 0 for the above command.

After this I am doing,

EXEC CICS READNEXT
DATASET('PHREVSAM')
INTO(PHREVSAM-REC)
LENGTH(PHREVSAM-LEN)
RIDFLD(PHREVSAM-KEY)
RESP(RESPONSE-CODE)
END-EXEC

While PHREVSAM-LEN is defined as PIC 9(5) VALUE 22000 as 22000 is the total length of each record in VSAM file.

I am not sure what I doing here wrong. Any help or comment will be appreciated.

Abhishek

Bill Woodger · Posted: Tue Apr 22, 2014 1:50 am

What length have you defined for PHREVSAM-REC? Check on the compile listing.

Robert Sample · Posted: Tue Apr 22, 2014 1:57 am

From the Application Programming Reference manual on READFROM:

abhishek chhawcharia · New User Joined: 21 Mar 2009 Posts: 10 Location: Ohio

I tried doing that and changing the declaration as below.

05 PHREVSAM-LEN PIC S9(04) COMP .

But I still get the same error as 22.

Also the length of my VSAM file is 22000.

Abhishek

Bill Woodger · Posted: Tue Apr 22, 2014 2:06 am

22,000 isn't going to fit in COMP PIC 9(4), unless you are using compiler option TRUNC(BIN).

If you are not using TRUNC(BIN), define it as COMP-5 PIC 9(4).

abhishek chhawcharia · New User Joined: 21 Mar 2009 Posts: 10 Location: Ohio

I tried changing the declaration to COMP-5 PIC 9(4). It still give me resposnse code of 22 in first read and the PHREVSAM-REC is spaces....

Abhishek

Rohit Umarjikar · Posted: Tue Apr 22, 2014 3:13 am

abhishek chhawcharia · New User Joined: 21 Mar 2009 Posts: 10 Location: Ohio

Hi Rohit,

I read the sentence in bold and corrected the field declaration to COMP-5 PIC 9(4) but I still get the same error message. VSAM record length is 22000.

Rohit Umarjikar · Posted: Tue Apr 22, 2014 3:29 am

Have you still given the VALUE clause, if yes then try keeping without it? also can you please tell what value are you getting into EIBRESP2 ? can you also check for the FCT entry to be a Fixed Record as you say?

abhishek chhawcharia · New User Joined: 21 Mar 2009 Posts: 10 Location: Ohio

Hi Rohit,

I have removed the value and made the declaration as below.

PHREVSAM-LEN COMP-5 PIC 9(4).

And I still get the error. Do you think adding the value clause will make any difference?

Rohit Umarjikar · Posted: Tue Apr 22, 2014 3:39 am

Bill Woodger · Posted: Tue Apr 22, 2014 3:47 am

abhishek chhawcharia · New User Joined: 21 Mar 2009 Posts: 10 Location: Ohio

NO, the records are fixed length of 22000 bytes.

So what you are saying is I should move the length of PHREVSAM-REC to PHREVSAM-LEN before every read??

Anuj Dhawan · Posted: Tue Apr 22, 2014 4:06 pm

With COMP and 22000, you assign a value to this field which won't fit in it, said that ,you've two choices -- as has been said, you should either specify the TRUNC(BIN) compiler option or define this field as COMP-5 but then, as said earlier, your compiler might/might not supports this.

And you should also note that if you use COMP-5 and use TRUNC option as well, there is no use of that - as these two don't talk to each other.

abhishek chhawcharia · New User Joined: 21 Mar 2009 Posts: 10 Location: Ohio

Hi All,

Thanks for the responses. MOVE LENGTH OF statement fixed the issue and now the VSAM file read and write is happening correctly.

Appreciate all your help.

Abhishek

Mickeydusaor · Posted: Tue Apr 22, 2014 10:50 pm

If you had coded your CICS statements as below you would not have had any of these issues.

Bill O'Boyle · Posted: Tue Apr 22, 2014 11:07 pm

Mickey,

I think he had the halfword defined in WS with a value clause and he used TRUNC(OPT) during compilation.

This causes high-order truncation, because the picture clause is 4 and the value exceeds 9999. But, the LENGTH OF is the better way to go.

COMP-5 was introduced with OS/390 COBOL 2.2 (about 15 years ago). But, if the OP is running a non-friendly COMP-5 compiler, he'd have to use TRUNC(BIN) in order to negate any truncation of non COMP-5 binary fields.

Sidenote: Always use KEYLENGTH in a FILE API because if the file becomes REMOTE, then the CICS System Programmer doesn't need to scurry around and find this value for the FCT entry. The KEYLENGTH keyword (and value) is NOT Function Shipped to a Remote File for any File API.

HTH....

Rohit Umarjikar · Posted: Wed Apr 23, 2014 4:09 am

Bill,

I would just like to understand more here on how

Bill Woodger · Posted: Wed Apr 23, 2014 4:26 am

First question is "which Bill"?

COMP/COMP-4/BINARY PIC 9(4) with TRUNC(OPT) (likely) or TRUNC(STD) (definitely) cannot hold more than 9999 as a value. the compiler does decimal truncation to the PICture size.

COMP-5 (or any of the above with TRUNC(BIN)) does binary truncation to the field size, The PICture is just used to define the field size. PIC 9 to PIC 9(4) gets a half-word, but the maximum value of any of those is 64k-1.

LENGTH OF field gets a value representing the length of the field in question (saves counting, looking at the listing, "knowing").

If the length of the data is required to be passed to CICS, and if CICS then sets that value to the actual length used, it will need to be re-set each time.

I'd suspect that the length of the field turned out to be less than 22,000, or that the actual records are larger than thought to be. Using LENGTH OF instead of a literal takes away the effort of ensure that the literal is, and remains, correct.

Just from reading the link, it would seem that LENGTH(...) is not needed for fixed-length records anyway...