> Robin Vowels wrote:
> And I understand that RISC processors came long after C.
The word RISC was coined long after C. The actual architecture existed long
before C.
Regards, Jon.
>> Jon wrote:
>> Programs do not access Unix files. Specifying path
>> causes a Unix address space to handle the file.
>> It communicates with the program thru the subsystem file> Paul wrote:
> Isn't the same true for JES files?
Yes
> Paul wrote:
> Spitefully, I tried a concatenation of a
On 2018-01-30, at 21:30:33, Jon Perryman wrote:
>> Steve Thompson wrote:> It causes me to wonder, why DSORG causes a problem
>> with a path or
>
>> a file. After all, unless you know something special about the
>> file, aren't all files DSORG=PS -- Physical Sequential in EXT,
>>
I believe
> Charles wrote:
> Exactly. There is no best language. There is only the best available language
> for the task at hand.
I agree that there is no best language but tasks are often solved with an
acceptable solution.
As for languages, if IBM Watson or Google (various products) makes any
On 2018-01-30, at 21:21:49, Robin Vowels wrote:
>
> The MVC and CLC instructions of the IBM /360 came years before
> Unix and C.
>
... and were available on all but the most primitive S/360 models.
I believe that nowadays the z has strlen() and strcpy() in microcode.
> And I understand that
On 2018-01-30, at 21:17:05, Robin Vowels wrote:
> On 31/01/2018 3:27 AM, Jon Perryman wrote:
>>
>>
>> Exactly my point. I suspect that the C group considered Null-terminated
>> strings cost exactly the same as fixed length fields. ...
>>
> But if you just want the length, a fixed-length
On 2018-01-30, at 18:30:40, Jon Perryman wrote:
>
> C programmers will not code HLASM for a reason. C's __ASM( ) does not handle
> HLASM line continuations. First, column 72 floats so you must compile and
> locate where to put the continuation character (change the C code and it
> might have
> Steve Thompson wrote:> It causes me to wonder, why DSORG causes a problem
> with a path or
> a file. After all, unless you know something special about the
> file, aren't all files DSORG=PS -- Physical Sequential in EXT,
> EXT2, btrfs, hfs, zfs, etc.? Ok, in hfs and zfs they are
>
> Robin Vowels wrote:
> And I understand that RISC processors came long after C.
C was developed on a PDP-11. I believe that the PDP-11 was a RISC machine. Even
so, I think it had byte instructions.
Regards, Jon.
>> Jon wrote:
>> I suspect that the C group considered
>> Null-terminated strings cost exactly the same as fixed length fields.
> Robin Vowels wrote
> But if you just want the length, a fixed-length string wins.
Length of a fixed length string is calculated by the compiler. I was
specifically
> Kirk wrote:
> C has always had support for fixed length strings (aka char[]).
Sorry if I was insulting. It was not intentional. I'm not sure how implied this
wasn't possible.
> Kirk wrote:
> XLC/C++ compiler will inline MVC, MOVS, etc inplace of memcpy() and
> strcpy(). And it knows how
On 31/01/2018 3:43 AM, Jon Perryman wrote:
Tom Marchant wrote:
Well, ok, null-terminated strings are a booby-trap
included in the C language. But it was poor programming that caused the
problems.
I'm not sure how strings could be attributed to poor programming. Unix & C were
designed and
On 31/01/2018 3:27 AM, Jon Perryman wrote:
On Tuesday, January 30, 2018 8:05 AM, Paul Gilmartin
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> Gil wrote: > Which of the two is to blame for null-terminated strings? >
(Or was it BCPL?)
Exactly my point. I suspect
On 01/30/2018 03:43 PM, Paul Gilmartin wrote:
On 2018-01-30, at 13:33:24, Jon Perryman wrote:
Jon wrote:
If you specified the attributes needed,
then you would not need concatenated datasets. > Paul wrote:
No, I have tried TRSMAIN UNPACK with a single
UNIX file as archive. FILEDATA, RECFM,
> Dave Cole wrote:
> Thank you Kirk for reposting by "The Pointlessness of handwriting
> 'efficient' code" article! Sometimes I put these things out there and
> am deafened by the silence. It's nice to know that someone is listening.
Sorry about the silence but your posts are most definitely
Exactly. There is no best language. There is only the best available language
for the task at hand.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Ze'ev Atlas
Sent: Tuesday, January 30, 2018 4:23 PM
To:
I also coded in Assembler but no longer doing that (although I could). I
totally agree that Compilers are the way to go. One can tell the C compiler
what is the minimum (oldest) hardware to compile for, and which hardware to
optimize for, and the compiled product is optimized better than any
On 1/30/18 3:42 PM, Paul Gilmartin wrote:
On 2018-01-30, at 14:15:00, Jon Perryman wrote:
FYI, Android is a modified Linux.
I've heard that; how does that play with GPL?
Android is open source...
https://source.android.com
On 2018-01-30, at 14:15:00, Jon Perryman wrote:
>
> FYI, Android is a modified Linux.
>
I've heard that; how does that play with GPL?
-- gil
> Kirk wrote:
> I'm not sure what "fair" means the context of
> comparing HLASM and C/C++. (IMO, all C programmers should be
> using C++ if possible, even if you choose to restrict
> yourself to a small subset like we do).
Google doesn't agree with C and C++ because they encourage application
On 2018-01-30, at 13:33:24, Jon Perryman wrote:
>>> Jon wrote:
>>> If you specified the attributes needed,
>>> then you would not need concatenated datasets. > Paul wrote:
>
>> No, I have tried TRSMAIN UNPACK with a single
>> UNIX file as archive. FILEDATA, RECFM, LRECL, BLKSIZE
>> all
On Tue, 30 Jan 2018 13:32:17 -0500, David Cole wrote:
>Thank you Kirk for reposting by "The Pointlessness of handwriting
>'efficient' code" article! Sometimes I put these things out there and
>am deafened by the silence. It's nice to know that someone is listening.
Yes, many of us were
On 2018-01-30, at 11:20:10, Jon Perryman wrote:
>
>> Paul wrote:
>> I can fool it by prefixing an empty temp Classic PDS.
> Open uses the first dataset in concatenated datasets to fill in the DCB. The
> second DD must be able to tolerate the DCB attributes from the first dataset.
> The classic
Thank you Kirk for reposting by "The Pointlessness of handwriting
'efficient' code" article! Sometimes I put these things out there and
am deafened by the silence. It's nice to know that someone is listening.
Dave Cole
ColeSoft Marketing
At 1/30/2018 01:07 PM, Charles Mills wrote:
Amen!
Amen!
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Kirk Wolf
Sent: Tuesday, January 30, 2018 9:34 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM
I'm not sure what "fair" means the
On 2018-01-30 12:33, Kirk Wolf wrote:
My favorite comments related to this subject came from Dave Cole on the
Assembler-List last October, which I will re-post below because it deserves
more bits of storage.
Kirk, I was sorely tempted over the last few days to dig out this gem
and post it.
> Dave wrote
> B used null terminated strings...
Isn't this another language developed around RISC processors? Byte processing
is the standard for that hardware.
Regards, Jon.
Jon,
You are wrong.
C has always had support for fixed length strings (aka char[]). The
XLC/C++ compiler will inline MVC, MOVS, etc inplace of memcpy() and
strcpy(). And it knows how to write unrolled MVC loops for a run-time
length argument variable.
Not to mention that with C++ you can
> Tom Marchant wrote:
> Well, ok, null-terminated strings are a booby-trap
> included in the C language. But it was poor programming that caused the
> problems.
I'm not sure how strings could be attributed to poor programming. Unix & C were
designed and implemented around RISC processors.
I'm not sure what "fair" means the context of comparing HLASM and C/C++.
(IMO, all C programmers should be using C++ if possible, even if you
choose to restrict yourself to a small subset like we do).
Is it fair that the z-arch has an order of magnitude more instructions than
/can be effectively
On Tuesday, January 30, 2018 8:05 AM, Paul Gilmartin
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> Gil wrote: > Which of the two is to blame for null-terminated strings? >
> (Or was it BCPL?)
Exactly my point. I suspect that the C group considered Null-terminated
> Tom Marchant wrote:
> I am not a fan of C, but I don't believe
> that any of the shortcomings> of Unix are properly attributed to the C
> language.
I'm not opposed to C. It's just another language to me except it made computers
accessible and promoted "free". I use several languages and
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of Paul Gilmartin
> Sent: 30 January 2018 16:06
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Fair comparison C vs HLASM
>
> On 2018-01-30, at 06:27:02, Tom Marchant
On Tue, 30 Jan 2018 09:05:31 -0700, Paul Gilmartin wrote:
>On 2018-01-30, at 06:27:02, Tom Marchant wrote:
>
>> On Tue, 30 Jan 2018 05:46:20 +, Jon Perryman wrote:
>>
>>> Unix lacks the robust MVS features because of the C language
>>
>> I am not a fan of C, but I don't believe that any of
On 2018-01-30, at 06:27:02, Tom Marchant wrote:
> On Tue, 30 Jan 2018 05:46:20 +, Jon Perryman wrote:
>
>> Unix lacks the robust MVS features because of the C language
>
> I am not a fan of C, but I don't believe that any of the shortcomings
> of Unix are properly attributed to the C
@Jonathan, you are of course correct. Not sure where I got the erroneous
impression.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Jonathan Scott
Sent: Tuesday, January 30, 2018 12:53 AM
To:
On Tue, 30 Jan 2018 05:46:20 +, Jon Perryman wrote:
>Unix lacks the robust MVS features because of the C language
I am not a fan of C, but I don't believe that any of the shortcomings
of Unix are properly attributed to the C language.
--
Tom Marchant
Ref: Your note of Mon, 29 Jan 2018 07:01:57 -0800
> > you can embed inline assembly instructions in C/C++ programs
>
> @Jonathan, in C programs only, not C++ -- correct?
>
> Charles
C and C++. Here's the URL of a developerWorks article on the
subject (but the URL may get split as it is very
38 matches
Mail list logo
