Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

CICS Statements in Assembler Macros

 
Post new topic   This topic is locked: you cannot edit posts or make replies.    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler
View previous topic :: :: View next topic  
Author Message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Thu Oct 15, 2009 9:39 am    Post subject: CICS Statements in Assembler Macros
Reply with quote

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... icon_razz.gif
Back to top
View user's profile Send private message

Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Fri Oct 16, 2009 4:52 am    Post subject: Reply to: CICS Statements in Assembler Macros
Reply with quote

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.

Many things to consider....

Bill
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Fri Oct 16, 2009 12:04 pm    Post subject:
Reply with quote

Hi Bill,

Thanks for the reply... icon_smile.gif

Before trying to give answers to your query I will just update the issue has been closed... icon_razz.gif ...

I didnt want to put too much details in my first post... icon_smile.gif 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... icon_redface.gif 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... icon_cool.gif So.. now the compilation issue has been solved.. icon_biggrin.gif

Thanks Bill once again for the input/guidance/suggestions. And to others also who worked on it trying to find a solution... icon_smile.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   This topic is locked: you cannot edit posts or make replies.    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Date and time format in CICS Chandru3183 CICS 2 Sat Mar 18, 2017 12:46 pm
No new posts Asynchronous CICS Processing Question moezbud CICS 0 Mon Mar 06, 2017 6:13 pm
No new posts CICS Question RE: Browse, Readnext an... moezbud CICS 7 Sun Mar 05, 2017 5:45 am
No new posts how to send just 10 rows in a CICS sc... Megha Gupta CICS 5 Thu Feb 23, 2017 6:57 pm
No new posts Mainframe Interview Questions CICS,CO... akshathan Mainframe Interview Questions 6 Thu Feb 09, 2017 6:38 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us