maj@cl.cam.ac.uk (Martyn Johnson) (07/21/89)
One of our "sed" scripts stopped working in Ultrix 3.0, with "RE too long". On investigation (we have source) I discovered that part of the internal representation of REs has doubled in size to allow for 8-bit characters, but the workspace arrays have not been correspondingly expanded. So I fixed it locally; it took a few minutes. I reported it to Digital via the DSIN, explaining both the symptom and the cause. I was expecting to hear that it would be corrected in "some future release". Instead, they said that it was a "feature" of Ultrix 3.0, and I would just have to work around it. In fact they said that RE's are limited to "60 characters" - I believe this to be at the very least irrelevant, since it is the COMPILED version of the RE which overflows, and this depends more on its complexity than its length. Is this support? If anyone in Ultrix engineering is listening, how about just increasing the array sizes so that it works as it did before? Martyn Johnson maj@cl.cam.ac.uk University of Cambridge Computer Lab
grr@cbmvax.UUCP (George Robbins) (07/23/89)
In article <843@scaup.cl.cam.ac.uk> maj@cl.cam.ac.uk (Martyn Johnson) writes: > One of our "sed" scripts stopped working in Ultrix 3.0, with > "RE too long". > > On investigation (we have source) I discovered that part of the internal > representation of REs has doubled in size to allow for 8-bit characters, > but the workspace arrays have not been correspondingly expanded. > > So I fixed it locally; it took a few minutes. > > I reported it to Digital via the DSIN, explaining both the symptom and > the cause. I was expecting to hear that it would be corrected in "some > future release". > > Instead, they said that it was a "feature" of Ultrix 3.0, and I would > just have to work around it. In fact they said that RE's are limited > to "60 characters" - I believe this to be at the very least irrelevant, > since it is the COMPILED version of the RE which overflows, and this > depends more on its complexity than its length. > > Is this support? This is the kind of case where filing an SPR is appropriate. The people in software support lack any real authority and the largest part of their responsibility is limited to identifying known problems and customer confusion and supplying workarounds or clarifications. Actually fixing problems requires (I believe) the intervention of Ultrix engineering or at least higher level support people. The lower level persons task is "complete" when he can explain the problem or provide a workaround, extra stimulation may be required generate a fix. Working within the support system, the most effective thing would probably be to represent that this is a crucial problem with no known workaround, and insist on a fix or patch. This forces escalation of the problem into the attention somebody actally competent to understand the issues and recommend that change(s) be made to Ultrix. It also (theoretically) makes the fix available to anyone else calling about the problem. I agree that this is *not* good support. Any issues of this sort should be flowing thru DSIN, into an Ultrix engineering "workbook" so that they do receive consideration for fixing in the next release. Also, if *I* dial up DSIN and query for "sed" I'd expect to find a note derived from this transaction, to make me aware of the newly declared "limitation" - fat chance! The establishment of an effective independent support organization seems to have established a degree of isolation between the customer and the actual software development group that does not work to either the long term benefit of either DEC or the Customer. I would encourage continued posting of problems here, especially those, without/without adequate resolutions. The Usenet readership statistics suggest that there are 500-5000 readers of this group. Even if we assume these numbers are hopelessly inflated one could still represent that postings here reach and audience an order of magnitude or two larger than the "failed" support transaction. The "Introduction to the Support Center" document makes rather amusing, if condescending reading. Did you know that most problems are user errors that can be resolved via socratic dialog with support center personnel? Must be all them VMS types or something... 8-) -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)