Re: Fair comparison C vs HLASM

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

Re: Fair comparison C vs HLASM

Here in the MVS development shop, we test and debug the code compiled at the optimization level with which it will be shipped. Doing otherwise would mask the source code bugs which have consequences only at a higher optimization level, and would also mask the compiler code generation bugs

Re: Pascal (was : comparison C vs HLASM)

> On Feb 1, 2018, at 9:13 PM, Robin Vowels wrote: > > From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> > Sent: Friday, February 02, 2018 2:16 AM > > > On 2018-02-01, at 06:55:29, Paul Raulerson wrote: >> >> It also explains one of the reasons why

Re: 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

Re: Pascal (was : comparison C vs HLASM)

From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, February 02, 2018 2:16 AM On 2018-02-01, at 06:55:29, Paul Raulerson wrote: It also explains one of the reasons why strings in C are null terminated. There were two modes of thought back in those days,

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. ;) It also explains one of the reasons why strings in C are null

Re: Fair comparison C vs HLASM

> 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

Re: Fair comparison C vs HLASM

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.

Pascal (was: Fair comparison ...)

On 2018-02-01, at 08:37:07, Pieter Wiid wrote: > > BTW, those "'Pascal' strings" were not in Wirth's specification of Pascal; > they came later with, e.g. UCSD. > > Too true -- Wirth's Pascal was useless for any real work. Character arrays > only. > UCSD Pascal had strings and async block I/O.

Re: Fair comparison C vs HLASM

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

Re: Pu

And for copies of the ESA PoOP (there are no links for those on Jim Elliot's page) there is this Library Catalog page with links to several editions of that manual: https://m.ibm.com/https/publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handheld/DOCNUM/SA22-7201/CCONTENTS HTH Peter

Re: Fair comparison C vs HLASM

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

Re: Pu

I replied to this thread over on IBM-MAIN, not realizing that it originated from this list, but here is a copy if my reply for the archives: There appear to be pretty stable PoOP links on Jim Elliot's CMOS Processor page: https://jlelliotton.blogspot.ca/p/cmos-processor-table.html HTH Peter

Re: Fair comparison C vs HLASM

On 1 February 2018 at 16:40, Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > > with a multi-stream pipeline topology ... > > That restriction is a myth. C programs can deal with multi-stream > pipe topologies. In shell that requires named pipes. > Because CMS

Re: Fair comparison C vs HLASM

On 2018-02-01, at 02:33:03, Rob van der Heij wrote: > > Indeed, traditional CMS programs all have their own logic to identify data > sources, though we can access Shared File System directories as if it were > a mini disk and have most programs handle the data there. Exploitation of > FILEDEF and

Re: Fair comparison C vs HLASM

-Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin BTW, those "'Pascal' strings" were not in Wirth's specification of Pascal; they came later with, e.g. UCSD. Too true -- Wirth's Pascal was useless for any real

Re: Fair comparison C vs HLASM

On 2018-02-01, at 06:55:29, Paul Raulerson wrote: > > It also explains one of the reasons why strings in C are null terminated. > There were two modes of thought back in those days, ‘Pascal’ strings, which > have the string size encoded in a single byte at the start of the string, and > ‘C’

Re: Fair comparison C vs HLASM

RISC comes along late in the game. Think about it: REDUCED instruction set. Reduced from what? Reduced from the standard sort of design at the time. The relative history is pretty easy to sort out: "C was originally developed by Dennis Ritchie between 1969 and 1973 at Bell Labs" --

Re: Fair comparison C vs HLASM

> The last time I used a dump to find bugs in a compiled program was about 35 > years ago. Right! I think if you are using a classic "core dump" to find logic errors in a compiled language program then you are doing something wrong. To find an error in some big table or something, sure, but

Re: Fair comparison C vs HLASM

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 two modes of thought back in those days, ‘Pascal’ strings, which

Re: Fair comparison C vs HLASM

On Wed, 31 Jan 2018 15:41:11 +, Martin Ward wrote: >gdb can analyse a core dump from an optimised program: >providing a backtrace, allowing examination of variable values >and linking executable code to source code line numbers. gdb can analyze a SYSMDUMP or SVCDUMP? It is hard to imagine

Re: Fair comparison C vs HLASM

On Wed, 31 Jan 2018 10:25:40 -0600, Mark Hammack wrote: >While it >is difficult to find C/C++ programmers coming out of college, it is all but >impossible to find anyone using or willing to train to use HLASM. But we >can find Java programmers all day long. Over the last few years, we have hired

Re: Fair comparison C vs HLASM

On 29 January 2018 at 20:16, Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2018-01-29, at 11:55:56, Seymour J Metz wrote: > > > While the DOS I/O was very device dependent, there was the DTFDI with > limited device independence. > > > Insofar as "device

Re: Fair comparison C vs HLASM

From: "Glen" To: Sent: Thursday, February 01, 2018 3:10 AM Subject: Re: Fair comparison C vs HLASM The 360/20 has MVC and CLC, but, strangely, not LR. The model 20 was not strictly of the 360 family. (You can use SR and AR instead,

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: "Keith Moe" Sent: Tuesday, January 30, 2018 11:08 AM Keith Moe wrote: One of the downsides

Re: Fair comparison C vs HLASM

From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Wednesday, January 31, 2018 3:48 PM 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

Re: Fair comparison C vs HLASM

From: "Jon Perryman" Sent: Wednesday, January 31, 2018 3:19 PM 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. The