So this is a case of DCL bits provided by a vendor that breaks, and you're here in ITRC asking questions? An approach more proximate and that would seem most expedient would be to ask the vendor that provided the DCL bits how to transfer the bits over to the host.
OpenVMS files that touch Windows boxes are often corrupted by that stop-over, which is why various vendors provide these as zip archives. zip (with the zip "-V" switch specified, including the quotes around it) prevents intervening hosts from stripping the file attributes; from producing these sorts of corruptions.
Here, use cut-and-paste if you have that set up. If you received this DCL as a mail attachment or such, save the file as a .txt and not a .com, and re-transfer it as an ASCII text file. Or you can ask the vendor to resend the file as a zip archive (with "-V") as that prevents corruptions.
DCL command procedure can be corrupted with a stop-over in Windows for a second reason, as the browsers and tools on Windows all tend to assume a .COM file is an executable and not a sequential text file. Which is another reason to use zip (with "-V") option to protect the files. More than a few firewalls strip messages with .COM files, too.
The other option is to download the DCL bits directly to and via the OpenVMS box and its networking capabilities, as the tools and browsers on OpenVMS assume a .COM file is a sequential text file.
Yes, I'm very deliberately repeating the recommendation around the use of a zip archive (with "-V") as that prevents corruptions. Vendors that don't do that should be called up and verbally flogged as they're allowing you and other users of their products and tools to join the legions of those that have encountered corrupted file transfers.
Your vendor left you hanging here, either in terms of skipping the use of zip (with "-V") or with the lack of directions on how to use these bits of DCL from the file source (mail, ftp server, otherwise) over onto the OpenVMS host.
