Moving vision file 4 from an SCO Unix System to windows 2003 server

Hi all

I moved an indexed vision 4 file from SCO Unix to Windows server 2003 by an FTP manager (Cute Ftp).

In Unix the file is working properly with no problems but In win2003 server using Acu Cobol 7.0 could n't open it and get an 39 error on open.

I tried to rebuild the file and I gor the messages : "Chain of records is broken!" and "11 records recovered 6275 records lost"

Using other than primary keys to rebuild i reached to recover 275 instead of 11 records but it's a big loss either way.

After I tried several rebuilding options with no result I tried to use "-load" option of vutil32 but in that  case i got more than half records of the file send in .rej file as with illegal Duplicated keys which is not logical as the file is working in SCO Unix properly.

I tried also to recover the file manually by a START, READ program and ERROS_OK 1 in configuration file but it reads no more than one record.

I also tried to read the data-segment portion of the index file indivisually like a BINARY SEQUENTIAL file but i had no success on that also.

I appreciate for any help.

Thank you in advance.

  • We had several customers on SCO Unix that migrated to a Windows NT setup in the (very) late 90's instead of paying to upgrade their SCO license for Y2K.  What worked for us was to transfer the files as Vision 3 files (data and index combined in a single file, "vutil -r -3").  Since the file in questions has 6286 records, it sounds like it is small enough to try.  (The size limit on Vision 3 is 2GB).  Once you get the file(s) moved over (FTP must be running in binary, not ASCII mode), you can convert back to Vision 4 ("vutil32 -r -4") or even Vision 5 ("vutil32 -r -5").

    Another approach to consider would be to unload the file on SCO, transfer the file to Windows and load the data into an empty copy of the Vision file on Windows.

    If these don't work, you might try compressing the file(s) using gzip on the SCO side, then using WinZip or 7za to decompress them on the Windows side.

  • The most likely explanation is that the file was transferred in text mode rather than binary mode.  Vision 4 files are the same on any supported platform and can be moved between them without issue as long as the files are not modified during the transfer.  Can you try the transfer again?

  • The most likely explanation is that the file was transferred in text mode rather than binary mode.  Vision 4 files are the same on any supported platform and can be moved between them without issue as long as the files are not modified during the transfer.  Can you try the transfer again?

  • Vision 3, 4 or 5 files should transfer just fine between systems, with the following caveats:

    • When using FTP, you must use binary transfer mode. Using ASCII transfer mode (which is often the default in FTP client programs) will almost certainly corrupt your files.
    • If your data contains COMP-5 data and you're moving between systems that use different byte-ordering, your data will almost certainly become corrupt. COMP-5 data is not considered portable and should be avoided for any persistent use. This shouldn't be an issue for your case, as both SCO Unix and Windows run on the same processor family (Intel x86) and therefore use the same byte-ordering.

    Once a file has been corrupted due to an ASCII FTP transfer, there is no reliable way to restore it* - other than going back to the origin and transferring again in binary mode. 

    One quick way of determining if ASCII mode was used is to simply compare the file sizes before and after the transfer. If they differ by even one byte, you've used the wrong transfer mode.


    *Note that this statement doesn't apply to simple text-only files; they can be restored to the Unix line-termination style. But the statement holds true for any file containing binary data - including all Vision indexed files.

  • Thank you all so much for your kind help.

    Finally I tried other older backups of the file and it worked fine, which means I think that there is a problem with the particular backup-pc. (I checked the transfering mode in Cute Ftp and it was in Binarty Mode so I left that possibility also).

    Maybe its a virus or something else but now we know where to search at.

    Thank you all again, didn't know about this community, I'm new here and I'm thinking now that's a great and very helpful idea.  :-)  

  • Thank you all so much for your kind help.

    Finally I tried other older backups of the file and it worked fine, which means I think that there is a problem with the particular backup-pc. (I checked the transfering mode in Cute Ftp and it was in Binarty Mode so I left that possibility also).

    Maybe its a virus or something else but now we know where to search at.

    Thank you all again, didn't know about this community, I'm new here and I'm thinking now that's a great and very helpful idea.  :-)