>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".
