For Programmers: Free Programming Magazines  


Home > Archive > Cobol > November 2006 > Re: CICS and COBOL reentrancy was Re: Further discussion on "Something has to be









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re: CICS and COBOL reentrancy was Re: Further discussion on "Something has to be
Pete Dashwood

2006-11-16, 6:55 pm


<docdwarf@panix.com> wrote in message news:ejht02$7a0$1@reader2.panix.com...
> In article <4s35prFt7q07U1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
<snip>>>[color=darkred]
>
> That depends on the code, Mr Dashwood. For a basic SEND/RECEIVE MAP
> program this is true; for a CALLed subroutine this may not be true and I
> have written apps similar to what you've described below which may
> SEND/RECEIVE different maps depending on where in the processing one is.
>
> [snip]


Yes, of course. I was keeping it simple, in line with the example you
posted. However the EIBCALEN being zero means there is no current
conversation in progress. The difference with IMS-DC is that a SPA is
automatically assigned when the code is activated so there is ALWAYS a
conversation in progress. It doesn't use a transaction code to activate code
the way that CICS does. Simply hitting Enter will cause the code to be
activated and a SPA assigned. (There are other environmental factors
associated with this and I'm not trying to cover all of them here... the
terminal is in conversational mode for example, the format decides what code
will be activated (DIF/DOF/MID/MOD), and so on. All I'm trying to do here is
explain the use of "serial reusability" in two popular IBM environments, and
how that differs from true re-entrancy).

>
> See above... I have dealt with CICS code which does this, as well.
>


Certainly, but CICS usually deals with this in a different way. The module
to be activated can be programmatically enqueued against the specific
terminal; in other environments (as noted above) the pregenerated format
decides what will be activated. Different formats for the same conversation
will activate the same code, which is re-entered as described earlier.

In CICS it is more likely that the CICS code will decide what happens next.
(Obviously, it is possible to do almost anything you want in either
environment; I'm sticking to what is considered "good practice". For CICS
this means a module per format (based on the TRANCODE), for other
environments it means a program per multi-format conversation.)


> [snip]
>
>
> I've sung this song myself, Mr Dashwood... perhaps even well enough to do
> harmony.
>


Maybe sometime when I'm in New York, over a couple of beers... :-)

(That's a show people would buy tickets for :-))

>
> Righto... thanks for the clarification.
>


No problem. Brought back happy memories of a distant time for me... :-)

Truly there is no such thing as "useless information" (there may be
knowledge you haven't found a use for, yet...).

The grounding I received in these techniques was very applicable and helpful
(without being ITSA) when it came to dealing with event driven code,
multiple instances, reusability, re-entrancy, and multi-tasking/processing
in a networked OO environment.

Pete.



Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com