Conference iosg::all-in-1_v30

    
    Iwao,
    
    VIEW TRACE is equivalent to CTRL/B. You wil see up to 1000 lines of
    TRACE. The TRACE output will then indicate what can be done next:
    
                                       Trace to Terminal
    ******************************************************************************
    Trace information is discarded on returning to the menu (using RETURN/EXIT).
    To prevent this, press GOLD F at the bottom to retain up to 1000 lines.
    ******************************************************************************
    
    Ciao,
    
    	Simon

Hi Iwao,
	What in particular did you find difficult about the trace log? We're 
currently eagerly gathering suggestions for a possible future release!

-eileen

    
    Just a few comments on the new tracing facilities in V3.0.
    
    Overall I find it a major improvement.  The layout is a lot
    more readable and easier to understand.
    
    But, I do find it a bit of a pain sometimes that I can't see the trace
    as things are happening. It is sometimes useful to see the trace in the
    context of what the user is seeing.
    
    I also find it annoying that DCL trace *does* come out immeadiately
    when the rest does not. This makes it very hard to work out what is
    going on. I can appreciate, however, the technical problems involved -
    DCL tracing is only "set verify" after all (I think).
    
    Andy
     
    

    Andy,
    
�   But, I do find it a bit of a pain sometimes that I can't see the trace
�   as things are happening. It is sometimes useful to see the trace in the
�   context of what the user is seeing.
    
    You can re-direct the output to SYS$OUTPUT in the LOG field.
    
    Sjaak.

	Thanks my friends .....

> 	Re:4
>
> 	You can re-direct the output to SYS$OUTPUT in the LOG field.

	It's good information for me. I wanted to know this information !  


> 	Re:2
>
>	What in particular did you find difficult about the trace log? We're 
>	currently eagerly gathering suggestions for a possible future release!

	Now, I am using ALL-IN-1 V3.0 everyday. And I have become quite 
	accustomed to see the Trace Log.

	But, Now I have one question.

	+--------------------------------------------------------------+
	|                   Trace Flag Argument Form  		       |
	|							       |
	|  _ FLOW (xxxxxxxxxxxxxxxxxx)     _ SCRIPT   _______________  |
	|  _ SCRINP (xxxxxxxxxxxxxxxxxx)   _ SYMBOL   _______________  |
	|  _ IO (xxxxxxxxxxxxxxxxxx)       _ FORM     _______________  |
	|	                                             |         |
                                                             |
	      Q1) What is this field ?  <--------------------+
		  and How use this field ?

	      Q2) Which manual explain about "How to use Trace Log" ?



	Thanks your help.
	Iwao

    
    Iwao,
    
    > _ FORM     _______________ 
    
    These fields can be used to indicate which 'specific' forms, Scripts,
    symbols etc. you want to include in the TRACE. E.g. indicating:
    
    _ SCRIPT  *CM_*________
    
    means that the TRACE will only TRACE Scripts starting with 'CM_' and
    not any others. It's a possibility to filter information.
    
    Look at the documentation for:
    
    	Guide: Chapter 25, Problem solving
    	APR II: SET_TRACE function
    
    That is, if you have the V3.0 docset.
    
    Ciao,
    
    	Simon

    
    It seems that the SCRIPT filter isn't effective when there's a lot of 
    named data associated with the scripting language, as is the case at the 
    Customization Management main menu.
    
    I've also been experiencing an annoying problem with VIEW TRACE :
    
    After several trace operations, targeting the terminal memory buffer, I'll 
    eventually be unable to view the trace output that is written there...
    Pressing CTRL/B returns the message -
    
    "You can't use CTRL/B at this point"
    
    Pressing CTRL/A returns the message - 
    
    "You can't use CTRL/A at this point"
    
    Can anyone offer a guess as to why this happens?
    
    Also, when I test an element in Customization Management, and the
    element generates an error, the message returned is 
    
    "Error occurred during the DO mode script test.."
    
    This is even the case when I'm testing a form that generates an error.
    So if I'm testing a form, and the form calls a DO script, but its the 
    form that generates the error, the message that's returned leads me 
    to believe (wrongly) that the error is being generated from the 
    script that gets called.  I hope I'm making sense...
    
    Steve

Script tracing includes named data which doesnt support filtering .. so I agree,
it adds a lot of noise. I'll add a suggestion to the long list for a PFR. 

If you are looking for something specific amongst the noise though, use the
text serach facility (type character string and hit FIND / GOLD FIND)

RE the problems with the CTRL keys, do any other CTRL keys work at that point?
What menu are you on when you try it?

-eileen

    
    Ooops...customized version of form DEFAULT was it.
    
    Embarassed,
    
    Steve

    
    Steve,
    
    >    Also, when I test an element in Customization Management, and the
    >    element generates an error, the message returned is
    >
    >    "Error occurred during the DO mode script test.."
    
    Unfortunately I cannot give a plausible reason why this is the way it
    is. When testing a BLP the message will refer to 'Error during MERGE
    operation...' which is correct, but testing elements which call one of
    the following test procedures will all return the message you
    mentioned, together with an additional message (use GOLD/W) which
    indicates the real problem:
    
    	CM_TEST_COM.SCP
    	CM_TEST_FDL.SCP
    	CM_TEST_FRM.SCP
    	CM_TEST_SCRIPT.SCP
    
    The fact that the forms calls a DO procedure has nothing to do with the
    final message. CM tests an element of a specific element type, and
    that's it.
    
    Sorry, but it looks like SPR time.
    
    Ciao,
    
    	Simon