> From: Ron Hutchings > I came to the Pick world by way of Prime Information through > Universe with the Prime Flavor. I am currently working on an > implementation of Universe with the Pick flavor. I have come > across examples of Multiple Data Files in the application and > am having a difficult time understanding the purpose of this > file structure. Can anyone share some practical uses for > these file structures?
Other answers stand, but here's some additional history that may explain it (to all but those former primates who are still wondering, "what does 'Multiple Data Files' mean?" ) It has to do with the difference between Pick originally being the file system, and Information using the Primos file system. In PICK, the MD (aka Master Dictionary) had "D"-items (! NOT the same as PI or UV D-items. A different animal!) that were disk addresses pointing to files that served as the dictionary for data file(s). Those dictionaries, besides containing A- and S-items that defined attributes and correlatives, also contained similar D-item(s) that were, in turn, disk addresses to that dictionary's data file(s). Pick typically referred to that at the "data portion". The only way to get to data file(s) was through the dictionary. So the only way to share dictionaries was to define multiple data files within one dictionary. The simplest, default case would be one D-item in the dictionary of the same name as the D-item in the MD. But one could define other data portions, to do things like break out history by year. Back when Clif Oliver (he was but a child) and his cronies at DEVCOM wrote Information, they let PRIMOS do the file system stuff and files were known to Information only via the VOC (almost like the Pick MD) F-pointers,(just like UV & UD today) with the data file in attribute 2, and the dictionary in attribute 3. Since the data & dict files were independent of one another at the OS-level, one could share dictionaries just by mentioning the same Primos file in attribute 3 of multiple F-items. (For that matter, you can define the same file as a dict in one voc record and data in another. Try explaining DICT.DICT to an old Pickie sometime! Actually, explaining DICT.DICT is the beginning of wisdom for old Pickies: once they get that, they understand some architectural fundamentals.) PI did not bother trying to mimic the Pick multi-level-data stuff since they had another way to accomplish the same. That is why old primates are not familiar with these structures in UV. UV is primarily a PI child, so adopted PI's VOC F-pointer idea. The same is true for UD. But true to their "be all things to all men, so that by any means we may win some" philosophy, VMark made a UV PICK flavor and found a way to functionally mimic Pick-style Multi-level files in the VOC, mostly so Pick customers could more easily convert, without changing code that might look something like this: INPUT YEAR FNAME = "PO,":YEAR OPEN FNAME TO FILE ... I don't *think* UD recognizes Pick-style multiple-data-files. That would be in keeping with their philosophy of "do it right". (That's my take on the fundamental difference between Vmark's & UniData's original startup cultures: "all things to all men" vs. "don't be sloppy, do it right.") If you are defining a UV application from scratch, multiple F-pointers &/or distributed files are probably generally preferred to the multi-level pick approach, but maybe that's just the old primate bias in me talking. Chuck Stevenson ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
