Gregg L. DesElms wrote at 2012-12-30 20:40:36
The link to the Wikipedia "Professional File System" article, and the other information posted about it in the answer, is, I'm sorry, completely incorrect... or, more accurately, completely inapplicable to that about which the questioner was actually asking. I've been in IT for nearly 40 years, and was a desktop computing pioneer from the earliest days of DOS (in fact, CP/M, even before that; and Apple II and early Mac OS's, too). I actually helped to beta test the specific product about which the questioner is actually asking; and I installed it, professionally (no pun intended), in, seriously, over a hundred companies and non-profit organizations back in those days. I really, then, know what I'm talking about, here; and, in fact, what caused me to stumble onto this answer was my Googling as I was updating this Wikipedia article:http://en.wikipedia.org/wiki/Pfs:Write
pfs:Professional File (later renamed just "Professional File," without the "pfs:") was a desktop computer database product for DOS made by Software Publishing Corporation (SPC). It was part of trio of separately-purchased products that included "Professional Write" (a word processor) and "Professional Plan" (a spreadsheet). When all three were installed on the same computer, they interacted and combined into a sort of integrated office suite. When a separately-purchased networking pack was added, the trio could be used on a local area network (LAN) using such as Novell's Netware, Banayan Vines, and others; and could utilize, when on a LAN, file locking (but, sadly, not record locking) via NetBIOS.
Professional File was a flat-file, non-relational database; however, it did have the ability to do lookups from other database files, and so was kinda' sorta' almost relational... I used to call it "pseudo-relational".
New database files were created from completely blank screens onto which any field names could be added anywhere on said screens, with a colon at the end of each field name. Once all the fields were created and laid-out on the screen the way one wanted them, then the database file could be saved and immediately used for data entry, with one moving forward/backward from field to field with the [Tab]/[Shift-Tab] key/keystroke-combination; and then pressing the [F10] key to save the record. These now-unusual tab/shift-tab/F10 keystrokes, believe it or not, could keep-up with even 12,000-keystroke-per-hour professional, heads-down, almost-sweat-shop-like data entry people. It was something to see.
Data could then be retrieved by going into a lookup screen (which looked so similar to the entry screen that it was initially a little confusing to new users) and specifying, in whatever fields one wanted, the precise information, or range of information, that one sought. Results could be primarily sorted on one field, and optionally secondarily sub-sorted on others; and then the results displayed a record at a time, using the [F10] key to move from record on the same (again, kinda' confusing to new users) data entry- and data-selection/sorting-looking screen, or in on-screen or printed-on-paper reports.
To enhance functionality, several (I think up to eight, if memory serves) fields could be indexed; and once the field layout was established, then each field could have a field type specified for it; and each field could also be formatted so that, for example, only numbers could be keyed-into numeric fields, or dates into date fields, etc. Fairly sophisticated -- even formulaic -- rules for what could and couldn't be typed into even unformatted (but formatted, too) fields could also be created; and each field could also be programmed or scripted, using syntax very similar to how one types formulas into a spreadsheet cell, so that as something is keyed-in to one field, calculated and/or looked-up results could automaticaly be made to appear in subsequent fields. One could even make it so that records could have unique IDs, with no duplications.
Batch changes could be made, as well, so that entire groups of fairly-easily-specified records or ranges of records could be changed, reformatted, or even deleted in a single process; and there was a fairly easy import and export capability from/to common (of the day) spreadsheet, database and delimited ASCII (even CSV-style) text file formats. That part, though simple (and in its simplicity, ever-so-slightly underpowered), was VERY slick; and allowed Professional File to work with (via providing data to, and/or receiving data from, in batches) all manner of other popular word processing, database and spreasheet tools of the day... even both early and current Windows-based ones, in fact.
Database app developers liked that a database file (or set of files, with the additional files beyond the main file used strictly for lookups) could be created, formatted, rules created for it, and then fields programmed/scripted; and then an interface -- with menus and even custom help screens -- could be created around the database files; and then all of it saved to an .EXE file which could then be distributed as a custom DOS database application (though not standalone: an underlying and legally-purchased/licensed copy of Professional File needed to be installed with it, though the developer usually didn't tell the end-user that it was there, nor put access to it on the computer's main menu, if it had one).
Professional File was, for its day, an extraordinarily powerful, yet quite surprisingly easy-to-use (so easy, in fact, that it belied the underlying potency of the) software package which has never, seriously, been replicated by any other product that's quite like it in the Windows environment... to my chagrin. I really miss it. And so, apparently (and understandably), does the questioner... it was that good!
Though I can develop fully-functional relational database apps using all manner of other Windows-based tools, today, the truth is that if the client is willing to work in a DOS box, and just needs a really simple, straightforward, super-easy-to-use database app, I can develop a fairly sophisticated one in old Professional File version 2 or higher in a literally fraction of the time that I could so do in almost anything else. The downside, though, is that it's all just so antiquated by today's standards; and -- and this is really the killer -- some fairly sophisticated coding (which I figured out) in all three of the field formatting, rules and scripting/programming areas, fields (also involving, in order to do it truly correctly, a lookup table), needs to be created in any custom app which uses dates in order to make the resulting app not susceptible to Y2K problems... hence probably the biggest reason that no one even bothers with Professional File anymore (in addition to, of course, that it's old DOS, while everything, today, is Windows).
That's a pity, though, because old Professional Files was a real honey... unique in its potency/ease-of-use ratio. Again, I miss it. But, as with most beloved, but now-discontinued old apps, one learns to move on. [grin]
All that said, Alpha Software's now-old "Alpha IV" DOS-based rapid application (RAD) database development software was a logical upgraded alternative; and was what most old Professonal File developers (and even end users) moved to once SPC stopped supporting it, and then went out of business. Your questioner would likely find Alpha IV to be a decent alternative if she insists on it being DOS-based; and Alpha IV was still supported (and may still be, if one digs sufficiently deeply on its maker's website) by Alpha Software until not all that long ago. The Windows-based "Alpha V," though, is that company's premier current product... though it's sure expensive. I no longer use it much, but, still, as database RADs of its type go, it has few -- actually, no -- rivals, to speak of. It's quite good.
Hope that helps!
Gregg L. DesElms
Napa, California USA
gregg at greggdeselms dot com