Category : Databases and related files
Archive   : DATAMAGE.ZIP
Filename : MACRO.DOC

DATAMAGE MACROS



If you have just gotten DATAMAGE and you are browsing the docs please don't
read this file. While rambling about the MACROS I will assume you have a good
understanding of how the SCRNBASE and DISKBASE programs work, and what they do.

The help screens liken MACROS to programs, and they are similar in that they
are both a way to do a job needing done. NO ATTEMPT has been made to provide a
full-fledged programming language. And none will be, until I'm so vain as to
think I can do better than BASIC; and that'll be a while....

You see, to wield a full-fledged programming language you need to be a full-
fledged programmer. If you are one of those you will see the facility of the
datafiles being accessible to your BASIC (or whatever) programs. The DATAMAGE
can free you of the drudgery of writing datafile maintenance into each and
every program you originate, and provide your users with many functions not
offered by your program.

DATAMAGE is designed to be totally assimilated by your average clerical
employee. And is PURPOSELY LIMITED to what is reasonable to expect of same.

Unlike a real programming language, MACROS do not allow the interaction of the
data being processed and program control. They do not embrace the concept of
LABELS, nor do they allow testing/branching.

They do allow conditional processing; only the records in the group are acted
upon by many functions. The functions themselves are fine-tuned to do what is
necessary in business datafiles, within the context of your average clerical
employee.

DATAMAGE is the realization of the concept that any good secretary can program.
If you can do an operation on paper files then you can do it to a diskfile.

This idea would make many a programmer awaken at night in a cold sweat,
concerned about the data in the file. It has that affect on me, as well.

For that reason, DATAMAGE provides many tools not available with, for example,
BASIC. The ability to BROWSE the current group and verify the results of all
operations done so far (provided you remember them) is invaluable to the
neophyte, and quite useful regardless of the status of the operator.

On the other hand, MACROS are limited in what they can do, where BASIC is not.

So, first off, decide who you are. If you are a programmer then the
PROGRAMMERS KIT, and a QUICK BASIC (turbo pascal, etc.) compiler will take you
all the way.

But, do you need to go all the way? Or, could you make a quick, easy, bullet-
proof MACRO that runs from within the DATAMAGE? Your decision.

Or, would you like some sort of hybrid situation, where a MACRO does some
record selects and calculations, then writes the records in the current group
and their two counters to disk in a MARKER FILE that is read by your CUSTOM
program, the POWER COPY program or the POWER MAIL program? Or, how about egg
in your beer?

DATAMAGE imposes no limits; you are CERTAINLY not limited to what a MACRO can
do. You are free to put the pieces of the puzzle together any way you wish (we
made them all square) and to come up with the overall system that best suits
your needs.


CHEAP INSURANCE


Having written a fair number of random-file programs in BASIC I don't think
I've ever tested a program on the only copy of a valuable file. May I be so
bold as to say that you shouldn't, either?

The datafile structure of DATAMAGE allows quick and easy datafile cloning.
From the MAGE directory of C:, enter: MD WORK (test, temp, target, whatever
turns your crank....). Then CD WORK. And, finally COPY ..\(dir name you're
cloning)\*.*. Presto, you've got a copy of the file you can afford to blow
away. When you do, repeat the above process, and try again!



TIP #1: DEVELOP YOUR MACRO IN A TEST ENVIRONMENT!



Once you have established your test environment it becomes a SIMULATOR. The
dynamic factor in the MACROS is the data in the files. In the SIMULATION
environment you are free to change data in certain records to find out what
would happen if....

ERROR TRAPPING: Somewhere between 1958 and 1960 somebody wrote the first
computer program. Endless quibbling can be done on what constitutes a program,
so the poor guy still, as far as I know, hasn't gotten credit for it.

Soon after the first program was written, or perhaps during it's creation,
somebody thought: WHAT IF something goes wrong right here....

The concept of PROGRAMMING and ERROR TRAPPING are of approximately the same age,
and are siamese twins. Each time a new program is created one of the things
the PROGRAMMER must do is to separate them, and make them both behave.

When you write a MACRO you (yep, YOU) are the programmer. The fact you are
programming a program instead of the computer is of little consequence when you
realize the RESULTS are the same.

YES YOU CAN program. If you have used DATAMAGE to select a group of records
and print them you ALREADY HAVE! You have issued a first-class programming
command: IF (parameters you selected to form the group) THEN PRINT THE
RECORDS. And you have, no doubt, met with success in doing so. So, the hard
part is behind you.

DATAMAGE, like the programming language of your choice, consists of a limited
number of functions. Many of the functions will do different, though similar,
operations when various parameters are specified. Like a programmer, the user
selects these functions and specifies parameters to them. The functions are
building blocks, of which a very great number of possible process can be
constructed.

Most ways to program group your function selections into a program.
DATAMAGE allows you the option of making a program: The MACRO.

There's DANGER in MACROland. A poorly designed MACRO can work well for six
months or six years, then blow up in your face. Leaving you with some of your
records having been processed, some not, and no way to determine which is
whom.

Let's say we have a customer file with records from all states. Every so often
we need to print our receivables by state in order on amount. While we're at
it, we'll post interest on the balance to the record.

A MACRO is written that selects records in the target state, selects records
in the survivors having a balance of > 0, sorts on balance, prints a report,
computes/adds interest, etc. Then reloads the file, and does it again until
all fifty states have been processed.

The macro is carefully verified, implemented, and runs fine for three months.

The forth month all our customers in Montana are paid up. The MACRO expects to
find Montana records to process but has found none. If this had happened
during manual program operation DATAMAGE would have provided the appropriate
error message, and how to proceed would then be left up to the user. In a
MACRO that's not good enough.

If the MACRO aborts we are left in the sad situation described above. The
operator (whenever the MACRO is run) CAN NOT be counted upon to recover from an
error of this type. So the MACRO must recover the error and continue
processing the remainder of the states.

In order for the MACRO to recover it must JUMP OVER the instructions that
compute the Montana records, and resume processing with the first instruction
that processes the records for the next state.

After the processing of each states' records the entire file was reloaded
using the F11 function, then the F7 function was used to select the records in
the next state to be processed. If the MACRO jumped to the next F11 the
recovery would be successful.

The above situation is often duplicated, but a marker file is loaded between
the processes. For that reason you may also select resume next load marker as
an error option.

In some cases you would want a MACRO to end early if no survivors were found
during a record select operation. The ABORT error option will do that, and the
message FATAL ERROR IN MACRO will be displayed.

Depending on the complexity of the task a MACRO may or may not be an
acceptable way of doing it. If you need, and can handle, the kind of error
trapping that allows you to redirect the control to any label you have defined
inside your program then get QUICK BASIC and write your own program.

If DATAMAGE allowed that kind of processing it would, of necessity, exclude
many users incapable of programming at that level. In other words you would
have to be a programmer to be able to use the program. And that's NOT what
we're doing, here.



TIP #2: PLAN FOR THE UNEXPECTED!



Let's take the above example just a little further, if you can stand it....

Suppose we have current customers in only 31 states, but we have BIG PLANS! By
taking advantage of out simulation environment we can write a macro that will
compute the states having no current customers.

Unlike BASIC, DATAMAGE will not allow the processing of data that is not
present. In BASIC you would use a FOR-NEXT loop structure, and an array
containing the two-letter state abbreviation for all 50 states.

The FOR-NEXT would, first off, read through the file and identify the records
matching the current state code. If there were none you would BRANCH to the
NEXT, and try the next state code.

Odds are you don't program in BASIC (or any other language) and don't
understand the last two paragraphs. That's O.K. (Bunky); DATAMAGE was written
for YOU!

Simply enter a couple of "dummy" records for the states in which you have no
current customers. During MACRO recording the select records routines MUST
find some survivors. If a select records operation is executed that finds no
survivors an error message will be displayed and the MACRO will be aborted.

When your MACRO is completed and verified copy it to the dir containing the
real file to be processed. If you have correctly selected your error options
the MACRO will compute records in the states currently represented in the file,
and ignore the fact that some are missing.

Suppose after our monster MACRO had finished its calculations we wanted a total
of the money we charged our customers who owed us for doing nothing during the
preceding week/month etc.

That would be easy, just write it into the records as they were computed, then
re-load the file and use F14 to make a total, right?

And it would work O.K. first trip....

Second month/week, the values from the last run would still be there. If a
customer was paid up it would still be added in, along with the new data for
those who weren't paid up and had been processed....

And, what about that cash and carry state: Montana? The records accruing
interest last month would still have the amount of interest in them, and it,
too, would be added to the would-be total of this months interest.

The F9 function writes the same value to all records now in the group. If it
was used to zero the field containing the interest before the states were
selected and processed there would be no problem.

The computer can't think, and neither can your macro. Neither recognize a
logic error on your part, and both will hum happily along and feed you garbage
until you burst.

And your car will happily slam into a concrete wall at 80. The reason it
doesn't is because you are in control, and you can think.

In the drive to work situation you are required to think, and since you made it
I'll assume you did.

In order to drive the DATAMAGE successfully to your destination you may find it
useful to think about your "trip" before you start. You know that "beantowne"
is somewhere in the upper left corner of Texas. So you access Mr. McNally,
find it, then chart a course on roads that appear on the map.



TIP #3: THINK ABOUT IT A WHILE FIRST!



Once I worked for a place that had eight programmers. And most of them came
and went. I stayed a while, though I hated the conditions, because I liked the
work and the guy I worked for.

One day I asked him: "When a new guy comes in, how do you tell if he's any
good?" His reply was that he just used his watch. The time interval between
the new guy getting an assignment, and beginning to code it was the key.

Within reason, it was the longer the better, and the more questions the guy
asked in the time period, the better. He also told me he didn't think I was
any good, at first!

"Yeah, O.K., that's what I thought you wanted; just made sure." was his
favorite line, and he NEVER had to re-organize a program to do something he
forgot. When changes were called for by the big-shots he often started over.

I had a way of coding that was so modular I could "throw it up in the air" and
when it landed it would do whatever else. We learned from each other.

Organizational methods/props galore exist to provide graphic facsimiles of
program control; some use flowcharts, some wiege boards, even dolls with many
pins. Still others ask their questions, then sit like the sphinx for three
days before writing code that runs first time.

Anyhow, the WORST POSSIBLE way to do it is to run through it and walk away.
You will find it has a way of calling you back, and installing grief.




TIP #4: DON'T BYTE OFF MORE THAN YOU CAN CHEW!




It has occurred to me on many occasions that I have given my users about 10
times enough rope to hang themselves. I decided to write DATAMAGE one day
while screaming profanities at dBase. That program makes me NEED to get my
baseball bat and....

After having written DATAMAGE, I look at it a bit differently. DATAMAGE makes
it all too easy. Touch a couple keys and watch it go!

Another way of looking at it is there will be many people "programming"
DATAMAGE who have absolutely no business doing so, and DISASTER will often
result. dBase is anything but easy. But, few would DARE try to program it
without taking a night course, and a couple tranquilizers!

Though it may seem otherwise, the production of any serious business systems
using DATAMAGE requires of the user/programmer the same things that are
required when using dBase: A thorough knowledge of the software AND the job to
be done.

Though the former has become a LOT easier, the latter remains unchanged.

The presence of a computer in the room frightens many people into immobility.
Others don't think logically, and computers require logic. And some people are
just plain dumb.

If you are a logical person who is unafraid, possessed of average intelligence,
and have taken the time to define and fully understand the job to be done you
will do well.

If not, you can get someone else to do it. If you need to pay them then do so.
That is far more economical than taking action on erroneous data. And
preferable to the frustration experienced by those whose thought processes do
not lend themselves to computerized data processing.

I can cause this computer to do anything it can do, but I can't draw a picture
as well as your average five year old kid. I KNOW THAT, so I don't draw
pictures. If the above applies to you in reverse, then don't write programs!