Newsgroups: bit.listserv.appc-l
Date:         Mon, 4 Jan 1993 13:10:16 EST
From:         maurerm@VNET.IBM.COM
Subject:      Continue APPC-L List?

Subject: Continue APPC-L List?

From: Max M. Maurer         Ext: +1 914 435-5724  Tie: 295-5724
      Dept Y02A/D91G           IBMMAIL: USIB4GWR
      Poughkeepsie, NY        Internet: MAURERM@VNET.IBM.COM
I would vote for keeping the list. The reason that there might not be much
activity right now is that there are some rather active forums in other
places. The COMPUSERV forum (GO APPC) is quite active. I have had the
opportunity to talk with a fair number of people who are using or who are
planning to use APPC and I have found that the problem seems to be one of
critical mass. Many people feel that APPC is or must be a mean, intractable
beast and so avoid it. However, once people actually get started with it, this
viewpoint evaporates rapidly because of the multitude of capabilities that
APPC offers and because of the wide number of platforms that embrace APPC.

To make sense of the following you would need to know that I work for IBM and
am involved in APPC on the mainframe and the PS/2. However, the general
principles range far beyond this restricted set because of the wide number of
different platforms/software that support APPC. (I just pulled the WINDOWS
APPC specification from COMPUSERVE, for instance.)

Just for everyone's information, the applications that we see being
implemented today seem to fall into one of three categories: 1) Enterprise to
enterprise communications, 2) Personal System as an I/O device, and 3) GUI
interface to existing functions. Typically, 1 and 2 are being built by
individual businesses while 3 is usually being done by vendors for their own
code. Also, most of the activity seems to be concentrated on CICS and the
AS/400. The reason that we see these platforms being the most active is that
these were the first to implement. The reason that we see the categories above
is that 1 and 2 provide businesses with a competitive edge where 3 does not.
However, 3 DOES help a vendor sell the next release of their code.

Some examples of current usage just to seed the discussion:

You have a shipping company that receives paper documents (bills of lading,
say) that need to be distributed. They get these documents on a FAX board in a
PS/2, upload them with APPC (CICS) and distribute them to the destination port
via their wide area network and download them to a destination PS/2 for
printing. (this is category 2)

An insurance company has PS/2s on their agent's desks with a rate book on it.
(How much is life insurance for a 40 year old man who smokes?) Each day, the
agent is supposed to download the new rate book. This often doesn't happen.
So, when the rate book is updated on the host, they open an APPC conversation
with their agent's machines and update them directly from the host in batch.
(Again, category 2)

A company sells reports to their customers. Typically, these come on paper.
The buying company then gives the reports to their data entry operators to put
the information into the buying company's data base. The selling company, to
reduce costs and to increase capabilities, defines an APPC transaction to
allow the buying company to browse their data bases on-line in real time.
Having done this once, they can then allow anyone to do the same regardless of
the type of equipment the customer is using as long as it supports APPC. (This
is category 1)

A company sells a certain product in a certain market. They would like to
cross-license their products to another company in return for a similar
agreement. (Many European companies are doing this now due to the opening of
the borders. ) Both companies get expanded markets and expanded offerings with
minimal investment. To implement the support for this agreement, they define
APPC interfaces between their respective machines to sell their respective
products. Thus, the agents for each company see no changes and do not need
much retraining while the parent companies need to do only minimal
reprogramming to effect the merger. (Again, category 1)

These are a few examples of what is being done today. I find, in talking to
customers, that it is fairly easy to find more by simply discussing their
current problems. We see the very user friendly GUI interfaces on personal
systems married to the compute power and reach of mainframes and the
capabilities that are then available become quite interesting. An interesting
idea that was proposed to me was a "worm". Since you can send anything you
like across an APPC conversation, you could send a program followed by data
upon which the program would operated. Thus, you could put together an
application that would roam around your network looking for things. (Kind of
like some of the viruses we see today but, at least with the APPC/MVS with
full B1 security.)

Thus, I think that we are just now starting to see enough mass in the
marketplace to really see what this thing can do. For this reason, I would
like to see this forum continued. I monitor this forum and would be more than
willing to answer any questions that might be raised. In addition, there a
bunches of examples that IBM provides -- some with source code. (I cannot send
files or I would provide them.) Ask your local, friendly IBM guy to look on
MKTTOOLS for you. In the mean time, I would strongly suggest that you give
this a try if you can. I found it to be rather intoxicating -- lots of fun,
too.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
MxM    Where the thought for the day is:
Be bold in what you stand for and careful in what you fall for
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU