- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Job aparently freezze
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2010 09:39 AM
04-14-2010 09:39 AM
Does anybody have an idea? Very thanks
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2010 11:27 AM
04-14-2010 11:27 AM
Re: Job aparently freezze
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2010 11:42 AM
04-14-2010 11:42 AM
Re: Job aparently freezze
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2010 07:35 PM
04-14-2010 07:35 PM
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.
Regards,
Ketan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2010 08:05 PM
04-14-2010 08:05 PM
Re: Job aparently freezze
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...
bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2010 11:01 PM
04-14-2010 11:01 PM
Solutionwelcome 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:
$ ANAL/SYS
SDA> SET PROC/ID=
SDA> SHOW PROC
SDA >SHOW PROC/CHAN ! look for busy channels
SDA> SHOW PROC/LOCK ! look for waiting locks
SDA> EXIT
Consider to provide the output in an attached .TXT file to your next reply.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2010 09:47 AM
04-19-2010 09:47 AM
Re: Job aparently freezze
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2010 10:56 AM
04-19-2010 10:56 AM
Re: Job aparently freezze
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2010 11:53 AM
04-19-2010 11:53 AM
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2010 10:28 PM
04-19-2010 10:28 PM
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.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-20-2010 02:29 PM
04-20-2010 02:29 PM
Re: Job aparently freezze
As Volker suggested, use the /REWIND qualifier. Since this backup is taking multiple tapes anyway, I can't think of any reason to append to any previous tape. Also, without it the use of /media=compaction will be ignored (at least for the first tape).
You stated you are using new media. I would expect that to work, but there may have been some bugs with backup from 7.1-2 with continuation volumes not being initialized. See $help backup /label for a description of what Backup will do if a label isn't specified.
Try this:
1. Before backup starts, initialize your tapes, each with a unique 6-character label (I would also put a paper label with that label printed in the slot in the tape cartridge. (What type of tape drive is this? DLT, DAT, something else? Please specify model number). The output of show device/full mka600: should provide a clue (at least in VMS versions from the last 10 years or so, I am not sure if 7.1-2 did).
2. In the backup command, use /LABEL=(label1,label2,label3)/exact_order/rewind [/tape_expiration=date] [/media_format=compaction] [/protect=(S:RWED,...)]. The combination of /label and /exact_order causes VMS BACKUP to verify that the correct tapes are used, and that all 6 characters of the label are significant. This prevents mistakes, like putting the same tape back into the drive and overwriting it with a continuation volume. /TAPE_EXPIRATION allows you to specify a date that you want to save the tape until, before allowing BACKUP to overwrite it. (This is a blade guard, and can be overridden). The /media_format /protect and /density are used when initializing and rewriting the tape headers.
3. I would use /BLOCKSIZE=32256 or 31744 instead of 32255 (which will be rounded down to the previous multiple of 512, or 31,744). This is just so the qualifier is consistent with the actual value that is used.
4. If you use list, I would recommend having it go to a file. I.e. /list=backup_lst:sngsbkp_1904.lis There is no problem with using /list while the backup is being made. Since this backup will have
5. /SAVE is default for tape save sets, but specifying it definitely causes no harm, and removes any doubt as to what is being written.
Example:
$! init tapes. This only has to be done the first time you use a tape (and define its tape label)
$! put in second tape
$ init mka300: rbf002 /own=system /prot=(s:rwed,o:rwed,g,w) /media=compaction
$! put in third tape
$ init mka300: rbf003 /own=system /prot=(s:rwed,o:rwed,g,w) /media=compaction
$! put in first tape
$ init mka300: rbf001 /own=system /prot=(s:rwed,o:rwed,g,w) /media=compaction
$
$! now do the backup...
$
$ Backup -
/BLOCK_SIZE=32256 /log /List=sngsbkp_1904.lis /rewind -
/Media=Compact /label=(rbf001,rbf002,rbf003) /exact_order -
sngs_pro.rbf; mka600:sngsbkp.1904 /Save /tape_expiration=1-jan-2011 ! example of tape_expiration
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-20-2010 05:39 PM
04-20-2010 05:39 PM
Re: Job aparently freezze
A hardware problem with a tape drive can ruin your whole day.
Also check that all cables to your tape drive are seated properly. The fact that the backup runs sometimes but not others is curious, so we need to look for possible intermittent faults.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-22-2010 11:40 AM
04-22-2010 11:40 AM
Re: Job aparently freezze
I think that there are enough hints to hold this problem so I'm closing this thread.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-22-2010 11:41 AM
04-22-2010 11:41 AM