CICS, pronounced as "kicks", is the better known acronym for CustomerInformationControlSystem
IBM's general-purpose Online Transaction Processing (OLTP) software.
The IbmCorporation TransactionProcessingMonitor
(TP monitor) underpins many of the world's major businesses. It has progressed beyond support for JavaTwoEnterpriseEdition
(J2EE) (see EnterpriseJavaBeansInCics
) to better integration with SoapProtocol
CICS is supposedly a product line that accounts for a huge proportion of BigBlue
's revenue and earnings.
CICS is turning 35 years old in 2004, and it is the only reliable TP monitor able to support high volume transactions.
Dont forget about IbmIms which also falls in that category
Although it has started to offer JavaLanguage
support in recent years, it was felt the interface was "unnatural". Dec 2004 release of the TransactionServer?
3.1 for ZOS, together with a new transaction gateway, have made further progress in support of ServiceOrientedArchitecture
(SOA). For example, CICS will be able to consume SOAP based web services for the first time.
Besides better integration with IBM's flagship J2EE WebSphere
product (support JCA1.5), CICS is going to have better support for CeePlusPlus
, better transaction management (using Tivoli) and thread safety.
Improvements in the CICS will better position BigIron
infrastructure to deliver machine cycles for the SOA requirements.
And recently Thre are further performance related additions to CICS, for programs that are ThreadSafe
. See more at http://www.reevans.com/spec.html
views CICS as a suitable CareerLanguage
for new graduates. See http://www.theregister.co.uk/2004/12/07/ibm_soap/
CICS belongs to a class of systems software known as TransactionProcessingMonitor
s; in the latter part of the 20th century, it was a de facto standard for medium and larger Enterprises, due to scalability and efficiency.
Q1 Any one knows why JavaLanguage and CICS do not fit well? Is it due to fluidity of resource impact, due to memory requirements?
Q2 Does it mean with the 3.1 version of CICS, companies that are committed to DotNet can benefit in a significant way, without having to support J2EE?
The main issue with CICS and JavaLanguage
not fitting well, IMHO, has to do with Java dynamicity. CICS was born at a time in which entire data centers had less memory than, say, your cell phone now does. So CICS tends to be optimized to minimize memory use and minimize paging, even today. Java comes along with no such constraints. Java wants to use huge tracts of RAM and load it up with jars of classes per each JVM. In the JVM implementation which CICS uses, each JVM appears as an unshared entity to CICS, which means that classes are loaded per JVM and cannot be shared. If a JVM is needed for a transaction and an idle one does not already exist, CICS must wait for an existing active one to become idle or initialize a new one. The bottom line is that JVM initialization under CICS is dreadfully slow, but once a JVM is initialized subsequent invocations of the same code are reasonably quick and efficient. This was part of the rationale for the serially reusable JVM introduced with IIRC CICS TS 2.2 . If the JVM implementation was more CICS-like, each class would be a separately loadable sharable entity. Maybe someday this will be realized. The other thing to consider is that CICS is not very GUIish, although support for web publishing improves that somewhat. So, all the kewl GUI-enabling Java capabilities are, if not completely irrelevant, at least difficult to work with.
Anything much more complicated than a "Hello, World" program will still require the programmer to be cognizant and environment-dependent in his/her CICS Java code. So I wouldn't think CICS Java would really provide much DotNet
benefit. I guess it depends on what you mean by DotNet
. Keep in mind that in fact CICS Java support is hosting the IBM z/OS J2EE implementation within the CICS TransactionProcessingMonitor
; you definitely have to support J2EE to take advantage of CICS Java support.
CICS with better WebServices capabilities Dec04 http://weblog.infoworld.com/techwatch/archives/000851.html