topic Re: Openvms file attributes change after FTP transfer in Operating System - OpenVMS

Openvms file attributes change after FTP transfer

IS Ops account — Thu, 03 Jun 2010 06:58:08 GMT

Dear forum,

I have just copied a tcpip patch file from UNIX host to VMS via FTP.
I cannot run it to decompress as the attributes changes.

Before:
--------
DEC-AXPVMS-TCPIP-V0506-9ECO5-1.ZIPEXE;1 File ID: (45190,42,0)
Size: 85340/85351 Owner: [SYSTEM]
Created: 3-JUN-2010 18:52:36.69
Revised: 3-JUN-2010 18:52:40.37 (1)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 85351, Extend: 0, Global buffer count: 0
No version limit
Record format: Variable length, maximum 0 bytes, longest 5299 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None

Command:
--------
SET FILE/ATTR=(RFM:FIX,MRS:512,LRL=512,ORG=SEQ,RAT=NONE)DEC-AXPVMS-TCPIP-V0506-9ECO5-1.ZIPEXE

After:
------
DEC-AXPVMS-TCPIP-V0506-9ECO5-1.ZIPEXE;1 File ID: (45190,42,0)
Size: 85340/85351 Owner: [SYSTEM]
Created: 3-JUN-2010 18:52:36.69
Revised: 3-JUN-2010 19:08:30.96 (4)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 85351, Extend: 0, Global buffer count: 0
No version limit
Record format: Fixed length 512 byte records
Record attributes: None
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None

Total of 1 file, 85340/85351 blocks.

This file is from ITRC and release date is 05-mar-2010.

Size:
dir /size DEC-AXPVMS-TCPIP-V0506-9ECO5-1.ZIPEXE

Directory CARD$DKB1:[PATCHES]

DEC-AXPVMS-TCPIP-V0506-9ECO5-1.ZIPEXE;1
85340

Total of 1 file, 85340 blocks.

Please advise.

Thanks a lot,
IO

Re: Openvms file attributes change after FTP transfer

Volker Halle — Thu, 03 Jun 2010 07:05:39 GMT

IO,

did you use FTP in binary mode explicitly ?

I assume, that the .ZIPEXE file still does not run after changing the attributes. Could please post the error message ?

Could you also attach a DUMP/BLOCK=COUNT=1/OUT=x.txt filename output as an attachment ?

Volker.

For reference: discussion stared at the bottom of this thread:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1417205

Re: Openvms file attributes change after FTP transfer

Shriniketan Bhagwat — Thu, 03 Jun 2010 07:27:25 GMT

Hi,

Yes, transferring the file in Binary mode should solve the problem. Are you able to install the kit, after modifying the attributes or after transferring the file in Binary mode?

>>What I can see already is that the block size of this file is different from your example,
Are you specifying 85340/85351 as difference in block size here?

Regards,
Ketan

Re: Openvms file attributes change after FTP transfer

P Muralidhar Kini — Thu, 03 Jun 2010 11:44:36 GMT

Hi IO,

>> I have just copied a tcpip patch file from UNIX host to VMS via FTP.
Was the file transferred in binary mode from UNIX to VMS ?

>> I cannot run it to decompress as the attributes changes.
What error message do you get now ?

Regards,
Murali

Re: Openvms file attributes change after FTP transfer

Hoff — Thu, 03 Jun 2010 12:46:37 GMT

From the OpenVMS Alpha box (and presuming that the VMS box is not blocked from reaching the internet via ftp) issue the following DCL command:

$ COPY /FTP /BINARY /ANONYMOUS -
ftp.itrc.hp.com::"/openvms_patches/layered_products/alpha/DEC-AXPVMS-TCPIP-V0506-9ECO5-1.ZIPEXE" -
DEC-AXPVMS-TCPIP-V0506-9ECO5-1.ZIPEXE

Those hyphens are continuations; you might need to remove them.

You'll have a copy of the TCP/IP Services patch that should decompress correctly, and directly on the OpenVMS box.

Re: Openvms file attributes change after FTP transfer

Steven Schweda — Thu, 03 Jun 2010 13:01:46 GMT

> I cannot run it to decompress as the
> attributes changes.

"I cannot" is not a useful problem
description. It does not say what you did.
It does not say what happened when you did
it.

> I have just copied a tcpip patch file from
> UNIX host to VMS via FTP.

How did it get to the UNIX host? "copied
[...] via FTP" omits a few important details.
As usual, showing actual commands with their
actual output might be more helpful than
vague descriptions and interpretations.

> Record format: Variable length, [...]

That does not look like the result from a
binary FTP transfer.

> SET FILE/ATTR=(RFM:FIX,[...]

Nice try, but you probably damaged more than
the attributes, so repairing the attributes
probably won't repair all the damage.

> Yes, transferring the file in Binary mode
> should solve the problem.

Only the original problem, not the lack of
useful information in the problem report.

Re: Openvms file attributes change after FTP transfer

Mashood K — Thu, 03 Jun 2010 15:53:00 GMT

The issue is because Variable length record stores the record size before each record.

I copied one zipexe file from OpenVMS machine to a windows machine and then ftp'ed it back.
Then I am able to see a similar issue.

I also tried to repair the file using the command,
SET FILE/ATTR=(RFM:FIX,MRS:512,LRL=512,ORG=SEQ,RAT=NONE)DEC-AXPVMS-TCPIP-V0506-9ECO5-1.ZIPEXE
and it gave the same result.

PUTTUR\SYSTEM>run VMS83A_COPY-V0300.ZIPEXE;
%DCL-W-ACTIMAGE, error activating image VMS83A_COPY-V0300.ZIPEXE;
-CLI-E-IMGNAME, image file $1$DKA0:[MASOOD.TEST]VMS83A_COPY-V0300.ZIPEXE;2
-IMGACT-F-NOTNATIVE, image is not an OpenVMS Alpha image

From the dump/header of the file which I tested,

RMS record attributes before ftp,
VAX-11 RMS attributes
Record type: Fixed
File organization: Sequential
Record attributes:
Record size: 512
Highest block: 368
End of file block: 355
End of file byte: 0
Bucket size: 0

RMS record attributes after ftp,
VAX-11 RMS attributes
Record type: Variable
File organization: Sequential
Record attributes: Implied carriage control
Record size: 512
Highest block: 368
End of file block: 356
End of file byte: 198

So there is a difference in End of File Block (EBK) and End of File Byte (FFB) between the two files.

In Fixed format files , there is no need to store the record size before each record.
But in Variable length the record size is stored before each record.

here there are 355 records of 512 bytes each.
to store record size, 2 bytes are used.
So before each record 2 bytes will be used to store record size 512.
So 355 * 2 =710 byte are extra needed in variable length format.
710 = 512 + 198 , Thus the end of file byte is correctly stored at 198th byte in the next block.
because of this record header the file has become corrupted.

So please ensure that to ftp Executable file you are using binary mode.

Regards,
Mashood

Re: Openvms file attributes change after FTP transfer

Steven Schweda — Thu, 03 Jun 2010 20:03:16 GMT

> The issue is because Variable length record
> stores the record size before each record.

That's one way to look at it. I find it
simpler to think of an ASCII FTP transfer
being inappropriate for non-text data. Even
if the FTP software on the VMS system created
a Stream_LF file, it might still be corrupted
by a text-mode transfer.

> I copied one zipexe file from OpenVMS
> machine to a windows machine and then
> ftp'ed it back.

Copied _how_, exactly? FTP'd _how_, exactly?
There are many ways to corrupt a file.

> As usual, showing actual commands with their
> actual output might be more helpful than
> vague descriptions and interpretations.

That's as true for answers as it is for
questions.