Re: CICS and COBOL reentrancy was Re: Further discussion on "Something has to be maintained" and lack of OO acceptance.
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 17 Nov 2006 02:01:45 +1300
<docdwarf@xxxxxxxxx> wrote in message news:ejhe49$1ba$1@xxxxxxxxxxxxxxxxxxxx
In article <4s2r11Ftma0fU1@xxxxxxxxxxxxxxxxxx>,
Pete Dashwood <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
[snip]
This
usually held a "progress indicator" which told the executable code where
to
resume processing... the code was always entered at the top, but
immediately
branched, based on the progress indicator, which was set immediately
before
dequeuing. Calling this re-entrance was a bit of a liberty but I uiess you
can argue the same code was being entered again :-). CICS was a little bit
different in that the next code to execute could be enqueued against the
terminal, so the "progress indicator" wasn't really necessary. (I have
seen
CICS programs written both ways).
What you describe here, Mr Dashwood, sounds like what is tested for at the
top of many CICS programs I've worked with, the standard IF EIBCALEN = 0
(Execution Interface Block Common Area Length); if this is true then one
usually Performs/Goes To First-Time-In, otherwise one Performs/Goes To
Receive-Map.
Yes (almost... :-)). EIBCALEN indicates whether this is the first time in,
as you describe. However, as I mentioned, with CICS you really only need to
know whether it is the first time in, because if it isn't you will simply
receive the current map, process it, then repeat the cycle. (Assuming you
don't XCTL out of the cycle or enqueue a different module when the next map
is received.) The fact that the Comm area has zero length means that this
terminal(thread) has not been previously active and a new "conversation " is
starting with it. The "first time" code you mentioned would usually display
a blank format to kick things off. The program then dequeues. CICS often
uses a module for each format, so the cycle is simple and efficient.
With IMS-DC (and similar systems on other platforms), a single program might
drive several formats, each of which would represent a "stage" in an ongoing
conversation. This is a bit like dynamic web pages; the format served up
depends on the processing options taken by the user on the last screen. A
series of linked menus would be one example. The processing depends on the
options selected, but some or all of the options are catered for by the same
program. It must be able to pick up the processing at the point where it
left off before dequeuing. It could be servicing several threads, each at a
different point in the processing. Hence, each thread has a "progress
indicator" stating where it needs to be re-entered (just like the use of
EIBCALEN, except it is now a multi-state switch). Typically, the "progress
indicator"would contain a single digit number; it was rare for a
conversation to need more than 9 formats... We found GO TO... DEPENDING ON
.... pretty useful in these circumstances... :-)
I'm not sure what, exactly, you are calling 'the same code being entered
again' but it seems rather obvious that the code - whether the same code
or an identical copy of it - is processing the same copy of the data
areas; otherwise how would it be determined if this is the First Time In?
It is processing the same copy of the data areas, for each terminal (thread)
that is conversing with it.
The "same code" is the memory resident executable. The whole process hinges
on a thread-dependent data area so that each thread's state can be
remembered and restored. For CICS, this is the Comm area, For IMS_DC it is
the SPA, and so on.
I have used "terminal(thread)" above because you could have a single
threading system that would still service each terminal. (For years we did
this...). It just means that a given terminal will process until it
dequeues, at which point the next one comes in with IT's terminal-dependent
data and processes until IT dequeues... It is not until you have around 16
terminals that you would even notice any delay. (The delay is all absorbed
by the time a Human takes to fill in the format and press Enter.) Nowadays,
multithreading means they can process concurrently. (Multiprocessing means
more of them can multithread :-), hence, the good performance we have come
to expect from mainframe systems generally, and CICS systems in
particular... The executable doesn't change, and each terminal has its own
copy of its own data. Hence, the executable code is "serially reusable".
The difference between this and a distributed OO system is that the
networked system can provide a dedicated processor to an object method
instance, which will also have its own copy of its data (the object
properties, which may include database keys or factory data). There is no
"re-entrancy" as described above because the process is event driven. When
an event occurs (mouse or key click, but other possibilities also) the code
to process that particular event is immediately scheduled on an available
processor. (Note that the use of remote processing through remote procedure
calls means that if the local system is busy, another one can be immediately
used. This is called "load levelling" and modern server operating systems
have it as standard. More processors, more parallel processing... RPC also
allows interrupts to be processed remotely from where they occurred. As
Remote Procedure Calls become more secure and powerful, processors on
servers where data is physically located can be automatically utilised
(although the current trend is away from this and towards letting specialist
subsytems be dedicated to data handling, and other servers be dedicated to
application code). Processing of a conversation could occur literally all
around the World, with data flowing and being processed wherever it was
located or needed. Databases in different countries can be concurrently
accessed and the data brought to one or more screens in diverse locations,
all instantly.The user who intitiated the conversation could easily copy it
to other users elsewhere (kind of like a conference call), interrupt the
flow to make enquiries elsewhere or GOOGLE the web, then resume from where
they left off (shades of TiVo :-)). Furthermore, you don't need a computer
or terminal to initiate it; you can do it from your mobile phone or iPod.
It is another dimension in transaction processing.
The current problems with this are bandwidth, processor power, and security
(this type of processing is often limited to the corporate intranet, for
these reasons), but all of these are being addressed and improving in leaps
and bounds.
Which approach will win out, only time will tell, (maybe both will continue
to flourish for some time yet) but my money is on the network... :-)
Pete.
.
- Follow-Ups:
- References:
- Further discussion on "Something has to be maintained" and lack of OO acceptance.
- From: Clark F Morris
- Re: CICS and COBOL reentrancy was Re: Further discussion on "Something has to be maintained" and lack of OO acceptance.
- From: Pete Dashwood
- Re: CICS and COBOL reentrancy was Re: Further discussion on "Something has to be maintained" and lack of OO acceptance.
- From: Arnold Trembley
- Re: CICS and COBOL reentrancy was Re: Further discussion on "Something has to be maintained" and lack of OO acceptance.
- From: Pete Dashwood
- Re: CICS and COBOL reentrancy was Re: Further discussion on "Something has to be maintained" and lack of OO acceptance.
- From:
- Further discussion on "Something has to be maintained" and lack of OO acceptance.
- Prev by Date: Re: IBM mainframe and OO was Re: Further discussion on "Something has to be maintained" and lack of OO acceptance.
- Next by Date: Re: CICS and COBOL reentrancy was Re: Further discussion on "Something has to be maintained" and lack of OO acceptance.
- Previous by thread: Re: CICS and COBOL reentrancy was Re: Further discussion on "Something has to be maintained" and lack of OO acceptance.
- Next by thread: Re: CICS and COBOL reentrancy was Re: Further discussion on "Something has to be maintained" and lack of OO acceptance.
- Index(es):
Relevant Pages
|