NAS copy, RMS-F-WER, file write error, SYSTEM-F-TIMEOUT

[Dipak Mistry_1]

Hi All,

I have mapped an Openvms NFS disk onto a NAS server.
And I am having problems copying over just two files, daily, the error I get is :-

%COPY-E-WRITEERR, error writing DNFS5:[000000.SAVOYE.26-FEB-2008]PFIZER_AUDIT.DMP;12
-RMS-F-WER, file write error
-SYSTEM-F-TIMEOUT, device timeout
%COPY-W-NOTCMPLT, APP_DATA_DSK:[000000.ORACLE8.BACKUP]PFIZER_AUDIT.DMP;12 not completely copied

Other much larger files copy fine, and disk space is not an issue.
As the copy procedure is scripted, some days we have noticed the files copy fine.

Please fine following other info.

PFIZ01> ucx sho ver

Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 4
on a AlphaServer 1200 5/533 4MB running OpenVMS V7.3-1

PFIZ01>
PFIZ01> sho dev DNFS5: /full

Disk DNFS5: (PFIZ01), device type Foreign disk type 7, is online, mounted, file-
oriented device, shareable, accessed via DFS or NFS.

Error count 0 Operations completed 480420
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:RWPL,W:RWPL
Reference count 1 Default buffer size 512
Total blocks 62914560 Sectors per track 0
Total cylinders 0 Tracks per cylinder 0
Allocation class 1

Volume label "SANNA:/vol/s" Relative volume number 0
Cluster size 16 Transaction count 1
Free blocks unknown Maximum files allowed 1000000
Extend quantity 16 Mount count 1
Mount status System ACP process name "DNFS5ACP"

Volume Status: ODS-2, caching is disabled.

PFIZ01>

Files to be copied to NAS server
PFIZ01> dir /siz=all /prot
PFIZER_AUDIT.DMP;12
13848/13860 (RWD,RWED,RWED,RWED)
RESTORE_DATABASE.COM;2682
16/35 (RWED,RWED,RE,)
TBS_TO_DATAFILES.LIS;2682
3/35 (RWED,RWED,RE,)

Copy error

Current Time 26-FEB-2008 05:00:00.94
%COPY-E-WRITEERR, error writing DNFS5:[000000.SAVOYE.26-FEB-2008]PFIZER_AUDIT.DMP;12
-RMS-F-WER, file write error
-SYSTEM-F-TIMEOUT, device timeout
%COPY-W-NOTCMPLT, APP_DATA_DSK:[000000.ORACLE8.BACKUP]PFIZER_AUDIT.DMP;12 not co
mpletely copied

Current Time 26-FEB-2008 05:00:11.05
%COPY-S-COPIED, APP_DATA_DSK:[000000.ORACLE8.BACKUP]RESTORE_DATABASE.COM;2682 co
pied to DNFS5:[000000.SAVOYE.26-FEB-2008]RESTORE_DATABASE.COM;2682 (16 blocks)

Current Time 26-FEB-2008 05:00:11.16
%COPY-E-WRITEERR, error writing DNFS5:[000000.SAVOYE.26-FEB-2008]TBS_TO_DATAFILE
S.LIS;2682
-RMS-F-WER, file write error
-SYSTEM-F-TIMEOUT, device timeout
%COPY-W-NOTCMPLT, APP_DATA_DSK:[000000.ORACLE8.BACKUP]TBS_TO_DATAFILES.LIS;2682
not completely copied
.
.
Other larger files that copy o.k.
Current Time 26-FEB-2008 05:05:58.08
%COPY-S-COPIED, APP_DATA_DSK:[000000.ORACLE8.BACKUP]ORA_PFIZER_DATA1.DBS;2674 co
pied to DNFS5:[000000.SAVOYE.26-FEB-2008]ORA_PFIZER_DATA1.DBS;2674 (204800 block
s)
Current Time 26-FEB-2008 05:06:26.54
%COPY-S-COPIED, APP_DATA_DSK:[000000.ORACLE8.BACKUP]ORA_PFIZER_DATA2.DBS;2674 co
pied to DNFS5:[000000.SAVOYE.26-FEB-2008]ORA_PFIZER_DATA2.DBS;2674 (102400 block
s)
Current Time 26-FEB-2008 05:06:40.75
%COPY-S-COPIED, APP_DATA_DSK:[000000.ORACLE8.BACKUP]ORA_PFIZER_IND.DBS;2674 copi
ed to DNFS5:[000000.SAVOYE.26-FEB-2008]ORA_PFIZER_IND.DBS;2674 (942080 blocks)

If I try to copy the file from another OpenVMS node running TCP/IP 5.3 (7.3-1)
without the ECO 4 patch, to the same NAS server, the copy works fine.

Any help will be greatly appreciated.

Thanks

Dipak

[Hein van den Heuvel]

Dipak,

Welcome to the ITRC OpenVMS Forum.

A nice, complete, first question. Excellent!

Hmmm 7.3-1 huh? To know that and not do anyting about it is almost criminal negligence.
Every system running V7.0 or higher should be on 7.3-2. No excuse.
(And every V8 system should be on V8.3 today!)

Anyway... what is the SIZE (DIR/SIZE=ALL or F$FILE:EOF, FFB and ALQ) of the failing file?
I suspect it has something to do with how the copy buffers divide into the nmber of blocks to be copied. On OpenVMS V8.3 you can $COPY/BLOCK=n (Thanks Guy!) but I do not known about 7.3-1 anymore. I _think_ it listens to SET RMS /SEQ/BLO. Not sure.

Can BACKUP copy that file correctly?

Working with a copy of the file first, can you extent the file a little, just the allocated space, to 'even' it out? Or even the eof pointer

hth,
Hein.

[Hoff]

Either get to a supported configuration and (if it persists) escalate to HP, or pull the PCSI kits and pieces apparent for yourself and create your own "Frankenstein" ECO kit, or your own hand-upgraded box.

NFS itself can and does have integration issues. Sometimes its the OpenVMS client, and sometimes its the remote NFS server. When you're off in this area, turning on any of the diagnostics that might be available underneath NFS (and checking both ends) can sometimes help resolve issues.

Do look to see if zipping the file makes any difference. Either the current released zip and unzip for operations below a couple of gigabytes, or use the zip3/unzip6 beta for 64-bit archives. Released bits:

http://mvb.saic.com/freeware/freewarev80/000tools/

As for your current software versions here, staying on old software releases is not free, and can and will have its costs, and you're seeing some of those costs accruing here.

And FWIW (and not at all related to the base NFS file transfer issue) there's a block transfer tool latent in V8.3; the start block, end block or length of a block transfer can be specified.

Personally, I'd punt on the whole concept of using NFS and NAS here, and move to a (zip-protected, zip-shrunk) FTP transfer. Most NAS devices support FTP, and I'd bet it'll be faster and more reliable for this sort of thing. COPY /FTP is the command to use.

[Dipak Mistry_1]

Hi Hein,

Firstly, Thank you everso much for the response.
Yes, I agree I should upgrade this OpenVMS system, but its about obtaining downtime and funds from our client that I support this system for to undertake the work. But I will endeavour to mention this at the next meeting.

I did have the dir/siz=all on the original txt, but I have included a dir/full on the file.
I have extented the file, and retried the copy, no joy, and the backup command copy also fails.

Please see attached file

Kind Regards and Many Thanks

Dipak

[Dipak Mistry_1]

Hi Hoff @ Hoffman Labs,

Thank you for the Time & response.
I do agree that I need to get to the support OS version, this I will stride to do.

I Zipped the file I was having a problems with and re-did the copy and this worked!.
So I have a plan 'B'.
But I would like to get the copy going, as other files are moved with the copy command and we have tested the restore, back from the NAS server, so there are no file attribute/formating issues.
Our client wanted us to use the NAS server method, so we just complied with the request.

Once again, many Thanks

Dipak

[Dipak Mistry_1]

Hi Hein,

I missed the following details in the attached file.
RMS attributes on file pfizer_audit.dmp


File allocation is (ALQ) ...... 14385
Number of Blocks used is (EOF) ...... 14376
First Free Byte is (FFB) ...... 0
Maxiumum record number is (MRN) ...... 0
Maxiumum record size is (MRS) ...... 4096

Many Thxs

Dipak

[Dipak Mistry_1]

I would like to say Thank You to Hein and
Hoff in replying to my thread.
I would have still liked to have known why
my copy does not work. The thread has been
open for a week, and I expected any
immediate solutions to come to light by
now.
Many Thanks to everyone who have read my
thread also.