HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.sys.hp

In comp.sys.hp / casper@fwi.uva.nl (Casper H.S. Dik):
>jinx@zurich.ai.mit.edu (Guillermo J. Rozas) writes:
>
>>- People are trained from age 2 onwards (when they learn to read) not
>>to distinguish case.  On cursory inspection, most people don't, thus
>>it is a misfeature to use to names (whether they are file names or
>>variable names or procedure names) that differ only in case, since
>>people have to pay very careful attention (which they are not trained
>>to do) to notice the difference.  This has bitten me many times.
>
>I don't buy this. You use capitals when typing and capitals at
>the beginning of sentences enhance the readability.
>Capitals alter the meaning of some words. (god vs God, Frank vs frank,
>roger vs Roger and many more)

Enhancing readability doesn't equate to *distinguishing* one word
from another, especially when they're the *same* words, with 
case the only difference.  Heck, if you somehow believe that
enhancing readability in everyday text is an argument that case-
sensitive filesystems are "better," then un*x hasn't carried
it far enough:  we should not only differentiate by case, but
also by font, point size, and color; all of which make words
more "readable."

Gee, wouldn't that be great: "Yeah, the file you're looking for
is in the '/usr/stuff/Misc' directory, but don't forget that
'stuff' is all lower-case and is in Roman 12, while everything
else is in Courier 12, and the 'M' in 'Misc' is capitalized.
Oh, almost forgot: I'm using cyan for my filenames today, and
my directories are in LightGreen, so don't forget to specify
those too...."

The readability of text is hardly an argument for case-sensitivity
in filesystems.


>This is my main problem with case insensitive filesystems. I've
>used a number of them (DOS, VMS, AOS/VS and Macintosh). The only
>implementation that remembered case is the Mac implementation.
>The other implementations accept any case you type but when you
>list the files THE SYSTEM SHOUTS THE NAMES BACK AT YOU. That is
>not acceptable. (See how uppercase reads differently from lowercase)

Well, it does "read" differently, but it still *means* the same as
if you'd written "the system shouts the names back at you."  The
argument against case-sensitive file systems isn't one of subtle
"interpretations" of names, it's about *complete* differences in the
way they are managed by the O/S.

MS-DOS 5.0 supports the environment variable "DIRCMD" (or "dircmd,"
same difference :-)) which allows you to, among others, specify the
case for directory listings.  No "shouting."  DOS operations
remain case-independent.

This discussion, like O/S and editor debates, borders on religion.
Some people argue that case-sensitivity is in some ways "better."
I haven't seen anyone really explain *why*, other than the
over-used "flexibility" it offers.  Yeah, it's more flexible,
but where's the ADVANTAGE? (caps used to indicate *emphasis*,
not meaning ;-))

Dean Cashen
-- Boise

--------<disclaimer>----------
HP and I share some views, but
the ones above are all mine...
From: acmeyer@hpfcso.FC.HP.COM (Alan C. Meyer)
Newsgroups: comp.sys.hp
Subject: Re: Problem with loading fortran library libcl.sl
Date: 30 Sep 92 15:11:28 GMT
Article-I.D.: hpfcso.7371350
Organization: Hewlett-Packard, Fort Collins, CO, USA

In comp.sys.hp, hans@es.ele.tue.nl (Hans Fleurkens) writes:

> I've a problem, if I want to load dynamically a library fft.sl into a
> C program. I use the following command to link the shared library:
> 
> ld -b -o fft.sl fft.o fft.for.a -lcl -lnlsstubs
> 
> fft.o is a compiled C file and fft.for.a are a few fortran object files.
> 
> Loading the library results in the following error/warning messages:
> 
> /lib/dld.sl: Unresolved symbol: RAND (code)  from /usr/lib/libcl.sl
> /lib/dld.sl: Unresolved symbol: IRAND (code)  from /usr/lib/libcl.sl

One possibility: RAND and IRAND are only recognized as intrinsics if you
compile with the $HP9000_800 INTRINSICS directives.  In this case, your
references will resolve to FTN_RAND and FTN_IRAND in libcl.

Hope this helps,

Alan Meyer
Colorado Language Lab
acmeyer@fc.hp.com
From: chuckm@hpunsca.canada.hp.com (Chuck Munro)
Date: Tue, 29 Sep 1992 10:22:27 GMT
Subject: Re: "Stereo" socket in HP9000/720 (was Re: HP9000/720 and audio/sound)
Organization: H-P Canada Ltd., Dartmouth, N.S.
Newsgroups: comp.sys.hp

If you are referring to the BNC connector on the CRX-24Z card, marked
"Stereo", I'm not sure what that is, but I do know that the 720/730/750 do
NOT have any digital audio capability.  They do have an "Audio" connector
which is simply the output of a 3-tone beeper circuit (the internal speaker
uses this).

Currently, only the 705/710 have digital audio in/out.  This is implemented
as a monaural, voice-quality susbystem.  Most future 700s will have CD-quality
stereo audio.

Hope this helps.

Chuck.

+-------------------------------------------+
| The above is a personal statement, not an |
| official statement of Hewlett-Packard.    |
+------------------------------- ve1ajz ----+
Newsgroups: comp.sys.hp
From: slater@tpocc.gsfc.nasa.gov (Don Slater)
Subject: Compressed 4mm on s300
Followup-To: comp.sys.hp
Keywords: 4mm DAT HP-UX_9.0
Organization: Integral Systems, Inc / TPOCC Project
Date: Tue, 6 Oct 1992 17:02:19 GMT

My current understanding is that the data-compression model of the HP 4mm DAT
drive is not supported on the S300/400 machines, only on the s700.  Does any-
one know if HP will include this support on s300/400 under HP-UX 9.0?


|    Don Slater    Senior Technical Staff   |   Occasional System      |
|    Integral Systems, Inc                  |    Administrator         |
|    <slater@tpocc.gsfc.nasa.gov>           |--------------------------|
|    1100 West Street                       | "What part of 'No' don't |
|    LAUREL  MD 20707-3587    USA           |  you understand?"        |
Newsgroups: comp.sys.hp
From: kees@ee.ualberta.ca (Kees denHartigh)
Subject: wais/www for 9000-s800 ??
Reply-To: kees@ee.ualberta.ca (Kees denHartigh)
Organization: University of Alberta Electrical Engineering
Date: Mon, 28 Sep 1992 17:27:21 GMT

Has anyone successfully compiled wais or www or both on any
HP9000-835 machines and if so how. Or where can I ftp the sources
from that might successfully compile.
Thanks in advance for any input.
-- 
Kees denHartigh                         kees@ee.ualberta.ca 
Electrical Engineering Digital Labs     alberta!bode!kees
University of Alberta 238 Civil Elect   Voice (403)492-5421
Edmonton, Alberta Canada                Fax   (403)492-1811
From: shankar@sgi.com (Shankar Unni)
Newsgroups: comp.sys.hp
Subject: Re: hpterm survey
Date: 6 Oct 1992 00:25:31 GMT
Organization: Silicon Graphics, Inc.
NNTP-Posting-Host: boris.wpd.sgi.com
X-Newsreader: Tin 1.1 PL5

K. van Houten (houten@pttnwb.nl) wrote:

> In article <1992Oct02.171407.24987@cadlab.sublink.org>, martelli@cadlab.sublink.org (Alex Martelli) writes:
> |> xm9@sdcc12.ucsd.edu (richard g. adair) writes:
> |> :I don't use HPTERM, since it doesn't work on our Suns.  XTERM works
> |> :everywhere, SUN DEC HP etc...
> |> 
> |> HEAR HEAR!!!  Down with proprietary unportable kludges!  Up with portable
> |> kludges!-) [...]
> 
> I fully agree, and just look to the memory use of hpterm vs. xterm!

To come to HP's rescue, I should point out to you folks that you can
always run "xterm" on an HP machine (yes, HP *does* ship xterm, too,
you know..) if you don't care for HPterm.  Edit your window manager
menus and ":s/hpterm/xterm/g".

The main benefit of HPterm is that it emulates an HP terminal
(surprise!). A whole slew of non-Unix applications (read: HP1000 and
HP3000) run only on HP terminals, and it is to the features they use
(stuff like block mode, programmable function keys, etc.) that HPterm
was written.  It's really nice to be able to telnet over to an MPE
machine from your workstation and run all those clunky VPLUS
applications..

The main screwup that HP made in the beginning, IMHO, is that is made
HPterm the default term emulator for HP-UX workstations.  Big mistake:
as many have pointed out, standard is better than better..  (Here at
SGI, they *did* succumb somewhat to the temptation of porting their
own in-house terminal emulator (xwsh) to IRIX 4.0, but at least it's
an ANSI terminal emulation, so setting TERM=ansi or vt100 works; and I
must also add that I find xwsh to be much nicer than xterm).
--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-390-2072
Newsgroups: comp.sys.hp
From: stevej@hpc.mentorg.com (Steve Jumonville)
Subject: Re: HP 9000/7xx NamePlates
Originator: stevej@hpc.mentorg.com
Date: Tue, 06 Oct 1992 22:30:36 GMT
Distribution: na
Organization: Mentor Graphics 
Keywords: 
Followup-To: 


In article <1992Oct05.184912.10046@allegro.com>, sieler@allegro.com (Stan Sieler) writes:
|> 
|>    Does anyone know why the 710, 720, 730, and 750 don't have
|>    product numbers on their fronts?

Because HP has always prided itself on protecting their customer's investments.
In the old days, the early Motorola 68000 based HP systems could be CPU board upgraded to 68010, then 68020, 68030, ...

The same investment protection through board upgrades is true on the 700 Series as well.

Even when HP did try sticking product numbers on the front they were often misleading. You couldn't tell if the system that said 825 on the front was really an 825, or if the user had never bothered to paste his new 835 or 845 sticker over the old one.

The best/only way to really tell is to ask the system what it is:

                               "uname -m"
 
 --------------------------------------------------------------------------
 Steve Jumonville              INTERNET:       steve_jumonville@mentorg.com
 Hewlett-Packard Technical Consultant
 Mentor Graphics Corp.
 8005 SW Boeckman  Road        VOICE:          (503) 685-7746
 MS  E-1302                    VOICE-MAIL:     (503) 685-1316 (ext. 7746)
 Wilsonville, Oregon 97070     FAX:            (503) 685-7986
 --------------------------------------------------------------------------
From: franks@hpuamsa.neth.hp.com (Frank Slootweg CRC)
Date: Mon, 5 Oct 1992 13:48:45 GMT
Subject: Re: hp720 won't boot
Organization: Hewlett-Packard
Newsgroups: comp.sys.hp

atkinson@itd.nrl.navy.mil (Randall Atkinson) writes :

>>drive is SCSI ID 6. In addition, you MUST run the 'mediainit' program on your
>>internal drive to wipe out the boot block and prevent your system from booting
>>from the internal drive (regardless what's on it).
>
>mediainit will wipe out The Whole Disk since it is a low level format.
>The low level reformat probably isn't necessary and is potentially
>quite destructive to the information on that disk.

  There are implied smilies behind "probably" and "potentially", aren't
there? If not, then :

$ man -k boot
[deleted]
mkboot, rmboot(1M)      - install, update, or remove boot programs from a disk
device
[deleted]
$ 
(and of course "man mediainit").

Frank Slootweg, HP, Main Operations Response Organization Netherlands.
Newsgroups: comp.sys.hp
Subject: pcnfsd version 2 for HP-UX
From: larry@gauss.mie.uc.edu (Larry Schartman)
Date: Tue, 29 Sep 1992 14:35:59 GMT
Organization: Dept of Mechanical Engineering University of Cincinnati
Keywords: pcnfs

Does anyone know where I can find  pcnfsd version 2 that will compile
under HP-UX 8.0. All the ones archie finds for me seem to be SUN
specific and won't compile on my HP. 

Thanks in advance


-- 
Larry Schartman		  	  E-mail  Larry.Schartman@uc.edu
University of Cincinnati  	  Dept of Mechanical Engineering
Cincinnati, Ohio          	  		      45221-0072
From: kinsell@hpfcso.FC.HP.COM (Dave Kinsell)
Newsgroups: comp.sys.hp
Subject: Re: 3rd party disks
Date: 6 Oct 92 15:07:21 GMT
Organization: Hewlett-Packard, Fort Collins, CO, USA

In comp.sys.hp, wk@cup.hp.com (Wayne Krone) writes:

> Without looking at the code, this doesn't sound right to me.  All
> mediainit does is invoke the driver which in turn just issues a SCSI
> "FORMAT UNIT" command to the drive.  It's up to the drive to do all the
> work of formatting the media and handling any bad sectors.

At least on the workstations, mediainit isssues the format_unit command, then
later does its own read scan of the disk to look for problems not taken care
of by the disk.  According to the standard, a format_unit without the disable
certification bit being set should be enough to guarantee that all blocks are
accessible.  Lack of conformance to the standard by disk drives is not
exactly unheard of in the industry.

-Dave Kinsell
From: seymour@milton.u.washington.edu (Richard Seymour)
Newsgroups: comp.sys.hp
Subject: Re: HP vs. DEC (not again!)
Keywords: Alpha
Date: 29 Sep 92 20:14:30 GMT
Article-I.D.: u.1992Sep29.201430.27428
Distribution: na
Organization: University of Washington, Seattle

In article <38535@sdcc12.ucsd.edu> xm9@sdcc12.ucsd.edu (richard g. adair) writes:
(gee... the signature says "Tony Burzio"?)
Re: the DEC Alpha beast...
>Who knows what the speeds will be...  DEC has lied before...
yeah... on the spec sheet i have, they (Digital) list the HP 9000/720 as a 
  100 SpecMark machine... you just cannot trust their numbers...  :-)

but, semiseriously, folks: re: the "you can't run your old executables" 
 comment... that's true... it's NOT a VAX...it's an ALPHA.
and you CAN give your old .EXE files to "VEST".. a program which chews
 through them and generates ALPHA-native code which mimics true-blue-VAX/VMS
 operation and idiosyncracies...
it's not an emulator... it's a compiler.  VAX binary in, ALPHA binary out.
It knows about the constraints/advantages of the chip's internal pipelines,
  so it rearranges instruction order to avoiod delays.
Speed of execution won't be ALPHA-fantastic, but the code will run...

(Cobwebbed historical note: back in the late 60's, about 4 years after the 
  introduction of the IBM 360 line of computers, IBM estimated that well
  over 50% of the machine time in use was running old IBM 1401 AutoCoder
  programs in emulation.)
 And the VAX 11/780's ability to run pdp-11 RSX-11M programs was a factor
  in our purchase thereof...
 ALPHAs DO exist... you can't BUY one today, but properly-equipped sites can
  get DEC to GIVE them one (or two or three...)
The beasts ARE fast... and will be available in many speed ranges, with more
 coming right along .. and the architecture is "scalable"... more parallel
  pipeling can be added immediately, and the clock speeds can be upped from
the current 150MHz nominal (the chip is designed for 200MHz) to 400 MHz
 (currently running in the lab) with care.  The existing chip is a 64-bit
 wide beast which is run as a dual 32-bit.  The in-development chip is
  quad-wide.
The current chip dumps 35 watts... even the desktop unit has 4 fans (each with
 different voltages so they won't have an audio "beat" against eachother)

Digital's "betting the company" on this platform... and they did the VAX/VMS
 system right (things we wrote in 1978 still run on every VAX we've got,
  things we write today still run (slowly) on our serial-number 357 11/780).
We expect similar "family consistency" from the ALPHA platform, and i doubt
 we'll be disappointed (other than we can't have them now...).

We've ported many monster Fortran programs to the HP 710, and see various
 percentages of speed improvement over our VAXes... i expect we'll see
 similar non-linearities in porting to ALPHAs.  We'll be buying systems
 based upon demonstrated capabilites, and probably won't actually order an
 ALPHA until next summer or fall (funding cycle constraints), once it's
 shown its abilities...

Of course, maybe by then i'll have put "OpenVMS" on an HP, and the pressure 
  to buy ALPHA may diminish...

--dick
From: cionca@siihp1.epfl.ch (Ion Cionca [epfl.sic.sii])
Newsgroups: comp.sys.hp
Subject: Re: Looking for PCL to PostScript filter
Date: 5 Oct 92 11:03:25 GMT
Distribution: usa
Organization: Ecole Polytechnique Federale de Lausanne

In article <DBROOKS.92Oct2233431@penge.osf.org>, dbrooks@penge.osf.org (David Brooks) writes:
|> esc@netcom.com (Steve Etchelecu) writes:
|> > I am looking for a PCL to PostScript filter.  Any information regarding 
|> > this topic would be appreciated.  
|> > 
|> > I have an HP9000 with a PostScript printer and would like to be able to
|> > print from HP's LaserROM product which seems to support only PCL printers.
|> 
|> Funny; I had logged in to ask exactly the same question.  We have a number
|> of PostScript printers on the network, so I guess I am asking for a
|> (ill-formed question here) filter mumble model mumble remote.  Something
|> that looks like a printer but ends up in PS being fed to rlp.
|> --
|> David Brooks					dbrooks@osf.org
|> Open Software Foundation			uunet!osf.org!dbrooks
|> Four more months!  Four more months!

you might try to use lj2ps filter available on the network:
	- ftp.uu.net:/usenet/comp.sources.misc/volume13/lj2ps
	- irisa.irisa.fr:/News/comp.sources.misc/volume13/lj2ps (for Europe)
	.....
for details on lj2ps contact:
        Internet:       lishka@uwslh.slh.wisc.edu
        UUCP:           ...!uunet!uwvax!uwslh!lishka

        Work phone:     (608) 262-4485 (Tues.-Sat., 9am-5pm)

        Address:        Christopher Lishka
                        Data Processing Dept.
                        Wisconsin State Laboratory of Hygiene
                        465 Henry Mall
                        Madison, WI     53715


Once you get lj2ps to work you may tune the /usr/spool/lp/model/postsript
filter to transform PCL inputs into PostScript output...

hope this helps
	ion

-- 
--------

       Ion CIONCA
       -- HP/Apollo Support --
       Swiss Federal Institute of Technology (EPFL)
       Service Informatique Central (SIC)
       1015 LAUSANNE (SWITZERLAND)
       E-Mail : cionca@sic.epfl.ch
       Phone  : (+41 21) 693.45.86 / 693.22.11
       Fax    : (+41 21) 693 22 20
From: dek@hpuerca.atl.hp.com (David Kohl)
Newsgroups: comp.sys.hp
Subject: Re: hp-ux reinstallation on hp 9000/800 series (827s)
Date: 2 Oct 92 16:46:26 GMT
Organization: the HP Response Center, Atlanta

Not sure why the two tapes are defining the disk differently but the 
recommended method of performing an install is to use the install tape.
The Support Tape is intended for use by HP in recovery situations
Newsgroups: comp.sys.hp
From: chrisp@slc.com (Chris Pinkham)
Subject: swapinfo(1M) location
Organization: Servio Corp, Beaverton Oregon, US
Date: Thu, 1 Oct 1992 00:30:58 GMT

Hello. I use aforementioned program in an installation script, and
before I do, I check for its existence in /etc. One installer
complained that his swapinfo was located not in /etc but somewhere
under the /system directory. That sounds kind of odd. I was wondering
if it had something to do with his running an older version of hpux?
Is this a general thing that I need to consider, or are all 8.07
swapinfo's in the 'correct' place? If you run an 8.07 system and
have swapinfo in a place other than in /etc, please could you let
me know?

Manythanks,
Chris
Newsgroups: comp.sys.hp
From: zaphod@ctrg.rri.uwo.ca (Lance R. Bailey)
Subject: Re: /etc/hosts and name servers...
Reply-To: zaphod@ctrg.rri.uwo.ca
Organization: University of Western Ontario
Distribution: na
Date: Tue, 6 Oct 1992 13:33:41 GMT

In article <vic.718370711@news2> vic@class.gsfc.nasa.gov (James V. Ryan (Vic))  
writes:
>cricket@winnie.corp.hp.com (Cricket Liu) writes:
>>In article <1992Oct5.153221.5779@nrcnet0.nrc.ca>, cantin@nrccsb3.di.nrc.ca  
(Claude Cantin) writes:
>
>I realy think that this should be a enhancement request for a number of  
reasons
>
>1. If it was a option to set the order of search then a lot of packets could 
>   be kept off the lans for local ribs by not querying the nameserver for 
>   the address of the workstation on the next desk or in the next room.
hmmmm, is this really a traffic issue? how many packets on the net are due to
resolution?

>2. If the nameserver is down, you won't have a long timeout wait for the  
switch
>   to the secondary nameserver 
granted, this is why your nameservers should be listed in /etc/hosts in order
of accessability.

>3. There are times that our nameserver is very busy 
Hmmm, i am wondering is the nameserver busy from resolving (ie named is taxed)
or that particular CPU is being hogged by something else. It would seem to
me that you need to get your name server on a less taxed machine.
are you trying to support a slew of machines from one named? hmmm. perhaps
it would be an idea to run a caching only nameserver -- not a secondary, 
just a caching server.

the basic problem with /etc/hosts is that, as a file, it is bound to be out
of date. /etc/hosts should be surplanted by /etc/resolv.conf in most cases.
I have routines to build /etc/hosts from my DNS whenever i update the latter,
but if people do not update them, then i get called that "gee i cannot hit
the following host" if the number has changed. sigh.

--
Lance R. Bailey  System/Network Manager         Robarts Research Institute
     NeXT/email: zaphod@ctrg.rri.uwo.ca    box: Clinical Trials Resources Group
            fax: +1 519 663 3789                P.O. Box 5015, 100 Perth Dr.
            vox: +1 519 663 3787 x4108          London, Canada N6A 5K8
Newsgroups: comp.sys.hp
From: nelsonc@hyades.cs.rpi.edu (Chris Nelson)
Subject: Re: HP1000
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Tue, 6 Oct 1992 17:45:10 GMT

Marcus,

Typeahead can be enabled on HP1000 ports but I generally found the secondary
command prompt rather useful.

                                     Chris


-- 
------------------------------+----------------------------------------------
Chris Nelson                  |  Rens-se-LEER is a county.
Internet: nelsonc@cs.rpi.edu  |  RENS-se-ler is a city. 
CompuServe: 70441,3321        |  R-P-I is a school in Troy!
Newsgroups: comp.sys.hp
From: mkibler@yoda.eecs.wsu.edu (Michael K. Kibler)
Subject: 92 spec marks for HP9000/710
Originator: mkibler@yoda.eecs.wsu.edu
Organization: Washington State University
Date: Tue, 29 Sep 92 22:55:02 GMT


Does anyone out there have the 92 spec marks (integer and float)
for the HP9000 710. I checked with my local sales rep and he
is still pushing the old spec marks (for this particular machine).


thanks in advance.
-- 
 ---- Mike  ( Radiosity - Virtual Reality - 3D )
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Michael K. Kibler        INTERNET:  mkibler@eecs.wsu.edu
 Elect/Compt. Engr. Dept. UUCP    :  ...uunet!eecs.wsu.edu!mkibler
Newsgroups: comp.sys.hp
Subject: Test coverage using shared libraries, would this work?
From: bernard@sdl.mdcbbs.com (Bernie Solomon)
Date: 6 Oct 92 02:37:07 PDT
X-Newsreader: Tin 1.1 PL4

I had an idea in the middle of last night and I wondered if it would work. We 
are considering tools for automatic test coverage and sort of at the minimu 
would like to know how many external routines a given test actually hits. As I 
understand the shared library mechanism when the system originally loads an 
image all references into shared libraries actually have an entry to the 
dynamic linker in them. When you call that routine for the first time it calls 
into the dyanmic linker which then replaces the reference with the address of 
the real entry point. My idea is simply to grovel through the shared library 
tables and look at which entries have been changed to not be into the dynamic 
linker. This would then give you all external routines which have been 
exercised by the given program run. Since all our external routines bar one 
or two .o's are in shared libraries we would catch everythings. I know we would 
miss static routines and that could be fixed up by renaming these routines so 
they were really external for purposes of test coverage analisys. The beauty of 
this to me is for the external case only I don't have to recompile all the 
libraries specially for the test coverage (I work on a rather large program so 
recompiling everything twice once for normal use and once for coverage analysis 
would take sginificant time and indeed some of the libraries are built at a 
different site to where I work).

So would this work?

If it would work, is there some way of finding out how to scan the shared 
library tables?
--
Bernie Solomon (bernard@sdl.mdcbbs.com), Shape Data, A Division of EDS Ltd.


Newsgroups: comp.sys.hp