HDTenEightyP/NetNews huggingface dataset:
From: raymond@es.ele.tue.nl (Raymond Nijssen)
Newsgroups: comp.unix.sysv386
Subject: Re: SpeedUp Sources and Patches on export.lcs.mit.edu
Date: 6 Apr 92 09:58:08 GMT
Organization: Eindhoven University of Technology, Eindhoven, The Netherlands
In-reply-to: glenn@cs.utexas.edu's message of 6 Apr 92 04:04:25 GMT

glenn@cs.utexas.edu (Glenn G. Lai) wrote:

>   Two suggestions for people who want even better performance:
>(1)  Get a faster processor.  A 33-Mhz 486 can double the text performance
>(2)  If your ET4000 board, like my Orchid, has DRAMs, using a slower dot clock

The performance depends *significantly* on the throughput of the IO bus.
A faster processor for X speedup is a waste of money without fast IObus.
It seems to almost linearly depend on the ATbus clock, so:

(3) Get a motherboard which offers an ATbus clock of up to CPU clock/2.
    E.g. ETEQ chipsets provide this (among others).

-Raymond.
--
| Raymond Nijssen         | Eindhoven University of Techology                 |
|                         | Department of Electrical Engineering              |
| phone: +31-40-473373    | Design Automation Section (ES),  Room EH 7.16     |
| raymond@es.ele.tue.nl   | P.O. Box 513, 5600 MB Eindhoven, The Netherlands  |
|                         | "Trust me. I know what I'm doing" (Sledge Hammer) |
From: karl@ttank.ttank.com (Karl Bunch)
Newsgroups: comp.unix.sysv386
Subject: Re: Dell kernel memory corruption
Date: 12 Apr 92 23:16:29 GMT
Reply-To: karl@ttank.com
Distribution: usa
Organization: Think Tank Software, Norwalk, CA

In <1992Apr11.234639.24045@digibd.com> rick@digibd.com (Rick Richardson) writes:

>I've noticed a corruption a of kernel data structure on Dell SVR4.
>This is on a stock system with no additional device drivers.

>Specifically, the value stored in linesw[0].l_open is getting corrupted.
>I've checked this by looking at the value just after all of the device
>driver XXXinit() routines are called, and then again after the system is
>booted multiuser.

>Just after the init routines are called, the value (for my system)
>is 0xd007034c (ttopen+0), which is correct.  However, after coming up
>multiuser, the value is 0xd0070050 (ttywait+64).  This corrupted
>value is very lucky, in that if you add device drivers that use
>the linesw[], they will just hang, rather than cause a kernel panic.

This is because domainname is writting your machine name into srpc_domain
and is overwritting your linesw table.

In /etc/rc2.d/S11uname you'll find:

    uname -S `cat /etc/nodename`
    [ -r /etc/domain ] && domainname .`cat /etc/domain`

I made the following change (And notified Dell support) to
/etc/conf/pack.d/kernel/space.c around line 247...

/*
** Tue Jan 28 14:27:11 PST 1992 - KEB
** Changed to 256 chars per manual page: domainname(4)
*/

char srpc_domain[256] = SRPC_DOMAIN;

It used to be:

char srpc_domain[] = SRPC_DOMAIN;

And SRPC_DOMAIN was "" on my system so it was rounded up to a word (4 bytes)
when the kernel was linked.  You'll find the declaration for linesw a
few lines down from this.  I ran into this problem trying to get
FAS 2.09 to work on Dell UNIX.  Boy what fun!  I wasn't as lucky: ttank.com
sort of caused the system to panic constantly! :-(

Try using: nm -xv /unix | less +/linesw
That's how I found out that srpc_domain was just above it and
only 4 bytes! :-)

Good Luck,
Karl
-- 
% ----------------------------------------------------------------------------
% Karl Bunch                        ||| UUCP: ..!uunet!cerritos.edu!ttank!karl
% Think Tank Software               ||| INTERNET: karl@ttank.com
% 42.5% of all quoted statistics are made up, of those 23.185% are right. :-)
Newsgroups: comp.unix.sysv386
From: sdw@bugatti (Steve Williams)
Subject: Re: Will vp/ix ever support Windows in enhanced mode?
Organization: Mead Data Central, Dayton OH
Date: Mon, 13 Apr 1992 05:22:48 GMT

grog@adagio.UUCP (Greg Lehey) writes:
: In article <1992Apr8.181747.13041@kong.gsfc.nasa.gov> sheldon@kong.gsfc.nasa.gov (Roger Sheldon - AISS) writes:
: >I was thrilled to get Windows 3.0 running under vp/ix under ISC 3.0.
: 
: Well, everybody to his own taste.
: 
: >Is it, as I suspect, impossible to run Windows in enhanced mode 
: >under vp/ix?
: 
: At least for the time being, yes. vp/ix runs virtual 8086's, which
NONONO.  It runs in virtual 80286 mode!!! You can run in standard/286
mode which is much better than real mode.  Still, not nearly as nice
as 386/enhanced mode....
: don't have `enhanced' mode. To handle Windows 3.1 in enhanced mode,
: you would need a virtual 80386 mode. I suppose that could happen, but
: I don't really see the need.

--
Stephen D. Williams    SDW Systems (513) 496-5223 Pager (513) 439-5428 VMail
Object Oriented R&D    Internet: sdw@world.std.com CIS 76244.210@compuserve.com
Source Distribution    By Horse: 10028 Village Tree Ct., Miamisburg, OH 45342
GNU Support            ICBM: 39 34N 85 15W
Xref: sparky comp.unix.sysv386:8727 comp.sys.intel:878 comp.lang.misc:1739 de.comp.os.unix:724
From: stroess@nrm6.UUCP (ROBERT STROESSENREUTHER / STROESS)
Newsgroups: comp.unix.sysv386,comp.sys.intel,comp.lang.misc,de.comp.os.unix
Subject: UNIX386 hosted Intel DTO Tools(ICEs,compilers for embedded controls)
Keywords: embedded controls 80186 unix sysv386 development tools
Date: 16 Apr 92 16:07:14 GMT
Followup-To: poster
Organization: SIEMENS Corp. AUT V151, 8012 Ottobrunn, Germany



Hello,
my bosses have asked my for an educated guess on how interesting
a portation of Intel's DTO tools for 80186 embedded applications,
e.g. the ICE-186 in circuit emulator, from their current DOS-based
version to a UNIX-386 System V.3 version would be for the developers
out there.
The reason they ask is that Siemens is already selling a couple
of UNIX ports of Intel DOS languages and utilities (C386, ASM386, RLL386,
AEDIT) and Intel ICEs (ICE386, ICE486, ICE386SX), done by Intel for
Siemens. Up till now it has found it's market, as there are lots of
tools available for the 386/486 reprogrammable market, however only
Intel's toolset has considered the special requirements of embedded
applications using 386/486 chips.

Anyhow, the 80186 is a very different type of CPU compared to the 386/486.

I would therefore really appreciate any comments whether to you
experienced developers out there a 80186 toolset for embedded
controls applications running on UNIX-386 based hosts sounds interesting.

Thanks in advance for your advice !


Robert F. Stroessenreuther    Email: stroess@nrm6.uucp
Siemens Munich/Germany        Dep. AUT 15 ST SK
Phone 49 (89) 4144 5915       Fax 49 (89) 4144 5962
From: lobsang@unixland.natick.ma.us (Michael Levin)
Newsgroups: comp.newprod
Subject: announcing availability of Unix/VMS backup product
Keywords: unix, vms, backup
Date: 15 Apr 92 22:35:49 GMT
Followup-To: poster
Organization: Maine Network Backup

|	     	      Announcing availability of
		Utility FOR Internet Archiving (UFORIA)
	       -----------------------------------------

     UFORIA is a full-featured utility that allows BACKUP and RESTORE
operations between any combination of Unix and VMS systems connected
by TCP/IP networks. The main features of UFORIA are:

VERSATILITY - any type of system (Unix or VMS) can be the data source
(client) or data repository (server) or both. Multiple clients can
simultaneously exchange data with multiple servers performing many
BACKUP/RESTORE operations at the same time. Operations can be
initiated by individual users, or operators on server nodes.

FUNCTIONALITY - the full set of necessary operations: backup/restore
of complete file systems as well as separate files, attended and
unattended modes, incremental and full backups, archiving, local
access to backup volumes, and multi-tape volumes. All VMS file types
are supported.

MANAGEABILITY - centralized and distributed control (job pausing,
aborting, etc.), multiple interactive monitoring tools, recovery
procedures, event and error logging.  Comprehensive and flexible
security features allow system managers to tailor UFORIA activity to
their security needs.

PORTABILITY - UFORIA supports multiple platforms, operating systems,
and backup devices (SUN Unix, Ultrix (VAX), Ultrix (RISC), VMS,
different tape devices).  VMS nodes require a TCP/IP package (we
currently support DEC's UCX and TGV's Multinet). A native user
interface is used for each supported operating system.

COMPATIBILITY - platform-independent data format allows you to save
and restore data between different platforms and still preserve
OS-specific file organization; backup tapes can be physically moved
to and read from other operating systems. Cross-platform restores are
supported (with appropriate name and file type changes, etc.).

     If you would like more information on this product, please email
to lobsang@unixworld.natick.ma.us 

UFORIA is produced by Maine Network Backup.

          Unix is a registered trademark of AT&T in the USA and other
          countries. Ultrix, VMS, DCL, UCX, and DEC are trademarks of Digital
          Equipment Corporation. Multinet is a trademark of TGV Inc. SUN
          is a trademark of Sun Microsystems Inc.
-- 
Ron Heiby usenet@chg.mcd.mot.com	Moderator: comp.newprod
From: crystal@StarConn.com (Paul Chen)
Newsgroups: comp.newprod
Subject: Netwroking Product Announcement
Date: 15 Apr 92 22:36:50 GMT
Followup-To: poster
Organization: Starnet-Public Access UNIX--Los Altos, CA  415-949-3133

Crystal Computing Corporation announces NetRunner, a $24.95 PC-based
remote control program that can run on all LAN platforms and modems.
Featuring remote control, remote execution, file transfer, remote
printing, and keyboard locking.

San Jose, California - Crystal Computing Corporation announces a
feature rich, low cost remote control program, NetRunner, which is
perfectly suitable for Technical Support, Computer Aided
Instruction, Remote Control, and Group Works. Running on all
PC/XT/AT/386/486s and 100% compatibles under MS-DOS 2.0 or higher,
NetRunner can reach out and control remote computers across Novell
LAN, NetBIOS based LAN, or even Wide Area Network connected by
modems. Once connected, the user can take over the re mote machine,
observe the progress of remote machine, co-work with remote user on
application programs, transfer files between connected machines,
print remote files on local printers or print local files to remote
printers, submit job to remote comp uter for execution, and read
remote directories.

NetRunner

Crystal Computing's NetRunner provides the following features.

Remote Control Functions:
You can take over remote computer, observe remote user's progress,
or co-work with remote user on application programs like Lotus 123,
dBASE III, or word processors, etc.

File Transfer Functions:
You can transfer files to or from remote computer without
interfering remote user's current work. Wild card file name
supported.

Remote Printing Functions:
You can print local files to any of the remote printers, or print
remote files to the local printers.

Remote Execution Functions:
You can edit a batch file and submit the job through NetRunner to
the remote machine. Then you can either observe the progress of the
remote machine, or go back to local to proceed other tasks. This
frees you from walking over to the remote machine t o execute and
watch programs.

LAN and WAN versions in one package:


NetRunner includes NetBIOS version, Novell IPX/SPX version, and
Modem (RS-232) version in one package. And they share the same user
interface.

Easy to install, easy to use:
Both installation program and NetRunner program are menu-driven.
Experienced users can also execute the program with parameters.

Availability and Price:
NetRunner is immediately available from Crystal Computing
Corporation. The U.S. suggested list price for the NetRunner Starter
Kit (2-user version) is $29.95. Each additional user: $24.95. Site
License: $124.95.

For more Information,

Contact:
Paul Chen
P.O. Box 9527
San Jose, CA 95157-0527
(408)446-1522
Order: (800)726-6209
Fax: (408)996-2899
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 14 Apr 92 17:30:49 GMT
Organization: /theta/theta5/unc/martinc/.organization
In-reply-to: ivler@mdcbbs.com's message of 8 Apr 92 15:17:18 GMT

In article <1992Apr8.151718.1@mdcbbs.com> ivler@mdcbbs.com (J.M. Ivler    ivler@mdcbbs.com) writes:

   Would you as a General Contractor to estimate the cost of building
   you a home on how many nails it will take?

Maybe yes, maybe no.  But if I knew that other things were equal -- as
they often are in software within a single organization -- I bet that
good guesses of the number of nails would be predictive.

   A "better mousetrap" was proposed by Steven Colborne and Dr. Hannes
   Callison of Magnavox Advanced Products and Systems Company in
   Torrance, CA. This system was called SAFE, for Syntatical Analysis
   For Estimation. It was mildly based one B.  Bohems work in cost
   modeling as well as the strict definitions that are required in DOD
   requirements documents.

What demonstration have you or can you cite that it is indeed a better
mousetrap?  How much calibration does it require?  Any less than Boehm's
methods which *are* SLOC-based?

I'll repeat my eariler question:  can anyone show me any citations for
statistically valid studies of the use of various size or volume
measures that show some other measure is significantly more predictive
than SLOC?  Everything I've ever seen shows: (1) that SLOC measures
properly calibrated are very highly predictive of cost [Boehm] and (2)
that every other volume measure that is predictive of cost is very highly
correlated with size in SLOC.

*PLEASE* don't just tell me that SLOC are silly, or make analogies like
"counting the nails"!  *PLEASE* try to recall that we're supposed to be
approaching this more or less scientifically!  We've got enough trouble
with religious wars about emacs vs vi.
--
Charles R. Martin/(Charlie)/martinc@cs.unc.edu/(ne crm@cs.duke.edu) 
O/Department of Computer Science/Sitterson Hall/UNC/Chapel Hill, NC 27599
H/3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
The universe is full of magical things patiently waiting for our wits to
grow sharper.  -- Eden Phillpot, I'm told.  Anyone have a better reference?
From: gowen@walt.tmc.edu (Lon Gowen)
Newsgroups: comp.software-eng
Subject: Re: Search for Dev.Tools
Date: 15 Apr 92 18:06:24 GMT
Organization: Mississippi State Univ.

In article <1992Apr15.160642.3168@tpki.toppoint.de> bohly@tpki.toppoint.de (Jens Bohlmann) writes:
>Wir  wollen mit einem Entwicklerteam von 5 bis 6 Leuten Standard
>( - Branchen)  Software entwickeln.  Da wir  uns nicht auf ein
>spezielles Betriebssystem  / eine Oberflaeche festlegen wollen,
>suchen wir Entwicklungswerkzeuge, mit denen man  fuer die
>verschiedensten Systeme Software entwickeln kann ohne auf die
>Vorteile grafischer Oberflaechen voellig zu verzichten.
>Insbesondere sind wir interessiert an :
>

I might be able to reply to this if I knew how to read German?

Lon
From: er1p+@andrew.cmu.edu (Erik Riedel)
Newsgroups: comp.software-eng
Subject: Re: Search for Dev.Tools
Date: 16 Apr 92 02:21:57 GMT
Organization: Senior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

I am not sure I understand why the subject line is English and the
question then in German but a translation of the German follows.  I'm
not sure if answers in English are welcome (helpful), but in the spirit
of internationalism:  [translators notes/comments]

We are a development team of 5 to 6 people developing Standard Software.
 Since we do not wish to limit ourselves to a specific operation system
or hardware platform, we are looking for Development Tools which we
could use on different platforms without completely sacrificing the
benefits of graphical interface.  We are particularly interested in:

- Tools to create Graphics [drawings I believe]
- Inclusion of various databases, particularly SQL
- Version and source code management
- Tools for documenting the development process

Possible operating systems are:

- DOS / Novell
- Unix
- VMS (Vax)

We have not yet decided on a particular platform at this time.

(Herr Bohlman, die meisten Leser dieser newsgroup spechen [sehr
wahrsheinlich] kein Deutsch, ich nehme an dass sie antworten auch in
English entgegennehmen, also habe ich uebersetzt [hoffentlich keine
grossen Fehler gemacht, ich bin schon mehrere Jahre in den Staaten...]).
 

[Please respond directly to Mr. Bohlman.  I don't really have the excess
time to act as translator]

Erik Riedel
Carnegie Mellon University
Pittsburgh, PA 15213
er1p+@andrew.cmu.edu
From: harkcom@spinach.pa.yokogawa.co.jp (Alton Harkcom)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 15 Apr 92 04:01:33 GMT
	<MARTINC.92Apr14133049@grover.cs.unc.edu>
Organization: Yokogawa Electric Corporation, Tokyo, Japan
In-reply-to: martinc@grover.cs.unc.edu's message of 14 Apr 92 17:30:49 GMT

In article <MARTINC.92Apr14133049@grover.cs.unc.edu>
   martinc@grover.cs.unc.edu (Charles R. Martin) writes:

 =}*PLEASE* don't just tell me that SLOC are silly, or make analogies like
 =}"counting the nails"!

   Might as well start off by raising the temperature... "SLOC isn't silly.
The way that is usually used is."

   The counting the nails analogy is a good one not in that lines = nails
but in that it exposes the major problem with all of the 'metrics'...
When one doesn't know the carpenter, one must have some way of determining
how well the carpenter can work.  The metrics use 'casual' [not causal]
relationships between quality and some easily measured objects to make
estimations.  Going the extra step and replacing "knowing the carpenter"
with "counting the nails" is where metrics go wrong...

 =}*PLEASE* try to recall that we're supposed to be
 =}approaching this more or less scientifically!

   Is there anything 'scientific' about SLOC?  pseudo-scientific maybe...

Al
From: daves@hpopd.pwd.hp.com (Dave Straker)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 11 Apr 92 10:35:47 GMT
Organization: Hewlett-Packard NSG-PWD, UK.

>The problem with the Lines of Code metric is really "what is a line of code"?
>...
>John

I would take a step back from this, and ask,

     "What is the purpose of measuring lines of code?"

If it is to measure the performance of programmers, then yes, it is
eminenently open to abuse, it will vary with style, etc.
Measuring people is an incredibly complex business, and measuring
their work is only one aspect of this. How do you measure the
effect they have on their team members, the design of the product,
the sales of the product, etc.?

Going back to basics, the objective of the company is to make
a profit and to survive to do it next year too. So what you
want to measure is the contribution towards that.

The key about measuring people is that the measure will signficantly
change their performance. So, if you can't find the right measure,
then it is probably more profitable not to measure them at all.

Dave Straker            Pinewood Information Systems Division (PWD not PISD)
(}-8]                   HPDESK: David Straker/HP1600/01
#define opinions mine   Unix:   daves@hpopd.pwd.hp.com
Newsgroups: comp.software-eng
From: leisner@johnker.henr801@xerox.com (Marty Leisner x76704 siena)
Subject: Re: "Lines of Code" Metric
Organization: Xerox
Date: Wed, 15 Apr 1992 01:33:55 GMT

I use line of code as an indication of complexity...all things being equaled (i.e. a programmers code), more lines indicates a harder problem.

I wrote this ditty to get lines of codes on a total project in a tree structure usingBrian Renaud's  kdsi program:


# Use kdsi to get totals
# First column is lines of code
# Second column is blank lines
# Third column is lines of comments
# Four column is number of comments
# Fifth colum is file name (or total)
#
# Xargs for some reason only uses 470 characters
#
# 
find . -name '*.[ch]' -follow -print | xargs kdsi |\
/usr/gnu/bin/gawk '\
{	if ($5 == "total") {\
		sloc = sloc + $1\
		blanks = blanks + $2\
		lines_comments = lines_comments + $3\
		num_comments = num_comments + $4\
	}\
} END { \
	print "Source lines:     ", sloc \
	print "Blanks:           ", blanks \
	print "Comment lines:    ", lines_comments \
	print "Num comments:     ", num_comments \
	print "Total lines:	 ", sloc + blanks + lines_comments \
   }' 




marty
leisner.henr801c@xerox.com
Member of the League for Programming Freedom
(You get what you pay for -- except in software)
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 16 Apr 92 11:52:48 EST

In article <1992Apr15.193735.7165@nmt.edu>, al@nmt.edu (Al Stavely) writes:
> 
> In article <MARTINC.92Apr14133049@grover.cs.unc.edu> martinc@grover.cs.unc.edu (Charles R. Martin) writes:
>>
>>I'll repeat my eariler question:  can anyone show me any citations for
>>statistically valid studies of the use of various size or volume
>>measures that show some other measure is significantly more predictive
>>than SLOC?  Everything I've ever seen shows: (1) that SLOC measures
>>properly calibrated are very highly predictive of cost [Boehm] and (2)
>>that every other volume measure that is predictive of cost is very highly
>>correlated with size in SLOC.
> 
> This may be, but even if there were a perfect functional relationship, valid
> for every program in the world, between SLOC and cost, it wouldn't affect the
> criticisms of the SLOC metric as it is commonly misused or hyped.  Neither
> SLOC nor cost *predicts* the other, in the common sense of the word, because
> you don't know either one until the product is completed.  Same for all the
> rest of the size and volume metrics.  They are all equally useless for
> estimating the cost of a project before you start writing the code, which is
> the crystal-gazing that managers really want.  Boehm's work is interesting,
> but it doesn't really help much.  If you can guess SLOC accurately enough to
> be useful, you probably could have guessed cost just as well.
I presume only the cost of development.
> 
> Sure, I'm willing to believe theories about SLOC or other volume measures of
> completed code as a predictor of future maintenance effort of that same code,
> or something like that.  But let's try to be realistic about what we claim
> metrics can really *predict*.  After-the-fact correlations aren't the same
> thing.
> 
But that's the whole point of prediction and measurement.  IMHO you seem to be
saying that we should not be making estimations because they are not correct. 
It is only by measurement and feedback that models constructed by Boehm and
others can be corrected and hopefully eventually converge.
> 
George Kambic
standard disclaimer
From: pgh@bnr.co.uk (Peter Hamer)
Newsgroups: comp.software-eng
Subject: Re: "Lines of Code" Metric
Date: 14 Apr 92 14:46:13 GMT
Reply-To: pgh@bnr.co.uk (Peter Hamer)
Organization: BNR Europe Limited, London Road, Harlow, Essex, GB

In the referenced article jerry@ajones.austin.ibm.com writes:
|In article <7APR199214170281@adpdp2.lanl.gov>, 105126@adpdp2.lanl.gov
|(John Curtis) writes:
| 
|More to the point, how do you count modified lines of code?  In a development
|shop that goes through mulitple releases of the same software, counting lines
|of code becomes a tricky exercise.  Obviously in the first release you count
|lines of code because its all new.  In subsequent releases what do you count?
|Obviously you can't just count total lines of code because that gives an 
|unrealistic (IMHO) number as to the amount of coding that was done.

As a start try --

a) Run the code through a pretty-printer to standardise layout.
b) Remove leading white space on lines (otherwise changes to nesting levels
   causes problems).
c) Use UN*X diff or similar to compare with a previous version.

Regards, Peter