The IPSA/STSC file system, also know as BSS (Backing Store (sub)System) ran as an independent process. It so happened that it was only used via the APL interpreter. But were it available to the world at large other programs could have utilized it given the API and the code to access it. IFRC it was layered on top of ISAM or maybe VSAM (I don't exactly remember)
Without having examined your keyed file system, and on no way making a value judgement, I infer from your comments in reply to my previous post that it is dependant on APL. Am I correct? Peter On 2014-07-10, at 6:07 PM, Blake McBride <blake1...@gmail.com> wrote: > On Thu, Jul 10, 2014 at 4:49 PM, Peter Teeson <peter.tee...@icloud.com> wrote: > > On 2014-07-10, at 5:22 PM, Blake McBride <blake1...@gmail.com> wrote: >> What I've been trying to convey (and clearly have failed on every attempt so >> far) is that an APL component file system must be file-centric. Every APL >> component file system that I've worked with or have read about has created a >> file to contain its APL data components. >> >> Conceptually, yes. Actually, what goes on under the hood is implementation >> specific. In our present case, each component file would equate to an SQL >> table - not an SQL database. This is very important. So, if your >> applications uses 15 component files, that would be represented as 15 SQL >> tables in one SQL database. > > In my experience with the IPSA/STSC file system a component file could store > different data types in each component. > In my experience with various SQLs an SQL table only stores records whose > fields are consistent for each record. > Therefore I do not agree that component file maps to an SQL table. > > Peter > > > The way I implemented the keyed file system, which supports arbitrary nested > arrays of varying size and types in each record, is as follows: > > Each table is defined to have two columns (for data - not including the key). > One is a varchar, the other is a text. I use GNU APL's 14 ⎕CR and ¯14 ⎕CR > to convert between arbitrary nested APL arrays and string vectors. If the > string vector is short I use the varchar field. If it is long, I use the > text field. > > So, SQL only sees varying length strings. APL sees arbitrary APL nested (or > not nested) arrays. > > --blake > > >
