| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 80.1 | | IOSG::WDAVIES | Vic Williams is still not free | Mon Feb 24 1992 12:02 | 26 |
| The basic rule of thumb is the same as when you quote quotes in DCL.
eg write sys$output " "" Hello "" "
gets "Hello" on the screen.
If you remember that the statement seperator is "\" then
.IF cond THEN x \ y
means the same as
.IF cond THEN do x
do y regardless
But if you have
.IF cond THEN x \\ y
Then it means process X\\Y as condition.
Its sort of the inverse of the quotes, but I think it is the best
way of thinking about it.
Aldo you can insert FOR DOs - and these likewise will start doubling
if you nest statements.
.IF cond THEN FOR A DO x \\\\ y \\z
Then it means process X\\\\Y FOR A and then z once, IFF cond.
Winton
|
| 80.2 | Unless it's a script...in which case... | HYTIDE::CREAMER | Keep a low profile | Mon Feb 24 1992 14:10 | 24 |
|
> If you remember that the statement seperator is "\" then
> .IF cond THEN x \ y
> means the same as
> .IF cond THEN do x
> do y regardless
Note that the above statement would hold for Named Data and within
templates, but in a script both x and y would be done. As a general
rule, you need to double the number of backslashes in named data,
since a single backslash separates functions in the same way that
beginning a new line separates functions in a script.
As I'm sure you have noted, in V2.4 and earlier versions, complex
.IF statements can confuse ALL-IN-1. I have heard that V3.0 has new
functions (ENDIF ??) to help cope with this problem, but until I
get a copy of the new APR, I can't give you the exact syntax.
Aren't backslashes FUN???
HTH,
Jack
|
| 80.3 | What a fun :-) | UTRTSC::BOSMAN | We're just sugar mice in the rain | Mon Feb 24 1992 14:57 | 32 |
| Hi,
Backslashes are fun :-) try to avoid them! You just have to invert the
condition and jump to a kind of faked end_if:
.IF NOT (condition) THEN .GOTO end_if
.
. conditional statements
.
.LABEL end_if
This syntax is a result of using conversion-rules due to implement the
Nassi-Shneidermann structure for ALL-IN-1 script and DCL command-
procedures. This makes it possible to program GOTO-less (except for the
ones to implement the structure). It helps one to program in a
structured way (YES) and make the programs more readable!
Unfortunatly this doesn't work in NAMED-DATA. But you can make it
visible by indentation:
.IF (condition) THEN
function-1 \\ <- stay in .IF clause, indent next function
function-2
ELSE
function-3 \\ <- stay in ELSE clause, indent next function
function-4 \ <- end of .IF statement, don't indent next func.
function-5 \
I *NEVER* put more than one function on one DATA-line; maybe it has
negative influence to the performance, but it read 1000 times better!
Sjaak.
|
| 80.4 | Syntax of structured If for DO scripts | IOSG::ECHRISTIE | Eileen Christie | Tue Feb 25 1992 15:51 | 29 |
| The syntax of the new V3 structured IF (for DO scripts only) is as follows
.IF expression
.THEN
then-clause
.
.
[.ELSE]
[ else-clause]
[ . ]
.END_IF
eg, curtesy of APR Ref 1,
.IF #ANSWER EQS OA$Y
.THEN
.IF #FLAG EQS "1"
.THEN
DISPLAY ("Working...")
FORCE
DO CHECK
.ELSE
DO TEST
.END_IF
.ELSE
GET OA$DISPLAY = FN$CONCAT("The value of #ANSWER is ", #ANSWER)
.END_IF
|
| 80.5 | Request for more info os Syntax rules and undocumented featues | GIDDAY::SETHI | Man from Downunder | Wed Feb 26 1992 00:31 | 26 |
| Thanks for all your replies I wanted to include this topic to enable us
all to know the syntax rules and it should include not just "\". How
about symbols when do we use @#symbol_name to translate the symbol
contents or how about @@#symbol_name.
Also re: note 80.3 Sjaak thanks for the reply but what is the
Nassi-Shneidermann structure. Can I get some more information as this
would be useful so that I am clear about what you are saying.
I have customized ALL-IN-1 and what causes problems are the syntax
rules there is very little documentation. It's not a big problem
but it wastes time while you are trying to find out. I am hoping that
this topic will be of use to all whenever they encounter a syntax
problem.
Also undocumented features cause a problem such as for example
GET OA$MESSAGE='envelope field' etc. but this is not a problem because
I know how it works. Can anyone point me to a document that contains
undocumented feature as well as the documented. I know it's a bit of a
contridiction asking for a document containing documentation about
undocumented features !!! BUT you never know.
Thanks
Sunil
|
| 80.6 | @#symbol_name | SCOTTC::MARSHALL | Pearl-white, but slightly shop-soiled | Wed Feb 26 1992 09:33 | 19 |
| Hi,
Sticking an @ in front of a symbol name causes the contents of the symbol to
be treated as a symbol name: the expression returns the contents of that
symbol. Its easiest to explain with an example (-> denotes output from the
preceding command):
GET #SYMBOL1 = "Hello Sunil!"
GET #SYMBOL2 = "#SYMBOL1"
GET #SYMBOL3 = #SYMBOL1
GET OA$DISPLAY = #SYMBOL1 -> Hello Sunil!
GET OA$DISPLAY = #SYMBOL2 -> #SYMBOL1
GET OA$DISPLAY = @#SYMBOL2 -> Hello Sunil!
GET OA$DISPLAY = #SYMBOL3 -> Hello Sunil!
HTH
Scott
|
| 80.7 | That little "dig" against documentation | SIOG::T_REDMOND | Thoughts of an Idle Mind | Wed Feb 26 1992 11:33 | 7 |
| Re. 5
When you say that "there is very little documentation", can you be a
bit more specific? What documentation are you referring to and what
would you like to see?
Tony
|
| 80.8 | NS-diagram | UTRTSC::BOSMAN | We're just sugar mice in the rain | Wed Feb 26 1992 13:26 | 51 |
| Sunil,
The NS-structure is another way to create a flow of you're program, in
fact you first have to create a diagram, and then the program. Using
NS-diagrams you can program without using GOTO's. Ofcourse this makes
your program much more readable. A NS-diagram is a rectangle,
containing several blocks that represents basic-structures as
IF-THEN-ELSE, WHILE-DO, REPEAT-UNTIL etc.
Because DCL and ALL-IN-1 doesn't have any notice of WHILE-DO,
REPEAT-UNTIL and CASE-OF structures you've to fake them. Using
conversion-rules you can write a ALL-IN-1 or DCL program from a
NS-diagram. Except for the GOTO's to implement the diagram the program
doesn't contain GOTO's. Modifying or updating such programs is most of
the time piece of cake.
I'm short of time but if you want I can send you those conversion-rules
and a little story on how to use them.
Success, Sjaak.
-----//-----
An example:
----------------------------------------------------
| |
| (function) |
| |
|----------------------------------------------------|
| |
| WHILE (condition) DO |
| |
| -------------------------------------------|
| | |
| | (function) |
| | |
| |-------------------------------------------|
| | \ IF (condition) / |
| |T \ / N|
| |---------------------.---------------------|
| | REPEAT | | |
| | | (function) | (function) |
| | | | |
| | ------------| |
| | | |
| | UNTIL (condition) | |
|----------------------------------------------------|
| |
| (function) |
| |
----------------------------------------------------
|
| 80.9 | No "dig" intended just need more info if possible | GIDDAY::SETHI | Man from Downunder | Thu Feb 27 1992 01:02 | 9 |
| Hi Tony,
I would like to see them documented in the ALL-IN-1 Application
Programming: Mini-Reference. I would just like to see a brief
discription of the functions. As I have said that sometimes you are
unable to find the fuctions documented as per note .5. It would by nice
to have them documented if it's possible.
Sunil
|
| 80.10 | | SIOG::T_REDMOND | Thoughts of an Idle Mind | Thu Feb 27 1992 08:26 | 6 |
| Why isn't the full APR suitable for this kind of material? The
mini-reference is getting a little big to carry around... After all,
how often do you need to consult rules of syntax (every day in my
case)?
Tony
|
| 80.11 | Corrections to .4 | IOSG::HULIN | Ian Hulin, IOSG: REO, DTN 830-6141 | Thu Mar 12 1992 13:26 | 34 |
| There were a few stray hyphens in Eileen's original note, so here's a
cleaned-up version.
.IF expression
.THEN
then-clause
.
.
[.ELSE]
[ else-clause]
[ . ]
[ . ]
[ . ]
.END_IF
eg, courtesy of APR Ref 1,
.IF #ANSWER EQS OA$Y
.THEN
.IF #FLAG EQS "1"
.THEN
DISPLAY ("Working...")
FORCE
DO CHECK
.ELSE
DO TEST
.END_IF
.ELSE
DISPLAY (FN$CONCAT("The value of #ANSWER is ", #ANSWER))
.END_IF
|
| 80.12 | Syntax rules to access segmented keys | BUSHIE::SETHI | | Tue Sep 14 1993 06:25 | 42 |
| Hi All,
I am looking for some general information regarding the syntax rules to
access segmented keys. I have seen topic 1549 but really I require
rules that I can give to a customer. He has requested more information
for the following situations:
------
Attached is the FDL file used. You may notice that several of the
alternate keys are segmented and that the later segments are
actually the primary key. By doing this I am able to retrieve on an
alternate key and have the retrieval order sorted the way I like it.
I'm using an reference like:
OF_PH_ENTRY:PREFERRED_NAME
in a FOR loop to retrieve using KEY 13 of the FDL file.
PREFERRED_NAME is also the name of the first field/segment in the
key.
The above practice works but I'd like to know why, what should I do
if the first field of the key and the key have different names?
I'm also using an reference like:
OF_PH_ENTRY:TELEPHONE_DESCRIPTION
where TELEPHONE_DESCRIPTION isn't the name of any key but it is
the first field/segment of the primary key. This practice also works
but I'd like to know why?
------
If you would like me to provide the FDL I will do so. But I feel if I
have a good explaination I will be able to give that to the customer.
The problem I have is that the documentation is not very clear on the
subject so I am a bit stuck. Your hellp would be appriciated.
Regards,
Sunil
|
| 80.13 | Syntax notes on DATASET:KEY_OF_REFERENCE | SCOTTC::MARSHALL | Spitfire Drivers Do It Topless | Tue Sep 14 1993 17:06 | 55 |
| Sunil,
I'll have a go at answering your questions, but my answer is based on educated
guesswork rather than precise knowledge, so I make no guarantees!
The DSR syntax DATASET:KEY_OF_REFERENCE is exactly that - you can specify the
name of the key on which you want ALL-IN-1 to search. There is no syntax that
allows you to specify the individual segments within a key. ALL-IN-1 will pass
the whole key to RMS, and leaves it up to RMS to do the segment-matching within
a record (OK, in practice it doesn't actually go and lookup segments; it's all
done via lookups on the index for the specified key; see the RMS manuals for
details!). So the position and name of individual segments of keys defined by
an FDL file doesn't matter to ALL-IN-1. If you want (limited) control over
segments of keys, you need to map the file with an entry form.
Note that in a lot of cases, it (probably) doesn't matter whether or not
you specify a key of reference (unless you're looking up one specific record
by an alternate key value); the actual records that ALL-IN-1 finds from the
dataset will be determined by other terms in the DSR (dataset reference) or
RSE (record selection expression). The main advantage (and in some cases this
could be a very important advantage) in specifying a KOR (key of reference) is
that you're giving ALL-IN-1 a "hint" on how it should do keyed lookups, and this
could yield significant performance improvements. But this is only a hint to
ALL-IN-1; it will revert to sequential lookups if it thinks that the keyed
lookups won't yield the data required by the DSR or RSE.
So, given that information, we can answer your questions: why do the two
scenarios you gave work?
The first one is simple; the fact that the KOR you supply is also the name of a
segment of the key doesn't matter, as ALL-IN-1 isn't looking at the segment
names. You give a KOR, and a key value, and ALL-IN-1 gives that to RMS. RMS
splits the key value up into (conceptual) segments, and finds the record. You
(and ALL-IN-1) needn't be concerned about the individual segments. Indeed,
there is no syntax in ALL-IN-1 that lets you get at the individual segments.
Just forget that the key has segments, and it should all make sense.
(OK, if you know where the segments are, you could use FN$ functions to split
up the key value, but that's really outside the scope of the DSR/RSE itself!)
In the second case, you give a KOR that isn't a KOR at all; it's actually the
name of a segment of a key. As the value you give isn't the name of a key,
ALL-IN-1 throws it away and just defaults to the primary key. By coincidence,
the primary key is what you wanted (you gave the name of a segment of the
primary key) so you get the right data back. ALL-IN-1 ignores (more
specifically, doesn't even know!) that you're trying to specify just one segment
of the key; it passes the key value you give to RMS as the whole primary key
and lets RMS sort it out. If you'd given the name of a segment of an alternate
key, ALL-IN-1 would still have done the lookup on the primary key, as the
segment name would be meaningless to ALL-IN-1. In that case, you might not
have got the results you wanted, or intended.
I hope that explains it a bit for you!
Scott
|