| To Pete or whomever:
My ASAP ID is 120970. I am trying to port part of an application written in C
from UNIX to VMS. I'm having a lot of trouble reading and writing a simple text
file. For now I am working on a VAX/VMS system at a remote location to which I
telnet from my PC. (I thought I should at least get the C-code running before I
come over to the porting center to try the full client/server setup that I
need.) I compile in CC/DECC. In UNIX C there are two ways to do file I/O: (1)
standard I/O (uses fopen, fread, and fwrite), and (2) system I/O (uses open,
read, and write). Because I have to read and write large blocks of data at a
time, I am using system I/O. The problems I am having are illustrated by the two
small programs and one text file that I have attached.
Here is the first problem. The text file portall.lst contains the 3
records
0525289S7
135087UN2
2485059X9
each consisting of 18 characters. On my PC each record ends with a CR and a LF.
Therefore, the records are each of length 20. When I ftp this file to a UNIX
system, the LF is stripped off, so the record lengths become 19, and this is
what my program expects. To upload this file to the VMS system I have used both
Kermit and ftp. In either case I still cannot tell if the LF was case stripped
out or not -- I think not. If not, then my program will crash. How can I tell if
the LF is still there, and how can I get rid of it if it is? Or better yet, how
can I upload files so as to delete LF's automatically? I suppose this is a
function of my transfer software.
The second problem is really unrelated to the first and is much worse. The
attached programs rrr1.c and rrr2.c are supposed to put the entire contents of
the file portall.lst into a buffer and then print out that buffer. rrr1.c writes
Size is 19
0 '0'
1 '5'
2 '2'
3 '5'
4 '2'
5 '8'
6 '9'
7 'S'
8 '7'
9 ' '
10 ' '
11 ' '
12 ' '
13 ' '
14 ' '
15 ' '
16 ' '
17 ' '
18 '
'
This is completely wrong. It seems to have read only up to the first CR.
In
rrr2.c I changed open(filename, O_RDONLY) to open(filename, O_RDONLY,
"ctx =
bin", "ctx = stm") as you suggested (I think it was Pete). rrr2.c then
produces
Size is 60
0 ''
1 ''
2 '0'
3 '5'
4 '2'
5 '5'
6 '2'
7 '8'
8 '9'
9 'S'
10 '7'
11 ' '
12 ' '
13 ' '
14 ' '
15 ' '
16 ' '
17 ' '
18 ' '
19 ' '
20 ''
21 ''
22 '1'
23 '3'
24 '5'
25 '0'
26 '8'
27 '7'
28 'U'
29 'N'
30 '2'
31 ' '
32 ' '
33 ' '
34 ' '
35 ' '
36 ' '
37 ' '
38 ' '
39 ' '
40 ''
41 ''
42 '2'
43 '4'
44 '8'
45 '5'
46 '0'
47 '5'
48 '9'
49 'X'
50 '9'
51 ' '
52 ' '
53 ' '
54 ' '
55 ' '
56 ' '
57 ' '
58 ' '
59 ' '
This is crazy. It reads 60 characters all right, but it left off the
trailing CR and LF (those LF's must be there!) and inserted two
characters
(CR and LF?) at the beginning of each record! What's going on here? I
obviously don't know much about file structure in VMS, but can't I get a
simple binary block read of a file? I would really appreciate your help.
Thanks.
Sincerely
Nish
Nishan Krikorian
Base-Two Investment Systems, Inc.
Boston, MA
617-395-8550
------ =_NextPart_000_01BC5EED.B8F2A0E0
Content-Type: text/plain; name="Portall.txt"
Content-Transfer-Encoding: 7bit
0525289S7
135087UN2
2485059X9
------ =_NextPart_000_01BC5EED.B8F2A0E0
Content-Type: text/plain; name="Rrr1.txt"
Content-Transfer-Encoding: 7bit
#include <fcntl.h>
#if defined(MSDOS)
#include <sys\types.h>
#include <sys\stat.h>
#include <io.h>
#else
#include <sys/types.h>
#include <sys/stat.h>
#endif
#include <stdlib.h>
#include <string.h>
#define BUFFERSIZE 12000 /* max in bufersize >(20*40)*/
main()
{
int nread, rdpos, nbytes, handle, i;
char buffer[BUFFERSIZE], filename[80];
rdpos = 0;
nread = 0;
nbytes = BUFFERSIZE;
strcpy(filename, "PORTALL.LST");
if ( (handle = open(filename, O_RDONLY)) < 0 )
printf("Cannot open %s\n", filename);
nread = read(handle, &buffer, nbytes);
close(handle);
printf("Size is %d\n", nread);
for (i = 0; i < nread; i++) printf("%5d '%c'\n", i, buffer[i]);
}
------ =_NextPart_000_01BC5EED.B8F2A0E0
Content-Type: text/plain; name="Rrr2.txt"
Content-Transfer-Encoding: 7bit
#include <fcntl.h>
#if defined(MSDOS)
#include <sys\types.h>
#include <sys\stat.h>
#include <io.h>
#else
#include <sys/types.h>
#include <sys/stat.h>
#endif
#include <stdlib.h>
#include <string.h>
#define BUFFERSIZE 12000 /* max in bufersize >(20*40)*/
main()
{
int nread, rdpos, nbytes, handle, i;
char buffer[BUFFERSIZE], filename[80];
rdpos = 0;
nread = 0;
nbytes = BUFFERSIZE;
strcpy(filename, "PORTALL.LST");
if ( (handle = open(filename, O_RDONLY, "ctx = bin", "ctx = stm")) < 0 )
printf("Cannot open %s\n", filename);
nread = read(handle, &buffer, nbytes);
close(handle);
printf("Size is %d\n", nread);
for (i = 0; i < nread; i++) printf("%5d '%c'\n", i, buffer[i]);
}
|
| Nish --
Nish --
As I discussed, OpenVMS has a rich set of file and record attributes that are
available to you. In your case this looks like excess baggage, but there are
others who appreciate the capabilities they offer.
$ DUMP/BLOCK will show you just how the bytes are laid out on disk.
The output of this is in two parts -- a hex dump on the left (which is read from
right to left) and an ASCII dump on the right (which is read from left to right)
You should be able to see from this whether there are CRLF pairs in there or not.
I suspect that you will find that the first two bytes of each record are a count
of the number of bytes in that record. I think that this is how ASCII files are
created by default by Digital's FTP.
If you use IMAGE format, you'll likely get exactly what is on the disk. If
you're coming from a PC, I expect you'll get the CR and LF characters.
You say that when you use FTP to bring the file to your UNIX box, you end up
without the CR character. This reinforces my assumption that you're using ASCII
mode, since the bytes in your UNIX file are now different from the bytes in your
PC file.
You now have two options for getting your file onto the OpenVMS system in the
desired format.
1) Pull the file from your PC and use the "CONVERT /FDL input_file output_file"
command to create a new version in the desired format. If your files are small,
this is probably perfectly acceptable.
The FDL file you will use will look like this:
RECORD
CARRIAGE_CONTROL none
FORMAT stream_lf
2) Use GET/FDL to have FTP create the file in the desired format (I'm not sure
if you would use IMAGE or ASCII mode -- or if it matters). This may be a little
trickier. I'll discuss some of the steps in more detail here. I can't give you
definitive steps because I don't have a PC to try this on and because I don't
know everything about what you have/want for file formats.
That said...
In order to get LF terminated records on the OpenVMS system, please try the
following experiment and let me know what you get.
1) Create your file on a UNIX system.
2) On OpenVMS pull this file in IMAGE mode. This will give you the file on the
OpenVMS system just as you want it. Please try your test program(s) to verify
this. Make sure you use "ctx=bin" on your open statement.
Now comes some of the uncertainty:
3) On the OpenVMS system, push the file to your PC in ASCII mode with PUT/FDL.
See if the file is on your PC as you want it.
If it isn't, use SET FILE/ATTR=RFM=STMLF and then push the file again, testing
to see if you get the desired results on your PC.
Once you get the file on your PC, you'll want to look at the FDL file that was
created with it. This will be the key to getting the file back to the OpenVMS
system correctly.
Once you get this far (if you choose this route), send my your .FDL file from
your PC.
|