Conference iosg::all-in-1_v30

    Hi,
    
    There are various topics on nested .IF and syntax rules. As a start you
    could visit the notes 80, and 340. In there I tried to give my 2� point
    of view. Particular in the replies 80.3 and 340.9. Using these rules I
    solved your problem. 
    
    What I'm actually doing is faking a IF-THEN-ELSE structure (I've
    learned that while programming DCL in VMS 3.5!). Using ALL-IN-1 V3.0
    that is not necessary anymore.
    
    Hope this helps, Sjaak.
    
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    
    The script:
    
.LABEL main

   DECIMAL I
   COMPUTE #count = 0
   TEXT OPEN out "test.txt" /WRITE

   .LABEL repeat

      TEXT WRITE OUT #count

      .IF #count GE 5 THEN .GOTO else_if_1

         .IF #count GE 2 THEN .GOTO else_if_2

            TEXT WRITE out "        The count < 2"

            .GOTO end_if_2
         .LABEL else_if_2

            TEXT WRITE out "        The count < 5"

         .LABEL end_if_2

         .GOTO end_if_1
      .LABEL else_if_1

         TEXT WRITE OUT "        The count < 7"

      .LABEL end_if_1

      COMPUTE #count = #count + 1

      .IF #count LT 7 THEN .GOTO repeat
   .LABEL until

   TEXT CLOSE out

.EXIT
    
    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    
    The output TEST.TXT:
    
0
        The count < 2
1
        The count < 2
2
        The count < 5
3
        The count < 5
4
        The count < 5
5
        The count < 7
6
        The count < 7

	It's unclear whether you intended to write out only one line per #COUNT,
or write out *all* lines that apply (e.g., if #COUNT is 1, then it's <2, <5,
*and* <7).  However, taking the example of .1, here's what you could do to get
one line per #COUNT -- and it doesn't require any .GOTOs, or multiple 
statements:

	DECIMAL I
	COMPUTE #COUNT = 0
	TEXT_FILE OPEN/WRITE OUT "TEST.TXT"

.LABEL LOOP
	TEXT_FILE WRITE OUT #COUNT
	.IF #COUNT LT 2 -
	  THEN -
	    TEXT_FILE WRITE OUT "The count < 2" -
	  ELSE -
	    .IF #COUNT LT 5 -
	      THEN -
		TEXT_FILE WRITE OUT "The count < 5" -
	      ELSE -
		.IF #COUNT LT 7 -
		  THEN -
		    TEXT_FILE WRITE OUT "The count < 7"

	COMPUTE #COUNT = #COUNT + 1
	.IF #COUNT LT 7 THEN .GOTO LOOP

	TEXT_FILE CLOSE OUT

Knowing what you want the output to look like would help in diagnosing
the problem you're attempting to solve.

If you wont the output as follows I would suggest the script after it.


0
        The count < 2
        The count < 5
        The count < 7
1
        The count < 2
        The count < 5
        The count < 7
2
        The count < 5
        The count < 7
3
        The count < 5
        The count < 7
4
        The count < 5
        The count < 7
5
        The count < 7
6
        The count < 7



        DECIMAL I
        COMPUTE #COUNT = 0
        TEXT OPEN OUT "TEST.TXT" /WRITE

        .LABEL LOOP
        TEXT WRITE OUT #COUNT
        .IF #COUNT LT 5 THEN -
                oa$null\-
                .IF #COUNT LT 2 THEN -
                        TEXT WRITE OUT "        The count < 2" \-
                TEXT WRITE OUT "        The count < 5"
        TEXT WRITE OUT "        The count < 7"


        COMPUTE #COUNT = #COUNT + 1
        .IF #COUNT LT 7 THEN .GOTO LOOP

        TEXT CLOSE OUT


The "OA$NULL\" is there to keep ALL-IN-1 from getting confused with an
".IF" statement in the "THEN" clause.  Anytime I want to nest IFs one 
right after another (and I do it often) I add an OA$NULL in the THEN 
clause before the next IF.

Good luck,

Joe

	I made the ass/u/mption about the output because that was the *harder*
of the two cases.  If .0 really just wanted the results in .3, then it wouldn't
need to be that convoluted.  Just do:

	DECIMAL I
	COMPUTE #COUNT = 0
	TEXT_FILE OPEN/WRITE OUT "TEST.TXT"

.LABEL LOOP
	TEXT_FILE WRITE OUT #COUNT
	.IF #COUNT LT 2 THEN TEXT_FILE WRITE OUT "The count < 2"
	.IF #COUNT LT 5 THEN TEXT_FILE WRITE OUT "The count < 5"
	.IF #COUNT LT 7 THEN TEXT_FILE WRITE OUT "The count < 7"

	COMPUTE #COUNT = #COUNT + 1
	.IF #COUNT LT 7 THEN .GOTO LOOP

	TEXT_FILE CLOSE OUT

I made the assumption that the question wasn't so much, "How do I get this
output?", but "Why isn't the second IF being recognized?".

The answer is that for some reason (there are many people listening who can
explain this, but I can't) ALL-IN-1 won't recognize an ".IF condition THEN
.IF condition..." unless you provide a valid statement between the "THEN"
and the following "IF".  OA$NULL is the perfect valid statement to fix this
problem.

So, ajb, who guessed correctly, or is your question still unanswered?

Joe

    And the winner is...

    Joe Maddox!  You're right in .5, Joe, that in actual fact I was only
    using the script to test the syntax, and I accept your solution in .3
    although I'm sure that you would agree that it is *unusual* for it to
    be necessary.

    I'd be interested in knowing why (from a philosophical perspective)
    since command parsers are not that uncommon and even non-languages like
    DCL do not suffer from this sort of 'awkwardness'.

    Thanks for your help, Frank and my appologies for not properly defining
    the output that I was attempting to generate.

    Sjaak, I appreciate your help and the pointers to the other notes.

    regards,
    ajb
    

    Read you documentation. The syntax of a .IF-THEN is:
    
    	.IF rse THEN ([1 script command] or [stack of functions])
    
    While subtle in nathure, that means if you have a . following the
    THEN you can not use a \ or any combination of then to tie a second
    command or script directive to the command. OA$NULL is one way to
    force your way around this problem, the second is the use of the
    .FUNCTION script directive.
    
    Rick
    
    	

    wrt: .-1... Sorry Rick, I disagree, the documentation says that this IS
    so, not WHY it is so. Please don't take offense, for none is intended,
    I was only wondering why you limit it to one script command.
    
    Regards,
    ajb

	OK, to take this philosophical discussion a little further...

	The reason for the limitation of one script directive is that the
Script Processor *does not* recognize "stacking", using backslashes.  That is
a convention known only to the Command Dispatcher.

	When I am in a script, the Script Processor looks at every "token" as
either beginning with a "." or not.  If it does, then THE REST OF THE TOKEN
is a *single* script directive; if it does not, then the script processor
assume that this is a command line and (internally) puts a ".FUNCTION" at the
beginning of the line.

	(Just for a little history, the script processor was initally only
intended to process directives and keystrokes -- like a Script mode script.
But since "procedures" could be created by putting the script directive .FUNCTION
at the beginning of each line, the "short cut" was to create DO scripts that
do that automatically.)

	Stacking directives was never part of the script processor.  That's why
the documentation says 1 script directive or 1 command line.  It's only due to
the "extra" processing of the command dispatcher that "1 command line" is
allowed to contain multiple functions, separated by backslashes.

	(BTW, if you think about *who* is processing the line -- i.e., the
Command Dispatcher or the Script Processor -- it will also be clear why the
"same" line may appear different in Named Data than in a script:)

	Named Data:

	.IF condition THEN function1\\function2\\function3

	DO script

	.IF condition THEN function1\function2\function3

	In the first case, it's the Command Dispatcher processing the line,
and (internally) executing the OA$SCP_DISPATCH function (*AFTER* reducing
multiple backslashes!); in the second case, it's the Script Processor, who
doesn't *care* about backslashes, and just passes the remainder of the line
following the THEN clause to the Command Dispatcher!

	Clear as mud?

	8^)

    Thanks, Frank,
    
    I see, I was (wrongly) assuming that the same command processor was
    doing everything. I can understand why the script processor would have
    limited command functionality since it is really there to handle '.'
    commands.
    
    Thanks, one and all, for bearing with me.
    Regards,
    ajb
    
    PS: I still think it makes coding cumbersome, though! ;-)