Shareware Overload/ShartewareOverload.cdr/database/datamage.zip/DOCS.ZIP/MACRO.DOC

Text File | 1991-02-28 | 15KB | 291 lines

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 BASE program works, and what it can do.

RECORDING AND RUNNING MACROS:

DATAMAGE MACROS are recorded from the BROWSE screen of the BASE program.   Once
recorded,  they are executed from there as well.  To record a macro, press Ctrl
+  F-1.   Then  do what you want it to do.  Press Ctrl + F-1 again   to   close
the file.  Your MACRO is now ready to run.

To execute a MACRO press Ctrl + F-2.  MACROS can also be run automatically,  at
the exit of a datafile.  To make an automatic MACRO all you need do is to  call
it AUTOEXIT.  This MACRO will run automatically every time a user accesses  the
file and deletes, enters or updates a record.  This feature is usually used  to
maintain MARKER FILES containing groups of records in a certain order.

WHAT IS A MACRO?

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.

You  see, to wield a full-fledged programming language you need to be  a  full-
fledged   programmer.  If you are you will see the facility of  your  datafiles
being  accessible  to your BASIC or C 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  real
programming languages such as C and BASIC are not.

So,   first  off,  decide  who  you are.  If  you  are  a  programmer  then   a
QUICK BASIC (Quick C, 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 with C and 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, sorts on the 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 OK. (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 OK. 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!  And that I was the only exception to his rule, to date.

"Yeah,  OK.,  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
weeks 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!

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 BASIC or C:  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.