See http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ASMR1020/9.9.2?SH ELF=ez2zo112&DT=20080711003624
> Am 14.12.2010 19:52, schrieb Abe F. Kornelis: > > All, > > > > with the help of John Kalinich (thanks John) I am trying to port a > > program from z390 to HLASM. > > We're encountering something strange with a self-defining term. Please > > take a look at the following piece of code: > > GBLC&HEXVAL,&DECVAL * Input, output of HEX2DEC > > LCLA&MAJOPCD,&MINOPCD * Major, minor opcodes > > ... * Other code > > MNOTE 4,'findo...@106 DECVAL=&DECVAL' **!! > > &MAJOPCD SETA (&DECVAL) > > &MINOPCD SETA -1 * No minor opcode > > > > > > In the listing it generates the following sequence (please mind line- > wraps): > > ** ASMA254I *** MNOTE *** 44277+ 4,findo...@106 DECVAL=- > 1 02-FINDO > > ** ASMA102E Arithmetic term is not self-defining term; default=0 - > FINDO/DECVAL > > ** ASMA435I Record 107 in AD.ABE.MACLIB(FINDOPCD) on volume: PERM61 > > ** ASMA013S ACTR counter exceeded - HTMLG > > ** ASMA435I Record 670 in AD.ABE.MACLIB(HTMLGEN) on volume: PERM61 > > > > > From this output I deduce the following: > > 1) The variable&DECVAL holds character string with value '-1' > > 2) Error ASMA102E indicates HLASM cannot assign this value to the SETA > > variable&MAJOPCD > > 3) The next error as indicated by the ASMA013S message occurs much > later, > > so the assignment at line 108 is executed correctly! > > > > So that leaves me with the question why the first SETA fails on a > > negative number, while the second one does accept a negative self- > defining term. > > Checking the manual only adds to the confusion: it states that > > negative self-defining terms are not acceptable. Still the assignment > > to&MINOPCD at line 108 in the macro is accepted by HLASM. > > > > Does anybody have an explanation? Am I missing something? > > > > Thanks in advance, > > Abe Kornelis. > > ========== > >
