Backup /NoAssist in Batch jobs.

[The Brit]

Hi Guys,
This is a continuation of an earlier post with a slightly different emphasis. In my earlier post I was interested in how to get to the "-F-" information in the

%BACKUP-E-FATALERR, fatal error on $2$MGA5:[]ND03.BCK;
-SYSTEM-F-PARITY, parity error

I have concluded that I can get by using the "BACKUP-E-" status and a "On ERROR then.." condition to trap it.

my next question is related to the result of this error, vis.

%BACKUP-I-OPERSPEC
%BACKUP-I-OPERASSIST, operator assistance has been requested

This backup job is running in Batch, and so there is no-one to respond to this. Looking at the Help, it tells me that "/NoAssist" will not help me here,

"The /NOASSIST qualifier has no effect if the logical name SYS$COMMAND points to a device that is not a terminal (as is the case when you run BACKUP in a batch job)."

So the real question is:-

Is there any point in adding the "/NoAssist" qualifier? And secondly,
If I put in a "On ERROR then GoSub ERROR_CHECK"

will the Error condition (and specified action) be triggered before the Operator Request, or will I still be stuck waiting for a response.

I suspect that the "On ERROR" Condition will precede the Operator call, and allow me to code some response. I was just hoping for some confirmation since this is a production script, and really don't have a way to reliably recreate the error (although you may tell me otherwise).

thanks

Dave.

[Volker Halle]

Dave,

the BACKUP image remains running when issuing the %BACKUP-I-OPERASSIST message. It does not exit and you cannot do anything at DCL level in this process to detect and handle this situation.

Volker.

[The Brit]

Volker,
This is terrible news, and totally non-intuitive. What you are telling me is that,

Even if I have the "On Error" condition set, it will be ignored, and I will end up at the same point, i.e. The script will still be stuck waiting for a response from a non-existant operator.

It will not matter if I set

"On ERROR then EXIT"

While I recognise your expertise in this area, I find it hard to understand how such a situation could be allowed to exist. There must be a way to respond to this error within DCL, or for the script to terminate.

Do you know of any reason why this behavior would be desirable?, particularly within a batch job.

Dave.

[The Brit]

Is there any way to avoid the Operator request in this situation. (i.e. when running as a batch job)

Dave.

[Volker Halle · Accepted solution]

Dave,

what do you expect backup to do, when intervention of a real operator is required (i.e. backup needs the next volume to be put into the tape drive) ? If something like a tape loaded is present, you may see such a message while backup waits for the tape to be automatically loaded.

If there is no terminal enabled as a TAPE class operator, backup will abort with the 'NOOPER, no operator is available to handle the request' message. That is something you can try to handle at DCL level.

Did you experiment with $ DEFINE/USER SYS$COMMAND OPA0: (or LTAx:) preceeding a $ BACKUP/NOASSIST ?

Volker.

[The Brit]

Thanks for the suggestion Volker,

I understand your point regarding the need to have operators insert additional tapes, etc., however in this case, it is in response to an "abnormal" condition, and I would have thought the system might be smart enough to know the difference. Perhaps I am just too used to OpenVMS being able to do just about anything.

In this particular situation, even if there was an operator present, I don't think he/she could do except terminate the job anyway.

Regarding your suggestion: Is this intended to trick the system into believing that SYS$COMMAND is actually a Terminal, and therefore it should take notice of the "/NoAssist" qualifier?

finally, if it works, what status should I expect to get back. From the discussion in my earlier post, I suspect it will return either a -W- or -I-, which will make it more difficult to trap. (however I will accept any opening)

thanks

Dave

[Hoff]

Batch is intended to (always) ask for help.

What I'd try here: aim SYS$COMMAND (DEFINE /USER) at a handy pseudo-terminal within the batch procedure, specify BACKUP /NOASSIST and run a test or three, and move along.

The other option here (equally brute-force, all documented interfaces, but somewhat more coding work) is to write up a sys$sndopr daemon that says "QUIT" when it receives an OPCOM from a batch job running BACKUP.

There can be secondary discussions here around the increasingly constrained and fragmented nature of the available management, command, communications and control interfaces. This is one manifestation. There are others.

Stephen Hoffman
HoffmanLabs LLC

[Art Wiens]

An unattended backup on one of our test systems behaves "properly" for us. This system is regularily wanting a second tape but no operators log into this system ie. no sessions that have done a REPLY/ENABLE. The backups "fail" as desired:

28-FEB-2008 23:57:57.67 : Backing up $1$DGA93:
%BACKUP-I-RESUME, resuming operation on volume 2
%MOUNT-I-OPRQST, medium is offline
%MOUNT-I-OPRQST, Please mount volume 080202 in device _$2$MGA0: (node)
BACKUP requests: Saveset MTRX03_080228., Volume number 02, write ENABLED
%MOUNT-F-BATCHNOOPR, no operator available to service batch request

The command procedure has this just before issuing the BACKUP command:

$ ON SEVERE_ERROR THEN GOTO DISK_ERROR

Catches the -F-.

Cheers,
Art

[Art Wiens]

Perhaps I should show our command as well:

$ BACKUP -
'DISK' -
$2$mga0:'DISK_LABEL'_'TAPE_LABEL' /SAVE_SET -
'BACKUP_PARAMETERS' -
/IMAGE /BLOCK=32256 /IGNORE=(INTERLOCK,LABEL) -
/NOCRC /NOINITIALIZE /MEDIA_FORMAT=COMPACTION -
/LABEL='TAPE_LABEL' -
/JOURNAL=SYSMGRC:'DISK_LABEL'_'TAPE_LABEL'.BJL

'BACKUP_PARAMETERS' is simply /REWIND or /NOREWIND as this is in a loop backing up multiple disks.

Art

[The Brit]

Art,
you say that there are no terminals where a reply/enable has been executed. Does this mean that you have OPA0 disabled?

Dave

[Art Wiens]

This system has a KVM on it ie. console is in graphics mode running Decwindows (but no one logged in there). I'm not sure if that constitutes OPA0 as "disabled" ... I can show terminal OPA0 and it's there. Opcom (the process) is running.

Art

[Volker Halle]

Dave,

it should be sufficient, to disable some operator classes on OPA0:. Backup sends this operator request to CENTRAL, DEVICES, TAPES and DISKS operator classes, so if you would issue a REPLY/DISABLE=(CENTRAL,DEVICES,TAPES,DISKS) on OPA0: you would still get the rest of the operator messages, but backup will fail/exit with %BACKUP-F-NOOPER.

You can set up an OPC$OPA0_CLASSES logical in SYLOGICALS.COM to specify the desired OPCOM class for OPA0: during startup.

Volker.

[Hoff]

The presence of a KVM is not relevant, save for corner cases such as what happens when an OPCOM storm arises.

One of the easiest ways to see if an operator is active (somewhere) in the cluster is:

REQUEST /REPLY "ignore me"

If that pauses, you have an operator. (You can then tailor that command to test for the operators enabled for the specific operator classes of interest, too.)

You could go look for operator flags on the devices, but that's (more) work.

Most folks disable the console as an operator (usually via SYLOGICALS.*, though also via the older DEFINE and REPLY/DISABLE two-step), but there are a number of systems with the console enabled as an operator.

Stephen Hoffman
HoffmanLabs LLC

[Jess Goodman]

Here's a little command file that lists enabled operator terminals on the current system. You can run it from SYSMAN to check an entire cluster.

$! Lists currently enabled opertor stations
$! V1.0 September 1987 Jess Goodman
$! V2.0 April 1993 Jess Goodman - Modified to use F$DEVICE
$ WRITE SYS$OUTPUT -
"Username Process Name PID Operator Terminal"
$LOOP:
$ DEVICE = F$DEVICE(,"TERM") !Check all terminal devices
$ IF DEVICE .NES. "" !At end of list?
$ THEN !No, check it
$ IF F$GETDVI( DEVICE, "OPR")
$ THEN
$ PID = F$GETDVI( DEVICE, "PID")
$ USERNAME = F$GETJPI( PID, "USERNAME")
$ PRCNAM = F$GETJPI( PID, "PRCNAM")
$ NC = F$LEN(PRCNAM)
$ PRCNAM[NC,18-NC] := " " !Blank fill
$ PORT = F$GETDVI( DEVICE, "TT_ACCPORNAM")
$ IF PORT.NES."" THEN PORT = "("+PORT+")"
$ DEVICE = F$GETDVI(DEVICE,"DEVNAM") - "_" !Get rid of _node
$ NC = F$LEN(DEVICE)
$ DEVICE[NC,9-NC] := " " !Blank fill
$ WRITE SYS$OUTPUT USERNAME, " ", PRCNAM, PID, " ",DEVICE, PORT
$ ENDIF
$ GOTO LOOP
$ ENDIF
$ EXIT

[John Gillings]

Dave,

Maybe I've missed something here... I can't figure out what you're trying to achieve or under what circumstances. I'm looking for the "big picture", not in terms of BACKUP return statii.

You're starting an unattended backup job, then something happens (?) and you want your procedure to respond (?)...

[The Brit]

Hi John,
The basic problem is that; During a backup of multiple disks, running in batch, a Fatal Parity error occurs (which seems to be related to a bad tape, since it is reproducable using the same tape.). Instead of "bombing out", the backup command then goes to a

%BACKUP-E-FATALERR, fatal error on $2$MGA5:[]ND03.BCK;
-SYSTEM-F-PARITY, parity error
%BACKUP-I-OPERSPEC
%BACKUP-I-OPERASSIST, operator assistance has been requested

Of course, there is no Operator to respond to this, and even if there was, all they could probably do is to terminate the job.

My problem is/was that I couldn't use the "On Error..." syntax to trap the problem because the Backup Image is still running until the operator responds with a "quit". In addition, I couldn't get past the Operator Request, because the script is running in batch.

I am pleased to say that thanks to Volker's suggestion (define/user SYS$COMMAND OPA0:), I am now able to get past the Operator Request, and also use the "On ERROR..." syntax to trap the problem.

Since I am using an MSL5000 tape library, I can now have the script remove the defective tape, store it back in an available slot, grab and load a spare tape, and restart the backup at an appropriate place.


Dave

[The Brit]

Thanks for all your help Guys, the suggestion made by Volker (and Hoff) allows me to move forward with dealing with the problem. vis.

Define/User SYS$COMMAND OPA0:

This generates an Image dump as follows;

$ On ERROR then goto ERROR_CHECK
$!
$ Define/User Sys$Command OPA0
$ Backup -
/Image -
/NoAssist -
/NoCRC -
/Density=SDLT -
/Ignore=(Label,InterLock) -
DSA101: $2$MGA1:OpenVMS.Bck/Save_Set


%BACKUP-E-FATALERR, fatal error on $2$MGA1:[]OPENVMS.BCK;
-SYSTEM-F-PARITY, parity error
%BACKUP-F-ABORT, operator requested abort on fatal error
-RMS-E-FNF, file not found
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000848, PC=00000000000F0ECC, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
: : :

: : :
SP = 000000007AE25AC0 PC = 00000000000F0ECC PS = 000000000000001B
%BACKUP-F-LABELERR, error in tape label processing on $2$MGA1:[]OPENVMS.BCK;
-SYSTEM-F-PARITY, parity error
$ ERROR_CHECK:
$!
$ Write sys$output $Severity," ",$Status
4 %X10A3810C

Although the Image dump is ugly, It does allow me to get to the ERROR_CHECK label where I can deal with the problem.

Thanks to all.

Dave