I always felt that was a major deficiency in C. A language should not be
defined in terms of a particular implementation strategy.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM M
The same is true of PL/I; CHARACTER VARYING works no matter the contents. I
prefer PL/I over REXX, but REXX is always available. PL/I versus ooRexx is more
of a tossup.
Of course, my preference is to have all of them available.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂ
Are there still C only compilers these days, or is everything C/C++?
I don't believe that C has the infrastructure for record oriented files, so you
would probably need to build this on top of stream-oriented files rather than
as a file system.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/
Aren't most un*x files (if that is the proper word) streams, where there is no
length?
I would assume that C++ could have a varchar type where operators would be
defined to properly use these strings.From my recollection that isn't possible
in standard C.
On Tue, 31 Dec 2024 19:01:24 +1100 Clemen
I've long been searching for a solution that might become a defacto
standard. So far we have a collection of proprietary file formats.
But we should remember that C was originally not a general purpose
language, but a tool for a specific need.
Few would have predicted that C and its silly strings
Thompson and Ritchie were working on the PDP-7 and PDP-11 during the
formative years of C and its predecessors B and BCPL, not the x86, so they
didn't have REP MOVSB and friends available. From a Bell Labs article on
the evolution of C:
"None of BCPL, B, or C supports character data strongly in th
I cut my teeth on some English computers in the 1960's before the 360 was
invented. We programmed in PLAN on the ICL 1900 and in Intercode on the
English Electric LEOs. I am pretty sure we used to refer to them as
Assemblers.
Shell Oil in Melbourne had two LEO's. They were paper tape based machin
Over many years, I have brought up the C string problem. Both it's speed
and safety. I developed some C macros which improve the situation, however
I think that by simply introducing a new file type, say .VB like .EXE, many
speed and safety issues can be corrected relatively simply, as well
as re
I'm writing a blog post on how to use and protect GPMSERVE, when using a
REST API to get data.
The doc says you can create a profile CLASS(APPL) GPMSERVE to control
access. I've created this profile and it does not seem to be used. It
looks like anyone can get data ! I've done a RACF trace, a
On Tue, 31 Dec 2024 11:35:08 -0600, Charles Mills wrote:
>
>- Does C do mainframe record I/O? C doesn't do any I/O at all, but the
>IBM-supplied C library has excellent support for records, VSAM, pipes, etc.,
>etc. You can read all about it in the Programming Guide.
>
Can files of those formats b
It can be confusing when in some contexts one uses a file extension to
imply record structure and in others to imply the functional content of
the file --i.e., what app or family of apps should process the record
content in the file. Of course now that the extension is no longer
restricted t
On Tue, 31 Dec 2024 10:55:49 -0600, Joel Ewing wrote:
>It can be confusing when in some contexts one uses a file extension to
>imply record structure and in others to imply the functional content of
>the file --i.e., what app or family of apps should process the record
>content in the file. Of
True, I typed in haste, although my thoughts still seem valid, that most
string data was smaller back then, and we didn't have thousands of buggy
programs blindly copying data from a socket to a static buffer until one of
them contained a magic 0x00.
I was assuming that PDP 7 would have a handy eq
On Tue, 31 Dec 2024 19:01:24 +1100, Clement Clarke wrote:
>Over many years, I have brought up the C string problem. Both it's speed
>and safety. I developed some C macros which improve the situation, however
>I think that by simply introducing a new file type, say .VB like .EXE, many
>speed and
On Tue, 31 Dec 2024 19:01:24 +1100, Clement Clarke wrote:
>Charles Mills kindly suggested that C++ was the answer. However, I think
You cut me off in mid-suggestion! I was not suggesting that C++ was the
answer; I was suggesting that C++ std::string is the answer.
Let me re-phrase the sugges
Mainframe people are more likely to realize the distinction between
machine code and Assembler language because some of us have actually
been forced at some point in our life to write at the machine code
level, where you have to write in binary, octal, or hex. or decimal
numbers and manually as
On Tue, 31 Dec 2024 11:38:53 -0600, Joel Ewing \wrote:
>Mainframe people are more likely to realize the distinction between
>machine code and Assembler language because some of us have actually
>been forced at some point in our life to write at the machine code
>level, where you have to write in
In some cases it was true binary/decimal/octal hexadecimal, e.g., mulipunching
a card. In other cases there was a translation, e.g., Superzap.
The dead start panel on the CDC 6x00 machine was a set-and-forget.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִ
On Mon, 30 Dec 2024 16:37:12 -0800, Ed Jaffe
wrote:
>It's good to hear from you brutha. SHARE hasn't killed you yet... ;-)
:)
>Originally, my HZS logstream was variable size i.e., INIT(9M) and
>SIZE(12M) so I changed both values to 9M. No difference in behavior.
>Since our IPL on Sunday, we've
19 matches
Mail list logo
