Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

VSAM write failing thru code but working by REPRO/edit mode

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
aakar

New User


Joined: 08 Apr 2008
Posts: 36
Location: mumbai

PostPosted: Fri Oct 31, 2008 11:42 am    Post subject: VSAM write failing thru code but working by REPRO/edit mode
Reply with 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!!!.

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
View user's profile Send private message

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Fri Oct 31, 2008 5:12 pm    Post subject:
Reply with quote

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
View user's profile Send private message
aakar

New User


Joined: 08 Apr 2008
Posts: 36
Location: mumbai

PostPosted: Sat Nov 01, 2008 7:33 pm    Post subject:
Reply with quote

Thanks a lot Robert for the reply. icon_smile.gif

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
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10201
Location: italy

PostPosted: Sat Nov 01, 2008 9:02 pm    Post subject: Reply to: VSAM write failing thru code but working by REPRO/
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Sat Nov 01, 2008 9:21 pm    Post subject:
Reply with quote

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
View user's profile Send private message
aakar

New User


Joined: 08 Apr 2008
Posts: 36
Location: mumbai

PostPosted: Sat Nov 01, 2008 9:35 pm    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Sat Nov 01, 2008 9:55 pm    Post subject:
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10201
Location: italy

PostPosted: Sat Nov 01, 2008 10:31 pm    Post subject: Reply to: VSAM write failing thru code but working by REPRO/
Reply with quote

why are You using shareoption(x,4) ??
are You using it cross system..
Back to top
View user's profile Send private message
aakar

New User


Joined: 08 Apr 2008
Posts: 36
Location: mumbai

PostPosted: Sat Nov 01, 2008 10:34 pm    Post subject:
Reply with quote

No enrico its not being used cross system.
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10201
Location: italy

PostPosted: Sat Nov 01, 2008 10:48 pm    Post subject: Reply to: VSAM write failing thru code but working by REPRO/
Reply with quote

so just use shr(x,3) icon_biggrin.gif
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Sun Nov 02, 2008 2:40 am    Post subject:
Reply with quote

The manual link to the quote is:

http://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
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10201
Location: italy

PostPosted: Sun Nov 02, 2008 3:30 am    Post subject: Reply to: VSAM write failing thru code but working by REPRO/
Reply with quote

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 icon_biggrin.gif
and is not our problem, after all they are grown men. aren' t they icon_cool.gif
Back to top
View user's profile Send private message
aakar

New User


Joined: 08 Apr 2008
Posts: 36
Location: mumbai

PostPosted: Mon Nov 03, 2008 8:45 am    Post subject:
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10201
Location: italy

PostPosted: Mon Nov 03, 2008 1:18 pm    Post subject: Reply to: VSAM write failing thru code but working by REPRO/
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Mon Nov 03, 2008 7:34 pm    Post subject:
Reply with quote

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
View user's profile Send private message
aakar

New User


Joined: 08 Apr 2008
Posts: 36
Location: mumbai

PostPosted: Tue Nov 04, 2008 8:35 am    Post subject:
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Tue Nov 04, 2008 8:53 am    Post subject:
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts What is the code in CLIST to enable t... jackzhang75 CLIST & REXX 1 Fri Dec 02, 2016 3:02 am
No new posts IDEAL - Code Retrieval yugendran CA Products 0 Fri Nov 25, 2016 3:27 pm
No new posts What is the command to check MODE of ... rohanthengal CLIST & REXX 6 Fri Nov 18, 2016 1:48 pm
No new posts BWO option in VSAM blayek CICS 3 Sat Nov 05, 2016 10:47 am
No new posts Error IEC161I 052(009,XXXRS00)-084 wh... amitc23 JCL & VSAM 10 Wed Oct 12, 2016 5:00 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us