fseek,fread in c program

[ch5082]

Not sure if this is the proper place to post a c programming question, but here goes. I am a new c/c++ developer on VMS and I have little experience with VMS itself.
I am trying to position the file pointer randomly using fseek. This always positioned the file pointer to the beginning of the file until we changed the file attributes to Stream_LF. Then I could use fseek to position the file pointer, but now the fread function does not work properly. I've seen some talk on the web about fseek on vms not working properly, but I'm not sure how else to randomly read from a file.

[Hein van den Heuvel]

Right.

Using variable length record RMS files the program can only seek to 'record boundaries'.
This pretty much limits you to seek to locations you have previously found and recorded through tell.
Using stream_lf files the C RTL takes over from RMS, and knows how to do byte positioning.

You may also want to try "Undefined" RMS files ($SET FILE/ATTR=RFM=UDF), notably if there is no defined record structure, just blobs of data.

hth,
Hein van den Heuvel
HvdH Performance Consulting

[ch5082]

We changed the attribute as suggested. The fseek appears to have worked. I then use fgets to find the newline and position the file pointer at the correct location. Then I do fread for 132 characters which should be end of the line. The fgets call returned an empty string.
Would it be useful to see the code or file?

[Steven Schweda]

> Then I do fread for 132 characters which
> should be end of the line.

If you're looking for the end-of-line, why
not use fgets() here?

> The fgets call returned an empty string.

Well, if it was right at the end of the line
(and not at the beginning of the next), ...

> Would it be useful to see the code or file?

It might. An actual (small) test case is
always handy.

[Ian Miller.]

which version of VMS and do you have the current CRTL patch for that version?

CRTL documentation is available at
http://h71000.www7.hp.com/doc/83final/5763/5763pro.html

[ch5082]

I had to wirte a small program to read in the file from the beginning and then output it to a new file. The new file created the file with the proper file attributes so I am now able to use the fseek. Here are the attributes of the 2 files.
BAD FILE:
Record format: Stream_LF, maximum 0 bytes, longest 132 bytes
Record attributes: Carriage return carriage control
GOOD FILE:
Record format: Stream_LF, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control

--
We tried to just change the file attributes to use 32767 bytes, but it still did not work until I created the new file.
-Thanks for the suggestions.

[Steven Schweda]

DUMP might tell you something interesting
about what's in those files. A stray NUL
byte here or there can do bothersome things
to the C RTL.

[Jan van den Ende]

ch5082,

>>>
until we changed the file attributes to Stream_LF.
<<<

and
>>>
We tried to just change the file attributes to use 32767 bytes, but it still did not work until I created the new file.
<<<

So, _HOW_ did you change the attribs?
By just a
$ SET FILE/ATTR=,
or by a
$ CONVERT/FDL=
?

Just a SET file DOES change the DESCRIPTION of the file in the header, but _NOT_ the internal structure. And, for a programm that does not leave handling to RMS, the header is irrelevant.

>>>
I had to wirte a small program to read in the file from the beginning and then output it to a new file.
<<<

Effectively, what you did is write your own CONVERT, with the default C output format as an implicit FDL.

Hein can probably explain thin in much more detail and better wording.

fwiw,

Proost.

Have one on me.

jpe

[ch5082]

I used set file chuck.csv /attrib=(lrl:32767).

Is there a better way if this is all that needs to be done? I'm sure we'll have to do this in the future.

[Hein van den Heuvel]

There may be a better way, but we need still more data on what a bad file vs good file looks like. Perhaps both a DUMP/BLOCK=COUNT=3 (to see the raw bytes) as well as DUMP/RECO=COUN=10 (to see how RMS interprets them). And a DIR/FULL (or ANAL/RMS/FDL). Attach as .TXT to a reply.

I suspect most interested readers also wonder what the program did to make it right. Just get+put (read+write) in a look, or some end-of-line or null-byte-terminator processing? Did you try a simple CONVERT also?
May there was an MRS overruling the LRL?

Hope this helps some,
Hein.