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
