Conference iosg::all-in-1_v30

    TABs have always been a problem, mostly after the beginning of the
    line.  I don't think this problem was ever fixed.  As I recall it works
    with non-compiled scripts, but not with compiled ones.  You did say it
    worked in V2.4, but it is certainly unadvisable in any version.
    
    Ben

    Ben,
    
    yes it works with V2.4.
    And it doesn't work with a non-TXLed script. (Haven't tested it with a
    TXLed) And it even doesn't work in interactive (GOLD 7) command-mode.
    
    I guess that some pre V3.0 (customer-written) applications will break after
    V3.0 has been installed.
    
    Fritz

    Does it work with V2.4 patched to K603?  Maybe it's the improved script
    interpreter that's being more picky about what it will accept as a
    separator...
    
    T

    Tony,
    
    it does work with V2.4
    it does work with V2.4/K603
    but it does NOT work with V3.0
    
    so it might be a "centralized parser" problem.
    
    Fritz
    	

The centralised parser is the mechanism for parsing the parameters to a function
in a generic manner and in a single place in the code before continuing with the 
action for the function. It wont impact script parsing.

Looking at a trace it seems that the text after the tab is corrupt .. but
differently whether compiled or non-compiled.

This looks like a bug, I'll raise one

-eileen 

    
    Gru� Fritz!
    
    	I also know how tough it is to find bugs like this, because this
    	one drove me nuts during Diamond development. I had one of these
    	and had to call in the experts to find what the problem was...
    
    	You look at the line and it looks okay 'cos you can't see the
    	TAB.... drove me wild. Even worse if you knew the code worked on
    	V2.4...
    
    Regards,
    Paul

    It looks like this bug has mutated, trying to protect itself. ;-)  Must
    be difficult to fix in code.
    
    Perhaps we should have a utility that removes all the TABs that aren't
    at the beginning of a line and replaces them with spaces.  Of course if
    we did, somebody would use one in a .TEXT statement.  
    
    Unfotunately, new versions of ALL-IN-1 always break some applications. 
    At least it wasn't a function that stopped working.  There are always
    notes in here from frustrated programmers like you and me who had to
    rewrite a script or series of scripts because of something undocumented
    in any release notes.  It's not ok, but it is a fact of life!
    
    Ben

    
    Yes, an upgrade may break a customer application, which once 
    idnetified can be fairly easily addressed. But, the question is
    how many scripts are out there that are shipped as part of the
    V3.0 kit that contain this problem.  that is what I am really
    concerned about.
    
    I know that just last week I was researching a problem with renaming
    a user, and found that one of the script that the procedure runs
    (OA$LIB:GS_RENAME_USER.SCP) was just not doing what it should have
    been.  I turned on tracing and see that it is not executing the
    FOR loop like it should.  Finally, just as a last ditch effort
    I found that the script had TABS in it separating the continutation
    lines of the FOR loop and I removed them and VOILA! the script
    began performing as it should.
    
    So, how do we address the question of the impact that this bug
    may have on the standard SSB shipped product functionality?
    It will be awful time consuming here at the CSC when troubleshooting
    problems caused by this as there are no errors, and no
    specific symptoms.
    
    Please let us here from those in the know on this one.
    
    P.S. I plan to submit this to Engineering as a P1 problem soon.
    
    Worried and confused,
    
    Faith
    

    
    Eileen,
    
     I think that someone from IOSG needs to get involved to help
    determine the impact of the problem on existing V3.0 sites. If
    this (GS_RENAME_USER.SCP) is the only script in the kit that
    may experience the problem it is easy enough to fix it. But,
    we also need to consider customer developed applications. If
    there are alot of elements in the SSB that will likely 
    experience problem with functionality due to this problem, 
    then YES I think it needs to be fixed in the first patch
    that is released.  Also, is the real impact just limited
    to TABS in FOR loops within scripts or is it any TAB in
    a script?  That will also make a difference in determining
    what the impact of the problem will be.
    
    Just my opinion, I would recommend getting IOSG involved.
    
    Faith
    
    

A quick search indicates that this is probably the only script with 
the problem. The problem occurs if there is a a stack of functions
on one line of the script and one of these functions has a trailling
tab, eg <function 1>tab\\<function2>
  

Does this <TAB>\function bug also appear on stacked function lines that
are continued, IE:

	FOR xyz DO -
	<TAB>function1 -
	<TAB>\\function2

  or

	function1 -
	<TAB>\function2

  or

	function\<TAB>function2

  or in Named Data

	function1<TAB>\function2
/Marty

    Marty,
    
     I don't know in general but the GS_RENAME_USER.SCP that had the
    problem was a FOR loop that continued over several lines like:
    
     FOR xyz DO <TAB>-
     <TAB>xxx<TAB>\\-
     .....
    
    Hope that this helps,
    
    Faith