You may believe whatever you want, but that won't change the facts.
There's a difference between an explanation and an unsupported assertion.
EDMK works on raw data with not attributes. Would you claim that it is not a
(packed) decimal instruction?
Shmuel (Seymour J.) Metz
From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf
of Paul Raulerson <paul.rauler...@me.com>
Sent: Sunday, February 11, 2018 7:18 PM
Subject: Re: Fair comparison C vs HLASM
I believe you are simply wrong here, PL/I has String data types and those data
types have plenty of attributes. All those functions you are talking about?
They work on the String type, not on raw data with no types or attributes, such
I think I already answered this with a more accurate definition of a string and
a bit of explanation???
> On Feb 11, 2018, at 2:49 PM, Seymour J Metz <sme...@gmu.edu> wrote:
> "special knowledge" is not relevant. The string operations in PL/I have no
> special knowledge of strings either; the compare, concatenate and copy
> regardless of the language of the text. Nor is the length fixed at compile
> String processing is older than ISPF. How are purported limitations in. e.g.,
> SuperC, relevant?
> Usually character strings are defined as strings of characters.
> MVST et al also wok with comma delimited strings and LF delimited strings.
> Shmuel (Seymour J.) Metz
> From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on
> behalf of Paul Raulerson <paul.rauler...@me.com>
> Sent: Thursday, February 8, 2018 5: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 <sme...@gmu.edu> 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
>> From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on
>> behalf of Paul Raulerson <paul.rauler...@me.com>
>> 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 <robi...@dodo.com.au> wrote:
>>> From: "Bernd Oppolzer" <bernd.oppol...@t-online.de>
>>> 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… :)