Error feedback in sequenced translators

Alex Akilov (121●16●24) | asked Oct 10 '14, 3:19 p.m.
edited Oct 10 '14, 3:23 p.m.

We are having an issue with RTC builds using a language definition with more than one translator having a SYSXMLSD defined.

Using a SYSXMLSD data set definition defined as ‘Temporary data set used for build’ and a single COBOL compile translator everything works as expected. If we add our preprocessor and postprocessor translators that include SYSXMLSD DD allocations the SYSXMLSD results do not appear in the Compilation tab in the Build results. We Publish the SYSXMLSD so we have log files show they were created and built correctly.

If we change the SYSXMLSD data set definition to ‘Existing data set used for build’ everything is produced as expected with the SYSXMLSD results in the Compilation tab in the Build results.

Can anyone explain why this won’t work for multiple temporary SYSXMLSD’s?

This is related to https://jazz.net/forum/questions/160634/reusing-dd-names-in-sequenced-translators

Accepted answer

permanent link

Liam Doherty (231●2) | answered Dec 17 '14, 2:12 a.m.
JAZZ DEVELOPER

I am wondering if this as something to do with the fact that ELAXMGUX the RDz processor that populates SYSXMLSD actually reallocates SYSPRINT under the covers. We had an issue recently where the actual COBOL output was being replaced by SYSXMLSD garbage. We changed the translator for COBOL to use DD substitution to use a different DD for sysprint. Send me a note to dohertl@au1.ibm.com and I can forward you the relevant note.

Of course this may not be the same/similar issue. In which case can you send me any information you have to my email address above.

Alex Akilov selected this answer as the correct answer

One other answer

Most liked answers|Newest answers|Oldest answers ↓

permanent link

Liam Doherty (231●2) | answered Nov 25 '14, 1:35 a.m.
JAZZ DEVELOPER

Hi Alex, can you send me screen shots of your translators, and the macrodefs.xml for them. I am particularly interested in what your pre and post processors do with SYSXMLSD. If you also send me a build log with -debug turned on so I can see the bpxwdyn allocations.

Thanks

Liam

Comments

Alex Akilov commented Dec 16 '14, 10:08 a.m.

Liam,

Sorry, didn't see your response until now. Our compile process was defined before the compiler supported various types of preprocessing. For example, even though the compiler now has coprocessing support for CICS and DB2, we continue to use our original preprocessing utilities since there are additional checks built into those analyzers that we still need to preserve and rather than unravel everything and deal with the inconsistencies of how the coprocessors work compared to the preprocessors, we left things as they worked before. We also do our own source expansion and then analyze the listing checking for various standards violations and so on. At any rate, we'd like to gather all of the analysis errors in one place (SYSXMLSD) from each step and then present the aggregate error feedback in the build result and allow you to open them against the compile listing (rather than the source member which is what the build result currently wants to open). Where would you like me to attach the macrodefs and screenshots? This forum has limited space. Should I open a work item?

It's all about the answers!

Related questions

Error feedback in sequenced translators

Accepted answer

One other answer

Your answer