I agree! Why would anybody want to use a data-space now we have 64-bit
storage?
On 2020-01-27 7:13 AM, Charles Mills wrote:
Well, I hear you.
A dataspace seems like overkill. How much data do you have?
My program runs 31-bit and keeps its data just in C++ "new" storage (GETMAIN storage, in
the region) and I never heard of any issue, not even an x78 ABEND where the answer was
"increase the region size." I suppose support might have come up with that answer on
their own.
I build a big table of everything I need. In other words the program logic is "read all the
input and then write all the output" not "read input, write output, read input, ..."
So everything I need is saved in memory.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Joseph Reichman
Sent: Sunday, January 26, 2020 10:51 AM
To: [email protected]
Subject: Re: Prolog code of Metal C program (register 0)
I had the sysadata downloaded as binary
And had the ebcdictoascii routine
And as you are correct for the length and offset pointers I had a bigedcpy
routine to copy it to a int to make sure it was aligned correctly
In the mainframe I store sysadata in a dataspace and Metal seems perfectly
suited for that as it has alet type pointers
I don’t need a robust runtime library that LE provides as all I am trying to do
is copy the data to data space
I like Metal with its __asm interface it kinda of reminds me of when I worked
in poughkeepsie on IOS I am referring to plx
I can only imagine what Peter Relson would be saying if he read this (“how did
they let that guy in the door”)
On Jan 26, 2020, at 12:38 PM, Charles Mills <[email protected]> wrote:
I wrote a program -- robust enough to be part of a vendor product -- that
read and processed assembler SYSADATA using LE-supported C++. I found no
problems with "flexibility." I would be curious in what way you found it
inflexible.
As is my general approach with C++, I did alpha testing on MS Visual Studio.
Although there was no intent to produce a saleable product for Windows, the
code was in fact fully functional on Windows, just lacking the niceties you
would expect in a product, such as an install package.
Windows is where there were some interesting problems to be solved. SYSADATA
makes extensive use of both EBCDIC and binary fields. You can't blindly
translate the records (as FTP would, for example) because that makes hash
out of the binary fields. And the binary fields have their own "issue" in
that they are big-endian, while Windows code is little-endian. Easy problems
to solve, and in a portable fashion using #ifdef and other tools, but
interesting problems nonetheless. Also binary RECFM=V records are not a
natural for Windows.
Want to know a great trick for dealing with endian issues in portable code?
The standard c library routine ntohl() flips an integer from big- to
little-endian on Windows, and on Z is a no-op. So just run every integer
through ntohl() and it will be right for the platform, with no performance
hit whatsoever on Z.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Joseph Reichman
Sent: Sunday, January 26, 2020 8:38 AM
To: [email protected]
Subject: Re: Prolog code of Metal C program (register 0)
I have code on windows that I use to display assembler listing. I down load
the SYSADATA and have a DLL that does reads and does various other
functions. Since I have a need for the same functionality on z/os I figured
I would use the same code.
I knew there would be differences but I figured I could use #ifdef __MVS__
for that. Originally I thought of LE but found its way to inflexible. My
code is amode 31
I have a number of functions 1) openfile - opens the sysadata and has
various pointers to various sections. There is a certain order to the
sysadata 20 external symbols precede 30 source code 36 machine code
eventually follow 30
My code would store these in dataspace.
Since my Main Program OPENFILE is reading the SYSADATA I have tried to tell
the compiler that is 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
----------------------------------------------------------------------
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
