Conference iosg::all-in-1_v30

This looks like a bug, although I don't know the reason why.

Rewritten to use the V3.0 structured .IF the code works...

   .IF #NBS_DATE NES ""
   .THEN
      DATE_CONVERT #DAY, #NBS_DATE, 12
      DATE_CONVERT #DATE, #NBS_DATE, 9
      DATE_CONVERT #TIME, #NBS_DATE, 11
   .END_IF

But your original code doesn't, even after changing your IF to an .IF

    GET #NBSDATE2 = OA$DATE_NBS  
    
    .IF #NBSDATE2 NES "" THEN -
    	DATE_CONVERT #DAY2, #NBSDATE2, 12\\ -
    	DATE_CONVERT #DATE2, #NBSDATE2, 9\\ -
    	DATE_CONVERT #TIME2, #NBSDATE2, 11

An interesting point is that the first DATE_CONVERT bombs as it complains 
about the input date format not being in a range of 0 to 14, so maybe it's 
the internal command line parsing that's upset by DATE_CONVERT being stacked?

Tony    

    Make that:
    
    GET #nbsdate = OA$DATE_NBS  
    
    .IF #nbsdate NES "" THEN -
    	DATE_CONVERT #day,  #nbsdate, 12 \ -
    	DATE_CONVERT #date, #nbsdate,  9 \ -
    	DATE_CONVERT #time, #nbsdate, 11

    Using \ instead of \\ was discussed earlier, I can't remember which
    note.
    
    Regards, Sjaak.

    �Make that:
    � 
    �GET #nbsdate = OA$DATE_NBS  
    �
    �.IF #nbsdate NES "" THEN -
    � 	DATE_CONVERT #day,  #nbsdate, 12 \ -
    �	DATE_CONVERT #date, #nbsdate,  9 \ -
    � 	DATE_CONVERT #time, #nbsdate, 11
    �
    �Using \ instead of \\ was discussed earlier, I can't remember which
    �note.
    
    This works, but we can't find out why. What happened to the old '\\' to
    seperate commands?
    
    Steve.
    

    I'll bite. See notes 340 and 80.
    
    Regards, Sjaak.

	Yes, please read the other notes that have gone into this in detail.
Your line was exactly correct, had it been issued from Named Data (i.e., from
the Command Dispatcher).  However, coming from within a script, you do *not*
need the double backslashes, as the Script Processor doesn't recognize them.

	F

> However, coming from within a script, you do *not* need the double 
> backslashes, as the Script Processor doesn't recognize them.

Unless, of course, you are writing a FOR statement instead of an .IF
statement.  (Go figure.)

Joe

� Unless, of course, you are writing a FOR statement instead of an .IF
� statement.  (Go figure.)

	But that's what this note (and others like it) are all about -- so you
don't have to "go figure"!  I would have thought by now that the difference
noted in your reply would be apparent: a FOR statement -- whether issued from
Named Data or from within a script -- must make a call to the Command Dispatcher.
Hence, any nested functions within its DO clause will require multiple back-
slashes, *wherever* they occur.

	An .IF statement, on the other hand, is processed differently from Named
Data than from within a script.  In a script, the Script Processor is entirely
capable of handling the .IF clause without dispatching to the Command Dispatcher;
in fact, it's the Script Processor that handles *ALL* .IF statements.  Even if
they come from Named Data, for instance, ALL-IN-1 will change a ".IF blah..." to
"OA$SCP_DISPATCH .IF blah..." -- and execute an internal function that invokes
the script processor.  But in so doing, anything nested in that string must
make use of the double-backslash syntax.

	Seems to be pretty straightforward to me...

	F	8^)

Frank,

I don't mean to get into an argument here.  Yes, I understand (now that
I've read the explanation a third time) why the .IF and FOR behave 
differently, although I must admit that I don't yet have a tight grasp
on the command dispatcher.

Because it can be explained does not make it straigt forward to us small-
brained people.  When looking at the rules for using backslashes without
pretending to be a command dispatcher, do you really think it is straight-
forward and logical?

Rules for Backslashes:

When writing .IF statements in a script you must seperate the dependent
functions with a backslash.  For each additionally nested .IF statement
the number of backslashes between dependent functions must be doubled.

When writing .IF statements in named data, since functions in named data
already need a backslash seperator, the dependent functions of the first
level .IF must be seperated by two backslashes.  Again, for each addition-
ally nested .IF statement the number of must be doubled.

When writing a FOR statment in a script you must seperate the dependent
functions with two backslashes if the FOR statement is not part of a 
higher level conditional statement.  The same holds true for writing a
FOR statement in named data, i.e., a FOR statement takes only two back-
slashes if it is not part of a higher level conditional statement.

If a FOR statement is written as a dependent function of an .IF statement 
one might suspect that it's dependent functions would need double the 
number of backslashes dependent functions of an .IF statement at the 
same level, but it dosen't.  It takes the same number.

Now I think I'm confused again.  8')>

Joe

	Joe,

	You were doing *great*... up to that last paragraph:

� If a FOR statement is written as a dependent function of an .IF statement 
� one might suspect that it's dependent functions would need double the 
� number of backslashes dependent functions of an .IF statement at the 
� same level, but it dosen't.  It takes the same number.

	Not so; let's take a non-nested FOR:

	FOR rse DO function1\\function2\\function3\function4

	In the above statement, functions 1-3 will be executed for each iteration
of the FOR loop; function 4 will only be executed once -- after the FOR loop has
completed.  *REGARDLESS* of whether this is executed from Named Data or from
within a script.

	Now, from within a script:

	.IF condition THEN FOR rse DO function1\\function2\\function3\function4

will do the exact same thing *IF* the condition is true.  If false, it will do
nothing.  However, if the .IF is to be invoked from Named Data, and function4 is
to be considered part of the .IF conditional, then you would have:

;;whatever;;

.IF condition THEN FOR rse DO function1\\\\function2\\\\function3\\function4

	(If that's to difficult to follow, try adding an *unconditional"
"function5" to the end of the last two, and you'll see the difference.)

	Sorry if it's confusing, but I'll also point out that:

	a) The ALL-IN-1 Application Programming II course provides a *very*
thorough description of all of this, removing the "smoke and mirrors", and

	b) One of the reasons that script directives and functions have *always*
been separated in the APR documentation, ever since V2.0 is that they DO operate
very differently, and in different contexts.  It may not be important to under-
stand that there are two separate internal mechanisms within ALL-IN-1 to handle
script directives vs. functions; but I think it *is* important to realize that
the two *are* different.

	F

For the sake of no one in particular:  myself, Frank and many others have had
problems in the past understanding the issues of backslashes.  Frank and I even
have "advantages" that others might not have to better understand this stuff and
we have both "struggled".  Only after many attempts to get what we thought
should work working have some of the layers of the onion peeled away to reveal
the core.

No one should feel too bad about having difficulty with this.  It is NOT simple
to accept, figure out, and it has not been simple to describe (in the docs).
A training class should not be the way to get this information across to the
application developers.  It (the backslash information) is just too important
and causes too many false turns.

Perhaps the training material surrounding this issue should be worked into the
very next possible release (VNPR, a new FLA!) of the ALL-IN-1 documentation,
getting it into programmer's hands.  Perhaps this training material should be
released to this conference NOW, to stop the "pain".  After all, if it is so
good as to avoid all future confusion...

/Marty

    
    Well, as long as we're talking about versions AFTER V2.4...  
    
    I would suspect that with the advent of .THEN, .ELSE, and .ENDIF 
    in V3.0, the days of The Many Multiple Backslashes (TMMB) are numbered.  
    If so, this discussion will become moot except for hysterical purposes.
    
    Just think!!  In years to come, application programmer's eyes will
    glaze over at the sight of 4\8\16\32 backslashes.  (The same
    way mine do when someone mentions OAMAILBOX and/or DCLMAILBOX...  ;')
    
    Maybe Frank should have entered his note in this way:
    	.IF #THIS_IS_A_SCRIPT EQS OA$Y AND #THIS_IS_CLEAR EQS OA$N -
    	  THEN DISPLAY Your displeasure -
    	      \.GOTO CLASS
    
    	.IF #THIS_IS_NAMED_DATA EQS OA$Y AND #THIS_IS_CLEAR EQS OA$N
    	 THEN DISPLAY Your displeasure \\.GOTO CLASS
    
    
    That should open a new can of worms...  ;')
    
    Jack

	Unfortunately, Jack, your examples held a hidden answer to your question
about whether .ENDIF and the .THEN/.ELSE syntax would put an end to backslashes.
Since this construct applies only to scripts, and not to Named Data, you're still
going to see the backslash hodge-podge in Named Data... unless, of course, every-
one begins programming all of their Named Data with XOP's!  Remember, a Named
Data line -- whether a menu option to be executed, or a /PRE or /POST, or what-
ever else -- contains *one command line* only.

	Backslashes forever!

	F

Re: .12

Frank,

>	Now, from within a script:
>
>	.IF condition THEN FOR rse DO function1\\function2\\function3\function4

I think this is what led me to make the rash statement that the FOR 
statement's dependent functions wouldn't need the expected four back-
slashes.  I recal from some application I did months ago (I don't have
a clue which one) that I discovered that the above statement would
cause FUNCTION1, FUNCTION2, and FUNCTION3 to all be executed as part
of the FOR loop.  Is this correct?  If so, how do you terminate the
FOR statement without terminating the .IF?

Joe (who votes with Marty that this should perhaps be discussed in 
more detail in the APR)

    Hi,
    
    I hardly ever had problems using multiple backslashes. Just try to
    avoid to use them by implementing faked IF THEN ELSE constructions (I
    described this many times before). Ofcourse this works only in scripts.
    As for the named-data, I found the XOP (I use it as a sub-routine call)
    one of the most wanted functions.
    
    Sjaak.

� >	.IF condition THEN FOR rse DO function1\\function2\\function3\function4

� I discovered that the above statement would
� cause FUNCTION1, FUNCTION2, and FUNCTION3 to all be executed as part
� of the FOR loop.  Is this correct?  If so, how do you terminate the
� FOR statement without terminating the .IF?

	That's the whole point; the double backslashes insure that the 3
functions *are* part of the FOR loop; it's the single backslash before the 4th
function that separates it out of the FOR loop, but still keeps it within the
context of the .IF condition.

From .12:

>	You were doing *great*... up to that last paragraph:
>
>� If a FOR statement is written as a dependent function of an .IF statement 
>� one might suspect that it's dependent functions would need double the 
>� number of backslashes dependent functions of an .IF statement at the 
>� same level, but it dosen't.  It takes the same number.
>
>	Not so; let's take a non-nested FOR:
>
>	FOR rse DO function1\\function2\\function3\function4
>
>	In the above statement, functions 1-3 will be executed for each iteration
>of the FOR loop; function 4 will only be executed once -- after the FOR loop has
>completed.  *REGARDLESS* of whether this is executed from Named Data or from
>within a script.
>
>	Now, from within a script:
>
>	.IF condition THEN FOR rse DO function1\\function2\\function3\function4
>
>will do the exact same thing *IF* the condition is true.  If false, it will do
>nothing.  However, if the .IF is to be invoked from Named Data, and function4 is
>to be considered part of the .IF conditional, then you would have:

From .-1

>� I discovered that the above statement would
>� cause FUNCTION1, FUNCTION2, and FUNCTION3 to all be executed as part
>� of the FOR loop.  Is this correct?  If so, how do you terminate the
>� FOR statement without terminating the .IF?
>
>	That's the whole point; the double backslashes insure that the 3
>functions *are* part of the FOR loop; it's the single backslash before the 4th
>function that separates it out of the FOR loop, but still keeps it within the
>context of the .IF condition.

Now I don't see what was wrong with my statement in the first paragraph
above.  Since an .IF statement normaly needs double the number of back-
slashes in its dependent functions as would otherwise be needed, and
since a FOR statement's dependent functions need two backslashes if it
is not nested, then it would seem logical to the hapless observer that
a FOR statement nested within an .IF statement would require four back-
slashes as delimiters for its dependent functions.  I know this is not
true, I think I sort of understand why, but I still think it is less than
intuitively obvious.

Thanks for all the helpfull explanations,

Joe

    RE: .19

    I'm getting confused as to inclusion marks ">" and "�".  

    >Now I don't see what was wrong with my statement in the first paragraph
above.

    Which first paragraph?  I don't really understand all this dispatch
    stuff.  But in a script, if you want to do something unconditionally,
    you put it on the next line with no "-" and no "\".  Therefore, to my
    way of thinking, the script processor is smart enough to realize that 

    .IF condition THEN function1\function2

    means that you want function2 to be conditional, because otherwise you
    would have put it onto the next line:

    .IF condition THEN function1
    function2

    (The backslash in a script with no conditional is terribly inefficient,
    so one doesn't do it.  It has to change mode to "immediate mode" at the
    backslash, then change back for the next line.  

>	.IF condition THEN FOR rse DO function1\\function2\\function3\function4

    I suspect that there is a similar explanation for the case above. 
    ALL-IN-1 probably stops processing when the condition is false.  Should
    it?  Logically, I would say no, but it is easy enough to put it onto
    the next line, so that is what everyone does.  

    I am in the process of installing ULTRIX for the first time, and the
    guy showing me keeps assuring me that the commands are convenient, just
    not intuitive.  I think that's the case here.  Once you know it, you
    just go with it.  ALL-IN-1 was originally written in the tradition of
    TOPS-10 by TOPS-10 system engineers.  It was a great operating system,
    but none of the commands made any sense when compared with each other.
    People in this conference pride themselves on knowing these
    idiosyncrasies.

    Incidentally, re: .14

>    Maybe Frank should have entered his note in this way:
>    	.IF #THIS_IS_A_SCRIPT EQS OA$Y AND #THIS_IS_CLEAR EQS OA$N -
>    	  THEN DISPLAY Your displeasure -
>    	      \.GOTO CLASS
>    
>    	.IF #THIS_IS_NAMED_DATA EQS OA$Y AND #THIS_IS_CLEAR EQS OA$N
>    	 THEN DISPLAY Your displeasure \\.GOTO CLASS

    The syntax here is invalid and will yield an error message.  Immediate
    mode again.  Even though the script processor is working here, it is in
    immediate mode, rather than DO mode.  In addition, I always avoid
    putting anything after DISPLAY, because ALL-IN-1 gets confused,
    particularly in named data.  Data on the same line works differently
    from data on the same line after a DISPLAY.  This is especially true of
    ELSE:  
    
    .IF condition THEN DISPLAY This is clear \\GET #A=1 ELSE function2
    
    (in named data) will not always work right, if at all. Again, you don't
    expect ALL-IN-1 to be clean about these things.  There are ways to get
    around these problems, so you do it.
    
    Ben

    Ben

    
    Congratulations, Ben
    
>    	.IF #THIS_IS_A_SCRIPT EQS OA$Y AND #THIS_IS_CLEAR EQS OA$N -
>    	  THEN DISPLAY Your displeasure -
>    	      \.GOTO CLASS
    
    I was beginning to wonder if anyone was going to pick up on the fact
    that you can't mix functions and .GOTOs.  I thought I'd slipped that
    one past.  
    
    Good eyes...  ;')
    
    Jack