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