Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Paul Raulerson
Sent: Sunday, February 11, 2018 7:18 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
I believe you are simply wrong here, PL/I has String
delimiter?
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> ________
>> From: IBM Mainframe Assembler List on
>> behalf of Paul Raulerson
>> Sent: Monday, February 5, 2018 10:53 PM
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of Paul Gilmartin
> Sent: 11 February 2018 20:55
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Fair comparison C vs HLASM
>
> On 2018-02-11, at
On 2018-02-11, at 13:46:22, Seymour J Metz wrote:
> Only in languages descended from C is there an issue with nulls in strings.
> Certainly PL/I doesn't treat NULL any differently than any other character.
>
FSVO "descended from". I suspect the convention is older than C.
Someone mentioned BC
Assembler List on behalf
of Paul Raulerson
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
ters.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Paul Raulerson
Sent: Saturday, February 10, 2018 12:14 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
On Feb 9, 2
muel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Robin Vowels
Sent: Saturday, February 10, 2018 7:25 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
From: "Seymour J
ctively.
Use it in each procedure, on entry.
From: IBM Mainframe Assembler List on behalf of Robin Vowels
Sent: Tuesday, February 6, 2018 7:30 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
From: "Seymour J Metz"
Sent
On Feb 9, 2018, at 11:11 PM, Paul Raulerson wrote:
MM- I think you misread a comment I left, which was a bit unclear, and have
rather gone off on a bit of a tangent.
When I said ‘unless the null terminates the string” in a previous comment, what
I was saying was “unless in this particular ins
From: IBM Mainframe Assembler List on behalf
of Bernd Oppolzer
Sent: Thursday, February 8, 2018 4:02 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
All the instructions mentioned below have their lengths determined at
compile
time. String instructions (and
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 abo
du/~smetz3
From: IBM Mainframe Assembler List 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, Seym
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 am
__
From: IBM Mainframe Assembler List 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 1
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
hmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Paul Raulerson
Sent: Thursday, February 8, 2018 9:03 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Strings (was : Fair comparison C vs HLASM)
Sen
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 con
nframe Assembler List on behalf
of Paul Raulerson
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 wrote:
> From: "Paul Raulerson"
> Sent
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 pu
> 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 speci
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
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 req
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
> variant
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 tha
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 compose
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 a
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
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
>
, 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
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 A
it selectively.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Robin Vowels
Sent: Tuesday, February 6, 2018 7:30 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
From:
arc-requ...@listserv.uga.edu>
Sent: Thursday, February 8, 2018 12:21 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Man or boy test (was: Fair comparison C vs HLASM)
On 2018-02-08, at 08:33:37, Bernd Oppolzer wrote:
> Am 08.02.2018 um 15:50 schrieb Martin Ward:
>>
>>
>>
On 2018-02-08, at 08:33:37, Bernd Oppolzer wrote:
> Am 08.02.2018 um 15:50 schrieb Martin Ward:
>>
>>
>> http://rosettacode.org/wiki/Man_or_boy_test
>>
> I would like to thank you very much for posting this.
> I never heard about this test before, but I am very fascinated by it,
> and I will tr
Am 08.02.2018 um 15:50 schrieb Martin Ward:
On 08/02/18 14:29, Jon Perryman wrote:
knowing full well I wouldn't waste my time learning a language that
is irrelevant to me.
I'm not sure why you think I am asking you to learn a new language.
If you are not sure what the Algol 60 code for the "ma
] on behalf
of Martin Ward [mar...@gkc.org.uk]
Sent: Thursday, February 8, 2018 9:50 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
On 08/02/18 14:29, Jon Perryman wrote:
> knowing full well I wouldn't waste my time learning a language that is
> irrelevant
On 08/02/18 14:29, Jon Perryman wrote:
knowing full well I wouldn't waste my time learning a language that is
irrelevant to me.
I'm not sure why you think I am asking you to learn a new language.
If you are not sure what the Algol 60 code for the "man or boy test"
actually does, and (not unrea
Dr. Martin Ward, could you at least show us the parts of HLASM OOP you can
figure out? You've seen OOP languages, so you should know the basics. I would
love to show how easy it is to use HLASM OOP.
> Dr. Martin Ward wrote:
> The man or boy test
Kudo's for being disrespectful without being dis
On 07/02/18 23:51, Tony Thigpen wrote:
Does GEN_MOVE, ZC_CONV, ZC_PACK31 (and other major macros) in zCOBOL
demonstrate enough of the OOP standard that our OOP evangelist here will
accept that OOP can be added to HLASM using macros such as those examples?
zCOBOL does not include any of the new
So, here is the question:
Does GEN_MOVE, ZC_CONV, ZC_PACK31 (and other major macros) in zCOBOL
demonstrate enough of the OOP standard that our OOP evangelist here will
accept that OOP can be added to HLASM using macros such as those examples?
Tony Thigpen
Martin Ward wrote on 02/07/2018 01:5
On 05/02/18 05:54, Jon Perryman wrote:
Pick any non-trivial macro (e.g. not save or return) and tell us how
you could make the functionality available / usable / maintainable in
ANY other language.
zCOBOL is an open source portable mainframe COBOL compiler.
The zcobol compiler translates COBOL
Pick any non-trivial macro (e.g. not save or return) and tell us how you
could make the functionality available / usable / maintainable in ANY
other language.
FWIW, there might be others, but one such language is PL/X. Not that that
helps you any because PL/X is not available in general.
Th
On Tue, 6 Feb 2018 01:16:46 +
Jon Perryman wrote:
> > Shmuel wrote:
> > While PL/I macros can't extract the attributes of variable > names,
> > they are in most regards as powerful as HLASM
>
> > macros and syntactically cleaner.
>
> Would anyone be interested in my CALC macro.
Yes.
: Re: Fair comparison C vs HLASM
From: "Seymour J Metz"
Sent: Saturday, February 03, 2018 4:08 AM
That deepends on what you mean by debugging facilities. PL/I has features bthat
help in debugging,
but a good debugger has a lot more.
Such as?
---
This email has been checked for viruse
On 06/02/18 03:53, Paul Raulerson wrote:
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… :)
:-) Here is another gem from Jon:
2. I don't see a difference in using MVC A,B and MEMCPY(A,B,SIZEOF(A))
Just
On 05/02/18 23:01, Jon Perryman wrote:
I agree. The C compiler is good about discarding useless code but
never bothers to issue a warning.
I am not sure which compiler you are calling "*the* C compiler",
but Clang carries out extensive static analysis including
warning about unreachable code.
From: "Paul Raulerson"
Sent: Tuesday, February 06, 2018 2:53 PM
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
From: "Jon Perryman"
Sent: Tuesday, February 06, 2018 12:16 PM
Shmuel wrote:
While PL/I macros can't extract the attributes of variable > names, they are in most regards as
powerful as HLASM
macros and syntactically cleaner.
I don't know PLI macro's so I did a little research. The deal
> 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 wer
From: "Jon Perryman"
Sent: Tuesday, February 06, 2018 6:50 AM
Back then, saving bytes was the norm and would not be considered moronic.
2 bytes could radically increase the size of your programs.
No they couldn't.
A few extra bytes added to transfer time. A few bytes was significant.
It's
From: "Jon Perryman"
Sent: Tuesday, February 06, 2018 6:27 AM
Jon Perryman wrote:>> Keith is talking about dump analysis. Show original message
Robin Vowels wrote:
Perhaps. But even if he was, the link map and assembly listing deals with that issue.
Think of optimization as a chaotic pro
From: "Charles Mills"
Sent: Tuesday, February 06, 2018 1:51 AM
My (long former) product wrote a successful S/390 commercial product in C in the ~1995 timeframe.
No problems with S/390 performance.
At that time I don't think the x86 architecture had any "string" instructions either -- strcpy(
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
> Shmuel wrote:
> While PL/I macros can't extract the attributes of variable > names, they are
> in most regards as powerful as HLASM
> macros and syntactically cleaner.
Would anyone be interested in my CALC macro. To me, the most important feature
is getting a CB address without all the USING
Nazi should be capitalized.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Smith
Sent: Monday, February 5, 2018 2:48 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM
Ah... another
> Gord Tomlin wrote:
> As I've said before, I'm not here to defend C; it has some serious > defects
> and, FWIW, Dave Cole's piece was not specific to C. HLASM has
> its place, and I continue to do the majority of my work in it (because
> of the nature of my work), but its place isn't "everywher
> Jim Mulder wrote:
> With regard to the effects of optimization on understanding
> the translation, that can be a mixed bag.
I agree. The C compiler is good about discarding useless code but never bothers
to issue a warning. You have to love those who say I'll fix it later since it
doesn't bo
meaning. The capital
> punishment is to be hanged. http://grammarist.com/usage/hanged-hung/
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Monday, February 5, 2
http://grammarist.com/usage/hanged-hung/
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Paul Gilmartin
Sent: Monday, February 5, 2018 1:53 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM
On
I accept your criticism that the syntax for inlining HLASM in C/C++ is not
good, and that my example should have used labels.
I generally use HLASM wrapper routines where I need to, and have only used
the inlining syntax a handful of times for some performance tweaking.
The context of my post was t
On 2018-02-05, at 14:29:32, Seymour J Metz wrote:
> You just mentioned a macro language whose name is the letter m followed by a
> digit.
>
No, although that's probably what he intended to do. See:
https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction
> ___
Assembler List on behalf
of Charles Mills
Sent: Monday, February 5, 2018 9:51 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
My (long former) product wrote a successful S/390 commercial product in C in
the ~1995 timeframe. No problems with S/390 performance.
At
: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
On Mon, Feb 5, 2018 at 10:26 AM, Charles Mills wrote:
> I am no expert but are there not "better" (FSVO better, of course) macro
> languages, either for C, or generic in their capabilities?
>
Good question.
: Monday, February 5, 2018 12:44 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
IMHO the biggest lack in HLASM in this sort of regard is lack of variable
scope. The support for named DSECTs got us halfway there, but symbols still
must be unique. If I want to define
> Kirk Wolf wrote:> Pity there is no z/OS port of bash that supports > local
> spawn, which is important in many cases.
Pipes and spawn go against z/OS fundamental philosophy. Spock's famous Star
Trek saying summed it up best. The needs of the business outweigh the needs of
the employee. Pipes
> Paul Gilmartin wrote:
> Who made that moronic "single byte" rule!?
Back then, saving bytes was the norm and would not be considered moronic. 2
bytes could radically increase the size of your programs. A few extra bytes
added to transfer time. A few bytes was significant.
> It's startling ho
>> Jon Perryman wrote:>> Keith is talking about dump analysis. Show original
>> message
> Robin Vowels wrote:
> Perhaps. But even if he was, the link map and assembly listing deals with
> that issue.
>> Think of optimization as a chaotic programmer.
> The last time I used a dump to find
Ref: Your note of Mon, 5 Feb 2018 17:32:28 +
Martin Ward wrote:
> Jon Perryman wrote:
> > C has functions to reduce complication. C++ and other OOP languages
> > have objects. Assembler can easily do this thru macro's and it has
> > other tools to greatly reduce complexity.
>
> How do you def
This is too funny. Profess the virtues of C and provide actual examples that
look like they prove the point but when scrutinized actually disprove it. When
I provided these type of examples, it was considered a gross exaggeration. C is
a mindset that is common. Here's the proof I'm not exagerati
uage.)
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Martin Ward
Sent: Monday, February 5, 2018 9:32 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM
On 05/02/18 15:03, Jon Perryman wrote:
>
On 05/02/18 15:03, Jon Perryman wrote:
C has functions to reduce complication. C++ and other OOP languages
have objects. Assembler can easily do this thru macro's and it has
other tools to greatly reduce complexity.
How do you define a function using assembler macros?
How do you define objects?
On Mon, Feb 5, 2018 at 10:26 AM, Charles Mills wrote:
> I am no expert but are there not "better" (FSVO better, of course) macro
> languages, either for C, or generic in their capabilities?
>
Good question. But the question is not only "do they exist", but "are they
available on z/OS (or z/VSE
On 05/02/18 16:26, Charles Mills wrote:
I am no expert but are there not "better" (FSVO better, of course)
macro languages, either for C, or generic in their capabilities?
Scheme has hygienic macros, whose expansion is guaranteed not to cause
the accidental capture of identifiers, a pattern-mat
February 5, 2018 7:32 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM
On Mon, Feb 5, 2018 at 9:03 AM, Jon Perryman wrote:
> >> Jon Perryman wrote:
> >> For large complicated problems, assembler is the language of choice.
> > Martin War
Amen. The "motivated reasoning" charge Perryman levels at virtually the
entire world is very ironic. Besides the straw-man arguments, there has
been a whole lot of comparing apples to locomotives.
sas
On Mon, Feb 5, 2018 at 9:18 AM, Tom Marchant <
00a69b48f3bb-dmarc-requ...@listserv.uga.edu
On Mon, Feb 5, 2018 at 9:03 AM, Jon Perryman wrote:
> >> Jon Perryman wrote:
> >> For large complicated problems, assembler is the language of choice.
> > Martin Ward wrote:
> > For large complicated problems a domain-specific language,
> > targeted at the problem domain, is the language of choic
DU] On
Behalf Of Charles Mills
Sent: Monday, February 5, 2018 6:52 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM
My (long former) product wrote a successful S/390 commercial product in C in
the ~1995 timeframe. No problems with S/390 performance.
At that t
>> Jon Perryman wrote:
>> For large complicated problems, assembler is the language of choice.
> Martin Ward wrote:
> For large complicated problems a domain-specific language,
> targeted at the problem domain, is the language of choice.
IBM assembler is the only language that I know which is easi
loop.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Bernd Oppolzer
Sent: Monday, February 5, 2018 6:23 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM
Am 05.02.2018 um 14:42 schrieb Gord Tomli
Am 05.02.2018 um 14:42 schrieb Gord Tomlin:
On 2018-02-05 00:54, Jon Perryman wrote:
C is NOT portable. Portable languages must be usable (acceptable) on
a platform's as it exists. zArch became a portable platform after
hardware changes added String (and other) instructions. These
instructions
On Mon, 5 Feb 2018 08:42:55 -0500, Gord Tomlin wrote:
>I'm just a
>little taken aback by the complete dismissal of the advantages of
>compiled languages in general, and I'm a bit puzzled by the vitriol.
And I'm puzzled that Mr. Perryman continues so persistently with his
crusade, adding little n
On 2018-02-05 00:54, Jon Perryman wrote:
C is NOT portable. Portable languages must be usable (acceptable) on a
platform's as it exists. zArch became a portable platform after hardware
changes added String (and other) instructions. These instructions were not
added for MVS because we lived wit
It's disappointing that so many in this group don't realize the true power of
HLASM. I respect Dave Cole's opinions but his comment "ASM has it's place"
makes me think even he has underestimated it's power.
People have played down my using DCB to show the power of HLASM. Do you realize
that th
From: IBM Mainframe Assembler List on behalf
of Robin Vowels
Sent: Friday, February 2, 2018 8:07 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
From: "Seymour J Metz"
Sent: Saturday, February 03, 2018 4:08 AM
That deepends on what you mean by
From: "Seymour J Metz"
Sent: Saturday, February 03, 2018 4:08 AM
That deepends on what you mean by debugging facilities. PL/I has features bthat help in debugging,
but a good debugger has a lot more.
Such as?
---
This email has been checked for viruses by Avast antivirus software.
https
On 2018-02-01, at 23:56:19, Jim Mulder wrote:
> ... simplistic environments
> where all of your problems can be recreated with an unoptimized compiles while
> running under an interactive debug tool. We certainly do not have that
> luxury in the operating system.
>
BTDT. Ouch! The debug opt
Vowels
Sent: Thursday, February 1, 2018 4:02 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
From: "Jon Perryman"
Sent: Thursday, February 01, 2018 1:49 AM
> On Wednesday, January 31, 2018 1:00 AM, Robin Vowels
> wrote:
>
> From: "
On 2018-02-01, at 19:11:07, Paul Raulerson wrote:
>
> Huh - may not know what I am talking about here, but any C program on a *nix
> variant, like AIX, can open and handle as many pipes as you want.
> STDIN/STDOUT is
> just one set,
>
Yes.
> and you can reopen them as many times as you want.
@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM
From: "Paul Raulerson"
Sent: Friday, February 02, 2018 12:55 AM
> And as already been noted, C was first compile on a PDP-7, which had a simple
> instruction set but
> was most definitely a CISC machine too. ;)
>
On 2018-02-02 09:45, Charles Mills wrote:
I wonder, have machines changed at all since 1989? Any new instructions on the Z?
The "problem" is fixed in C++ -- Google std:string.
or std::string
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
T
: Fair comparison C vs HLASM
Much of MVS is written in a compiled language (PL/X and its predecessors),
and I have spent the past 38 years making a living by debugging it using
dumps.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
IBM Mainframe Assembler List
nt: Friday, February 2, 2018 4:13 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM
Tests I did in 1989 and earlier showed that the null terminated strings
are up to 26 times slower that using PL/I and Pascal strings. And they
are dangerous.
I have put some tests and doc
Tests I did in 1989 and earlier showed that the null terminated strings
are up to 26 times slower that using PL/I and Pascal strings. And they
are dangerous.
I have put some tests and documentation here:
http://start.oscar-jol.com/fast-c-strings and an early message about the
problem here:
h
On 2 February 2018 at 03:11, Paul Raulerson wrote:
>
> Timing is usually done with signal and/or semaphores - or better yet with
> message
> queues. :)
>
With 'relative timing' I mean the flow of records in two parallel paths,
for example selecting a subset of the records to modify, and then com
01/31/2018 04:03:34 AM:
> From: Robin Vowels
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 01/31/2018 12:23 PM
> Subject: Re: Fair comparison C vs HLASM
> Sent by: IBM Mainframe Assembler List
>
> From: "Keith Moe"
> Sent: Tuesday, January 30, 2018 11:08 AM
>
:37 AM:
> From: Charles Mills
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 02/02/2018 01:00 AM
> Subject: Re: Fair comparison C vs HLASM
> Sent by: IBM Mainframe Assembler List
>
> > The last time I used a dump to find bugs in a compiled program was
> about 35 years
From: "Paul Raulerson"
Sent: Friday, February 02, 2018 12:55 AM
And as already been noted, C was first compile on a PDP-7, which had a simple instruction set but
was most definitely a CISC machine too. ;)
It also explains one of the reasons why strings in C are null terminated.
There were
> On Feb 1, 2018, at 1:10 PM, Paul Gilmartin
> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
>
> On 2018-02-01, at 10:28:47, Kirk Wolf wrote:
>
>> With bash you can handle multiple pipes at once without explicit named
>> pipes ("process redirection"),
>>
> Also Korn Shell. I'm awar
On 1 February 2018 at 20:10, Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> On 2018-02-01, at 10:28:47, Kirk Wolf wrote:
>
> > and you can also get a completion statusarray ("PIPESTATUS[i]")
> > from a multi-stage pipe.
> >
> Valuable indeed. I often wish for it. (How
On 2018-02-01, at 10:28:47, Kirk Wolf wrote:
> With bash you can handle multiple pipes at once without explicit named
> pipes ("process redirection"),
>
Also Korn Shell. I'm aware of the construct; I haven't mastered
it -- I try to stay in POSIX for portability. But does it have
the flexibili
With bash you can handle multiple pipes at once without explicit named
pipes ("process redirection"), and you can also get a completion status
array ("PIPESTATUS[i]") from a multi-stage pipe. Pity there is no z/OS
port of bash that supports local spawn, which is important in many cases.
Kirk
1 - 100 of 277 matches
Mail list logo
