| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1729.2 | also, A1 version & search style | DEVIL1::CAFE1 | Mike Lampson - [email protected] | Fri Nov 06 1992 16:45 | 18 |
| In addition, how did you do your search and what version of
ALL-IN-1 are you using.
There is a bug with alternate keys (in V2.4 at least) such that:
FOR DATASET:KOR2 WITH .%KEY = #STRING DO ...
does a sequential search starting at the first record beginning
with #STRING.
However, if you do:
FOR DATASET:KOR2 WITH .KOR2_FIELD_NAME = #STRING DO ...
where .KOR2_FIELD_NAME is the first field which makes up the
alternate key, the search is sequential.
_Mike
|
| 1729.3 | Key entered on the entry form FOR loops, scp not used | GIDDAY::SETHI | Man from Downunder | Mon Nov 09 1992 00:28 | 93 |
| Hi,
Sorry I forgot to say it is Version 3.0 of ALL-IN-1. The customer call
up the entry form OF020_CORPHONE and enters the Emp No. in the EMPLOYEE
NUMBER field and enters return. If he does the same on the SURNAME
field an indexed search is carried out. I know this happened version
2.<whatever> because I logged a call a few years ago when I was a customer
and was told this is how it works. Before I tell the customer that is
the expected behaviour can this be confirmed.
So in short the style of searching that is used is the entry form and
the Emp. No. is entered as the alternate key to search on. I should
have made it clear I was hoping my title did that, slap wrists for me
:-).
I am enclosing the FDL as requested below. Thanks for your help
Sunil
TITLE "Created from OPTIMZE_RMS for 0 added records"
IDENT " 9-NOV-1992 07:50:58 VAX-11 FDL Editor"
SYSTEM
SOURCE "VAX/VMS"
FILE
CONTIGUOUS no
FILE_MONITORING no
GLOBAL_BUFFER_COUNT 0
NAME "OA$DATA:OF020_CORPHONE.DAT"
ORGANIZATION indexed
OWNER [1,5]
PROTECTION (system:RWED, owner:RWED, group:RWE,
world:RWE)
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL carriage_return
FORMAT fixed
SIZE 138
AREA 0
ALLOCATION 471
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 9
EXTENSION 117
AREA 1
ALLOCATION 9
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 9
EXTENSION 9
AREA 2
ALLOCATION 144
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 3
EXTENSION 39
KEY 0
CHANGES no
DATA_AREA 0
DATA_FILL 75
DATA_KEY_COMPRESSION yes
DATA_RECORD_COMPRESSION yes
DUPLICATES yes
INDEX_AREA 1
INDEX_COMPRESSION yes
INDEX_FILL 75
LEVEL1_INDEX_AREA 1
NAME "SURNAME"
NULL_KEY no
PROLOG 3
SEG0_LENGTH 20
SEG0_POSITION 0
TYPE string
KEY 1
CHANGES no
DATA_AREA 2
DATA_FILL 75
DATA_KEY_COMPRESSION yes
DUPLICATES yes
INDEX_AREA 2
INDEX_COMPRESSION yes
INDEX_FILL 75
LEVEL1_INDEX_AREA 2
NAME "EMP_NO"
NULL_KEY no
SEG0_LENGTH 8
SEG0_POSITION 118
TYPE string
|
| 1729.4 | /PUT_SAVE may be the reason for a sequential search | GIDDAY::SETHI | Man from Downunder | Wed Nov 11 1992 05:50 | 70 |
| Hi,
Here are some thoughts on this subject as to why the entry form is
searching sequentially when the alternate key is entered.
Basically the named data design is at fault because it's using
/put_saves for the indexed fields. The correct method for example
would be to use the named data for the NETWORK form ie
Form: NETWORK
Library: DISK$OFFICE_DISK:[ALLIN1.LIB_BRITISH]MEMRES.FLB;
--------------------------------------------------------------------------------
;;.TYPE;;
ENTRY/MODE=UPDATE/KEY=USER,NODE/HARD=OA$_NETWORK_PROFIL
/PRE='DATE_CONVERT #ADATE,TIMESTAMP,10'
/GET=LAST_UPDATE,#ADATE
/POST="GET TIMESTAMP=OA$DATE_NBS\GET $RECORD=USER"
;;.FILE;;
OA$DATA_SHARE:NETWORK.DAT,OA$LIB_SHARE:NETWORK.FDL
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
||||||||||||||||||||||||||||||||||||||||||||||||||
Ensure that the file specification for the .DAT is exactly the same
as the one specified in the .FDL
;;USER;;
/RSE_RECOG=network.user WITH .user ENS user AND .node ENS node
/AUTO/SHOW=".user ' ' .node"/HARD=OA$_GBL_A1_USER
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Replace the /put_save with the above named data structure for the
primary key
;;NODE;;
/get_save=oa$node/RSE_RECOG=network.node WITH
.user ENS user AND .node ENS node/UNIQUE
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|||||||||||||||||||||||||||||||||||||||||||||
Replace the /put_save with the above named data structure for the
primary key
One thing to note is that when a search is carried out on a keyed field
it may appear that it's being done sequentially. This is caused by the
algorithm that does the searching. Basically it makes use of a number
of methods of searching such as a binary search followed by a
sequential or other variations.
Now the reason why I am leaning towards this pet theory is because I
remember reading something along those lines in a Stars article, I just
cannot find it anymore. I would be grateful for any input regarding
this and please do let me know if I am wrong or better still point me
to the article.
Thanks for your input in advance
Sunil
PS - You may not hear from me for a few days I am going to a customer
site to help them with their 3.0 upgrade.
|
| 1729.5 | | SCOTTC::MARSHALL | | Wed Nov 11 1992 09:17 | 24 |
| Hi,
To add to .4
I don't think the presence of /PUT_SAVE is a problem. However, as Sunil points
out, it may be useful to add /RSE_RECOG to force ALL-IN-1 to search the file
in a specific way. I've written other notes on RSE_RECOG elsewhere in this
conference so won't repeat all the details here.
ALL-IN-1 doesn't do binary searches on files, it just does RMS keyed lookups.
Now, one could say that the RMS file index structure is a form of binary search,
but that's irrelevant.
ALL-IN-1's algorithm for keyed lookups is (put simply):
- do get-by-key (with greater-than-or-equal matching) to get the first record
that matches the specified key
- do get-next to get subsequent records until no more match the key.
>> I am going to a customer site to help them with their 3.0 upgrade
Into the shadow of the Valley of Death... :-)
Scott
|
| 1729.6 | another red herring... | OK4ME::CAFE1 | Mike Lampson - [email protected] | Wed Nov 11 1992 14:28 | 6 |
| The presence of a filename in the .FDL is not causing a sequential
search either. The .FDL is only used during the initial file
creation. Once that is done, ALL-IN-1 depends upon the RMS
structure of the ISAM file itself for access to the data.
_Mike
|
| 1729.7 | Might jog soemeone's memory? | IOSG::SHOVE | Dave Shove -- REO-D/3C | Wed Nov 11 1992 16:59 | 3 |
| This isn't the "quotes in field names" one, is it?
Dave.
|
| 1729.8 | Alternate key never does an indexed search | GIDDAY::SETHI | Man from Downunder | Tue Nov 17 1992 04:51 | 26 |
| Hi All,
I have tried to get this alternate key working for the last few days
with no success. Looking at the Stars articles I have had no success
they seem to as vague as the documentation.
I have tried very thing I can think of to try to get the alternate key
called EMP_NO to search using the index. It always searchs in
sequentially. I read the documentation Applications Programmers guide
chapter 3 and 7 without success.
I have saved the FDL and the form's TEXT IMAGE in a file called
RIPPER::USER$TSC:[SETHI]WMC.INFO;1. Could someone give me a working
example of an alternate key search that actually search's
non-sequentially ! Better still if one could be posted here it would
be most useful to others I am sure.
The primary key always searchs no-sequentially no matter what the named
data is like.
Thanks for your help
Sunil "I like to put my foot in it" Sethi
PS - The Stars articles mention that the field names in the FDL and on
the FORM must match. Maybe they need to be re-examined.
|
| 1729.9 | A pointer to solve the problem would help | GIDDAY::SETHI | Man from Downunder | Wed Nov 18 1992 00:33 | 15 |
| Hi,
Can someone please confirm that an alternate keys is always searched
sequentially.
Even if I do a <get pm_ph_entry.emp_no["9898989"] I get an error
message %OA-W-INVGET, Symbol "pm_ph_entry.emp_no["9898989"]" not found.
However if I enter <get pm_ph_entry.emp_no["FRED"] the file is searched
using the primary index and get's the EMP_NO by directly accessing the
said record.
Can anyone give me a pointer to help me get to the bottom of this
problem. Thanks
Sunil
|
| 1729.10 | | SCOTTC::MARSHALL | | Wed Nov 18 1992 11:29 | 20 |
| Sunil,
>> please confirm that an alternate keys is always searched sequentially
Not true. You can do keyed lookups using alternate keys. You just need to
make sure that ALL-IN-1 realises this! :-)
>> Even if I do a <get pm_ph_entry.emp_no["9898989"] I get an error
>> message %OA-W-INVGET, Symbol "pm_ph_entry.emp_no["9898989"]" not found.
Maybe it's a typo in your note, but how about:
<get pm_ph_entry:ALTERNATE-KOR.emp_no["9898989"]
IE you need to tell ALL-IN-1 to use the alternate key.
>> Can anyone give me a pointer to help me get to the bottom of this problem
How about the APR guide, chapter on data sets and/or entry forms?
Scott
|
| 1729.11 | | GIDDAY::SETHI | Man from Downunder | Wed Nov 18 1992 23:57 | 28 |
| Hi Scott,
>Maybe it's a typo in your note, but how about:
> <get pm_ph_entry:ALTERNATE-KOR.emp_no["9898989"]
>IE you need to tell ALL-IN-1 to use the alternate key.
Do you really mean <get pm_ph_entry:ALTERNATE-KOR.emp_no["9898989"]
^^^^^^^^^^^^^
|||||||||||||
Because it does not work I still get the same error message.
>How about the APR guide, chapter on data sets and/or entry forms?
Life could not be made any harder some good examples are in order. I
have gone through all of this previously and Stars nothing works.
The customer feels it's a Bug and has asked for this call to be CLD'd.
I just have had no choice but to do just that and further the customer
does not think too highly of the documentation. Sorry I have had to
add this last bit here but that's they way things are.
Unfortunely I just do not have the time at the CSC to explore any more
as my call queue keeps growing. There are only two of us here at best
this week taking call and next week I will be alone for 3 days or more.
ALL-IN-1 upgrades are well and truely on there way at many sites.
Sunil
|
| 1729.12 | Read my lips :-) | SCOTTC::MARSHALL | | Thu Nov 19 1992 11:13 | 100 |
| This reply is going to sound a bit irritated, for which I make no apology, but
point out that my irritation isn't aimed at anyone in particular. Several
replies have stated that keyed lookups do work with alternate keys of reference.
As the customer is so convinced that they don't, I have taken time out of my
own very busy schedule to investigate this. As it turns out, it is very easy
to show that alternate keys do work in the way that has been described by
myself and others.
I created an FDL file, show below (I'm not an FDL expert; I simply copied an
existing ALL-IN-1 FDL file (prize for anyone who can guess which one! :-) and
added another key. The customer should be competent enough to do this, if they
want to customise ALL-IN-1).
FILE
NAME "disk:[dir]MYFILE.DAT"
ORGANIZATION indexed
RECORD
FORMAT fixed
SIZE 42
AREA 0
ALLOCATION 9
BUCKET_SIZE 2
EXTENSION 0
KEY 0
CHANGES no
DATA_AREA 0
DUPLICATES no
INDEX_AREA 0
NAME PRIMARY
SEG0_LENGTH 12
SEG0_POSITION 0
TYPE string
KEY 1
CHANGES no
DATA_AREA 0
DUPLICATES no
INDEX_AREA 0
NAME ALTERNATE
SEG0_LENGTH 12
SEG0_POSITION 12
TYPE string
I then used $CREATE/FDL to create a data file from this FDL.
I then created an entry form (using FD) called MYFILE which mapped the file.
The form has three fields,
called PRIMARY (length 12), ALTERNATE (length 12) and OTHER (length 18), in
that order. The named data for the form (which was constructed using basic
ALL-IN-1 knowledge, readily available in the APR Vol 1 (I checked!), which
again the customer should be able to work out) is:
;;.TYPE;;
ENTRY /MODE=UPDATE
/HARD="My Entry Form"
/KEY=PRIMARY,ALTERNATE
;;.FILE;;
USER1:[MARSHALL]MYFILE.DAT,USER1:[MARSHALL]MYFILE.FDL
;;PRIMARY;;
/HARD="Primary"
;;ALTERNATE;;
/HARD="Alternate"
/RECOG=MYFILE:ALTERNATE
;;OTHER;;
/HARD="Other"
The /HARD qualifiers aren't essential, I just put them in as "place markers".
Now, when I go onto this form, TAB to ALTERNATE field, type in a value and hit
FIND, ALL-IN-1 does a keyed lookup on the file, using ALTERNATe as the KOR.
Note that you need the /RECOG to force a keyed lookup. Note also that having
done a keyed lookup, ALL-IN-1 does GET_NEXT operations to find any more matching
keys. This is standard and the way it works with primary keys
and any other RSE.
If on the other hand I try to get a record using MYFILE:ALTERNATE.OTHER["xx"]
where "xx" is a valid value for the ALTERNATE field in some record, then it
correctly does a GET_BY_KEY using ALTERNATE as the KOR.
So I am curious to know what exactly the customer's CLD is for? It seems to
me that what they really need to do is invest in some ALL-IN-1 training and
consultancy before screaming that things are broken.
Now, back to my real job...
Scott
|
| 1729.13 | | SIOG::T_REDMOND | Thoughts of an Idle Mind | Thu Nov 19 1992 15:12 | 8 |
| I agree with Scott ... alternate keys do work as long as you create the
FDLs correctly, and use the keys correctly in DSRs and named data. CM
is full of good examples of how to use alternate keys -- for example,
the NUMBER from CM$SITELOG records is used as an alternate KOR into
CM$ETYPES to discover what element processing functions should be
called at every step of an element's lifecycle.
Tony
|
| 1729.14 | How to add an alternate key to an existing data file | SANFAN::LESLIE_DA | Greetings & Solutions | Thu Nov 19 1992 18:48 | 20 |
| RE: .12
Sunil, you do not have to re-create the data file from scratch if all
you want to do is add an alternate key. The following steps are not
entirely cookbook, but they might help if you're customizing an
existing application/data file.
You can add an alternate key to an existing file using steps below:
1. Create a FDL file for your data file using the following DCL:
$ analyze /rms /fdl ddd.dat /outp=ddd.fdl
2. Edit the FDL file and add the alternate key information
according to .12 (name your alternate key the same as the field
name it corresponds to (doing otherwise is very sloppy and hard to
maintain)
3. Make sure the data file is not opened by anyone and create a new
version of it using the following DCL:
$ convert ddd.dat /fdl=ddd.fdl ddd.dat;0
HTH,
Dan
|
| 1729.15 | The bottom line is the customer is always right :-) | GIDDAY::SETHI | Man from Downunder | Thu Nov 19 1992 22:44 | 38 |
| G'day Scott,
To be quite honest I was taken back because when I arrived in the
morning the customer had escalated the call. The customer is in
Western Australia they are 3 ours behind the East Coast. I had
referred the customer to the Manual and made a suggesstion that they
use /RSE_REGOG or /RECOG and gave examples of some forms in ALL-IN-1.
Now the bottom line argument from the customers point of view is that
the examples and the manual is not very clear. This is not pointing a
finger at anyone but telling it as it is. Our customers know that all
computer related business has it's back to the wall and they are doing
all they can to get extra milage. This is a buyers market in short.
Point to note that I had asked some of the ALL-IN-1 gurus here if they
had used alternate keys. The general view was that they don't work and
do a sequential search. Now this leads to the question of
documentation or lack of and examples again it's not your problem or
engineerings. We need to address this issue and that of education in
future, the "We" refers to DEC.
I hope that you do not feel irritated any longer or at least feel less
irritated. The bottom line is the customer is always right even though
we know they are not. My approach is if it makes them happy and they
think they are entitled to complain and take there frustrations out on
us so be it. I for my part feel it's all part of the job makes life
interesting :-). Life at the CSC is at the sharp end of the knife and
it's fun at times.
Thanks for your help, patients and keep on :-) it's good to see that
mate all these miles away.
Regards
Sunil
PS I have entered a note in the ALL-IN-1 Documetation conference
regarding the documentation issue.
|
| 1729.16 | Problem solved | GIDDAY::SETHI | Man from Downunder | Fri Nov 20 1992 04:29 | 24 |
| Hi All,
The problem has been solved. To summarise this is what I asked the
customer to do.
1. Edit the FDL and remove the quotes around the Name of the key.
2. Do a convert/fdl on the data file.
3. On the emp_no named data enter /recog=pm_ph_entry:emp_no, this is
the alternate field.
4. Test with trace on.
The form CM$SITELOG is a good reference if anyone has problems with
alternate keys.
Thanks everyone for your input and I hope this summary helps
Sunil
PS - The person who was looking after the call has gone on holiday and
his stand in was an ex-DECie from Germany Brigit Yandel. So there
is life after DEC :-).
|
| 1729.17 | In defence of documentation | SIOG::T_REDMOND | Thoughts of an Idle Mind | Fri Nov 20 1992 11:23 | 13 |
| Re. documentation.
I hesitate to add this commercial, but there is a section on alternate
keys in Technical Odyssey.
The documentation can't cover everything -- ALL-IN-1 is too big a
product and too customizable a product to do everything in a set of
books. New things are, after all, discovered every day. And some of
them end up in books...
;-)
Tony
|