Problems with EMC Networker

[Manny DeAssis]

Environment:
VMS 7.3-2 running EMC Networker OpenVMS Client (NOC) 7.3-4 ECO 1 (formerly LEGATO Networker). EMC Networker Server is running on Unix (Solaris) box utilizing the SAVEPNPC backup command to backup device group.

Problem:
Not sure what root cause is but it appears that pre-processing executes but backup/post processing does not. Only noticeable error is...

%SYSTEM-W-NOSUCHDEV, no such device available

This only happens when executing backup via GUI on Solaris. Last known good execution was at Networker version 6.0.1-D. Problem started at version 7.3. We upgraded 12 months ago to version 7.3-4 ECO 1. Problem persists.

Please advise.

[Steven Schweda]

I know nothing about EMC Networker, or about
exactly what you're doing where, but I'll
guess that you have some VMS process trying
to do some graphical thing, but no one has
done an appropriate SET DISPLAY /CREATE
command, so that there's no X/DECwindows
display device, hence %SYSTEM-W-NOSUCHDEV.

Perhaps this should be done in the user's
SYS$LOGIN:LOGIN.COM, or perhaps some
Networker procedure should be doing it, but
with my burden of ignorance on this software
and the way(s) you're using it, I'm unfit to
guess more.

Someone else may know more, or the product's
documentation may explain it. Otherwise,
something more detailed than "executing
backup via GUI on Solaris" may be needed.

[Manny DeAssis]

Actually the EMC Networker server runs on Solaris which is where the GUI is hosted from. The GUI is invoked via HTTP. The EMC Networker client (non GUI) is running on OpenVMS. All communication is between the server and client (as you would expect). We use SAN disk arrays (EMC Symmetrix DMX) and are backing up the BCVs (Business Continuance Volumes).

That being said our backups are done in groups and have to interact with the SAN. A group can comprise of several BCV devices. These devices are dropped from existing associations and prepped for backup via a pre-process step (written in DCL) that runs on OpenVMS.

After backup a post-process step (also written in DCL) is supposed to run. Something is happening either directly in pre-process or during backup (not sure). The post-process does not run unless there is operator intervention.

[Richard W Hunt]

We are running a Solaris 10 Networker Server with NOC on our OpenVMS 8.3.

First thing to look for is the log files that might be in NSR$LOG:SAVEPNPC.LOG to see if there are any useful details.

Next, look at the NSR$LOG:NSREXECD.LOG files to see if they show anything of interest.

Try also to look at SYS$SYSROOT:[NSR.RES].RES to see what the pre- and post-processing commands look like. Look for a timeout command that might be causing your post-processing commands to execute early in a way that becomes effectively useless if the files are still locked at the time.

Supposedly you can monitor this with NSRWATCH from the client side to see what is happening.

We use the GUI but don't use the PNPC option so I can't be more specific.

[Steven Schweda]

> Actually [...]

That's about as opaque as the original.

> The GUI is invoked via HTTP.

Does that mean that you use a Web browser to
run this "GUI"?

> [...] a pre-process step (written in DCL)
> that runs on OpenVMS.

I can't see that DCL from here.

> [...] a post-process step (also written in
> DCL) [...]

Can't see that, either.

> Something is happening either directly in
> pre-process or during backup (not sure).

Step one might be to try to figure out who
does what when. It can be hard to determine
the cause of an error message with no clue as
to the command(s) which produced it.

[Manny DeAssis]

Richard:

I cannot find the NSR$LOGS:SAVEPNPC.LOG but I've attached the NSR$LOGS:NSREXECD.LOG and the NSR$RES:. NSRWATCH.exe runs on the command line and displays session activity.

Steven:

First, yes the GUI is called from a web browser and I have included several files/command procedures that you can review.

The GUI calls a backup command (SAVPENPC) which calls the .res file and executes the precmd and pstcmd. There is a command procedure (NSREXT.com) in the precmd phase that creates a pre and post process command procedure. It also dismounts a BCV from each disk device so it can perform backups.

The pstcmd phase (supposed to run after the backup has completed) calls NSRADMIN.exe which reads it's input from QACLUSOFF.txt. I'm not sure of what else is happening behind the scenes. It would be helpful if I can set a verbose / debug flag to generate more information.

[Manny DeAssis]

I forgot to attach the NR$LOGS:NSREXECD.LOG so here it is.

[porcicasi]

Hello

Don't buy Networker.
Because this software not work properly.

Goog luck if you make backups with

[Siobhan Ellis HP]

If you get an error in pre processing or the backup, post processing does not run.

So, that error is coming from somewhere. See where it comes from, and make it go away.

The question around X was because it is oftena problem with systems that Xwindows is started, but there is no device and so that error shows up.

[Art Wiens]

Surely "bankofny.com" can afford a maintenance / support agreement with EMC. Engage them directly for meaningful help.

As far as verify / debug, unless the first attachment you provided is generated every time, that would be a good place to put in the SET VERIFY as it appears to be the place where the disks are made available to the program. What about tape drives? If it's similar to Data Protector, I assume Networker tells VMS which tape drive to use? Where does it do that? Are the tape drives visible to VMS? Maybe that's the NOSUCHDEV?

Where do you actually see the NOSUCHDEV error? It's not in the log you attached.

Cheers,
Art

[Richard W Hunt]

Until 2009Q3, we were on a similar configuration. We've since upgraded to VMS 8.3 vs. your 7.3-2 version but still use the latest version of Networker for OVMS/Alpha.

Our biggest problem was that we had to assure that our client nodes were visible via DNS lookup OR that the local HOSTS table had the client nodes named with a valid associated address. If our DNS went nuts, NETWORKER went nuts.

The "no such device" issue cropped up for us. Part of the fix there was a good exclusion list. But we had a bizarre configuration because we had a cluster and our security guys made us split it into two standalone nodes. So we had to apportion the disks between the systems. That meant that associations between the former cluster members had to change. Like, if DGA1535 was visible to one node, it had to be ignored for the other node (post-split). Attempts to touch a device you no longer owned, shared or had mount privileges on, usually failed miserably.

Having offered that list of ills, I have to say that once we got the network problems fixed and repopulated the exclusion list, we have not had problems.