HP OpenVMS Systems

Data provider changes data format?

» close window

The Question is:

 
I am uncertain of the OpenVMS version number. The system is run by our data
 provider and I do not have access to that information at this time.
 
This is my situation. My data provider has been sending us information for the
 past several years on 3480 tapes. They simply use the VMS copy command to copy
 a whole directory of files to the device which is the 3480 tape drive. These
 files are ASCII text
 files. We then take these tapes and read them onto a UNIX machine ( Solaris
 2.6 ) using the dd command.
 
Now our data provider wishes to simply burn CDs each month, instead of the
 tapes. They ftp the same text files to a PC and create the CDROM for us.
 However these files look different internally.
 
The files we received on tape have within them numerous 4 digit codes that
 preceed a group of characters. These 4 digit codes tell us exactly how long
 that line of data is, including the for digit code. For example, if we saw
 "0008Test0006me", we would kn
ow that we had a line with "Test" on it and another with "me" on it. We wrote
 code to parse this data based on the existence of these 4 digit codes. Also,
 the files are in 2Kb blocks, which are padded with carets, "^".
 
The problem is that when we receive the data files on CD instead of tape, these
 4 digit codes are no longer there. Our provider tells us that when they view
 the files on their VAX or their PC, they do not see the 4 digit codes.
 
Could the VMS copy command be doing something to these text files when it
 copies them to tape? Something that would be translated behind the scenes if
 the file were to be viewed again on another VMS system?
 
If you can provide any insight at all into this situation I would greatly
 appreciate it. I thank you very much for your time.
 
Scott T. McColl
Bell & Howell Publishing Services
 

The Answer is :

 
  You will need to work out this file transfer and the resulting file
  transfer format issues with your data provider -- something has quite
  obviously changed, and most likely this involves changes to the tools
  and the environment that your data provider is using to generate the
  data files for you.
 
  This may well simply be a case of having accessed an ANSI tape volume
  using a tool that directly reads both the ANSI file structure and the
  data using raw (low-level) operations.  As the disk is not using the
  ANSI tape file structure, a tool that expects this structure will have
  corresponding problems reading the data.
 

  

     

     
answer written or last revised on ( 28-MAR-2000 )
     
» close window