Excellent Ann! Couldn't have said it better myself!
>
> 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
>
>
===========================================================================
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".
