|
View previous topic :: View next topic
|
| Author |
Message |
aakar
New User
Joined: 08 Apr 2008
Posts: 36
Location: mumbai
|
|
|
|
I am getting the VSAM error return code 24 while trying to write to a VSAM file through a COBOL program. but when i open the file in edit mode and add a record or if i repro records into the file it works!!!.
24-
An attempt was made to write beyond the externally defined boundaries of a relative or indexed file. Or, a sequential WRITE statement was attempted for a relative file and the number of significant digits in the relative record number was larger than the size of the relative key data item described for the file.
The cobol program is somehow calculating bytes allocated to VSAM by this formula,
No. of records written = (Primary extent in kb) / (Recordsize in bytes)
In my case i did foll testing,
No. of records written = 16600.78kb (i.e. 20 cyclinders) / (80 bytes)
= 207(approx)
When i increase the primary extents, the Records written increases.
I reproed huge amount of records into the file succesfully but everytime i run the program it abends.
I read in this forum that increasing secondary extents problem is solved.
How will it help me.
Please below dataset info:
| Code: |
Data Component Information: Current Allocation Options:
Device type: 3390 Load option: SPEED
Organization: KSDS Write check: NO
KSDS key length: 8 Buffer space: 37376
KSDS key location: 0 Erase on delete: NO
Average record size: 80 Imbedded index: NO
Maximum record size: 80 Replicated index: NO
Allocated Space: Unit Primary Secondary Reuse option: NO
Data: CYLINDERS 20 10 Share option: 4-4
Index: TRACKS 1 1 Spanned records: NO
|
|
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
LISTCAT output provides much more information than whatever you've put out here. The number of records written calculation is not, strictly speaking, number of tracks divided by the record size -- you must take into account the data component CI size as well as the free space percentage to accurately figure record counts per track (or cylinder).
Is there any chance the pack has no room to take an extent? If so, that could explain your problem.
If there's room on the pack, I would say your shareoptions are causing your problem. From the manual on SHR(4 4):
| Quote: |
| Writing is limited to PUT-update and PUT-insert processing that does not change the high-used RBA if your program opens the data set with DISP=SHR. |
So if you're trying to add records to the end of the file with SHR(4 4) you very well could get a file status 24, which would indicate you're trying to write past the end of the file (hi used RBA). |
|
| Back to top |
|
|
aakar
New User
Joined: 08 Apr 2008
Posts: 36
Location: mumbai
|
|
|
|
Thanks a lot Robert for the reply. 
| Quote: |
| Is there any chance the pack has no room to take an extent? If so, that could explain your problem. |
Even after the program used to abend with RC=24, the cluster was still editable and records could be added manually into. So there was definitely room in the pack.
| Quote: |
| If there's room on the pack, I would say your shareoptions are causing your problem. |
I tried by changing the Shareoption to (3,3) , (4,3) & (3,4) and reduced
VSAM size to TRACKS(10,10) from CYLINDERS(20,10).
Results:
No. of records written by program to file
(4,4) : 70 (file not full and manually editable further)
(3,3) : 4073(file full and manually not editable further)
(4,3) : 4073(file full and manually not editable further)
(3,4) : 70(file not full and manually editable further)
So shareoptions was my problem, But i want the file to be shared(written to) without contention problems by jobs running parallely. Can u suggest a correct option out of (3,3) & (4,3) Or provide the reference from where u found this line:
| Quote: |
| Writing is limited to PUT-update and PUT-insert processing that does not change the high-used RBA if your program opens the data set with DISP=SHR. |
|
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| But i want the file to be shared(written to) without contention problems by jobs running parallely. |
are You and Your organization aware of the integrity exposure of concurrent update ?? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| SHAREOPTIONS (2 3) are typically used for a good reason. Using 4 4 requires (note: does not suggest -- requires) use of enqueue to ensure writes do not cause file corruption. As enrico says, there are definite integrity exposures in doing concurrent updates. |
|
| Back to top |
|
|
aakar
New User
Joined: 08 Apr 2008
Posts: 36
Location: mumbai
|
|
|
|
| Quote: |
| are You and Your organization aware of the integrity exposure of concurrent update ?? |
Yes Enrico we are aware and this is an existing VSAM file in production. It always fails giving RC=24 when it crosses 70 entries in production. Each job makes only one line entry to this file and around 60 jobs run in a day & at the EOD we clear off the data.Also we have around four to five jobs running in a parallel at a time. So we never faced a contention issue. By changing to correct shareoption i want to make sure we can accomodate enough jobs(more than 70) in a day. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| i want to make sure we can accomodate enough jobs(more than 70) in a day. |
I suggest you only want to do this if you can be sure there will be no loss of data integrity.
Running more and losing/damaging some is very poor choice. . .
While probably not accomplished over the weekend, it may be time to convert this to database. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
why are You using shareoption(x,4) ??
are You using it cross system.. |
|
| Back to top |
|
|
aakar
New User
Joined: 08 Apr 2008
Posts: 36
Location: mumbai
|
|
|
|
| No enrico its not being used cross system. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
so just use shr(x,3)  |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
The manual link to the quote is:
publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handheld/Connected/BOOKS/dgt1v403/3.7.1.2?SHELF=&DT=19990113080956&CASE=
Or go to the manuals link at the top of the page, click on the VSAM Services for DFSMS manual, go to section 3.7.1.2 and read about SHAREOPTIONS 4.
The section of SHAREOPTIONS 3 says
| Quote: |
3
specifies that the data set can be fully shared by any number of users. With this option, each user is responsible for maintaining both read and write integrity for the data the program accesses. User programs that ignore the write integrity guidelines can cause VSAM program checks, lost or inaccessible records, irreversible data set failures, and other unpredictable results. This option places heavy responsibility on each user sharing the data set. |
In other words, if you're not following the guidelines, you could cause all sorts of problems for yourself.
What's the LISTCAT for the file look like? Perhaps that'll give some clue as to what's going on. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
since the issue is with file capacity when the cross system shareoption is 4
and the TS confirmed that the dataset is not shared cross system,
then the cross system shareoption can be set to the minimum
all the other concerns for local shareoption 3/4 still stand valid...
but that' not the issue the TS was complaining about
and is not our problem, after all they are grown men. aren' t they  |
|
| Back to top |
|
|
aakar
New User
Joined: 08 Apr 2008
Posts: 36
Location: mumbai
|
|
|
|
All the jobs that write to the VSAM file run on the same batch system. Their purpose is to just write one entry to the VSAM file. The manual link given by Robert for option (x,3) says,
| Quote: |
| This option places heavy responsibility on each user sharing the data set. |
Does this mean that even after (x,3) say (4,3) we might expect a data integrity issue? Say If the file is not going to be shared among any other job but itself i.e. each job creates its own VSAM file then (3,3) should be fine right with DISP=OLD/SHR??
Please find the listcat for the base cluster:
| Code: |
LISTCAT ENTRIES(MVSAM.QUAL2.SPLIT.VFILE -
MVSAM.QUAL2.SPLIT.VFILE.DATE) ALL
CLUSTER ------- MVSAM.QUAL2.SPLIT.VFILE
IN-CAT --- CATALOG.UCATA.DEV06
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2008.306
RELEASE----------------2 EXPIRATION------0000.000
SMSDATA
STORAGECLASS ----PDBASEC MANAGEMENTCLASS--PDBASEA
DATACLASS --------NONSTD LBACKUP ---0000.000.0000
BWO STATUS------00000000 BWO TIMESTAMP---00000 00:00:00.0
BWO---------------(NULL)
RLSDATA
LOG ----------------(NULL) RECOVERY REQUIRED --(NO) FRLOG --------(null)
VSAM QUIESCED -------(NO) RLS IN USE ---------(NO)
LOGSTREAMID-----------------------------(NULL)
RECOVERY TIMESTAMP LOCAL-----X'0000000000000000'
RECOVERY TIMESTAMP GMT-------X'0000000000000000'
PROTECTION-PSWD-----(NULL) RACF----------------(NO)
ASSOCIATIONS
DATA-----MVSAM.QUAL2.SPLIT.VFILE.DATA
INDEX----MVSAM.QUAL2.SPLIT.VFILE.INDEX
AIX------MVSAM.QUAL2.SPLIT.VFILE.DATE
DATA ------- MVSAM.QUAL2.SPLIT.VFILE.DATA
IN-CAT --- CATALOG.UCATA.DEV06
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2008.306
RELEASE----------------2 EXPIRATION------0000.000
ACCOUNT-INFO-----------------------------------(NULL)
PROTECTION-PSWD-----(NULL) RACF----------------(NO)
ASSOCIATIONS
CLUSTER--MVSAM.QUAL2.SPLIT.VFILE
ATTRIBUTES
KEYLEN-----------------8 AVGLRECL--------------80 BUFSPACE------------9728
RKP--------------------0 MAXLRECL--------------80 EXCPEXIT----------(Null)
SHROPTNS(4,3) SPEED UNIQUE NOERASE INDEXED NOWRITECHK
UNORDERED NOREUSE NONSPANNED
CISIZE--------------4096
CI/CA----------------180
NOIMBED NOREPLICAT
STATISTICS
REC-TOTAL--------------1 SPLITS-CI--------------0 EXCPS---------------4
REC-DELETED------------0 SPLITS-CA--------------0 EXTENTS-------------1
REC-INSERTED-----------0 FREESPACE-%CI---------10 SYSTEM-TIMESTAMP:
REC-UPDATED------------0 FREESPACE-%CA---------10 X'C33B21BC7F8AB
REC-RETRIEVED----------1 FREESPC----------5156864
ALLOCATION
SPACE-TYPE------CYLINDER HI-A-RBA---------5160960
SPACE-PRI--------------7 HI-U-RBA----------737280
SPACE-SEC--------------7
S SYSTEM SERVICES TIME: 07:49:44
VOLUME
VOLSER------------CIZADG PHYREC-SIZE---------4096 HI-A-RBA---------5160960
DEVTYPE------X'3010200F' PHYRECS/TRK-----------12 HI-U-RBA----------737280
VOLFLAG------------PRIME TRACKS/CA-------------15
EXTENT-NUMBER----------1
EXTENT-TYPE--------X'40'
EXTENTS:
EXTENTS:
LOW-CCHH-----X'026D0000' LOW-RBA----------------0 TRACKS------------105
HIGH-CCHH----X'0273000E' HIGH-RBA---------5160959
|
|
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
if the dataset is shared You must ensure as the IDCAMS manual says the proper integrity ( ENQ/DEQ)
if the datset is not to be shared then SHR(2,x) might be a good choice
( 1 open in write, as many as You want in read )
still the process is not clear...
You say that each program has it's own dataset, and...
You have up to 5 jobs executing...
take a decision, are You facing a "multiple open for output at the same time "
situation or not ?? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
Okay, going back to the beginning ....
| Quote: |
| I am getting the VSAM error return code 24 while trying to write to a VSAM file through a COBOL program. but when i open the file in edit mode and add a record or if i repro records into the file it works!!!. |
Could you post the SELECT, FD, OPEN, and WRITE statements from the COBOL program? Also post the JCL for the step (at least the VSAM DD statements). Post these in code format, please. |
|
| Back to top |
|
|
aakar
New User
Joined: 08 Apr 2008
Posts: 36
Location: mumbai
|
|
|
|
Hi Robert & enrico thanks a lot for your help. I am no longer getting RC=24 error. I was able to write 1863149 records to the file with Shareoption (4,3) with a VSAM file having size TRACKS(10,10).
| Code: |
Select:
SELECT O-VSAM-FILE ASSIGN TO OVSAM
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
RECORD KEY IS SEQ-NO
FILE STATUS IS WS-FILE-STATUS.
File description:
FD O-VSAM-FILE
LABEL RECORDS ARE STANDARD
DATA RECORD IS O-VSAM-REC.
01 O-VSAM-REC.
Open:
OPEN I-O O-VSAM-FILE
Write :
WRITE O-VSAM-REC OF O-VSAM-FILE
|
Sorry can't post the entire JCL the DD statement is,
| Code: |
//OVSAM DD DSN=MVSAM.QUAL2.SPLIT.VFILE,DISP=SHR
|
|
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| You have an alternate index defined on this file. If the AIX is defined in the upgrade set, I'm not sure what results you get from writing records without having it available, but a file status 24 is certainly possible. Add the ALTERNATE RECORD KEY clause to the COBOL program and //OVSAM1 DD statement to the JCL and let us know the results after doing so. |
|
| Back to top |
|
|
|
|
