CFOG's PIP, June 1987, Volume 5 No. 8, Whole No. 56, page 1
[For the benefit of those members who did not take the front page editorial last month as seriously as they should have, the following report was published in the June issue of DOG Bytes, volume 6, number 6. -- bhc]
by Charley Johnson
We finally found a name for our organization. It fits. DOG is gone, doggone it.
By now DOG members have received a letter from John Gaudio speaking for the board of directors with the bad news. The board, after long deliberations, has decided to dissolve the corporation called the Denver Osborne Group. Of course, your appravel of this action will be sought at the regular meeting on July 2, 1987.
There is no reason at all why there cannot continue to be a group of friends who meet each month or share a newsletter. The board has taken great pains to ensure that such a group can remain and reform itself. But it is clear that the current trends, if allowed to drift as they are, will make such a pleasant outcome impossible.
Let me explain myself. We have a considerable amount of money in unspent dues, paid by the membership (about $1300). We have a newsletter with a great history and editor. We have a good meeting place. We have some talented people. We have several libraries of public dornain software. We are associated with FOG. We have a great history.
But good people, for perfectly good reasons, don't come any more. We can't get enough articles for a newsletter. Pleas for help with presentations go unheeded. The membership is down to 89 (600+ have passed through our rolls) and may be below 50 in two months. Few new members are joining and many old members are not renewing. The meeting place is about 20 times larger than we need and too expensive. We have only one advertiser (John Gaudio, and his ad is a kindness to us rather than good business for him) and very few supporting vendors. The libraries distribute fewer than 10 disks a month according to the reports I had at our board meeting.
The real killer is that we no longer have that single, central, unifying idea that we had in the beginning. Very few of us still use an Osbome and those that do need no more training or support. Search as we might for the past year, we have found no reason to continue DOG except friendship.
And it is for the sake of that friendship that we must stop now. The possibility of bitterness and accusations over the last few dribbles of money haunt me. The decline of the club has already divided a few of us and that cannot be allowed to continue. I hope with all my heart that what will remain of DOG are the lifelong friendships started here. If some are already broken, let this action signal their renewal.
Let us dissolve while we are still able to refund what we owe people, at least financially. When people remember DOG, let them remember a group that put them first
I hope you understand. No one believes that we will survive for another twelve months. Is the value of those few remaining meetings and newsletters great enough to warrant spending that much money, personal effort, and mutual regard?
If we quit new we can refund dues, meet all of our obligations, and part friends. If we wait any longer we may lose what little remains to us and ngain nothing.
There is some good news made possible by our acting now. The libraries still exist. And the librarians have agreed to keep them as long as they can for your use. Keep their phone numbers. At their convenience you may copy to your hearts' desire anything you want for free. For this promise on their part the borad has entrusted the libraries to these people.
More good news is that we can still meet. We are publishing the phone numbers of every member in the next issue so that any effort to form a new organization or just get together informally can have a head start. In addition, DOG will pay for the hall one more time so that those interested can sit down together to arrange something new. Come that last night, July 2, 1987, and rearrange the chairs. Some may want to form more informal home gatherings for CP/M or portables or rock hounds. Now is your chance.
[I have omitted the details of the dissolution process as outlined in DOG Bytes. -- bhc]
[It can happen here. While CFOG is bigger than DOG, still over 200 members, and the election of new board members at the May 31 meeting seems to carry with it the possibility of a revival of sorts, only time will tell. Don't let it be your fault.-- bhc.]
CFOG's PIP, June 1987, Volume 5 No. 8, Whole No. 56, page 2
[I found these on the Lillipute Z-Node, 312-649-1730. -- bhc]
Msg # 6030 posted 05/08/87 by Jeff Moro
Does anyone know how to make a dbase II CMD file abort back to a main menu with a keystroke? I've done a nice little menu set-up for some folks who don't want to touch the innards. The problem is that they may want to abort printing their labels before the job is finished (slow printer, paper jam, etc.) and return to the menu. [Esc] will (partially) work but it dumps them back to the (dreaded) dot prompt; wait, input, accept and various combinations of get and read I've tried don't seem to do the trick. Seems there should be some kind of INKEY procedure which could flip a logical to false and allow a graceful abort.
Msg #6035 posted 05/08/87 by Steve Cohen
There is no INKEY function in DBASE. If you want one you have to put it in with assembly language. A routine to do this is given in the book "advanced programmer's GUIDE" by Castro, Hanson, and Rettig, published by Ashton-Tate pp. 538-539. You should also read Chapter 22 of this book on the assembler interface in general. In my opinion this is the best book I've seen on dBase and it covers versions II, III, and III+ (somewhat).
Msg #6038 posted 05/09/87 by Charlie Kestner
I seem to recall that if you modify dBase with one of the NEWBASnn inserts, you can prevent the user from EVER getting the dot prompt.
Msg #6043 posted 05/09/87 by Bruce Morgen
NEWBAS11.ASM has both INKEY and dotprompt lockout options. In a word, indispensable to the serious dBase user.
CFOG's PIP, June 1987, Volume 5 No. 8, Whole No. 56, page 3
by Mike Rulison, Raleigh Osborne Computer Club
The dBase II Report command is a powerful report generator, but it provides no means of revising a filename.frm file once it has been made. This can be done with a word processor, however, as the file is a very straightforward ASCII format file.
Revising the file with the word processor is especially useful if you want to make significant reorganization, such as moving the last column several columns to the left. That is readily accomplished with a block move, starting with the line that contains field width and field name or expression, followed by the column heading (or blank line if this is omitted), and, if the field is numeric and you have asked for totals, a 'Y' or 'N' depending on whether you want totals for that field. (This adds up to 2 or 3 lines.)
Be careful, however, in revising such a file NOT to allow a blank line at the top of the file. Such blanks will result program failure and messages about format or syntax errors. Remember this also should you decide to create your filename.frm file totally with a text editor, rather than with the dBase II Report command. It is relatively easy to do that, too.
CFOG's PIP, June 1987, Volume 5 No. 8, Whole No. 56, page 4
by Daryl Gelbach and Walt Wheeler
[This is the fourth in a series of articles on MEX to be reprinted here. They originally appeared in Y.O.U.r NEWSLETTER, the newsletter of the Yankee Osborne Users Group. -- bhc]
In a previous article we explored the use of the INI.MEX file for setting operating parameters. As we said, this is a special kind of READ command file. It is possible (and desirable!) to use READ command files for other tasks, in particular file transfers. This article will present four command files to demonstrate how MEX can make the task of file transfer easy.
The first example is a simple download file. It is expected that you are in the drive/user area where your target file is.
[These files are set up indented a few spaces. The lines with two periods at the left are comment lines. In your file you'll actually have those at the left margin. They help you keep track of what you have done. The numbers at the left margin are line numbers shown in square brackets in the explanation that follows. -- bhc]
..
.. GET1.MEX
.. written 1-12-86
.. modified 1-20-86
..
1 WRT
2 SENDOUT "XMODEM S {1}"
3 SLEEP 3
4 RT {1}
Note the number in curly braces {}. The curly braces indicate that a variable will be read from the command line you type. Thus the file is adapted for multifile use. By turning the MEX EXTEND switch ON [STAT EXTEND ON<cr>], you can exccute a READ file without typing the word READ. This makes for an elegant command. From the MEX command prompt you type.
GET1 fn.t
<cr>
MEX will [1] close any buffer that you have by writing its contents to the disk, [2] activate XMODEM on the remote system telling it to send the fn.t, [3] open a file with the same name on your logged drive/user, [4] tell XMODEM to start sending the file, and return to terminal mode when it's all done.
The second download file adds a drive/user prefix to the target file, allowing XMODEM to cross areas to transfer the file. Again note the numbers in brackets {}. These indicate the position of the variables on your typed command line. This is very important to remember.
..
.. GET2.MEX
.. written 1-12-86
.. tested and modified 1-20-86
..
1 WRT
2 SENDOUT "XMODEM S {1}:{2}"
3 SLEEP 3
4 RT {2}
To transfer this file, go to the command prompt and enter:
GET2 du fn.t
<cr>
The drive/user must be separated from the filename by a space and NOT contain the colon. MEX will then be able to set up the file transfer properly and do it.
The only difference in this file is that line [2] specifies the drive and user area from which the file is to be sent This allows you to get a bunch of files from the remote system without changing drive or user area there.
.. SEND.MEX
.. written 1-12-86
.. tested and modified 1-20-86
..
1 WRT
2 SENDOUT "XMODEM R {1}
3 SLEEP 3
4 ST {1}
Now you have a READ file we call SEND.MEX! To send a file, go to the command prompt and enter:
SEND fn.t
<cr>
This READ file [1] closes the buffer, [2] sends the command to the remote system to receive the file you are going to send, [3] waits a moment for the remote system to get ready, and [4] sends filename.typ from the current logged drive and user area, then return to terminal mode.
Library file transfers are a little more difficult. There are three variables to enter on your command line. The following file is simply a variation of the above:
.. LGET.MEX
.. written 1-13-86
.. modified 1-20-86
..
1 WRT
2 SENDOUT "XMODEM L {1}:{2} {3}"
3 SLEEP 3
4 RT {3}
The command to use this file is:
LGET du lbrname fn.t
<cr>
If you have not engaged the READ extend function, you will have to prefix the command with the word "READ".
This READ file [1] closes the buffer, [2] sends the command to the remote system to send fn.t from lbrname located on the drive and user specified. The READ file continues by [3] waiting a moment for the remote system to get ready, and [4] tells your system to receive filename.typ, then return to terminal mode.
These four examples increase the versatility of MEX for you. This can help reduce the frustration you experience with any RCPM. The true benefit, however, is the time saved. This is enough to make MEX the modem program for you.
CFOG's PIP, June 1987, Volume 5 No. 8, Whole No. 56, page 5
by Benjamin H. Cohen
I was working on the documentation file for PC-File 80 with VDM because it's fast. I had to break it down into five separate parts because it was over 124K bytes and my O-1 with Drive C: RAM disk and Presto! installed has a small TPA (Transient Program Area, the part of memory in which programs run and where VDE puts the file to be edited). It worked fine. I found a couple of uses for VDM's macro keys that others might find helpful.
One of the perennial problems is saving files. I wrote a series of five macros using VINST, into a copy of VDM that I reserve for editing the PC-File documentation. Each macro looks like this:
^[nb:pcfile.001^M^[s^W
^[nc:pcfile.001^M^[s^W
^[na:pcfile.001^M^[s
I've broken the macro down into three lines to fit PIP's format. When defining the macro with VINST you'll enter the entire macro on one line. Now let's parse the macro:
^[nb:pcfile.001^M^[s^W
The first three characters stand for [ESC]n. That tells VDM to change the name of the working file. Next I've specified drive B: and the filename PCFILE.001. You have to press the <cr> to tell VDM you've completed the filename: the ^M shows that. The next three characters, ^[s, stand for [ESC]s, the VDE command to save the file under the current working name. This macro didn't seem to work the first time I tried it so I added a ^W for a short wait.
The next line of the macro is just the same, except that the working file has been moved to drive C:. The third line changes the working file to drive A:, the RAM disk, and saves it again.
Since there are five parts to the whole document, I made up five macros, saved on macro keys 1 through 5. Of course I don't take a chance that I'll hit the wrong key. I load the file from one of my two working floppy disks and then put two otherwise empty disks into drives B: and C:. If I hit the wrong macro key I won't wipe out a file by mistake! Another macro I set up while working on this file is one to reform the current paragraph and then move the cursor back to the place where it was when I hit the key. Here it is:
^P^Z^B^Q^P^H^G
The ^P^Z puts a place marker in the file. ^B reformats the paragraph. ^Q^P moves to the place marker. ^H moves the cursor back one space to the place marker and ^G deletes it.
Of course, if you have other place markers in the file this won't work correctly. That's not a very good solution to the problem, so I devised another one that's more or less foolproof.
A more or less foolproof method of doing this would create a macro like this
^Vxxx^B^Q^R^Q^Axxx^P^M^P^MY
This one sticks a string of three "x"s in your text, reformats, goes to the top of the file, searches for the three "x"s and replaces them with nothing. I say "more or less" foolproof, since if you have a string of three "x"s somewhere in the file you'll wind up there instead of where you expected. Of course, you could use a more unlikely string. This works so fast there's no reason not to do it.
Setting formats is another nice trick for VDM macros. You could simply set the margins: "^O^L5<cr>^O^R58<cr>". (Remember, you have to use a ^P before the <cr> to get it into the macro or macro definition.) That will set the left margin at 5 and the right margin at 58 for indented quotations in legal briefs. But I sometimes forget which function key is which. So, in order to avoid mistakes, first I jump to the left margin, then I insert a carriage return, then I set the left margin to one, then I enter two periods and the text "left margin 5 right margin 58", and then and only then come the margin setting comands. You can easily hit ^Y to get rid of the extra line of text, but it won't print if you use NewWord or WordStar to print your files.
The macro string is:
^V^O^L1^P^M^Q^S^P^N
..left margin 5, right margin 58
^O^L5^P^M^O^R58^P^M
Again, I've broken the macro down to three lines to fit PIP's format, but you would enter it as one string.
CFOG's PIP, June 1987, Volume 5 No. 8, Whole No. 56, page 6
CFOG Board Meeting, March 12, 1987
The following actions were taken:
Annual election meeting will be held at the May 3 meeting since the April 5 meeting will be during the special Triton College weekend on computer graphics. This will also give us the opportunity to present the amendments to the by-laws at the same time, since they were omitted from the March PIP.
The Secretary will take over the membership list and postcard meeting notice chores formerly handled by Cedric Chernick and Dave Jacobsohn. The hard disk and modem will be transferred from Cedric to Rand. Rand is purchasing a printer.
Because of Bill K's new position he will not have time during the next several months to develop the Televideo multi-user system. We will liquidate this system in favor of some other system which may take less time and effort to develop for expansion of the remote access systems.
RCPM #1 will be reinstalled at Bill K's house. It will be necessary to reformat the hard disk at that time. Bill will set up additional MS-DOS public domain and shareware on the systems. Only selected software from the library will be on line at all times since many items have never been downloaded.
Members will be encouraged to take an active part in CFOG affairs. We need to involve non-Osborne owners.
A suggestion to charge 50 cents for each library disk copied in order to create a fund to purchase a PC clone that could be used at meetings to copy disks onto MS-DOS and multiple CP/M formats was shelved for the time being.
CFOG Board Meeting, April 28, 1987
President Kuykendall brought up MS-DOS support. Proposed separate MS-DOS SIG with its own bulletin board. Jacobsohn asks what we can offer MS-DOS users that other groups can't: transition people who are moving to MS-DOS from CP/M. Friendships. No charge software copying. One system will become an MS-DOS system; the other will be a CP/M system.
Bill Kuykendall will keep both systems physically at his house and do the system maintenance. We need a group of CP/M people to take over most of the sysop tasks on the CP/M system.
An MS-DOS library will be started.
Jon Shimberg will get a 1200 baud modem to be used by him as treasurer.
No progress on sale of old equipment to date. There may be some developments.
Moved and passed to amend by-laws to make number of directors <in addition to the four officers> to one to five directors at large, effective at immediately. A quorum shall be four members of the Board.
Ben Cohen and Dave Jacobsohn are appointed as directors for a term to end at the annual meeting on May 3, 1987.
Board policy statements:
Correspondents who will during the course of the year submit an article to PIP.
Publicity Person(s)
Remote Systems Manager
Sysops, CP/M System
Sysops, MS-DOS System
Librarians, CP/M
Librarians, MS-DOS
Membership List and Meeting Notices
Executive Editor
Editor for MS-DOS
Editor for CP/M Kaypro
Editor for Osborne
Program Chairperson -- MS-DOS
Program Chairperson -- CP/M
Two programs at meetings with programs for both.
If there are not enough people to fill these critical positions the Board will consider disbanding the group.
Approved blanket order for FOG disks.
CFOG's PIP, June 1987, Volume 5 No. 8, Whole No. 56, page 7
by Benjamin H. Cohen
The title is taken from a column of Ted Silveira, a prominent writer on computer subjects, and author of the "CP/M Connection" column in "The Bay Area's Computer Newsmagazine", Computer Currents. Computer Currents is published bi-weekly and distributed free in the San Francisco Bay Area. I pay $18 a year to have it sent by bulk mail; 1st class is $40 a year. The May 5-18 issue arrived on May 14. It runs 96 pages in tabloid size. Center Productions, 5720 Hollis St., Emeryville, CA 94608.
Silveira speculates about what might be in WordStar 4.0 when it arrives. Here's a summary:
What Can We Expect to Get?
Expanded printer support
Expanded headers and footers
Multiple ruler lines
Undelete
Jump to page
Save and resume place
Easier customization
What Should We Hope For?
More speed
Built in macros
Laser printer support
Proportional spacing
Better column support
Better on-screen display
What Won't We Get
Split screen
Automatic reformatting
What Don't We Need
Built-in spelling checker
Built-in thesaurus
Built-in math
Based on expericnce with NewWord 2.12, 2.14, and 2.16 on the Osborne 1 and Executive, I think that you can expect to get everything that Silveira expects us to get. NewWord 2.16 supports more printers. NewWord 2.x supports three header and footer lines. Multiple embedded ruler lines (and right and left margin setting dot commands) in NewWord 2. x are "live": as you scroll past them the ruler line at the top changes to match the embedded ruler lines. You can select the size of the undelete buffer in NewWord 2.x: I have my undelete buffer set for 2500 characters with my Osborne Executive's large TPA, about 500 with the O-1. Jump to page is a feature of NewWord 2.x. ^KS does return you to the place where the cursor was without need for ^QP. And customization is much easier.
As for what Silveira hopes for, I hope we'll get them, but I'm not sanguine about all of them. More speed would be nice, especially judicious choice of what goes in which overlay. I'm not convinced that NewWord 2.x is faster than WordStar. Eric Meyer has proven that limited but significant macro ability can be built in without a lot of memory cost, but I doubt that anyone at MicroPro can approach the efficency of his code. It's not in NewWord 2.x. Limited laser printer support is given in NewWord 2.16, including proportional fonts, though not graphics of any sort or justified proportional spacing. I think Silveira is right that PostScript device support is not likely. Proportional spacing <other than on laser printers> seems to be on some folks' want lists, and might be nice if properly implemented, but hardly seems that important in the big scheme of things. Silveira doesn't explain what he wants in better column support -- NewWord 2.x has a column replace mode, and seems a small bit easier to work with than WordStar, but other than that it's no improvement over WordStar, giving the same problems with embedded print commands running across columnar material. NewWord 2.x does support underlining and highlighting to show underlining, boldface, etc., on screen. In my opinion, some of Silveira's "hoped for" features belong in the "expected" category.
I'm as sure as Silveira we won't get the ability to view and edit two files at once. I'd at least like to see a freezeable window a la VDM. I'm editing this file now with the list of features in the "won't get" category frozen in the lower half of my screen while I work on this text in the upper half of the screen. Even if I can't do it with a second file, and even if I can't edit in two places, the ability to see what's in another section of the file sure is nice. Automatic reformatting is a mixed blessing, frankly. If you're trying to edit a marked up hard copy, it's a curse: as you edit a paragraph text jumps from place to place so you can't find the next change because it's now at the right side six lines from the bottom instead of at the left side five lines from the bottom. It would be nice only if you could turn it off. As long as ruler lines and dot commands allow you to do a global reformat at the end in one step and get it all taken care of automatically, I don't consider lack of automatic reformatting all that bad.
I agree with Silveira that a built-in spelling checker of the RAM resident type isn't needed. After the fact spelling checkers that Iet you correct mistakes without having to go back and re-edit the text are fine. That's especially so for writers who wants to concentrate on getting thoughts down. Checking spelling can wait. Is a thesaurus worth the code it takes up? How fast can it be on a floppy disk system? And math features are certainly less important than a lot of other features, such as macros, reduced size, snd more speed.
What do YOU want? Have you written to MicroPro yet to tell them? If not, turn on your computer and fire off a letter to Mr. Lee Lensky, Project Manager for WordStar, Attention: CP/M Marketing, MicroPro International Corporation, 33 San Pablo Avenue, San Rafael, CA 94903.
[All right, I promise. Not another word about the new WordStar until... until I come across some hard facts about the CP/M version. -- bhc]