HP3000-L Archives

August 2002, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"F. Alfredo Rego" <[log in to unmask]>
Reply To:
F. Alfredo Rego
Date:
Sat, 17 Aug 2002 21:17:18 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (198 lines)
A good friend of mine commented on my recent comments:

>>about *distributed* file systems.  I am still searching for
>>information on trivial (for MPE folks) things such as freaddir
>>and fwritedir, which have been "standard" on every release of
>>MPE since 1972 or so.


My friend wrote:

>Am I missing something or does an fseek() followed by an fread() or
>fwrite() not do the trick?
>In languages such as C you could write a short macro to define your
>own freaddir() or fwritedir().

And, indeed, this is a common way to do so.  But how primitive
(backward, benighted, unenlightened, raw, rough, crude, rude,
unpolished, barbaric, barbarous, uncivil, barbarian, uncivilized,
uncultivated, early, ancient, antediluvian, primordial -- fill in
your favorite adjective :-)

I would keep quiet but I have too much respect for HP's important
contributions to the advancement of worldwide file-system material.
Granted, HP's contributions with MPE date back to the early 1970s.
But they are still way ahead of (most of) the competition.
Why are people (particularly HP management) so arrogant when it
comes to MPE?  Please keep in mind that MPE -- according to
overweening people from other rarefied spheres -- is supposed to
be "old legacy stuff".  Dream on :-)

Few people defend MPE's file system in public.  I am happy to
do so.  And, believe me, I am NOT on HP's PR payroll.


>It would be very difficult to write a database or isam package
>without this ability, as I am sure you are quite aware.  Having said
>that, there must be a way because even the *nix folks wouldn't use
>the "elegant" algorithm of serially processing the whole file
>between two work files in order to get the results we want.

Of course not.  Here is an example, from SAP DB. You can download
the source from http://www.sapdb.org/develop/dev_linux.htm


Take one file out of the blue hat: SAPDB_ORG/sys/src/eo/veo100c

Yes, there is no "." before the "c" at the end -- perhaps a typo,
because other (not all) C source files in the "eo" directory (and
other directories) end with the standard ".c" for C and ".cpp" for
C++.

Perhaps I am missing some deep naming convention.  Given the
contents of the source file, though, you may wonder about a few
more things besides potential typos...

Here is one function from that source file, for your edification:

/*----------------------------------------------------------------*/
static int replace_page ( devsp, devsp_pos, pno, new_page)
/*----------------------------------------------------------------*/
FILE *devsp ;
int devsp_pos ;
int  pno ;
char *new_page ;
{
   long pos_to_seek = devsp_pos * PAGE_SIZE;
   int seek_ok      = fseek ( devsp, pos_to_seek, SEEK_SET ) == 0 ;
   if ( !seek_ok )
     perror ( "can't seek to specified position" ) ;
   else
     { char buf[PAGE_SIZE] ;
       seek_ok = fread ( buf, sizeof (char ), PAGE_SIZE, devsp ) == PAGE_SIZE ;
       if ( !seek_ok )
         perror ( "can't reading from specified pos" ) ;
       else
         if ( !(seek_ok = *((int *)buf) == pno ) )
           printf ( "\ninvalid page on specified position!(%d)\n",
                     *((int *)buf) );
         else
           { seek_ok = fseek ( devsp, pos_to_seek, 0 ) == 0 &&
                       fwrite( new_page , sizeof(char), PAGE_SIZE, devsp )
                       == PAGE_SIZE &&
                       fclose ( devsp ) == 0 ;
             if ( !seek_ok )
               perror ( "can't write new page to specified position" ) ;
           }
     }
   return ( seek_ok ) ;
}


---


Please notice the variable "seek_ok".  In how many semantic "moments of
truth" do you see this poor variable involved?  I know that memory was
a super-valuable resource in the old days of legacy systems.  Nowadays,
saving a few words of memory AND paying for the "saving" by recycling
the same variable for totally different purposes is not necessary.  This
is not sufficient to automatically generate errors, of course, but this
kind of "methodology" is an accident waiting to happen.  What's wrong
with defining a couple of other variables, such as "read_ok" and
"write_ok"?  Ok, ok: The function returns the value of "seek_ok", so
it would be awkward to have many different names.  With this reason
(very reasonable) in mind, then why not choose a neutral name that
applies to ALL the file operations?  How about something like
"result-ok".  Why use a specific name for many different instances
when a generic name will do (and will be less confusing)?

Please notice the nice error messages, all written in a consistent
style (never mind that they are all predicated on the falsehood of
the SAME variable, "seek_ok", which goes through quite a semantic
shake-up):

   can't seek to specified position
   invalid page on specified position
   can't write new page to specified position

And then, whamo, a message that obviously was written by somebody
else from another planet (or perhaps by the same person under a
different influence at a different time),

   can't reading from specified pos



...  Go figure.  Is this the way of the future?




>Comparing the richness of the MPE file system to the *nix file
>capability is obviously an apples and peanuts comparison since the
>*nix facilities are so primitive.  Perhaps there is an underlying
>set of undocumented file manipulation routines that all the
>"masters" use.

Or, as Oracle did, some people just bypass the *nix file
system and write their own.  There are quite a few alternative
file systems for Linux.  I use the Reiser File System (ReiserFS)
with SuSE Linux (as one of three native OSs on my Mac Titanium
PowerBook, a beautiful big-endian PowerPC machine -- this makes
Jeff Woods happy, because he can't stand little-endian machines :-)

For some history on Linux file systems, see this article from
December 2001:
http://www.extremetech.com/article2/0,3973,11602,00.asp

All users of MPE's file system will certainly appreciate the
strength and robustness of MPE.  MPE's file system is still
ahead of the competition.  HP: Please take note and be proud.

Among many things, the article mentions:

    JFS is the journalized file system designed and used by
    IBM. Proprietary and closed at first, IBM recently decided
    to make JFS freely available.

I didn't notice any HP contributions to the Linux file system
projects.  I wonder what the status of HP/Linux things will be
now that Bruce Perens has decided not to continue as an HP
employee.  Here is an article from two days ago about Bruce's
choice:
http://www.pcworld.com/news/article/0,aid,104016,00.asp

    Politics appears to have divided Hewlett-Packard and one
    of its top Linux engineers.

    Bruce Perens, an icon in the open source community and a
    senior strategist with HP's Linux software group, disclosed
    Thursday that he plans to leave the company in order to
    become more politically active, a move that has been
    ill-received by HP management, he said.
    ...


Time to finish writing this note.  Time to seek a good restaurant
where I can eat a good meal and read a good book.


Still on the road after LinuxWorld, your man in the street
and your informal reporter on technical and managerial issues,

   _______________
  |               |
  |               |
  |            r  |  Alfredo                     [log in to unmask]
  |          e    |                           http://www.adager.com
  |        g      |  F. Alfredo Rego
  |      a        |  Manager, R & D Labs
  |    d          |  Adager Corporation
  |  A            |  Sun Valley, Idaho 83353-3000            U.S.A.
  |               |
  |_______________|

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2