|
View previous topic :: View next topic
|
| Author |
Message |
Dinesh Manivannan
New User
Joined: 17 Mar 2008
Posts: 17
Location: India
|
|
|
|
Hi All,
Can we create VSAM - KSDS file in first step and second step uses it as output file [open mode I-O & DISP=SHR]?
When I tried to write a record into this file, I got VSAM status code as 48. |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
Why not try it out and see what happens.
Did you find out what file status 48 means |
|
| Back to top |
|
|
Gary McDowell
Active User
Joined: 15 Oct 2012
Posts: 139
Location: USA
|
|
|
|
From Google search - Status Key Value 48...
The execution of a WRITE statement was
attempted on a file not open in the I-O,
output, or extend mode. |
|
| Back to top |
|
|
Dinesh Manivannan
New User
Joined: 17 Mar 2008
Posts: 17
Location: India
|
|
|
|
Thanks for the reply.
I googled and got the reason for file status 48.
I tried two ways:
First method:
1) Had two JCLs. One for creating the vsam file and other for executing the program.
2) Program will just write a record into vsam file created by first JCL. File opened in I-O mode.
Result: Record written to vsam file sucessfully
Second menthod:
1) Had only one JCL with two steps. First step will create the vsam file and second step will execute the program.
Result: File status returned as 48, though I did not make any changes to the program [vsam file opened in I-O mode]
This is the reason behind my posting. I need to know why the second method did not succed. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
A "best practice" is to add a record to a VSAM file as soon as it is defined. Then opens will not fail. If it is not needed, the first record can then be deleted.
Some systems add a ZEROs or a NINEs record and just leave it in the file, bypassing it when processing the data in the fle. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| VSAM distinguishes between an empty file and a file that has never had a record in it. An empty KSDS file has had at least one record placed in it and then deleted. The difference to application processing is that an empty VSAM KSDS file can be opened INPUT or I-O whereas a VSAM KSDS file that has never had a record in it CANNOT be opened for INPUT nor I-O processing, as you found. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| I don't like the idea of leaving the record lying around after it has done its job. I've not done it, but people seem to think that if you leave a "high key" as the first record on the file, you're asking for trouble with countless "splits" as you add the data. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
The VSAM Demystified Redbook now says this on page 17, section 1.4.10:
| Quote: |
| Keep in mind that splits are not that bad. The occurrence of a split can worsen the performance, but each subsequent split decreases the probability of having another one. Splits are how VSAM deals with a lack of space, and the process generates free space that helps prevent more splits. |
The days of being able to walk a disk drive across the computer room floor are long gone  . |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Yes, but the thing would be, if we imagine sequential inserts in key order, a split every few inserts and about 50% of 99.999999% of CIs being freespace, plus the initial work of effectively writing that last record every few records, and the stuff which goes with that.
Anyway, I'm not sure how often a file would genuinely be loaded like that. I think the example someone was quoting was from the same Redbook, but I'll try to check later. The "resolution" didn't make much sense on the face of it either :-) |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
The numbers don't look too bad. I created a VSAM KSDS with attributes of
| Code: |
INDEXED -
RECORDSIZE(4080 4080) -
SHAREOPTIONS(2 3) -
KEYS(10 0) -
FREESPACE(0 0) - |
and data CISZ of 4096 (as I usually do, I let the index CISZ default -- let VSAM do the math). I copied in one HIGH-VALUE record (4080 bytes of X'FF'). The LISTCAT looked as expected.
I then loaded 10,000 records with sequential keys from 0000000001 to 0000010000 into the file and did another LISTCAT. 56 CA splits, no CI splits:
| Code: |
REC-TOTAL----------10001 SPLITS-CI--------------0
REC-DELETED------------0 SPLITS-CA-------------56
REC-INSERTED-------10000 FREESPACE-%CI----------0
REC-UPDATED------------0 FREESPACE-%CA----------0
REC-RETRIEVED----------0 FREESPC----------1060864
ALLOCATION
SPACE-TYPE------CYLINDER HI-A-RBA--------42024960
SPACE-PRI--------------1 HI-U-RBA--------42024960 |
|
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
That's very intteresting.
Not what I'd have expected (I don't know exactly what I would have expected, but not this).
Just the 56 cylinders used?
CI "fills", is "split" into approximately equal. New key always inserted immediately before the high key.
Very interesting. I've definitely missed something :-) |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
| Bill Woodger wrote: |
| I don't like the idea of leaving the record lying around after it has done its job. I've not done it, but people seem to think that if you leave a "high key" as the first record on the file, you're asking for trouble with countless "splits" as you add the data. |
I always used low values, however once the record has been written it can be erased again. |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 592
Location: London
|
|
|
|
We've always added a high-value record and then immediately deleted it using the old VSAMINIT program that can be download free from the interweb. It probably doesn't matter whether it is a high or low value as long as it's deleted afterwards. The effect is to format at least one CI, which VSAM does during loading. This means CICS is happy to open the file.
One thing to be careful of using JCL to allocate VSAM is there are some values you can't pass as JCL keywords such as SHAREOPTIONS. If you have an appropriate Dataclas set up with these values and specify the Dataclas in the JCL it can overcome that. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| One thing to note: JES2 and JES3 work differently for this. JES3 allocates data sets at the beginning of the job, so using IDCAMS to define a VSAM KSDS in step 1 will prevent that JCL from using the same VSAM KSDS. |
|
| Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008
Posts: 1248
Location: Richfield, MN, USA
|
|
|
|
| A problem with leaving a "dummy" record in the file is that all it takes is for ONE program to fail to take into account the existence of that record. My preference would be to delete it immediately after it's served its purpose. |
|
| Back to top |
|
|
|
|
