Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Error feedback in sequenced translators

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

0 votes


Accepted answer

Permanent link
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

0 votes


One other answer

Permanent link
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

0 votes

Comments

 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?

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,022

Question asked: Oct 10 '14, 3:19 p.m.

Question was seen: 3,991 times

Last updated: Dec 17 '14, 2:12 a.m.

Confirmation Cancel Confirm