Undocumented flag for VMS C open() ?

[Daniel R. Levy]

Please, please pardon me for cluttering up your screens again if you've seen
this before, but I really need to find something out and I knew it was posted
some time ago (when of course I neglected to save it :-( ).

A couple or so months back, somebody (I think from Raytheon Corp.) posted a
question of how it would be possible to induce reads from VMS C to fetch the
"hidden" first byte of each record in a file which had been previously created
with Fortran carriage-control attributes.  It seems that in their infinite wis-
dom, the implementors of VMS C decided that reads from such a file would ignore
these first bytes, as if it were being read from a printed page, I guess.
Unfortunately, this makes such a file and an edited copy of it (sans attributes)
look different to a VMS C program, among other difficulties (what if there is
important data in that first byte?).  A workaround is converting the file
type (from DCL) but that is kind of awkward.

Anyhow, several helpful people posted messages concerning an "undocumented" flag
which could be used upon open()-ing [or maybe fopen()-ing] the file in order
not to miss those first bytes when the file was read.  At the time I did not
have access to VMS C (only Eunice C, which did not care whether or not there
were Fortran carriage-control attributes--yay Eunice I guess) so there was no
occasion for me to save this.  Now I have access to a VMS C compiler, and am
banging my head over this problem.  I contacted my friendly DEC representative,
who told me he knew of no such flag, but suggested the direct use of system
services (UGH!!! and highly nonportable).   So I am pleading and begging for
SOMEONE who remembers this or knows about this to PLEASE post or send me
Unix mail (address given in .signature).  I shall a thousand times over
be grateful (well maybe only 999 but... :-).

--Dan--


-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!ihnp4!ttrdc!levy