Re: Fair comparison C vs HLASM
The terminator is specified in R0. It could be anything - want to parse CSV data? ...chris. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Raulerson Sent: February-08-18 2:46 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM Because they don’t have any special knowledge of strings, only untyped data. And the lengths of the data they operate on is fixed and defined at compile time, not at run time. How about taking as a definition of a string any text that SuperC will search for? Or a text string in ISP? Obviously, what a string is and how it is defined varies from language to language. But usually they are not defined as binary data. Unicode excepted. Just by the way, a NULL as a string terminator seems to make sense. MVST (Move String), CLST (Compare String), SRST (Search String) are all instructs and all work with null terminated strings. Translate Extended is needed to work with Unicode without loosing one’s mind… - Paul > On Feb 8, 2018, at 2:14 PM, Seymour J Metz wrote: > > WTF? How are CLC, MVC, TR and TRT not string instructions? Or do you only > consider it to be a string if it conforms to the abominable C use of 0 as a > string delimiter? > > > -- > Shmuel (Seymour J.) Metz > https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Es > metz3&d=DwIFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=RI5WP1B > N1KW_B4HrO2twbFFOhk97OdY6xsy0TwKReZE&m=3iRL-2thHu8_n1iTzmP0Cez2237D1Qy > HUBAC3uDHYGQ&s=W9ZQBeJXKBySzvdYR8sPm3s-4CpxJwskuRzTTgn9dtA&e= > > > From: IBM Mainframe Assembler List > on behalf of Paul Raulerson > Sent: Monday, February 5, 2018 10:53 PM > To: ASSEMBLER-LIST@listserv.uga.edu > Subject: Re: Fair comparison C vs HLASM > >> On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: >> >> From: "Bernd Oppolzer" >> Sent: Tuesday, February 06, 2018 1:23 AM >> >> >>> Am 05.02.2018 um 14:42 schrieb Gord Tomlin: >>> And, BTW, the historic facts are simply wrong: >>> IBM had a C compiler for MVS (and VM, I believe) long before there >>> were string instructions on z/Arch. >> >> MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT are all string >> instructions. Most of these were available in 1965 with the S/360. >> Long before C. > > Oh my - but no. These are >character< operators, not string operators. > Much more akin to C’s memcpy() than anything else. (Yes, memcpy() was > built, in part, to emulate them.) > > CLST, CUSE, MVST, SRTST, and the later generations of these and other > instructions work on strings. Albeit, I think the definition of “string” in > this case is a little dodgy. > > I must say, it is a lot of fun to read some of these postings. I don’t > necessarily agree with a lot of them, but they are fun to read. > > z/OS as the epitome of a portable OS? HLASM more portable that C? > Does anyone really buy into that? I assumed it was a just leg pulling… > :) > > -Paul
Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)
The BEA tells where you came from. It means (going back to an earlier comment) you don't need to branch around x'00'. You can freely branch to it. It is so useful I wish it was part of the symptom dump. ...chris. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: May-12-17 9:57 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction) On 2017-05-12, at 09:56, somitcw wrote: > My favourite was to branch to an odd address. > > S0C1 and S0C7 ABENDs are common, but any S0C6 abend was mine. > If an operator called at 2:00AM, I would know who caused 3 pair of socks. > Unfortunately, IIRC the exception occurs after the branch is taken so the PSW provides no ready indication of the point of error. > Coding so that the assembler didn't flag it was needed but easy. > Something like: > > BNE ERRLABEL-CSECT-1(BASEREG) > I suppose that could be doctored so the PSW points near either the point at which the error was detected or to an error message. I think of: BZNOERROR (If RC==0.) DCX'00',C'You shouldn'ta done that.' NOERROR DS0X -- gil
Re: HLASM anomaly
HLASM correctly refers to POPs since it is not describing each instruction. POPs uses 'treated as' for describing different operands. The term 'treated as' is used frequently with different instructions and appears to accurately describe the operand. How is it ambiguous? The limits of a 16-bit signed binary integer are well known aren't they? Not sure why you have examples of unsigned. Sorry for getting defensive but I don't see a problem here, ...chris. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: February-23-17 11:05 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly On 2017-02-23, at 11:16, Paul Gilmartin wrote: > > What are the limits on the operand of AHI? What of: > > AEQU -32768 > DC Y(A) > AHI R1,AOK, I believe. > > BEQU 32767 > DC Y(B) > AHI R1,BOK, I believe. > > cEQU 65535 > DC Y(C) > AHI R1,COK ??? > > Is the operand of AHI treated modulo 2^16, or ? > So, I RTFM and learned little: * HLASM * HLASM Language Reference * Machine instruction statements * Operand entries * Immediate data HLASM Language Reference SC26-4940-06 ... Immediate data must be specified as absolute expressions whose range of values depends on the machine instruction for which the data is required. The immediate data is assembled into its binary representation. "depends on the machine instruction". So I need to read the PoOps, which says, for AHI: ... The second operand is two bytes in length and is treated as a 16-bit signed binary integer. ... Does "treated as" mean it's treated modulo size of field? Or ...? That seems to be a HLASM question, not a zSeries question, so I guess HLASM deserves an RCF; it shouldn't pass the responsibility (to PoOps?), which offers no clarification. Are the limits of a halfword operand: (-32768,32767) (0,65535) (-32768,65535) Other (specify)? Lore is not documentation. -- gil
Re: Bogus ASMA307E?
What is your initial using for r13? Is DLTABLE part of that dsect? Just checked some code and USING (X,X@END),R11 Seems to work (at least it does for dasm). A dependent using (from the active usings hdr): DBST(X'10994'),R11+X'32FC' X dsect has DBSTmDSXL(DBST$) The using is: USING DBST,DBSTm ...chris. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: December-20-16 10:15 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Bogus ASMA307E? Well, I found a work-around: *USING DLTABD,DLTABLE This fails w/ASMA307E USING DLTABD-4000,DLTABLE-4000 Trick to fool HLASM My brain exploded trying to figure out the workarounds in the old postings. On Tue, Dec 20, 2016 at 12:55 PM, Steve Smith wrote: > Well if that's the design, then the design is an ass. But I don't see > how that's the case, as the manual says otherwise. > > I finally found Robert Ngan's nearly identical post from 2 years ago, > and several older ones, too. There was one reference that implied IBM > won't fix it because of "compatibility" issues. Frankly, that sounds > like a cop-out; it would be more understandable to just say that it's > not a high enough priority yet. > > And IBM hasn't bothered to update the manual either. Sheesh. > > Google was not my friend today. Apparently, the assembler-list > archives aren't Googleable. > > Is there an outstanding SHARE req. for this? > > sas > > On Tue, Dec 20, 2016 at 11:33 AM, Paul Gilmartin > <0014e0e4a59b-dmarc- requ...@listserv.uga.edu> wrote: > >> On 2016-12-20, at 09:13, Steve Smith wrote: >> >> > I'm getting an error on a dependent USING apparently just because >> > it's >> out >> > of the normal 12-bit offset range... >> > >> > This seems to be a HLASM bug to me. >> > >> No. WAD. This has been discussed here before. (No, I don't like >> it.) >> >> -- gil >> > > > > -- > sas > -- sas
Re: converting character to packed
A modified version for current hardware. The storage references are kept to a minimum. LGHI 11,15 max digits LGHI 15,0 IP010DS0H LLGC 1,0(,8) CLIJL 1,C'0',IP020 < zero CLIJH 1,C'9',IP020 > nine NILL 1,15 clear 'F' AGR 15,1 SLLG 15,15,4 ready for next digit JCT 11,IP020 JIP030 too many chars IP020DS0H LAR8,1(,R8) next character JCT R9,IP010 IP030DS0H AGHI 15,X'C' sign STG 15,0(10) ...chris. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ze'ev Atlas Sent: October-13-16 9:41 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: converting character to packed ClassicWe sould make a.macro out of it :)ZA Sent from Yahoo Mail on Android On Thu, Oct 13, 2016 at 12:17 PM, Richard Rogers wrote: Just a stab, FWIW * R8 ==> INCOMING FIELD * R9 = INCOMING FIELD LENGTH * R10 ==> PL8 PACKED DECIMAL RESULT * R11 = WORK - DIGIT COUNT * R12 ==> CL16 - WORK - SAVE DIGITS INCMPACK DS 0H INCOMING PACK SR R11,R11 DIGIT COUNT LA R12,IPWORK IP010 DS 0H CLI 0(R8),C'0' Q-DIGIT BL IP020 N CLI 0(R8),C'9' INSURANCE - NO CHARS > '9' BH IP020 MVC 0(1,R12),0(R8) SAVE DIGIT LA R11,1(,R11) DIGIT COUNT CH R11,=H'16' Q-TOO MANY DIGITS BNL IP030 Y-HAVE ALL WE CAN HANDLE LA R12,1(,R12) NEXT DIGIT SAVE AREA IP020 DS 0H LA R8,1(,R8) NEXT INCOMING BYTE BCT R9,IP010 IP030 DS 0H BCTR R11,R0 ADJUST FOR 'EX' EX R11,IPPACK * PACK 0(8,R10),IPWORK(*-*) * R10 ==> PL16 PACKED DECIMAL * TTD - EXIT INCOMING PACK ROUTINE, EG, B CONTINUE ON IPPACK PACK 0(8,R10),IPWORK(*-*) IPWORK DS CL16 -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Greg Gray Sent: Thursday, October 13, 2016 08:22 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: converting character to packed 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?
SDSF Command Line Width RE: ASSEMBLER-LIST Digest - 23 Nov 2015 to 24 Nov 2015 (#2015-132)
The '/' key will give the pop up but it is still limited in the screen width.
Updating multi-line commands (think SLIP) in the pop up is still painful.
Not that I recommend it but panel ISFPCU41 can be changed to expand the command
line to the screen width. Add the '/ /':
$COMMAND INPUT ===>_ISFCMD/ /$SCROLL ===>_ISFS+
...chris.
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of John Walker
Sent: Wednesday, November 25, 2015 8:44 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ASSEMBLER-LIST Digest - 23 Nov 2015 to 24 Nov 2015 (#2015-132)
SDSF already can do more than one line. There is some keystroke(\ maybe) that
you can issue to get it to do the extended line. I can't remember for sure
though.
On Tue, 11/24/15, ASSEMBLER-LIST automatic digest system
wrote:
Subject: ASSEMBLER-LIST Digest - 23 Nov 2015 to 24 Nov 2015 (#2015-132)
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Date: Tuesday, November 24, 2015, 11:00 PM
ASSEMBLER-LIST Digest - 23 Nov 2015 to 24 Nov 2015
(#2015-132)
#yiv2240609433 body {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv2240609433 td {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv2240609433 p {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv2240609433 a {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;font-weight:bold;color:#3366CC;text-decoration:none;}
#yiv2240609433 h2 {
font-family:Arial, Helvetica,
sans-serif;font-size:17px;font-weight:bold;color:#CC0033;}
#yiv2240609433 h3 {
font-family:Arial, Helvetica,
sans-serif;font-size:16px;font-weight:bold;color:#3366CC;}
ASSEMBLER-LIST Digest - 23 Nov 2015 to 24 Nov 2015
(#2015-132)
Table of contents:
Change in GETMAIN
behavior (5)
ASSEMBLER-LIST Digest - 19
Nov 2015 to 20 Nov 2015 (#2015-130)
Change in GETMAIN
behavior
Re: Change in GETMAIN
behavior (11/24)
From: Tom Marchant
Re: Change in GETMAIN
behavior (11/24)
From: Elardus Engelbrecht
Re: Change in GETMAIN
behavior (11/24)
From: Robert Ngan
Re: Change in GETMAIN
behavior (11/24)
From: David de Jongh
Re: Change in GETMAIN
behavior (11/24)
From: Robert Ngan
ASSEMBLER-LIST Digest - 19
Nov 2015 to 20 Nov 2015 (#2015-130)
Re: ASSEMBLER-LIST Digest
- 19 Nov 2015 to 20 Nov 2015 (#2015-130) (11/24)
From: John Walker
Browse the ASSEMBLER-LIST
online archives.
Re: Baseless problem
Scott, A couple more suggestions. 1. add 'ieabrcx enable' (or maybe it was snipped) 2. use larl 12,const instead of lr/ahi - it will make amode 64 conversion easier 3. limit the using range to avoid base register bleed beyond the intended range 'using (const,constend),12' 4. both dataloc1/2 loctr's have no purpose when they are just followed by dsects 5. use the noprint option on the print statements to keep the listing cleaner ...chris. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Scott Ford Sent: Thursday, April 11, 2013 12:13 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Baseless problem Guys: I wanted to say a BIG THX...I got my code to assemble still working thru design and coding issues..but hey what's life without a challenge or two or three... Heres my new code..I had to changes things for obivious reasons. SAMPLE01 AMODE 31 SAMPLE01 RMODE ANY YREGS PRINT OFF SYSSTATE ARCHLVL=2 IEABRCX DEFINE PRINT ON J BEGIN PROLOG LOCTR DCC'SAMPLE01 - xxx V4.7.0.2' DCC'Assembled Date && Time: &SYSDATE &SYSTIME' DCC'Copyright (C), Identityforge,LLC' DCC'All rights reserved' CODEBG1 LOCTR BEGINDS0H SAVE (14,12) save regs coming in LRR12,R15 AHI R12,CONST-BEGIN USING CONST,R12 LRR10,R1 USING WRKDSECT,R11 base parameter map USING EVXPL,R10base parameter map L R4,EVXFLAGS exit flag address . .. . CONSTDC0D .(literal constants) LTORG DATALOC1 LOCTR DYNAMIC DSECT SAVEAREA DS18F register save area ... ... DYNSIZE EQU *-DYNAMIC length of DSECT DATALOC2 LOCTR WRKDSECT DSECT WRKSIZE EQU *-WRKDSECT length of DSECT IHAPSA IHAASCB IHAASXB IRREVXP IEANTASM IHAACEE IKJTSB LIST=YES,EXT=YES Something I would also like to comment on and share. I saw Jon Perryman's comments. I thank him for the suggestion but still as a vendor we are the ones responsible for our code. Can it be done better, of course, but there is a way to suggest that. Over the last couple of days a customer , tried to tell us that every vendor had to have their modules identify the vendor by its first three characters of a name. There were a few other ill-educated suggestions. I understand everyone has to learn but again there is a respectful way of suggesting this to a company, i.e.; vendor. I would never try to tell a vendor, i.e.; IBM, how to code or what to do, they have suggestion forms and forums for that. Maybe I am too old school.. Regards, Scott J Ford Software Engineer http://www.identityforge.com/ aka ...somewhere lost in NJ From: John McKown To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Thursday, April 11, 2013 12:54 PM Subject: Re: Baseless problem He said that he did, IIRC. On Thu, Apr 11, 2013 at 10:56 AM, Steve Comstock wrote: > On 4/11/2013 9:33 AM, Ed Jaffe wrote: >> > I wonder if the OP got his problem solved. > > -- > > Kind regards, > > -Steve Comstock > The Trainer's Friend, Inc. > > 303-355-2752 > http://www.trainersfriend.com
Re: MVC with 2nd operand length
> -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > l...@listserv.uga.edu] On Behalf Of Paul Gilmartin > Sent: Tuesday, May 22, 2012 9:33 AM > Subject: Re: MVC with 2nd operand length > > I'm moderately surprised. I'd expect that moving fields into a buffer to > build > a print line should be a common occurrence -- like strcpy(). > Or is it more common to map subfields of the buffer and let those determine > the length(s) of the MVC(s)? > > -- gil strncpy() should be preferred to strcpy() in many instances. It is more common to map the layout. The original suggestion was for a new class of assembler instruction. It does not match any of the functions listed for the assembler instructions in the reference summary and isn't really an extended mnemonic. Some people have a hard enough time differentiating between machine and assembler instructions. ...chris.
Re: Subroutines, save areas and 64bit
Not intending to hijack but there was an assertion about z/OS and services known not to save/restore registers... Was there a thread here or on IBM-MAIN that discussed R2-R13 being 'corrupted' following storage/getmain/freemain calls? I don't recall seeing any thread or experiencing it. The doc says the registers are unchanged. Now it may be they don't save/restore because they don't alter but that would not cause any problems. Just trying to understand if there is a known problem to be coding defensibly for. ...chris. From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Bill Fairchild [bi...@mainstar.com] Sent: Monday, January 17, 2011 4:46 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Subroutines, save areas and 64bit R14-R1 or all? All that the documentation says are supposed to be unaltered, assuming (1) the documentation exists and (2) it discusses altering of caller's registers. Where documented? I don't know. I don't do VSE. We were talking about VSE in this thread. The only doc I have is for z/OS. In that doc are several commonly used system services (e.g., STORAGE , previously spelled "GETMAIN/FREEMAIN) that are known not to save and restore the high-order halves of GPRs. I assume that whatever happens in z/OS system services could also happen in VSE system services, ergo my suggestion to check the VSE doc and not necessarily to trust the doc. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Binyamin Dissen Sent: Monday, January 17, 2011 4:35 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Subroutines, save areas and 64bit On Mon, 17 Jan 2011 22:08:15 + Bill Fairchild wrote: :>The z/OS system service GETMAIN does not preserve the high-order half of GP registers, and there are probably others in z/OS like that. Check the doc on each VSE system service that you use. When in doubt, save all 16 GP regs with a STMG before you call a system service and reload all of them, except for any that are supposed to be altered by the service (typically R15-R1), after you get control back from the system service. I/O macros are also system services (GET, PUT, OPEN, EXCP, etc.). Huh? Do you mean R14-R1 or all? If so,m where is this documented? :>-Original Message- :>From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tony Harminc :>Sent: Monday, January 17, 2011 2:23 PM :>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU :>Subject: Re: Subroutines, save areas and 64bit :> :>On 17 January 2011 15:18, McKown, John wrote: :>> First question: Does your code use 64-bit instructions? If not, then why would you need to worry about saving the high word of the caller's registers? If you don't modify it, then it doesn't need to be saved, does it? :> :>Just don't issue a GETMAIN... :> :>Tony H. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
Re: Parameter passing: overly cautious or properly paranoid?
Just for the sake of an example, suppose I wanted to pass the address of routine A to routine B. Routine B may need to do a BASSM to routine A (amode 31 or 64), so the 0 bit would definitely need to be set. ...chris. -Original Message- From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On Behalf Of Kirk Talman Sent: Friday, August 13, 2010 8:35 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Parameter passing: overly cautious or properly paranoid? The legacy of bit 0 meaning end of address list is back to the dark mists of the invention of the 360. But using the high bit for signaling 31-bit addressing mode is much newer. It is used by the hardware, but why would it ever be necessary (not just convenient) in a parameter list? IBM Mainframe Assembler List wrote on 08/13/2010 09:25:27 AM: > Yes, the unfortunate overloading of bit zero. Does bit zero on in a > parameter list mean a 31-bit address or the last parameter in variable > length parameter list. A real problem when you don't know how old the > legacy code is that's calling your routines. > Gary weinhold > Data Kinetics. Ltd. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
