Ken,
You've been getting a lot of abuse from the list, and I'm not hearing too
many people come to your defend. I think the reason behind this is that the
majority of folks out there recognize CICS and similar TP Monitors as the
revered ancestors of modern application servers and component transaction
monitors.
CICS, IMS, IDMS-DC, and similar mainframe-based runtime systems are known as
Transaction Processing Monitors (TP Monitors). These systems were developed
in the sixties to provide online transaction processing (OLTP) services in
an inherently batch MVS world. TP Monitors provide two critical services:
1- they manage scarce resources (address spaces, tasks, requests, program
load memory, program usage concurrency control, and shared storage -- these
are MVS resources that roughly equate to processes, threads, and memory).
CICS systems regularly support thousands or tens of thousands of concurrent
users. The recognized best practice was to use only reentrant code (the
equivalent of stateless session beans).
2- they provide transaction management services for file-based data stores
(file systems accessed through BDAM, QSAM, ISAM, and VSAM do not provide
their own transaction management services, unlike database systems such as
IMS, DB2, Oracle, etc).
Modern application servers provide essentially the same types of services:
managing scarce resources and transaction services -- admittedly, the
specifics of the services are slightly different now, but conceptually, they
do the same thing. CICS actually did do the equivalent of modern database
connection pooling. A CICS region would establish one connection to a file,
and all file requests executed by any task in the region would use that one
file connection.
So you might be a little more understanding of people who defend CICS. It
was an absolutely brilliant piece of technology in its time, and the things
we learned from CICS are used in every modern application server.
BTW - BDAM, QSAM, ISAM, VSAM, etc., were not considered proprietary in their
time. There was no such thing as SQL for accessing files. Developers has to
be cognizant of the physical file structures in those days. And these APIs
weren't CICS APIs. They are file access methods. If you want to access the
raw file, you still need to use these access methods -- whether from a CICS
application or a batch application.
CICS has a variety of proprietary APIs that you use to allocate storage, to
link or transfer control to another application, or to use other CICS
runtime services. Similar proprietary APIs were used in products such as
Kiva, NetDynamics, and WebLogic before we defined a standard set of APIs --
EJB. But now you don't have to use the CICS proprietary APIs anymore -- CICS
provides an EJB container, so you can just write to the EJB APIs.
Regards,
Anne Thomas
p.s. I wrote CICS applications in my youth
-----Original Message-----
From: Kenneth D. Litwak [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 25, 1999 7:08 PM
Subject: Re: <vendor/> Re: EJB CICS integration
>CICS *is* an application server... and a transaction monitor. And CICS
>does *not* contain "a proprietary setof APIs to read and write data sets
>on a record basis." CICS customers generally use VSAM, DB2, or Adabas
>for file access.
>
>Whatever made you think CICS wasn't an application server?
It depends upon how you define application server. If we are going to bend
that
definition to whatever we like, Powerbuilder is an application server.
Visual
Workbench is an application server. It saves data to a persistent store.
It
provides utility functions. This minimalist definit8iion you seem to be
implicitly using is not exceedingly helpful. If CICS is an app server, what
is
not an app server? I cxan define app server to include MS DOS. Is that
helpful? I don't think so. My view, which I d9on[t claim is canonical in
any
sense, is based on products that are generally labelled app servers. They
provide things like workflow engines, authentication, load balancing,
database
connection pools, and the like. CICS might be tied to RACF but it does not
do
(at least when I used it) its own authentication. It did not do connection
pooing. In fact, it had no logical connection at all to any spcific data
store.
YOu had to completely dfine that yourself. Unless the latest version of
CICS is
far different from its 1980's version, application server is not an
applicable
term. This will be my last comment on this. You can stretch the semantic
domain of app server as far as you wish, but does it make sense to call a
Big
mac a pizza just becuase it has cheese and meat on top of a bread-type
substance?
As I told Ian, I used CICS to read from and write to DAM files. What would
make you think that calls like open, close read, write and the like, which
are
used with files, be they DAM or VSAM, is not a properitary set of APIs for
reading adn writing data records? ANd since I owned a good piece of the
internals of DB2w/MVS, thank you, I happen to know that at heart, DB2 reads
from
and writes to VSAM files one recortd at a time. So it's pretty questionalbe
IMHO to suggest that CICS is not a proprieatary set of APIs to read or write
records. It can't do much else from an application progrmming perspective.
CICS might be more, but it is at least this. WHy would yuu say otherwise?
Have
you ever written CICS application code?
To the other point, please describe exactly what you mean when you say CICS
is
a TP monitor.
That's all I have to say on the subject. I can't imagine compariing CICS to
an
EJB server. That's apples to oranges. It is not a knock agaisnt CICS, but
treating the words app server as having a fairly specific meaning.
>
>
>FWIW, when I first read the EJB spec... I knew I was looking at the next
>CICS. CICS is ubiquitous... albeit proprietary. I doubt that you could
>achieve ubiquity today without the type of "openness" that we see in the
>EJB and J2EE specifications. (I also doubt that EJB could achieve
>ubiquity
>without the expertise and support of IBM... but EJB seems to have that
>aplenty.)
>
>-eric
>
>
>
>"Kenneth D. Litwak" wrote:
>>
>> CICS stands ofr Customer Information and Control System, generally
pronounced
>> like "kicks". CICS is NOT an application server. It is a transaction
manager.
>> It has a proprietary setof APIs to read and write data sets on a record
basis.
>> Exactly what the transaction management part is I never knew, except that
you
>> could comit and rollback your work.
>>
>> Ken Litwak
>>
>>
===========================================================================
>> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
>> of the message "signoff EJB-INTEREST". For general help, send email to
>> [EMAIL PROTECTED] and include in the body of the message "help".
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
