Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

Job aparently freezze

Go to solution
Occasional Contributor

Job aparently freezze

There is a job on my Openvms 7.1-2 that executes a backup to tape. This backup usually need 3 tapes and, just after I put the third tape the process "freeze". There is no change in cpu, io, page faults, etc. Also, there is no error message and I have to stop the process.
Does anybody have an idea? Very thanks
Honored Contributor

Re: Job aparently freezze

Did the batch job (simply) finish here?

What are the commands involved?

Have you tried the BACKUP command sequence interactively?

What state (rwast?) is the process in when this happens?

Are the process quotas for the username running BACKUP set per the HP recommendations?

Do you have the patches for V7.1-2 loaded?

What has changed here?

Are any device errors logged?

Does having an operator enabled (REPLY /ENABLE) show any messages when the processing wedges?

Tried this with fresh tape media?

What's changed here?
Honored Contributor

Re: Job aparently freezze

What is the exact backup command please. What logs are generated by this job. Are the tapes labeled appropriately if required? Second Hoff's question, are there any operator messages queued?

If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Trusted Contributor

Re: Job aparently freezze


What does â process freezeâ mean?
Does that mean backup is not happening on third tape? Check the tape labels. If you are not concerned about the exact tape label, you can use /IGNORE=LABEL_PROCESSING qualifier. If you are concerned about the exact tape label use /EXACT_ORDER qualifier. Use /LOG qualifier in the BACKUP command. This will indicate whether the BACKUP is able to backup any files on to third tape or not.

Respected Contributor

Re: Job aparently freezze

Right, job status is crucial here. $ SHOW PROC/CONT/ID=pid and look at the PC and counters to see if they're changing. Check the active image for the process.

I usually don't say this often but V7.1-2 is somewhat aged. Is there a compelling reason for staying on that version and have the most recent patches (relatively speaking) been applied?

Knowing the BACKUP command string could help and the way that command is issued might also be interesting. Batch or interactive? Part of a BACKUP menu script? Part of either SLS or ABS? Seems to me that there might have been some issues with BACKUP "getting lost" during processing around the V7.1-2 timeframe, too. The utility has changed a LOT since then. BACKUP patches could be a necessity...

Honored Contributor

Re: Job aparently freezze


welcome to the OpenVMS ITRC forum.

If none of the previous requests for information has helped you diagnose your backup problem, please consider to use SDA to find out more information about the state of your BACKUP process:

SDA >SHOW PROC/CHAN ! look for busy channels
SDA> SHOW PROC/LOCK ! look for waiting locks

Consider to provide the output in an attached .TXT file to your next reply.


Occasional Contributor

Re: Job aparently freezze

Anwsering all of you:
- The command is:
$ Backup -
/BLOCK_SIZE=32255 /log /List
/Ignore=(InterLock,Label)/Media=Compac -
sngs_pro.rbf; mka600:sngsbkp.1904 /Save
- It usually takes 6 hours so it runs in batch
- The job state is LEF
- In the Show proc/cont NOTHING changes, except time (top right)
- Quotas: the job runs under system account
In the beginning 1 tape was enough, now we use tree tapes...
Sometimes the job finish ok, other times it freezes.
- No patches were load on OpenVMS 7.1-2
- There are no errors reported
- Operators use Reply/enable and receive the solicitation
to put a new tape
- I use new medias
- SDA: I will wait next "freeze occurrency" to use SDA.

I hope the information above can better clear the scenario.
Thank you all
Honored Contributor

Re: Job aparently freezze

The /log lists the files as processed, the /list is to provide a directory listing of the files in a save set. Remove the /list qualifier.

Based on the file name, I'll make the assumption that you're backing up an Oracle RDB backup file. Ignore the following if that's not correct.

When the backup job starts, the file should be completely written, so you don't need INTERLOCK in the /ignore qualifier. Can you confirm the RMAN process to write this file has completed when the backup is started?

If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Occasional Contributor

Re: Job aparently freezze

- /list qualifier will be removed
- /ignore=interlock will be removed
- The only file being backed up is really a Oracle RDB. We use Rmu/backup command to make a disk backup of our database and after that we make a OpenVMS backup to put the first backup on a tape. The first backup has certainly finished before the second starts.

The last five executions of backup routine ran fine (???).
I suppose that there are external reasons affecting backup job (like another job or user process), and I'll be care abaout.
The intriguing about this is that the system does not return anything. It just freezes...
Honored Contributor

Re: Job aparently freezze


may I also suggest, that you add the /REWIND qualifier to your backup command. This makes sure, that the backup actually starts at the beginning of the first tape. If NOT using /REWIND (note: /NOREWIND is the default !), backup would skip over all existing savesets on the tape and start writing your saveset after the last saveset found on tape.