Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Hi All,
I am having an issue with having to put in some CICS statements in the Assembler MAcros which is leading to compilation errors.
Task Details : Currently the existing system has some Assembler macros which are called by the main programs. As part of our requirement we need to add some CICS statements in these macros. But when doing the precompilation, since the macros are not expanded, the CICS statements are giving a problem.
One option what got so far is to replace the CICS statements with appropriate DFHECALL statements. Is there any other way around ? probably more direct and simple...
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
We used to pre-translate CICS copybooks (COBOL, Assembler, etc) and store them in a separate PDS, which would then be used as part of the SYSLIB concatenation for Compilation/Assembly.
Without disclosing proprietary information, what do these Assembler Macro's do?
The problem that you're going to have is that the Assembler API's breakdown into CALL's/BALR's to DFHEIP and with that, the internal labels/fields which are used by the a given CICS/API are normally allocated (as reentrant storage) under the CICS/Assembler DSECT DFHEISTG.
If you incorporate these labels as part of the Macro itself, add the CICS/API's and translate them, you'll have duplicate labels defined after this translated Macro is copied into the given CICS/Assembler program, resulting in an Assembly RC=08 or even, 12 as they've already been defined and allocated under DFHEISTG.
When invoking these Macro's currently in CICS/Assembler, are they using reentrant storage from either DFHEISTG or an explicit CICS GETMAIN? If they're not, then you're using non-reentrant storage (IE: Program Storage) which would prohibit you from migrating to an OpenAPI/Threadsafe environment (IBM's statement of direction).
In other words, it would be unwise to incorporate pre-translated CICS/API's into an existing Macro. This is why I was curious what function these Macro's performed.
But there's something else. The CICS/Assembler translator may trip up on some Macro statements (never say never) and that could really throw a monkey wrench into the works.
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Hi Bill,
Thanks for the reply...
Before trying to give answers to your query I will just update the issue has been closed... ...
I didnt want to put too much details in my first post... Anyway.. I will try explain the details now... As you have mentioned, I cant put too much details but for the moment i hope we can consider one of the macros does a "file read". Now, in my project, we are tyring now to embed these programs and macros in a CICS environment with minimal changes. So the part where the actual file read is happening we try to replace it with the CICS (READ) statements.
A small test was done sometime back to access the feasibility. During the time it was found that the CICS statements was giving a compilation error. They tested with the DFHECALL statements which seemd to work fine. So it was mentioned as part of their finding that this could be the strategy... which we accepted.
I had posted the question here mainly out of curiosity just in case if there was some easy way around. My small brain i should say.. i was thinking there was no way it could be done... Later in the day when we tried to simulate the condition it worked fine. After some hours of discussion with clients we found out that recently ( after the initial test phase ) they have upgraded the CMNWRITE step (part of changeman compile step) to parse and expand the macros. This happens just before the CICS precompiler as a result of which the compilation went fine... So.. now the compilation issue has been solved..
Thanks Bill once again for the input/guidance/suggestions. And to others also who worked on it trying to find a solution...
Later in the day when we tried to simulate the condition it worked fine. After some hours of discussion with clients we found out that recently ( after the initial test phase ) they have upgraded the CMNWRITE step (part of changeman compile step) to parse and expand the macros. This happens just before the CICS precompiler as a result of which the compilation went fine... 
So.. now the compilation issue has been solved.. 
