Conference iosg::all-in-1_v30

    Hi 'Chele . . .
    
    You don't indicate what the key is for the entry form RA_USER.  Do you
    know what the key starts with? VMSUSER? followed by APP_CODE?
    
    Have you changing /RSE_VALID=RA_USER.VMSUSR WITH ... to
    		      /RSE_VALID=RA_USER WITH ...
    
    See if that does it.
    
    HTH,
Dan

>>-< Remove the field spec from /rse_valid=dsab? >-

Thanks for the suggestion, but it has Already been done, and it's still slow...

Further suggestions would be appreciated.

Thanks & Regards,

'Chele

	Dan's answer is still valid; what is your key?  If it is not VMSUSR,
then your RSE will not be doing a keyed lookup -- it will be doing a sequential
search.  You might want to turn on RMS tracing and see if you're doing 
GET_BY_KEY or GET_NEXT operations.

	F

Hello again,

The trace is displaying GET_NEXT, which is not what the customer wants of 
course.

I have attached part of his code, if you need more info, let me know

Thanks & regards,

Chele

.
.
NAMED_DATA INDEX=1 NAME='.TYPE'
   DATA='ARG /OVERLAY/HARD="Send a Paging Message"' ;
NAMED_DATA INDEX=2 NAME='.TYPE'
   DATA='/POST="IFEXIT\XOP ~~BUILD_DCL_COMMAND~~\GET OA$DCL=#DCL_COMMAND"' ;
NAMED_DATA INDEX=3 NAME='BT_BEUTENAME'
   DATA=/HARD="Recipients Beute Username"' ;
NAMED_DATA INDEX=4 NAME="BT_BEUTENAME'
   DATA='/RSE_VALID=BT_CORPHONE_ENTRY WITH .BT_BEUTENAME = BT_BEUTENAME AND ' ;
NAMED_DATA INDEX=5 NAME='BT_BEUTENAME'
.
.

	'Chele,

	It appears that your example truncated right in the middle of the RSE,
so I don't have a lot to go on.  But I'll repeat the earlier question:  what is
the primary key of the dataset being validated against (sorry about the bad
grammar!)?  Is it BT_BEAUTENAME?  Or something else in the RSE?  Because unless
the RSE can determine that it *should* be doing a keyed lookup, then it won't.


	Also, if this is a *segmented* key, for instance, and BT_BEAUTNAME is
only *part* of the key, that won't work either.  So:

	1)  What is (are) the entry form key field(s)?
	2)  What is the RMS primary key name?
	3)  What does the full RSE look like?

	F

    Chele,
    
    As Frank says, we need to know the keys to this data set. To get a
    keyed lookup, BT_BEUTENAME must be a primary or alternate key to 
    BT_CORPHONE_ENTRY. If it's an alternate key, then the syntax you need
    for your RSE is:
    
    /RSE_VALID=BT_CORPHONE_ENTRY:BT_BEUTENAME WITH .BT_BEUTENAME = ....
    
    HTH,
    
    Nick

Hello people,

(I had considered putting a grovel in my greeting but I'll spare you that)

>> the primary key of the dataset being validated against 
   It is BT_BEAUTENAME
   Alternate key is BT_PAGERNUM

>>1)  What is (are) the entry form key field(s)?
   It is BT_BEAUTENAME

>>2)  What is the RMS primary key name?
   It is BT_BEAUTENAME

>>3)  What does the full RSE look like?

 aargh 
 - I'll re-enter everything on the customer's fax. One day I'll learn to type!


Thankyou VERY much for your assistance!

'Chele


*******************************************************************************
!		FMS Form Description Application Aid
!			Version V2.4

FORM NAME='BT_PAGER_SEND'
    AREA_TO_CLEAR=1:23
    WIDTH=80
    BACKGROUND=CURRENT
    ;


TEXT (2,31) 'Send a Pager message '
    BOLD
    ;
TEXT (5,1) 'Recipient:'
    ;
TEXT (5,36) 'Priority:'
    ;
TEXT (7,1) 'Pager Message:'
    ;
TEXT (14,2) 'Enter details and press RETURN'
    ;

ATTRIBUTE_DEFAULTS_FIELD
    CLEAR_CHARACTER=' '
    NOAUTOTAB BLANK_FILL NOBLINKING NOBOLD NOREVERSE
    NOUNDERLINE NODISPLAY_ONLY EXHO NOFIXED_DECIMAL
    LEFT_JUSTIFIED NOSUPERVISOR_ONLY NOSUPPRESS NOUPPERCASE
    ;

FIELD NAME="BT_BEUTENAME'  (5,17)
    PICTURE=12'X'
    UPPERCASE RESPONSE_REQUIRED UNDERLINE
    ;
FIELD NAME='PRIORITY'  (5,47)
    PICTURE='X'
    UNDERLINE
    ;
FIELD NAME='PAGER_MESSAGE_1'  (8,1)
    PICTURE=80'X'
    AUTOTAB RESPONSE_REQUIRED UNDERLINE
    ;
FIELD NAME='PAGER_MESSAGE_2'  (9,1)
    PICTURE=80'X'
    AUTOTAB UNDERLINE
    ;
FIELD NAME='PAGER_MESSAGE_3'  (10,1)
    PICTURE=80'X'
    AUTOTAB UNDERLINE
    ;
FIELD NAME='PAGER_MESSAGE_4'  (11,1)
    PICTURE=80'X'
    AUTOTAB UNDERLINE
    ;
FIELD NAME='PAGER_MESSAGE_5'  (12,1)
    PICTURE=62'X'
    UNDERLINE
    ;

ORDER BEGIN_WITH = 1
    NAME='BT_BEUTENAME'
    NAME='PRIORITY'
    NAME='PAGER_MESSAGE_1'
    NAME='PAGER_MESSAGE_2'
    NAME='PAGER_MESSAGE_3'
    NAME='PAGER_MESSAGE_4'
    NAME='PAGER_MESSAGE_5'
   ;

NAMED_DATA INDEX=1 NAME='.TYPE'
   DATA='ARG /OVERLAY/HARD="Send a Paging Message"' ;
NAMED_DATA INDEX=2 NAME='.TYPE'
   DATA='/POST="IFEXIT\XOP ~~BUILD_DCL_COMMAND~~\GET OA$DCL=#DCL_COMMAND"' ;
NAMED_DATA INDEX=3 NAME='BT_BEUTENAME'
   DATA=/HARD="Recipients Beute Username"' ;
NAMED_DATA INDEX=4 NAME="BT_BEUTENAME'
   DATA='/RSE_VALID=BT_CORPHONE_ENTRY WITH .BT_BEUTENAME = BT_BEUTENAME AND ' ;
NAMED_DATA INDEX=5 NAME='BT_BEUTENAME'
   DATA=' .BT_PAGERNUM NES '''';CLOSE_PRIOR\GET BT_BEUTEMAME = ' ;
NAMED_DATA INDEX=6 NAME='BT_BEUTENAME'
   DATA=' BT_CORPHONE_ENTRY.BT_BEUTENAME[OA$SEL_KEY]/AUTO' ;
NAMED_DATA INDEX=7 NAME='PRIORITY'
   DATA='/HARD="Pager Message Priority"' ;
NAMED_DATA INDEX=8 NAME='PRIORITY'
   DATA='/VALID=OA$TABLE:"1,2,3"' ;
NAMED_DATA INDEX=9 NAME='PRIORITY'
   DATA='/RECOG=OA$TABLE:"1 - URGENT,2 - Important,3 - Non-Urgent"' ;
NAMED_DATA INDEX=10 NAME='~~BUILD_DCL_COMMAND~~'
   DATA='GET $DCL_COMMAND = ''BTpage/NOWAIT/PRIORITY='' PRIORITY '' '' ' ;
NAMED_DATA INDEX=11 NAME='~~BUILD_DCL_COMMAND~~'
   DATA='BT_CORPHONE_ENTRY.BT_PAGERNUM[BT_BEUTENAME]' ;
NAMED_DATA INDEX=12 NAME='~~BUILD_DCL_COMMAND~~'
   DATA=' '' "'' PAGER_MESSAGE_1 PAGER_MESSAGE_2 PAGER_MESSAGE_3 
PAGER_MESSAGE_4 ''"''' ;

END_OF_FORM NAME=BT_PAGER_SEND' ;

    Actually I would suspect its the NES operator that flips it back
    into non-keyed lookup. Afraid I don't have time to extract your form
    to verify the reason.
    
    Rick

NES shouldn't make any difference, as the NES doesn't apply to the key field.

Scott

    I tested the operation of the RSE (there are 6 or so syntax errors in the
    FLG) and discovered that removing the NES clause was the only way to
    get the RSE to not search sequentially.  I changed the NES to EQS to no
    avail.  I added the keyname to the dataset name to no avail.

    		   Direct access:

    /RSE_VALID=BT_CORPHONE_ENTRY:BT_BEUTENAME  WITH .BT_BEUTENAME =
    BT_BEUTENAME;CLOSE_PRIOR\
     GET BT_BEUTEMAME =  BT_CORPHONE_ENTRY.BT_BEUTENAME[OA$SEL_KEY]/AUTO

    		Sequential access:

    /RSE_VALID=BT_CORPHONE_ENTRY WITH .BT_BEUTENAME = BT_BEUTENAME AND
     .BT_PAGERNUM NES '';CLOSE_PRIOR\GET BT_BEUTEMAME =
     BT_CORPHONE_ENTRY.BT_BEUTENAME[OA$SEL_KEY]/AUTO

    /RSE_VALID=BT_CORPHONE_ENTRY:BT_BEUTENAME  WITH .BT_BEUTENAME = 
     BT_BEUTENAME AND
     .BT_PAGERNUM NES '';CLOSE_PRIOR\GET BT_BEUTEMAME =
     BT_CORPHONE_ENTRY.BT_BEUTENAME[OA$SEL_KEY]/AUTO

    /RSE_VALID=BT_CORPHONE_ENTRY:BT_BEUTENAME   WITH .BT_BEUTENAME =
     BT_BEUTENAME AND
     .BT_PAGERNUM EQS '';CLOSE_PRIOR\GET BT_BEUTEMAME =
     BT_CORPHONE_ENTRY.BT_BEUTENAME[OA$SEL_KEY]/AUTO

    More confused than usual,
    don

Another not very enlightening observation...

    		   Direct access:

   /RSE_VALID=BT_CORPHONE_ENTRY WITH .BT_BEUTENAME = BT_BEUTENAME AND
     .BT_PAGERNUM = '';CLOSE_PRIOR\GET BT_BEUTEMAME =
     BT_CORPHONE_ENTRY.BT_BEUTENAME[OA$SEL_KEY]/AUTO

    		Sequential access:

    /RSE_VALID=BT_CORPHONE_ENTRY WITH .BT_BEUTENAME = BT_BEUTENAME AND
     .BT_PAGERNUM EQS '';CLOSE_PRIOR\GET BT_BEUTEMAME =
     BT_CORPHONE_ENTRY.BT_BEUTENAME[OA$SEL_KEY]/AUTO

   8^(>

Anybody out there who can clear up this confusion?

Joe

	Well, I'm going to go out on a limb and say that your example indicates
that ALL-IN-1 is actually smarter than we give it credit for.  In your first
case:

   /RSE_VALID=BT_CORPHONE_ENTRY WITH .BT_BEUTENAME = BT_BEUTENAME AND
     .BT_PAGERNUM = '';CLOSE_PRIOR\GET BT_BEUTEMAME =
     BT_CORPHONE_ENTRY.BT_BEUTENAME[OA$SEL_KEY]/AUTO

I'd like to believe that the ALL-IN-1 expression evaluater is "smart" enough to
see the ".BT_PAGERNUM = ''" and recognize it as a "NO-OP" (since *everything*
begins with a null string).  This would then "reduce" the expression to one
that, logically, *should* use keyed access.

	In the other example, we're back to the case where we need to check
every record to see if .BT_PAGERNUM *is equal to* null string; and that seems
to be where the sequential access comes from, judging by the earlier replies.

	F

Hi,

>> Huh?

Chele, assuming your "huh"ing about what I think you are...

First, note that the '=' operator is 'begins with', which is different to EQS.

The expression
    symbol = ''
is always true; to understand why consider this:

symbol = '' is true if symbol contains: 'aaa'
                                        'bbb'
                                        'ccc'
                                        ...etc

symbol = 'x' is true if symbol contains: 'xaaa'
                                         'xbbb'
                                         'xccc'
                                         ...etc

Just remove the 'x' from the second case to see why the first case is always
true.

However, I think it unlikely that the "parser" is detecting this.  I'm afraid
curiosity has got the better of me.  I'm going to go and look at the code and
see what's happening.  I'll be back with a definitive answer and explanation
later, if I survive... fools rush in, and all that :-)

Scott

Well, I'm back!

I've just tested this, stepping through the code in the debugger, and
everything seems to be working properly and doing keyed lookups.  This is with
V3.0, but the relevant bits of code haven't changed since V2.3 (or maybe even
earlier...)

Not having the actual form BT_CORPHONE_ENTRY or its data file, I used PROFIL,
which goes through the same code path.  However, just to be sure, perhaps you
(Chele) could do the tests with PROFIL on the machine where the problem with
BT_CORPHONE_ENTRY is found.  Alternatively, if you can get the form and file
on-line so that I can copy them over and repeat the tests on the "real" data,
I will be happy to do so.

The tests I did were:

1. FOR PROFIL WITH .USER EQS "MARSHALL" DO GET .USER

This correctly identified MARSHALL as a key, then did a GET_BY_KEY operation,
and returned one record.  The RSE then "finished" without attempting to get
any more records.

2. FOR PROFIL WITH .USER = "MAR" DO GET .USER

This correctly identified MAR as the beginning of the key, then did REWIND on
the file, LOCATE (ie find-with-key-greater-than-or-equal-to MAR), then four
GET_NEXT operations.  This correctly returned three matching records (MARCHANT,
MARSHALL and MARTINJ); the fourth GET_NEXT determined that no more records
matched the key, and the RSE "finished".

3. FOR PROFIL WITH .USER = "MAR" AND .AD$MIN NES '' DO GET .USERPROFIL WITH .USER = "MAR" AND .AD$MIN NES '' DO GET .USER

This is the closest I could get to the syntax of the "problem" RSE.  It
worked exactly the same as '2' above: the addition of a non-key field
made no difference to the RSE operation.

4. /RSE_VALID = PROFIL WITH .USER = "MAR" AND .AD$MIN NES '' DO GET .USER

I created an ARG form with this named data, just in case there is something
odd about the operation of RSEs in RSE_VALID.  Again, this worked as in '2'
above: the operations on the file are:  OPEN, REWIND: LOCATE (first record),
then GET_NEXT for as long as the key field matches that in the RSE.  There are
no unnecessary GET_NEXT operations, and the file is not searched sequentially.

So I'm afraid I have no clue why your RSE_VALID isn't working.  Sorry. :-(
My only guess at the moment is that there must be a mismatch between the form
definition, the file's FDL, and the actual file structure, that is confusing
ALL-IN-1 about what it may use as a key field (for example, does the key
position and length in the file (ANALYZE/RMS) match up with the key position
and length on the form?  Does the key in the file have more than one segment
(even if they are contiguous segments)?  Do the key names on the form and in the
file match exactly, with no trailing white space in either?  etc, etc...).  If
you can get me the form and file, I'll check all this too.

Scott

Scott,

I turned trace on on my 2.4 system and entered:

<FOR PROFIL WITH .USER = "MAD" AND .AD$MIN NES '' DO GET .USER

or

<FOR PROFIL WITH .USER = "MAD" AND .AD$MIN NES 'X' DO GET .USER

The trace indicates that the FOR started with the first user record "ADZIJA"
and then did a GET NEXT until it came to "MADDOX".  It continued to do a 
GET NEXT through the rest of the file and displayed "MADDOX" on the screen.

When I entered:

<FOR PROFIL WITH .USER = "MAD" AND .AD$MIN EQS 'Y' DO GET .USER

it did a LOCATE and two GET NEXTs.  It then decided it had no more "MAD"s and
quit, displaying "MADDOX" on line 24.

Needless to second FOR executed significantly faster with trace off.

A <VERSION returns "ALL-IN-1 V2.4 PBL8C3  7-JUN-1990" on my system.

Happy hunting,

Joe

OK, I've cracked it, thanks to Joe's vital clue...

There was a fix in V2.4 to optimise processing of RSEs.  Unfortunately,
it had the side effect of breaking keyed lookups in the way described in this
topic (hardly an optimisation :-).  It has been fixed in V3.0.

The reason I didn't spot this yesterday is that the bug was in the RSE parsing
code, not the RSE evaluation code: I wanted to avoid looking at the former if
at all possible! :-)

So Chele, the answer to give your customer is "upgrade to V3.0" :-)

Scott