|
View previous topic :: View next topic
|
| Author |
Message |
sanjay kumar tripathi
New User
Joined: 08 Jul 2008
Posts: 11
Location: chennai
|
|
|
|
Hi all,
I have a requirement to create a vsam with average record length 127 and maximum of 381. The primary no. of records are 500000 and secondary 100000. I have created the VSam with following attributes.
DEFINE CLUSTER (NAME(vsam file) -
INDEXED -
NOREPLICATE -
RECORDS (500000,100000) -
RECORDSIZE (127,381) -
KEYS (25, 0) -
FREESPACE (10, 20) -
REUSE -
SHAREOPTIONS (4, 4)) -
DATA (NAME (vsamfile.DATA)) -
INDEX (NAME (vsamfile.INDEX))
But when i am running the program which uses this VSAM , after processing certain number of records(which is very less than 500000) its giving this error
COBOL: 24; VSAM:08, 0, 028
Could anyone please help me? |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
Please post the exact error messages and codes issued from the job output.
Also bear in mind
| Quote: |
When you define the cluster using the RECORDS parameter, the amount of free space specified is not considered in the calculations to determine primary allocation. |
|
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Read VSAM Demystified
I would say that we should make this a sticky, but that would be a waste of time.
few search, few look at manuals, most just post the question and wait for answers. |
|
| Back to top |
|
|
sanjay kumar tripathi
New User
Joined: 08 Jul 2008
Posts: 11
Location: chennai
|
|
|
|
I have used following declarative in the program
DECLARATIVES.
ERR-FLAGFILE SECTION.
USE AFTER ERROR PROCEDURE NEWVSAM.
DISPLAY 'ERROR DURING PROCESSING VSAMFILE'.
DISPLAY 'COBOL: ' WS-ARCH-STAT
'; VSAM:' FLG1 ', ' FLG2 ', ' FLG3.
MOVE 8 TO RETURN-CODE.
STOP RUN.
END DECLARATIVES.
Therefore i am getting following error message -
ERROR DURING PROCESSING VSAMFILE
COBOL: 24; VSAM:08, 0, 028 |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
OK, let's get to the basics.
Were there any IDC or IEC messages issued by the failing program.
You have defined the cluster, and what next -
Did you load it with data by some method
Do you use the program to load the data
How many records have been processed. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Post a LISTCAT in BBcode format for the file so we can see the definition.
Also, how many records got loaded? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
expat: wanna bet the program is loading the file and the COBOL code writes the maximum record length instead of the actual record length, and that the record count loaded is therefore about 167,000?  |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
| Back to top |
|
|
sanjay kumar tripathi
New User
Joined: 08 Jul 2008
Posts: 11
Location: chennai
|
|
|
|
I am not getting any other error mesage appart from that i mentioned. I have just created the VSAM with the specified attribute and then initialize it, because my program is using this in i/o mode. Thereafter my program is reading some values from databse and writing them into VSAM file.
Since VSAM is of variable record length, so i can not determine the exact reord being processed. In each and every run its used to be diferent. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
Mmmmmmm, setting up your own error messages when those that occur naturally from IBM are far more informative is not such a good idea. But then that's only my opinion.
Please post the LISTCAT requested by Robert.
| Quote: |
expat: wanna bet the program is loading the file and the COBOL code writes the maximum record length instead of the actual record length, and that the record count loaded is therefore about 167,000?
|
Robert: Bet against a sysprog ? NO WAY - they're shadier than an English summer
One thing that I have noticed is that when people load a cluster via a program rather than IDCAMS, they tend to be extremely lazy by not sorting the input file into key sequence order. Not only does this tend to take longer in total than a load from a sorted file + the sort time taken, it is also a recipe for more splits than you find at a schitzos comference.
Recall once this happened and during the load the job blew out after about 40 minutes. Irate developer screaming "You told me how much space to allocate - you got it wrong, you don't know what your on about ..... blah blah blah". I took a look at the file and it was split to pieces. I sorted the input and then reran, the job took about 25 minutes and the file was pristine on completion well within the space estimate that I'd given him. Sending him an email to explain the situation was a joy 
Maybe this is the case here too |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
expat: Splits or every record written at maximum record length (or even both) -- the LISTCAT output will tell us. Presuming the COBOL file status is 24 per the message, the problem seems likely to be one of the two.
And sysprogs being shadier than an English summer? I doubt it. Maybe shadier than Seattle in the winter but not an English summer! 
sanjay: you need to give us something more than you have -- such as the LISTCAT output. How many records are being processed before the problem occurs (approximately -- we understand how the count can vary a bit from run to run)? Is your input file sorted in the same sequence as the VSAM file key? And why are you using shareoptions of (4,4) -- unless you have specific requirements for (4,4) you are much better off using the more standard (2,3)? This could be the proximate cause of the error you're getting if the file is DISP=SHR; you cannot add space to a (4,4) VSAM file unless you have DISP=OLD specified. |
|
| Back to top |
|
|
sanjay kumar tripathi
New User
Joined: 08 Jul 2008
Posts: 11
Location: chennai
|
|
|
|
Thanks robert for the help.
I changed the disp mode to OLD and now its working fine. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
| Good shot Rob, I never knew that. Thanks. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Thanks, expat -- I've run into that a time or two over the years. DISP=SHR and SHR(4,4) won't let you extend the VSAM file, even if there is secondary specified.
I still think there are other issues, but as long as the o/p is satisfied ... |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
| Quote: |
| but as long as the o/p is satisfied ... |
He will settle the invoice  |
|
| Back to top |
|
|
sanjay kumar tripathi
New User
Joined: 08 Jul 2008
Posts: 11
Location: chennai
|
|
|
|
You are right robert, now i am facing one new issue.
Even VSAM is getting populated with the records perfectly, now its not in sorted order. |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1205
Location: Dublin, Ireland
|
|
|
|
Records in a VSAM KSDS have to be in ascending key sequence. If what you're seeing is not sorted in the order you expect, then you have specified the key position incorrectly.
GArry. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| What do you define as "sorted order"? The file will be kept in key sequence, no matter how you sorted it for input. The key sequence is the first 25 bytes of the record according to your first post. What sequence do you expect the records to be in? |
|
| Back to top |
|
|
sanjay kumar tripathi
New User
Joined: 08 Jul 2008
Posts: 11
Location: chennai
|
|
|
|
For example, records are getting stored like this:-
GB1X605 09070111006006099999999990
GB1X605 09070111006006199999999990
MT0353DMLA090701010010000MT0353DMLA
MT0353DMLA090701020010000ADDRESS
MT8000LMLA090701020040000NAME
MT8000LMLA090701060010000
MT8000LMLA090701070010000
SA0015ARUH090701010010000SA0015ARUHI
SA0015ARUH090701020010000ADDRESS
But it shuld come in sequence of M,G and S |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Then your VSAM file definition is wrong. What is the actual key starting position and length supposed to be?
Assuming these are the first bytes of the records, they are sequenced as you specified in your first post -- G comes before M comes before S in the English alphabet, and that is how they are stored in the file. Further, MT0353 comes before MT8000 so these records are also sequenced as you specified in your original post. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| But it shuld come in sequence of M,G and S |
That may be some logical ordering, but it is not a collating sequence.
The system only works on the collating sequence (ebcdic for the mainframe) so the keys are in the proper order. Might not be what you want, but unless you change the record definition to include a prefix that will force the order you want, this is the order the sort will sequence the data and the order they will appear when inserted in a vsam ksds. |
|
| Back to top |
|
|
|
|
