[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

708.0. "MERGE output includes NUL character" by ADO75A::BEESTON () Tue May 19 1992 09:56

    
    I have a problem with a NUL character being printed in the output 
    of a MERGE command. 
    
    However, the problem is not consistent. With search order set to DVF 
    the MERGE output does not include this NUL character. With search 
    order set to DFT, the NUL is printed and appears as a 'glitch' on the
    output. The character always occurs in the same place in the output.

    There is another line in the template file with the exact same format 
    and this line does not cause any problems. If I completely remove the 
    template line where the error occurs the NUL is not included in the
    output. 

    The problem occurs if the output of the MERGE is either a .WPL file or 
    a .TXT file. 
    
    My latest idea is that the print problem is caused by the 
    FORMAT function in WPPRINT as I can print a .TXT output file directly 
    from VMS and the output is clean or when printing if I force the 
    #PRINT_FORMAT to not be WPSPLUS the output is also clean. However 
    this doesn't explain how the NUL gets there in the first place.

    Any ideas as to what might be causing this problem. I have tried a lot 
    of test scenarios with this one and all with the same result.. failure

   Liz


T.RTitleUserPersonal
Name
DateLines
708.1SIOG::T_REDMONDThoughts of an Idle MindTue May 19 1992 12:276
    Is the live version of the element compiled into a TXL?
    
    That might account for the difference between DFT (default - including
    TXLs) and DVF (develop first, ignore TXLs).
    
    Tony
708.2Yes, its in the BLPADO75A::BEESTONTue May 19 1992 14:2910
    
    Yes, the live version of the BLP is in the TXL.
    
    Also, when directing the MERGE output to a WPL file a dump of the WPL
    file shows the NUL character. It is also possible that when printing
    the output to a printer the 'glitch' is actually the characters '{NUL}'
    overprinted on each other. It is hard to tell exactly what the
    characters are but this combination is possible.
    
    Liz
708.3more informationADO75A::BEESTONWed May 20 1992 10:1222
    Further...
    
    I require the output of the MERGE to be a WPL file so that I can
    maintain bolding etc. and the NUL always occurs at the end of the line.

    Further investigation reveals that I can get rid of the NUL by 
    modifying the line following the problem line in the BLP. For example if I 

    . remove a data item from the line
    . remove bolding from a piece of text
    . move the first data item 1 column to the right

    At this stage I think that the problem occurs when the MERGE is 
    formatting the line after the one that includes the NUL but it still 
    only occurs in DFT not in DVF.

    RE .1 When I trace this code the DVF version includes references to 
    Text DSAB Name:TXT$TXL_BLP. Does this mean I am referencing a BLP 
    item not currently compiled in a TXL?
         
    Does this information mean anything to you ... Liz

708.4It's in the TXLADO75A::BEESTONThu May 21 1992 09:3019
    It's in the TXL !!
    
    If I force the code to use the template in OA$BLP rather than 
    using the OA$TXL_SEARCH_ORDER to find the BLP the output is OK.

    If I OA$TXL_LIST the TXL version of the BLP to a file and dump the 
    output I can see the NUL character.

    So, how might this character be included in the TXL. Could there 
    be a problem with the OA$TXL_COMPILE function.

    I have two very similar BLP's and both are effected by this problem 
    in exactly the same way.
	
    Also when I OA$TXL_LIST an element the list does not clear the line
    before it displays the next line so there is additional text
    information displayed. Is this normal.

    Thanks.. Liz
708.5any examplesIOSG::ECHRISTIEEileen ChristieFri May 22 1992 11:578
It does look like a TXL compilation problem. I havent had time to look into it
but if you supply an example of a BLP which exhibits the problem, I'll see if
I can get some investigation done


thanks

eileen
708.6Example suppliedADO75A::BEESTONMon May 25 1992 04:5434
	Here is a reduced version of the BLP causing the problem.

	The problem occurs at the end of the first line of ==='s.
	
	Thanks.. Liz

                      
<&BOLD>As at<&CLEAR><&TAB 17><#FRS_DATE:2>-<#FRS_DATE:2:2>-<#FRS_DATE:4:4> 
<&BOLD>Last Report Date<&CLEAR> <#CUS_LNSR_DATE:2>-<#CUS_LNSR_DATE:2:2>-<#CUS_LNSR_DATE:4:4>

<&TAB 12><&BOLD>Credit<&TAB 25>Legal Debt<&TAB 43>Usage<&TAB 56>Security<&TAB 72>Current<&CLEAR>
<&TAB 12><&BOLD>Limit<&TAB 26>Exposure<&TAB 56>Valuation<&TAB 71>Est. Loss<&CLEAR>
<&BOLD>Class 1<&CLEAR><&TAB 11><#CUS_CLASS1_LIMIT><&TAB 26><#CUS_CLASS1_LEGAL_DEBT><&TAB 41><#CUS_CLASS1_USAGE><&TAB 56><#CUS_CLASS1_SEC_VALUATION><&TAB 71><#CUS_CLASS1_EST_LOSS>
<&BOLD>Class 2<&CLEAR><&TAB 11><#CUS_CLASS2_LIMIT><&TAB 26><#CUS_CLASS2_LEGAL_DEBT><&TAB 41><#CUS_CLASS2_USAGE><&TAB 56><#CUS_CLASS2_SEC_VALUATION><&TAB 71><#CUS_CLASS2_EST_LOSS>
<&TAB 11>========<&TAB 26>========<&TAB 41>========<&TAB 56>========<&TAB 71>========
<&BOLD>Total<&CLEAR><&TAB 11><#CUS_LIMIT><&TAB 26><#CUS_LEGAL_DEBT><&TAB 41><#CUS_USAGE><&TAB 56><#CUS_SEC_VALUATION><&TAB 71><#CUS_EST_LOSS>

<&BOLD>LRD<&CLEAR><&TAB 11><#CUS_LNSR_LIMIT><&TAB 26><#CUS_LNSR_LEGAL_DEBT><&TAB 41><#CUS_LNSR_USAGE><&TAB 56><#CUS_LNSR_SEC_VALUATION><&TAB 71><#CUS_LNSR_EST_LOSS>
<&TAB 11>========<&TAB 26>========<&TAB 41>========<&TAB 56>========<&TAB 71>========
<&BOLD>Difference<&CLEAR><&TAB 11><#CUS_DIFF_LIMIT><&TAB 26><#CUS_DIFF_LEGAL_DEBT><&TAB 41><#CUS_DIFF_USAGE><&TAB 56><#CUS_DIFF_SEC_VALUATION><&TAB 71><#CUS_DIFF_EST_LOSS> 

<&TAB 11><&BOLD>Principal<&TAB 26>Specific<&TAB 39>Int. Accrued<&TAB 56>Book Debt<&CLEAR>
<&TAB 10><&BOLD>Written-Off<&TAB 26>Provision<&TAB 41>& Forgone<&TAB 56>Exposure<&CLEAR>
<&BOLD>Class 1<&CLEAR><&TAB 11><CUS_CLASS1_WRITE_DOWN><&TAB 26><CUS_CLASS1_SPEC_PROV><&TAB 41><CUS_CLASS1_INT_FORGONE><&TAB 56><CUS_CLASS1_BOOK_DEBT>
<&BOLD>Class 2<&CLEAR><&TAB 11><CUS_CLASS2_WRITE_DOWN><&TAB 26><CUS_CLASS2_SPEC_PROV><&TAB 41><CUS_CLASS2_INT_FORGONE><&TAB 56><CUS_CLASS2_BOOK_DEBT>
<&TAB 11>========<&TAB 26>========<&TAB 41>========<&TAB 56>========
<&BOLD>Total<&CLEAR><&TAB 11><CUS_WRITE_DOWN><&TAB 26><CUS_SPEC_PROV><&TAB 41><CUS_INT_FORGONE><&TAB 56><CUS_BOOK_DEBT>

<&BOLD>LRD<&CLEAR><&TAB 11><CUS_LNSR_WRITE_DOWN><&TAB 26><CUS_LNSR_SPEC_PROV><&TAB 41><CUS_LNSR_INT_FORGONE><&TAB 56><CUS_LNSR_BOOK_DEBT> 
<&TAB 11>========<&TAB 26>========<&TAB 41>========<&TAB 56>========
<&BOLD>Difference<&CLEAR><&TAB 11><CUS_DIFF_WRITE_DOWN><&TAB 26><CUS_DIFF_SPEC_PROV><&TAB 41><CUS_DIFF_INT_FORGONE><&TAB 56><CUS_DIFF_BOOK_DEBT> 
 

708.7what version?IOSG::ECHRISTIEEileen ChristieThu Jun 25 1992 14:296
Liz,
	I finally got round to trying this. What version are you running? I 
cant duplicate it on ALL-IN-1 V3.


-eileen
708.8ALL-IN-1 V2.4ADO75A::BEESTONMon Jun 29 1992 03:446
    
    eileen
    
    This is ALL-IN-1 V2.4
    
    .. Liz