thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (04/09/91)
The subject says most of it -- I'm ticked at HP's APR 'resolution' method. Consider FLAME ON through this whole thing. I sent in an APR in mid October of 1990 (it was not a high-priority one, so I'm only mildly upset at the 6 month turnaround). Basically, the problem is that "/com/lst" doesn't handle wildcards correctly. If you give it a wildcarded pathname that doesn't exist, then it gives an lst of the current directory (Unix users - 'lst' is more-or-less 'du'). I feel that this is an error, as I certainly didn't _ask_ for the current directory. I got a response today (April 8). Problems I have with the response - 1) HP/Apollo is actually having someone HAND TYPE the APR responses!!! Now, perhaps I shouldn't gripe, but it seems wasteful to make somebody type in the e-mailed forms again, after they had a computer print them out. (I know that it's hand typed, because we've found errors (typos) in the US-nail response.) 2) Even though it was a low priority APR, I think 6 months is too long. (It says that it's from 3/26, and the postmark is 4/5, so I guess you could argue that the response people only had it for 5 1/2 months.) 3) Their response is that this is not a bug -- it is working within specs. The comment was that "When the wildcard specification has no match, as far as lst is concerned it is quivalent (sic) to mot specifying any pathname." THEY GAVE ME THE BEHAVIOR, AND SAID THAT IT'S OKAY, SINCE IT BEHAVES LIKE IT BEHAVES!!!!! If "dlt bad?*wildcard" deleted the current directory, you can be _SURE_ that it'd be a bug! When I ask for a disk usage of a wildcard, I do not expect to get the current directory! Therefore, the behavior isn't expected! Therefore, it's wrong! The help file (which they also quoted) says that "When no pathname is specified the default...." This is fine; however, I specified a pathname! I told it in no uncertain terms what I wanted, and it shouldn't offer me something else if it can't find what I told it to give me. This would normally only irritate me slightly. However, we have not received any responses to APRs lately that have been timely _OR_ satisfactory. Any bug in the Domain/OS (Apollo side of HP) product arena has been found to be "working within specifications," or else "the documentation is in error." We just got a new 400t in, with the HP flavored manual "Getting Started With Domain/OS." I'm looking forward to the _real_ manual -- "How We Finished Off Domain/OS." -- jt -- John Thompson Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com Me? Represent Honeywell? You've GOT to be kidding!!!
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (04/10/91)
In article <9104082143.AA24021@pan.ssec.honeywell.com> thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes: >The subject says most of it -- I'm ticked at HP's APR 'resolution' method. >Consider FLAME ON through this whole thing. > >3) Their response is that this is not a bug -- it is working within specs. > The comment was that "When the wildcard specification has no match, as far > as lst is concerned it is quivalent (sic) to mot specifying any pathname." > THEY GAVE ME THE BEHAVIOR, AND SAID THAT IT'S OKAY, SINCE IT BEHAVES LIKE > IT BEHAVES!!!!! I have had a bunch of APRs "resolved" with this now-classic response too - the person who thought up "working within specs" should have got a big pay raise. This is how you reduce the APR count and claim that this is the best quality software ever: Bugs? What bugs? I don't see any bugs! (Maybe it's a "feature" :-) ). In addition, they can add one to the list of closed APRs for SR10.4. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
nazgul@alphalpha.com (Kee Hinckley) (04/10/91)
In article <1991Apr9.173756.24708@alchemy.chem.utoronto.ca> system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: >>3) Their response is that this is not a bug -- it is working within specs. ... >I have had a bunch of APRs "resolved" with this now-classic response too - >the person who thought up "working within specs" should have got a big pay I have to agree that this is a rather obnoxious reply. I suspect that what they really mean to say is: This is a bug, but we are never going to have the time or resources to fix it. That would be more straightforward. I'm not sure how much happier it would make people though. Bugs like the one mentioned in lst (which by the way, was a known bug years ago) simply never rise high enough in priority to get fixed even in the best of times. I'd much rather see someone adding lst options (-level comes to mind) to /bin/du than fixing bugs in lst. I'd even more rather see OSF/1 on my 3500.... -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
chen@digital.sps.mot.com (Jinfu Chen) (04/11/91)
In article <1991Apr9.173756.24708@alchemy.chem.utoronto.ca> system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: >In article <9104082143.AA24021@pan.ssec.honeywell.com> thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes: >>The subject says most of it -- I'm ticked at HP's APR 'resolution' method. >>Consider FLAME ON through this whole thing. >> >>3) Their response is that this is not a bug -- it is working within specs. >> The comment was that "When the wildcard specification has no match, as far >> as lst is concerned it is quivalent (sic) to mot specifying any pathname." >> THEY GAVE ME THE BEHAVIOR, AND SAID THAT IT'S OKAY, SINCE IT BEHAVES LIKE >> IT BEHAVES!!!!! > >I have had a bunch of APRs "resolved" with this now-classic response too - >the person who thought up "working within specs" should have got a big pay >raise. This is how you reduce the APR count and claim that this is the best >quality software ever: Bugs? What bugs? I don't see any bugs! >(Maybe it's a "feature" :-) ). In addition, they can add one to the list >of closed APRs for SR10.4. Another classic example is the response to my APR about /com/tpm. We found out users can use tpm when crp'ing on or rsh/rlogin/telnet to change mouse/touchpad device sensitivity on the node. I filed an APR complaing about it. All it would take Apollo to fix is adding a pad_$isa_dm_pad call to the program. The response, on the other hand, gave the classic answer of "it's a feature, not a bug". -- Jinfu Chen (602)898-5338 Motorola, Inc. SPS Mesa, AZ ...uunet!motsps!digital!chen chen@digital.sps.mot.com CMS: RXFR30 at MESAVM ----------
rees@dabo.citi.umich.edu (Jim Rees) (04/11/91)
In article <50e4e732.3593b@digital.sps.mot.com>, chen@digital.sps.mot.com (Jinfu Chen) writes:
Another classic example is the response to my APR about /com/tpm. We found
out users can use tpm when crp'ing on or rsh/rlogin/telnet to change
mouse/touchpad device sensitivity on the node. I filed an APR complaing about
it. All it would take Apollo to fix is adding a pad_$isa_dm_pad call
to the program. The response, on the other hand, gave the classic answer of
"it's a feature, not a bug".
I consider it a feature. Your suggested fix would defeat the use of tpm in
my startup_dm file. I like the current behavior and don't want it to
change.
My favorite APR response was always "fixed in a future release." We never
said which future release, and no one could claim we lied, unless they
waited forever.
By the way, I've filed two APRs in my life. One was to complain that 'plot'
doesn't work when the output is to a DM pad. I got an ack six months later.
I don't remember whether I ever got an actual response or not, but it's been
over a year and 'plot' is still broken. The other APR I filed in June of
last year, and it hasn't been answered yet. I think the bug (a security
hole I don't want to discuss here) has been fixed, but I'm not sure, and I
never got a response on that one either.tvb@bugeater.frame.com (Terry V. Bush) (04/12/91)
FLAME ON HIGH!!!
On the contrary, I think that is a pretty good response considering what I
have been getting on a TCP/IP -vs- Xapollo CRASH APR that I submitted last August!
APR #DE313.
It took them until late December until they sent me something to test to see
if it worked. It didn't work. Then until a couple weeks ago I had heard
nothing. Well, now I get this letter saying if you run FrameMaker (That is
where the problem occurs.) you should use this patch #pd91_m0234. Well...,
it doesn't fix the problem! Well, lets put it this way, TCP/IP doesn't
crash, Xapollo doesn't crash, I guess the problem is solved even though
FrameMaker crashes still. Well I have checked everything out on
FrameMaker's side. We aren't doing anything wrong. The X server just
decides, gee this is too hard so I guess I should kill the client (put that
stop talking to the client and let it die). Well no other server will do
this to the same binary. Also, you ought to see how slow an X server can
run by installing their patch! Don't leave it there and don't delete your
old Xapollo server!
I just can't see how they can create a patch and release it and EVEN put our
name on it as though we have blessed it when we never saw hide nor tail of
it until it hit the streets!
Flame on low.
Now, I am sure that Rab never knew that I hadn't seen the patch when he sent out
the patch tape notice, but someone should have known whether I (That is "ME"!!!)
had looked at the patch or not FIRST!
Now HP (quietly apollo) says why don't you just use the NEW X11R4 Xdomain
server. Right! Tell all of our customers they have to FLASH between this
screen and that one just to see if the inset from this or that third-party
vendor made it into FrameMaker! THEY WILL TELL US THAT THIS IS NNNOOOTTT
(LOUD NOT) INTEROPERABILITY! (I.e., that sucks!)
When will HP (quiet apollo) realize that the SHARE MODE server is GREAT for
old and new software alike. If the share mode server is a little slower
than the borrow mode server and I want it to run fast today I will start it
up in borrow mode, but if I want to see DM windows and X windows on the same
screen I want them to both be there at the same TIME!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
In other words don't give up the added value of the DM just because it isn't
STANDARD. It's BETTER, especially with BOTH!
Peace,
Terry V. Bush
The Veritable Bugeater tvb@frame.com N6IFX
#include "std/disclaimer.h"
"In article <9104082143.AA24021@pan.ssec.honeywell.com>, thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes:
> Path: frame!vsi1!ames!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!PAN.SSEC.HONEYWELL.COM!thompson
> From: thompson@PAN.SSEC.HONEYWELL.COM (John Thompson)
> Newsgroups: comp.sys.apollo
> Subject: APRs (FLAME ON)
> Message-ID: <9104082143.AA24021@pan.ssec.honeywell.com>
> Date: 8 Apr 91 21:43:20 GMT
> Sender: daemon@ucbvax.BERKELEY.EDU
> Organization: The Internet
> Lines: 51
>
> The subject says most of it -- I'm ticked at HP's APR 'resolution' method.
> Consider FLAME ON through this whole thing.
>
> I sent in an APR in mid October of 1990 (it was not a high-priority one,
> so I'm only mildly upset at the 6 month turnaround). Basically, the problem
> is that "/com/lst" doesn't handle wildcards correctly. If you give it a
> wildcarded pathname that doesn't exist, then it gives an lst of the current
> directory (Unix users - 'lst' is more-or-less 'du'). I feel that this is
> an error, as I certainly didn't _ask_ for the current directory. I got a
> response today (April 8).
>
> Problems I have with the response -
> 1) HP/Apollo is actually having someone HAND TYPE the APR responses!!! Now,
> perhaps I shouldn't gripe, but it seems wasteful to make somebody type
> in the e-mailed forms again, after they had a computer print them out.
> (I know that it's hand typed, because we've found errors (typos) in the
> US-nail response.)
>
> 2) Even though it was a low priority APR, I think 6 months is too long.
> (It says that it's from 3/26, and the postmark is 4/5, so I guess you
> could argue that the response people only had it for 5 1/2 months.)
>
> 3) Their response is that this is not a bug -- it is working within specs.
> The comment was that "When the wildcard specification has no match, as far> as lst is concerned it is quivalent (sic) to mot specifying any pathname."> THEY GAVE ME THE BEHAVIOR, AND SAID THAT IT'S OKAY, SINCE IT BEHAVES LIKE
> IT BEHAVES!!!!!
> If "dlt bad?*wildcard" deleted the current directory, you can be _SURE_
> that it'd be a bug! When I ask for a disk usage of a wildcard, I do
> not expect to get the current directory! Therefore, the behavior isn't
> expected! Therefore, it's wrong! The help file (which they also quoted)
> says that "When no pathname is specified the default...." This is fine;
> however, I specified a pathname! I told it in no uncertain terms what I
> wanted, and it shouldn't offer me something else if it can't find what I
> told it to give me.
>
> This would normally only irritate me slightly. However, we have not received> any responses to APRs lately that have been timely _OR_ satisfactory. Any
> bug in the Domain/OS (Apollo side of HP) product arena has been found to be
> "working within specifications," or else "the documentation is in error."
> We just got a new 400t in, with the HP flavored manual "Getting Started With
> Domain/OS."
> I'm looking forward to the _real_ manual -- "How We Finished Off Domain/OS."
>
> -- jt --
> John Thompson
> Honeywell, SSEC
> Plymouth, MN 55441
> thompson@pan.ssec.honeywell.com
>
> Me? Represent Honeywell? You've GOT to be kidding!!!mike@hpfcso.FC.HP.COM (Mike McNelly) (04/12/91)
> My favorite APR response was always "fixed in a future release." We never > said which future release, and no one could claim we lied, unless they > waited forever. "Fixed in a future release" may seem like weasel-words but it's necessary if the name of a future release is not entirely stable. For example, consider the possible confusion to customers if the engineer had responded "fixed in release 11.xx" and that release was subsequently renumbered to 10.yy. Also, in the mad world of releases, sometimes unrelated releases unexpectedly leapfrog each other due to slips of one part or another. This accounts for some creative release renumbering and further confusion for everyone, the engineers included. Mike McNelly mike@fc.hp.com (I have nothing to do with Apollo APR's, by the way)
glenn@huxley.huxley.bitstream.com (Glenn P. Parker) (04/13/91)
mike@hpfcso.FC.HP.COM (Mike McNelly) writes: > "Fixed in a future release" may seem like weasel-words but it's > necessary if the name of a future release is not entirely stable. For > example, consider the possible confusion to customers if the engineer > had responded "fixed in release 11.xx" and that release was subsequently > renumbered to 10.yy. > > Also, in the mad world of releases, sometimes unrelated releases > unexpectedly leapfrog each other due to slips of one part or another. > This accounts for some creative release renumbering and further > confusion for everyone, the engineers included. Naahhh, them's weasel-words alright! If HP/Apollo really wanted to convey any concrete information in such a report, they could either: 1) Specify a _date_ by which the problem would be fixed. 2) Specify a maximum number of releases that would follow before the problem was fixed, i.e. "Fixed within two releases" or "Fixed in the next release." As a user, I would even be willing to be a _little_ generous when given this kind of feedback, by allowing for a bit of slop in an estimate to compensate for "leapfrog" releases and/or delays due to other significant events (like acquisition by another company :-). There's no disguising the fact that the only thing "Fixed in a future release" says is "Don't call us, we'll call you." That's certainly not what I want to hear from a technical support organization. Of course, "Fixed in a future release" is infinitely better than "Performs to specification," which (in some cases I have read about on comp.sys.apollo) is the purest form of BS (bureaucrat-speak). -- Glenn P. Parker glenn@bitstream.com Bitstream, Inc. uunet!huxley!glenn 215 First Street BIX: parker Cambridge, MA 02142-1270
nazgul@alphalpha.com (Kee Hinckley) (04/14/91)
In article <GLENN.91Apr12171539@huxley.huxley.bitstream.com> <glenn@bitstream.com> (Glenn Parker) writes: > 1) Specify a _date_ by which the problem would be fixed. > > 2) Specify a maximum number of releases that would follow before the > problem was fixed, i.e. "Fixed within two releases" or "Fixed in > the next release." ... >There's no disguising the fact that the only thing "Fixed in a future >release" says is "Don't call us, we'll call you." That's certainly not >what I want to hear from a technical support organization. > >Of course, "Fixed in a future release" is infinitely better than "Performs >to specification," which (in some cases I have read about on >comp.sys.apollo) is the purest form of BS (bureaucrat-speak). That's great in concept. But when I got a bug report I a) usually didn't know when it was going to get fixed (you've got to schedule these things, and the schedule isn't easily predictable at the time you handle the APR) and b) had no idea which release it will go out in. (Release get added an subtracted all the time. SR9.5 was a major release with a minor number because too much had been promised for SR10. The engineer who answer's your bug would be foolish to ever mention a number of releases.) Given that situation, what do you expect? Also further consider that the words you see are often not written by the engineer who replied. These things get edited before they hit the streets, and things like "We're never going to fix your stupid bug" :-) often get turned into something more politic but less true. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
mike@hpfcso.FC.HP.COM (Mike McNelly) (04/15/91)
> mike@hpfcso.FC.HP.COM (Mike McNelly) writes: > > "Fixed in a future release" may seem like weasel-words but it's > > necessary if the name of a future release is not entirely stable. For > > example, consider the possible confusion to customers if the engineer > > had responded "fixed in release 11.xx" and that release was subsequently > > renumbered to 10.yy. > > > > Also, in the mad world of releases, sometimes unrelated releases > > unexpectedly leapfrog each other due to slips of one part or another. > > This accounts for some creative release renumbering and further > > confusion for everyone, the engineers included. > Naahhh, them's weasel-words alright! > If HP/Apollo really wanted to convey any concrete information in such a > report, they could either: > 1) Specify a _date_ by which the problem would be fixed. > 2) Specify a maximum number of releases that would follow before the > problem was fixed, i.e. "Fixed within two releases" or "Fixed in > the next release." > As a user, I would even be willing to be a _little_ generous when given > this kind of feedback, by allowing for a bit of slop in an estimate to > compensate for "leapfrog" releases and/or delays due to other significant > events (like acquisition by another company :-). > There's no disguising the fact that the only thing "Fixed in a future > release" says is "Don't call us, we'll call you." That's certainly not > what I want to hear from a technical support organization. > Of course, "Fixed in a future release" is infinitely better than "Performs > to specification," which (in some cases I have read about on > comp.sys.apollo) is the purest form of BS (bureaucrat-speak). > -- > Glenn P. Parker glenn@bitstream.com Bitstream, Inc. > uunet!huxley!glenn 215 First Street > BIX: parker Cambridge, MA 02142-1270 Again, I don't have anything to do with Apollo so my comments are based only on our own lab's procedures, not any other's. "Fixed in a future release" is used in only one context: The bug has been investigated, a fix has been implemented and installed, it's been tested, and we're waiting for a release train to hook the new code onto. This response is never used to describe anything that has not already been determined to be a problem and been fixed. We cannot specify a date for which a bug fix will be available because a) the bug has already been fixed as far as the lab is concerned. We're awaiting a way to get it out to the customers. b) We don't like to make statements that sound like promises we can't be sure we can keep. This is a matter of professionalism and integrity as much as anything else. c) We have a worldwide distribution for releases that can take a significant amount of time to crank up (e.g., released by xxx in the US doesn't necessarily satisfy anyone in Uganda. d) At the time the bug is fixed we frequently don't have a clear idea when the next release is to occur. Releases involve a large number of labs, marketing, support, manufacturing, etc. The humble engineer who fixes your problem may not be privy to the grand scheme (I really doubt that any grand pubah has a clue in the early stage, either). As to promising "within two releases", etc.: These responses don't entirely satisfy people, either and they're certainly pretty ambiguous. We make releases all the time for various hardware boxes, software packages, etc. that any single customer probably never knows about. It's a lot less clear what a release is now that we support such a large variety of machines and configurations. Occasionally we also run across problems that require coordinated action between two or more widely separated labs. I know customers don't care who fixes their problem but sometimes a fix in the debugger, for example, must also await a corresponding modification to the kernel. If the kernel isn't being turned for a particular release then the customer will not see the fix in the next release despite the best intentions of the debugger team. The whole point of these comments are to give you a little insight into what's involved in fixing problems and getting the fixes to you. If you've got suggestions I'd like to hear them, preferably off line. We can summarize later if that makes any sense. Keep in mind, though, that you're dealing with a humble engineer, not the master of the universe. Mike McNelly mike@fc.hp.com
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (04/17/91)
In this subject-chain (that I started), there has been a fair amount of HP/Apollo bashing. This is not necessarily unjustified, but I would like to make one comment on it. I have numerous problems/complaints/flames with HP/Apollo management and policy. However, I have found nearly _all_ HP/Apollo representatives to be helpful, considerate, understanding, etc. (It may be that I only encounter old Apollo-ans, since we don't do HP-UX, but I doubt it.) I don't want to go into details, because I don't want to get the HP/Apollo person in trouble, but somebody at HP (you know who you are) took the time and energy to get back to me with a workaround to my problem that was "not a bug -- operating within specs." The fact that the problem was apparently easily fixed leads me to wonder why the problem (which I DEFINITELY consider a bug, and don't understand how HP/Apollo can call it a feature) was written off rather than "fixed in a future release." Regardless, "thank you" to the HP/Apollo person who cared enough to risk getting in trouble for helping out a customer. -- jt -- John Thompson Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com Me? Represent Honeywell? You've GOT to be kidding!!!
vince@bcsaic.UUCP (Vince Skahan) (04/18/91)
In article <9104161951.AA06798@pan.ssec.honeywell.com> thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes: > >In this subject-chain (that I started), there has been a fair amount of >HP/Apollo bashing. This is not necessarily unjustified, but I would >like to make one comment on it. > >I have numerous problems/complaints/flames with HP/Apollo management and >policy. However, I have found nearly _all_ HP/Apollo representatives to >be helpful, considerate, understanding, etc. (It may be that I only >encounter old Apollo-ans, since we don't do HP-UX, but I doubt it.) > amen to that... my experience has been that the PEOPLE at Apollo (not HP) have always been willing to do almost anything for you. it's the SYSTEM that's screwed up, has always been, and apparently still is. they are continuing to lose both face and customers as a result. people can wait only so long, then they vote with their wallets.. and their feet... -- Vince Skahan vince@atc.boeing.com ...uw-beaver!bcsaic!vince (ensure your child's future... fire and prosecute striking teachers !)
hamm@austoto.sps.mot.com (Steve Hamm) (04/23/91)
-----On 12 Apr 91 20:30:08 GMT, tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) said:
Thomas> ....you clearly favor the share mode server, and HP/Apollo
Thomas> realizes that many folks do. Thats why the share mode server
Thomas> continues to be supported/ bug-fixed, albeit the process for
Thomas> customer bugs appears to be lacking.
Terry> When will HP (quiet apollo) realize that the SHARE MODE server is
Terry> GREAT for old and new software alike. ..........
Thomas> And we also get beat up by those who didn't consider the Share
Thomas> Mode server adequate. Our answer, the borrow mode server, and
Thomas> for many, it was the answer they were looking for.
Just for balance, I'll throw in my 2 cents worth, since most folks who
post seem to LIKE the DM, and think the share-mode server is a great
idea.
I don't like the DM. Nice idea 10 years ago, but... And the share
mode server is/was a kluge of the worst order. But the main thing I
don't like is that my X11 code, which functions perfectly well on
other (nameless) machines, hangs the blasted node on the share-mode
server. Not just a kluge, but a buggy kluge.
IMHO, HP will do well to learn what it can from DomainOS, then
propagate HP's un*x as fast as they can, if they hope to sell any more
Apollo machines at all...
Obviously, just my opinion, as one who develops software on other,
more standard machines and has to port to the DomainOS environment.
--Steve
--
Steve Hamm ------- Motorola Inc. Semiconductor Systems Design Technology
3501 Ed Bluestein Blvd., MD-M2, Austin TX 78762
Ph: (512) 928-6612 Internet: hamm@austoto.sps.mot.com
Fax:(512) 928-7662 UUCP: ...cs.utexas.edu!oakhill!austoto!hammnazgul@alphalpha.com (Kee Hinckley) (04/24/91)
In article <HAMM.91Apr23071238@toto.austoto.sps.mot.com> hamm@austoto.sps.mot.com (Steve Hamm) writes: > >-----On 12 Apr 91 20:30:08 GMT, tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) said: > >Thomas> ....you clearly favor the share mode server, and HP/Apollo >Thomas> realizes that many folks do. Thats why the share mode server >Thomas> continues to be supported/ bug-fixed, albeit the process for >Thomas> customer bugs appears to be lacking. I missed this message the first time around. The sharemode server continues to be supported/bug-fixed!? Who is supporting it? Who do I submit the bugs to? I haven't even bothered writing them down because I'd been told it was no longer supported. If that's not true I would *definitely* like to know it. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.