HDTenEightyP/NetNews huggingface dataset:
From: jerry@austin.ibm.com (Jerry Heyman)
Subject: Re: cscope? trus?
Originator: jerry@dcheney.austin.ibm.com
Date: Mon, 21 Dec 1992 15:08:23 GMT
Reply-To: jerry@austin.ibm.com
Organization: IBM AIX AWSD Austin, TX
Keywords: debugging


In article <BzH2K4.1uz4@austin.ibm.com>, jerry@austin.ibm.com (Jerry Heyman) writes:
|> 
|> A user has just approached me asking if we have (or can get access to) a
|> program called cscope.  It is a file browsing tool which will index and load
|> files from a given directory and index based on the function names, identify
|> where it is called and give the use the ability to switch immediately into
|> that particular file/function call.  I don't know if this is PD or a commercial
|> product, but if anyone is familiar with this I'd be glad to hear about it.
|> 
|> Also, a program called 'trus' (or something similar) that will monitor a
|> command and return back a list of each system call that is made, along with
|> the first couple of arguments to that system call, and the actual return code
|> from the system call.  Again, I do not know if it is PD or commercial, but if
|> anyone is familiar with this I'd be glad to hear about them.
|>

Many thanks to the overwhelming response from the USENET community.  What has
been conveyed is the following:

	1) 'cscope' comes from the AT&T Toolchest and is believed to be
	   separately purchaseable

	2) 'truss' is another SysV program, and is also believed to be part
	   of the Toolchest.

Many thanks again to all that have responded.  Also special thanks to:

Todd Eigenschink (eigenstr@CS.Rose-Hulman.Edu) for suggesting I look at
wuarchive.wustl.edu. for information.

jerry
-- 
Jerry Heyman                         e-mail   : jerry@austin.ibm.com
IBM AWSD AIX Dev Env Tools MS 9631    "Software is the difference between
Austin, TX  78758                        hardware and reality"
*** All opinions expressed are exactly that - my opinions and NOT IBM's
Newsgroups: comp.software-eng
From: shanks@saifr00.cfsat.honeywell.com (Mark Shanks)
Subject: Re: When do we inspect
Organization: Honeywell Air Transport Systems Division
Date: Mon, 21 Dec 92 21:56:42 GMT

In article <1992Dec21.184224.21056@den.mmc.com> jhull@vulcan-gw.den.mmc.com writes:

>In article 6r0@NeoSoft.com, 
>claird@NeoSoft.com (Cameron Laird) writes:
>cl> I assert:  source code should go into the CM system
>cl> from its first day.  ...  Some object
>cl> that checking in source is too much overhead; for
>cl> me, that's only a symptom that the check-in process
>cl> isn't yet adequate.  Coders should *want* the benefits
>cl> of even the most rudimentary CM:  automated regression
>cl> testing, static semantic analysis, validation of
>cl> porting considerations, ...
>
>Au contraire.  Since we are not yet, and may never be, at a
>point where we all think alike and work alike, I suggest that
>each programmer should be allowed to do his or her own work 
>in whatever manner allows them to be most productive.  If
>that involves some form of CM, fine.  But if not, so what.
>
>I suggest that a unit of code should enter a "Software
>Development Library" at the time when the individual team
>member has finished coding and unit testing it

>I further suggest that there should be a "Project Software
>Library" controlled and managed by a Software Quality
>Assurance group/team/organization, and that Unit A must be
>entered in the PSL prior to being released for use by Team
>B.

I believe Cameron misunderstood me, or perhaps has a different
working model for "CM" than I do. I was referring to a simple
"vault" type of tool; no regression testing, no semantic analyses,
no nothing but a freeze on the code and enforced procedures to
check it out and make changes.

I guess Jeff's description of a "SW Development Library" is
less restrictive than a typical CM system. I can understand
a customer's desire for tracking changes, but IMHO, taking a
"snapshot" at CDR time accomplishes that function without
incurring the truly prodigious overhead entailed by some
CM systems (check out package, make changes, inspect, fill
out software change request (SCR) form, meet with configuration
control board, edit SCR, check package back in, get change from
customer, goto line 1). I'm on a program using Ada, heading a
team of 10 software designers producing well over 200 Ada
packages and close to 20,000 LOC. Multiply that by 30 or 40
such teams and see how much time will be spent on CM alone.
Why start that process any sooner than necessary?

Mark Shanks
shanks@saifr00.cfsat.honeywell.com
Newsgroups: comp.software-eng
From: mat@mole-end.matawan.nj.us
Subject: Re: When do we inspect [getting LONG]
Keywords: Inspections
Organization: :
Date: Fri, 25 Dec 1992 08:16:08 GMT

In article <1992Dec23.162649.16555@saifr00.cfsat.honeywell.com>, shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
> In article <Bzo1ML.GK6@NeoSoft.com> claird@NeoSoft.com (Cameron Laird) writes:
> >    Mr. Shanks, are you saying that you approve of the way it is, or
> >    that you're stuck with something you see as suboptimal, and therefore
> >    you don't wish to "start that process any sooner than necessary"?  ...
> >    ...  It would make me feel as though I'm in a trailer factory, say,
> >    welding away on my assigned joints, and I notice that I need more
> >    light on my worktable to jig up the pieces carefully.  I get the
> >    feeling that, in the factory where you work, I'd have to call a
> >    meeting of the union first.  Is there no cheaper way for me to
> >    improve my process?

Your proposed improvement is needlessly selfish: if you are short of
light it is possible that others are also.

The proper procedure is to get the light put in, get your shop steward
to put in a claim to get you paid for the light, then raise the issue of
adequate lighting at the next regularly scheduled union meeting ...

It's not a question of the cheapest possible benefit, but of the most
benefit for the money.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.software-eng
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: Debugging the process
Organization: Motorola Codex, Canton, Massachusetts
Date: Thu, 31 Dec 1992 14:12:54 GMT

First, let me clear up some ambiguities in my last post - I wrote:

>kirby.roch803@xerox.com (Mike Kirby) writes:
>>All the SEI is saying is that you need to have a management process in
>>place [...]
>
>This is the clearest statement I've seen yet of the SEI
>misunderstanding that generates so much opposition among engineers.

I meant to say that the SEI misunderstood, not that Mike misunderstood
the SEI.

Anyway, back to the discussion:

kirby.roch803@xerox.com (Mike Kirby) writes:
>If good engineering is performed under bad management it is because if
>the skills of the people.  When those people leave, the bad management
>will "take over" and everything will be back to level 1.

Agreed. However, this is a characteristic of any field, from software
engineering to burger flipping.

>Contrary to popular belief, software engineering is more management
>than engineering.  If a stable management process exists, and no
>engineering exists, a stable product can still be delivered.  And this
>is indepenedent of the engineering talent inthe organization.

As an engineer who was under the impression that my employer was
better off if I come to work than if I stay home and draw my pay, I
find it hard to believe this statement.

jeh@cs.rit.edu (James E Heliotis) writes:
>[...] kirby talks about an engineering PROCESS, which is part of what
>SEI is trying to tell us.  You (peterd@pjd.dev.cdx.mot) are saying, I
>think, "Given a group of good engineers, they can do a good job, with
>or without the support of management."

I think we would all agree that good management is strongly correlated
with good engineering; however I would argue that it is neither
necessary nor sufficient. Another way of stating this principle would
be that the quality of engineering embodied in a product can be judged
without considering the management of the product development.

Unfortunately, the SEI model concentrates on the engineering process,
and the management framework within which the engineering process
occurs, to the point of excluding consideration of the *engineering*
itself. 

				Peter Desnoyers
-- 
Newsgroups: comp.software.licensing
From: sammy@world.std.com (Samuel Murphy)
Subject: Re: Licence server products wanted.
Organization: The World Public Access UNIX, Brookline, MA
Date: Tue, 22 Dec 1992 04:20:35 GMT

In article <1992Dec21.174254.20979@engage.pko.dec.com> gibian@ljohub.enet.dec.com writes:
>
>Digital also has a product in this area which may be of interest.


Could you post some details? 


>--
>Marc S. Gibian			email: gibian@talent.ljo.dec.com

Sam Murphy
sammy@world.std.com
From: gibian@talent.ljo.dec.com (Marc S. Gibian)
Newsgroups: comp.software.licensing
Subject: Re: Licence server products wanted.
Date: 21 Dec 92 17:42:54 GMT
Reply-To: gibian@ljohub.enet.dec.com
Organization: Digital Equipment Corporation


Digital also has a product in this area which may be of interest.
--
Marc S. Gibian			email: gibian@talent.ljo.dec.com
Principal Software Engineer	phone: (508) 486-6598
Digital Equipment Corporation	fax:   (508) 486-6648  or (508) 486-6100
Newsgroups: comp.software.licensing
From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Merge Ahead v2.1 released
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Thu, 24 Dec 1992 07:10:27 GMT


Earlier, I promised that I would tell comp.software-eng readers when
the new release of our Merge Ahead software (v2.1) was shipping. Well,
we formally announced the new version for immediate availability
today.  A press release has been submitted to BusinessWire, and also
to comp.new-prod.  A copy of this press release is available for
anonymous FTP from ~ftp/pub/mcgregor/merge-aheadv2.1/v2.1press-release
on netcom.com, I won't repost it here.  The key features of this new
release are that we support  more computer platforms now, and we have
redesigned around a Motif limitation that previously limited the size
of the files that you could merge--this limitation is completely gone
now. Also, integrations to RCS and SCCS are now in a contributed
library, and integrations to Atherton Software BackPlane and
CASEWare/CM are available from Atherton and CASEWare respectively.

A demonstration version of Merge Ahead is also available by annonymous
FTP from netcom.com -- see the README file in the
~ftp/pub/mcgregor/merge-aheadv2.1 directory for details.

A 50% off introductory promotional price is available through January
31,1993.

I'm not sure who is keeping the CASE products FAQ these days, but it
would be appropriate to add Merge Ahead v2.1 to the CASE FAQ.  The
release has all the relevant information I think, if not, please
contact me for additional information.




-- 

Scott L. McGregor		mcgregor@netcom.com
President			tel: 408-985-1824
Prescient Software, Inc.	fax: 408-985-1936
3494 Yuba Avenue
San Jose, CA 95117-2967

Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
offers consulting  & training in project management and design for usability.
From: goutal@hammer.crim.ca (Jean-Michel Goutal)
Newsgroups: comp.software-eng
Subject: Petri nets
Keywords: petri nets simulation
Date: 22 Dec 92 21:12:26 GMT
Reply-To: goutal@hammer.crim.ca
Followup-To: freedman@crim.ca keller@crim.ca goutal@crim.ca
Organization: Computer Research Institute of Montreal

Hi,

We are currently doing a comparative study about tools based on Petri nets 
for simulation.
Our interest is not only for commercial tools, but also tools used or 
designed by university or other research centers.

So far, we have identified the following:

Tool			Compagny
----			--------
PACE			GPP
ELSIR			ADV technologie
SES workbench		Scientific & Engineering Sotware
G++			SYCO
SEDRIC			Techlog
GSPN			University of Turino
SPNP			University Duke
Design/CPN		MetaSoftware
Eval			Verilog
Voltaire		McGill university
TeamWork/sim		Cadre technologies
Adas			Cadre technologies


Does anyone know other products or comparison studies?

Thanks by advance


---
Jean Michel Goutal
Conseiller Genie Logiciel
From: defaria@hpcuhe.cup.hp.com (Andy DeFaria)
Newsgroups: comp.software-eng
Subject: Re: C Code Layout
Date: 21 Dec 92 23:49:23 GMT
Organization: Hewlett Packard, Cupertino

>/ hpcuhe:comp.software-eng / phardie@nastar.uucp (Pete Hardie) /  8:03 am  Dec 18, 1992 /

>>To me, such statements, while they require a close, should not require an
>>open.

>I disagree.  Symmetry is desirable in a language. 

Symmetry for symmetry's sake is not a good argument in my book.

>>In other words the assumption should be that I always have a compound
>>statement and must tell the compiler when it's done.

>Again, I disagree.  Since a compaund statement is lexically identical to a
>single statement, they should have the same form.

Again a consistancy argument.  While I agree that consistancy is important,
I'm not often thinking about lexically identity when writing code.  I'm more
concerned with it's readablity, look and flow.

>>C required that I also specify an open but I see no reason to devote a full
>>line to it!  I detest:
>>
>>	if (condition)
>>	   statement;
>>   statement;
>
>I don't quite understance why this bothers you.  

Because it's too easy to mess up the alignment and end up with:

	if (condition)
	   statement;
	   statement;

and because it's too much of a bother to have to enclose it in braces merely
to insert a debugging printf.

If you argue for consistancy then by always specifying braces you are more
consistant but my argument is more "Every if statement opens, look for the
closing brace".

>>	if (condition) {
>>	   statement;
>>	} /* if */
>>
>>	statement;
>>
>>Note I label my terminating close (}).  Now think about it.  When eyeballing
>>the above code and reading the if statement: Do you really care where it has
>>opened or when it has closed?  To me the open is inconsequential: Of course it
>>starts but where does it end?
>
>I think that this is why I prefer the braces on separate lines - to make
>their associations clear.  

Again, to me the opening brace is inconsisquentcial (sp?) and needless
syntaxtic sugar.  I guess I got this from programming in Modula-2 for a while.
After working with a "all if's are compound - just tell me when they close"
for a while I got used to it and said "This makes sense".  Again this is only
my opinion.

>I dislike a comment that is placed for syntactic reference.  I prefer
>comments be reserved for semantic clarification.  In some of the code I've
>seen, there would be a forest of /* if */'s hiding the desired semantic
>information.

I got used to this from Ada and it's "end if"'s and the like.  Again, it made
sense to me to designate the end of such things as if's, while's, etc.  Sure
having more information about exactly what thing this is brace is closing
would be even more helpful but then you have to duplicate the (condition)
From: drake@Autodesk.COM (Dan Drake)
Newsgroups: comp.software-eng
Subject: Re: Author-less inspections (was: Software Inspections.  How many does it take?)
Date: 21 Dec 92 18:21:45 GMT
Organization: Autodesk Inc., Sausalito CA, USA

claird@NeoSoft.com (Cameron Laird) writes:
+ I have no experience with reviews in which the
+ author(s) is (are) *not* present, but I like
+ the idea; is there anyone who can report on how
+ that works in practice?
+ 
+ My attraction to this has nothing to do with
+ "ego"; I just want to have the documents stand
+ on their own, without the explanations that the
+ author(s) inevitably carri(es).

I haven't tried this either, but the author's presence could be put to
good use here:

If the author explains a piece of the code, the person taking notes
marks this piece of code as inadequately documented.  Of course, on
reflection it may turn out that the code is not inadequately documented,
but just a poor piece of design; either way, you've spotted something
that needs correction.

--
Dan Drake                 Therefore, send not to know for whom the bell tolls;
drake@Autodesk.com        It tolls for Them.
Newsgroups: comp.software-eng
From: kirby@xerox.com (Mike Kirby)
Subject: Re: Appeal to SEI (was: Debugging the proc
Reply-To: kirby.roch803@xerox.com
Organization: Xerox Corporation, Webster NY
Date: Mon, 28 Dec 1992 22:01:47 GMT

In article 20735@asl.dl.nec.com, terry@asl.dl.nec.com writes:
>Hi folks,
>
>In article <1992Dec28.113148.15707@sei.cmu.edu> mcp@sei.cmu.edu
>(Mark Paulk) writes:
>
>> What we intend the CMM to say is that an organization has to have a good
>> metrics program in place to achieve level 4...  We do not say that an
>> organization cannot, or should not, have metrics in place much earlier...
>> The belief that the SEI requires that "you have to be level 4 to do
>> measurement" is a fairly widespread misconception that we have tried
>> repeatedly to correct...
>
>From the perspective of a critic, I would definitely concur that the SEI
>concept of process progress has always had a strong metrics flavor from
>the get-go.  It shows up clearly in level 2, let alone 3 and 4.  Indeed,
>one of my complaints was that it unclear what a level 2 organization as
>defined in early SEI materials would DO with their metrics it was clearly
>supposed to collect.

KEY KEY point.  What do you do when you collect process metrics from a level 2 
organization.  This means that your metrics are management metrics, and there
are no engineering metrics because you have no engineering process.  Now that
we have our measurements, at some point we must decide that our process is
bad based on our measurements and then change the process to bring our
metrics back to a reasonable level.  However, we have no way of determining
how this will affect the engineering non-process.  If we had a process,
we could measure it, and we could measure the effect of management process change
to ensure that it isn't causing any undo problems.  Of course this doesn't even
begin to talk about what are the "right" metrics and what are the "correct"
values.

It is my belief that product metrics are much more effective in non-process
shops.  It is fairly easy to measure something like defects/kloc or complexity,
and order additional testing or longer development time based on those numbers.


>
>
>				Cheers,
>				Terry Bollinger
>
>
>+--------------------------------------------+-------------------------------+
>| Terry Bollinger                            | Phone: 214-518-3538           |
>| Advanced Switching Laboratory, NEC America |   Fax: 214-518-3499           |
>| 1525 Walnut Hill Lane, Irving, Texas 75038 | Email: terry@asl.dl.nec.com   |
>+--------------------------------------------+-------------------------------+



Mike Kirby
Xerox Corp
E-mail: kirby.roch803@xerox.com
From: sammy@smds.com (Samuel Murphy)
Newsgroups: comp.software-eng
Subject: Re: average identifier length (was Comments: Code...)
Date: 23 Dec 92 14:58:28 GMT
Reply-To: sammy@ishmael.UUCP (Samuel Murphy)
Organization: Software Maintenance & Development Systems, Inc.


>
>THE TOOL IS THE SERVANT, NOT THE MASTER!!!
>

The exception is X windows.


... oh, yea, this may deserve a :-) ,  but then again ...


Sam Murphy
sammy@smds.com
Newsgroups: comp.software-eng
From: terry@asl.dl.nec.com
Subject: Re: Appeal to SEI (was: Debugging the process)
Originator: terry@aslss01
Keywords: "sei cmm" "sw engineering" "process improvement" "sw quality"
Organization: (Speaking only for myself)
Date: Mon, 28 Dec 1992 19:39:11 GMT

Hi folks,

In article <1992Dec28.113148.15707@sei.cmu.edu> mcp@sei.cmu.edu
(Mark Paulk) writes:

> What we intend the CMM to say is that an organization has to have a good
> metrics program in place to achieve level 4...  We do not say that an
> organization cannot, or should not, have metrics in place much earlier...
> The belief that the SEI requires that "you have to be level 4 to do
> measurement" is a fairly widespread misconception that we have tried
> repeatedly to correct...

From the perspective of a critic, I would definitely concur that the SEI
concept of process progress has always had a strong metrics flavor from
the get-go.  It shows up clearly in level 2, let alone 3 and 4.  Indeed,
one of my complaints was that it unclear what a level 2 organization as
defined in early SEI materials would DO with their metrics it was clearly
supposed to collect.

You cannot do something well if you cannot see what you are doing.  The
question is more one of what metrics give insight, and what ones will
ultimately prove illusory in terms of how much warning and insight they
provide to bottom-line production, quality, schedule, and cost.  Even
one-man projects need metrics from that perspective.

				Cheers,
				Terry Bollinger


P.S. -- Thanks to Dr. Leveson for that little jaw-dropper on concurrent
        engineering & risks of *REAL* project blowups, missile-silo-style!

        (Hmm... Why did that description of the dangers of everyone working
        in parallel, without well-defined definitions of how things would
        finally fit together, remind me of one or two software projects
        I've seen??)

+--------------------------------------------+-------------------------------+
| Terry Bollinger                            | Phone: 214-518-3538           |
| Advanced Switching Laboratory, NEC America |   Fax: 214-518-3499           |
| 1525 Walnut Hill Lane, Irving, Texas 75038 | Email: terry@asl.dl.nec.com   |
+--------------------------------------------+-------------------------------+

Newsgroups: comp.software-eng
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: Debugging the process
Organization: Motorola Codex, Canton, Massachusetts
Date: Tue, 29 Dec 1992 20:57:18 GMT

kirby.roch803@xerox.com (Mike Kirby) writes:

[lots of interesting points...]

>All the SEI is saying is that you need to have a management process in
>place before an engineering process will be able to take hold.  and you
>need both processes before you can determine if a product failure is
>due to engineering or to management.  AND you need to be able to
>measure both.  Once you can do these things then you will be able to
>continously improve the processes.

This is the clearest statement I've seen yet of the SEI
misunderstanding that generates so much opposition among engineers.

Management is not engineering. Management has the ability to hinder
engineering, and it has the ability to facilitate it. However, good
engineering can be performed (with difficulty) under bad managers;
conversely, good management does not guarantee good engineering.

				Peter Desnoyers
-- 
Xref: sparky comp.software-eng:5186 comp.edu:2263
From: memon@cse.unl.edu (Nasir Memon)
Newsgroups: comp.software-eng,comp.edu
Subject: Class Project For Software Engineering Course
Date: 2 Jan 1993 18:04:42 GMT
Organization: University of Nebraska--Lincoln	
Distribution: world
NNTP-Posting-Host: cse.unl.edu

I am teaching an  undergrad software engineering course the coming semester.
Have not taught such a course before and as such am no `expert'  in software
eng. I would like the course to be project oriented. Have been looking around
for ideas for a class project and a `Mix and Match Component' scheme suggested
by James Horning's Software Hut seems quite interesting to me. However, do not
have the original article - `The Software Component as a Serious Game' which
describes the project in detail. Does anybody out there have a copy of this or
a similar article? If so, I would appreciate getting a copy of the same. 
Also, any other suggestions for an interesting class project?  A real project
from an external client does not seem feasible at such a short notice. perhaps,
the next time i teach the course :-)  Any help provided will be greatly
appreciated.
Thanks

Nasir Memon