its owner, the
richest man since Solomon (from the Old Testament, some 4000 years B.C.,
who graced the people of that ancient time with wisdom - at least he
brought that for all his riches!).

I was shocked when I heard Roy, the DER technician who helped me with
random numbers. I wrote about it in a prior Nostalgia issue. I learned he
had ditched it for DarkBASIC. I'm into apps rather than games, and it
sounds like modern-day consumers won't take such things seriously.

So, the last nail is in the coffin; the last straw is drawn. None of the
fifty or so books, nor any of the Googled items, tells me in simple, non drawn-out terms how to keep variables in memory across multiple forms
(though you shouldn't have to do anything until you wish to free memory by clearing the variables).

The latest is keeping a Boolean, caused via a button click, on a form. I
have tried to follow everything I've read though, but can't find anything specific to this. I have even tried creatively with variations and my own ideas - so much so, that the only thing left to do is to wave two fingers
in the air - and walk away.

Here's to unhappy prog'ing...

May you all have better luck in your endeavours.



*************************************
NEVER ON A COMMODORE
By Lenard R. Roach
*************************************

I used to do everything from surfing the Net (not the Internet) to
budgeting to writing - and Heaven knows what else - on a Commodore. I used
to spend several hours a day on the Commodore just doing whatever I wanted.
My biggest fun was creating programs in 64 mode on my 128. I enjoyed the
fact that, with each subroutine written in BASIC, I added to a larger compilation of separate subroutines that would eventually conglomerate
together to become a functioning program by tying each subroutine with
either a GOTO or GOSUB command. But, even in programming it was
frustrating to look for those little gremlins called bugs, which were
little BASIC commands worded incorrectly or placed in the wrong subroutine.

I remember working on the program Check It Out recently, trying to make the program more compatible with its sister program, Check Mate. For those who
are not aware, Check It Out made it into the very last issue of RUN
magazine as one of the featured works of the month. RUN magazine gave me
$150 for the work, and like a fool, upon signing the contract, I lost all
the rights to make improvements to the program unless I received permission from RUN. Now, here in the 21st century, the programs once owned by RUN
have passed from company to company and from hand to hand so that only God knows exactly who owns them now. If any of you have read my book Run/Stop-Restore: 10th Anniversary Edition, I talk about dealing with one
of the companies that I found back in the early 2000s that had my program.
At first the company wanted me to publish any upgrades in their own
magazine which they started to replace RUN, but I couldn't see myself once again signing a work-for-hire contract and losing a second work to the
legal nonsense created by my failure to use foresight. Thus, the program upgrades never saw the light of publication.

What did I do with the upgrades? Right now they just sit in my collection
of Commodore programs waiting for the day of rebirth. Occasionally, I
break these programs out and run them through their paces to see if there
are any more changes I can make to them, but so far they seem to fit the
bill as they were designed, and the Spirit of Creation hasn't lighted upon
me to make any more changes. It is getting time to pull them down again,
clear off the dust, and check, just one more time, to see if there is
anything I can do with them. Maybe, just maybe, the light will come on and
I will begin to work on them again.

Well, like an old man, I get into a cul-de-sac and forget what I was
writing about. This article was suppose to be about the wrestling match in getting Check It Out and Check Mate to talk to each other. Maybe a
run-down of what each program is supposed to do may bring some light to
what I'm saying.

Check It Out was designed to allow a user to type in all the information
needed on a wallet size check. Then the program would print off that
inputted information onto a check inserted into a standard Commodore 9-pin printer. In the age where the Internet and hardware has made it easy to
pay bills instantly and on-line, this program seems a little moot, but if
there are any users out there like me who still like to make out checks,
and create for themselves a paper trail to look back upon, then this
program is for them. At first, I wrote this program because my hands have developed carpal tunnel and writing checks week after week had become a
painful experience. Check It Out alleviated some of that pain and made the check writing experience a little less awkward. When I started making out checks ahead of time for gas from my local convenience store, the clerks
were impressed by how it was done - and how neat it was to read a check
that didn't look like it was written by a three-year-old, since most people
in my neighborhood apparently had bad hand writing.

This is when I got the idea to try and go public with the program. First I contacted RUN magazine by mail, thinking they had hundreds of programs to
go through, and something as simple as a check-writing program would never
fare against some of the works they have published in the past. RUN
responded to the positive and sent me a copy of RUN Script (their response
to COMPUTE'S Speedscript) and told me to send the program in with a corresponding article written in RUN Script format. It took me several
months to learn how to manipulate Speedscript and I wasn't about to take several more months to learn another word processing program just to write
one article, so I cheated. I took the article that was written on how to
work RUN Script, erased the text, and wrote my article in its place, thus having all the margins and spacing's pre-formatted for me - and it worked.
Upon having program and article done, I mailed the two disks in, and
waited.

It didn't take RUN very long to get back to me with a letter stating they
were very interested in publishing my program code and to start talking contract. I called the number they listed in the letter and talked
directly with their front desk, who also happened to be working with Check
It Out on her computer when I called, and she had a few issues with the program. I thought I alpha-tested all the bugs out of the program before I mailed it, but I went ahead and listened to her complaints. It seemed at
the time when she went to hit RETURN to print the check, the program would print two question marks at the top of the check before making the check
out. At first I thought there was something I was missing in one of the subroutines that I wrote, so while on the phone, I booted my master copy of Check It Out (the one I made the copy from that I sent to RUN magazine),
and went with her, step by step, through the check set-up process. My
version ran just fine with no question marks popping up; when she ran hers
the question marks again appeared.

A mystery.

Well, with any mystery, as Sherlock Holmes says, you eliminate the obvious,
and whatever remains, no matter how improbable, must be the truth.
Software was eliminated, so now it was down to hardware. I asked the front desk person what hardware she was using. She told me she was on a
Commodore 128D with special hookups to talk to the remaining computers in
the building. Problem? As Charlie Chan would say to Number One Son, "Is possible," but such a hookup shouldn't be interfering with the print status
of the program, but I would ask to be sure. She stated that each computer
had its own free-standing printer. With that eliminated, there was only
one item left, and that was the printer itself. I wrote Check It Out to
work with the Commodore MPS 80

--- MBSE BBS v1.0.01 (GNU/Linux-i386)
* Origin: Dragon's Lair ---:- bbs.vk3heg.net -:--- (39:901/280)