EDCDSECT has so many quirks it is almost useless without significant adjustments to the output. Many of the standard control blocks are defined in such a way in assembler that it is impossible to tell that they are address fields so EDCDSECT has no choice but to define them as "array of char [4]" or "array of char [8]". Don't even try to use the results from EDCDSECT for a 4-byte field with a one-byte flag area and a 3-byte address pointer. Don't ever expect a typedef of a structure instead of a plain structure to be output.
Just because there is a tool doesn't always mean there is an effective tool. EDCDSECT might work just fine for application DSECT's with "normal" record-area data definitions (and I suspect that is its design point), but it is not too good at translating complex and often anachronisticly defined system control block fields. As I said in a prior reply, having PL/S ADATA of the control blocks (and documentation thereof) might permit a more robust translation to other languages. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Steve Smith Sent: Wednesday, September 18, 2019 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: I see a need for general conversion of mappings was Re: C headers in z/OS 2.4 XLC has a DSECT conversion utility. Check the User's Guide. Many don't like its output (probably including Peter Relson), but it can be useful, maybe as a starting point. sas On Wed, Sep 18, 2019 at 1:26 PM Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Hmm-m-m. Interesting idea, but I can see complex language-dependent > variable definition issues. Might be a real bear to implement in the > compilers in any shared-code-among-languages way. > > But again, "business" (profit) justification needed for IBM to devote > the resources. Maybe if they bought back fewer of their own shares to > prop up the share price they could afford a larger development staff . > . . yeah, right, like that's gonna happen. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Tom Marchant > Sent: Wednesday, September 18, 2019 12:18 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: I see a need for general conversion of mappings was Re: C > headers in z/OS 2.4 > > On Tue, 17 Sep 2019 22:49:10 -0300, Clark Morris wrote: > > >This is nice but when I was still doing system type coding I wanted a > >tool that converts Assembler mappings to COBOL or PL1. If people > >currently in the field would push for getting the BIT, > >BINARY-Character, the true binary, IEEE binary and decimal floating > >point usages that are in the current COBOL standard, then these > >mappings would be even more valuable. One of the justifications for > >making the effort is that COBOL should be able to access all data > >types that can be stored in DB2. I write this as someone who has > >used COBOL to get program and data set usage from SMF data. > > What if you could get the compilers to be able to process the > Assembler DSECTs? Would that be a better approach? > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an > authorized representative of the intended recipient, you are hereby > notified that any dissemination of this communication is strictly > prohibited. If you have received this communication in error, please > notify us immediately by e-mail and delete the message and any attachments > from your system. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
