Joined: 25 Jun 2008 Posts: 5 Location: Massachusetts
I searched and did not find any prior discussion of this topic.
Disregarding for the moment any given shop's compile & link-lib setup, what recommendations or experiences can any of you share regarding writing a single COBOL module to serve as common business logic source code for both batch and online (CICS) usage?
Examples of what I've been researching ==> COBOL/DB2 Stored Procedures, dynamic and static-linked called subroutines, and Procedure Division copybooks.
Each has advantages and drawbacks. There may be no universal "best" method, but let's see what everyone thinks...
Joined: 25 Jun 2008 Posts: 5 Location: Massachusetts
Thanks for responding.
More specifically:
1) Modules directly executable within CICS must include an EIB and Commarea as the first two 01-level Linkage Section definitions. That usually precludes being able to compile & link the modules into a batch loadlib. Have you worked around that at all?
2) DB2 Stored Procedures don't have this problem, but show poor performance if used for iterative processing (as is usually used for batch). Do you or your tech staff make use of any particular performance tuning methods?
3) Regular called modules, invoked from either batch or online, don't have either of these issues - but again, how the link-edit is implemented is key. The compiler would probably have to have two link steps, one to the batch loadlib, and another to the CICS loadlib. And I don't really even know if that's possible.
That's about as much more detail as I can provide. Can you please respond and tell me if the shared COBOL modules you're using are directly executed in batch & CICS, vs. being called?
Joined: 04 Apr 2007 Posts: 37 Location: Lisbon, Portugal
Nick North wrote:
1) Modules directly executable within CICS must include an EIB and Commarea as the first two 01-level Linkage Section definitions. That usually precludes being able to compile & link the modules into a batch loadlib. Have you worked around that at all?
Yes. If you want to use the same program in CICS and Batch, the Commarea must have a dummy field 85 bytes in length equivalent to CICS DFHEIBLK.
It must be something like this:
01 ws-dummy-area PIC X(85)
02 ws-area-to-pass PIC X(.....) --> whatever you need
In BATCH the code must be:
CALL program-name USING ws-dummy-area ws-area-to-pass
IN CICS:
CALL program-name USING DFHEIBLK ws-area-to-pass
Nick North wrote:
2) DB2 Stored Procedures don't have this problem, but show poor performance if used for iterative processing (as is usually used for batch). Do you or your tech staff make use of any particular performance tuning methods?
In DB2 they use APPTUNE to analyse the system, the plans and packages.
You can also view with detail all the package and plan activities, errors, number of executions, CPU, etc. It also gives you some advices on how to improve the performance for each statement.
Nick North wrote:
3) Regular called modules, invoked from either batch or online, don't have either of these issues - but again, how the link-edit is implemented is key. The compiler would probably have to have two link steps, one to the batch loadlib, and another to the CICS loadlib. And I don't really even know if that's possible.
That's right. You have to pass it through the CICS translator first, then through the DB2 precompiler, a compilation for BATCH, a compilation for CICS and 2 link-edit steps: one for BATCH and one for CICS.
We also use Xpediter for debugging so, I don't know if we have something more or if all these steps are really necessary, but as you have tow separate load modules it makes sense to me.
Nick North wrote:
That's about as much more detail as I can provide. Can you please respond and tell me if the shared COBOL modules you're using are directly executed in batch & CICS, vs. being called?
All these modules are executed directly under BATCH and CICS.
If you want to execute differently depending on the Environment, then you must determine first in which you are.
For that see this link: gsf-soft.com/Freeware/COB2JOB.shtml
It is a program that accesses system information.
Additionally they coded in that program:
IF CB2(21:4) = LOW-VALUES
MOVE 'BATCH' TO BATCH-OR-CICS
ELSE
IF JOB-NAME(1:4) EQUAL 'CICS' OR
JOB-NAME EQUAL 'DBDCCICS'
MOVE 'CICS ' TO BATCH-OR-CICS
ELSE
MOVE 'BATCH' TO BATCH-OR-CICS
END-IF
END-IF
DBDCCICS is IBM's default name for CICS.
I hope this will help
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Another method is to (at program start), CALL a sub-program which informs the Caller of the run-environment (Batch or CICS). This accomplished in Assembler, using the DFHAFCD Macro (TYPE=LOCATE), defaulting to R15.
If the environment is CICS, then CALL a sub-program, passing a parm-group, consisting of four elementary items -
01) The address of DFHEIBLK
02) The length of DFHEIBLK
03) The address of DFHCOMMAREA (NULL when not present)
04) The EIBCALEN (ZERO when not present)
In the caller, all you need is a 01-byte "Placeholder" to establish LINKAGE addressability, similar to an Assembler EQU * statement.
Because the length of DFHEIBLK could change, you can use reference modification with the returned-length if you need to address certain EIB fields in the caller.
Note that in LINKAGE, you only need the one-byte field to address the target data, providing you have the length.
Joined: 04 Apr 2007 Posts: 37 Location: Lisbon, Portugal
Bill O'Boyle wrote:
Another method is to (at program start), CALL a sub-program which informs the Caller of the run-environment (Batch or CICS). This accomplished in Assembler, using the DFHAFCD Macro (TYPE=LOCATE), defaulting to R15.
Bill
Hi Bill
You're right
The difference with us is that, the way by which we determine the environment is in fact a CALL to a version of the program I mentioned, which is written in COBOL.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
you can just compile a batch cobol db2 module, and cobol CALL it from a CICS module or a batch module. If CALLed by CICS insure the batch module is in a cics defined loadlib. no CICS APIs, no DFH,EIB areas.
same load module for both. why would a module want to know what environment he is in, if the functionality consists of db2 access and/or data minipulation?
more and more shops are learning to get away from this dual module stuff. no, need.
Joined: 25 Jun 2008 Posts: 5 Location: Massachusetts
Yes, a standard Cobol CALL statement to a submodule that gets linked to the batch and CICS calling programs at compile / link-edit time does seem to be the most straightforward way to do this. Still, the methods described above to build directly-executable shared modules are intriguing, and may be useful for some of the problems I'm trying to solve.
However, your post and a previous one confirms that it's possible to link the same (called) module into separate batch and CICS loadlibs. None of the shops I've worked in were configured to allow that, but I always supposed it could be done.
Somewhat unrelated to the mechanics of it all, I can envision situations where it could be helpful for a shared module to know if it is being invoked via batch or CICS. For instance, execution from batch might be able to handle some level of bulk request processing, whereas execution online would most likely be a single processing request.
That's just a potential program logic option, and not specifically what I was asking about.
Joined: 25 Jun 2008 Posts: 5 Location: Massachusetts
Yes, and thanks for clarifying that.
The wording in my latest post probably implied a static link, but of course that would really compromise what I'm trying to do - build fully modular COBOL business logic processing modules.
