Mainframe, MVS and zOS Discussion

Hi,

Whenever we allocate a VSAM dataset using IDCAMS it is told to initialize the file before we can use it in a COBOL program. Why it is so, could anybody tell why this is required?

And if it is required why IDCAMS itself can not do this?

VSAM distinguishes between an empty data set (that is, one which has never had a record in it) and a data set with no records (for example, adding a record to a KSDS and then deleting it). The difference is that for each write to a VSAM data set, a pointer is updated to reflect the highest used RBA. If you have never written any data to the data set, this pointer has no value and hence causes VSAM problems when attempting to use it to locate the end of the used data. This is not something unique to COBOL -- any program attempting to open a VSAM data set for input before anything has been written to the data set will have a problem.

Yes, IDCAMS could have been updated to write data to a new VSAM data set, but IBM does not generally change established behavior of programs (except slowly and over years). At some point in the future I could see an option added to DEFINE to allow the pointer to be updated, but until then just get used to the behavior and always write something to a VSAM data set before attempting to open it for input or I-O.

So every program written in any language for mainframe, tries to read a newly created VSAM, it will have problems?

Why are you asking a question that has already been answered before you asked? What is unclear about Robert's reply?

any program attempting to open a VSAM data set for input before anything has been written to the data set will have a problem.

The whole premise is rubbish.

There is one "problematic" situation: a KSDS that is opened for input. If that KSDS has never contained data since it was DEFINEd, then you will get a file-status of 35 on the OPEN INPUT, and only OPEN INPUT, in COBOL.

Now, if someone can explain the use of opening a KSDS for input that has never had any data...

Yes, it is one of those wildly prevalent misconceptions which waste time and cause confusion, but questioning it is met with "we've always done it that way" or some woolly "but I had a problem with that 13 years ago and doing this fixed it".

It is all stuff-and-nonsense.

If you never do it, you'll only have a problem when your KSDS is empty-as-in-never-had-records-on-it. I feel that is a situation you'd like to know about, and specifically discover why that is the case, rather than avoid it and find out eight months later that you could have spotted an otherwise subtle problem immediately.

William Collins wrote:The whole premise is rubbish.

There is one "problematic" situation: a KSDS that is opened for input. If that KSDS has never contained data since it was DEFINEd, then you will get a file-status of 35 on the OPEN INPUT, and only OPEN INPUT, in COBOL.

Now, if someone can explain the use of opening a KSDS for input that has never had any data...

Yes, it is one of those wildly prevalent misconceptions which waste time and cause confusion, but questioning it is met with "we've always done it that way" or some woolly "but I had a problem with that 13 years ago and doing this fixed it".

It is all stuff-and-nonsense.

If you never do it, you'll only have a problem when your KSDS is empty-as-in-never-had-records-on-it. I feel that is a situation you'd like to know about, and specifically discover why that is the case, rather than avoid it and find out eight months later that you could have spotted an otherwise subtle problem immediately.

Perhaps the premise is rubbish but my intention was to know, why would that happen? One answer which I get is, "it's by design" but I thought there can be an intelligent rational behind it all.

One example of opening an empty KSDS can be when a program wants to read a file which is created or maintained by other system. That time you don't know if the VSAM is empty. But it should happen only when the program executes first time, but we still check for the VSAM status code all our life, right?

But your job should be scheduled to run after the job that writes that data. If it fails because the data has not yet been written to the dataset then you know that you have made a mistake.

When you take data from another system, don't you do anything to check to check that you have a correct dataset? If you suddenly get an "empty" KSDS, how do you know you have the correct dataset?

"VSAM initialisation" is not required for COBOL, or any other language.

It's a bag-o'-crap, the whole idea. However, I fully understand, since I've had the conversation "more than once" that intransigence and inbuilt-inertia with "seniors" will mean you get nowhere fast trying to change it. It is an entirely dumb waste of resources, but you'll probably have to do it.

Tanu Banerjee wrote:One example of opening an empty KSDS can be when a program wants to read a file which is created or maintained by other system. That time you don't know if the VSAM is empty. But it should happen only when the program executes first time, but we still check for the VSAM status code all our life, right?

You realize that there are other status codes that can be generated, yes?

One example of opening an empty KSDS can be when a program wants to read a file which is created or maintained by other system. That time you don't know if the VSAM is empty. But it should happen only when the program executes first time, but we still check for the VSAM status code all our life, right?

If you do something like this you will have bigger problems than a return code. This can result in read-integrity problems where updated information is not reflected in the catalog and programs may miss records. If updating is involved, you'll likely destroy the file.