APL Component Files vs. Native Files vs. Databases

Question

I'm new to APL and am starting to work on an APL code base which uses APL Component Files (e.g. ⎕FSTIE, ⎕FREAD, ⎕FAPPEND) heavily. I have also been asked to research transfering the contents of these component files to an SQL database, the point of which would be to make the data available to other applications.

A few of the file components contain text which at first glance looks as if it would work fine if stored in a native file, but the bulk of the component files mostly contain "irregular" numeric matrices which offhand strike me as something which would eventually be implemented as one DB2 table per component. The largest so far was something like 500 rows x 20 columns. I have not (knowingly) seen any nested arrays yet, though I have only barely scratched the surface. So far, only character text and numeric vectors and matrices.

Would transfering the contents of these component files to Native Files also be a sensible option? Why would one ever use APL Component Files at all?

The APL system in use is Dyalog APL under Windows 7. It has been around for a while, no one is sure for how long.

Answer 1

The advantage of using component files is that you can read/write any APL-Array (as complex and as large as you like) with a single native operation to/from file whereas you may need to write your own dedicated functions if you wanted to do that for a large, complex array in .TXT-Format or .XML. (Fortunately Dyalog's ⎕CSVand ⎕XML will do that for you, but in terms of performance component files will almost certainly win.)

Answer 2

The first file system was developed jointly by I.P.Sharp Associates and STSC, two premier APL timesharing companies, in the late 1960s. The file system and new system features like []FMT, report formatting, was part of an effort to make APL\360 more commercially viable. The IBM offering around that time, APL.SV, featured TSIO as an analogue to Native Files. There were aftermarket file systems for APL.SV as well as for future IBM interpreters like VSAPL and APL2.

Why would one ever use APL Component Files at all?

Back then, if using Sharp or STSC timesharing, it was the only thing available. Also the file system made development very easy. It was arguably the best way to persist APL data when the alternative was to use native files. If your system was originally run on timesharing, or used some of the early STSC (Manugistics) interpreters, it probably used component files from the very beginning. Access to DB2 from APL, first in the form of AP127 for mainframe APL2 and Sharp APL, came somewhat later, around the mid 1980s.

Naturally, component file systems between different vendors, like workspaces, were incompatible.

Would transfering the contents of these component files to Native Files also be a sensible option?

It depends on the contents. It sounds as if there might be a home-grown database in those numeric components. This opens up the much larger question of data migration.