> > 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-requ...@classiccmp.org wrote: > >Date: Thu, 11 Aug 2016 16:08:39 -0400 > >From: Douglas Taylor <dj.tayl...@comcast.net> > >To: "General Discussion: On-Topic and Off-Topic Posts" > > <cctalk@classiccmp.org> > >Subject: VAX file format conversion > >Message-ID: <d54db4aa-efc8-d332-971f-57250d5fd...@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.
