Do system abends corrupt VSAM files?

psubra001 · New User Joined: 01 Feb 2006 Posts: 15

I am working with a system built on vsam files as backend.

There is a single program/module which updates 7 VSAM files for each transaction record. A backup of all these files are taken before this step is run. This step runs for 1 hour.

Now, when any abend occur in this step, we restore all these files from the backup and rerun the step again. The files are too huge that the restore runs for 2 hours.

I am trying to modify this in such a way that, when an abend occur, I ignore that transaction and conitue with rest of the transactions (instead of restore and rerun the whole process). Are there situations where a system abend corrupt VSAM files and thus demands delete-define and restore of those VSAM files for a successful process?

What are your thoughts on this?

William Thompson · Posted: Wed Feb 14, 2007 11:59 pm

A system abend can definitely corrupt VSAM files, but I think you are referring to an application abend, where the "single program/module" terminates abnormally, right?
With an application abend, things shouldn't become "corrupt" but they become out of sync, there is no guarantee that all 7 files were updated by the last transaction.
If the system abends, the internal tasks responsible for the internal VSAM structure may have been interrupted and that could corrupt the VSAM structure.

dick scherrer · Posted: Thu Feb 15, 2007 1:46 am

Hello,

Even if the vsam file(s) are not damaged/corrupted physically/internally, they may contain "corrupted" data. As Bill pointed out, it is likey that your data will be out of sync and therefore invalid.

To be sure you have a stable start/restart point, you want to restore the complete backup. To speed things up you might consider running the restore in multiple jobs with different jobnames that can run concurrently. If your current restore runs 7 steps serially, splitting them into 2 or 3 processes should speed things up considerably. If you have scheduling software you could make the job restart dependent on the successful completion of the reload jobs.

psubra001 · New User Joined: 01 Feb 2006 Posts: 15

All my restore jobs run parallel now. What I am trying to build here is a method below. In case of an abend,

1. Using expeditor, identify the transaction record that caused it.
2. Remove the out of sync created by this transaction record key.
3. Start the process with rest of the transactions.

ie. I plan to manage the out of sync created by the abend. Will this work in all cases? ie. for user abends as well as system abends? Will there be a situation that demands the delete/define of vsam file before I proceed? e.g of abends that I usually get is S0C4 S04E S0C7 SB37 SE37 SD37

dick scherrer · Posted: Thu Feb 15, 2007 9:24 am

Hello,

For starters, i'd make a LARGE investment in preventing the abends. This most likely means correcting both the problem job as well as jobs that create the data being used by the problem job.

If you have lots of production abends your question "will this work in all cases" is very difficult to answer. Do you have user abends as well as the system abends you referred to? Will you be able to identify clearly "where you are" at any given abend?

If you can identify exactly what should be retained and what was "in process" at the time of the abend you may be able to remove the problem data and continue the run (but please read on).

I'm not sure how you'll continue a run that ran out of space. All of the data created to that point will need to be kept (and added onto) for the remainder of the run - which will take even more space. Do the x37 abends occur on a vsam file or other file?

If there is any vsam corruption, you may not be able to return the file(s) to a stable point.

Very complex cleanup tasks that are different for each situation often cause more problems than they solve. Sometimes they also take longer than a restore/rerun.

How often is this job run?

What method is currently used to backup/restore the vsam files? There may be faster alternatives.

I'll look for your reply in my morning