Conference clt::decset

    Hi Stanley,

    Thanks for the legwork thus far. 
    
    Not having access to the source code or at least the images is going to
    complicate things rather severely; PCA is that kind of product.
    However, there are some things that we may be able to isolate.

    UNAS is a complete unknown, and it's entirely possible that the problem may
    be the result of attempted interaction between it and PCA. Can the programs
    be run without UNAS, or are they architected such that UNAS is an
    integral component? The more we can find out about it, the better.

>1. pca crashes with following  msg:
>
>    I
>%SYSTEM-F-ACCVIO, access violation, reason mask=00,
>virtual address=00000004, PC=0128D234, PS=0000001B

    Does this program run successfully using just the VMS DEBUGger and not PCA?
    Does GO/NOCOLLECT from the PCA collector succeed or fail? Is UNAS involved
    in this program?

>* program 1 (SINGLE_TEST):
>the /nodebug version worked most of the time;
>The version linked /DEBUG fails every time
>the /debug version runs
>but at the end of the data collection says that no data
>was collected.  Both versions link with UNAS components
>(see below) but they are not used during this execution.

    This is somewhat unclear. Is the DEBUG version using PCA or VMS DEBUG?
    What does it mean that the /nodebug version worked "most of the time"?
    Under what circumstances did it fail? Also, the questions above apply
    here as well.

>The 7th last block has binary data, but the 8th last block
>has debugger reference info - including full file spec's -
>and these references include those to $64$DUA213: which is
>a disk that WE DON'T HAVE !

    We don't have this either, so it's not related to the PCA development
    environment here; it must be related to something in the user's
    environment -- a logical name, a linker options file, or something. This is
    important to track down.

>* program 2 (TU_PROMPT_FOR_SWITCHES):
>Both /debug and /nodebug work fine.

    Does this mean that it worked with PCA or VMS DEBUG (or both)? Is UNAS
    involved in this image?

>* program 3 (TP):
>
>linked with /NODEBUG, runs using UNAS and causes the
>access violation at the start of this call.
>.EXE size 30,000 blocks.

    Same questions. 
    
    As I said, it would be really great if we could get UNAS out of the
    picture and see what happens; would that be possible?

    -- Daryl

    
    
    Daryl,
    
    thanks for prompted response.
    
    I am getting user to collect info as you suggested.
    
    will get back once it is ready.
    
    
    rgds
    
    /stanley

    
    
    DAryl,
    
    
    Sorry for taking so long to get back to you.
    
    
    1. All the program under under vms debugger without problem.
       under pca with do/nocollect ,works fine without error.
    
       Yes for every program user claims UNAS is involved.
    
    
    In regarding to the 7th last block  has binary data ,but
    the 8th block  where debugger has reference , contains 
    information $64$DUA213: , user claims he check all his
    application and Unas, they do not have this disk as reference
    point.   well, we can only treat this a mystry.
    
    * program 2 (TU_PROMPT_FOR_SWITCHES):
    >Both /debug and /nodebug work fine.
    
    this small program does have Unas third party application, and
    it works fine under vms debugger as well as  pca.
    
    >* program 3 (TP):
    >linked with /NODEBUG, runs using UNAS and causes the
    >access violation at the start of this call.
    >.EXE size 30,000 blocks.
    
    
    User can not pull the third party application out of the program.
    So this really a problem here.
    
    
    I will keep you inform about the progress. AS user is NOT
    treat this as high priority.
    
    
    rgds
    
    
    /stanley 
    
    
      
    

    Hi Stanley,
    
    Thanks for the info.
    
>In regarding to the 7th last block  has binary data ,but the 8th block 
>where debugger has reference , contains  information $64$DUA213: , user
>claims he check all his application and Unas, they do not have this disk
>as reference point.   well, we can only treat this a mystry.
    
    That's interesting. How was this information obtained? I'm wondering if
    ANALYZE/OBJECT or /IMAGE could be used to get more information about
    the section that contains the disk reference. If so, it might be
    possible to identify exactly where the reference comes from.
    
>I will keep you inform about the progress. AS user is NOT treat this as
>high priority.
    
    Okay, thanks, that's good to know. I ran this by our PCA engineer, and
    he had the following ideas on additional questions to ask:
    
    - Did these programs ever work with PCA? If so, what has changed?
    
    - Is it possible to try these programs on a VAX? If so, what is the
    result?
    
    - What data is being collected?
    
    - Do any other data collections work (e.g., SET COVERAGE PROGRAM BY
    ROUTINE)? It would be helpful to see what happens with other types of
    collections.
    
    - Which interface is being used, the character cell or the DECwindows?
    Is there any change in behavior when the other is used?
    
    - Would it be possible for us to see the output of the Analyzer LIST
    ALL command?
    
    
    -- Daryl

    
    Daryl,
    
    
    thanks for the reply.
    
    will get back to you later.
    
    
    rgds
    
    
    /stanley