Conference bulova::decw_jan-89_to_nov-90

    Indeed this is a bug.  It has been QARed already.
    
    The READ path in the transport layer should be re-entrant, but due to
    this bug, it screws up its internal state.  I'm afraid this isn't
    likely to be fixed until AFTER V5.4.
    
    James

Non-ast reentrancy of Xlib is a big problem for this customer and it 
has been CLD'd to get high priority.

I hope something can be done to fix it before 5.4 because our official 
line is that Xlib is ast reentrant and that the read side of the 
transport isn't seems like an enormous exposure for us.

    
    Failure to fix this problem quickly will greatly damage Digital's
    DOS/PC Solutions strategy.
    
    Marshall
    

>    Failure to fix this problem quickly will greatly damage Digital's
>    DOS/PC Solutions strategy.

If you feel this is important, I suggest you QAR this.

>If you feel this is important, I suggest you QAR this.

It was quar'd.  This comes from a customer and since it is critical it 
was CLD'd.

RE: .5

>It was quar'd.  This comes from a customer and since it is critical it 
>was CLD'd.

The CLD process gives you a direct channel to the responsible developers.  Why
aren't you using that instead of whining in NOTES conferences?

--PSW

    
    Considering the less than satisfactory response when this bug was first
    reported, why not post it in this notes file and let everyone know
    about it? Doesn't seem unreasonable to me. Very much appreciate
    past resonses to our problems here; people have been wonderful.
    Isn't best we share this information with as wide an audience as
    possible?
    
    Marshall
    
    
    

It is reasonable to post problems in this notes file for general discussion.

What makes developers mad is when the problem described in the notes files
appears to be a serious problem affecting customers, and yet there is no
indication that the problem has been sent through regular channels.  Perhaps
the problem has been properly escalated.  But if you post the description
in this notes file, please so indicate!

Another problem is that it is not clear to us whether TOOLEY::B_WACKER and
WSINT::GOLDBERG are working on the same customer problem or not.  If these
problems are for two different customers, then two separate QARs should be
entered.  The priority for one customer's problem may be different from
another customer's problem, even though they stem from the same bug.

Finally, statements like "must be fixed quickly!!" have no use in this
notes file, as audience here is the general Digital community, not the
developers.  I have no idea why "failure to fix this problem quickly will
greatly damage Digital's DOS/PS Solutions strategy."  The correct procedure
is to explain in a QAR in detail exactly what this means.  Only then will
solving the problem get the proper priority it deserves.

Thank you.

>there is no indication that the problem has been sent through regular
>channels.

Back a couple of notes I said it had been CLD'd (and got accused of 
whining), so it was indicated.

>Another problem is that it is not clear to us whether TOOLEY::B_WACKER
>and WSINT::GOLDBERG are working on the same customer problem or not.

It is the same problem for the same customer.  Goldberg is something 
like contract administrator/liason.  I'm with CSC/CS.

If you're interested there's an article in Digital News, February 19, 
on page 62 about the coprocessor product that is affected.

>...have no use in this notes file

Agreed, but Goldberg doesn't frequent here and doesn't know that.

>audience here is the general Digital community, not the developers.

In my experience the "official" channels are woefully slow and often
breed misunderstanding.  SPR's average 6-9 months to get a response.
CSSE is often over-committed and not much help.  Until the other 
channels are dramatically improved notes is what gets the job done,
and even informal participation by developers is crucial to what
success we do have. 

I put a little more back in here after I had enough to work the 
customer issue because I thought the DW community needed to be aware 
that Xlib may not be as ast reentrant as we believe.  If I've broken 
notes etiquette in the process please send me mail and I'll fix it.

Bruce

RE: .9

>Until the other 
>channels are dramatically improved notes is what gets the job done,

That is precisely Peter Vatne's point.  NOTES conferences DON'T get the job
done, where "the job" is getting problems reported to the developer and fixed in
a reliable, timely fashion.

If, as you say, you have a CLD open on this problem, then you already have a
channel open to the developers responsible for fixing this problem.  Make your
comments about the urgency of the problem known through those channels.

--PSW

>NOTES conferences DON'T get the job done, where "the job" is getting
>problems reported to the developer and fixed in a reliable, timely
>fashion.

In this and many cases the first thing is to figure out if there 
really is a problem.  Notes and all you gurus who read them are 
invaluable in this respect.  From the hinterlands the QAR system is
impossible to search, so notes also tend to flush known problems and
sometimes provide already fixed next release knowledge unavailable
elsewhere.  I don't think any CSC specialist thinks notes will get 
anything fixed.

>Make your comments about the urgency of the problem known through
>those channels. 

I don't think I made such comments and I already apologized for 
Goldberg's unfamiliarity with the whole system.  I feel like I'm being 
blamed for another's actions and since I have a vested interest in 
this conference, the product, and relations with the developers I 
repeat my request to direct your remarks through mail to the concerned 
party and not beleaguer it further here.

Bruce (not Marshall)

    Two comments with two different hats on:
    
    1. with my devo hat on:  We have gotten the CLD (the same day the
    original note was written, it turns out) and are working on it.
    
    2. with my moderator hat on top of the devo hat:  I don't see anything
    in this note that has not been in 100 other notes and has not been
    stamped on.  In my opinion, it is fine to discuss problems in here and
    to vent frustrations etc etc.  The crucial thing to recognize is that
    this conference is a hit-or-miss thing.  You may happen to catch the
    eye of a devo who will go off and investigate the problem and come up
    with a workaround or a fix quickly.  However, on the other hand, we are
    not measured on how many notes we answer.  We are measured and
    monitored on how we deal with QARs/SPRs/CLDs.
    
    In addition, I don't think there is any apology due for anything said.
    I don't believe there were any breaches of ettiquite (sp?).  However,
    from a practical standpoint, you should know that as developers reading
    a conference, it is real easy to filter out "this problem is critical"
    or to get annoyed when seeing it for the nth time.  The reason is that
    nearly everyone says their problem is critical.  We have no way to
    weigh one critical problem against another.  In this particular case,
    we have raised the priority of the problem quite high based on both the
    CLD and the fact that in looking at the problem, we realized that it
    probably affects a large number of people.
    
    Burns

    
    	I wonder what CLD stands for in this context.
    
    	QAR :== Quality Assurance Report
    	SPR :== System Performance Report
    
    [	CLD :== Command line definition	]? :-)
    
    
    

Customer Level D??? or some such nonsense.  What the letters stand for
is not as important as what it is...

A CLD is a mechanism by which a customer can unilaterally elevate a
problem that is having a substantial impact on the operation of their
system (i.e. an impact on their business).  CLDs can only be closed
by the customer and cannot be closed by engineering, SWS or CSSE and
can be closed by a patch sent to the customer, or anything else that
makes the customer happy.

CLD's appear to be a compromise between the black hole called a SPR
and KO call.

While intended for serious business impact problems (as I've been told) the
CLD is now the weapon of choice by customers who are used to zero response
via the "normal" problem reporting mechanisms.

    A CLD is the mechanism originally created by Field Service (now
    Customer Service) which allows a local unit manager responsible for a
    particular customer installation (i.e. they have purchased a support
    contract and the resources to service this contract are supplied by the
    local office unit manager). The unit manager may choose to escalate
    critical customer situations which may require corporate level
    resources for resolution by logging a call with the "Central/Critical
    Log Desk". This CLD is part of the process called MAP (Management
    Action Planning) which requires the local unit manager to create and
    follow thru on an action plan which is designed to resolve the customer
    issue.
    
    Although originally designed to escalate down hardware situations, it
    was adopted for the software arena when FS became responsible for
    remedial software issues. 
    
    We now have (again) an agreement (at least for VMS components) that a
    priority 1 or 2 SPR will be treated at corporate levels with the same
    priority as a CLD. For a time this was not the case, and therefore
    customers and the field began using the CLD process when a priority 1/2
    SPR would have been used before. Hopefully the corporation is beginning
    to get the kinks worked out of the process.
    
    A CLD can only be closed by the originater (called the Problem Manager)
    and that is normally only done when the customer has been satisfied to
    the extent that Digital is able to do so.
    
    Bob Bowman
    Consultant, CSC/CS
    (Part of the team responsible for handling 
     Software Problem escalations...but not CLDs)

    re: .-1
    
   > A CLD can only be closed by the originater (called the Problem Manager)
   > and that is normally only done when the customer has been satisfied to
   > the extent that Digital is able to do so.
  
    This is the theory. However often CSSE/and/or/Engineering close
    CLDs without any confirmation that either the customer or Problem
    manager are satisfied with the proposed solution. But i guess this
    is a rathole that does not belong here.
    
    		Pekka

    
>    1.  Is this likely to be the same problem described in reply 0?
    
    	Same problem.
    
>    2.  Are there other problems relating to ASTs and event handling to
>        watch out for?
    
    	Prior to V5.4, if both non-ast processing and AST processing are
    	both waiting for an event or reply, they can incur this problem.
    
>    3.  Does removing the synchronize really cure the problem?
 
    	Since the synchronize performs a wait for a reply, yes.  If you
    	added another form of event or reply wait to your AST processing,
    	the problem would return.
    
    	This bug is fixed in V5.4.
    
    
    		Sam