CFOG's PIP, May 1986, Volume 4 No. 7, Whole No. 43, page 1
Editor's Message
PIP: Where we are and where we are going
We're trying to convince advertisers that (a) PIP is now back on schedule as a regular monthly newsletter and (b) they ought to put ads in. As part of the effort in that direction, the Board of Directors has offered to our two regular advertisers, WestWind Computer and Witt Services, a free page advertisement in this issue. Mark Witt has also taken another page to promote his current ad campaign. We've devoted another page to a FOG membership application. The WestWind ad won't appear this issue, but I'm promised by Dave Price that he will have it ready for next issue, with some special new announcements.
My plan is to have PIP "on calendar" by the end of the year. That means that this May issue goes to the printer about the 1st of July, the June issue about the 21st of July, the August issue in mid-August, the September issue about September 10th, the October issue about October 5th, the November issue about the 1st of November, and the December issue about 23rd of November. That means you should start getting PIP about the 1st of the month in December or January.
I hope that we will have enough material in the future to run 12 pages consistently. That means YOU have to write. I need two or three articles a month from the members, so that our newsletter isn't simply a compendium of articles stolen from elsewhere. If that's what it's to be, you'll need a new editor. So, whatever it is you do with your computer, whatever little mystery of life you have recently solved using it, let's hear about it. There's no reason why we should all be constantly reinventing the wheel.
With nearly 300 members, 30 articles a year means each member has to write one every ten years. Don't think that let's you off the hook, you'll write yours five years from now and be "average". The Talmud tells us that while it is not your job to complete the task, i.e., fill up PIP all by yourself, that doesn't mean you don't have to get started on the job. So do it now.
FOG: Where it is and Where it is Going:
FOG is having problems. FOG is the national and international group out in California, originally an Osborne group, but now more of a CP/M and general microcomputer user group, that this little local group is affiliated with. Last year, FOG expanded its offices and services in anticipation of great growth. It didn't materialize and a big loss resulted. As a result, FOG has had to Iay off most of its office staff and curtail services and benefits. The FOG #3 RCPM has been turned off for want of time to maintain it. On the other hand, this should have no effect on the timely publication of the Foghorn, FOG's monthly newsletter.
I'm not concerned with the internal political ramifications of this. Given the state of affairs, I'm quite pleased at having failed in my attempt to get elected to the FOG Board: they have a tough row to hoe. But FOG must be maintained and brought back to good health. It can't be good for us for FOG to die. FOG publishes a substantial newsletter each month and provides a clearing house for information that couldn't readily be maintained by a bunch of local user groups operated solely by volunteers. Sellers of CP/M and Osborne stuff know that the Foghorn is the place to advertise. If there's no more Foghorn, they won't be able to find all the little local user group newsletters, and besides the cost and logistics of advertising in dozens of newsletters would make such a project unmanageable. If you're not a member of FOG, there really is a memoership application in PIP this month, so get out your pen and checkbook and join.
An Osborne Group Disbands
I just received the newsletter of the Capitol Area Microcomputer Society, Albany, NY. CAMS is an umbrella group with several constitutent "SIGs". One of them was an Osborne SIG. I say was because the June newsletter reports that the Osborne group is disbanding.
Where is CFOG and Where is it Going
CFOG used to have over 500 members. It dropped in 1985 to about 400. This year it has fallen to about 275. In June our Board had a meeting devoted to future planning, and the June downtown SIG and regular meeting were devoted to discussion of future planning. Apparently not too many members have an interest in CFOG's future: only about 20 showed up for the Sunday meeting.
Some decision has to be made. Even if the decision is to keep CFOG going as a purely CP/M user group, the decision has to be made. While it's true that we started out as an Osborne user group, we've effectively changed that in recent times so that we're now a more-or-less generic CP/M user group. At the same time, many of our members have or use other computers: our president and sysop of RCPM #2, Bill Kuykendall and our director at large and sysop of RCPM #1, Glen Ostgaard, work all day on MS-DOS computers; Cedric Chernick, who maintains our mailing list, works all day with a Burrougns system that runs MS-DOS as a task; Dave Jacobsohn, who sends out those postcard meeting notices that you get every month, has an AT&T 6300+ at home; Tom Ferguson, our Treasurer, works all day with an IBM PC; Rand Gerald, our Secretary, works all day with a variety of systems from CP/M to mini-computers. I could go on and on.
Yet at the same time I'm using my CP/M systems every day at home and office and have no current plans to change. Indeed, it's my expectation that I'll continue to use essentially the same systems for two to five years more. In fact, I've just ordered a hard disk for the office. There are no doubt others in the group who are very happy with their CP/M systems and have no plans to change them. Like the old car that you drive to the train station, it still does the job and no matter how fancy the new ones may be there is no reason to replace it even if you can afford to.
What does this all mean? Can CFOG continue to be a CP/M user group with no support for people who aren't using CP/M? Not really, for several reasons. First, as Bill Kuykendall points out, we use WordStar, we use SuperCalc and SuperCalc 2, we use dBase II -- and so do MS-DOS users. So when we support WordStar users, SuperCalc users, and dBase II users, we're not supporting CP/M, we're supporting our users.
Second, a lot of us just barely or just rarely use CP/M. Most of us start out the day firing up our computer with a disk that automatically starts up an application, be it WordStar, SuperCalc, dBase II, or some other program that we work with. At the end of our working session we use NewSweep to make backup copies of our work results. Later we use MEX to call the RCPM where we utilize the Metal Message System to read the messages. Where's CP/M? The fact is that we use our applications most of all, and while the run under the CP/M operating system, WordStar, SuperCalc, dBase II, and MEX all have MS-DOS versions!
Third, many of our most active members are among those who use other systems. I named a few above. They are not going to want to belong only to a group that supports only CP/M. They will migrate to other groups if CFOG doesn't keep their interest. We'll lose more members, and may find it hard to maintain the group at all.
Stay tuned. Read the colloquy that's on pages 3-4 and 13. Then get your two cents in by leaving a message on one of our RCPMs or by writing to our President if you don't have a modem.
CFOG's PIP, May 1986, Volume 4 No. 7, Whole No. 43, page 3 + 13
THE FUTURE OF CFOG: A CONVERSATION ON RCPM #2
One of the fine features of our RCPMs is the ability to engage in a conversation that a number of people can participate in over a period of time. Good ideas can and do emerge. The following colloquy occured over one week in June. I posted a message about the future of CFOG for only one purpose: to provoke comments. See here just how effective the project was!
Msg #753
posted 06/21/86 by Benjamin CohenCan I provoke some comments on this:
Should CFOG mainly try to continue to support CP/M users, Osborne users principally, but all types of CP/M users (including CP/M substitutes such as ZCPR1-2-3), and provide to those of its members who have such interests a modicum of support for other interests that they may have. At some time in the future, there may be [will be] no significant interest in CFOG as a CP/M user group, and it could then be merged into some then existing user group with a [then] broader base.
The rationale behind this idea is that CFOG has no logical argument to MS-DOS or other users in the competition for "outside" "new" members to the extent that they have no interest in CP/M. Thus, the argument runs: there's no reason why a new IBM PC or clone purchaser would join CFOG when there are many IBM only user groups available. If we move to support MS-DOS strongly we can still at best only hope to retain some percentage of the present membership that we currently have.
Ergo, the argument runs, why try to do something about attrition? The institutionaI imperative should not be honored. Let CFOG live out its appointed term as a CP/M user group, and when all of its members have moved off in other directions the remainder can merge into another group.
Msg #755
posted 06/21/86 by Bill KuykendallOne of the major points in Ben's argument can be summarized as follows: "Why try to duplicate the efforts of other (IBM based) user groups when they (presumably) are better equipped to support those users?"
I take exception to the basic premise of that argument -- the idea that we have nothing to offer to MS-DOS users. Many, if not most of CFOG's most active and helpful members have, out of necessity, moved on to MS-DOS or UNIX in their businesses. Those who no longer use CP/M are no longer members, but many still use their older machines at home. I am certain that we have more knowlegde of MS-DOS and the software packages in use on these machines than the first members of CFOG had of CP/M. The argument that a 'niche' is needed for CP/M users and that CFOG is that niche, is negated by the 'duplication doctrine'.
There are already groups totally dedicated to CPM/ZCPR. The Z-NODE users are an excellent example -- Rich doesn't even allow messages about MS-DOS on his systems, even though he also owns an IBM-PC. CACHE still has a CPM SIG group also. In fact, the 'niche' that CFOG once provided was a user group for business users who didn't care about operating systems at all, but were interested in how to use the programs that they needed to make their lives easier at work.
There are very few offices left that are locked into the CP/M operating system these days. There are a few users who feel threatened by MS-DOS. MS-DOS took away the commercial viability of CP/M and all but stopped the flow of quality applications programs. Now it threatens to take over their last refuge -- the user group. I don't see it that way, though.
User groups are made up of 3 kinds of users - novices, in-betweens, and gurus. The only difference between a novice and a guru is the number and difficulty levels of the problems (s)he's solved. Traditionally, CFOG's 'gurus' have been business users who were forced to find solutions to their problems. Pure hobbiests have no necessity driving them, and often conquer such obscure problems that their experience is of little use to other users. In my opinion, the choice is clear: We either support business users or we all lose as the quality of users drops off.
Msg #756
posted 06/21/86 by Bill KuykendallAs President of CFOG, and Sysop of one of our RCP/M's I have a duty to maintain a certain level of neutrality in discussions of this kind. As such, I am open to any and all opinions on this subject. The Board of Directors is committed to following the course of action dictated by the users. For purposes of discussion, I open this topic up, not only to members, but to all who might consider membership in a user group, be it CFOG or some other group.
Changing hats, I am also a user, and an ordinary member of CFOG. As such, I do have strong feelings on this matter. I currently use CP/M for only one task -- operating this RCP/M. I use both MS-DOS and UNIX at work, and would like to be a member of a user group that supports my interests. In 1987 I WILL be a member of such a group. I hope that each of you will be just as candid about where you stand. We have the talent and the assets to be an outstanding group if we choose to be.
Membership numbers aren't everything, either. What's important is a strong comraderie, and a willingness to help one anotner. Whether that can best be accomplished by sticking to one operating system or by expanding to include other users I can't say. We'll have to decide that together.
Msg #757
posted 06/21/86 by John MundtI do not see the business/hobbyist division as being a dicnotomy that cannot and is not bridged often. The one is often the other. And, as the number of CP/M systems decline, and as users move on to UNIX or MP/M, there will be less and less usage of this board. If it is to stay viable, as many users as possible sending in their $20 [CFOG dues] is mandatory. To cut one group off in favor of another is self-defeating.
The idea of SIGS here was a step in the right direction, although there seems to be little interest in them. One of the real problems as I see it is that there is nothing new coming along. People aren't writing for the CP/M environment any more.
I will go back to an idea that I had earlier, that this board try to become the "WordStar", or "SuperCalc", or dBase board of the city. There are still enough users of these programs to justify a board that will cater to those particular needs, and I'll bet that most ozzies are being used for the above programs.
Msg #759
posted 06/21/86 by Benjamin CohenA couple of minor points:
A. Rich Jacobsen doesn't own an IBM PC or clone -- he uses one at his office where it is owned by the firm.
B. There is a good deal of activity in software being written for CP/M. It's nowhere near as hot as the MS-DOS area, of course, but it's not fair to say nothing is coming out. See my message about VDE version 2.1, for example.
And a major point:
The proposition that I set out was designed to provoke comment and does not necessarily represent my current or final position on the subject. I am open to all ideas in any event.
One point that I should make clear -- the position positited is not that CFOG should not deal with members' MS-DOS needs, nor is it that CFOG would be a "clone" of MS-DOS user groups, but that in competing with MS-DOS user groups we do not start on level ground vis-a-vis the non-CP/M user. What do we have to offer the guy who has never had a computer and just got a Compaq, IBM PC, etc., vs. what a "plain vanilla" MS-DOS user group? There is no doubt that we do have something to offer the CP/M user who is moving to MS-DOS at the office or whatever -- or to UNIX, or whatever.
Msg #763
posted 06/22/86 by Bill KuykendallWhat some of us have to offer to beginning MS-DOS users is precisely what we have to offer to CP/M users. I would venture to say that I have more to offer to an IBM-PC user than I have to offer to a CP/M user at this point. That doesn't make me incompetent in CP/M -- just bilingual.
I work in the same office with Glen Ostgaard, our other Sysop, and I can speak for him also. He uses MS-DOS exclusively at work. If I was new to MS-DOS, I'd be glad to have him around to ask questions of. Still, that doesn't seem to have hurt his knowledge of CP/M a bit.
Since a User Group is no more or less than the sum of it's users, I'd say it would be impossible to judge whether we stand on higher or lower ground with respect to other "IBM only" groups. You would have to judge each member seperately on his own qualifications and then add them all up. In any case, you might bei surprised to find that some of the opposition's best talent are old CFOG players who got pushed aside by our unwillingness to continue to support business computer users when the business world changed brands.
The Osborne computer is a great machine even by today's standards. And for the record, I share the resentment that a lot of users have toward IBM for its ability to take over the market based on corporate size alone. A lot of little guys with great ideas have gotten lost in the shuffle who might have given us better machines. But let's be honest here -- it's precisely BECAUSE of the Adam Osbornes out there who are technical geniuses but egotistical business idiots; who have crashed businesses leaving their customers stranded without support that the public turned to IBM and said, "I don't care if you're the best. I know you're gonna BE here".
For better or for worse, that's the real world, and we, as a user group, either have to accept it and move with it, or fade into the sunset where we belong. I will use my Osborne until it finally dies and I'll probably resurrect it as long as Mark Witt has parts. But I can't afford to quit my job because they won't buy Osbornes for me to use. Besides, sometimes it's NICE to use a more sophisticated machine! Hey guys, am I all alone out here?
Msg #784
posted 06/25/86 by Jim KirschenmannLike others, I am using MS-DOS at work. I continue to use my Osborne and find it more comfortable to use when dealing with the standard Business Applications; i.e. dBASE, WordStar and SuperCalc. With conversion programs readily available, I have found that I do a lot of my "homework" on the Osborne 1 and then convert the data files for use at the office under MS-DOS.
From the perspective of a professional "observer" of the CP/M vs MS-DOS trends, there will remain a large group of CP/M users in the business community IF we know where to look for them. Zenith Data Systems (my employer) is still finding a thriving business in the 'Dual-Processor' (8085/8086) market, even though they are also going great guns in the PC market.
What people will use is what they feel comfortable with, and Zenith Data Systems is profiting from that basic human trait.
I tend to agree with John Mundt in that the best "draw" for new users of CFOG would be in the library and support of the standard business applications -- those that cross the lines of operating systems. In addition, however, the contribution to better understanding of the operating systems comes only from the support of foIks that we have in this group... as users we can all benefit from the interaction which we have seen in this group. That type of support also crosses the boundaries of operating systems, and I believe, will continue to evolve as the systems themselves evolve.
In short, my response to the question is anotner question -- Why worry about the Operating System at all? What counts is the applications and the interchange of assistance / info on how to better make use of these machines for those applications. MS-DOS has gone through its share of changes and challenges recently and may be losing its hold just as CP/M has. The evolution of personal computing is now moving toward a single machine handling SEVERAL Operating Systems including cp/m, MS-DOS, UNIX and others. Now more than ever, the users' group is an essential forum for the exchange of ideas -- not just operating system tips.
CFOG's PIP, May 1986, Volume 4 No. 7, Whole No. 43, page 5
VDE with Memory-Mapped Video: Here's F-A-S-T!
by Benjamin H. Cohen
I've been using word processing now for about nine years, on Wang and Osborne, Wang's WP, WordStar, NewWord, various versions of VDO and VDE, etc., from floppy disks and in a RAM disk. One of the things I had not tried was setting up memory-mapped video for WordStar on the Executive -- there was something else I wanted to do that seemed to be inconsistent with the installation so I never even tried it. But the other day, along came VDE version 2.1, from the prolific pen (so to speak) of Eric Meyer. It's the culmination of development (at least so far) of the VDE series, a divergent development from Jim Whorton's VDO series, the latter currently at version 2.5B.
A rundown of features of VDE version 2.1 is in order: word wrap, paragraph reformat, block moves, built-in macro capability, search, replace (and by use of the macro capability, global search and replace), etc. While the command structure is a bit simplified and non-WordStar like in many respects, it's easy enough for a WordStar user to get used to quite quickly. Besides, the help screen is there if you need it. VDE means speed. While this version is 8K, larger than previous versions (some of the VDO versions are as small as 4K bytes), it loads, along with a small (1K) text file, in under 8 seconds. That's compared to almost 23 seconds for WordStar, which needs 81K (without MailMerge).
But the really F-A-S-T thing about VDE is how it handles a file. The file must fit in memory -- that's not a big problem -- with an O-1 you can get 41,888 characters into memory, if you use Smartkey and a big fat definition file you can get in 35,480, or if you switch to an Executive you can get in over 51,000 characters. In fact, VDE uses a compression technique that let's you edit even larger files. Moving around in a file is only a matter of having the screen rewritten. From the top of the file, no matter how large, to the bottom, in just a fraction of a second.
I tried out VDE on my Osborne 1, and liked it. But what really turned me on to VDE was the memory-mapped video version which I tried out on my Executive. The screen is rewritten so fast that it's incredible.
I've now copied the block of text above so that the file is 11 pages long. Now I'm going to go to the top of the file and then search for the end. I'll try to time it. Let's put it this way: Hit ESC-T to go to the top -- less than 0.4 seconds. Hit ESC-F (to find a string), enter "end" as the string, and hit the <cr>. Less than 0.9 seconds. Mind you, the file is 23K bytes long! Try that with WordStar, even in your RAM disk!
One of the nice things is that I can write files here at my Executive with VDE's memory mapped video version and then take the disk to my secretary, who has NewWord and a Hewlett Packard LaserJet printer. She doesn't even have to reformat or change anything -- just print! I can put in the dot commands, the embedded print controls, etc., to make the file a NewWord file and NewWord just prints it as a normal file. [Loading a WordStar or NewWord file into VDE and then saving it strips the high bits, by the way, turning it into a straight ASCII file.]
I found another use for VDE that some others may have. I often get files via the RCPM, or create articles by making a log of messages from the RCPM. When you edit such files with WordStar or NewWord, you find a hard carriage return at the end of every line. Reformatting requires gyrations, and is at best tedious. Load the files into VDE version 2.1, hit ^B to reformat, and zip, it's done. Indeed if you simply want to change the format of afile from 65 characters to 80 characters and stick in a ".cw10" command, VDE reformats paragraphs about as fast as you can hit ^B! There are none of the long delays familiar with WordStar or NewWord. On the other hand, once you've written a file with VDEM you cannot reformat it with WordStar or NewWord, so it's not helpful for creating files for PIP since it won't justify the text and I cannot reformat with NewWord or WordStar. [If you see files printed proportionally spaced but with ragged right margins, it probably means they came with hard carriage returns and were reformatted with VDEM.]
The memory-mapped version of VDE is Vdem2l.com, found in Vde2l.lbr along with plain-vanilla Vde2l.com, and a full DOC file to explain both. Happy word processing.
CFOG's PIP, May 1986, Volume 4 No. 7, Whole No. 43, page 6
BDOS Error on B:
by Hanns Trostli
Believe me, I have had my share of the dreaded BDOS Errors. One of my disk drives behaved erratically and suddenly the disk and especially the directory had bugs in them. I tried many ways to overcome that trouble. Maybe my experience will be helpful to similarly worried Osborners.
First: save your files frequently. Using Smartkey II, I have programmed my <.s> or SuperShift s key to ^K^S^Q^P^M -- WordStar for save and resume editing, return to the cursor's last prior position, enter a <cr> to go to the next line. You can also program a special function key to do that. In the case of a small file, say 3 pages, it takes about 20 seconds.
Second: do make backups, always. This is like taking out insurance -- it costs some but it is invaluable in case of a loss.
Well, all this is old stuff to most readers. But what to do in case of real trouble? I have been using DU and DDT to salvage the undamaged files. This takes quite some time. One can also reconstruct many damaged files this way. Having spent many hours doing that I found two ways that help, at least partly.
If BDOS Error happens suddenly while you are working, try taking your disks out, put a disk containing Findbad.com in one of your drives (I have it on my WordStar disk) and the probably damaged disk in the other drive. Run Findbad and note the bad sector number. Then run Dirmap, using your printer. You will then find which file has the offending sector and if you are lucky you will be able to repair it. If it is a "COM" file, which you can't read, and which is probably quite okay on your backup disk, delete it and copy it again to your bad disk from the backup disk. Run Dirmap again and you will see that the location of the file has been changed, avoiding the now isolated [USED].BAD sector.
The other solution I have found uses a program called Fusa.com, which I have submitted for the CFOG library. [It's on -CFOGUTL.017 - bhc] Fusa is a program by my friend Peter Chirivas, based on Wash.com and works exactly like Nswp. But version 2.07 takes up 12k bytes and Fusa is only 8k bytes. The Fusa setup is much more practical than Nswp, because it shows the names of all the files on the disk at one time. Fusa doesn't do a CRC check when copying files to guarantee the accuracy of the copy, but I find this a minor disadvantage against the otherwise great advantages which you will note as you use it. I have Fusa on all my program disks.
The way I use Fusa for salvaging damaged disks is the following: I put Fusa in drive A: and a new formatted disk in drive B:. I enter Fusa B:<cr>. Fusa finds an empty disk and asks: Relog? Before you answer that question, take the disk out of drive A: and put the damaged disk in. Then type A. Now Fusa will try to log on to the A disk and won't succeed: you will see BDOS Error on A: on your screen. Don't despair.
Push the <cr> key 16 (yes, sixteen) times and then you will suddenly see the directory of disk A -- at least what there is still on it. Now tag all the files and then type M to mass copy to B:. Fusa will now transfer whatever possible to disk B:. Sometimes BDOS Error on B: will appear again while the files are being transferred. Push the <cr> until the transfer is completed. Take note of which files have been giving trouble. I have found this to be the most practical and rapid way to save most of my files spending only minutes instead of hours. If need be, I can still check into the damaged disk with DU.
[Pip.com can be used similarly. Put the bad disk in drive B:. Put a good disk with only Pip.com on it in Drive A:. If you have the revised version with [R]eset and [Q]uick repeat options, you can use any disk with Pip.com, change disks after Pip has been made active, and enter R<cr> to reset the disk. Enter Pip a:=b:*.* [WVOR]<cr>. Keep on hitting the <cr> key until you get too tired to keep it up or you get the A> prompt back. In the meantime you may see BDOS Error on B: dozens of times -- just keep leaning on the <cr> key. The files from many a disk have been recovered by this technique by many CP/M 2.2 users -- sorry, users of CP/M 3.0, the CP/M 3.0 version of Pip.com it's so sophisticated it knows there's a bad sector and quits! -- bhc]
Of course, I use Fusa for many other things: copying files, having a quick look at them with the V command, the mass delete function Q is extremely quick and troublefree, as is the R(ename) function. I call it up from within WordStar whenever needed.
CFOG's PIP, May 1986, Volume 4 No. 7, Whole No. 43, page 6
BASIC SIG on CFOG #2
Stop by our BASIC sig!
To get there, type SIG/BAS<RETURN> at the command prompt. (To get to the command prompt enter a C or J at the METAL prompt.)
We're trading infomation on all dialects of BASIC and on CREATOR/REPORTOR.
Stop by and say hello!!!
Mike Andrews
SIG/BAS SYSOP
CFOG's PIP, May 1986, Volume 4 No. 7, Whole No. 43, page 7
Mail Merge Tip -- Combining .AV and .DF commands
by Jack Snarr
Every WordStar book shows how to use MailMerge to address envelopes to a list of correspondents. The basic idea is to use the "data file" command (.DF) to specify the data file in which the names and addresses are stored, and the "read variable" command (.RV) to extract the variables. Very simple! But, what if you use multiple mailing lists (data files) from time to time? At least four alternatives exist:
1. Write a separate MailMerge command file for each, specifying the corresponding data file after .DF in each. This will quickly clutter a diskette with many virtually identical files.
2. Maintain one command file, but edit the the ".DF" each time a different group of addresses is desired. This saves disk space at the cost of repeated loading and editing.
3. Incorporate an "ask variable" (.AV) to request key board entry of the desired data file, then transfer that file name to .DF as a keyword, i.e., .DF &datafile&.
This is a step in the right direction, but surprisingly, when the job is run the data file name request is repeated with each step through that data file! Evidently, .DF recycles an entire command sequence with each step, including any .AV commands. Obviously this isn't the solution.
4. The answer is to use the file insert (.FI) command to chain two command files together: one to request the data file name, and the other to sequence the addressing.
(a) The first:
..ENV
.AV "Name of data file",DATAFILE
.FI ENV2
(b) The second:
..ENV2
.OP
.PO 30
.DF &DATAFILE&
.RV Name,Address,CitySTZIP
&Name&
&Address&
&CitySTZIP&
.pa
Once ENV and ENV2 are written, the user needs only to enter M ENV<cr> and when prompted, the name of the data file desired. Only ENV2 will be recycled.
Use the same approach to supply the heading and greeting to a merge letter sent on occasion to different groups of people.
CFOG's PIP, May 1986, Volume 4 No. 7, Whole No. 43, page 10
START YOUR OWN I.R.S.
by Jim Holmes
It's more than just a catchy title. The I.R.S. referred to is an "information retreival system", and you'll find it easy to create and use your own... at least you will after you've bought a superb new program called FREE FILER, from Telion Software. The author, Allan Gomes, was OKOK's [Pasadena, CA] guest speaker at the April 8th General Meeting. Let me tell you what he's got for you.
FREE FILER searches text or data files; those created for it or your existing ones. It locates (and will copy) card file entries, using key words -- much like a relational database program. There are several important differences, however.
Databases ask you to define "fields" (headings under which entries will be listed), naming these for later use in searches, etc. Most "card file" data bases work only on their own data files. They ask you to list the "key words" you will later wish to search on at the time of data entry. This limitation may not seem severe, but consider this example (from Gomes), an entry from a college research project:
"Uranus was a Greek god who was the personification of the heavens, the husband or son of Gaea (Earth) and father of the Titans, Furies, and Cyclopes; he was overthrown by his son Cronus (Saturn)."
You'd certainly select "Mythology" and "Uranus" as "key words" if you had to define them in advance. You might go so far as to list every proper noun, though that's unlikely if your main interest at the time was in Uranus. Be that as it may, what if you later want this information but all you can remember is that it concerns, "...some god who was dethroned by his son."
You'd find it with FREE FILER, and quickIy. You could search for the key words "god" .AND. "son"; FREE FILER would produce the reference... along with only those others which contained BOTH key words! Output may be to the CRT, printer or a disk file.
FREE FILER does more than simple "boolean searches"; you may combine two or more logical operators in a single search. Quoting Gomes, "Searches like these are now possible:
(Computers and MS-DOS) but not (IBM or COMPAQ)
(World War II and Churchill) or (Roosevelt and Yalta)."
FREE FILER avoids the limitations of predetermined headings (by searching the information itself, for the labels you define at search time), and the use of boolean operators allows you to be quite selective in your search criterea. Further, you can sort the output from FREE FILER, in ascending or descending order. This is very useful should you care to alphabetize your output set of cardfile entries; when these entries are to be organized by date, you may prefer to organize them chronologically, either "from the earliest" or "latest entry first". With FREE FILER you have your choice.
FREE FILER can be configured "as you like it". This means it's easy to get it to work with your "old files", not just those created for it. Since it only occupies around 34K, FREE FILER won't crowd you for disk space. It's also very fast; most of the work is done in RAM. A benchmark search of a 55K file took only 20 seconds (at 4mhz., DD 8" drives); it's even faster with a RAMdisk or hard disk drive. Wildcard search parameters [such as B:*.TXT or C:FNAME.*, etc.) are permitted; you can even search [D:*.*] an entire disk at once, if you wish.
As you know, I like to save the best for last. FREE FILER is not only fast and versatile, it's a bargain. Both CP/M and MS-DOS versions are available, and each is only $79.95. Gomes is willing to discuss a discount for Group Purchases, based on the number of units ordered, etc. He can be reached at: Telion Software, P.O. Box 1464, La Mirada, CA 90637-1464; Phone: (213) 547-9673. [If some enterprising CFOG member is interested in getting together a CFOG group purchase, please contact President Bill Kuykendall so that we don't have more than one person doing it. -- bhc]
CFOG's PIP, May 1986, Volume 4 No. 7, Whole No. 43, page 12
A Report on PdbM -- A Data Base Program
by Benjamin H. Cohen
I saw an ad in the October 1985 Foghorn offering a new data base program, the Personalized Data Base Manager or PdbM. The author of the program is the same person who wrote the Desolation game for the Vixen and who uses the company name B.C. Software. The ad promises that PdbM is "simple to understand", offers full screen editing, and is 100% compatible with other formats from dBase II to SuperCalc. With a record limit in excess of 65,000 and over 200 fields per record, PdbM sounded like it might be what I needed. One nice feature promised that you could add a field to a data base with a simple command. In the April 1986 Foghorn a very short report appeared, praising PdbM to the skies. I decided to take B.C. Software up on its 30 day money back guarantee.
PdbM comes on a single double desity disk with a small (5.75 by 7.375 inches), thin (0.125 inch), neatly perfect bound manual nicely printed with a daisy wheel printer. The manual sure looks nice. A little editing an proof-reading would have halped readers, though, even more than the nice appearance. After I figured out that a "filed" was a "field" -- a typographic error repeated throughout the manual -- there wasn't too much difficulty understanding the manual.
It was irritating, however, that the author follows no known rule of capitalization, that typos abound, that there are references to definitions of terms in Section 7-1 that aren't found there, to an ASCII table in Section 14-1 (for the sort order) even though the manual ends on page 13-1 (that it's not just a missing page in my copy is attested to by the table of contents -- it's not listed there, either.) On page 5-3 the author tells how to 'string' the Find Command with other commands: "Type (F) for Find, (D) for Output and (C) for Continue..." He means, I'm sure, "(D) for Delete", but it sure stopped me there for a minute.
When I got the pacakage I was at my office where I have an Osborne Executive on my credenza. I copied the disk for backup, put the master away, stuck the copy in Drive A:, and entered PdbM<cr>. Unfortunately, the Executive froze. Not to worry, the application of BIOS22.COM made a version that would run ond the Executive. (I don't believe the program was tried on an Executive. As additional evidence I note that the manual says that the DELETE key is supported for the Executive -- now you support a key that doesn't exist is beyond me. Perhaps that reference should be to the Vixen.)
At home with my Osborne 1 (tan case, Osborne 80 column and double density upgrades), with the small (192K) Drive C: RAM disk, I loaded PdbM again. Since I use the Dvorak keyboard I utilize SmartKey or XtraKey to reconfigure the keyboard. This is hard on program that are memory hogs, since the Drive C: uses about 1110 bytes for its software and the keyboard reconfiguration programs and their definition files subtract another 2K+ from the TPA (the Transient Program Area, the portion of the nominal 64K RAM that's left to run programs after subtracting the CP/M system overhead and in my case the Drive C: software and SmartKey or XtraKey.) unfortunately, while PdbM will run with the Drive C: software, it won't run in the Drive C: with either SmartKey or XtraKey present.
I've used PC File and DIMS and other programs of that sort. If you run these programs with your data on a floppy disk it takes forever to sort the data. Well, maybe not literally, but a sort that takes about 15 minutes when PC File is run on a floppy system taktes about 2 minutes in my Drive C:. I'm not about sacrifice that speed, so the sheer size of PdbM forces me to return it to B.C. Software. Another factor against PdbM is the need for macros while using any file management program. When I have to update a list to show who has paid current dues, a macro lets me enter the name [or enough of it to distinguish it from other names] and then hit one key to update the entry and initiate the search for the next name. In my RAM disk all of this is very fast.
The size of PdbM isn't all bad. With the program all in one piece you get the ability to move from function to function without delays. Programs that don't use as much TPA often have to have some of their functions in separate "overlays" -- that means each time you use those functions you have to wait for them to load from the disk. WordStar users are quite familiar with this phenomenon. PdbM on the other hand, has no overlays and thus moves from funtion to function quickly.
I tried out PdbM only in a small way, since I knew I wasn't keeping it. I can't really evaluate it fully since I didn't spend a lot of time with it.
Some of the problems with the manual show up in the program, too. One of the options in the main menu allows you to "Preform" (sic) arithmetic functions. Other spelling and grammar mistakes abound in the abundant and otherwise generally quite useful help screens.
You can't give fields long names, with spaces in them -- up to 65 characters.
[What neither the manual nor the help messages nor the plug on the back of the box nor the advertisements tell you is that field name plus field length is limited to 69 characters. If you try to enter a field name plus length that are, combined, greater than that, you'll get a message that the limit is too big -- but it doesn't tell you what the limit is. It's not listed anywhere that I could find it: I determined the number 69 by trial and error.] When you define your data base the field name is followed by a colon and then either a comma and the number of characters allowed or by a series of fixed characters terminated with a carat (¢). If you do the latter, the fixed characters will appear in each record in non-editable form. For example, you could create a field name
Telephone Number:( ) - ¢.
When you got to enter a telephone number the paranthesis and hyphen separators will always be present and PdbM will skip over them as you enter the data.
On line help is a nice feature, too. Error handling seems excellent -- PdbM won't let you enter incorrect commands and generally tells you what your choices are at a particular pint in the program. but there weren't always help screens available, and with the skimpy unindexed documentation I was several times left high and dry.
You can add or delete a field in an existing data base by a direct command. Editing a field name, however, seems impossible.
When you as PdbM to find a record you can enter as many characteristics as you want in a 'mask' -- if you want all records that have Zip code starting with 606, last name starting with G, and telephone number starting with 686, you enter those characteristics as the 'mask' in a dummy record and PdbM will find the matching records. Or you can find records that don't match your posted characteristics. I couldn't figure out, however, to find records with a Zip code greater than 606 -- a standard type of search for data base programs.
PdbM offers arithmetic functions. If your doing something that needs to be numbered or incremented, PdbM will do it.
PdbM offers a feature called overlay. This lets you overlay the data from the previous record in the same field in the current record. It's a great help. Many mailing lists have a lot of people from the same city. Most programs let you enter an apostrophe and hit the <cr> or use some other convention to repeat the required entry in each record without retyping it. The lack of an index or help screen prevented me from figuring out how to get this to work in PdbM. Indeed, in a number of places, hitting the "?" for help resulted only in a grind of a disk drive and a rewrite of the screen, without any help.
PdbM commands are performed only once unless you tell it to continue on the command line. If you tell it you want to insert more records in the file, you have also to tell it you want to continue or it will automatically stop after one addition. Somehow, it seems to me that the default ought to be in the opposite direction, since a single keystroke after the insertion of a record into the file will terminate record insertion.
As I said, this isn't designed to be a complete review or evaluation of PdbM. PdbM may work fine for you if you don't have the TPA problem that I run into. In any event, there's the 30 day money-back guarantee.
CFOG's PIP, May 1986, Volume 4 No. 7, Whole No. 43, page 14
The DOCS Command on RCP/M #2 -- New Stuff From FOG
One feature of our RCPM #2 is the DOCS command. At the "A>" prompt, enter DOCS<cr>. Here's what you'll see <blank lines are omitted to conserve space, and lines of more than 54 characters have been wrapped>:
[Entering the selection "B" will get you this:]DOCS (from HELP)
** DOCs Available **
A. Directory listings for public sections of this
RCP/M
B. Directory of FOG private sections on this system
C. Directory listing of CFOG RCP/M #1 (312) 344-2505
D. Help using DOCS
Type ^C=CP/M or Enter Selection
Loading DOCS File FOG.DOC
** DOCs Available **
A. Fog Catalogs | FOG private area
B. CP/M Section | Last update:
C. MS-DOS Section | 06/03/86
Level 1/ Type ^C=CP/M ^=Level .=Root or Enter
Selection
[Entering the selection "B" here will get you the CP/M files listings in the FOG section of the RCPM. This lists only the most recent FOG releases. Here's part of what it said <as of June 6, 1986> <some disks were omitted because of garbled transmissions and a desire to list some other things in PIP.]
Loading DOCS File FOGCPM.
Drive D1: Files: 18 Used: 2536k Free: 928k
-FOGCPM . 0k CPM#026 .LBR 168k
CPM#031 .LBR 128k CPM#039 .LBR 152k
CPM#016 .LBR 176k CPM#027 .LBR 160k
CPM#032 .LBR 160k CPM#040 .LBR 152k
CPM#023 .LBR 160k CPM#028 .LBR 160k
CPM#033 .LBR 144k SYSIN58 .$$$ 0k
CPM#024 .LBR 168k CPM#029 .LBR 160k
CPM#034 .LBR 168k CPM#025 .LBR 168k
CPM#030 .LBR 152k CPM#038 .LBR 152k
[This is the list of FOG CPM disks currently posted on the RCPM. These files are on Drive D, User Area 1. There are 18 files, 16 of which are FOG CP/M disks, each in a separate LBR file. -FOGCPM is an identifier file, used to designate what section of the system you are in. SYSIN58.$$$ is a temporary file you can ignore. The files take up 2536 kilobytes of space, and 928 k are available <free> for additional files.]
Library directory for D1:CPM#016 .LBR 176k
-FOG/CPM.016 0k //CPM016.DOC 2k
/DEC/85 . 0k DEARC .COM 14k
DEARC .DOC 1k DEARC .PQS 5k
DEARC2 .IQC 5k DEARC3 .IQC 3k
LU300 .DOC 35k LU310 .COM 20k
LU310 .HLP 1k MLOAD .COM 3k
NULU15 .COM 15k NULU15 .NOT 2k
NULU15 .WS 64k NULUTERM.ASM 3k
[This tells you that FOG disk CPM#016 is in Drive D, User Area 1 and contains 176k of files. The first file listed is the disk identifier, -FOG/CPM.016, identifying it as FOG's CPM disk #016. The next file listed is the "DOC" file. Each FOG disk contains a short summary of what's on the disk in a DOCument file. The next file is a date marker, /DEC/85, which tells us that this was released in December 1985. The subsequent listings are the individual files on the disk. On the RCPM they are stored in a LBR file. Use NULU151 from the CFOG New Member Disk to remove the files from the LBR, or download them individually from the RCPM. Enter XM0DEM<cr> for help on how to download individual files from a LBR. If you copy the disks at a meeting you will find there are no LBR files on FOG disks. Note that some of the files on these FOG disks have been in the CFOG library for some time, or later versions are in the CFOG library. Others are not in the CFOG library. Some files have been released with special permission only to FOG and will not appear in the CFOG library.]
Library directory for D1:CPM#023 .LBR 160k
-FOG/CPM.023 0k //CPM023.DOC 2k
/JAN/86 . 0k CPA .BAS 9k
CPA .DOC 1k DEMO .PRT 2k
PERT .DOC 29k PERT .INT 7k
PERT128 .BAS 12k PERT80 .BAS 12k
PERT80 .DOC 2k PERTHELP.INT 7k
PERTHLP0.INT 8k PERTOVR2.INT 9k
PERTOVR5.INT 7k PERTOVR6.INT 8k
PERTOVR7.INT 9k PERTOVR8.INT 1k
PERTSAMP.COM 27k PERTSORT.INT 2k
PERTTEST. 1k PERTWS .DOC 8k
PINSTALL.INT 7k
[This is as good a place as any to repeat: Whenever you see a file called README.1ST, or READ.ME, or READ-ME.1ST, or anything like that, it is intended by the author to be a command -- read it before you do anything else! At the CP/M A> prompt, enter type readme.1st<cr>. Or, load WordStar and print the file.]
Library directory for D1:CPM#024 .LBR 168k
-FOG/CPM.024 0k //CPM024.DOC 2k
/JAN/86 . 0k AFC .COM 12k
AFC .CQ 9k AFC .CQL 7k
AFC .DQC 2k AFC .SYM 1k
AMON .COM 7k AMON .CQ 3k
AMON .CQL 3k AMON .DQC 2k
AMON .SYM 1k AS .COM 10k
AS .CQ 10k AS .CQL 7k
AS .DQC 4k AS .SYM 1k
AS-EXEC .COM 10k ATARI .H 1k
ATARI .LQB 1k ATARIBUS.DQC 2k
ATARIFN .CQL 2k ATARIFN .CQM 7k
BASICDOS.AQR 59k DOSTRUCT.HQ 1k
HARDWARE.DQC 4k PATCHING.DQC 5k
README .1ST 3k
Library directory for D1:CPM#025 .LBR 168k
-FOG/CPM.025 0k //CPM025.DOC 2k
/JAN/86 . 0k DDTF .AQM 12k
DDTF .COM 2k DDTF .DOC 6k
H80 .MNE 2k I80 .MNE 2k
I85 .MNE 2k MAC .MNE 2k
MSA15 .COM 7k MSA15 .DOC 1k
REVAS .COM 16k REVAS .INF 3k
TDL .MNE 2k Z80 .MNE 2k
Z8E .COM 12k Z8E .DQC 90k
Z8E .SYM 1k ZDT .COM 7k
ZDT .DOC 1k
Library directory for D1:CPM#026 .LBR 168k
-FOG/CPM.026 0k //CPM026.DOC 2k
/FEB/86 . 0k FIND52 .COM 3k
FIND52 .DOC 12k FINOTE .COM 17k
FINOTE14.DOC 26k FINOTE14.INF 2k
JUKI .BAS 11k JUKI .DOC 8k
PAIRX .COM 1k PAIRX .DOC 3k
PSDEMO .SAM 3k PSDOTCMD.BAS 1k
PSFORMAT.BAS 9k PSFORMAT.DOC 4k
PSJUST .BAS 3k PSNCLUDE.BAS 3k
PSRJ .BAS 17k PSRJ .COM 21k
PSRJ .DOC 13k PSVALUES.LRG 3k
PSVALUES.SML 3k PSWRAP .BAS 4k
Library directory for D1:CPM#027 .LBR 160k
-FOG/CPM.027 0k //CPM027.DOC 2k
/FEB/86 . 0k GPIB .COM 12k
GPIB .DOC 4k GPIB .PAS 10k
SLIST .COM 31k SLIST .DOC 58k
SLISTCTL.DAT 1k SLISTINS.COM 23k
SLISTINS.DTA 5k SLISTINS.MSG 3k
SLISTRSV.DAT 2k SYSTEM .DAT 1k
TURBO .DOC 1k TURBO .PAS 7k
TURBOSAV.COM 1k TURBOSAV.DOC 2k
Library directory for D1:CPM#028 .LBR 160k
-FOG/CPM.028 0k //CPM028.DOC 3k
/FEB/86 . 0k CENTER .FNC 2k
CPM .PRC 5k CRT .PRC 2k
DISKFILE.FNC 1k FOGSTORE.COM 12k
FOGSTORE.DOC 6k FOGSTORE.PAS 6k
GETPIC .FNC 9k HEXTOCHR.FNC 2k
LCRJUST .FNC 2k LST .PRC 1k
MANYCHAR.FNC 1k MONEY2 .COM 15k
MONEY2 .DOC 3k MONEY2 .PAS 12k
PICTURE .DOC 6k PICTURE .PAS 2k
REPLACE .FNC 2k SAYBOOL .FNC 1k
SAYPIC .FNC 9k SLIST .PAS 12k
SLIST1 .INC 7k SLIST2 .INC 6k
SLIST3 .INC 6k SORTS .COM 12k
SORTS .DOC 3k SORTS .PAS 15k
SQUEEZE .FNC 2k SYSCONST.COM 1k
SYSINIT .PRC 2k SYSTYPE .TYP 1k
SYSVAR .VAR 1k TRIM .FNC 2k
WAIT .PRC 1k
Library directory for D1:CPM#029 .LBR 160k
-FOG/CPM.029 0k //CPM029.DOC 2k
/FEB/86 . 0k EXPLORE .CMD 6k
EXPLORE1.CMD 6k FAMTREE .BAS 24k
FATHER .NDX 1k GEN .DOC 23k
GENLGY .DOC 3k GHOST .FMT 2k
GHOST .ZIP 2k GHOST .ZPR 2k
HELPEXP .FMT 2k HELPEXP .ZIP 2k
HELPEXP .ZPR 1k HELPEXP2.FMT 2k
HELPEXP2.ZIP 2k HELPEXP2.ZPR 2k
HELPEXP3.FMT 2k HELPEXP3.ZIP 2k
HELPEXP3.ZPR 1k HELPEXP4.FMT 2k
HELPEXP4.ZIP 2k HELPEXP4.ZPR 1k
LIST .FMT 1k LIST .ZIP 2k
LIST .ZPR 1k MOTHER .NDX 1k
NAME .NDX 3k NEWGENEA.BAS 15k
NEWINDEX.CMD 1k NS .CMD 4k
PERSONS .DBF 4k REF .NDX 1k
STORIES .DBF 4k STORY .CMD 2k
STORYREF.NDX 1k TESTSW .CMD 2k
TREE .COM 27k TREE .DOC 3k
Library directory for D1:CPM#030 .LBR 152k
-FOG/CPM.030 0k //CPM030.DOC 2k
/MAR/86 . 0k AUTKYS60.COM 7k
AUTKY60 .WS 4k CLOCK . 4k
CLOCK .COM 5k CLOCK .DOC 2k
COLDBOOT.COM 1k COLDBOOT.DOC 1k
CURS-KAY.ASM 1k CURS-KAY.COM 1k
CURS-KAY.DOC k CURSOR .COM 1k
CURSOR .DOC 2k DB19 .COM 3k
DB19 .DOC 6k DDRAW .COM 21k
DDRAW .DOC 8k DDRAW .NOT 1k
DUMP10 .COM 1k DUMP184 .DOC 3k
DUMP24 .COM 1k KP4TIME .COM 2k
KP4TIME .DOC 2k KP-CHARS.COM 10k
KP-CHARS.DOC 1k KP4TIME .COM 1k
KP4TIME .DO 2k KP4IME2 .ASM 2k
SETPAD10.COM 13k SETPAD10.WS 5k
Library directory for D1:CPM#032 .LBR 160k
-FOG/CPM.032 0k //CPM032.DOC 2k
/MAR/86 . 0k EDIT .COM 2k
EDIT .DOC 1k EDIT11 .CRD 2k
VDE .DOC 20k VDE13 .COM 7k
VDO .AQM 34k VDO .DOC 14k
VDO-OVR .ASM 9k VDO-OVR .SUB 1k
VDO25 .COM 7k VDO25 .MAN 22k
VDO25 .NOT 2k VDOC .COM 4k
VDOC .DOC 5k VINST11 .COM 14k
VTRM .DAT 3k
CFOG's PIP, May 1986, Volume 4 No. 7, Whole No. 43, page 15
Fog PC-DOS Disks Available!
We have now received nine disks of PC-DOS software from California's FOG. These are available only to FOG members! They are on RCPM #2 in Drive D, user area 2. Here's a partial listing of what's available:
Library directory for D2:DOS#001A.LBR 152k
-DOS001 .DOC 2k EDWIN .COM 62k
EDWIN .HLP 7k FRED .DOC 11k
FRED .EXE 37k FRED .SUM 2k
MONTHWK .CAL 25k QUARTER .INT 3k
Library directory for D2:DOS#001B.LBR 176k
-DOS001 .DOC 2k DAILYINT.CAL 15k
DEPCAL85.CAL 22k GJTAXCAL.CAL 104k
SUMWORK .CAL 35k
Library directory for D2:DOS#002A.LBR 112k
-DOS002 .DOC 2k COMMANDO.EXE 88k
INSTALL .EXE 17k README .DOC 4k
Library directory for D2:DOS#002B.LBR 176k
-DOS002 .DOC 2k COMMANDO.DOC 169k
Library directory for D2:DOS#003A.LBR 144k
-DOS003 .DOC 2k BABY .EXE 37k
DIGGER .DOC 1k DIGGER .EXE 57k
FLY .BAS 5k HOPPER .BAS 6k
HOPPER .EXE 37k HOPPER .SCO 1k
Library directory for D2:DOS#003B.LBR 136k
-DOS003 .DOC 2k PACGIRLA.EXE 48k
PANGO .EXE 29k PANGO .KEY 1k
STARGATE.EXE 57k
Library directory for D2:DOS#004A.LBR 152k
-DOS004 .DOC 5k ASCII .PAD 2k
AUTO .BAT 1k AUTOEXEC.BAT 1k
AUTOINST.COM 8k AUTOM001.MDF 1k
AUTOMENU.COM 12k AUTOMENU.DOC 68k
AUTOMENU.MDF 2k CALENDAR.PAD 1k
DESKMATE.CFG 1k DESKMATE.COM 51k
DISKETTE.BAT 1k HARDDISK.BAT 1k
Library directory for D2:DOS#004B.LBR 152k
-DOS004 .DOC 5k DESKMATE.DOC 118k
EPSON .CFG 1k HOLIDAYS.PAD 1k
INSTALL .COM 18k MANUAL .BAT 1k
METRICS .PAD 2k OKIDATA .CFG 1k
PARALLEL.CFG 1k PHONE .PAD 1k
PLUGPLAY.CFG 1k PRINTER .CFG 1k
README . 2k README .BAT 1k
STATES .PAD 2k
Library directory for D2:DOS#005A.LBR 160k
-DOS005 .DOC 3k EDIT .EXE 46k
EDIT .HLP 6k EDIT .SET 1k
EDITDOC0.PRN 4k EDITDOC0.SET 1k
EDITDOC0.TXT 3k EDITDOC1.PRN 11k
EDITDOC1.SET 1k EDITDOC1.TXT 8k
EDITDOC2.PRN 29k EDITDOC2.SET 1k
EDITDOC2.TXT 21k EDITDOC3.SET 1k
EDITDOCA.PRN 20k EDITDOCA.SET 1k
EDITDOCA.TXT 8k
Library directory for D2:DOS#005B.LBR 152k
-DOS005 .DOC 3k EDITDOC3.PRN 85k
EDITDOC3.TXT 45k EDITDOCB.PRN 10k
EDITDOCB.SET 1k EDITDOCB.TXT 5k
PRINTDOC.BAT 1k READ .ME 3k