You can intercept the message if you have a Break Handler.

I did this for a client recently. It does error handling for (I think) all jobs.

If you have COZTOOLS, you can run the SRVINSTALL program to install one, but it calls:

ADDEXITPGM EXITPNT(QIBM_QMH_HDL_INQEXT) +    
             FORMAT(INQE0100) PGMNBR(*LOW) + 
             PGM(COZTOOLS/SRVPANEL)          

The called progam can retrieve JOB attributes and the message and then make a decision as to whether to swallow it or do something else.

Thanks for the tip, Bob. I was just thinking though, couldn't I just change the files to USROPN then open them with OPEN (E) and just exist the program if I receive an error? I don't really have to do any processing if it can't open the files. I just exit and try again next time.

Sorry, I misread your post. I thought you had a backup procedure giving you a break message.

Yes, just do an ALCOBJ before you call your task and if it works, fine, if not then you can't continue.

I reckon the USROPN option is something to pursue. If you close the file after each time you're through with it and then open it again prior to next use, you'd get an error if the file would be locked by the backup. If the error occurs, you run a delay or whatever you want to do to handle it before you try opening the file again. No error means it's free to continue. There is the obvious issue of extra overhead for closing and opening the file all the time so I'd try record blocking of some sort.

You could easily create a little test-program with the above logic and using a file you know will be backupped and then you run it during the night to see if it does as suspected.

Good luck!

Paulster