13 Aug
2016
13 Aug
'16
7:14 p.m.
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:
>
>$(a)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
14 Aug
14 Aug
4:03 p.m.
On 8/13/2016 3:14 PM, Peter Coghlan wrote:
The console line is different than other serial ports on the VAX when it
comes to flow
control, I seem to remember using the other lines for transfer without
these problems.
I was too lazy to type in the one PAK by hand, although I seem to
remember doing that in
the past.
Is there a linux program that will do the serial terminal
emulation/logging ? I have a laptop
that I am using as the console I am thinking of changing it over to
Debian Linux. I was
using an old Dell Mini but the keys were way to small for typing accurately.
Doug
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. > 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. 
4:20 p.m.
On Aug 14, 2016, at 12:03 PM, Douglas Taylor
<dj.taylor4 at comcast.net> wrote:
...
Is there a linux program that will do the serial terminal emulation/logging ? I have a
laptop
that I am using as the console I am thinking of changing it over to Debian Linux. I was
using an old Dell Mini but the keys were way to small for typing accurately.
I've used minicom for that. Seemed to work well.
paul
15 Aug
15 Aug
4:41 a.m.
On Sat, 13 Aug 2016, Peter Coghlan wrote:
> If you are importing files into VMS, you need to
become familiar with the
> EXCHANGE command.
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.
On vms say something like this:
$ help analyze
(pay attention to the parts about /rms and /fdl)
$ help convert
build and and edit an fdl file and then say something like:
$ convert /fdl=foo.fdl foo.old foo.new
sigh.
--
Richard Loken VE6BSV, Systems Programmer - VMS : "...underneath those
Athabasca University : tuques we wear, our
Athabasca, Alberta Canada : heads are naked!"
** rlloken at telus.net ** : - Arthur Black
1:49 p.m.
Is iCl VME sound too use toward VMS from Mac?
On Monday, August 15, 2016, Richard Loken <rlloken at telus.net> wrote:
On Sat, 13 Aug 2016, Peter Coghlan wrote:
If you are importing files into VMS, you need to become familiar with the
I was a bit puzzled by this. I thought the main use of EXCHANGE was to
--
Sent from Gmail Mobile incognito
EXCHANGE
command.
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.
On vms say something like this:
$ help analyze
(pay attention to the parts about /rms and /fdl)
$ help convert
build and and edit an fdl file and then say something like:
$ convert /fdl=foo.fdl foo.old foo.new
sigh.
--
Richard Loken VE6BSV, Systems Programmer - VMS : "...underneath those
Athabasca University : tuques we wear, our
Athabasca, Alberta Canada : heads are naked!"
** rlloken at telus.net ** : - Arthur Black
9:45 p.m.
On vms say something like this:
$ help analyze
(pay attention to the parts about /rms and /fdl)
$ help convert
build and and edit an fdl file and then say something like:
$ convert /fdl=foo.fdl foo.old foo.new
sigh.
CONVERT is great for taking a file with the proper content and changing
it into an equivelant with a different record type. However, it's not
going to do anything useful in this case. The original poster transferred
a text file to his VMS system and got this error:
$(a)hobbyist-use-only-va.txt
%RMS-W-RTB 512 byte record to large for user buffer
Using CONVERT on the file will change it from a fixed record length file
into a variable length record file or a stream file but in all cases, all
of the records will remain 512 bytes long and they will continue to
contain bits and pieces of the original text and the file will not work
as required.
The most likely to work solutions are to use $ SET FILE /ATTRIBUTES or
Joe Meadows' FILE utility to change the file attributes from fixed 512 to
stream format. The CR-LF pairs in the file will then be treated as record
delimiters and the file will then be usable. Alternatively, delete the
file and transfer it again selecting a text transfer mode rather than
a binary transfer mode.
Regards,
Peter Coghlan.
16 Aug
16 Aug
3:35 a.m.
On Mon, 15 Aug 2016, Peter Coghlan wrote:
The most likely to work solutions are to use $ SET
FILE /ATTRIBUTES or
Joe Meadows' FILE utility to change the file attributes from fixed 512 to
stream format. The CR-LF pairs in the file will then be treated as record
delimiters and the file will then be usable. Alternatively, delete the
file and transfer it again selecting a text transfer mode rather than
a binary transfer mode.
Yes, you are right. I stopped making that particular mistake many years
ago and I had forgotten. So back in 1986 I wrote a bit of garbage code
to fix that problem in the crudest manner possible.
Namely this:
/* Name: clean_cp.c
* Purpose: copy an rms file and ignore record length
* Author: Richard Loken
* Date: 17-Dec-1986
* Modified: 30-Sep-1987 - RLL Throw out any \r's that may be in the file.
* 07-Oct-1987 - RLL and most other non printing characters.
* 07-Sep-1994 - RLL Hacked for OpenVMS AXP and DEC C
*/
#include stdio
#include file
#include stat
#include stdlib
#include "au_src:[lib]extern_lib.h"
#define ERROR (-1)
#define MAXSTR 256
#define TOTAL 2 /* number of arguments expected */
char prompt[TOTAL][7] = {"input", "output"}; /* error message array
*/
main(argc, argv)
int argc;
char *argv[];
{
char files[TOTAL][MAXSTR]; /* names of input and output files */
char program[MAXSTR]; /* name of the executable file */
FILE *fin, *fout; /* input rms file and converted out */
int c;
int count; /* character count for pars_arg() */
int i, j;
unsigned fsize; /* size of input file */
/* initialize the variables */
i = 0;
j = 0;
short_path(argv[0], program); /* get rid of device & directories */
ltou(program); /* lets capitalize it */
/* parse any arguments to learn the file names */
while(i < TOTAL)
{
files[i++][0] = '\0';
}
if((argc > 1) && (argc <= (TOTAL + 1)))
{
for(i = 1; i < argc; i++)
{
count = 0;
while(j < TOTAL)
{
if((count = pars_arg(argv[i], count, files[j++])) == 0)
{
break;
}
else if(count == EOF)
{
j--;
break;
}
}
}
}
/* if we don't have enough file names, prompt for the rest */
for(j = 0; j < TOTAL; j++)
{
while(files[j][0] == '\0')
{
fprintf(stderr, "%s file: ", prompt[j]);
gets(files[j]);
}
}
/* open input and output files */
if((fin = fopen(files[0], "r")) == NULL)
{
fprintf(stderr, "\n%s\nCANNOT OPEN %s\n", program, files[0]);
exit(4); /* a fatal error */
}
if((fout = fopen(files[1], "w")) == NULL)
{
fprintf(stderr, "\n%s\nCANNOT OPEN %s\n", program, files[1]);
exit(4); /* a fatal error */
}
/* crude, copy char by char until the end */
while((c = getc(fin)) != EOF)
{
putc(c, fout);
}
fclose(fin);
fclose(fout);
}
--
Richard Loken VE6BSV, Systems Programmer - VMS : "...underneath those
Athabasca University : tuques we wear, our
Athabasca, Alberta Canada : heads are naked!"
** rlloken at telus.net ** : - Arthur Black
3130
days inactive
3133
days old
6 comments
5 participants
participants (5)
-
cctalk＠beyondthepale.ie -
dj.taylor4＠comcast.net -
paulkoning＠comcast.net -
rlloken＠telus.net -
sbez742＠gmail.com