CICS-VSAM
Hello all I have a VSAM file defined in a cics 3.1.0 region . The file is owend by CICSA and is accessed with remote definition from CICSB and CICSC. I have ZOS1.4 on Z890. This has been working fine fore three weeks now.. BUT,, After I recycled CICSA , my customer began to complain that the file was closed. But sometimes everything was working fine against the file, and sometimes the file seemed to be closed.. As the file was open enable and I could not see in my monitor that there were any bottleneck in the system, I guessed that the trouble was in VSAM, and tried to RECYCLE both regions CICSA and CICSF.. Then The problem was solved for CICSF and CICS5.. I beleve I also need to Recycle CICSB to get rid of the problem completely for the time beeing. Does anyone know anything about problem like that ? This has to be a bug ? Best reg. Jon Vidar -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CICS-VSAM
Hello Jon. Try put this question to CICS-L. This address are [EMAIL PROTECTED] Good Luck. Sergio Lima Costa System Consultant Caixa Economica Federal Sao Paulo - Brasil Jón Viðar Gunnarsson <[EMAIL PROTECTED]> escreveu: Hello all I have a VSAM file defined in a cics 3.1.0 region . The file is owend by CICSA and is accessed with remote definition from CICSB and CICSC. I have ZOS1.4 on Z890. This has been working fine fore three weeks now.. BUT,, After I recycled CICSA , my customer began to complain that the file was closed. But sometimes everything was working fine against the file, and sometimes the file seemed to be closed.. As the file was open enable and I could not see in my monitor that there were any bottleneck in the system, I guessed that the trouble was in VSAM, and tried to RECYCLE both regions CICSA and CICSF.. Then The problem was solved for CICSF and CICS5.. I beleve I also need to Recycle CICSB to get rid of the problem completely for the time beeing. Does anyone know anything about problem like that ? This has to be a bug ? Best reg. Jon Vidar -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __ Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CICS VSAM journal question
Hi, I use autojournaling to analize UOW records. How could I know UOW bounderies? The bit designating "START OF UOW" together with the taskid is obviously "START TRANSACTION". Could I know something about "COMMIT" or "ROLLBACK" ? Arie Kremer -- 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
CICS VSAM Return Code 21 on Write
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
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
Re: CICS VSAM Return Code 21 on Write
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 '01'. It
is being incremented with each write of our main file below. The next would be
'02', 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
WRITEDATASET('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):
01 DEL FITEQ.DVLFIL CL PURGE
02 DEF CL (NAME (FITEQ.DVLFIL) VOLUME (USER03) KEYS(10,0)-
03 INDEXED -
04 FREESPACE (5 5) -
05 RECSZ (466,466) -
06 SHAREOPTIONS (3 3)-
07 IMBED REPLICATE -
08 NOREUSE) -
09DATA (NAME (FITEQ.DVLFIL.DATA)-
10 CYL(500,100) -
11 CISZ (16384)) -
12INDEX(NAME (FITEQ.DVLFIL.INDEX) -
13 CYL(50,10) )
10 /* THIS IS THE JCL FOR DEFINING THE DAC VALIDATION LOGFILE ALTERNATE
11 /* INDEX1 WHICH IS THE
12 /* ACCT-ID+DAC-COUNTER+RESULT-CODE,LENGTH OF 16,OFFSET 39.
13
14 DEFINE AIX ( NAME(FITEQ.DVLFIL1)-
15 RELATE(FITEQ.DVLFIL) -
16 VOLUME (USER03) KEYS(16,39)-
17 NONUNIQUEKEY -
18 SHAREOPTIONS (3 3)-
19 REUSE -
20 UPGRADE) -
21 DATA ( NAME(FITEQ.DVLFIL1.DATA) -
22 CYL(20,10) ) -
23 INDEX ( NAME(FITEQ.DVLFIL1.INDEX) -
24 CYL(10,05))
25
26 /* THIS IS THE JCL FOR DEFINING THE DAC VALIDATION LOGFILE ALTERNATE
27 /* INDEX2, WHICH IS THE CCYYMMDDHHMISS PART OF THE TIMESTAMP.
28 /* LENGTH OF 14,OFFSET 10.
29
30 DEFINE AIX ( NAME(FITEQ.DVLFIL2)-
31 RELATE(FITEQ.DVLFIL) -
32 VOLUME (USER04) KEYS(14,10)-
33 NONUNIQUEKEY -
34 SHAREOPTIONS (3 3)-
35 REUSE -
36 UPGRADE) -
37 DATA ( NAME(FITEQ.DVLFIL2.DATA) -
38 CYL(20,10) ) -
39 INDEX ( NAME(FITEQ.DVLFIL2.INDEX) -
40 CYL(10,05) )
41
42 /* THIS IS THE JCL FOR DEFINING THE DAC VALIDATION LOGFILE ALTERNATE
43 /* INDEX 5, WHICH IS THE ACCOUNT-NUMBER,LENGTH 19,OFFSET 69.
44
45 DEFINE AIX ( NAME(FITEQ.DVLFIL5)-
46 RELATE(FITEQ.DVLFIL) -
47 VOLUME (USER04) KEYS(19,69)-
48 NONUNIQUEKEY -
49 SHAREOPTIONS (3 3)-
50 REUSE -
51 UPGRADE) -
52 DATA ( NAME(FITEQ.DVLFIL5.DATA) -
53 CYL(20,10) ) -
54 INDEX ( NAME(FITEQ.DVLFIL5.INDEX) -
55 CYL(10,05) )
56
57 /* BUILD THE ALTERNATE INDICES:
58 /*
59
60 BLDINDEX IDS(FITEQ.DVLFIL) ODS(FITEQ.DVLFIL1)
61 BLDINDEX IDS(FITEQ.DVLFIL) ODS(FITEQ.DVLFIL2)
62 BLDINDEX IDS(FITEQ.DVLFIL) ODS(FITEQ.DVLFIL5)
63
64 /* DEFINE THE PATHS:
65 /*
66
67 DEF PATH (NAME (FITEQ.DVLFIL.PATH1)-
68PATHENTRY (FITEQ.DVLFIL1))
69
70 DEF PATH (NAME (FITEQ.DVLFIL.PATH2)-
71PATHENTRY (FITEQ.DVLFIL2))
72
73 DEF PATH (NAME (FITEQ.DVLFIL.PATH5)-
74PATHENTRY (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 Retu
