IBM Mainframe Assembler Hints and tips

Hints and tips

The se hints and tips cam e out of a k nowle dge and te chnique s sharing se ssion at UK software ve ndor in the late e ightie s, but the y are still probably as use ful and valid today. So m any thank s to those whose contributions m ade it to this page . The y are not a tutorial as such, but are inte nde d as use ful code te chnique s that can be use d in ne w and m ainte nance de ve lopm e nt, and also unde rstanding asse m ble r that m ay be e ncounte re d whe n m aintaining le gacy code . The hints and tips on this page are groupe d into thre e are as: Proce ssing scre e n input Errors and re turn code s Lack of addre ssability

Caveat: The code samples below are intended as a starting point for your own use, it is your responsibility to ensure they works correctly in your situation. For instance, the code below assumes that 0 through 15 have been equated to R0 through R15, whereas sometimes equates are set-up so that 0 through 15 become R0 through R9, RA through RF.

Processing 3270 screen input

The re are still a lot of C IC S and IMS/DC transactions out the re that use Asse m ble r, so the first group of hints and tips are all aim e d at proce ssing and validating 3270 scre e n input.

Input area search

Suppose you want to se arch an input are a of som e k ind (e spe cially one which you e x pe ct to be m ostly blank ), and proce ss e ach non-blank characte r in it. O f course the re is the quick and dirty solution: LA LA CLI BE R14,AREA R15,LAREA 0(R14),C NEXT R14 --> Start of input area R15 = Length of input area Is this byte blank ? Yes, Ignore it No, take appropriate action R14 points to a non-blank character R14 --> Next input byte Repeat until end of input area ?

LOOP * * NEXT

LA R14,1(,R14) BCT R15,LOOP

The m ore pe rform ance m inde d m ight use TRT (translate and te st) , but this has ce rtain disadvantage s: it ne e ds a 256 byte table with a non-ze ro value in e ach byte e x ce pt the one at offse t X40, it use s R 1 and R 2 im plicitly which m ight be inconve nie nt in the conte x t of a re al program and its awk ward if the input are a is m ore than 256 byte s long be cause you have to re pe at it for e ach 256-byte chunk .

The following alte rnative m e thod of the TRT m e thod ove r the CLI loop m e thod, but without the disadvantage s. LA R14,AREA R14 --> Start of input area LA R15,LAREA R15 = Length of input area L R5,=AL1(C' ',0,0,0) R4 = Blank pad char + zero length LOOP CLCL R14,R4 Search for a non-blank character BE ALLBLANK Exit if none found * (take appropriate action - R14 points to a non-blank character) NEXT LA R14,1(,R14) Dont find same non blank again BCT R15,LOOP Continue unless that was last byte This look s pre tty sim ilar to the CLI loop, but the CLCL instruction can bypass large num be rs of blank s with e ach e x e cution. If the e ntire input are a is blank , you can only e x e cute it once anyway. The re are two points to note about the way CLCL work s in this e x am ple : 1. Be cause the se cond ope rand le ngth (in the thre e byte s of R5) is ze ro, the se cond ope rand addre ss is ignore d - R 4 doe snt e ve n have to contain a valid addre ss. (Howe ve r, be ware the high byte of R 4 will be change d anyway, e ithe r to the whole byte cle are d to binary ze ro if in 24 bit addre ssing m ode , or just the top bit if in 31 bit addre ssing m ode ! ) The instruction use s an im plie d se cond ope rand, which is the sam e le ngth as the first ope rand and consists e ntire ly of the pad characte r supplie d in the high byte of R5, in this case a blank . So the com parison stops whe n a non-blank byte is found in the first ope rand. 2. CLCL (lik e MVCL) incre m e nts the addre ss re giste rs and de cre m e nts the le ngth re giste rs as it goe s; so you can continue whe re you le ft off with only a m inor adjustm e nt to avoid finding the sam e non-blank characte r ove r and ove r again. Incide ntally, the condition code se t by CLCL is the sam e as for CLI, so if the Tak e appropriate action code use s the condition code to distinguish be twe e n value s le ss than X40 and those gre ate r than X40, it will still work .

Validating a packed decimal field

Assum e that you have a fie ld of le ngth L which is suppose d to be pack e d de cim al, and you want to find out if it re ally is. This could be done with a loop e x am ining e ach byte in turn, but the re is a m uch ne ate r m e thod, and as a bonus if the fie ld is invalid, you can te ll whe the r its a sign or a digit which is wrong, and if the fie ld is valid you can te ll whe the r it is positive or ne gative .

WORK PDVAL

XR UNPK TRT BZ BL BCT B DS DC

R2,R2 Clear TRT result register WORK(L*2+1),FIELD(L+1) Put each nibble into a separate byte WORK(L*2),PDVAL-C'0' Look for a sign BADSIGN Error if no sign found at all BADDIGIT Error if sign found before end R2,NEGATIVE Branch if negative sign found at end POSITIVE Must be positive sign at end. CL(L*2+1) 10X'00',AL1(2,1,2,1,2,2)

The above e x am ple is valid for fie lds up to 7 byte s long. For longe r fie lds, the basic te chnique is still valid but you ne e d m ore UNPK instructions at the be ginning. For e x am ple , if L is be twe e n 8 and 14, the following will do:

UNPK UNPK

WORK(15),FIELD(8) WORD+14(L*2-13),FIELD+7(L-6)

Validating a character input field.

Suppose you have a characte r input (e .g from a 3270 te rm inal) which is m e ant to only contain num e ric digits. Assum e that the fie ld is N byte s long

MVN CLC BNE FZONES DC

FZONES(N),INPUT FZONES(N),INPUT INVALID .... (N)C'0'

Nice and sim ple and avoids anothe r of those boring CLI loops. O f course it will not catch invalid characte rs in the range XFA-XFF which are nt lik e ly from a vanilla 3270, but if you have the possibility of APL k e yboards the n you will ne e d to che ck the appropriate IBM m anual to se e what the y can se nd back .

Errors and return codes

The ne x t two tips will he lp with re turn code che ck ing and forcing abe nd dum ps whe n all e lse fails.

Return code checking

This te chnique m ay be use ful if the program doe s a lot of re turn code te sting. The usual way of che ck ing re turn code s is to load and te st R 15 re turne d from a sub-routine .

LTR R15,R15 BNZ ERRRTN * * *

+4 etc bad code +0 ok code drop through to normal processing if R15 is zero

The above two instructions can be rationalise d to just the following one , but the re is no such thing as a fre e lunch so the downside is that this will only work with odd value re giste rs, and that the value in the re giste r is alte re d so it can't be re lie d on to have the original value in subse que nt proce ssing. Howe ve r it doe s save 4 byte s e ach tim e it is use d, so it is not worth doing for just one te st, but m ay be worth it if the re are a lot of te sts. Do m ak e sure you code and te st care fully, a typo of R 1 inste ad of R 15 could waste a lot of tim e . BXH R15,R15,ERRRTN

Testing two equated values are equal

In the ory it should ne ve r be ne ce ssary to have two e quate d variable s for the sam e value , but it doe s happe n from tim e to tim e so this is a sim ple way of e nsuring an asse m bly e rror if things ge t out of sync. MACRO EQUTEST &X,&Y .********************************************************************* .* Test that two values are the same. this can be useful to confirm * .* that private copy of values from operating system macros still * .* hold good. Non-matching values give an assembly error. * .********************************************************************* DC 0SL2(&X-(&Y),&Y-(&X)) MEND An e x am ple of this in use is shown be low.

TEMP ONE TWO LCBONE

* CSECT EQU 1 EQU 2 EQU 1 EQUTEST EQUTEST EQUTEST EQUTEST EQUTEST EQUTEST

ONE,ONE ONE,LCBONE ONE,TWO LCB,LCBONE FLAG1,FLAG2 FLAG3,FLAG2

this should cause an assembly error and this will be another another error

CBONE LCB FLAG1 FLAG2 FLAG3

DC EQU EQU EQU EQU END

CL1' ' *-CBONE X'0F' X'0F' X'0E'

Forcing program checks

No doubt m ost pe ople have com e across the DC halfword ze ro trick to force a program che ck at a particular point, which is ofte n done with a sim ple zap achie ve d by using AMASPZAP to alte r a load m odule on a load library. W ha t is not so we ll k nown is that it is possible to provide a variation so that the code alte rs itse lf on the first tim e it is use d and fails the se cond tim e through, or e ve n the third tim e through.

DC * *

H'0'

Fail 1st time Fail 2nd time through Fail 3nd time through Becomes XI *,X'97' 2nd time through

MVI *,0 MVI *,X'97' *

You m ight say this is a waste of tim e be cause I can ste p through m y code with a de bugge r, we ll that is true in your own te st/de ve lopm e nt e nvironm e nt, but is not m uch use in a production e nvironm e nt or whe n shipping code to run on anothe r m ainfram e .

Lack of addressability
O ne of the classic proble m s of an asse m ble r program that grows and grows ove r the ye ars is that of addre ssability. A program with a single base re giste r can addre ss from 0 to +4095 byte s, and for e ve ry additional base re giste r anothe r 4096 byte s can be addre sse d. Howe ve r in a m ainte nance situation putting in som e e x tra code can blow the lim it and the re m ay not be a spare conve nie nt re giste r to use to addre ss anothe r 4096 byte s of program . The following te chnique s m ay be found use ful in a de spe rate situation with short tim e scale s, but whe re tim e pe rm its a total code re -structure to re m ove the addre ssability issue is always the be st solution as the following trick s only put off the day of re ck oning and le ave an e ve n bigge r he adache for the ne x t pe rson doing m ainte nance . W he re tim e pe rm its and the code is going to be in use for som e tim e to com e , the n the pre fe rre d solution is always to re structure the program by bre ak ing it down into se ve ral m odule s.

Remove duplicate code

The first thing to do is se e if the program is suffe ring from having the

sam e code inline in se ve ral place s. If so the n it worth se e ing if the com m on re pe ate d can be conve rte d to be a subroutine calle d by a BAL instruction.

Save on return code checking

If the re are a lot of bits of code doing re turn code che ck ing the n the te chnique above m ay be use ful. It only save a fe w byte s but can be use ful whe re the re is a lot of re turn code che ck ing logic.

Check the literal pool

Anothe r thing to che ck whe n addre ssability has be e n e x ce e de d is the lite ral pool, as ofte n the re will be value s that are the sam e , but have be e n de fine d slightly, so a little rationalisation could save som e storage . Also the lite ral pool should be com pare d with program constants as som e one m ay have de fine d BLANKS DC CL132' ' som e whe re in the program and som e one e lse m ay have adde d som e code which use d the lite ral =CL132' ' at a late r stage , so this could save a lot of storage .

Avoid long literals with a repeated value

Having said that don't forge t that code which use s a lite ral lik e =CL132' ' to initialise an print line can be re place d with a MVI/MVC pair of instructions as be low to save 128 byte s.

MVC LINE,=CL132' ' * MVI LINE,C' ' MVC LINE+1(L'LINE-1),LINE

Generates a 132 byte literal achieve the same effect with 128 less bytes

Now you've re ad the quick and e asy hints and tips try the se ction on writing m aintainable code , or de lve a little into the world of m acros.

A Guide to DB2 Chris Date, C. J. ...

MVS Power Programming Mitchell Marx, Pen...

MVS I/O Subsystems Gilbert E. Houteka...

MVS and UNIX Richard J. Bambara...

Expert MVS/ESA JCL Mani Carathanassis...

Mainframe Assembler Programming Bill Qualls

MVS Assembler Language Kevin McQuillen, A...

MVS/TSO Barry K. Nirmal

Advanced Assembler Language and MVS ... Carmine A. Cannate...

Privacy Information

H ome | C ontac t U s Les Smith 2007-2010