VAX file format conversion

[Peter Coghlan]

>
> If you are importing files into VMS, you need to become familiar with the
> EXCHANGE command.
> (found via Google) 
> http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04623262
> It can do stream and carriage control conversions on various RMS fixed formats.
>

I was a bit puzzled by this.  I thought the main use of EXCHANGE was to
to copy files to or from disk or tape volumes which are not in a native
VMS format but are in a format native to some other DEC operating system.

(The url doesn't work for me - I get:

"Hewlett Packard Enterprise Support Center

 The service or information you requested is not available at this time.
 Please try again later.")

>
> When we first brought up DECnet-DOS network file transfer, we had 
> some "discussions" with the VMS RMS
> engineers that didn't like us doing auto conversions.  This was their 
> "compromise".
>

I had a look at the online help for EXCHANGE on VMS and it looks like you
are probably referring to using EXCHANGE with the /NETWORK qualifier.  I
can see how something like that would be needed in the case of DECnet-DOS
because there is no direct mapping that can be assumed between the types
of files you get on DOS and the types of files you get on VMS which will
work for every purpose in every case.

My guess is that you felt you could come with an automatic conversion
process that worked almost all of the time but the VMS people weren't
happy with that?

EXCHANGE /NETWORK does look like a bit of a kludge which could have been
made more user friendly but I find it hard to see how something like it
could be avoided altogether given the differences between the two
filesystems.

I have managed to get though a couple of decades of use of VMS without
ever having to resort to EXCHANGE /NETWORK, getting by instead using
the abilities of various file transfer utilites, archiving products
and networking packages to allow the user to specify either "text" or
"binary" files and in rare cases, making adjustments with
SET FILE /ATTRIBUTES or even more rarely, CONVERT.

>
> Oh and if you are doing serial transfers, yes, keeping the baud rate 
> low is a good strategy.
> I had to spend some time working on the DECnet-DOS DDCMP driver 
> developing better character overrun recovery strategies. Yes, you may 
> be coming in via a terminal line, but that line can hiccup from time to time.
>

Additionally, I would suggest using any terminal line other than the
console line (OPA0:) to do any sort of serial file transfers, even for
cutting and pasting groups of lines into a terminal emulator running in
a window on some other system.  It is very easy to overrun the console
and to end up getting it hung requiring a reboot or even a poweroff to
clear it.  I suspect there is no flow control at all on the console
terminal line and error recover is poorer than on ordinary terminal lines.

If you can only log in on the console due to lack of licensing, I would
suggest manually typing in just the VAX-VMS hobbyist license (and maybe a
license for a networking product) on the console, then logging on using
another terminal or over the network to transfer the other licenses.

If you can't avoid cutting and pasting into a terminal emulator attached
to the console line, do no more than groups of one or two lines at a time.

> Dave.

>
> On 8/12/2016 01:00 PM, cctech-request at classiccmp.org wrote:
> >Date: Thu, 11 Aug 2016 16:08:39 -0400
> >From: Douglas Taylor <dj.taylor4 at comcast.net>
> >To: "General Discussion: On-Topic and Off-Topic Posts"
> >         <cctalk at classiccmp.org>
> >Subject: VAX file format conversion
> >Message-ID: <d54db4aa-efc8-d332-971f-57250d5fd0f5 at comcast.net>
> >Content-Type: text/plain; charset=utf-8; format=flowed
> >
> >I have a MicroVax 4000 that I am trying to update the license PAKs on,
> >the last time I had valid PAKs on this machine was in 2002 (Hobbyist
> >Licenses).
> >
> >I registered and have received the new Hobbyist License PAKs.
> >
> >I connected a laptop and transferred the text file using C-Kermit on the
> >VAX and hyperterminal on the laptop.
> >
> >When I go to execute the file, I get an error:
> >
> >$@hobbyist-use-only-va.txt
> >
> >%RMS-W-RTB 512 bye record to large for user buffer
> >
> >It appears that when the file was transferred it showed up on the vax
> >with fixed length records of 512 bytes, not variable length.
> >
> >Can I convert the file on the VAX?
> >

Possibly but what you need to do depends on how exactly the file contents
ended up and what the file attributes are.  My guess would be something
like:

$ SET FILE /ATTRIBUTES=(RFM=STM,RAT=CR) filename

This assumes that the file contents are text with a CR and LF at the end
of each line and it can be made legible to VMS by changing the file
attributes from fixed length 512 byte records with no carriage control to
stream format records with CR-LF record terminations and carriage return
carriage control.

(This command only works on versions of VMS later than about 6.something.
If you have a very old version of VAX/VMS like V5.5-2, it is not available)


> >
> >Is there a setting for C-Kermit that I need to change?
> >

At a guess, you probably need something like "SET FILE TYPE TEXT" but I
would have thought text would have been the default.  Maybe you have a
CKERMIT.INI or other kermit initialisation file containing:
"SET FILE TYPE BINARY" ?

> >
> >Is Hyperterminal screwing things up?
> >

Hyperterminal and/or any of the so-called VT100 emulators bundled with
Windows are of little use to connect to anything that makes more than
the simplest use of a VT100 terminal or later generations of same.  It
will work ok for entering line mode commands but if you start up an
editor or another fullscreen application of moderate complexity, it
will fail spectacularly and leave you with a garbled mess on the screen.
The problem is that Hyperterminal et al do not implement scrolling
regions correctly or maybe at all.

If Hyperterminal purports to provide kermit file transfer, there may be
an option somewhere to specify text rather than binary file transfer or
it may be that this is not required at that end.

> >Doug
>

Regards,
Peter Coghlan.