Somewhere, maybe in a different branch of this topic, there was a
discussion about the pros and cons of replacing Assembler with Java. I
apologize for posting here if it's the wrong place, but I can't seem to
find the original discussion, and I have a question that seems relevant and
important, IMHO.
That's said, I can answer the question, for C/C++, as follows. (I pose the
question for Java, below.)
*With the *nix/C record and string models, there are these issues:*
1. Errant/unexpected/unintended pieces of binary data in a text
file/string can break something.
2. Separate functions/methods/techniques must be used to manipulate text
files/strings versus binary files/string. You *must* know what you are
dealing with up front, and/or somehow code logic for both. (I'm not sure
the latter is possible in the general case.)
3. Even with *nix/C oriented machine instructions, the need to inspect
all characters up to a target point results in performance killing cache
flooding.
4. C++ does garbage collection resulting in "pauses" in forward
progress, and working set, caching, and CPU spikes, among other things.
Let's call these attributes fragility, productivity, and efficiency,
respectively, for the convenience convenience. C has issue with these
characteristics.
As most of the readers here know, mainframe style records and strings do
not suffer from these limitation. When the length of a string/record is
known external to the data contents, you can manipulate any platform-native
data in z/OS, z/VM without it breaking due to something in the data, you
write the same code regardless of what you are dealing with, and, less
obviously, any activity that skips a cache can avoid a cache line promotion
saving processor resources.
So, my "burning" question for Java is, which, if any, of these above issues
(data fragility, coding productivity, efficiency, and garbage collections)
does Java share with C/C++.
If Java suffers from all or most of the issues, then I would say replacing
Assembler with Java is pretty much out of the question. On the other hand,
if Java suffers few or none of the above issues, it might be viable to
replace Assembler with Java (ignoring other issues, like cost, testing,
compatibility, data porting, etc.)
To sum up: Does Java use a similar record/string model to that of C/C++,
and does it do garbage collection similarly.
Thanks in advance for satisfying my curiosity.
OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.
On Sat, Apr 21, 2018 at 12:29 PM, Barry Merrill <[email protected]> wrote:
In 1975 there was a BOF, Bird's of a Feather Session on Year 2000 Concerns
at the SPRING SHARE meeting, as I recall. BOF's were spontaneous evening
meetings posted/scheduled usually that day.
Barry
Herbert W. “Barry” Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
[email protected]
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Paul Gilmartin
Sent: Friday, April 20, 2018 5:27 PM
To: [email protected]
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New
Hardware (nextgov.com)
On Fri, 20 Apr 2018 19:25:54 +0000, Lester, Bob wrote:
I agree with both you and Gil. But, how many programmers in the 60s,
70s, even 80s were thinking about Y2K? Sure, the really good ones were,
but what about the other 80%?
....and, Y2K came off without a hitch...(FSVO - "hitch") 😊
-----Original Message-----
From: IBM Mainframe Discussion List Porowski, Kenneth
Sent: Friday, April 20, 2018 1:20 PM
That was due to lack of foresight by the programmer not due to the age of
the system.
True in the sense that it affected one-year-old computers as much as older
computers running th same software.
I'm disappointed that this thread has so much focused on Y2K which I meant
only as an extreme example. Things change. Y2K was only more precisely
forseeable.
Increasing complexity of the tax code requires new logic. Inflation and
rate escalation may have made some data fields inadequate in size.
E-filing requires network interfaces and code to support them and causes
the one-day spike in workload. I gather from these fora that COBOL is not
comfortably suited to TCP/IP. IBM bet that SNA/VTAM could crush TCP/IP and
customers were the losers. IBM bet that EBCDIC could crush ASCII and
customers were the losers. And customers bet that COBOL skills would
remain in the forefront of availability.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
