ADLER1%BRANDEIS.BITNET@wiscvm.wisc.EDU (05/31/87)
I am having a problem with C on VAX/VMS which I could perhaps solve if the DEC documentation were reliable, which it is not. The problem has to do with using C to handle files. To be concrete, consider a program which prompts the user for a character, a string, a sourcefile name and a target file name and then copies the source file one character at a time to the target file except that it replaces every occurrence of the given ccharacter by the given string. This is a pretty simple program to write. In VMS, it performs strangely. For example, suppose I run the program so that it should have no effect, say, change every comma to a comma. The DIFFERENCES command will indicate that the source file and target file are identical but the target file will no longer be in standard text file format even if the source file is. This already shows that stdio is not designed to take the file formatting into account. Now suppose you begin with a file containing a period and run the program to change to period to 10 periods, then take the resulting file and run the program, again changing each period to 10 periods, and so on. Very quickly one gets error messages when one tries to type the resulting files and in some cases I've gotten error messages just from running the program. Again it has to do with the formatting of the file. I asked the system programmer here what to do about it and the reply was to use the other options to the various file handling commands in VAX C. I consulted the manual and found that apart from the usual qualifiers one has in C, one can also specify file attributes which presumably let one control the formatting. This is discussed in Ch. 16 of the VAX C manual and a table of file attributes is given without any explanation of what they mean (well, it hums a few bars but the fat lady doesn't sing). There is a lengthier discussion in Ch. 13 of the VAX C manual as well as a sample program. Because one is not allowed to remove the documentation from the building to xerox and study it, I was obliged to spend a week typing the sample program into a file. When I ran it, I discovered that the program is wrong. For one thing, the type XAB which it uses is never defined in any of the include files in the library. One of the C programmers tried changing XAB to XABKEY and also corrected some typos in the text and the resulting program did compile and run but did not perform correctly. Such errors suggest that DEC did not take the trouble to make sure that the program they printed was actually one that they had run: it is perhaps a copy or an earlier version. I note that their SCAN manual is typeset with Knuth's TEX and the technology exists (e.g. Knuth's WEB or Thimbleby's CWeb) to typeset programs that actually correspond to working versions. So such carelessness in documentation is inexcusable. The material in Ch. 13 of the VAX C manual is based on the RMS of VAX/VMS. Presumably, one can find what one needs to know by reading the RMS manual. However, I am advised that the RMS manual is itself unreliable. The computing center staff says it is not equipped to handle these problems. The logical thing would be to contact DEC and ask for help. However, users are not entitled to call up the toll-free numbers that DEC provides for user support and I am advised both by the computing center staff and by George Robinson, the software specialist at the local DEC office, that there is no help from DEC for the afflicted in the here and now: one's salvation comes in the hereafter when they sell you the next release for plenty. I don't want to spend months doing DEC's laundry. If this is typical of what one can expect from computer manufacturers and sites, I think users are in big trouble. Before starting any project one must know one is starting on solid ground and no one seems to be in the business of selling that.
g-rh@cca.CCA.COM (Richard Harter) (05/31/87)
In article <7614@brl-adm.ARPA> ADLER1%BRANDEIS.BITNET@wiscvm.wisc.EDU writes: >I am having a problem with C on VAX/VMS which I could perhaps solve if the >DEC documentation were reliable, which it is not. > Whoa, this is a bunch of horse puckey. The manual is reliable and pretty complete. Your snide remarks about DEC documentation are out of line. The VMS C manual is obscure in places, poorly organized (in my opinion), and very confusing on this matter to someone who is used to the UNIX treatment of files. However the information is there, and you don't have to read the RMS manual. >The problem has to do with using C to handle files. To be concrete, consider >a program which prompts the user for a character, a string, a sourcefile >name and a target file name and then copies the source file one character at >a time to the target file except that it replaces every occurrence of the >given ccharacter by the given string. This is a pretty simple program to >write. > Fundamentally the problem is this: VMS supports a number of different file formats, block sizes, etc. In the creat, fopen, etc routines you can optionally add record descriptor qualifiers as additional arguments. If you don't you get defaults, and they are UNIX type defualts which are not the same as VMS defaults. If you open files and read and write from and to the files and you use the wrong descriptors you get funny results. You can even figure out what they will be, if you RTFM. What you probably want is: fptr=fopen(fn,"w","rfm=var","rat=cr");/* Create file */ or fnum = creat(fn,0,"rfm=var","rat=cr");/* Create output file */ fptr = fdopen(fnum,"w"); /* Get file struct ptr */ where fptr is FILE * and fnum is int, to be used in conjuction with fprintf. These will write files in the standard VMS format. Don't use open/read/write unless you know exactly what you're doing. In the above, "rfm=var" says that the file is a variable length file (double count byte at the beginning.) The 'rat=cr" says that the record terminator is a carriage return, rather than a line feed. This is what the editor expects. What has happened is that your choice of formats is inconsistent. What the manual should have (and doesn't as far as I can recall) is an explicit statement as to what to do for ordinary file read/write (i.e. you want to read a standard format file and write same.) However I don't have a copy at hand, so maybe it is buried in there somewhere. -- Richard Harter, SMDS Inc. [Disclaimers not permitted by company policy.]
minow@decvax.UUCP (Martin Minow) (06/01/87)
In article <7614@brl-adm.ARPA> ADLER1%BRANDEIS.BITNET@wiscvm.wisc.EDU describes a problem understanding file attributes on VMS, and how they interact with C programs. I apologize for the length of this response, but hope it proves useful. First, I want to make it clear that the following are my opinions and do not represent the position of Dec. >I am having a problem with C on VAX/VMS which I could perhaps solve if the >DEC documentation were reliable, which it is not. I've found the C documentation to be quite reliable and useful. I hope the poster was able to read the entire manual, and the manual version matches the version of C. (These notes refer to the current "V2" version.) >The problem has to do with using C to handle files. To be concrete, consider >a program which prompts the user for a character, a string, a sourcefile >name and a target file name and then copies the source file one character at >a time to the target file except that it replaces every occurrence of the >given ccharacter by the given string. This is a pretty simple program to >write. I've appended an untested version to this posting. >In VMS, it performs strangely. For example, suppose I run the program so >that it should have no effect, say, change every comma to a comma. The >DIFFERENCES command will indicate that the source file and target file are >identical but the target file will no longer be in standard text file format >even if the source file is. This already shows that stdio is not designed >to take the file formatting into account. The output file knows nothing about the input file. One major goal for Vax C for VMS was to simplify porting programs from the Unix (byte-stream) environment to the VMS (record-oriented) environment. To do this, a new file format, "Stream-LF," was added to the file system (RMS), and optional arguments were added to open() (Vax C version 1) and fopen() (version 2). In VMS as a whole, the "standard text file format" is "variable-length, carriage-control", in which each record has a byte count and the "new-line" is implied. Unfortunately, this is impossible to use with any C program that assumes it can seek() to arbitrary positions in the file. > Now suppose you begin with a >file containing a period and run the program to change to period to 10 >periods, then take the resulting file and run the program, again changing >each period to 10 periods, and so on. Very quickly one gets error messages >when one tries to type the resulting files and in some cases I've gotten >error messages just from running the program. Again it has to do with the >formatting of the file. I don't understand -- perhaps a bug in your program? Every VMS error message is unique, and there is a large manual describing each one. The poster then discusses attributes and their sample programs. As I don't have a manual at home, I'll skip this. If I may venture a guess, I would suspect (s)he is describing direct calls to the VMS system services, which is possible, but fairly difficult (also unnecessary). The XABs describe extended file attributes, such as the creation date, protection, and ISAM key attributes. There are a half-dozen XAB's, chained together. Accessing them is moderatly boring, but not too difficult. I learned to do it by reading the documentation. I've never found an error in a sample program in the C documentation, by the way. If you find one, you should use the "reader's comment form" at the end of the manual to communicate it to Dec. >The material in Ch. 13 of the VAX C manual is based on the RMS of VAX/VMS. >Presumably, one can find what one needs to know by reading the RMS manual. >However, I am advised that the RMS manual is itself unreliable. Yes. Yes. You were advised incorrectly. The poster then describes problems getting help. These are not issues for comp.lang.c Following my signature is an uncompiled, untested sketch of the program requested. It should show how to specify "vanilla RMS file attributes." Martin Minow decvax!minow This posting does not represent the position of Digital Equipment Corporation. #include <stdio.h> #define SRC_CHAR (argv[1][0]) #define REP_STRING (argv[2]) #define IN_FILE (argv[3]) #define OUT_FILE (argv[4]) main(argc, argv) int argc; char *argv[]; { register int c; freopen(IN_FILE, "r", stdin); /* * Create output file with "standard attributes" */ freopen(OUT_FILE, "w", stdout, "rat=cr", "rfm=var"); while ((c = getchar()) != EOF) { if (c == SRC_CHAR) fputs(REP_STRING, stdout); else { putchar(c); } l, 1f
mouse@mcgill-vision.UUCP (der Mouse) (06/23/87)
In article <7614@brl-adm.ARPA>, ADLER1%BRANDEIS.BITNET@wiscvm.wisc.EDU writes: > [much about problems with VMS C] > The logical thing would be to contact DEC and ask for help. However, > users are not entitled to call up the toll-free numbers that DEC > provides for user support and [...] You've got to be kidding. You mean DEC doesn't listen when users call the user support number?! I mean, I'm not terribly fond of DEC either, but this is ridiculous. der Mouse (mouse@mcgill-vision.uucp)
hsw@TYCHO.arpa (Howard Weiss) (01/23/88)
I am a UNIX C programmer and have just recently been playing around with a VMS system and a C Compiler running on it. Unfortunately, I don't have any documentation of the VMS C compiler and I'm having trouble doing something that seems quite natural to do - command line argument processing. I am able to compile and link programs so that I have a resulting file (foo.exe) which I can then run using the VMS 'run' command (r foo). The problem I have it how do I pass arguments into the program (i.e., UNIX-style, foo -w). If I give any args on the VMS 'run' command line, the system complains about too many parameters. In addition, touching argv in the C program either gives bogus information or causes the program to bomb. Anyone have any good info for me - any and all would be appreciated. Please respond directly to me - I am not a regular reader of the mailing list. Thanks, Howard Weiss -------
hydrovax@nmtsun.nmt.edu (M. Warner Losh) (01/24/88)
In article <11421@brl-adm.ARPA>, hsw@TYCHO.arpa (Howard Weiss) writes: > I am a UNIX C programmer and have just recently been playing around with This was your first mistake :-). > a VMS system and a C Compiler running on it. Unfortunately, I don't > have any documentation of the VMS C compiler and I'm having trouble > doing something that seems quite natural to do - command line > argument processing. I am able to compile and link programs so > that I have a resulting file (foo.exe) which I can then run using > the VMS 'run' command (r foo). The problem I have it how do I pass > arguments into the program (i.e., UNIX-style, foo -w). If I give > any args on the VMS 'run' command line, the system complains about > too many parameters. In addition, touching argv in the C program > either gives bogus information or causes the program to bomb. > OK, here's how. The program that you are writing needn't be changed (if you are trying to access the command line args the way that UNIX systems usually do). You need to do a little set up in DCL. First you need to define a symbol (say foo) as follows: $ foo :== $disk:[dir]foo This tells VMS that FOO is a foriegn command and to pass the rest of the line to the process unscathed. Well, almost unscathed. It converts the whole thing that isn't contained in quotes to UPPER CASE. The 'C' compiler, not to be outdone, converts them back to lower case. So, this makes it inconvient to have -f and -F mean different things. If you want to pass mixed case you need to inclose the operands in quotes as follows: $ foo "-F" file Would set argv[1] to "-F", like you want (The quotes are for clarity in this line, but not in the command, your program doesn't see them). A warning about argv[0]. It is the complete file specification that the program was run as (that is it ignores what you type on the command line.) So if you had $ foo :== disk:[dir]foo $ bar :== disk:[dir]foo Your program couldn't tell the difference between foo xxx and bar xxx. This is the way it works in VAX C 2.2. They may have changed it for 2.3. I hope that this helps some. Also note: If you are using 2.2 (but not 2.3) they exit(0) produces strange results. This has been fixed in 2.3. To find the compiler version, do something like: $ CC/LIST foo $ TYPE FOO.LIS and look at the top of each page. The compiler version is listed there. You may want to do this for a SMALL 'C' program first (like hello world). -- bitnet: lush@nmt.csnet M. Warner Losh csnet: warner%hydrovax@nmtsun uucp: ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!hydrovax Warning: Hydrovax is both a machine, and an account, so be careful.