If possible, I'd arrange for LLIHH R00,12345, unless it leads to other kludges. Otherwise, I'd code it as IIHF R00,12345*X'10000'. Your taste may differ, but it's the least unpalatable to me.
sas On Mon, Feb 27, 2017 at 8:06 PM, Ngan, Robert <[email protected]> wrote: > I've tried using SETA functions directly as instruction operands, doesn't > work. > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:[email protected]] > On Behalf Of Farley, Peter x23353 > Sent: Monday, February 27, 2017 18:56 > To: [email protected] > Subject: Re: HLASM anomaly > > Maybe a little less of a kludge using SETA arithmetic function SLL, but > maybe not: > > LCLA &IIHFARG > &IIHFARG SETA SLL(X'01', 16)+X'2345' > IIHF R00,&IIHFARG > > Being able to code the SETA argument in the instruction would be nicer: > > IIHF R00, SLL(X'01', 16)+X'2345' > > Have not tried either of those in an actual assembly yet, just guessing > here. > > Peter > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:[email protected]] > On Behalf Of Ngan, Robert > Sent: Monday, February 27, 2017 5:45 PM > To: [email protected] > Subject: Re: HLASM anomaly > > The ability to specify: > > IIHF R00,H'12345,0' > > to insert 12345 into bytes 0-1, and zero into bytes 2-3 of register would > be useful. > > Kludge for this is: > > IIHF R00,12345*65536 > > which is ugly, while: > > IIHL R00, 809041920 > > is even uglier! > > Robert Ngan > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:[email protected]] > On Behalf Of Steve Smith > Sent: Saturday, February 25, 2017 11:24 > To: [email protected] > Subject: Re: HLASM anomaly > > Exactly. HLASM is inconsistent in conflating storage types (F, H, etc.) > and data types (B, X, C), which definitely adds to the confusion. C (and > its derivatives) makes more sense in this regard. OTOH, C does have the > interesting feature that the size of ints (and shorts and > longs) and pointers can vary. PL/I might have the best model, but I > haven't done any serious work with it in many years. > > sas > > On 2/25/2017 11:42, Charles Mills wrote: > > Another way of looking at things is that X' serves two different roles > in the assembler syntax. I became aware of this when I moved from a long > career writing assembler to C++ as my primary language. > > > > X' signifies (a.) that the constant that follows is in hexadecimal > notation and (b.) a unit of storage, a byte. > > > > Thus you can say LHI 0,X'23' (role a.) or DC X'23' (roles a. and b.). > Consider the contrast with H' which is only a unit of storage. You can say > DC H'23' but you would not expect to be able to code LHI 0,H'23'. So, > similarly, you can code DC 2X'23' but not LHI 0,2X'23' > > > > FWIW and OT, C/C++ separates the two functions. 0x23 represents only the > quantity 23 base 16, not a unit of storage. You can say foo = 0x23 (roughly > analogous to LHI) but if you want to define storage, you must explicitly > state the unit of storage that you are defining: char foo = 0x23 or short > foo = 0x23 (roughly equivalent to FOO DC X'23' and FOO DC H'35' > respectively). > > > > Charles > > > > > > CSC - This is a PRIVATE message - If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the mistake > in delivery. NOTE: Regardless of content, this e-mail shall not operate to > bind the Company to any order or other contract unless pursuant to explicit > written agreement or government initiative expressly permitting the use of > e-mail for such purpose. > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > CSC - This is a PRIVATE message - If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the mistake > in delivery. NOTE: Regardless of content, this e-mail shall not operate to > bind the Company to any order or other contract unless pursuant to explicit > written agreement or government initiative expressly permitting the use of > e-mail for such purpose. > -- sas
