Conference bulova::decw_jan-89_to_nov-90

    The design of the DECwindows application interface encourages memory
    leaks.  It is a rare application that doesn't have any.
    
    Some frequent sources of leaks - creating compound strings and
    not freeing them (especially with routines like CSTRCPY using
    the same string as input or output - the input string is now
    dangling), and not freeing the argname strings created with
    DWT$VMS_SET_ARG (use DWT$VMS_FREE_ARGNAMES).
    
    If you want to point me at (or send me if it is small) the source,
    I'll take a quick peek to see what I can spot.
    
    			Steve

	This is Mel Adams from CSSE.

	When you have a CLD open with us, you are taking the wrong approach to
go directly to Engineering.

	I will be addressing this through chanels.

							Mel

I just suppose this shows that the CLD process is now no more than yet another
variant of SPR.  Everything goes to CLD instantly.  Sigh.

			Steve

>                              -< Wrong Approach >-
>	This is Mel Adams from CSSE.
>	When you have a CLD open with us, you are taking the wrong approach to
>go directly to Engineering.
>
>	I will be addressing this through chanels.

What ever happened to just getting the right answer to the customer?  
I sure hope the channels are bi-directional!

Steve, how does it feel to be a DW engineer, "directly accessed" 
through notes, no less.

Bruce (Who still has NO RESPONSE WHATSOEVER from a CSSE inquiry on 
April 17, 1990)

RE: .4

>Steve, how does it feel to be a DW engineer, "directly accessed" 
>through notes, no less.

Steve wouldn't know.  He's not a DECwindows engineer.  He works on the VAX
FORTRAN compiler project.

>Bruce (Who still has NO RESPONSE WHATSOEVER from a CSSE inquiry on 
>April 17, 1990)

So escalate it.  You have a name you sent the request to, and that person has
a supervisor or manager.  Rattle chains until somebody gets you an answer.

--PSW

   << Forget the FLAME and prepare for >>
        << THERMONUCLEAR EXPLOSION >>

RE .2 and .4

You guys just don't get it do you?  THE SYSTEM DOES NOT WORK!

"Rattling chains" DOES NOT HELP!  You get this nice "form
letter" MAIL response from your request that says "Perhaps
you do not understand the way problems are prioritized at
CSSE ..." The only way to get any sort of an answer to a
technical question through "official channels" is via a CLD.
This is a totally unacceptable situation that the CSC's
have had to live with since the breakup of COG.  ...Nobody
seems to care!  I had two calls that were elevated to CSSE,
each was open FOR OVER A *YEAR*!  I never got answers. 

We folks on the front lines have to interact with customers.
We have to GET THE JOB *DONE*!  WE have to be aware
of CUSTOMER SATISFACTION.  That means we bend the rules
sometimes.  I am 110% in favor of "going through channels"
and "using the system" whenever possible.  ...but when the
system DOES NOT WORK, or worse yet, when people ACTUALLY TRY
TO GET IN THE WAY OF SOLVING THE PROBLEM (this has ACTUALLY
happened to me, not once, but twice) ... that is where I
draw the line!   You can choose to help me solve a 
customer's problem.  You can "add value".  You can choose to 
NOT help me solve a customer's problem.  ...but if you are 
not going to help, then STAY OUT OF THE WAY!

Two excellent examples of how good things could be are the
excellent support that the CSC gets from the DECdesign and
the Ada Engineering teams.  Another fine example is how very
well Andy Mermell stays on top of Motif at CSSE.  These 
folks are much more receptive to "informal" means of 
answering technical questions.  Sometimes, that's the only 
way we folks at the CSC's are able to get the job done.

I challenge anyone in DECwindows Engineering to come to
either the Atlanta or the Colorado CSC and sit on the phones
and answer customer questions on DECwindows! ... and that
goes for ANY engineering group for any product or component!
This is a "challenge", not a "dare"; and I mean it in the 
best spirit.



Ken Tice
Colorado CSC 
Language Support Team 

    I've done what Ken suggests - I've been out to Colorado twice and
    have sat in on the phones with folks from the Languages support 
    group.  It is a sobering experience.
    
    But there's a flip side too - if the formal channels are bypassed at
    the first opportunity and the engineers involved directly, we'd get
    a lot less engineering done.  I am getting more and more mail messages
    and telephone calls from around the company because someone was given
    my name as someone who once answered a question on a certain topic.
    (Also, though Paul is correct that I am a VAX FORTRAN developer, I'm
    also informally responsible for part of the DECwindows kit, including the
    FORTRAN versions of HELLOWORLD and DECBURGER, so I am especially
    interested in questions on using DECwindows from FORTRAN.)
    
    Rather than everyone flaming at each other here, how about we solve
    the customer's problem?
    
    				Steve

    See CLT::FAKE_VM for information about a tool which can help you find
    memory leaks.
    
                                August G. Reinig

RE: .6

Calm down.  I agree with you that the current problem reporting and resolution
scheme has almost totally broken down.  If you and your management can't get
anywhere with overrides, a CLD is regrettably the only option.  Aside from
that, you might have your customer consider trying it from
the outside.  Were I your customer, I would be wondering at this point just
what I am getting for the money I'm paying DEC on my service contract, and I'd
be making noises of the "resolve this if you ever expect to sell any products
to this company again" variety in the direction of DEC's sales and support
management.

--PSW

>Aside from that, you might have your customer consider trying it from
>the outside. 

In this case, had you just called a support center you should have 
gotten the same answer, much quicker, without any kind of elevation.  
I can't guarantee who you'll get, but the way the problem was stated 
made the cause of the leak pretty obvious.  I'm pretty sure anyone 
here or in Atlanta would have given you the right answer, no muss, no 
fuss.

In defense of CSSE, they typically cover a lot of products.  It used 
to be that one or two CSSE people handled all the languages and VIA 
products that have over 60 people devoted to them here in Colorado.  
You tell me if it is likely that a couple of people "dabbling" in many 
products are going to be as knowledgable as those who work with a few 
products full time.  It is very unrealistic to have such a small group 
doing "backup" for so many people on so many products.  They just 
won't know the answers.

The problem is that such is the "official" way of doing things and the 
unsuspecting get burned.  On the other hand, getting offensive 
("pursuing through channels") about it is not the right approach 
either.

There's a lot of knowledge in this company and most people are willing 
to share it.  Do try official regular support first, and maybe
escalate to a senior person there if it doesn't feel right.  Notes are
our real backup and most reasonable questions get answered pretty
fast.  CSSE may have a charter, but they (generally) don't have the 
manpower to add much value over the support centers.  They also spend 
a lot of time travelling.  We don't CLD questions, but, rather,
demonstrable bugs that, hopefully, go directly to engineering because
they are critical and only engineering can fix them.  I think we do a
pretty good job of weeding out the user errors/misunderstandings.   
Used in this way the CLD system works reasonably well.

Bruce

Hello,

Steve Lionel (.1) (thanks Steve!) was correct the problem had to 
do with VMS_FREE_ARGNAMES.  The customer was using this call after
a VMS_SET_ARG however they were specifying a pointer to the 
Argument list rather than a count due to an error in 
the DECwindows VMS DECwindows Toolkit Routines Reference 
Manual (Section 3.1 VMS FREE ARGNAMES).  

The documentation states...

argcount

	"the index to the argument list where the 	
	argument is to be placed"


This is actually ambiguous in that the variable name is
ARGCOUNT but the description says it is an index.  My customer 
trusted the description not the name.

Thus, the memory wasn't actually being freed even though they were 
issuing the FREE ARGNAMES call.

One more behind us!!!

Cheers,

Peter

    I told Peter I'd enter a documentation QAR on his behalf.
    
    And just a nit - the customer was passing zero, the index of the
    first entry, not a pointer to the structure itself.
    
    I must admit it has me worried just how much trouble this one
    little documentation error caused....
    
    				Steve