I don't believe you can jump from the 6.0 tree directly to 6.5.4.  You'd first have to install 6.5GA from a VMS CD, which means getting the media (or maybe we put it on FileConnect as well?  I have to admit I'm a little weak on the VMS client.)

The latest 6.0 maintenance pack for VMS is 6.0 MP7:
 ftp://ftp.emea.veritas.com/pub/support/Products/NetBackup_OpenVMS/

I unziped the file NB_VMS_6_5_4.zip, copied the files bpcd_axp.exe nbu_axp.exe nbuaxpmsg.exe and BPCD_STARTUP.COM to the directorie NBU$DIR and the client is working.

NBU> sho ver
%NBU-I-VERSION, Veritas NetBackup OpenVMS Client V6.5.4
NBU> sho client
%NBU-I-CONNECT, connect to xxx
%NBU-I-CONRECV, connection from xxx

Product: NetBackup
Protocol Level: 6.5.4
Version Name: 6.5
Version Number: 650000
Patch Level: 6.5.4
Client OS/Release: OpenVMS 6.2-1H3
Client Hardware: AlphaServer 800 5/500
Installation Directory: $48$DKB0:[OPENV.NETBACKUP]

Peter

You have to install 6.5GA from CD first and do an upgrade to 6.5.4, otherwise it will not work!

Thanks very much for all your posts. I have tried installing 6.5GA (which works just fine) then copying the 6.5.4 files on top of them, but I still get the same problem, it hangs before getting me to the NBU> prompt. Typing Ctrl-T tells me I am running the BPCD_AXP image:

ALF> nbu
ALF::_RTA2: 18:27:17 BPCD_AXP CPU=00:00:02.35 PF=9133 IO=31401 MEM=290

The NBU$LOGS:20090715 file tells me that I am at least getting this far:

18:27:16 [2383ED88] --------------------------------------------------------------
18:27:16 [2383ED88] %NBU-I-VERSION, Veritas NetBackup OpenVMS Client V6.5.4
18:27:16 [2383ED88] %NBU-I-LOGTRAN, "SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM.CANADA]PACIFIC."
18:27:16 [2383ED88] %NBU-I-TZGMTOF, timezone PDT offset from GMT -25200 secs
18:27:16 [2383ED88] %NBU-I-LOGTRAN, "NBU$TIMEZONE_DIFFERENTIAL" (not defined)

SET WATCH tells me that the last file I accessed was the timezone file SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM.CANADA]PACIFIC.

I wonder what NBU is trying to do next? Can anyone tell me what they see next in the NBU$LOGS:yyyymmdd file when they type NBU? Also, are any of you running the MultiNet TCP/IP stack?

Cheers,

Howard Taylor

I did the same wit h the V6.5.4 client and it simply logged the following:

16:29:55 [00000E58] --------------------------------------------------------------
16:29:55 [00000E58] %NBU-I-VERSION, Veritas NetBackup OpenVMS Client V6.5.4
16:29:55 [00000E58] %NBU-I-LOGTRAN, "SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM.AUSTRALIA]SYDNEY."
16:29:55 [00000E58] %NBU-I-TZGMTOF, timezone EST offset from GMT 36000 secs
16:29:55 [00000E58] %NBU-I-LOGTRAN, "NBU$TIMEZONE_DIFFERENTIAL" (not defined)

I then dropped our of NBU and back in again and did a NBU SHOW VERS  which logged the following:

16:30:24 [00000E58] --------------------------------------------------------------
16:30:24 [00000E58] %NBU-I-VERSION, Veritas NetBackup OpenVMS Client V6.5.4
16:30:24 [00000E58] %NBU-I-LOGTRAN, "SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM.AUSTRALIA]SYDNEY."
16:30:24 [00000E58] %NBU-I-TZGMTOF, timezone EST offset from GMT 36000 secs
16:30:24 [00000E58] %NBU-I-LOGTRAN, "NBU$TIMEZONE_DIFFERENTIAL" (not defined)
16:30:27 [00000E58] %NBU-I-NBUCMDL, show vers
16:30:27 [00000E58] %NBU-I-VERSION, Veritas NetBackup OpenVMS Client V6.5.4
16:30:29 [00000E58] %NBU-I-NBUCMDL, show client
16:30:29 [00000E58] %NBU-S-BINPORT, bind port 1023 success (0.0.0.0)
16:30:29 [00000E58] %NBU-S-BINPORT, bind port 1022 success (0.0.0.0)
16:30:29 [00000E58] %NBU-I-CONNECT, connect to xxxx (aa.bb.cc.dd,13782)

and returned:

%NBU-I-VERSION, Veritas NetBackup OpenVMS Client V6.5.4

I use native TCP/IP of course.

I don't believe there's any need to for the GA version although there might be something happening here with Multinet?

Just seen this of interest to folks in this discussion

TECH ALERT: When multiple versions of a file are present, the NetBackup OpenVMS client will back up additional copies of the data in the latest version in place of earlier versions of the file. Both full and incremental backups are affected by this issue.
http://seer.entsupport.symantec.com/docs/330187.htm
http://seer.entsupport.symantec.com/docs/330009.htm

Affects 6.5 through to 6.5.4, fixed in 6.5.5 (due before end of year 2009)

Hey Malcolm, could you please let me know if you get any new Etrack IDs assigned from your new issues with the binary?  We may need to edit that Tech Alert!