Re: Strings (was : Fair comparison C vs HLASM)

[Seymour J Metz]

I already answered that question; I don't consider EBCDIC code pages to be 
intrinsically superior to most other 8-bit code pages. The reason that it's 
superior to ASCII is that ASCII is 8 bit. 


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf 
of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Friday, February 9, 2018 5:15 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Strings (was : Fair comparison C vs HLASM)

On 2018-02-09, at 15:05:19, Seymour J Metz wrote:

> Pretty much any EBCDIC code page is superior to ASCII. As to what to call 
> 8-bit code pages, I'd suggest using the term" 8-bit code page" and reserving 
> the term "ASCII" for ASCII. Especially if you find yourself having to 
> transfer data among machines using different code pages.
>
But be fair.  How would you rate IBM1148 against ISO-8859-15, not
"any EBCDIC" against "ASCII"?

-- gil

Re: Strings (was : Fair comparison C vs HLASM)

[Paul Gilmartin]

On 2018-02-09, at 15:05:19, Seymour J Metz wrote:

> Pretty much any EBCDIC code page is superior to ASCII. As to what to call 
> 8-bit code pages, I'd suggest using the term" 8-bit code page" and reserving 
> the term "ASCII" for ASCII. Especially if you find yourself having to 
> transfer data among machines using different code pages.
>  
But be fair.  How would you rate IBM1148 against ISO-8859-15, not
"any EBCDIC" against "ASCII"?

-- gil

Re: Strings (was : Fair comparison C vs HLASM)

[Seymour J Metz]

Pretty much any EBCDIC code page is superior to ASCII. As to what to call 8-bit 
code pages, I'd suggest using the term" 8-bit code page" and reserving the term 
"ASCII" for ASCII. Especially if you find yourself having to transfer data 
among machines using different code pages.

I insist on precision because of having been burnt too many times by people who 
didn't. I notice that there has been a lot of traffic here relating to code 
pages, and adding to the confusion doesn't help.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf 
of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Friday, February 9, 2018 4:34 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Strings (was : Fair comparison C vs HLASM)

On 2018-02-09, at 13:32:29, Seymour J Metz wrote:

> I would argue that EBCDIC is intrinsically superior to ASCII. I would also 
> argue that it is not intrinsically superior to, e.g., ISO-8859-15.
>
Let's not compare an apple to an orange grove.  I know you insist on precision;
that ASCII is a 7-bit character set and ISO-8859-15 is a particular 8-bit
superset of ASCII.

But what's EBCDIC?  It's at least a family of character sets.  The one that
corresponds closely to ISO-8859-15 is probably IBM1148.  But "ASCII" is widely
used casually for ASCII-based character sets.  See:

https://secure-web.cisco.com/18H7Eyco4-EbVopgucoUzCqNl8ASENBZwoFfmRl1luDdjcLo5PanBJQgArOGHUAh5wYVAH6GmXTY0-Ke6zMSstKU9DPMz90ubj6RxTkx3iNdYmUNgN0ozbPMSzLC5F8ikS27WMxMvm_kG3IZc6e_5AVMJ2DJLa7_ylMXngr_uZ8J1bLcDnmePoXqY30RY-7sZHMVZxBoQAVbULFtYEoSZv_OXyM20JfxKGeCqNw8ixfQU1FPPtwA-dxQL8x1njNN5Gd5GW3jUEFqORwXBpqOg7Yb7w6I9RFX4-pxuPhx5nnZUg9eAMLdSkwtXWYpgxjUlqyiqzXByJmOHd4V7CtINnSaqhrwBonnAidx-VWDHeFGt1kmkhLerBvbWIM7yDzpO7_LEQte6UETMcOw2DDSjXxNvjKJ6ggNINx78RE1Ul4YM-iMTDh-4bwkwKcUak1bV/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSB23S_1.1.0.14%2Fgtpa2%2Fchar51.html

Can you suggest a more convenient term encompassing the CCSIDs called "ASCII" on
that page, less cumbersome than "ASCII-based character set" or "ASCII 
compatible"
used once in that document?

-- gil

Re: Strings (was : Fair comparison C vs HLASM)

[Paul Gilmartin]

On 2018-02-09, at 13:32:29, Seymour J Metz wrote:

> I would argue that EBCDIC is intrinsically superior to ASCII. I would also 
> argue that it is not intrinsically superior to, e.g., ISO-8859-15.
>  
Let's not compare an apple to an orange grove.  I know you insist on precision;
that ASCII is a 7-bit character set and ISO-8859-15 is a particular 8-bit
superset of ASCII.

But what's EBCDIC?  It's at least a family of character sets.  The one that
corresponds closely to ISO-8859-15 is probably IBM1148.  But "ASCII" is widely
used casually for ASCII-based character sets.  See:

https://www.ibm.com/support/knowledgecenter/en/SSB23S_1.1.0.14/gtpa2/char51.html

Can you suggest a more convenient term encompassing the CCSIDs called "ASCII" on
that page, less cumbersome than "ASCII-based character set" or "ASCII 
compatible"
used once in that document?

-- gil

Re: Strings (was : Fair comparison C vs HLASM)

[Seymour J Metz]

"Question - why do you think IBM added string specific instructions if MVC is 
all one ever really needs?"

The obvious reason is that K put the implementation of varying strings in the 
language specificatand IBM wanted to be able to compile efficient code from C 
programs.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf 
of Paul Raulerson <paul.rauler...@me.com>
Sent: Thursday, February 8, 2018 9:03 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Strings (was : Fair comparison C vs HLASM)

Sent from my iPad

> On Feb 8, 2018, at 7:31 PM, Robin Vowels <robi...@dodo.com.au> wrote:
>
> From: "Paul Raulerson" <paul.rauler...@me.com>
> Sent: Friday, February 09, 2018 9:46 AM
>
>
>> Because they don’t have any special knowledge of strings,
>
> The only "special knowledge" of strings that is required is that
> a string is composed of bytes.

Seriously?  Just haven’t to disagree there. From your point of view integers 
and character data and strings and floating point values are the same thing, 
right?

Because you can move character them all the same way?

>
>> only untyped data. And the lengths of the data they operate on
>> is fixed and defined at compile time, not at run time.
>
> Whether the length of a string is known at compile time or at run time
> is irrelevant.
>
> The data is a string.  And the instruction(s) that operate on them are
> string instructions.
>

Nope, but you are as welcome to your opinion as I am to mine.  :)

Question - why do you think IBM added string specific instructions if MVC is 
all one ever really needs?


>> 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.
>
> And if the string _contains_ null characters?

Then it isn’t a string - unless of course, the null marks the end of the string.



>
>> 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…
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://secure-web.cisco.com/13rPPIJHWHTD0_-HOUBzIxH4Ml5B4YsS1Vg74hBrIJc9q1EGQ29U_ntDiDBOausCoZqo-PyuqvUSzNOcXThWegU3NB4S9NEwVgYV-Wt9gMiUuFpnEMFEGA_q-1ixYRdohozFLwLbo-KWm1bk8uQxf1jA52v3L0aeNW7UV98kURXoF3c7iJNvCxO6n08956X1qSIrgJSVTwsFsfQhgVzWFt6xp3awOVERpzyhCvvYmZMyW_63iEtSv5B54pAYT6BM8AX11YmC8zgaEXKjkXdy9ix292zY5R0cez4o3G8pIyvIhFMaZWMY_KQpDA8Yfmn5KvLmjspAv2l9ZytMxF04UjTLqJgu62D0mLglGUYG42Zz9FhnAKr4oohRibHYlS4LiyIN_V7umjsPsm9y7XUstzqUJpYEOKGtCFFlLLenBRoURHIms4c0JBE33ZsP0L9Do/https%3A%2F%2Fwww.avast.com%2Fantivirus

Re: Strings (was : Fair comparison C vs HLASM)

[Seymour J Metz]

I would argue that EBCDIC is intrinsically superior to ASCII. I would also 
argue that it is not intrinsically superior to, e.g., ISO-8859-15.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf 
of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Thursday, February 8, 2018 10:54 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Strings (was : Fair comparison C vs HLASM)

On 2018-02-08, at 20:39:07, Tony Thigpen wrote:

> Let me see if I can sum up the conversation:
>
> There is this high and mighty language call C++ to which all other languages 
> must strive to emulate, and,
> any other language that does not handle strings the exact same way as C (and 
> variants) are sub-standard.
>
> And, to prove the point, the fact that IBM added some new instructions to 
> better handle null terminated strings means that IBM realized that null 
> terminated strings are the only real way to handle strings and they were 
> fixing a major defect.
>
> No consideration to the fact that just maybe IBM added the new instructions 
> because some young language was unable to adapt to any of the existing and 
> time-proven methods of handling strings?
>
> *Major light-bulb turning on*
> It sounds like we have been spending too much time trying to talk logic with 
> a bunch of (apparent) Millennials. And everybody knows that such is 
> impossible.
>
Too much sarcasm.  It's analogous to the ASCII-EBCDIC confrontation.  I prefer
ASCII, but EBCDIC, with no intrinsic superiority, has its proponents and is
entrenched in its own dusty corner.  I don't expect IBM to abandon it soon.

Likewise, I believe that null terminated strings are an inferior technology,
but they'll long be with us.

-- gil

Re: Strings (was : Fair comparison C vs HLASM)

[Seymour J Metz]

Paul Raulerson <paul.rauler...@me.com> wrote on Friday, February 9, 2018 at 
9:43 AM

>  No, you just asked what if the string “contains” null characters. 
> The most correct answer to that is that the “string” is not then a string.

How does the presence of a valid character, ASCII code Null character, 
magically cause a string to not be a string? If you'd ever had to deal with 
start-stop terminals that require delays you'd understand how bizarre the claim 
is.


 --
 Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3




 



  








 From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf 
of Paul Raulerson <paul.rauler...@me.com>
 Sent: Friday, February 9, 2018 9:43 AM
 To: ASSEMBLER-LIST@listserv.uga.edu
 Subject: Re: Strings (was : Fair comparison C vs HLASM)





> On Feb 9, 2018, at 7:46 AM, Robin Vowels <robi...@dodo.com.au> wrote:





> From: "Paul Raulerson" <paul.rauler...@me.com>
 > Sent: Friday, February 09, 2018 1:03 PM
 >
 >
 >>> On Feb 8, 2018, at 7:31 PM, Robin Vowels <robi...@dodo.com.au> wrote:





>>> From: "Paul Raulerson" <paul.rauler...@me.com>
 >>> Sent: Friday, February 09, 2018 9:46 AM
 >>
 >>>> Because they don’t have any special knowledge of strings,
 >>
 >>> The only "special knowledge" of strings that is required is that
 >>> a string is composed of bytes.
 >
 >> Seriously?
 >
 > Seriously.
 >
 >> Just haven’t to disagree there. From your point of view integers and 
 >> character data and strings and floating point values are the same thing, 
 >> right?
 >
 > No they are not. I never said that they were.
 >
 >> Because you can move character them all the same way?
 >
 >>>> only untyped data. And the lengths of the data they operate on
 >>>> is fixed and defined at compile time, not at run time.
 >>
 >>> Whether the length of a string is known at compile time or at run time
 >>> is irrelevant.
 >>
 >>> The data is a string.  And the instruction(s) that operate on them are
 >>> string instructions.
 >
 >> Nope, but you are as welcome to your opinion as I am to mine.  :)
 >
 > You are being ridiculous.

 Okay - so you want to pick and choose which data types you will recognize, and 
yet you think I am being ridiculous?

 HLASM is not a strongly typed language, which not incidentally, is one of the 
reasons it is not suited for OOP. The introduction of strong types into HLASM 
is always resisted, which is the primary reason to not both extending it to be 
a OOP language.

 It has not definition of a STRING type.

 >
 >> Question - why do you think IBM added string specific instructions if MVC 
 >> is all one ever really needs?
 >
 > IBM can add any kind of instruction that it likes.
 > It didn't need to add specific instructions to deal with null-terminated 
 > strings.
 > MVC, MVCL are prefectly good for for handling strings.
 >
 > IBM used them in all its compilers for handling all kinds of text (i.e., 
 > strings).
 >
 >>>> 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.
 >
 > Image data consists of arbitrary characters.  It may contain null characters,
 > and plenty of them.

 This *is* ridiculous - image data, say your average JPEG, is not a string, by 
any definition I know of.  It isn’t even character data. It’s just a byte 
array, at least on an IBM Mainframe. What is difficult to accept about that?

 >>>> Just by the way, a NULL as a string terminator seems to make sense.
 >>
 >>> And if the string _contains_ null characters?
 >
 >> Then it isn’t a string - unless of course, the null marks the end of the 
 >> string.
 >
 > I just said that it didn’t.


 No, you just asked what if the string “contains” null characters. The most 
correct answer to that is that the “string” is not then a string.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

Re: Strings (was : Fair comparison C vs HLASM)

[Paul Gilmartin]

On 2018-02-09, at 07:17:05, Robin Vowels wrote:

> From: "Paul Gilmartin"
> Sent: Friday, February 09, 2018 2:54 PM
> 
>> Too much sarcasm.  It's analogous to the ASCII-EBCDIC confrontation.  I 
>> prefer
>> ASCII, but EBCDIC, with no intrinsic superiority, ...
> 
> It was superior for 80-column punch card input and output,
> and for the tabulators that were used to print the input cards and
> output cards containing the results.
>  
I carefully chose the phrase "intrinsic superiority".  That reason
is more extrinsic than intrinsic.  (I know; it's all relative.)

-- gil

Re: Strings (was : Fair comparison C vs HLASM)

[Paul Raulerson]

> On Feb 9, 2018, at 7:46 AM, Robin Vowels  wrote:
> 
> From: "Paul Raulerson" 
> Sent: Friday, February 09, 2018 1:03 PM
> 
> 
>>> On Feb 8, 2018, at 7:31 PM, Robin Vowels  wrote:
>> 
>>> From: "Paul Raulerson" 
>>> Sent: Friday, February 09, 2018 9:46 AM
>> 
 Because they don’t have any special knowledge of strings,
>> 
>>> The only "special knowledge" of strings that is required is that
>>> a string is composed of bytes.
> 
>> Seriously?
> 
> Seriously.
> 
>> Just haven’t to disagree there. From your point of view integers and 
>> character data and strings and floating point values are the same thing, 
>> right?
> 
> No they are not. I never said that they were.
> 
>> Because you can move character them all the same way?
> 
 only untyped data. And the lengths of the data they operate on
 is fixed and defined at compile time, not at run time.
>> 
>>> Whether the length of a string is known at compile time or at run time
>>> is irrelevant.
>> 
>>> The data is a string.  And the instruction(s) that operate on them are
>>> string instructions.
> 
>> Nope, but you are as welcome to your opinion as I am to mine.  :)
> 
> You are being ridiculous.

Okay - so you want to pick and choose which data types you will recognize, and 
yet you think I am being ridiculous? 

HLASM is not a strongly typed language, which not incidentally, is one of the 
reasons it is not suited for OOP. The introduction of strong types into HLASM 
is always resisted, which is the primary reason to not both extending it to be 
a OOP language. 

It has not definition of a STRING type. 

> 
>> Question - why do you think IBM added string specific instructions if MVC is 
>> all one ever really needs?
> 
> IBM can add any kind of instruction that it likes.
> It didn't need to add specific instructions to deal with null-terminated 
> strings.
> MVC, MVCL are prefectly good for for handling strings.
> 
> IBM used them in all its compilers for handling all kinds of text (i.e., 
> strings).
> 
 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.
> 
> Image data consists of arbitrary characters.  It may contain null characters,
> and plenty of them.

This *is* ridiculous - image data, say your average JPEG, is not a string, by 
any definition I know of.  It isn’t even character data. It’s just a byte 
array, at least on an IBM Mainframe. What is difficult to accept about that?

 Just by the way, a NULL as a string terminator seems to make sense.
>> 
>>> And if the string _contains_ null characters?
> 
>> Then it isn’t a string - unless of course, the null marks the end of the 
>> string.
> 
> I just said that it didn’t.


No, you just asked what if the string “contains” null characters. The most 
correct answer to that is that the “string” is not then a string. 

Unless you just happen to be using the null as a string terminator. If you are 
not, or if you are using some other character as a delimiter, then your 
“string” is not a string, just a byte array. 



> 
 MVST (Move String), CLST (Compare String), SRST (Search String)
 are all instructs and all work with null terminated strings.
> 
> 
> So?  Also will MVC, MVCL, MVI, CLC, TRT, etc
> 

So NO. Not MVC, MVI, etc. 

 Translate Extended is needed to work with Unicode without loosing one’s 
 mind…
> 
> And TRT will handle null-terminated strings, as well as other kinds. 
> 

What has that got to do with handling Unicode?  TRT has no idea at all about 
handling “null terminated strings” so far as I know. 

Let’s bring this down to a more reasonable discussion, since you seem to be way 
the heck off in left field somewhere building up a hostile attitude. 

1. Yes, you can handle strings, of any type, in HLASM. But, you have to either 
use the IBM String instructions, or you have to roll your own routines. There 
are no standard definitions of a string in the language, and no built in ways 
to handle them. This to me, makes the definition of a string there quite dodgy.

2. If you dispute that, that’s okay with me. However, I see no qualitative data 
typing in HLASM to define a string, no faculties to do common things one might
want to do with a string, and no agreement at all on what a string actually is, 
other than what one wants it to mean at any particular time. No matter *how* 
you define a string.

Example: 

strcpy() - copies one string to another at run time 
— the compiler or assembler has no idea of the size of the string
strlcpy() copies n bytes of one string to another at run time   — which 
is quite relevant. 
strlen() returns the length of a string at run time
strcmp() compares two strings at 

Re: Strings (was : Fair comparison C vs HLASM)

[Robin Vowels]

From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Friday, February 09, 2018 2:54 PM



Too much sarcasm.  It's analogous to the ASCII-EBCDIC confrontation.  I prefer
ASCII, but EBCDIC, with no intrinsic superiority,


It was superior for 80-column punch card input and output,
and for the tabulators that were used to print the input cards and
output cards containing the results.

The internal codings derived naturally from weights associated with
rows on the cards.

Of course, once the card image was stored in memory, the values could
have been converted to ASCII (and the reverse on output)
possibly using a TR instruction.  And then the problem of ASCII and EBCDIC
would not still be with us.


has its proponents and is entrenched in its own dusty corner.
 I don't expect IBM to abandon it soon.



Likewise, I believe that null terminated strings are an inferior technology,
but they'll long be with us.


Definitely inferior, as Clem Clarke pointed out.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Strings (was : Fair comparison C vs HLASM)

[Robin Vowels]

From: "Paul Raulerson" 
Sent: Friday, February 09, 2018 1:03 PM



On Feb 8, 2018, at 7:31 PM, Robin Vowels  wrote:



From: "Paul Raulerson" 
Sent: Friday, February 09, 2018 9:46 AM



Because they don’t have any special knowledge of strings,



The only "special knowledge" of strings that is required is that
a string is composed of bytes.



Seriously?


Seriously.

 Just haven’t to disagree there. From your point of view integers and character data and strings 
and floating point values are the same thing, right?


No they are not. I never said that they were.


Because you can move character them all the same way?



only untyped data. And the lengths of the data they operate on
is fixed and defined at compile time, not at run time.



Whether the length of a string is known at compile time or at run time
is irrelevant.



The data is a string.  And the instruction(s) that operate on them are
string instructions.



Nope, but you are as welcome to your opinion as I am to mine.  :)


You are being ridiculous.

Question - why do you think IBM added string specific instructions if MVC is all one ever really 
needs?


IBM can add any kind of instruction that it likes.
It didn't need to add specific instructions to deal with null-terminated 
strings.
MVC, MVCL are prefectly good for for handling strings.

IBM used them in all its compilers for handling all kinds of text (i.e., 
strings).

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.


Image data consists of arbitrary characters.  It may contain null characters,
and plenty of them.


Just by the way, a NULL as a string terminator seems to make sense.



And if the string _contains_ null characters?



Then it isn’t a string - unless of course, the null marks the end of the string.


I just said that it didn't.


MVST (Move String), CLST (Compare String), SRST (Search String)
are all instructs and all work with null terminated strings.



So?  Also will MVC, MVCL, MVI, CLC, TRT, etc


Translate Extended is needed to work with Unicode without loosing one’s mind…


And TRT will handle null-terminated strings, as well as other kinds. 



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Strings (was : Fair comparison C vs HLASM)

[Paul Gilmartin]

On 2018-02-08, at 20:39:07, Tony Thigpen wrote:

> Let me see if I can sum up the conversation:
> 
> There is this high and mighty language call C++ to which all other languages 
> must strive to emulate, and,
> any other language that does not handle strings the exact same way as C (and 
> variants) are sub-standard.
> 
> And, to prove the point, the fact that IBM added some new instructions to 
> better handle null terminated strings means that IBM realized that null 
> terminated strings are the only real way to handle strings and they were 
> fixing a major defect.
> 
> No consideration to the fact that just maybe IBM added the new instructions 
> because some young language was unable to adapt to any of the existing and 
> time-proven methods of handling strings?
> 
> *Major light-bulb turning on*
> It sounds like we have been spending too much time trying to talk logic with 
> a bunch of (apparent) Millennials. And everybody knows that such is 
> impossible.
>  
Too much sarcasm.  It's analogous to the ASCII-EBCDIC confrontation.  I prefer
ASCII, but EBCDIC, with no intrinsic superiority, has its proponents and is
entrenched in its own dusty corner.  I don't expect IBM to abandon it soon.

Likewise, I believe that null terminated strings are an inferior technology,
but they'll long be with us.

-- gil

Re: Strings (was : Fair comparison C vs HLASM)

[Tony Thigpen]

Let me see if I can sum up the conversation:

There is this high and mighty language call C++ to which all other 
languages must strive to emulate, and,
any other language that does not handle strings the exact same way as C 
(and variants) are sub-standard.


And, to prove the point, the fact that IBM added some new instructions 
to better handle null terminated strings means that IBM realized that 
null terminated strings are the only real way to handle strings and they 
were fixing a major defect.


No consideration to the fact that just maybe IBM added the new 
instructions because some young language was unable to adapt to any of 
the existing and time-proven methods of handling strings?


*Major light-bulb turning on*
It sounds like we have been spending too much time trying to talk logic 
with a bunch of (apparent) Millennials. And everybody knows that such is 
impossible.


Tony Thigpen

Paul Raulerson wrote on 02/08/2018 09:03 PM:

Sent from my iPad


On Feb 8, 2018, at 7:31 PM, Robin Vowels  wrote:

From: "Paul Raulerson" 
Sent: Friday, February 09, 2018 9:46 AM



Because they don’t have any special knowledge of strings,


The only "special knowledge" of strings that is required is that
a string is composed of bytes.


Seriously?  Just haven’t to disagree there. From your point of view integers 
and character data and strings and floating point values are the same thing, 
right?

Because you can move character them all the same way?




only untyped data. And the lengths of the data they operate on
is fixed and defined at compile time, not at run time.


Whether the length of a string is known at compile time or at run time
is irrelevant.

The data is a string.  And the instruction(s) that operate on them are
string instructions.



Nope, but you are as welcome to your opinion as I am to mine.  :)

Question - why do you think IBM added string specific instructions if MVC is 
all one ever really needs?



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.


And if the string _contains_ null characters?


Then it isn’t a string - unless of course, the null marks the end of the string.






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…



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Strings (was : Fair comparison C vs HLASM)

[Paul Raulerson]

Sent from my iPad

> On Feb 8, 2018, at 7:31 PM, Robin Vowels  wrote:
> 
> From: "Paul Raulerson" 
> Sent: Friday, February 09, 2018 9:46 AM
> 
> 
>> Because they don’t have any special knowledge of strings,
> 
> The only "special knowledge" of strings that is required is that
> a string is composed of bytes.

Seriously?  Just haven’t to disagree there. From your point of view integers 
and character data and strings and floating point values are the same thing, 
right? 

Because you can move character them all the same way?

> 
>> only untyped data. And the lengths of the data they operate on
>> is fixed and defined at compile time, not at run time.
> 
> Whether the length of a string is known at compile time or at run time
> is irrelevant.
> 
> The data is a string.  And the instruction(s) that operate on them are
> string instructions.
> 

Nope, but you are as welcome to your opinion as I am to mine.  :)

Question - why do you think IBM added string specific instructions if MVC is 
all one ever really needs?


>> 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.
> 
> And if the string _contains_ null characters?

Then it isn’t a string - unless of course, the null marks the end of the 
string. 



> 
>> 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… 
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

Re: Strings (was : Fair comparison C vs HLASM)

[Robin Vowels]

From: "Paul Raulerson" 
Sent: Friday, February 09, 2018 9:46 AM



Because they don’t have any special knowledge of strings,


The only "special knowledge" of strings that is required is that
a string is composed of bytes.


only untyped data. And the lengths of the data they operate on
is fixed and defined at compile time, not at run time.


Whether the length of a string is known at compile time or at run time
is irrelevant.

The data is a string.  And the instruction(s) that operate on them are
string instructions.

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.


And if the string _contains_ null characters?


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… 



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus