Re: Fair comparison C vs HLASM

[Webster, Chris]

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=DwIFaQ=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E=RI5WP1B
> N1KW_B4HrO2twbFFOhk97OdY6xsy0TwKReZE=3iRL-2thHu8_n1iTzmP0Cez2237D1Qy
> HUBAC3uDHYGQ=W9ZQBeJXKBySzvdYR8sPm3s-4CpxJwskuRzTTgn9dtA=
> 
> 
> 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)

[Webster, Chris]

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: Bogus ASMA307E?

[Webster, Chris]

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

[Webster, Chris]

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)

[Webster, Chris]

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

[Webster, Chris]

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 john.archie.mck...@gmail.com
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
st...@trainersfriend.com wrote:
 On 4/11/2013 9:33 AM, Ed Jaffe wrote:

snip
 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