excellent
Anne Thomas wrote:
>
> 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".
--
Tony Holderith | Interactive Business Solutions
[EMAIL PROTECTED] | NetCentric Solutions
http://www.interactivebusiness.com | Business Objects
voice: 310.414.6760, 805.893.4503 | fax: 310.414.6759
Don't connect to the Internet - be there. IBS
===========================================================================
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".
