File in use crashed the backup CPF3156 - How to find what held the file open

Check the job log of the backup for more messages that might explain the problem. The object is in use and the job log may say what job had the object locked.

For example, CPF32B3 would say something like this:

Message . . . . :   Cannot allocate object for file QCMDSRC in BLIB.          
Cause . . . . . :   The save operation was not performed for member CALC file
  QCMDSRC in library BLIB type *FILE, because it is allocated by job          
  069856/QSECOFR/QPADEV000G. Recovery  . . . :   Try the request again when  
  the object is available.                                                  

If you need more help, post back the job log!
Barry

If QINTER an QBATCH were down, perhaps there was a server job that allowed a client program (using ODBC or JDBC for example) to access the file.  If the job is QZDASOINIT or QZDASSINIT, then that is what happened.  You probably want to end these type of host server jobs (and other problem services like FTP) during your backups as well.

- Gary Patterson

What you can do (before starting the backup) is to claim the library by locking it exclusive.
 -  it will be locked and no program will be able to use it.
 - or if it returns with an error, one or more objects are in use.

When the library is in use, you can list what objects are invloved and whar jobs are locking these objects.
on that basis you can decide if you like to wait or kill the jobs.

tliotta - Your suggestion of ENDHOSTSVR *DATABASE how would I implement this? I have the backup setup through the i Series navigator.

Hi murphey2,

I totally new to CL programming, would you be able to guide me through setting this up or if there is a built in backup program that supports ENDHOSTSVR & STRHOSTSVR

Thanks, Joe

A "restricted state backup" is the simplest and safest way to do a backup.  Basically, you end the system down to "single user" mode (ENDSBS *ALL from the console), and then run your backup.  GO SAVE, Option 21 is a full system backup that ends the system to a restricted state before performing the backup.  Of course, this means that no other work will be allowed to run on the system for the duration of the backup, but it also ensures that things like object locks don't occur.

After the backup completes, you STRSBS QCTL (or whatever your controlling subsystem is), and the system restarts, typically ready for users.

AS/400 backup, as with any complex multi-user system backup process, has some complexities that it is important to understand if you are responsible.  A backup that you cannot restore from isn't very valuable.  It is really important that you take the time to either train yourself, get trained, or have an experienced AS/400 backup expert help you get your backups set up properly.

The Backup and Recovery Guide for your OS version is a great resource, and you should take the time to familiarize yourself with it's contents.  It will answer a lot of your Backup and Recovery related questions.

Here's a link to the V5R4 manual:  http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/books/sc415304.pdf

- Gary Patterson

I agree, but most of the time (on production systems) you only like to backup the production files daily and not make a full backup of everything.
At the customer site I work now, all production files are backedup daily, all user libraries (program libraries) weekly and a total save monthly.. I think that's not too bad?