|
HP OpenVMS Systemsask the wizard |
|
The Question is: I need to transfer a very large file from a server file to the Alpha. The incoming file is EBCDIC file w/record length of 2711. This file we used to receive on magnetic tape media but now need to be able to receive via FTP. I have tried FTPing using SET IMAGE BINARY but the records are all shortened to 512 bytes instead of leaving them 2711 bytes. Please help! The Answer is : The OpenVMS Wizard expects you will need to work directly with the provider of the file to negotiate an acceptable file organization. The OpenVMS Wizard will assume you are running current TCP/IP Services with the current ECO applied. Your OpenVMS release is rather dated, and in need of an upgrade. The OpenVMS Wizard would suggest use of the COPY/FTP command. Without details on the file format and record organization of the file on the remote system, the OpenVMS Wizard can only suggest that you zip it before performing the file transfer -- the error you are seeing is due to an unexpectedly large record found in the input file. Zip might or might not help with the file format, but it will help you with the network transfer. Based solely on the error, the remote (sequential?) file does not appear to have a recognizable record organization. The application involved may well expect fixed-length records of 2711 bytes in size, and a careful study (ANALYZE/RMS, DUMP/RECORD=COUNT=3) of a file as was transferred by tape in the past is in order. RMS does not directly support odd-length records in packed binary. If this is the situation, the OpenVMS Wizard suggests creating a (simple) program using C or PERL or Macro32 to read raw data from the 512-byte input records, and to then aggreate and generate 2711 byte records in an output file. (CREATE/FDL or the FDL$ callable routines can be used to create the output file, potentially using an FDL file created by the ANALYZE tool. Normally, FTP transfers of an EBCDEC file in ASCII mode will result in the translation of the characters from EBCDIC to ASCII. Of course, this assumes that the native character set of the source of the file is EBCDEC. To avoid this conversion, BINARY mode should be used. From the original description, it appears that the EBCDIC file might be transfered via an intermediate host -- the addition of this intermediate host permits a larger range of problems in the transfer. Consider simplification. Please contact the file's provider and please contact the Customer Support Center for further assistance.
|