MVS TOOLS AND TRICKS OF THE TRADE
                         September 1989

                                      Sam Golob
                                      MVS Systems Programmer
                                      sbgolob@cbttape.org

                 THE SLAC MODS TO ASSEMBLER H

      You may be surprised to hear that I do not consider myself a
more knowledgeable MVS Systems Programmer than most of our esteemed
readers out there.  THAT MEANS YOU.  ALL OF YOU have your "pet
tricks" and neat ways of doing things.  ALL OF YOU HAVE EXPERIENCE
THAT I DON'T HAVE.  We all tend to take "our own stuff" for granted,
and we think that everyone else does things pretty much the same
way.

      WELL IT JUST AIN'T SO.

      I get a big charge out of going to someone else's data center
"just to see how they do things over there".  I happen to have a very
long commute to work (approximately 80 miles), and just about every
MVS shop that is located between Central New Jersey and Northern
New Jersey is "on my way to work", if I choose to go by that way.
My boss (bless his heart) is very understanding about my flexible
hours, as long as I put in the proper amount of time at the job.
Therefore, I visit friends at other data centers quite often.

      They do things very differently.  First, everyone has a
different hardware configuration than everyone else.  Often, they
have different levels of the operating system software.  The varied
scattering of vendor products in each place, makes for different
working methods by each individual.

      Every person's working history has given him a different "View
of Life".  One person has had to write a lot of JES2 exits.  The next
person runs JES3.  Another person has to contend with all kinds of
DASD management rules in his shop, so he has been busy enforcing all
sorts of restrictions as to "WHO is permitted to allocate a dataset
WHERE".  One person has to administer RACF and interface between RACF
and different devices; another shop has ACF2; still others have no
security at all, or they still use MVS passwords.  THESE DIFFERENCES
IN ENVIRONMENT FORCE EVERY INDIVIDUAL TO HAVE HIS OWN UNIQUE TOOLS,
AND WAYS OF DOING THINGS.

      People in our profession are starting to recognize that "we
can't do it all alone".  THERE IS POWER IN NUMBERS, AND IN MUTUAL
HELP.  Anyone who belongs to a local user group, or who has gone to
SHARE or GUIDE (and now NaSTEC) can testify that his "modus operandi"
or "what he does every day" has been improved in some way - a lot of
times IN MANY WAYS, at the conferences.  WHY IN HECK DO YOU READ THIS
MAGAZINE, if not to expand your knowledge and profit from what
someone else has done?

      What am I getting at?

      Simply this.  YOU DON'T HAVE TO THINK THAT YOU'RE AN EXPERT,
IN ORDER TO HELP SOMEBODY ELSE.

      Each one of us comes up with something pretty slick.  It comes
with the territory.  That's part of what we get paid for, because if
a robot or an untrained person could do our jobs, it would be a simple
matter of economics that we'd all be out of work.  They simply get
paid less money than we do.

      DON'T THINK FOR A MOMENT THAT THE OTHER GUY CAME UP WITH THE
SAME SLICK THING YOU DID.  HE HAD DIFFERENT PROBLEMS.  HE IS WORKING
IN A DIFFERENT SHOP.  HE has NO WAY OF PROFITING from YOUR work,
unless YOU DO ONE OF SEVERAL SIMPLE THINGS:

   o    Tell your friends.

   o    Bring the matter up at a user group meeting.

   o    Write something up and upload it on NaSCOM.

   o    Submit your thing to one of the MVS public-domain tapes.

   o    Write a note to this magazine, or write an article.


      My friends, I AM NO DIFFERENT FROM ANY OF YOU.  THIS IS ALL
I EVER DID.  If you profit from anything I am saying, I assure you
that many other people in the profession CAN PROFIT JUST AS MUCH
FROM WHAT YOU WILL SAY.

      JUST CARE A LITTLE BIT ABOUT THE OTHER GUY....

      IT COMES BACK.

      Just take the plunge and do it.  (Its no big plunge anyway,
just a plop.)

      YOU WON'T LOSE.

      Oops, I forgot.  I also did another thing.  I got into the
habit of calling the author of a public domain offering that I was
installing, to thank him (or her) for the work.  As a result, I
made a lot of good friends in the field, and we've often been able
to subsequently accomplish a lot of NEW good work together.

    *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *

      This month I would like to write about a marvelous product
extension that, unfortunately, not too many people know about.  It
is a series of improvements and enhancements to IBM's Assembler H
Version 2, called the "SLAC Mods" for Assembler H.

      The SLAC Mods were written by Gregory J. Mushial of the
Stanford Linear Accelerator Center in California.  They are one neat
piece of work.  People who know about them are hoping that the SLAC
Assembler H will provide IBM with future direction in REMEDYING SOME
OF THE GLARING DEFICIENCIES IN THE MVS (and VM) ASSEMBLER H VERSION
2.  (Be it known that the mods were originally developed under VM.)

      This is not to knock IBM completely.  Assembler H is a very good
product that we all depend upon.  Its main problem is that IT "KNOWS"
MORE THAN IT TELLS YOU.

      One of the biggest problems with all the MVS (or for that
matter OS) assemblers, is that they don't tell you, conveniently in
one place, WHICH MACROS WERE USED BY YOUR ASSEMBLY.  The assembler
has to "know" the information, because it must pull the text of
the macros out of a library, and process the material in enormous
detail.  THAT THE ASSEMBLER SHOULD LEAVE YOU IGNORANT OF THE FULL
NAMES OF THE MACROS IT FOUND, AND THAT IT WILL NOT PROVIDE YOU WITH
EVEN A SUMMARY REPORT ABOUT THEM IS ABSURD BEYOND BELIEF, when you
think about it.

      All the DOS and VSE assemblers give you a list of macro names
hit by the assembly, and they have done so since the beginning of
time.  Is MVS worse than VSE?  (Don't get me wrong.  I LIKE VSE.)

      The old IFOX00 assembler has some mods on the CBT and SPLA
tapes (CBT file 300, called $$MACROX), which show you which macros
were found by an assembly.  I am grateful to Bill Godfrey for writing
them, and I used them extensively for a time, but you can go only so
far in today's world with IFOX00.  You need assembler H.  I was so
interested such a mod for assembler H, that I wanted to write it
myself.  But being one who does not want to reinvent the wheel, I
nosed around to see if the work was already done.  That's how I found
the SLAC Mods from Greg Mushial.

      The SLAC Mods have a beautiful MACRO REFERENCE at the beginning
of the assembly (which will even tell you which macros are MISSING,
and which ones are INLINE), but they have much more.  I'll sketch
in some detail, some of the wonderful things that they have.

      The enhancements are of four types.  These are:

      o   Improvements to the assembler reports.

      o   Extensions to the Macro Language.

      o   Extensions to "Open Code" Assembler Language.

      o   "Run time" improvements.

I don't think I'll have space to describe ALL of the SLAC assembler's
improvements, but I'll try to give you a taste by mentioning a good
number of them.

      The two most immediately useful modifications are the MACRO
LISTING, mentioned earlier, which points out the LIBRARY NAME and
VOLUME SERIAL where each macro was found, and the USING LISTING,
which SHOWS ALL CURRENT, ACTIVE USINGS, at the top of each page.  The
macro listing comes in very handy when packaging code to be sent out
somewhere.  You want to make sure you've included all the necessary
macros, in the right versions, with the code you ship.  Also, for
your own information when you assemble a software product, it's very
useful to know what macros are involved with the code, and where they
came from.  The macro reference is turned on by the assembler option
"MSRC".  Sources for "COPY CODE" are also shown, together with the
MACRO origins that are displayed.

      The SLAC Assembler has a listing of ALL ACTIVE "USINGs" at the
top of each page.  The listing of all "USING" assembler statements,
makes it much easier to fix code.  For one thing, since the tied-up
registers are conveniently and currently displayed at the top of
each page, the programmer will not be tempted to reuse them to hold
some data, and thus introduce bugs into his program.  Instead of
conducting a lengthy search through pages and pages of code, with a
large possibility of missing a USING statement somewhere, all the
USINGs are visibly clear at the top of the page, with no more
guesswork.  The "UMAP" assembler option turns this feature on.

      Another annoying assembler inconvenience concerns the location
counter.  The programmer goes searching through the code, looking
for some particular displacement, and all of a sudden, the numbers
are not right.  This is often due to having a DSECT stuck in the
middle of the main code.  The location counter is showing the DSECT
displacements, and it is hard to immediately tell where you are.

      Two improvements address this.  The first one is a change in
the header display for the location counter.  At the top of a page
that has begun in the middle of a DSECT, the header says "D-LOC"
instead of the usual "LOC".  The regular location counter header
"LOC" is what is shown when the page header falls in the middle of a
CSECT.  Thus, a quick glance at the top of the page will inform you
what part of the code you're looking at.

      The second improvement is the DSECT CROSS REFERENCE at the
beginning of the assembler listing, if the option "DXREF" is turned
on.  This lists ALL DSECTS ASSEMBLED WITH THE PROGRAM, the LINE
NUMBER of the listing at which each begins, and the LENGTH IN HEX
of each DSECT.  Using the DSECT CROSS REFERENCE, you can "map out
the parts of the listing in your mind" in advance, to "scope out"
where the DSECTs are, so you'll be aware of them when you study the
listing in more depth later.

      It is possible to get "OPCODE COUNTS", which includes counts
of how many times a MACRO was hit, as well as how many times an opcode
was hit.  This is turned on by the option "OPCNTS".

      A "NON-REFERENCED SYMBOL LIST" can be printed at the end of
the assembler listing, if you turn on the option "NRLIST".  You get
to see a list of all LABELS THAT HAVE NOT BEEN REFERENCED BY CODE
in the assembly.  It may not be desirable to eliminate these labels;
they may be important markers to help follow the coding logic.  But
being able to see all of them together, can give a programmer an edge
in improving his coding design.

      The old IFOX00 option "LIBMAC" was put back in an improved
fashion.  This option had been dropped altogether from Assembler H.
Programmers seldom use this option, which PRINTS THE FULL SOURCE OF
ALL FOUND MACROS right in the listing.  IFOX00 printed all of the
macro source after the "END" statement.  Assembler H, which can have
multiple "END" statements if you use its "BATCH" option, evidently
caused a confusion to the designers as to where the expanded macro
source should fit in the listing.  The SLAC ASSEMBLER H puts them in
the listing, right before the expansion of the macro is printed.  A
comparison of SOURCE with EXPANSION can thus conveniently be done,
and we have not lost the possibility of using the facility, in the
rare instances when it is needed.

      One other change is apparent in the assembly listing.  When
looking at a LABEL CROSS REFERENCE or "XREF" listing, you'll notice
that some of the statement numbers are UNDERLINED.  This occurs when
the assembler determines that the operation being performed WAS
TRYING TO CHANGE THE VALUE OF THE REFERENCED FIELD.  This is an
attempt to show the difference between INQUIRY and UPDATE with
reference to statement labels.  At a glance, the reader can tell if
the location is being UPDATED, or merely referenced.  Again, the
programmer is being helped to zero in quickly on a reference he is
looking for.

      An EXCP count of READS and WRITES to the SYSUT1 work file of
the assembler is provided at the end of the listing.  It is also
possible to FORCE AN INCORE ASSEMBLY, using the "NODISK" option.
Since no I/O is done to the work file when "NODISK" is set on, the
assembly is significantly more efficient than if "DISK" is on.  The
SLAC Assembler always shows how much main storage would be necessary,
if the user wished to force the assembler to avoid using the work
file.  Problem with this is that if you run out of core when "NODISK"
is on, the assembler aborts. To avoid the abort, just keep "DISK" on.
The report at the end will show you if an incore assembly of this
particular code would have been safe, considering the amount of
REGION that you are running with.

      These constitute most of the REPORTING CHANGES in the full
assembly listing itself.  The SYSTERM file was also changed around
considerably, to enhance its usefulness to the programmer.

      The SYSTERM file is intended to provide a summary of the
success or failure of the assembly to the programmer.  As its name
describes, the output of necessity has to be SHORT, so a programmer
at a "limited view" terminal can check the assembly quickly.

      Most of the SYSTERM changes in the SLAC Assembler were designed
to remove the clutter, from what should be a simple listing.  I'll
just mention a few of the changes.

      The DECKID (name field of the first TITLE card) is printed
on each SYSTERM summary, to help avoid confusion when doing multiple
assemblies in one run with the BATCH assembler option.

      A "clean" SYSTERM listing now contains only the statements,
"ASSEMBLER DONE" and "NO STATEMENTS FLAGGED".  The rest is suppressed
for the sake of clarity.

      For errors in macro calls, the SYSTERM is simplified and made
to look more like the assembler listing.  Only essential material to
diagnose problems is printed.

      Up till here, we have described enhancements to the REPORTS
of the assembler, but not to the LANGUAGE ITSELF.  The SLAC Mods
have introduced new freedom in the macro language and in conditional
assembly.  In open code, there is a completely new concept of
"LABELED USINGS" and "QUALIFIED USING REFERENCES" which force an
address to be resolved by a PARTICULAR active USING, when several
are active at the same time.  This construct prevents unnecessary
extra tying-up of registers to resolve addresses.  More details
on these LANGUAGE CHANGES can be found with the SLAC Assembler
documentation.

      Run-time changes, besides the possibility of forcing in-core
assemblies, include the possibility of using an ASSEMBLER SYSPRINT
EXIT.  Also, it is no longer necessary to have the macro library
with the LONGEST LRECL FIRST in the SYSLIB CONCATENATION.  The new
assembler is smart enough to find the library with the longest record
length in the concatenation, and to allocate the size of its buffers
accordingly.

      Now comes an attitude question, which probably all of you are
having in one way or another.  Frankly, I am happy to use the SLAC
Assembler FOR THE REPORT CHANGES, but I AM AFRAID TO USE THE NEW
LANGUAGE IMPROVEMENTS, for fear that IBM will not pick up on these
enhancements, and I WILL NOT BE ABLE TO TRANSPORT ANY EXTENDED CODE
to a place that has the "ordinary" assembler only.  What can we do
about this situation?

      I am therefore urging you to do two things, if you wish to help
yourself.  Number one, if you are licensed for Assembler H Version 2
from IBM, make an effort to acquire the SLAC Assembler too.  The
reporting enhancements will quickly make your programming jobs easier
and more enjoyable, WITH THE EXISTING ASSEMBLER LANGUAGE.

      Second, please urge your IBM "Systems Engineer" to file a
"PASR" ENHANCEMENT REQUEST with the Assembler H development group,
to absorb the SLAC enhancements for Assembler H Version 2 into the
main IBM product.  THEN, EVERYONE WILL GET THE BENEFIT, and the
burden of supporting the mods for new assembler changes will be
lifted from non-IBM responsibility.  We'll also be able to use the
new language extensions and the efficient register usage, without
fear of portability problems.  IBM has a good record of responding
to A MASS of PASR REQUESTS.  If you take the time to cast your vote,
IBM will surely feel the pressure and the need for the changes.

      Meanwhile, there exists a version of source updates, now in
beta-test, that combines the unchanged SLAC Mods with the new ESA
opcodes.  This has been coordinated with further updates that
correspond to Assembler H source changes through PUT Level 8902.
Several obstacles must be cleared before I can inform licensees of
Assembler H Version 2 how to get this new set of updates.  I hope to
be able to get more info to you soon, hopefully by next month.

      Good luck in all your endeavors.  See you next month.