Re: converting character to packed
You did not say that is what you want, but then I didn't notice which forum you wrote to, so mea culpa. Anyhow, if your computer runs VM, you don't have to write assembler at all (and if it runs MVS, make your requirement known to IBM). The instruction you want is PACK, but you must remove all punctuation first. To do that you must copy the contents of the input buffer to a temporary buffer, omitting all punctuation, even the decimal point. And then you must read the manual very carefully. It boggles the mind why this question was asked at all in this context. On 10/13/2016 04:56 PM, John McKown wrote: That's not assembler code.
Re: converting character to packed
Aw, c'm on! (Untested:) pipe ... | change /$// | change /,// | spec 1-* c2p 1 | ... Do you guys still do bubble sorts? On 10/13/2016 04:22 PM, Greg Gray wrote: I have character data in a field (ex. $13,501,298.01) and I need to remove the special characters and convert field from char to packed? Can someone give a suggestion on the best and simplest way to do it, thanks?
Re: Not Understanding 0C4-03B
It does. A 31-bit address taken from the rightmost thirty-one bits of a fullword address constant expanded to 64 bits by zero padding. (MVS has a habit of turning on the top bit in a V() constant.) The program you refer to contains so many errors that it is clear that it was written by someone with "limited understanding" of z/Architecture. On 08/30/2016 12:54 AM, esst...@juno.com wrote: I thought LLGTR ensured a proper 64Bit Address
Re: Friday puzzle: CNOP 1,2
John, the point of this puzzle is how to avoid a wasted halfword; hence Friday. Though, equally one could argue that HLASM has a design bug here: 001 dc x'00' 00010001 0003 2 ORG *,2,1 Had it done things right, it would *not* have done a halfword align followed by going to the offset (as the book says it must); it would have computed the composite required alignment and the noted that it was already there; and the generated code for this test program would have been a single byte (the DC in statement 1): 00010001 0001 2 ORG *,2,1 On 08/23/2016 07:52 AM, John Dravnieks wrote: ORG *,2,1
Re: IBM Diassembler
And if you are on VM, you can get the instruction opcodes by: LOADMOD x PROGMAP D Ix.z On 08/17/2016 05:11 PM, Joseph Reichman wrote: That's what's in memory not PDS On Aug 17, 2016, at 11:09 AM, Ed Jaffe wrote: On 8/16/2016 4:01 PM, Joseph Reichman wrote: Can the IBM disassembler be invoked By a another method then submitting a job The disassembler I use most often these days is IPCS. IP LIST address INSTR can disassemble any code found in a dump or active memory. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: better way? C language x'00' delimited string.
Oh yes, the null will be. It will be in the line below your DC where the assembler prints the expanded statement. On 06/28/2016 05:45 PM, John McKown wrote: Even after assembling, the &NULL will be in the listing not an actual x'00'.
Re: LLILF/LGFI and ad-cons
There are several problems in your snippet. First of all, V(x) is valid only in a DC instruction or literal reference (which is another way of saying DC instruction). Second, =v(x) will fail because llilf wants an absolute value. This works: extern bpx4gui larl bpx4gui or even (if I can presume a basr 14,15 following): jas 14,bpx4gui (there is even a jasl nowadays) You get warning 215 with object (that is, not goff); and the CMS loader will likely not know what to do with the external reference (haven't tried). However, if your question came from z/OS, the jas[l] will work with a program object and that is the way to do it. On 06/20/2016 04:56 PM, Steve Smith wrote: Why shouldn't this be allowed: 0182 294 LLILF R15,V(BPX4GUI) GET THE EPA ASMA044E Undefined symbol - V ASMA173S Delimiter error, expected blank - (BPX4GUI)
Re: LLILF/LGFI and ad-cons
That ORG could be extremely harmful. On 06/20/2016 05:05 PM, John McKown wrote: DCVL4(BPX4GUI) VL4 AVOIDS FULLWORD ALIGNMENT * ORG , NOT REALLY NEEDED.
Re: EQUATE symbol
Looks to me as if the equate is not in the WS_DSECT. Stick WS_DSECT DSECT in front of the EQU. On 05/30/2016 06:14 PM, michealbutz wrote: 016682774=WS_LEN EQU *-WS_DSECT 0016680 01670 2775 HRTCPRD RSECT
Re: Structured Programming Macros
PL/j was originally a three-pronged approach, which I believe makes it unique: * An XEDIT macro to format code with indents and also to uppercase the parts of an instruction that must be uppercase with HASM. * The macro library * A listing post processor for HASM listings that shows a select line of generated code with the macro instruction, but suppresses the generated code lines from the listing. PRINT ALMOSTNOGEN, if you like. I.e., an IF instruction would carry the branch code. This also meant repagination. I dropped the listing post processor since I no longer print listings.
Re: Structured Programming Macros
Ah so. You might find the macro libraries on the pipelines home page. You'll need a VM friend to convert them to IEBUPDTE format. Or you could write a piece of REXX to convert if you understand the CMS library format. It is rumoured they are now being used in the CP component; they will certainly assemble on z/OS. No chance with IFOX (the MVT 21.8 assembler). Won't get you pipes on z/OS (but there is even a request you can vote for open now). On 05/12/2016 06:18 PM, Farley, Peter x23353 wrote: Excuse me for the confusion, certainly not. What I meant to describe is that my employer uses z/OS only, with no Batchpipes product installed, so no pipe command is available in any form. I don't think I am alone in this. We do have and use the HLASM Toolkit under z/OS. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John P. Hartmann Sent: Thursday, May 12, 2016 12:05 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Structured Programming Macros Excuse me, Peter. Did you say that you don't have z/VM or z/OS, but you do have HLASM and its toolkit? The mind boggles. On 05/12/2016 05:26 PM, Farley, Peter x23353 wrote: That's lovely for those with z/VM and CMS Pipelines available, but many of us out here do not have that (wonderful) luxury. Nor do many of us even have the TSO Pipelines product available, sad to say. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John P. Hartmann Sent: Thursday, May 12, 2016 11:21 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Structured Programming Macros CMS already has a set of (different) macros in FPLGPI/FPLOM MACLIBs. http://vm.marist.edu/~pipeline/asmhll.pdf On 05/12/2016 05:12 PM, Sharuff Morsa wrote: Hi We've just received an RFE asking for us to support parenthetical grouping of logical conditions via parentheses in our Structured Programming Macros. http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=8 8038 Please read the RFE and let us know your views Thanks - Sharuff -- 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. 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.
Re: Structured Programming Macros
Excuse me, Peter. Did you say that you don't have z/VM or z/OS, but you do have HLASM and its toolkit? The mind boggles. On 05/12/2016 05:26 PM, Farley, Peter x23353 wrote: That's lovely for those with z/VM and CMS Pipelines available, but many of us out here do not have that (wonderful) luxury. Nor do many of us even have the TSO Pipelines product available, sad to say. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John P. Hartmann Sent: Thursday, May 12, 2016 11:21 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Structured Programming Macros CMS already has a set of (different) macros in FPLGPI/FPLOM MACLIBs. http://vm.marist.edu/~pipeline/asmhll.pdf On 05/12/2016 05:12 PM, Sharuff Morsa wrote: Hi We've just received an RFE asking for us to support parenthetical grouping of logical conditions via parentheses in our Structured Programming Macros. http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=8 8038 Please read the RFE and let us know your views Thanks - Sharuff -- 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.
Re: Structured Programming Macros
CMS already has a set of (different) macros in FPLGPI/FPLOM MACLIBs. http://vm.marist.edu/~pipeline/asmhll.pdf On 05/12/2016 05:12 PM, Sharuff Morsa wrote: Hi We've just received an RFE asking for us to support parenthetical grouping of logical conditions via parentheses in our Structured Programming Macros. http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=88038 Please read the RFE and let us know your views Thanks - Sharuff Sharuff Morsa IBM Hursley Labs Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: ASM0A43E Previously Defined Symbol
Actually it does, but only for literals. On 04/14/2016 09:22 PM, Mike La Martina wrote: One would think so but HLASM does not have scoped namespaces.
Re: Microprocessor Optimization Primer
Are you speaking from knowledge? Last I heard SLR was seriously discouraged. because it stalls the pipeline where the others don't. On 04/02/2016 06:43 PM, Steve Smith wrote: All the same (and they're all optimized),
Re: Csect - Dsect Question
LLGT does not zero the 64-bit mode bit (63). On 03/31/2016 11:19 PM, Ed Jaffe wrote: On 3/31/2016 2:03 PM, Tom Marchant wrote: On Wed, 30 Mar 2016 07:42:10 -0700, Ed Jaffe wrote: LOAD EPNAME==CL8'MSGTABLE'Load external message table NILH R1,X'7FFF' Turn off AMODE indicators NILL R1,X'FFFE' (same) STG R1,MsgTable Save clean table address ITYM R0. And the manual doesn't specify that the address returned is a clean 64-bit address except if it is AMODE 64. So I'd suggest replacing the NILH with LLGTR R0,R0 Haha! You're right (re: R0) and good suggestion. That's better code... (Still not a bad effort for typing HLASM code into an email. ;-) ) Another alternative would be to make MsgTable a fullword and change the AG to an AGF in the indexing/lookup code.
Re: Generating warning for AL2 expression truncation?
The contents of a storage location is a bunch of bits. Signed or not is an interpretation of the instruction accessing the location. LH will sign-expand a halfword, so it was treated as signed; LLH does not sign extend, so the same bunch of bits are now taken as unsigned. I don't wish to be labeled as a troll, but it seems to me that you have got the architecture topsy-turvy. On 03/29/2016 12:18 AM, Ngan, Robert wrote: For non-relocatable values, the range of Y values is the same as a signed halfword. In my case, I want unsigned values so I can't use Y. I ended up coding: DCAL2(expr) DS0XL(65536-expr) ASSERT: expr was not truncated -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robert Netzlof Sent: Saturday, March 26, 2016 11:59 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Generating warning for AL2 expression truncation? On 3/26/16, Steve Smith wrote: Well, it seems to me that the lack of any message on the AL2 is a bug. Correct me if I'm wrong, but I think Y-cons are signed... H type constants, yes. Y type constants, no. They are address constants, addresses cannot be negative. They date from the dawn of time, when there were 32K and smaller 360's abroad in the land. -- Bob Netzlof a/k/a Sweet Old Bob 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.
Re: Generating warning for AL2 expression truncation?
I agree it is rather strange, but at least it is consistent: 001 dc al3(x'100') 2 end It has been like this since the early sixties. Perhaps the error message on Y type address constants was added when people started generating large DOS supervisors. The answer is lost in time. As I recall things started to go bad when the supervisor was larger than 32K. Another matter is that even if the constant you assemble is small enough for the storage allocated, this is not necessarily the case once it is relocated; and the linkage editor does not complain about overflow in relocation. On 03/26/2016 05:48 PM, Steve Smith wrote: Well, it seems to me that the lack of any message on the AL2 is a bug.
Re: Generating warning for AL2 expression truncation?
Use a Y type constant. 1170 1 dc al2(7) 0002 142C 2 dc y(70700) ** ASMA072E Data item too large 3 end On 03/25/2016 11:00 PM, Ngan, Robert wrote: I had a program that was generating a (non-relocatable) value larger than 65535 within an AL2 constant, and it's being silently truncated. A (brief) look at the manuals did not reveal any options for flagging this type of error. Did I miss something, or is there no way to flag this condition? Robert Ngan CeleritiFinTech 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.
Re: length of DSECT
Aw, c'on: secretname dsect .. .. realname equ secretname,*-secretname,c'J' Why waste IBM's with this? On 03/24/2016 09:33 PM, Phil Smith III wrote: Frank Swarbrick wrote: In 2012 I started a discussion with this title. (See https://groups.google.com/forum/#!topic/mainframe-assembler/W3oDT_txPWo). As it seemed to be fairly well received, but not yet implemented, I decided to open an official RFE for it: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=85682. (Make sure you are signed on with your IBM user ID before clicking.) Please vote if it seems useful. I guess I'm not convinced of the utility of this. Defining an EQU isn't hard, and many DSECTs don't end just because the definitions end: SOME DSECT , SOME1DSA Some address SOME2DSF Length of SOME3 SOME3EQU * Character string starts here So in cases like that, it seems like this magic length would be misleading. ...phsiii
Re: Using macro to set assembler option
I'm afraid you're snookered as far as specifying the RENT option
dynamically. The ACONTROL statement, which can modify some of the
assembler options, does not include a way to set RENT on or off.
I see not reason why this should be so, particularly since the RSECT
instruction does just that, but you may not wish to wait for it to happen.
Another matter is whether you can sense that RENT was specified for the
assembly. &SYSOPT_RENT is the boolean system set symbol that indicates
this. Perhaps you can turn the problem on its head? After all, your
macro must be issued before the first section is started to get ahead of
the ESDs, right?
On 02/15/2016 06:16 PM, Swarbrick, Frank wrote:
I don't see how this might be possible, but no harm in asking. I am writing a
simple macro which can be used to insert an appropriate SETOPT line to set the
link/bind REUS attribute:
MACRO ,
&LABEL REUS &REUSOPT
AIF ('&REUSOPT' EQ 'RENT').OPTRENT
AIF ('&REUSOPT' EQ 'NONE').SETREUS
AIF ('&REUSOPT' EQ 'SERIAL').SETREUS
AIF ('&REUSOPT' EQ 'REFR').OPTRENT
MNOTE 8,'INVALID PARAMETER #1'
MNOTE 0,'VALID OPTIONS ARE SAME AS BINDER REUS OPTIONS:'
MNOTE 0,'NONE, SERIAL, RENT, REFR'
AGO .EXIT
.OPTRENT ANOP ,
* something here to turn on ASM RENT option...
.SETREUS PUNCH ' SETOPT PARM(REUS=&REUSOPT)'
.EXITMEXIT ,
MEND ,
Ideally after the .OPTRENT label there would be something that would also set
the assembler RENT option. But since a *PROCESS option must occur in the
source before any other source statements (other than ICTL) I don't see how I
can do it. Any thoughts?
Thanks,
Frank
The information contained in this electronic communication and any document
attached hereto or transmitted herewith is confidential and intended for the
exclusive use of the individual or entity named above. If the reader of this
message is not the intended recipient or the employee or agent responsible for
delivering it to the intended recipient, you are hereby notified that any
examination, use, dissemination, distribution or copying of this communication
or any part thereof is strictly prohibited. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this communication. Thank you.
Re: Return code 8 from assembler no messages
The message was issued in a section of code that was PRINT OF. Refer to the diagnostics cross reference. On 02/11/2016 11:18 PM, michelbutz wrote: Hi I am getting a rerun code 8 from ASMA90 And I don't have any assembler error messages or MNOTES the source is a number of CSECTS Thanks
Re: load logical halfword immediate
sr x,x icm x,3, address On 01/20/2016 08:21 PM, Swarbrick, Frank wrote: Is there any such instruction? This would be an instruction that would: - Be a register-and-immediate instruction, with a halfword immediate value as the source. - Load the halfword in bytes 48-63. - Load zeroes in bytes 32-47. - Leave bytes 1-31 unchanged. I can't find anything that will do exactly this. Why do I want to do exactly this? I "just do", and it bugs me I can't find a single instruction to do it. I don't want LLILL because it sets bytes 1-47 to zero. I don't want IILL because it does not set 32-47 to zeroes (yes, I could follow the IILL with IILH Rx,0). I don't want IILF because it uses a fullword immediate value instead of a halfword immediate value. I don't want LHI because it sign extends. LA could almost be used, except it allows a value of "3/4s of a halfword". LLH does exactly what I want, except that it's register-and-storage, not register-and-immediate. In the end is it really a big deal? No; but I'm obsessing about it, thinking I'm just overlooking it. Probably I'll use either LLILL or IILF, depending on if I really care about bits 1-31 (which I don't really...). Thanks for putting up with this perhaps silly inquiry! Frank The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you.
