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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman Sent: Sunday, January 26, 2020 10:51 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 <charl...@mcn.org> 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:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Joseph Reichman > Sent: Sunday, January 26, 2020 8:38 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
