[Info-vax] difference in files being copied by scp from Unix to VMS
FredK
fred.nospam at dec.com
Mon Apr 27 18:22:58 EDT 2009
I have to admit that
Record type: LF-terminated stream
File organization: Sequential
Record attributes: Implied carriage control
Is a strange file organization.
Be that as it may, my observation in various file import/export scenerios is
that two problems are comon:
One is where the file transfer protocol is actively trying to interpret the
data stream (i.e. "ACII" format), and the other is where the end of file
marker is not correctly handled - this happens more frequently with binary
mode block transfers.
Extra nulls at the end of the file is typical of the latter.
"Sumir" <sumirmehta at gmail.com> wrote in message
news:a4d7c934-6cb0-42a4-8f07-5cc75fb827b5 at w31g2000prd.googlegroups.com...
On Apr 21, 5:33 pm, JF Mezei <jfmezei.spam... at vaxination.ca> wrote:
> Sumir wrote:
> > Meanwhile, the issue that was being faced has been averted by ignoring
> > this particular file that was causing the problem, and hence i am not
> > pursuing it further.
>
> It would be nice for the community to put some closure on this though.
>
> The fact that you have one file whose transfer is dubious would mean
> that this problem could surface with any other file.
>
> And finding the real problem would help others in this newsgroup should
> they ever encouncter a similar problem.
>
> In particular, I would be concerned about preservation of the end of
> file marker for the last block.
>
> DUMP/HEADER gives you some information about that:
>
> > VAX-11 RMS attributes
> > Record type: LF-terminated stream
> > File organization: Sequential
> > Record attributes: Implied carriage control
> > Record size: 32767
> > Highest block: 1464
> > End of file block: 1463
> > End of file byte: 471 <=============
> > Bucket size: 0
>
> AKA, the last byte is byte 471 in block 1463, with bytes 472 to 512
> being beyond end of file.
>
> It is possible that your source file was like this, but when copied back
> to VMS, the end of file byte was 512 (or is it 511 ?) which would add
> some 30 bytes to the file, probably all nulls (which would explain your
> extra line).
On Apr 21, 5:33 pm, JF Mezei <jfmezei.spam... at vaxination.ca> wrote:
> Sumir wrote:
> > Meanwhile, the issue that was being faced has been averted by ignoring
> > this particular file that was causing the problem, and hence i am not
> > pursuing it further.
>
> It would be nice for the community to put some closure on this though.
>
> The fact that you have one file whose transfer is dubious would mean
> that this problem could surface with any other file.
>
> And finding the real problem would help others in this newsgroup should
> they ever encouncter a similar problem.
>
> In particular, I would be concerned about preservation of the end of
> file marker for the last block.
>
> DUMP/HEADER gives you some information about that:
>
> > VAX-11 RMS attributes
> > Record type: LF-terminated stream
> > File organization: Sequential
> > Record attributes: Implied carriage control
> > Record size: 32767
> > Highest block: 1464
> > End of file block: 1463
> > End of file byte: 471 <=============
> > Bucket size: 0
>
> AKA, the last byte is byte 471 in block 1463, with bytes 472 to 512
> being beyond end of file.
>
> It is possible that your source file was like this, but when copied back
> to VMS, the end of file byte was 512 (or is it 511 ?) which would add
> some 30 bytes to the file, probably all nulls (which would explain your
> extra line).
Hi,
The DUMP/HEADER on the files i am comparing gives following info
------ FILE 1 ------
Header area
Identification area offset: 40
Map area offset: 100
Access control area offset: 255
Reserved area offset: 255
Extension segment number: 0
Structure level and version: 2, 1
File identification: (2278,3,0)
Extension file identification: (0,0,0)
VAX-11 RMS attributes
Record type: LF-terminated stream
File organization: Sequential
Record attributes: Implied carriage control
Record size: 127
Highest block: 20
End of file block: 14
End of file byte: 178
Bucket size: 0
Fixed control area size: 0
Maximum record size: 0
Default extension size: 0
Global buffer count: 0
Directory version limit: 0
File characteristics: <none specified>
------ FILE 2 ------
Header area
Identification area offset: 40
Map area offset: 100
Access control area offset: 255
Reserved area offset: 255
Extension segment number: 0
Structure level and version: 2, 1
File identification: (2275,10,0)
Extension file identification: (0,0,0)
VAX-11 RMS attributes
Record type: LF-terminated stream
File organization: Sequential
Record attributes: Implied carriage control
Record size: 0
Highest block: 20
End of file block: 14
End of file byte: 340
Bucket size: 0
Fixed control area size: 0
Maximum record size: 0
Default extension size: 0
Global buffer count: 0
Directory version limit: 0
File characteristics: <none specified>
Map area words in use: 2
Access mode: 0
File owner UIC: [BTRICS,KIM]
File protection: S:RWED, O:RWED, G:RWE, W:
Back link file identification: (1530,1,0)
Journal control flags: <none specified>
Active recovery units: None
Highest block written: 20
The difference between the two files is a row of nulls (hex 0x0000) as
observed below -
CURESOPER> DIFF/ignore=blank_lines/mode=(HEXADECIMAL)
CONV_COMP_TRACK.TXT_20090427;1 TEMP_COMP_TRACK.TXT_20090424
************
File BT$$_CURES:[CURES.REPT]CONV_COMP_TRACK.TXT_20090427;1
******
File BT$$_CURES:[CURES.REPT]TEMP_COMP_TRACK.TXT_20090424;1
RECORD NUMBER 69 (00000045) LENGTH 162 (000000A2)
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 ........................................
000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 ........................................
000028
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 ........................................
000050
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 ........................................
000078
0000 ........................................ 0000A0
************
Number of difference sections found: 1
Number of difference records found: 1
DIFFERENCES /IGNORE=(BLANK_LINES)/MERGED=1/MODE=(HEXADECIMAL)-
BT$$_CURES:[CURES.REPT]CONV_COMP_TRACK.TXT_20090427;1-
BT$$_CURES:[CURES.REPT]TEMP_COMP_TRACK.TXT_20090424;1
The file containing the extra line is being copied back from UNIX to
VMS (TEMP_COMP_TRACK.TXT_20090424;1)
Is there a way to remove these NULLs out of the file ? Please let me
know if additional information is required.
Regards,
Sumir
More information about the Info-vax
mailing list