| Re: .1
>
> CAB$:DOCUMENT = perform a BIND using DOCUMENT as an alternate key of
> reference. Presumably DOCUMENT is defined as an alternate key within
> the CAB$ data set, which of course is a special data set providing
> virtual mapping over a set of physical files.
According to the documentation, DOCUMENT is the primary key comprised of FOLDER
and FIXER (36 characters).
My question is, why does the code tack on the ":DOCUMENT" only when the folder
being searched starts with "[" (a shared folder); what advantage is gained.
Thanks,
Cb.
|
| Chaim,
I'd prefer it if when posting STARS articles you removed names and
phone numbers - it causes no end of grief trust me.
Here's your original note with that removed
Regards,
Andrew.D.Wicks
<<< IOSG::LIB0:[NOTES$LIBRARY]ALL-IN-1.NOTE;2 >>>
-< ALL-IN-1 (tm) Support Conference >-
================================================================================
Note 1052.3 CAB$ vs. CAB$:DOCUMENT ...??? 3 of 3
TAV02::CHAIM "Semper ubi Sub ubi ....." 142 lines 15-JUL-1992 14:59
-< Found STARS article ... >-
--------------------------------------------------------------------------------
Found the following in STARS after extensive searching:
Index of Shared Folder in CAB$ Looses Context After First Read of Document
PRODUCT: ALL-IN-1 V2.3, V2.4
SOURCE: Customer Support Center/Atlanta USA
PROBLEM:
Index forms do not update correctly when shared folders are
referenced in the CAB$ dataset.
For a fixed display index form the .type directive may look like:
.type index cab$ with .folder = "[foo]"
or the index form may contain a BIND statement which looks like:
BIND *A to CAB$ WITH .FOLDER == "[FOO]"
The index form would appear to display the correct titles, however
when the user reads a document from this list, the user would actually
be reading a document from their own file cabinet.
ANALYSIS:
The OA$SCL_INIT command appears to be changing the context of the
file cabinet which is accessed.
\The following are the results of testing on the form:
\ <OA$SCL_EXIT\BIND_BREAK *MOD_SEL
\ <get #f="[folder]doc"
\ <bind *MOD_SEL to cab$ with .folder == #f
\ <for *MOD_SEL do get .%key
\
\At that point the keys were correct and displayed [folder]doc and
\the document numbers. We then did:
\
\ <OA$SCL_INIT,,,*MOD_SEL
\ <FOR *MOD_SEL DO GET .%KEY
\
\At that point, the keys were composed of folders and docnums from the
\user's own file cabinet. We then looked at the named data in WP$INDEX
\and noticed that that form specifically checked to see if #SEARCH_FOLDER
\began with a "[" (indicating it was a shared folder). If so, then it did
\a BIND against CAB$:DOCUMENT and if not, it did a BIND against CAB$.
\We did the testing again, this time binding against CAB$:DOCUMENT, and sure
\enough, this time even after the OA$SCL_INIT, the keys were correct, i.e.,
\were composed of the shared folder and document numbers.
\
\CAUSE:
\** INTERNAL USE ONLY ****
\Part 1
\ In the DSAB mechanism the last key of reference that is used is
\ kept. Then each time you reopen the DSAB we check the key of
\ reference and if it is the same we don't do any resetting. If a new
\ key is detected then it will tell RMS to reset the key. If you don't
\ supply a key of reference then it will save the key as the primary key.
\ What it actually saves is the NAME of the key of reference. So if
\ you say:
\
\ BIND *Z TO CAB$
\ or
\ BIND *C TO CAB$:DOCUMENT
\
\ In both cases the current key of reference is stored as DOCUMENT.
\
\Part 2
\
\ The '[folder]' references are done inside the GET_BY_KEY code. It
\ checks to see if the key you are getting is in your cabinet or another
\ cabinet. If its in your cabinet it sets the CAB$ DSAB to really
\ point to DOCDB. If you specified a shared folder it sets CAB$ DSAB
\ to really point to DOCDBSF.
\
\Part 3
\
\ When you do a BIND it does not do anything other than save what the
\ BIND statement was (in a parsed form). It's when you access it the
\ first time that it accesses the DSAB and obtains the RFAs for each
\ record that matches. The RFA's are stored internally so that it
\ can latter find the records. Thus on the first use of a BIND it
\ will do a GET_BY_KEY followed by GET_NEXT on the real DSAB. On
\ following accesses it will use GET_BY_RFAs to obtain the records.
\
\ After you do a
\
\ BIND *A to CAB$ with .folder = '[xxx]'
\
\ AND you then do the first access -
\
\ 1) It opens the CAB$ DSAB. Thus storing the word DOCUMENT in the
\ saved key of reference location.
\ 2) Does a GET_BY_KEY - WHICH modifies CAB$ to point to the DOCDBSF
\ DSAB.
\ 3) Loads up the RFAs for each record you need.
\
\ On the SECOND and later accesses:
\
\ 1) It opens the CAB$ DSAB. Notes that there is NO key-of-reference
\ defined. So it RESETS the key of reference. This has the side
\ affect of reestablishing DOCDB as the DSAB that is being used!
\
\ 2) Does a GET_BY_RFA against CAB$. Which doesn't have that RFA in
\ the DOCDB dataset - thus it returns nothing!
\
\ When you use CAB$:DOCUMENT instead of CAB$ in the bind, the first use
\ is the same. But on the second use:
\
\ 1) It opens the CAB$ DSAB - finds that the key of reference is
\ STILL DOCUMENT, thus it leaves CAB$ alone , and it thus still
\ points to DOCDBSF
\
\ 2) Does the GET_BY_RFA which since it points to DODDBSF works.
SOLUTION:
When referencing shared folders using the CAB$ DSAB use the
syntax:
CAB$:DOCUMENT
to explicitly specify a key of reference to make sure that
the proper file cabinet data set (i.e., DOCDBSF) is accessed.
NOTE: Depending on the functions and/or symbols used in the
index form, you may wish to include a form qualifier
/PRE='MAIL INITIALIZE' in the named data of the form (as
used in the WP$INDEX).
\\ A1_IOS
\\%QX902 VER_2.3_A1_IOS VER_2.4_A1_IOS APPR
\\OA1
Thanks,
Cb.
|