IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Creating and using VSAM - KSDS in same JCL


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Dinesh Manivannan

New User


Joined: 17 Mar 2008
Posts: 17
Location: India

PostPosted: Thu Jul 18, 2013 2:43 pm
Reply with quote

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

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Thu Jul 18, 2013 2:59 pm
Reply with quote

Why not try it out and see what happens.

Did you find out what file status 48 means
Back to top
View user's profile Send private message
Gary McDowell

Active User


Joined: 15 Oct 2012
Posts: 139
Location: USA

PostPosted: Thu Jul 18, 2013 4:48 pm
Reply with quote

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

New User


Joined: 17 Mar 2008
Posts: 17
Location: India

PostPosted: Thu Jul 18, 2013 6:56 pm
Reply with quote

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

Moderator Emeritus


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

PostPosted: Thu Jul 18, 2013 7:34 pm
Reply with quote

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

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Thu Jul 18, 2013 8:30 pm
Reply with quote

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

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Thu Jul 18, 2013 9:47 pm
Reply with quote

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

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Thu Jul 18, 2013 10:11 pm
Reply with quote

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 icon_smile.gif .
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Thu Jul 18, 2013 10:58 pm
Reply with quote

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

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri Jul 19, 2013 12:09 am
Reply with quote

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

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri Jul 19, 2013 2:05 am
Reply with quote

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

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Fri Jul 19, 2013 4:46 am
Reply with quote

Try adding the VSAM Enhanced File-Status group-level to the FD -

ibmmainframes.com/viewtopic.php?p=313225&highlight=#313225

HTH....
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Mon Jul 22, 2013 1:27 pm
Reply with quote

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

Active Member


Joined: 31 Dec 2009
Posts: 580
Location: London

PostPosted: Tue Jul 23, 2013 12:30 pm
Reply with quote

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

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Jul 23, 2013 3:13 pm
Reply with quote

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

JCL Moderator


Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA

PostPosted: Thu Jul 25, 2013 2:17 am
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts Access to non cataloged VSAM file JCL & VSAM 18
No new posts Merge two VSAM KSDS files into third ... JCL & VSAM 6
No new posts Creating Unix Directory using COBOL i... COBOL Programming 2
No new posts Creating Report using SORT DFSORT/ICETOOL 7
No new posts CVDA value for RRDS VSAM dataset. CICS 2
Search our Forums:

Back to Top