HDTenEightyP/NetNews huggingface dataset:
From: dent@DIALix.oz.au (Andrew Dent)
Subject: Re: Software costs revisited?
Organization: DIALix Services, Perth, Western Australia
Date: Fri, 24 Jul 92 12:00:47 GMT

In comp.object, wgg@cs.ucsd.edu (William Griswold) writes:
>For maintenance, one desirable characteristic of a system is locality of
>change.  If an enhancement or repair can be implemented within one or two
>modules/classes (and it is not necessary to check every module in the system
>for consistency), then the design has succeeded in making the life of
>maintainers easier, and improves the chances of a reliable product.
                                                              
After nearly two years of (on and off) work on a magazine publishing system,
I'm a solid believer in OO for reducing maintenance hassles. Not only is the
locality of change a major benefit but it is easier to completely reimplement
behaviours because of greater conceptual modularity backed up by poly-
morphism (ie: you can subclass to reimplement a behaviour - something that 
is invariably messy to try to do in a functional oriented system).
 
After writing a FORTRAN->Pascal converter, another major OO benefit seen is
ease of incremental development - adding similar objects with slightly different
behaviour, instead of constantly revising central functions.

Andy Dent (A.D. Software - Mac & VAX programming)
94 Bermuda Dve, BALLAJURA  Western Australia  6066
Phone/Fax: 09 249 2719 (local)  +619 249 2719 (International)
       Internet: dent@DIALix.oz.au    Compuserve: 100033,3241

Newsgroups: comp.software-eng
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.software-eng,comp.arch.storage,comp.unix.internals
Subject: Re: Extent-based Filesystems (was: Large Application data sets )
Date: 27 Jul 92 02:15:38 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

pettengill@cvg.enet.dec.com () writes:
>Perhaps I've been using RSX and VMS for too long, so that they have pushed
>memories of other file systems into the dark alleys.  I can only think of
>two file systems that I know DON'T use extents: DOS-11 and AmigaDOS.
>DOS-11 and the older AmigaDOS file system version stored 500+ bytes of
>data in a block and the remainder of the block included the necessary
>information to find the next block.  I was really surprised to find that
>AmigaDOS, which was and is a very modern OS, used such a scheme.

	That was the "Old Filesystem" (or "Slow Filesystem"), which was
replaced about 4 years ago by the "Fast Filesystem".  OFS is still an option,
used almost entirely for floppies.  Note that OFS did not actually use that
information to find the next block; normally the fileheader and extension
blocks hold the lists of blocks.  The extra info in the block was for 
recovery.  

	OFS (and FFS) are not extent-based, but the next-block pointer has
nothing to do with that.  They are not extent-based because the extension
blocks hold lists of blocks, instead of starting block and length.

	OFS was a hold-over from Tripos, which AmigaDOS is a decendant of.

-- 
"Rev on the redline, you're on your own; seems like a lifetime, but soon it's
 gone..."  Foreigner
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Newsgroups: comp.software-eng,comp.arch.storage,comp.unix.internals
From: dafuller@sequent.com (David Fuller)
Subject: Re: Extent-based Filesystems (was: Large Application data sets )
Organization: Sequent Computer Systems Inc.
Date: Wed, 22 Jul 92 19:42:14 GMT

>
>Who implements extent-based filesystems commercially? How
>does it compare with the alternatives?
>
>I've still to scrape together the money to buy a UNIX
>machine where I can write my own brain-damaged filesystem.
>Everybody else seems to have done so ;-)

Well, CP/M had an extent-based file system.

Every proprietary OS I can think of has strongly typed files and that 
means extenting.

In fact, under Tandem's OS the UNIX style of file is given the name 
"unstructured files".  Even their editor spits out structured files...


-- 
Dave Fuller		 	All opinions expressed are my own and not
Sequent Computer Systems	those of Sequent Computer Systems, Inc.
dafuller@sequent.com
Xref: sparky comp.software-eng:2948 comp.arch.storage:542 comp.unix.internals:1605
From: grog@adagio.UUCP (Greg Lehey)
Newsgroups: comp.software-eng,comp.arch.storage,comp.unix.internals
Subject: Re: Extent-based Filesystems (was: Large Application data sets )
Date: 24 Jul 92 12:18:36 GMT
Followup-To: comp.software-eng
Organization: LEMIS, Schellnhausen 2, W-6324 Feldatal, Germany

In article <1992Jul22.194214.20451@sequent.com> dafuller@sequent.com (David Fuller) writes:
>>
>>Who implements extent-based filesystems commercially? How
>>does it compare with the alternatives?
>Well, CP/M had an extent-based file system.
>
>Every proprietary OS I can think of has strongly typed files and that 
>means extenting.
>
>In fact, under Tandem's OS the UNIX style of file is given the name 
>"unstructured files".

You seem to be confusing two things here: Tandem's file system is
extent-based, but this also applies to the `unstructured' files.

First, extents. The idea here is to allocate data in chunks larger
than a sector. Looking at it this way, ufs is an extent-based file
system (allocates up to 8K at a time). The way Tandem uses it, you
have to *specify* the extent size (well, you get a default of 2 pages
(of 2048 bytes each), but that can severely limit your maximum file
size). This applies to all files, both structured and unstructured.

Structured files, on the other hand, are either ENSCRIBE files, in
which the concept of a record and possibly a record key is introduced,
or the editor brain-damage you mention. ENSCRIBE has blocks of 512,
1024, 2048 or 4096 bytes, but they are still packed into extents.

> Even their editor spits out structured files...

Yes, the intention here was to compress text and maintain line
numbers, a sort of poor man's btree. It could have been implemented in
ENSCRIBE, but they needed an editor to write ENSCRIBE... In addition,
the editor can't understand plain text, there are almost no
programming utilities to read edit files, and the whole thing is a
disaster. As far as text compression goes, the edit files tend to be
about 20% larger than plain text.

-- 
Greg Lehey                       | Tel: +49-6637-1488              
LEMIS                            | Fax: +49-6637-1489
Schellnhausen 2, W-6324 Feldatal, Germany
*** NOTE ***: Headers are mangled - reply to grog%lemis@Germany.EU.net
From: dsanders@doc.bmd.trw.com
Newsgroups: comp.software-eng
Subject: Air Force 2167A Training
Date: 29 Jul 92 10:08:43 MST

TO:  Software Engineering Newsgroup

Several years ago, while a student in the Air Force's Information Systems-
Systems Engineering course at Keesler AFB, I was exposed to a training
document that explained the use of 2167 (not 2167A) in understandable
terms (true statement!).  I am currently working on a project with engineers
that would appreciate access to a training document such as this, but dealing
with 2167A.  Does anyone have access to such or know where I can get a copy?
I am tracking through Air Force channels, but the process is slow.  Any
help would be appreciated.

Thanks,
Dale Sanders 
phone: 801-625-8343
Newsgroups: comp.software-eng,comp.arch.storage,comp.unix.internals
From: bernie@metapro.DIALix.oz.au (Bernd Felsche)
Subject: Extent-based Filesystems (was: Large Application data sets )
Organization: MetaPro Systems, Perth, Western Australia
Date: Tue, 21 Jul 92 11:36:52 GMT

In <33120@cbmvax.commodore.com>
   jesup@cbmvax.commodore.com (Randell Jesup) writes:

>	"extent-based" means that instead of storing lists of blocks, you
>store lists of block ranges (extents).  For example, if you have a contiguous
>file 10MB long, it's stored as starting block and number of contiguous
>blocks (or starting and ending).  As you can see, this is great for storing
>(and seeking) in fairly unfragged files.  It doesn't get worse than lists
>of blocks unless it's average number of contiguous blocks is less than 2.

Understood. The main saving is that each block use doesn't
have to be explicitly named, unless it's at an extent end.
That would save I/O overhead.

>>Does it still allow sparse file?

>	You could design it to do so.  Normally I don't care much about
>sparse files - I think you'll find they don't actually save much on the
>average Unix installation - and some of the uses could be easily replaced.

Ever have a look at core dumps on a Sun? Badly maintained
machines have dozens of 8MB core dumps, though each
fortunately, consumes only a few disk blocks, but they are
fun to backup. (This is admittedly a sick excuse for sparse
files!)

The only rational existence I can think of for sparse files
is with memory-mapped (or similar) data files.

>> Could one still seek to the end of a 256MB file with only 4 block reads? 

> You could do it in 0 (on the assumption that the current position's
>file-list block is cached), if the file is reasonably contiguous.  You can
>also combine extents and heirarchical indirection blocks.

If it's cached, UNIX doesn't have to read it either ... but anyway:

Who implements extent-based filesystems commercially? How
does it compare with the alternatives?

I've still to scrape together the money to buy a UNIX
machine where I can write my own brain-damaged filesystem.
Everybody else seems to have done so ;-)
-- 
+-----+ Bernd Felsche                     _--_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /      \ bernie@metapro.DIALix.oz.au
| | | | 328 Albany Highway,              X_.--._/         Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: +61 9 362 9355
From: dgray@sadis01.sa.aflc.af.mil (1LT DOUGLAS S. GRAY)
Newsgroups: comp.software-eng
Subject: IFPUG - info anyone?
Keywords: Function Points, IFPUG, address
Date: 28 Jul 92 14:17:03 GMT
Organization: 1923CCSG/SC Kelly AFB, San Antonio, TX


	Does anyone out there know how I can get in contact with the
International Function Point Users' Group?  Are there local chapters -
particularly in the San Antonio-Austin, Texas area?  Any fees or publications?
Basically, I just know it exists and anything beyond that would be most
helpful.  

	Thanks,
	   Doug Gray
Xref: sparky comp.software-eng:2962 comp.arch.storage:553 comp.unix.internals:1618
From: shc@lhdsy1.lahabra.chevron.com (S.H. Couturie)
Newsgroups: comp.software-eng,comp.arch.storage,comp.unix.internals
Subject: Re: Extent-based Filesystems (was: Large Application data sets )
Date: 26 Jul 92 23:03:42 GMT
Followup-To: comp.software-eng
Organization: Chevron, LaHabra, CA

In article <1992Jul25.064903.21099@e2big.mko.dec.com> pettengill@cvg.enet.dec.com () writes:
>In article <1992Jul21.113652.4898@metapro.DIALix.oz.au>, bernie@metapro.DIALix.oz.au (Bernd Felsche) writes:
>
>|>In <33120@cbmvax.commodore.com>
>|>   jesup@cbmvax.commodore.com (Randell Jesup) writes:
>|>
>|>>	"extent-based" means that instead of storing lists of blocks, you
>|>>store lists of block ranges (extents).  For example, if you have a contiguous
>|>>file 10MB long, it's stored as starting block and number of contiguous
>|>>blocks (or starting and ending).  As you can see, this is great for storing
>|>>(and seeking) in fairly unfragged files.  It doesn't get worse than lists
>|>>of blocks unless it's average number of contiguous blocks is less than 2.
>
>|>Who implements extent-based filesystems commercially? How
>|>does it compare with the alternatives?
>
>Is this a trick question?
>


Check out SGI's IRIX with "EFS" - Extent File System - which certainly is
an extent based filesystem.  As of IRIX 4.0, also includes a defragger
(fsr).

Seems to work pretty well; check out the Unix Reviews I/O benchmarks:
SGIs tend to be pretty quick at disk I/O.

Steve
--
Steve Couturie                      Voice:     (310) 694-9332	
Chevron Information Technology Co.  FAX:       (310) 694-7709
P.O. Box  446                       Internet:  shc@chevron.com
La Habra, CA  90633-0446            UUCP:      ...!uunet!lhdsy1!shc
Newsgroups: comp.software-eng
From: sharpster@hns.com (Stephen Harpster)
Subject: Re: "Bang!"
Originator: sharpster@sharpster
Organization: Hughes Network Systems
Distribution: hns
Date: Wed, 29 Jul 1992 12:26:25 GMT


In article <1992Jul28.085235.8554@iccgcc.decnet.ab.com>, kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo) writes:
|> I suspect that this is in one of the FAQ's, so if it is, just please point. 
|> 
|> Can anyone please provide references to "Bang."  I believe that it is related
|> to module fan-in-fan-out, but am not sure of the actual mathematical
|> definition.

It's from Tom DeMarco's "Controlling Software Projects" (Chapter 9), New York:
Yourdon Press, 1982.

I don't have the book at my fingertips, but the bang metric is a relative
measure of the number and complexity of system requirements.  Since the
number and complexity of requirements is proportional to the effort needed
to implement them, bang measures can be used to predict project effort.

BTW, some CASE tools, such as Cadre's Teamwork, will calculate bang for you.
Newsgroups: comp.software-eng,comp.unix.questions
From: jimh@pacdata.com (Jim Harkins)
Subject: Source control systems
Organization: Pacific Data Products
Date: Wed, 22 Jul 1992 16:32:21 GMT

One of my co-workers has been tasked with deciding which software version
control system we should use.  Us Unix types are pushing for RCS-CVS, but
she wants to be thorough.  So what other packages are available?  We know
about SCCS, RCS, CVS, and PC-CVS.  Names of packages to investagate are
fine, short evaluations of the product is better.  Best are platitudes for
RCS-CVS and slams on everything else :-)  (nothing quite like an open
mind).

We are running SunOS 4.1.2, if there is an equivalent package for PC's
Karen would like to know.  We have no CASE tools, just make and gcc.

jim

-- 
Never name your character Clint Flicker
--------------------------------------------------------------
Jim Harkins                         [ucsd|uunet]!pacdata!jim
Pacific Data Products               jim@pacdata.com
--------------------------------------------------------------
From: bkottmann@falcon.aamrl.wpafb.af.mil (Brett Kottmann)
Newsgroups: comp.software-eng
Subject: Re: Byte me : ) (Was Re: Writing portable code)
Date: 20 Jul 92 15:31:25 EST
Organization: Logicon Technical Services, Inc.

In article <1992Jun30.131203.6737@sci.kun.nl>, caspar@sci.kun.nl (Caspar Terheggen) writes:
> In <2972@dozo.and.nl> jos@and.nl (Jos Horsmeier) writes:
> 
>>As I understand it (and I might be totally wrong here,) lowercase 
>>characters are used for the decimal powers (k= 10^3, m= 10^6 etc.)
>>and the uppercase characters for the powers of 2 (K= 2^10, M= 2^20 etc.)
> 
> In the SI uppercase letters are used for decimal powers of 10^6 and
> higher, e.g. MeV = Mega electronvolt, GW = Giga Watts (as in 1.21 GW), etc.
> The abbreviation for kilo however is a lowercase k, so this scheme does
> not work, unfortunately.  Pity really, it would be nice to have some
> sort of agreement on this.  Anyone?

	I'll byte :).

	How about k2byte for kilo (base 2) byte, k10byte for kilo (base 10)
byte, etc.

	kNbyte: k2byte or kilo2byte
	mNbyte: k10byte or mega10byte

Brett--------------------------------------------------------------------------
	"Why the courts don't tell a husband who has been living off his wife
to go out and get a job is beyond my comprehension."--Joan Lunden
-------------------------------------------------------------------------------
From: dgray@sadis01.sa.aflc.af.mil (1LT DOUGLAS S. GRAY)
Newsgroups: comp.software-eng
Subject: Re: SEI Process Maturity Model
Date: 31 Jul 92 14:49:50 GMT
Organization: 1923CCSG/SC Kelly AFB, San Antonio, TX

In article <1992Jul9.223354.26306@asl.dl.nec.com> 71033.536@compuserve.com (Terry Bollinger) writes:
>
>---------------------------------------------------------------------------
> 6. Level 5 organizations DO exist.  Look at the space shuttle software.
>---------------------------------------------------------------------------
>
>
>    I bet Level 1 -- *maybe*, just *maybe* Level 2 in a pinch.
>
>    Why?  Because the 1987-1992 questionnaire that is used to actually
>    assign a numeric rating is strikingly picky and arbitrary, making
>    the chances that even a quite decent organization will "hit" all the
>    right answers *without knowing the questions first* almost nil.
>
>				Terry Bollinger  71033.536@compuserve.com
>


   Interesting discussion.  Definitely some material to chew on for a while.
I find section 6 a bit troubling though.  I do not follow from your reasoning
how you can determine that Space Shuttle organization was a Level 1/2 back in
1987 because the questionare is "picky?"  It seems a rather gross leap of
logic; especially after seeing what their organization does and has done for
the last 15 years.  Yes, they would not have been a Level 5, five years ago
(and maybe that's the critical point), but a 1 or 2??  Not with the kind of
"in-control" process they described.  They obviously have had the key areas of
configuration management, project planning, project management and software
quality assurance all well-in-hand for a number of years.  Which, by defintion
of the CMM, would indicate that they were at least a level 2.  I could go on,
but I think my point is clear.  Could you clarify your logic?

	-Doug
Xref: sparky comp.software-eng:2940 comp.object:2986
From: pramoon@doi.cs.keio.ac.JP (Pramoon Sermsuk)
Subject: OO Development
Reply-To: pramoon@doi.cs.keio.ac.jp
Organization: Doi Lab., Dept. of Computer Science, Keio Univ., Japan.
Date: Tue, 28 Jul 1992 04:53:28 GMT


For my PhD research, which concerns Object Oriented Computing,
I'm looking for 
  - tools for OOA/OOD supporting methods from the most known authors like
    Booch, Rombaught,...
  - Some C++ code generators from the definition in the OOA/OOD tool.
Can you give me some more information? 
Can I find some free, publicly available, version?

Please e-mail directly.
Thanks in advance.

Pramoon
pramoon@doi.cs.keio.ac.jp
Newsgroups: comp.software-eng
From: dhg@scs.carleton.ca (Daryl Herbert Graf)
Subject: Want addresses for Esteva and Reynolds
Reply-To: dhg@scs.carleton.ca
Organization: School of Computer Science, Carleton University, Ottawa, Canada
Date: Thu, 23 Jul 1992 18:16:43 GMT

I would appreciate it if someone could pass along email addresses for 

Juan Carlos Esteva                   or   Robert G. Reynolds
   ORIS Department                           Computer Science Department           
   Eastern Michigan University               Wayne State University 
   Ypsilanti, MI                             Detroit, MI

Many thanks in advance...    Daryl Graf (dhg@scs.carleton.ca) 
Xref: sparky comp.software-eng:2909 comp.unix.admin:4246
From: stevef@bony1.bony.com (Steve Faiwiszewski)
Subject: Re: H. L. Mencken on ``software engineering''
Organization: Lost in NYC
Date: Mon, 20 Jul 92 22:40:16 GMT


My two favorite "engineering" titles are:

Sanitation Engineer: a garbage-man

Household Engineer: a housewife, oops, er.. homemaker (to be
         politically correct)

Sorry, couldn't help it ;-)

	- Steve -
-- 
Internet: stevef@bony1.bony.COM   |  ____________________________
bang : {uupsi,uunet}!bony1!stevef | / If cows could fly, everyone \
                                  ||| would carry an umbrella     ||
  Opinions? What opinions?        | \_____________________________/
Xref: sparky comp.software-eng:2919 comp.arch.storage:527 comp.unix.internals:1583
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.software-eng,comp.arch.storage,comp.unix.internals
Subject: Re: Extent-based Filesystems (was: Large Application data sets )
Date: 22 Jul 92 21:35:52 GMT
Followup-To: comp.software-eng
Organization: Auspex Systems, Santa Clara

>Every proprietary OS I can think of has strongly typed files and that 
>means extenting.

Err, could you please explain how "strongly typed files" "means
extenting", by which I assume you mean that any OS with "strongly typed
files" is therefore required to have an "extent-based file system"?

I don't see how having "strongly typed files" - by which I assume you
mean files where the standard "access method"s provide more than just
access to a random-access stream of bytes (or words, or whatever), and
where one of the attributes stored with the file is, in effect, the
access method to be used when accessing the file - requires an
extent-based file system.

In fact, I seem to remember reading, a long time ago, something from
Apollo indicating that the underlying bucket-o-bytes in the file system
was implemented in a fashion somewhat similar to the fashion in which
the UNIX V7 file system implements its bucket-o-bytes, i.e. some number
of direct block pointers pointing to the first few fixed-size blocks in
the file, some number of indirect block pointers pointing to fixed-size
blocks containing pointers to the next N fixed-size blocks in the file,
etc..

I.e., they didn't have an "extent-based file system", by which I assume
you mean a file system wherein the file map is a set of "extents", each
extent saying "the next N blocks of the file are the N blocks of the
disk or partition starting at block X".

I also think that, at the time, they had strongly-typed files in the
above sense, although I don't think they'd yet implemented the scheme
that lets *new* types be added - it just had a fixed set of access
methods.

Now, given that the *underlying* file system mechanisms *did* provide, I
think, a bucket-o-bytes, which got mapped into the process's address
space, either by the application itself or by the "access method" code,
maybe that doesn't count as an OS with "strongly typed files" (in which
case there now is a proprietary OS you can think of that doesn't have
strongly-typed files, namely Aegis).
Newsgroups: comp.software-eng
From: ricky@citr.uq.oz.au (Ricky Leung)
Subject: Re: Configuration Management
Organization: Prentice Centre, University of Queensland
Date: Thu, 30 Jul 1992 03:13:35 GMT

Erik_Brown@transarc.com writes:

>ben@bailey.UUCP (Ben Bailey) writes:
>> I'm particularly interested in commercial packages that run on HP Unix
>> systems. I work for a large company, and shareware, etc., can't be
>> considered, regardless of how good or cheap the product is.  They must be
>> commercial packages.

>The HP OpenView product is sold by HP and performs a number of
>management services.

As far as I know, OpenView is a network management product.  I am not 
sure how it can be used in Configuration Management.  Can you provide
more information?

>On this thread, does anyone know whether SNMP (System Network
>Management Protocol) or MIB (Management Information Base) documents
>are available on-line?  Any pointers appreciated.

RFCs on both areas (rfc 1157 and rfc 1156) are available via anonymous 
ftp.  There should be a number of ftp sites in the States holding the
rfc's.  If you couldn't find one, try this Australian site:

brolga.cc.uq.oz.au under the "rfc" directory.

>Erik Brown

--
Ricky Leung				    
Centre for Information Technology Research   Phone: +61 7 365-4321
The University of Queensland		     Fax:   +61 7 365-4399
Queensland  4072, Australia		     Email: ricky@citr.uq.oz.au
--
--
Ricky Leung				    
Centre for Information Technology Research   Phone: +61 7 365-4321
The University of Queensland		     Fax:   +61 7 365-4399
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: "Bang!"
Date: 28 Jul 92 08:52:35 EST

I suspect that this is in one of the FAQ's, so if it is, just please point. 

Can anyone please provide references to "Bang."  I believe that it is related
to module fan-in-fan-out, but am not sure of the actual mathematical
definition.

Email to kambic@iccgcc.decnet.ab.com.  Or post here.  Then we can start another
fun thread.

George Kambic
kambic@iccgcc.decnet.ab.com
"You can't win, you can't break even, you don't even know what game
you're playing."

Xref: sparky comp.software-eng:2914 comp.object:2961