| Clark F Morris 2006-12-16, 6:55 pm |
| On Fri, 17 Nov 2006 12:09:50 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:ejht02$7a0$1@reader2.panix.com...
><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).
From the viewpoint of an MVS systems programmer, the change from
COBOL/VS (74 standard) to VS COBOL II release 1.4 was from serial
reusability to true reentrancy. The latter programs could be write
protected after loading. The former can only be used by one user in
an address space at a time and consistency is guaranteed on entry
either by full initialization or clean-up on exit. If the code that
is re-entrant in terms of not modifying itself, it still may be
serially reusable if it needs exclusive use of something like a queue.
Exclusive use of file resources or data base resources are normally
only for parts and not for the duration of the instantiation. VS
COBOL II also eliminated the need for such things as SERVICE RELOADs
to refresh register settings. If they finally fully multi-task in
CICS, then COBOL programs can literally have multiple concurrently
executing threads on different CPUs.
>
>
>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.)
>
>
>
>Maybe sometime when I'm in New York, over a couple of beers... :-)
>
>(That's a show people would buy tickets for :-))
>
>
>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.
>
>
|