🚀 go-pugleaf

Two small additions and one heartfelt plea

When SMP came out it was not the most reliable of products, a situation
compounded at least once when a fix for itself was distributed in SMP format
which provoked the error being corrected!  SMP was followed by SMP/E, a
chargeable product which invited the comment that using it would be like
paying somebody to mug you!  Since then, it seems to have evolved into a
reliable product which, like most, takes some getting used to .  The value
of the learning curve will depend on the amount to which it will be put by
the vendor.  I have heard of one very small vendor (not many left these
days) who will provide an SMP/E version of the software  ---- for an
additional $250,000.  This is on the grounds that actually starting from
scratch and getting it right, having climbed the learning curve, will be
very costly in employee time spent more productively evolving the products.
That is an interpretation of the value from the low end of the market -
doubtless others will jump in and decry such luddite attitudes.  But it is a
perception as to its usefulness in a small ISV, and just 'cos it is small
does not mean its commercial decisions are necessarily wrong, even if they
conflict with those of the larger players in the market.

Secondly, on a high level, I have always regarded assembler as a series of
instructions that manipulate data into a form that is suitable for the
(mainly) IBM macros - which do all the hard work.  A bit simplistic, but it
helps to explain why I usually code all macro invocations starting in column
7, so that they stand out in the code.  Also keeping names to 8 chars -
surely enough for a single module? - and op codes in column 10 keeps things
tidy.  Combined with the "col 7 macro", the code becomes familiar and (to a
lot of folk) acceptably easy to read.

The Plea      However you code, be CONSISTENT in the techniques.  Having
spent  a lot of time examining the code of others, it is a delight to open
up some source and recognise the "handwriting" of a consistent coder.  This
means that both debugging and maintenance will be more predictable, more
straightforward and less frustrating - and that should  be a good thing for
all parties.

I doubt if this will be the last posting on the subject

Mike Kerford-Byrnes


-----Original Message-----
From:   IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of David Cole
Sent:   02 September 2005 20:36
To:     ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject:        Re: Assembly coding guidelines

Good suggestions, Mike.

Let me also recommend my on contribution to this topic: "Considerate
Programming: Rules for Writing Quality, Maintainable, Assembler
Code". You can find a pdf at
"http://www.naspa.com/PDF/2005/0605/T0506001.pdf".

Dave Cole              REPLY TO: dbcole@colesoft.com
Cole Software          WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road    VOICE:    540-456-8536
Afton, VA 22920        FAX:      540-456-6658






At 9/2/2005 02:56 PM, MShaw wrote:
>Ing:
>
>Section 1.1 in Chapter 1 of Carmine A. Cannatello's Book _Advanced
>Assembler Language and MVS Interfaces_ has 18 good guidelines.  The
>book is hard to find, but it is excellent.
>
>Here's the URL to it on Amazon:
>
>http://www.amazon.com/exec/obidos/tg/detail/-/0471361763/qid=1125686728/sr=
1-1/ref=sr_1_1/104-6665684-2410350?v=glance&s=books
>
>Mr. Cannatello says that good Assembler language programs have these
>characteristics:
>
>1) simple, easy to understand logic
>2) use mostly simple instructions
>3) use no relative addressing (he means things like  B *+4+8+6  etc.)
>4) use subroutines
>5) use DSECTs
>6) have efficient code
>7) do not modify instructions 'on the fly'
>8) do not ABEND due to a user error
>9) request and check feedback from macro instructions
>10) use internal tables that are easily expanded
>11) issue meaningful error messages
>12) use only standard interfaces
>13) let the Assembler determine lengths
>14) have op-codes, operands, and comments aligned
>15) contain meaningful comments
>16) use meaningful labels
>17) use meaningful DS instructions
>18) do not specify BLKSIZE for files in DCBs
>
>I would also recommend that you should always include PATCH areas
>[PATCH1 DC 120S(*)] for later use with AMASPZAP, and you should add
>debugging code that is gated by conditional assembly language driven
>via a SYSPARM. This lets you test with XDC or TSO TEST  or WTO
>messages easily, then reassemble one last time without the debugging
>code when you go into production.
>
>Also, DON'T run APF authorized if you don't have to...
>
>Mike Shaw
>MVS/QuickRef Support Group
>Chicago-Soft, Ltd.