Anne, I'm appreciative of your note. OF course, I never said that CICS was
dumb nor anything as ridiculous as "modern app servers invented transaction
management." SO why I'm getting those kind of responses, I don't know. (As a
matter of fact, I regularly tell Sun customers learning Java that they will
probably have to integrate with IMS and CICS becuase those systems are still
fairly prevalent because they are robust and can deal with high transaction
volumes). What I still fail to see is the approach of some on the list. I've
got more years doing mainframe programming probably than most of the people on
the list. Can we see a show of hands for how many of you wrote IMS DB//DC
programs, used the IMS Data Dictionary (worst software program I have ever used
and the very worst doc I've ever tried to read -- makes the doc for GridBagLaout
look crystal-clear), or MFS with DB2/MVS or (to date myself even more) DB2 with
ADF II. I've done CICS in 370 Assembler, COBOL and PL/I. So I was pretty
appalled to have someone suggest my perspective is a Java/OO perspective, as
though I had no mainframe background. As I said, I used to work in the kernel
of DB2/MVS and can talk all about how it works (though I'm probably still
legally bound to not do so).
The issue here is twofold: what do you do with a given product as a
developer and what does the product do natively. IF locking and logging and
program launching and authentication constitute an app server, then one could
argue that DB2/MVS by itself is an app server. Would any of you like to do
that? Then again, in response to Eric Williams, I could argue that DB2 does
not do locking. It's actually handled by IRLM. It does not actually manage
memory. That's done by MVS system calls, a beast which I've written. DB2
doesn't do parallel processing but relies upon hardware to really make that
happen to get CPU parallelism. I know because I wrote part of the code. So
it's rather inappropriate in my view for someone to talk as though I've got no
background in this. So we're back to what constitutes an app server. Is it a
product that comes with lots of features or a product that can interface with
other tools to accomplish the tasks? I'd say the former. The whole point of
EJBs is to do all the enterprise-level stuff transparently for a developer.
Finally, while there are calls in CICS like Link, I'm flabbergasted
that anyone would deny that CICS has its won APIs like open, close, read and
write, for accessing plain old files. It's there in the doc. It's he
fundamental stuff CICS app programmers use. What is the benefit of denying
this? Surely only rhetorical. I have no quibble with the idea that IBM
mainframe software pioneered a lot of mechanisms for doing OLTP. I never said
that, so why are people accusing me of it? The leap from that to CICS as the
ultimate app server, however, is a bit questionable to me. Anyway, I'll stop
criticizing and hopefully I won't have to read essentially non-technical
marketing posts on CICS.
>
>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".
