I really appreciate everyone's feedback on this.
We have a separate file keeping track of the key sequence. It's a non-keyed
file that at the beginning contains '0000000001'. It
is being incremented with each write of our main file below. The next would be
'0000000002', and so on.
In addition, each transaction that writes a record for this test is not running
concurrently at this time. Each transaction
completes before another is executed.
The '21' return code is being received as a response from CICS when performing
a 'WRITE' on 'DVLFIL'.
EXEC CICS
WRITE DATASET('DVLFIL')
FROM (WS-DVLFIL-IO-AREA)
RIDFLD (DVLFIL-VALIDATION-ID)
RESP (WS-CICS-RESPONSE)
END-EXEC
Here are the defines for our VSAM file and it's supporting AIX's (only 3 as of
now):
000001 DEL FITEQ.DVLFIL CL PURGE
000002 DEF CL (NAME (FITEQ.DVLFIL) VOLUME (USER03) KEYS(10,0) -
000003 INDEXED -
000004 FREESPACE (5 5) -
000005 RECSZ (466,466) -
000006 SHAREOPTIONS (3 3) -
000007 IMBED REPLICATE -
000008 NOREUSE) -
000009 DATA (NAME (FITEQ.DVLFIL.DATA) -
000010 CYL(500,100) -
000011 CISZ (16384)) -
000012 INDEX (NAME (FITEQ.DVLFIL.INDEX) -
000013 CYL(50,10) )
000010 /* THIS IS THE JCL FOR DEFINING THE DAC VALIDATION LOGFILE ALTERNATE
000011 /* INDEX1 WHICH IS THE
000012 /* ACCT-ID+DAC-COUNTER+RESULT-CODE,LENGTH OF 16,OFFSET 39.
000013
000014 DEFINE AIX ( NAME(FITEQ.DVLFIL1) -
000015 RELATE(FITEQ.DVLFIL) -
000016 VOLUME (USER03) KEYS(16,39) -
000017 NONUNIQUEKEY -
000018 SHAREOPTIONS (3 3) -
000019 REUSE -
000020 UPGRADE) -
000021 DATA ( NAME(FITEQ.DVLFIL1.DATA) -
000022 CYL(20,10) ) -
000023 INDEX ( NAME(FITEQ.DVLFIL1.INDEX) -
000024 CYL(10,05))
000025
000026 /* THIS IS THE JCL FOR DEFINING THE DAC VALIDATION LOGFILE ALTERNATE
000027 /* INDEX2, WHICH IS THE CCYYMMDDHHMISS PART OF THE TIMESTAMP.
000028 /* LENGTH OF 14,OFFSET 10.
000029
000030 DEFINE AIX ( NAME(FITEQ.DVLFIL2) -
000031 RELATE(FITEQ.DVLFIL) -
000032 VOLUME (USER04) KEYS(14,10) -
000033 NONUNIQUEKEY -
000034 SHAREOPTIONS (3 3) -
000035 REUSE -
000036 UPGRADE) -
000037 DATA ( NAME(FITEQ.DVLFIL2.DATA) -
000038 CYL(20,10) ) -
000039 INDEX ( NAME(FITEQ.DVLFIL2.INDEX) -
000040 CYL(10,05) )
000041
000042 /* THIS IS THE JCL FOR DEFINING THE DAC VALIDATION LOGFILE ALTERNATE
000043 /* INDEX 5, WHICH IS THE ACCOUNT-NUMBER,LENGTH 19,OFFSET 69.
000044
000045 DEFINE AIX ( NAME(FITEQ.DVLFIL5) -
000046 RELATE(FITEQ.DVLFIL) -
000047 VOLUME (USER04) KEYS(19,69) -
000048 NONUNIQUEKEY -
000049 SHAREOPTIONS (3 3) -
000050 REUSE -
000051 UPGRADE) -
000052 DATA ( NAME(FITEQ.DVLFIL5.DATA) -
000053 CYL(20,10) ) -
000054 INDEX ( NAME(FITEQ.DVLFIL5.INDEX) -
000055 CYL(10,05) )
000056
000057 /* BUILD THE ALTERNATE INDICES:
000058 /*
000059
000060 BLDINDEX IDS(FITEQ.DVLFIL) ODS(FITEQ.DVLFIL1)
000061 BLDINDEX IDS(FITEQ.DVLFIL) ODS(FITEQ.DVLFIL2)
000062 BLDINDEX IDS(FITEQ.DVLFIL) ODS(FITEQ.DVLFIL5)
000063
000064 /* DEFINE THE PATHS:
000065 /*
000066
000067 DEF PATH (NAME (FITEQ.DVLFIL.PATH1) -
000068 PATHENTRY (FITEQ.DVLFIL1))
000069
000070 DEF PATH (NAME (FITEQ.DVLFIL.PATH2) -
000071 PATHENTRY (FITEQ.DVLFIL2))
000072
000073 DEF PATH (NAME (FITEQ.DVLFIL.PATH5) -
000074 PATHENTRY (FITEQ.DVLFIL5))
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Ken Brick
Sent: Friday, June 17, 2011 7:59 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CICS VSAM Return Code 21 on Write
On 18/06/2011 07:59 AM, John Weber wrote:
> All,
>
> We are running individual CICS transactions. Each increments a counter for a
> key that is written to a VSAM file. This file
> Consists of a primary index as well as 6 alternate indexes. It encounters a
> response code of 21 after roughly 3,000 writes. It seems
> To improve in the number of successful writes with the removal of the AIX's -
> one at a time.
>
> Return code 21 is described as a 'sequence error' on write (notably
> sequential).
>
> These writes are occurring in sequence but this doesn't matter because the
> file is indexed.
>
> Could this be related to storage or the VSAM definitions?
>
> If anyone has encountered a situation like this or can make a suggestion, it
> would be much appreciated.
>
> The internet only describes the 21 but offers no reasons or resolutions for
> it.
>
> Thanks...
>
> John
>
> P.S. Go IBM!
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
John,
First some suppositions and a disclaimer.
1. The KSDS starts off empty at the beginning of a session. This means
you are loading the file.
2. There are multiple "concurrent" transactions updating the KSDS and AIXs.
Many eons since I did any CICS programming.
I see a possible cause of the sequence error. The first is a transaction
that starts after another actually gets to write its record first which
will cause the earlier transaction to fail with the sequence error. This
could be a pure path question or it could be caused by the AIX updates
on transaction N not be being completed before N+1 is completed.
Could you start the KSDS with a dummy record then when CICS starts
adding records it is actually updating the file and sequence no longer
matters. If you take this approach you had better provide a smalll
amount of freespace.
Ken
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
