RMS-F-WBE, error on write behind

[Fernando Vallarino]

When I try to back up one Rdb database, I´m obtaining theese messages.
-RMS-F-WBE, error on write behind
-SYSTEM-F-OPINCOMPL, operation is incomplete
I can't find any info about them.
I'm backing up the database from one EVA raid-5 volume to other in the same storage.
Backing it up to other EVA produces the same result.

Thanks in advance.

[Hein van den Heuvel]

I can tell you what the error shoudl mean, but not what caused it.
It means that a program used RMS $PUT record IO to with 'Write Behind' enabled. Thus when a buffer is filled, a write Io is started but not waited for. If there is an IO error, then there is no good place to report it. Eventually, typically when the file is closed, the error is reported as RMS$_WBE

To better help you, you need to tell us WHAT COMMAND you are using to make the backup?

RDB tool? Copy? BACKUP? ZIP ?...

Are there hardware error reported?

What buffers sizes/buffer count is used?
($SHOW RMS ?)

Good luck!
Hein

[Fernando Vallarino]

Hein,
I'm using one RDB tool, RMU/BACKUP specifically.
There are no reported hardware errors.
Here is the output of SHOW RMS:
$ show rms
MULTI- | MULTIBUFFER COUNTS | NETWORK
BLOCK | Indexed Relative Sequential | BLOCK
COUNT | Disk Magtape Unit Record | COUNT
Process 0 | 0 0 0 0 0 | 0
System 32 | 0 0 0 0 0 | 8

Prolog Extend Quantity QUERY_LOCK
Process 0 0 System
System 0 0 Enabled

CONTENTION_POLICY
Process System
System Never

Fernando.

[Jur van der Burg]

OPINCOMPL is a low-level error probably coming from the scsi drivers. This means that the storage controller returned that it actually wrote less bytes than what was requested. Have your storage checked out.

Jur.

[Fernando Vallarino]

Jur,
I can understand that, but there are not errors reported.

[Hein van den Heuvel]

My (our :-) source at Oracle confirms that RMU/BACKUP uses plain RMS $PUT's.

He indicates you should first and formost check all exact versions, patch levels and apply the most recent patches if at all possible.

So is this a first attempt? Did this ever work? What changed? New type of output devices? More volume? Different load? New disk init parameters (clustersize, HWM...)

While the error should indicate a hardware issue, the fact that you get the error on multiple volumes suggests it might be software. Bad HDA, Switch? Tried a local disk?

The show RMS indicates nothing special. That ought to work, albeit none-optimal. I forgot to ask whether RMS sets non-default RMS options, as it probably would(should!) in whcih case the RMS params are over-ruled.

I would check with ANAL/SYS .. SET PROC ... SHOW PROC/RMS=(FAB,RAB,BDBSUM) whether it sets explicit ALQ, DEQ, MBF, MBC. If those are 0, then try for example: $SET RMS/BUF=4/BLOCK=127/EXT=64000

Not that is there is any good reason why this would make the problem go away, but you newr know. It might change timings.

fwiw,
Hein.

[Jur van der Burg · Accepted solution]

You will not see these errors logged on VMS. The controller may show them though, but if it does not I would not be surprised. Have the storage checked out.

Jur.

[Volker Halle]

Fernando,

you may be able to use the SDA extensions IO$SDA or DKLOG$SDA to try to capture information about the IO, which failed.

Volker.

[Fernando Vallarino]

I've tried redirecting all I/O operations trough other path and all worked fine. So the trouble is with fiber or GBIC or SAN switch. Our support is working on that.
Sorry about my apparent absence.
Regards, Fernando.

[Fernando Vallarino]

We have replaced a fiber patch and now everything works normally.

Thanks to all of you.
Best regards, Fernando.