Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #54504 > unrolled thread

fseek under IBM MVS

Back to article view | Back to comp.lang.c

Contents

  fseek under IBM MVS jacob navia <jacob@spamsink.net> - 2014-12-14 22:16 +0100
    Re: fseek under IBM MVS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-15 01:12 +0000
      Re: fseek under IBM MVS jacob navia <jacob@spamsink.net> - 2014-12-15 09:13 +0100
        Re: fseek under IBM MVS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-15 09:22 +0000
    Re: fseek under IBM MVS Kaz Kylheku <kaz@kylheku.com> - 2014-12-15 16:26 +0000
      Re: fseek under IBM MVS raltbos@xs4all.nl (Richard Bos) - 2014-12-17 09:58 +0000
        Re: fseek under IBM MVS BartC <bc@freeuk.com> - 2014-12-17 11:29 +0000
    Re: fseek under IBM MVS John Bode <jfbode1029@gmail.com> - 2014-12-15 10:35 -0800
      Re: fseek under IBM MVS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-15 21:33 +0000
        Re: fseek under IBM MVS jacob navia <jacob@spamsink.net> - 2014-12-15 23:45 +0100
          Re: fseek under IBM MVS Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-12-15 17:56 -0500
            Re: fseek under IBM MVS Kaz Kylheku <kaz@kylheku.com> - 2014-12-15 23:05 +0000
            Re: fseek under IBM MVS BartC <bc@freeuk.com> - 2014-12-15 23:19 +0000
              Re: fseek under IBM MVS Keith Thompson <kst-u@mib.org> - 2014-12-15 16:36 -0800
              Re: fseek under IBM MVS Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-12-15 20:42 -0500
            Re: fseek under IBM MVS jacob navia <jacob@spamsink.net> - 2014-12-16 01:00 +0100
          Re: fseek under IBM MVS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-16 01:09 +0000
            Re: (OT) fseek under IBM MVS Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-16 09:11 +0100
          Re: fseek under IBM MVS raltbos@xs4all.nl (Richard Bos) - 2014-12-17 10:06 +0000
            Re: fseek under IBM MVS jacob navia <jacob@spamsink.net> - 2014-12-17 11:33 +0100
              Re: fseek under IBM MVS John Bode <jfbode1029@gmail.com> - 2014-12-17 08:48 -0800
                Re: fseek under IBM MVS raltbos@xs4all.nl (Richard Bos) - 2014-12-17 17:26 +0000
                Re: fseek under IBM MVS jacob navia <jacob@spamsink.net> - 2014-12-17 19:46 +0100
                  Re: fseek under IBM MVS Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 19:28 +0000
                    Re: fseek under IBM MVS jacob navia <jacob@spamsink.net> - 2014-12-17 21:38 +0100
                      Re: fseek under IBM MVS Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 21:05 +0000
                      Re: fseek under IBM MVS Ian Collins <ian-news@hotmail.com> - 2014-12-18 11:37 +1300
                  Re: fseek under IBM MVS John Bode <jfbode1029@gmail.com> - 2014-12-17 12:43 -0800
          Re: fseek under IBM MVS fir <profesor.fir@gmail.com> - 2014-12-19 08:35 -0800
            Re: fseek under IBM MVS BartC <bc@freeuk.com> - 2014-12-19 16:51 +0000
            Re: fseek under IBM MVS Robert Wessel <robertwessel2@yahoo.com> - 2014-12-19 16:36 -0600
      Re: fseek under IBM MVS raltbos@xs4all.nl (Richard Bos) - 2014-12-17 10:05 +0000
        Re: fseek under IBM MVS Keith Thompson <kst-u@mib.org> - 2014-12-17 09:05 -0800
          Re: fseek under IBM MVS raltbos@xs4all.nl (Richard Bos) - 2014-12-17 17:29 +0000
            Re: fseek under IBM MVS John Bode <jfbode1029@gmail.com> - 2014-12-17 12:55 -0800
              Re: fseek under IBM MVS John Bode <jfbode1029@gmail.com> - 2014-12-17 15:02 -0800
                Re: fseek under IBM MVS raltbos@xs4all.nl (Richard Bos) - 2014-12-17 23:37 +0000
                  Re: fseek under IBM MVS Keith Thompson <kst-u@mib.org> - 2014-12-17 16:11 -0800
                    Re: fseek under IBM MVS raltbos@xs4all.nl (Richard Bos) - 2014-12-18 12:06 +0000
                      Re: fseek under IBM MVS James Kuyper <jameskuyper@verizon.net> - 2014-12-18 11:44 -0500
                        Re: fseek under IBM MVS Keith Thompson <kst-u@mib.org> - 2014-12-18 11:03 -0800
                        Re: fseek under IBM MVS raltbos@xs4all.nl (Richard Bos) - 2014-12-19 11:31 +0000
                          Re: fseek under IBM MVS James Kuyper <jameskuyper@verizon.net> - 2014-12-19 08:03 -0500
                            Re: fseek under IBM MVS Keith Thompson <kst-u@mib.org> - 2014-12-19 08:08 -0800
                              Re: fseek under IBM MVS James Kuyper <jameskuyper@verizon.net> - 2014-12-19 11:30 -0500
                Re: fseek under IBM MVS Keith Thompson <kst-u@mib.org> - 2014-12-17 15:56 -0800
                Re: fseek under IBM MVS Ian Collins <ian-news@hotmail.com> - 2014-12-21 21:37 +1300
          Re: fseek under IBM MVS glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-17 21:59 +0000
            Re: fseek under IBM MVS Keith Thompson <kst-u@mib.org> - 2014-12-17 14:33 -0800
            Re: fseek under IBM MVS "Charles Richmond" <numerist@aquaporin4.com> - 2014-12-18 16:06 -0600
    Re: fseek under IBM MVS Siri Crews <chine.bleu@yahoo.com> - 2014-12-17 04:20 -0800

Page 3 of 3 — ← Prev page 1 2 [3]

#54988

James Kuyper <jameskuyper@verizon.net> writes:
> On 12/18/2014 07:06 AM, Richard Bos wrote:
>> Keith Thompson <kst-u@mib.org> wrote:
>>> raltbos@xs4all.nl (Richard Bos) writes:
>>> [...]
>>>> My problem is simply with depending on the wrong method when there is a
>>>> better one already available. It's similar to why I don't understand why
>>>> anyone would use strcpy() when they can do the same thing better, more
>>>> efficiently, and usually more reliably, with strcat(): even if the
>>>> difference is marginal, the cost is zero.
>>>
>>> How is strcat() an improvement over strcpy()? 
>> 
>> Sorry, typo/braino. I meant strncpy() and strncat().
>
> That makes more sense, though my own preferences differ. In most
> contexts in my code where I might need either one or the other of those,
> I already know the starting place for inserting new characters, and I
> need the unused portion of the array to be nulled out.  Every appearance
> of strncat() in code that I am currently responsible for was due to it
> being originally written by someone else.

Then you must be one of the few people who use strncpy() correctly.
Most uses of it that I've seen are by people who incorrectly assume that
it's a safer version of strcpy() in the same way that strncat() is a
safer version of strcat().

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#55052

James Kuyper <jameskuyper@verizon.net> wrote:

> On 12/18/2014 07:06 AM, Richard Bos wrote:

> > Sorry, typo/braino. I meant strncpy() and strncat().
> 
> That makes more sense, though my own preferences differ. In most
> contexts in my code where I might need either one or the other of those,
> I already know the starting place for inserting new characters, and I
> need the unused portion of the array to be nulled out.  Every appearance
> of strncat() in code that I am currently responsible for was due to it
> being originally written by someone else.

Surprising. Do you work for the NSA, or for a business which has reason
to believe the NSA is on its case? Because I can think of no other good
reason why you'd want to do that.

Richard

[toc] | [prev] | [next] | [standalone]

#55063

On 12/19/2014 06:31 AM, Richard Bos wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
> 
>> On 12/18/2014 07:06 AM, Richard Bos wrote:
> 
>>> Sorry, typo/braino. I meant strncpy() and strncat().
>>
>> That makes more sense, though my own preferences differ. In most
>> contexts in my code where I might need either one or the other of those,
>> I already know the starting place for inserting new characters, and I
>> need the unused portion of the array to be nulled out.  Every appearance
>> of strncat() in code that I am currently responsible for was due to it
>> being originally written by someone else.
> 
> Surprising. Do you work for the NSA, or for a business which has reason
> to believe the NSA is on its case? Because I can think of no other good
> reason why you'd want to do that.

The field I'm filling in the output file has a fixed length. I'm using
third-party library that copies an array of precisely that length into
the file, including the part after the end of the string. If I allow
random garbage to appear after the end of the string, output files that
are functionally identical will compare different when using Unix
utilities like cmp. This has bitten me often enough for me to decide it
needs to be prevented. In some of the files I'm working on, every text
field has a fixed length.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#55076

James Kuyper <jameskuyper@verizon.net> writes:
> On 12/19/2014 06:31 AM, Richard Bos wrote:
>> James Kuyper <jameskuyper@verizon.net> wrote:
>>> On 12/18/2014 07:06 AM, Richard Bos wrote:
>>>> Sorry, typo/braino. I meant strncpy() and strncat().
>>>
>>> That makes more sense, though my own preferences differ. In most
>>> contexts in my code where I might need either one or the other of those,
>>> I already know the starting place for inserting new characters, and I
>>> need the unused portion of the array to be nulled out.  Every appearance
>>> of strncat() in code that I am currently responsible for was due to it
>>> being originally written by someone else.
>> 
>> Surprising. Do you work for the NSA, or for a business which has reason
>> to believe the NSA is on its case? Because I can think of no other good
>> reason why you'd want to do that.
>
> The field I'm filling in the output file has a fixed length. I'm using
> third-party library that copies an array of precisely that length into
> the file, including the part after the end of the string. If I allow
> random garbage to appear after the end of the string, output files that
> are functionally identical will compare different when using Unix
> utilities like cmp. This has bitten me often enough for me to decide it
> needs to be prevented. In some of the files I'm working on, every text
> field has a fixed length.

Do they allow storing an N-character string in an N-byte field (which
means it won't be null-terminated)?  That's exactly the data structure
strncpy() was designed for.  Of course you have to be careful not to
assume that there's a null terminator (and I have no doubt that you
are).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#55080

On 12/19/2014 11:08 AM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
...
>> The field I'm filling in the output file has a fixed length. I'm using
>> third-party library that copies an array of precisely that length into
>> the file, including the part after the end of the string. If I allow
>> random garbage to appear after the end of the string, output files that
>> are functionally identical will compare different when using Unix
>> utilities like cmp. This has bitten me often enough for me to decide it
>> needs to be prevented. In some of the files I'm working on, every text
>> field has a fixed length.
> 
> Do they allow storing an N-character string in an N-byte field (which
> means it won't be null-terminated)?  That's exactly the data structure
> strncpy() was designed for.  Of course you have to be careful not to
> assume that there's a null terminator (and I have no doubt that you
> are).

Yes - I've mentioned this before - I think it was in a discussion with
you, several years ago. I remember that the person I was talking with
was amazed at the existence of anything for which strncpy() was an exact
match (other than the specific unix feature it was originally designed
to support).

[toc] | [prev] | [next] | [standalone]

#54897

John Bode <jfbode1029@gmail.com> writes:
[...]
> I'd favor stat since it doesn't require an open file descriptor/pointer.
> But if you already have an open file (via fopen), then fseek/ftell is
> probably the path of least resistance.  

If you already have an open file, you're probably still using it.
You'll probably want to:

    ftell() to remember where you are
    fseek() to the end
    ftell() to retrieve the size
    fseek() to get back to where you were

But then you might as well just use fstat(fileno(...)).

> And to be honest, if you're working on a filesystem where fseek/ftell don't
> give you a correct file size, you're probably already well aware of that
> fact and are using a different method anyway.  

And fstat() is moderately unlikely to exist on such a system.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#55173

John Bode wrote:
>
> Womped up a quick and very dirty test on a 64-bit SLES 10 system.
>
> Wrote 3 functions to get file size; one calls stat on the pathname, one
> opens the file and calls fstat on the descriptor, and the third opens the
> file and uses fseek/ftell on the file pointer.
>
> The functions that use stat and fstat take around 3 to 4 usec to run.  The
> function that uses fseek/ftell takes 15 to 20 usec.
>
> The sizes all report the same (one would hope).
>
> Of course, whether the performance difference means anything depends on
> the context.  If you're doing this for one file once over the lifetime
> of the program, it really doesn't matter.  If you're doing this thousands
> of times for an entire filesystem, then stat would probably be the better
> choice.

It will also depend on the filesystem.  For a example scanning a set of 
large files on my system, ZFS, the difference is much smaller:

419 files
File sizes (MB)

            value  ------------- Distribution ------------- count
               32 |                                         0
               64 |@                                        6
              128 |@@@@@@@                                  72
              256 |@@@@@@@@@@@@@@@                          154
              512 |@@@@@@                                   64
             1024 |@@@@@@@@@@@                              111
             2048 |@                                        11
             4096 |                                         1
             8192 |                                         0

Execution time (nS)

   sizeTestStat
            value  ------------- Distribution ------------- count
             1024 |                                         0
             2048 |                                         5
             4096 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  412
             8192 |                                         1
            16384 |                                         1
            32768 |                                         0

   sizeTestTell
            value  ------------- Distribution ------------- count
             2048 |                                         0
             4096 |@                                        12
             8192 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  406
            16384 |                                         0
            32768 |                                         1
            65536 |                                         0

Where:

long sizeTestTell( const char* file )
{
   FILE* handle = fopen( file, "r" );

   long result = -1;

   if( handle )
   {
     if( fseek( handle, 0, SEEK_END ) == 0 )
     {
       result = ftell( handle );
     }
     fclose( handle );
   }
   return result;
}

long sizeTestStat( const char* file )
{
   struct stat sb;
   int ok = stat( file, &sb );
   return (ok == 0) ? sb.st_size : -1;
}

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#54885

Keith Thompson <kst-u@mib.org> wrote:
> raltbos@xs4all.nl (Richard Bos) writes:

(snip)

>> Apart from the reliability issue, the fseek()/ftell() trick simply is
>> inefficient, in a way that fstat()/filelength()/GetFileSize()/&c.
>> aren't, if they're at all well implemented.
 
> On a system where it works, I woudnl't expect the fseek()/ftell() trick
> to be particularly inefficient.

By works, you mean for a stream of bytes file system?

For MVS, if you want the exact byte length, for variable length
records, you have to read the whole file and count them. For FBS,
you can read just the last track and count it. 

Disk addresses on MVS (back to OS/360) are eight bytes long, of the
form MBBCCHHR where the important ones are CC (16 bit cylinder), HH
(16 bit track within cylinder) and R (eight bit record within track).
That is what you need to know to seek and read a block.  

The OS/360 ISAM put disk addresses inside the file, which complicated
backups.  Just copying the bytes wasn't enough, as the addresses would
be wrong.  Similar to what happens if you write C pointers to a file.

Disk space is allocated in tracks or cylinders, not blocks. 

-- glen

[toc] | [prev] | [next] | [standalone]

#54887

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> raltbos@xs4all.nl (Richard Bos) writes:
>
> (snip)
>
>>> Apart from the reliability issue, the fseek()/ftell() trick simply is
>>> inefficient, in a way that fstat()/filelength()/GetFileSize()/&c.
>>> aren't, if they're at all well implemented.
>  
>> On a system where it works, I woudnl't expect the fseek()/ftell() trick
>> to be particularly inefficient.
>
> By works, you mean for a stream of bytes file system?

I suppose so.  More precisly, I'm referring to systems where the
fseek()/ftell() trick will reliably indicate (for a file no longer than
LONG_MAX bytes and assuming the file hasn't changed while this is being
done) the same size as reading the entire file a character at a type and
counting the characters read.  Of course I'd expect the latter approach
to be slower.

> For MVS, if you want the exact byte length, for variable length
> records, you have to read the whole file and count them. For FBS,
> you can read just the last track and count it. 

I presume that's accurate, but it's not relevant to my point, which
applies only to systems where the fseek()/ftell() trick works reliably.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#55005

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:m6sub5$8e4$1@speranza.aioe.org...
>
>             [snip...]                        [snip...] 
> [snip...]
>
> The OS/360 ISAM put disk addresses inside the file, which complicated
> backups.  Just copying the bytes wasn't enough, as the addresses would
> be wrong.  Similar to what happens if you write C pointers to a file.
>

This is like putting chalk marks on the side of a rented boat so you can 
remember where is the best place to fish.  After all, you may *not* get the 
same boat next time! ;-)

-- 

numerist at aquaporin4 dot com

[toc] | [prev] | [next] | [standalone]

#54834

In article <m6kumm$sfe$1@speranza.aioe.org>, jacob navia <jacob@spamsink.net> 
wrote:

> Some people keep repeating that the fseek function could not work 
> because some obscure machines do not support byte offsets.

Unix files are not ideal. They don't allow bytes to be inserted or deleted 
anywhere inside a file in near O(1) time, nor do they allow files to share 
common regions. Files could be represented as B-trees with sharable index and 
data nodes. Inserts and deletes edit the index tree instead rewriting the entire 
file. Different versions share common blocks and only diverge in the index trees 
where there are version differences.

A byte offset would be worthless if the byte position could always be changed by 
an insert or delete bytes. Instead you would want a current block id + block 
offset.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.
Be sure not to operate heavy machinery whilst on usenet.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web