The warning is not useful for MVHHI since there's no actual sign extension. For MVGHI and MVHI, it is useful for flagging (unexpected) sign extension, specifically when the immediate value is an expression.
I remember using the -65536 trick, but for some reason I stopped using it and then forgot about it (must be getting old!). Robert Ngan CSC financial Services Group IBM Mainframe Assembler List <[email protected]> wrote on 2015/01/26 10:37:40: > From: Steve Smith <[email protected]> > To: [email protected] > Date: 2015/01/26 10:44 > Subject: Re: 8 character mnemonics > Sent by: IBM Mainframe Assembler List <[email protected]> > > For this case you can append "-65536" (or x'10000') to get the value > without a warning. > > 00000080 E544 D120 3039 00000120 210 MVHHI > FIELD1,12345 > 00000086 E544 D120 9C40 00000120 211 MVHHI > FIELD1,40000 > ** ASMA320W Immediate field operand may have incorrect sign or > magnitude > ** ASMA435I Record 71 in TSSAS.WORK.ASM(TEST3) on volume: > TSO003 > 0000008C E544 D120 9C40 00000120 212 MVHHI > FIELD1,40000-65536 > 214 > @AUTO > 00000120 00000000 00000128 215+@@TEST3D DSECT > 00000120 216 FIELD1 DS H > > Another alternative is to just specify SUPRWARN(320), or > TYPECHECK(NOMAGNITUDE) once, since it's typically not that useful anyway. > > On Fri, Jan 23, 2015 at 7:07 PM, Robert Ngan <[email protected]> wrote: > > > I've actually used both the new instruction and the macro of the same name, > > e.g. for MVHHI > > > > MACRO , > > &Label MVHHI &S,&I > > PUSH ACONTROL,PRINT,NOPRINT > > PRINT NOGEN,NOPRINT Suppress printing of following ACONTROL > > ACONTROL NOTYPECHECK Suppress annoying ASMA320W messages > > POP PRINT,NOPRINT Print following instruction > > &Label MVHHI &S,&I > > POP ACONTROL,NOPRINT > > MEND > > > > > > for values less than 32K, I just use the actual instruction: > > > > MVHHI field,12345 > > > > but for (unsigned) values 32K or larger, I use the macro to avoid that (in > > this particular situation) annoying warning: > > > > MVHHI:MAC field,40000 > > > > > > Robert Ngan > > CSC Financial Services Group > > > > IBM Mainframe Assembler List <[email protected]> wrote on > > 2015/01/22 07:42:47: > > > > > From: John McKown <[email protected]> > > > To: [email protected] > > > Date: 2015/01/22 07:46 > > > Subject: Re: 8 character mnemonics > > > Sent by: IBM Mainframe Assembler List <[email protected]> > > > > > > On Thu, Jan 22, 2015 at 4:28 AM, Sharuff Morsa3 > > <[email protected]> > > > wrote: > > > > > > > >Ain't progress wonderful? > > > > > > > > Anyone know how to stop it ? (progress that is) > > > > > > > > I would not rule out > 8 character mnemonics nor > 8 character HLASM > > > > assembler directives (not that I'm currently planning any). > > > > > > > > Because of the very large number of mnemonics and extended mnemonics > > which > > > > have been added, there are some ISPF SuperC commands to assist users in > > > > searching their source, copybook and macro libraries to see if they may > > be > > > > affected (http://www.ibm.com/support/docview.wss?uid=swg21694301). > > > > > > > > The new instructions have highlighted a problem for which we have to > > > > strike a balance. Several of the new instructions have the same > > mnemonics > > > > but differing instruction formats. Who can successfully execute > > ESA/390 > > > > vector instructions ? But some users will have these mnemonics are > > coded > > > > in their applications (anyone want to own up having some?). > > > > > > > > Should we always (100%) maintain the ability for users programs to > > > > assemble programs cleanly even though they would not execute > > successfully? > > > > How much can a product change (or evolve) without users having to make > > > > some or consider those changes ? > > > > > > > > IBM z Systems have a very long history of minimising the affect of > > changes > > > > on users - but products and their usage change over time. How > > customers > > > > use our products changes over time. Is that progress ? > > > > > > > > Sharuff > > > > > > > > Sharuff Morsa IBM Hursley Labs > > > > > > > > > > > One thing that I can think of which _might_ be of some help would be to > > > have either another program, or a PARM= value for HLASM for a source > > > validation. That is, it would act like HLASM, but would flag all opcodes > > > which are HLASM machine opcodes and which _also_ exist as members in the > > > SYSLIB concatenation. I don't know if HLASM does this already, but it > > would > > > be nice if all machine instructions supported by HLASM, but _excluded_ by > > > using the OPTABLE/MACHINE compile parameter, were only searched for as > > > macros. Lastly, it might be nice to have a program which can > > > "pseudo-compile" a source program and not only flag machine instruction > > > opcodes which exist as members in the SYSLIB concatenation, but would > > also > > > create an IEBUPDTE control deck which puts a ":MAC" on the end of the > > > opcode. The user could then edit this and use it to more easily update > > > their source. > > > > > > Just some ideas. > > > > > > > > > -- > > > > > > While a transcendent vocabulary is laudable, one must be eternally > > careful > > > so that the calculated objective of communication does not become > > ensconced > > > in obscurity. In other words, eschew obfuscation. > > > > > > 111,111,111 x 111,111,111 = 12,345,678,987,654,321 > > > > > > Maranatha! <>< > > > John McKown > > > > > > -- > sas
