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 Cohen

Can 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 Kuykendall

One 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 Kuykendall

As 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 Mundt

I 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 Cohen

A 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 Kuykendall

What 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 Kirschenmann

Like 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>:

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

[Entering the selection "B" will get you this:]

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