Problem while reading adn writing due to key length change

Mayil · New User Joined: 19 Dec 2005 Posts: 14

A file had a Key of Pic 9(03) Comp-3. It was changed to Pic 9(03) due to a requirement change. Now I am unable to do a CICS write or a random read in the file.

When I try to read write to the file, it gives a response code of EIBRCODE 81 (Record not found) EIBRESP 16 & EIBRESP2 23. When i browse the file, i can see the record with the same key i am passing.

The return codes for a random read is 13 for EIBRESP & 80 for EIBRESP2.

However i am able to a successful CECI read on the file.

Any idea on why this problem is happening.

William Thompson · Posted: Mon May 28, 2007 5:01 pm

The resp2 on the write says it all:
23 When writing records containing embedded keys, the key in the record area (FROM option) and the key in RIDFLD do not match.
The key that your program is attempting to rewrite is different from the key of the record.
You went from a two byte PD (unsigned?) key to a three byte ZD (unsinged?) key.
Somehow, you have failed to fully convert either your program or your file.
Do the CECI again, and after the successful read, PF2 for HEX, and edit/select all/copy and paste onto your next responce here.

Mayil · New User Joined: 19 Dec 2005 Posts: 14

Actually i am working in a multiple region CICS.

In the file owning region am able to do a successful read.
The screen shot is given below.

In the transaction owning region, am not able to do a successful read even using CECI.

William Thompson · Posted: Mon May 28, 2007 6:15 pm

Mayil · New User Joined: 19 Dec 2005 Posts: 14

We cannot initiate transactions in the file owning region, hence cannot test the program over there. (From next timie, will copy the text instead of pasting a screen shot).

William Thompson · Posted: Mon May 28, 2007 6:45 pm

Sorry, missed the second JPG....
In the notfnd, try GTeq instead of Equal.
Also in the notfnd, do a cemt inq on the file......

Mayil · New User Joined: 19 Dec 2005 Posts: 14

Actually there are three records in the file IMDSP with the keys as
a.) 000
b.) 100
c.) 101

In the Transaction owning region, if i give a GT for 000, it reads the second record (key 100)

READ FILE(IMDSP) RID(000) GT
STATUS: COMMAND EXECUTION COMPLETE NAME=
EXEC CICS READ
File( 'IMDSP ' )
< SYsid() >
( SEt() | Into( '100TEST ...@BB' ... ) )
< Length( +00287 ) >
RIdfld( '000' )
< Keylength() < GEneric > >
< RBa | RRn | DEBRec | DEBKey >
< GTeq | Equal >
< UNcommitted | Consistent | REpeatable | UPdate < Token() > >
< Nosuspend >

RESPONSE: NORMAL EIBRESP=+0000000000 EIBRESP2=+0000000000
PF 1 HELP 2 HEX 3 END 4 EIB 5 VAR 6 USER 7 SBH 8 SFH 9 MSG 10 SB 11 SF

When i give a Read GT for a key of 100, it says record not found.

READ FILE(IMDSP) RID(100) GT
STATUS: COMMAND EXECUTION COMPLETE NAME=
EXEC CICS READ
File( X'C9D4C4E2D7404040' )
< SYsid() >
( SEt() | Into( X'' ) )
< Length( X'0000' ) >
RIdfld( X'F1F0F0' )
< Keylength() < GEneric > >
< RBa | RRn | DEBRec | DEBKey >
< GTeq | Equal >
< UNcommitted | Consistent | REpeatable | UPdate < Token() > >
< Nosuspend >

RESPONSE: NOTFND EIBRESP=X'0000000D' EIBRESP2=X'00000050'
PF 1 HELP 2 HEX 3 END 4 EIB 5 VAR 6 USER 7 SBH 8 SFH 9 MSG 10 SB 11 SF

I cannot do an inquire in the file owning region.

Mayil · New User Joined: 19 Dec 2005 Posts: 14

I noticed one queer thing, i gave a CECI inquire file for my file in Transaction owning region and the file owning regions.

In my file owning region, the key length is correctly getting displayed as 3.

INQ FI(IMDSP)
STATUS: COMMAND EXECUTION COMPLETE NAME=
EXEC CICS INQuire File( 'IMDSP ' )
+ < KEYLength( +0000000003 ) >
< KEYPosition( +0000000000 ) >
< LOadtype( +0000000835 ) >
< LSrpoolid( +0000000001 ) >
< Maxnumrecs( +0000000000 ) >
< OBject( +0000000010 ) >
< OPenstatus( +0000000018 ) >
< READ( +0000000035 ) >
< READInteg( +0000000001 ) >
< RECORDFormat( +0000000013 ) >
< RECORDSize( +0000000287 ) >
< RECOVstatus( +0000000030 ) >
< RELtype( +0000000001 ) >
< REMOTEName( ' ' ) >
< REMOTESystem( ' ' ) >
< REMOTETable( +0000000001 ) >
+ < RLsaccess( +0000000721 ) >

RESPONSE: NORMAL EIBRESP=+0000000000 EIBRESP2=+0000000000
PF 1 HELP 2 HEX 3 END 4 EIB 5 VAR 6 USER 7 SBH 8 SFH 9 MSG 10 SB 11 SF

Whereas in the transaction owning region, it is getting displayed as 2 only

INQ FI(IMDSP)
STATUS: COMMAND EXECUTION COMPLETE NAME=
EXEC CICS INQuire File( 'IMDSP ' )
+ < KEYLength( +0000000002 ) >
<KEYPosition( -0000000001 ) >
< LOadtype( +0000000835 ) >
< LSrpoolid( -0000000001 ) >
< Maxnumrecs( -0000000001 ) >
< OBject( +0000000001 ) >
< OPenstatus( +0000000001 ) >
< READ( +0000000001 ) >
< READInteg( +0000000001 ) >
< RECORDFormat( +0000000001 ) >
< RECORDSize( +0000000287 ) >
< RECOVstatus( +0000000001 ) >
< RELtype( +0000000001 ) >
< REMOTEName( 'IMDSP ' ) >
< REMOTESystem( 'A02J' ) >
< REMOTETable( +0000000001 ) >
+ < RLsaccess( +0000000001 ) >

RESPONSE: NORMAL EIBRESP=+0000000000 EIBRESP2=+0000000000
PF 1 HELP 2 HEX 3 END 4 EIB 5 VAR 6 USER 7 SBH 8 SFH 9 MSG 10 SB 11 SF

I believe this might be the root cause of hte problem, can you please give your view on this.
If this is the problem, how to change the key length in the transaction owning region? We define transactions only in this region, files are not defined.

William Thompson · Posted: Mon May 28, 2007 10:24 pm

Very observant, in the notfnd, ceci and give it a keylength of three.
If I recall correctly, the keylength on the file description (the cemt) is the default, and should be able to be overridden.

William Thompson · Posted: Mon May 28, 2007 10:25 pm

Another think, it looks like the file definition in the FOR got updated but the TOR one didn't....

Mayil · New User Joined: 19 Dec 2005 Posts: 14

When I am overriding the Key length as 3 in TOR, it is doing a read successfully. I don't why the key length doesn't get reflected in TOR. Both TOR and FOR were bought down and up on Sunday. So, it should have reflected, but it isn't. This problem is making me

William Thompson · Posted: Tue May 29, 2007 3:44 pm

Mayil · New User Joined: 19 Dec 2005 Posts: 14

Yep, will have a have talk with the system guys.
Thanks William for patiently replying to this entire thread.

William Thompson · Posted: Tue May 29, 2007 4:21 pm

No, thank you for promptly and accurately responding to my queries...