Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!pacbell.com!tandem!zorch!vsi1!frame!bugeater.frame.com!tvb From: tvb@bugeater.frame.com (Terry V. Bush) Newsgroups: comp.sys.apollo Subject: Re: APRs (FLAME ON) Message-ID: <18361@frame.UUCP> Date: 12 Apr 91 04:11:37 GMT References: <9104082143.AA24021@pan.ssec.honeywell.com> Sender: news@frame.UUCP Organization: Frame Technology, 1010 Rincon Cir., San Jose, CA 95131 Lines: 120 Phone.......: (408) 954-3900 (Office) "tvb@frame.com (email) 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!!!