Hi
The last thread got a bit tangled so please excuse my starting another.
Tony reckons nobody is interested, in which case read no further.

The FSI is scheduled to be a separate server and so has a great deal of new
code, the ACorrelatives being just one part. In order to do an A
Correlative with translate for the FSI one must do a FULL FILE PATH in the
dictionary eg
008 A13(Tfsitest,PRODUCTS,;X;3;3)(MR%3): the account being FSITEST and the
file being Products. Yes it does work, however I leave you to work out how
many different copies of dictionaries one will need - no copying from
account1 to account2 anymore.

Me being of a suspicious nature I suggest that full pathing is something one
must pay a great deal of attention to - all you R83 devotees look out. I
have come up with a first pass at the new OPEN file code required. Please
feel free to offer improvements I promise to use them. Lines 4-6 are
replaced by 7-25. Not much of a problem for me programwise as I use a
standard open routine - may your God Bless You if you have embedded Opens
and Roots.

Consider this also if it is separate will it cost extra?
Peter McMurray

TRY
001 $OPTIONS EXT
002 CRT "THIS LOOKS FOR PRODUCT GROUP 052 AND ABOVE"
003 OPEN '',"PRODUCTS" TO PRODF ELSE STOP
004 ***OPEN '','INVOICES'TO INVF ELSE STOP
005 ***JOE =
"A13(TFSITEST,PRODUCTS,;X;3;3)(MR%3):13(TFSITEST,P RODUCTS,;X;2;2)"

006 ***ROOT 'INVOICES',JOE TO ROOTVAR ELSE CRT "BANG";STOP
007 ACCT = OCONV('A','U50BB')
008 OPEN ACCT:',MD,' TO MDF ELSE CRT "LOST ":ACCT:' MD' STOP
009 READ INVFID FROM MDF,'INVOICES' ELSE CRT "LOST INVOICES FILE";STOP
010 CHK = INVFID<1>[1,1]
011 IF CHK = "D" THEN
012 FILEBASE = ACCT:',INVOICES,INVOICES'
013 END ELSE
014 ACCTBASE = INVFID<2>
015 DATABASE = INVFID<3>
016 IF ACCTBASE = "" THEN
017 FILEBASE = DATABASE
018 END ELSE
019 FILEBASE = ACCTBASE:","ATABASE:','ATABASE
020 END
021 END
022 OPEN FILEBASE TO INVF ELSE CRT "CANNOT OPEN ":FILEBASE;STOP
023 OPEN 'DICT',FILEBASE TO INVFDF ELSE CRT "CANNOT OPEN DICT
":FILEBASE;STOP
024 READV ACORR FROM INVFDF,'GRPDESC',8 ELSE CRT "LOST ROOT GRPDESC",STOP
025 ROOT FILEBASE,ACORR TO ROOTVAR ELSE CRT "LOST INDEX";STOP
026 A = "FRED"
027 WANTIT = '052'
028 KEY('C',ROOTVAR,WANTIT,ITEMID,VC)
029 LOOP
030 WHILE A = "FRED" DO
031 CRT ITEMID,VC,WANTIT
032 READV PRODUCT FROM INVF,ITEMID,13 THEN
033 PRODKEY = PRODUCT<1,VC>
034 CRT PRODKEY
035 END ELSE
036 CRT "NO PROD"
037 END
038 READ PRODUCTINF FROM PRODF,PRODKEY ELSE CRT "NO PROD"
039 CRT PRODUCTINF<2>,PRODUCTINF<3>
040 KEY('N',ROOTVAR,WANTIT,ITEMID,VC) THEN NULL
041 CRT "ENTER X TO EXIT ANY OTHER KEY TO CONTINUE":
042 INPUT JOJO
043 IF JOJO = "X" THEN STOP
044 REPEAT


:

Are you saying that full pathing is *required* for Opens as well as for
Indexes? or just that there might be problems without, and this is just
precautionary?

Chandru
"Peter McMurray" <excalibur21 (AT) bigpond (DOT) com> wrote

Hi Chandru
I am saying that at this point in time it is precautionary for opens.
However Rick Davies has indicated in a presentation that one should always
use full pathing. The FSI is about to become a totally independent process
and this has already crept into the subset of AQL that covers indexing so I
am suspicious that it will start cropping up elsewhere by accident if not by
design. I have asked them to reconsider it as I see it being a real
nuisance in dictionaries although I have no problem with basic as I have a
standard routine.
Personally I feel that there should only be one way of interpreting
dictionary correlatives and that is the way that is documented using
multi-values. Unfortunately we now have at least three, one for the VME
index, one for the FSI index and the AQL method with the latter being the
only one documented.
Peter McMurray

"murthi" <c_xyz_murthi (AT) seeing_xyz_green (DOT) net> wrote

"Excalibur" <excalibur21 (AT) bigpond (DOT) com> wrote

You bet. What a retrograde step! Whether or not you can code around it or
not, it is simply stupid to force full pathing when the essence of Pick apps
is that you can run the program from different accounts. This is no
different from having to say, specify sh as the unix verb on uv but if
you're on NT you have to use dos. Of course, you could copy the verbs to a
new common name, but the initial syntax is also different (sh -c vs dos /c).
What genius system programmers we have.

Chandru Murthi

Peter,
you appear to be tackling several issues. i cannot speak to anomalies
in the FSI (and without elaboration... i simply tend to avoid it!

however, the issue you raised desiring to implicitly bridge the
relationship context between two files that share a common Master
Dictionary is one that i have both fought and played with on/off over
the years -- and it is not excluded to the FSI -- applying equally to
the VME.

the current flavors of pick only allow establishing a file's context
using either an absolute pathing or via chasing through a process'
"current-effective" master dictionary. back in the early eighties i
actually hacked various PICK versions for both the IBM XT and ADD's
Mentor to implement a feature called "Floating Path Locks": instead of
maintaining the master dictionary as a single file, i actually allowed
a dynamically built hierachical list of files to be used, similar to
how the "path" function works in DOS, but with substantially more
advanced features. This proved awesome for Master Dictionary
organization (eg. allowing discrete organization for User-Verbs,
Administration-Verbs, Files, Roles, Applications...using tiny files)
but also for allowing dynamic precedences/rules to be incorporated for
file access and retrievals. what was "powerful" was an automatic
"lock" feature. this would allow an application account to be attached
as a path and would prioritize first searching that same account for
related file accesses, cataloged programs, etc. Under your scenario,
each account's relationships between its INVOICES and PRODUCTS files
would have been preserved and largely transparent. the only tricky
item was that things became interesting when attempting to update the
'master-dictionary' in the traditional manner... (therefore "catalog"
and create-file/delete-file/clear-file were expanded in their
functionality to handle this). anyways... when i eventually became vp
of development for Pick Systems, there were too many other things on
the plate and no real time to explore this -- however,
fastforwarding... i regularly confront situations requiring similar
data-organizational/access methods.

relative to solely the common need you raised in this thread, the ultra
simple solution would be for pick systems to implement an easy
enhancement: a relative pathing in its file-open convention(s): eg. a
translate conversion could contain a dot (".") to indicate the
'current' account that contains the dictionary of either the
file-defining-item containing the index; or the attribute-defining-item
containing the translate. For example, if the translate code:
"T.,PRODUCTS,;x;3;3" existed in an attribute-defining-item in the
dictionary of the INVOICES-file in the WEBSITE1-account, the
WEBSITE1-account should be used to lookup the PRODUCTS-file. Also,
your sample "index" could then be defined by
A13(T.,PRODUCTS,;X;3;3)(MR%3). Therefore, even if you accessed the
INVOICES-file from another account, the relationship with its
associated PRODUCTS-file could be preserved. Further, scenarios
requiring lots of accounts with common
instances of their file/dictionary-meta data without a need to
fixup/maintain by explictly wiring their dictionary items as
workarounds. Peter, the funny thing is, this is a trivial enhancment
to implement... that excluding any QA efforts, with a little front-end
specification effort to capture and define the various required
file-open-logic -- a seasoned programmer at RD could knock this off in
several hours.

although it would be convenient for many applications, this limitation
has impacted me greatest when attempting to implement/mirror advanced
object-oriented architectures within the Pick data model.

at different times, i have used various work-arounds... including the
fact that a Basic program can perform an [EXECUTE "logto
ACCOUNT2":char(254):command] which will preserve the context of the
logged-to account for subsequent commands that are part of the same
EXECUTE. (Note: that using the 'DATA' command no longer works within
the same new-account context -- for some reason i thought it used to.)
This has data-relationship limitations... but sometimes solves common
workarounds; i'm not sure how much of this will apply without full view
of your application.

for example, look at the output from running:
01 execute 'who' ;* original account

02 execute 'logto ACCOUNT2':char(254):'who' ;* 'who' now executed in
context of ACCOUNT2
03 execute 'who' ;* back to original account



-----------
footnote: for more production-strength code you will need to add some
robust 'index'-parsing between your lines 24-25. (eg. the FDI's
correlative is multi-valued and can have multiple indexes and other
codes/conversions present as separate values; your example has an
assumption of one index and no other values.)

good luck.
dave

murthi wrote:
Yoiks! Somebody needs to tell them that they're going the WRONG WAY (and
no Tony, it won't be me). What genius thought this one up?

Luke

Wrong way on an LA freeway at 5:00pm with no steering and no brakes.
The genius has got to be the "save on coding costs" manager - to h*ll with
the customers .
I am soooo glad that we got as far away from RD (moved to Universe) as
possible.
My guess is that "full pathing" would mean another conversion item for those
looking to move away also.
Would this also mean an end to "q" pointers?
Just curious, but sooo relieved that it won't concern us anymore.....
Tom

"Luke Webber" <luke (AT) webber (DOT) com.au> wrote

Hi
Thanks for this it is the sort of significant contribution that I was hoping
for.
I too felt that the solution should be straight forward but lacked the
internals knowledge.
The code snippet that I lobbed in was a quick cut that I ran up to check the
answer. However you need not worry about multivalues they blow up if used
in indices even though that is the only way of creating an A correlative as
per the manual. Yes Tony it is logged as an item at RD.
I have been considering various ways of approaching this given the unsafe
nature of dictionaries as creation devices - any dodo can change them. I am
considering using a proper program to create indices by creating the
appropriate dictionary item, writing it out and then executing CREATE-INDEX.
This way I would have complete control for ROOT as well. I really do think
indices at system level are a good idea they just need to work properly.

Peter McMurray


"dzigray" <google (AT) bridge2 (DOT) com> wrote

Hi Tom
Would you believe that they have just fixed the problem that did not
recognise the full path in a Q pointer.
In fact in the scrap of code that I did you may notice that I allowed for
attribute 2 being blank (bother! I should have done a TRIM to make sure it
was not a space) and pick the full path from attribute 3. I have not yet
worked out what the extra comma is for but it is ignored in NT anyway so
ACCOUNT,FILENAME,DATANAME is ok but Unix versions might need
ACCOUNT,FILENAME,DATANAME, subtle difference isn't it. Of course this might
get more interesting with DOS: etc but I have not tested that yet.
Peter McMurray
"Tom Phillips" <squash (AT) computer (DOT) org> wrote

Peter McMurray wrote:
on the scrap of paper that was lost last century ...