From: Mark Kovarski <kovarski@zooid.guild.org>
Subject: 1992 in review.
Organization: The Zoo of Ids
Date: Wed, 16 Dec 1992 22:12:09 GMT


Journal:   PC-Computing  Oct 1992 v5 n10 p58(1)
------------------------------------------------------------------------

MICROSOFT  IS SO  CONCERNED ABOUT  OS/2's POSSIBLE  success that  it's
putting on  a road show  just to convince  people that they  shouldn't
even try  OS/2. As far  as Microsoft's concerned,  we should wait  for
Windows NT or use Windows 3.1, no matter how limited their power.

A mole at  Microsoft has distributed  copies of an  internal marketing
memo  that outlines  the company's  strategy for  burying OS/2  in the
minds of anyone  even considering it. I'll outline  some highlights of
the 40-page  presentation to help  you evaluate the  sales pitches and
the  sometimes dubious  information  flying  around about  Windows and
OS/2. There is nothing worse than disinformation from pitchmen.

Microsoft's  key concern  is listed  in the  "Tactics" section  of the
memo:  "Whenever possible,  take the  high road.  The material  can be
inflammatory. It  may also give  the customer not  actively evaluating
OS/2 the impression  that we're worried about OS/2  and plant the idea
in their mind that they should evaluate it."

In  other  words,  leave  customers  in  the  dark  if  they  show  no
inclination  toward OS/2.  If they  do show  interest, then blast them
with this material.

The  sales reps  are told  to "use  squeeze positioning:  Squeeze OS/2
between the capabilities of Windows 3.1  on the desktop and Windows NT
on the  workstation and server." Then  memo instructs: "Important! Use
the term native Windows applications  when talking about Windows apps.
Important! Do not use the word seamless to describe OS/2 2.0's support
for native Windows applications."

The presentation goes  into a hard sell from  there. A slide indicates
that OS/2  will not even  load on 24  percent of the  machines tested.
Included  in this  list are  the names  of the  failed machines: "NCR,
Northgate, AT&T, Gateway,  and Dell." No model numbers  or details are
given on the slides or the memo,  but there seems to be an implication
that no  machine from NCR, Northgate,  AT&T, Gateway, or Dell  can run
OS/2. I was  just corresponding with a fellow  who was happily running
OS/2 on a Gateway 386 machine, so I wonder about these assertions.

If I  were a corporate Microsoft  client looking at this  list, I sure
wouldn't want  to buy any of  those machines, even to  run Windows. It
sounds  like  there  are  obvious  compatibility  problems.  Maybe the
mentioned vendors should straighten out Microsoft on this issue before
people begin to assume that these companies make dubious machines.

The  memo gets  better. Part  III of  the presentation  goes into high
gear.  Called  "Myth  Slides,"  this  section  shows  Microsoft's real
concerns and its litany of responses to these issues. According to the
memo, the Myth Slides are to be  used only on a customer who questions
Microsoft's claims.

Here  are  a  few  of  the  myths  and  Microsoft's  responses. First,
Microsoft attacks  the criticism that  Windows is just  a powerful DOS
shell. Although  its arguments are  sound, Microsoft admits  that file
I/O goes  through DOS; Windows needs  DOS to boot and  uses DOS to run
DOS programs.  It's amusing that Microsoft  calls Windows an operating
system but  admits it won't  boot or perform  file I/O. But  OK, we'll
stretch the definition.

The second  myth explored is that  "OS/2 is fully 32  bits." Microsoft
retorts that  various 16-bit components in  OS/2 cause bottlenecks. In
this  slide, Microsoft  compares OS/2  not to  Windows 3.1  but to the
unreleased  Windows  NT,  which  is  shown  as  100  percent  32  bit.
Great--give me a copy.

The next  myth is interesting:  "Windows NT is  a 1993-94 Technology."
Microsoft states, "Windows NT is on  track for a 1992 release." When I
see  shrink wrap  at Egghead,  then  I'll  believe it.  No offense  to
Microsofties, but I've heard these promises before.

Onward to "OS/2  is a better Windows than  Windows." Here Microsoft is
right:  It's not.  On my  system, OS/2  runs all  my Windows apps just
fine.  I'm  really  a  DOS  user  looking  for  more  performance  and
versatility. I  tell my friends in  the graphic arts who  need the GUI
and Windows to get Windows 3.1 (or a Mac) or wait for OS/2 Windows 3.1
support.

I suppose  that leads  to the   real joke  of the  presentation, where
Microsoft calls the phrase "OS/2 is a better DOS than DOS" a myth. Its
argument is  based on the  fact that OS/2  is bigger than  DOS, so how
could it be better?

By  declaring this  a hoax,  Microsoft brings  the entire presentation
into question. Gee, guys, is OS/2 good for anything at all? No? Funny,
since Microsoft is a codesigner and  only recently changed the name of
OS/2 3.0 to Windows NT. Who are we trying to kid?

The key here  is that Microsoft doesn't want anyone  to even try OS/2,
and  you have  to wonder  why. The   way I  see it,  OS/2 is  the best
solution for me  today. I agree with Microsoft that  it doesn't run on
every system, and I don't know if  it's because of wacky BIOS chips or
strange motherboard  designs, but I seriously  doubt that this dilemma
will be  any different with  Windows NT. In  fact, it could  be worse.
Whatever the  case, OS/2 is  an inexpensive multitasker  that ends the
need for extenders, caches, memory managers, and other costly add-ins.
If Windows  NT is better,  then I'll install  it. After all,  it's not
that hard  to swap operating systems  nowadays. Maybe Microsoft should
follow its own  advice-- "Take the high road"--and  dump this negative
and misleading presentation.
------------------------------------------------------------------------

Journal:   LAN Magazine  Oct 1992 v7 n10 p68(4)
------------------------------------------------------------------------

Many people say they are building distributed or cooperative computing
applications.  But actually  doing it--with  the transaction integrity
and access  security found in  most mainframe systems--is  a different
task altogether, Most complaints about DOS- and Windows-based attempts
at building these cooperative computing  systems deal with the loss of
integrity and inadequate security.

The release of IBM's OS/2 version  2.0 is welcomed by a large audience
of MIS analysts and designers. The  reason is not OS/2 itself, but how
it expands the base upon which distributed applicAtions can be built.

THE MOUNTAIN TO MOHAMMED

With  its complementary  products,  OS/2  Extended Services  (ES), LAN
Server  2.0,  and  a  less  well-known  IBM  product,  CICS  (Customer
Information Control System),  OS/2 2.0 can bring the  mainframe to the
workstation. Applications  can now be re-engineered  to take advantage
of  truly  distributed  architectures  while  maintaining  the central
security  and integral  transaction administration  that characterizes
current terminalbased mainframe applications.

The typical  workstation and server  products used today  to implement
the  client-server architecture,  such  as  Oracle's SQL*Net  or Micro
Decisionware's  PC/SQL-Link gateway,  only go  part of  the way. These
products only  recognize database units  of work in  their transaction
integrity schemes.  Many types of  businesses probably will  find this
recognition  inadequate  for   their  applications.  IBM  specifically
targeted  OS/2  for  its  large  customers,  such  as  banks and other
financial and customer service enterprises.

OS/2 2.0 is  a very different product than  its preceding cousin. Many
services  Extended Edition  (EE) added  to the  operating system  were
built on special-purpose code that exists  only in the EE version. Now
these services have been incorporated  into the base operating system.
Also, the virtual memory management techniques used in version 2.0 are
much  more  efficient  and  secure  than  in previous editions. OS/2's
preemptive multitasking capability is more capable of dealing with the
interrupt-intensive environment  of communications-based applications.
Except for the few applications that violate the integrity constraints
imposed by OS/2, such as  private memory management, most existing DOS
and Windows applications can be executed as they are under DOS.

DESIGNING FOR RELIABILITY

In a  typical financial enterprise,  the primary issues  surrounding a
decision to distribute or downsize are:

* continued  use  of  existing  workstation  applications,  like Lotus
  1-2-3;

* continued support of terminalbased applications; and

* the  ability   to  provide  the   following  distributed  functions:
  transaction or unit-of-work integrity; data and message recovery and
  rollback; and user access security.

OS/2  2.0 satisfies  the criteria   for continued  use of  existing PC
applications.  The   Communications  Manager  component   of  OS/2  ES
satisfies the need to still use terminal-based mainframe applications.
Providing mainframe-like  functions in a distributed  environment is a
bit  tougher.   The  mainframe  MIS  person's   answer  is  an  Online
Transaction Processing (OLTP) system, such as CICS.

Another feature  of OS/2 2.0 that  is useful in the  implementation of
distributed cooperative  applications is the Workplace  Shell. The old
window   model  is   too   similar   to  the   typical  terminal-based
applications, which pits the mainframe  against the workstation in the
control  of the  application. The  object-like model  of the Workplace
Shell gives the user interface a much more flexible look and feel.

Imagine  enterprise applications  just  waiting  to be  activated once
their container  is opened. These  applications are not  programs that
operate on files but are simply well-defined business activities, such
as a customer or an account  display. For example, if the customer has
been identified, the dropping of the customer icon on the account icon
will  present a  list of  the identified  customers' accounts for user
selection.

The operational  or product development  possibilities are refreshing,
especially if you  are a slave to the  current simplistic hierarchical
menuing systems.

Typically, mainframe-oriented  MIS people and  workstation-oriented PC
and LAN people  can't seem to communicate. It's not  only a shame, but
the lost productivity costs corporations millions of dollars per year.

The  following architecture  establishes  a  single standard  for both
mainframe  and  workstation  application  programming.  It  allows the
system  implementation  to  be  distributed  and  redistributed  to an
appropriate  computing  platform.  Whether   the  application  uses  a
Graphical User Interface (GUI) or non-programmable terminal to present
information  to the  end user,  the system  needs only the appropriate
versions of the presentation components, GUI or terminal-based.

GETTING YOUR CICS

As mentioned  earlier, the mainframe  programmer addresses transaction
integrity,  access security,  and systems  recovery by  using an  OLTP
environment  such as  CICS, a  workhorse in  the MIS  stable of tools,
developed more  than two decades ago.  In the interim, it  has evolved
from a  highspeed communications interface and  file management system
to  a   multiplatform,  intersystem  communication   and  unit-of-work
manager.

Originally   CICS  simply   provided  an   environment  that   allowed
applications  to  access  terminals  with  a  fairly  simple API while
supporting  highspeed  multitasking.  The  programs  were  written  in
assembler language.

Today,  CICS supports  COBOL or  C programs  and has added recoverable
database and file  I/O. Application users connected to  one system may
execute  portions of  their work  against a  DB2 database  on a remote
system.

CICS  OS/2  is  not  an  emulation  of  the  CICS  API like other CICS
lookalike  products, but  a fully  functional member  of the family of
CICS  products.  Currently,  CICS  is  implemented  or scheduled to be
implemented on all  SAA platforms plus AIX, the  IBM implementation of
Unix that is supported on IBM mainframes and the RS/6000.

The  key  elements  of  a  CICS-based  architecture  for a distributed
enterprise application are:

* CICS   API,  including   a  transaction   scheduling  mechanism  and
  intersystems communications;

* a robust communications interface;

* user security; and

* a sturdy transaction (unit-of-work) manager with integrated rollback
  and recovery features.

In  addition,  these  features  must  be  coordinated  across multiple
dissimilar platforms.

CICS API

CICS provides  several means of  communicating data among  application
functions.  Data can  be passed   in a  communication storage  area or
placed into  transient or temporary storage  queues. The queue storage
allows  data  to  be  maintained  even  after  the  termination of the
creating  task,  whereas  the   communications  area  must  be  passed
directly.

Process control or the scheduling of transactions, programs, and tasks
is  provided by  a set  of Intercommunication  (ISC) protocols, called
function   shipping,  transaction   routing,  distributed  transaction
processing, and distributed program link.

Function shipping  executes a CICS  function, such as  file I/O, on  a
different  processor  or  region.   Transaction  routing  initiates  a
transaction request  and executes on a  different processor or region.
Distributed   transaction   processing   carries   on  a  peer-to-peer
conversation between  two CICS transactions  on the same  or different
processors.  Distributed  program  link  links  to  a  subprogram that
executes on the same or different processor.

Although function shipping and transaction routing have their use in a
distributed enterprise  application, only DTP  and DPL are  used in an
example  of  a  cooperative  application  to  follow.  In  addition, a
facility available  to the workstation  programmer allows a  normal PC
application to  invoke CICS functions.  This facility is  known as the
CICS External Call Interface (ECI).

COMMUNICATIONS

The   most  important   communication  support   is  in   peer-to-peer
communications. CICS fully supports SNA LU6.2 or Advanced Peer-to-Peer
Communications (APPC) across the full  spectrum of IBM platforms, from
PC to  mainframe. In addition, NetBIOS  is supported on the  PC. It is
important  to  understand  that  the  communications  protocol  is not
actually implemented within CICS, but  as an operating system function
such as SNA VTAM on S/370 or Communications Manager on the PC.

TRANSACTION MANAGEMENT

Integral to these functions is the ability of CICS to include file and
database  updates using  dissimilar DBMSes  in a  single unit of work.
This ability  may rattle the  cage of a  sacred cow or  two, but it is
unlikely that a single DBMS  will support the commit/rollback function
across  the boundary  of little  more than  a few  relational database
managers. A distributed enterprise application  may need to access not
only dissimilar SQL  engines, but also sequential or  direct files and
hierarchical or network databases such as IMS or IDMS.

What is  most surprising about  the general direction  in the industry
and the majority of MIS managers is that they seem to be waiting for a
magic genie that  will allow them to use any  combination of DBMSs and
magically  perform full  commit with  integrity among  each other.  No
agreement  on  a  full  implementation  of  SQL  exists  or even looks
imminent.

Likewise,  network operating  systems such  as Banyan  VINES or Novell
NetWare are  perceived to provide  a similar service  that coordinates
commit  with  databases  and  files.  Even  CICS  is  not  capable  of
coordinating  commit/rollback of  a distributed  unit of  work all  by
itself.

USER SECURITY

Mainframes use products such as IBM's Resource Access Control Facility
(RACF) to  secure the data and  applications from unauthorized access.
Under these  systems, a user is  required to logon with  a user ID and
provide a password. CICS restricts its applications and data under its
control to those user IDs who have been registered as authorized.

User authentication is not accomplished by CICS, but in the supporting
security system. OS/2 provides a similar function, called User Profile
Management.  This facility  is  included  if the  workstation installs
Extended Services or LAN Requester.

When  coupled with  the ability   to lock  network definitions  at the
workstation  and  require  CICS  and  its  transactions  execute  only
resources resident on  a server, the workstation can  become a trusted
system.  A  trusted  system  is  one  where  a  central  authority  is
reasonably assured  that the person using  the facility is authorized,
the programs executed on the system  are secure and auditable, and any
system data is not subject to corruption.

It is  possible to implement  a highly integrated,  multiple database,
distributed  unit of  work transaction  with only  a slight  amount of
application programming.  In the near future,  a CICS application that
uses  supported  file  and  database  systems  will  have  coordinated
synchronization  of  data  updates  across  all  CICS  platforms. This
synchronization means a CICS program  can perform normal file requests
executed on a different machine (or  CICS Region on the same machine),
and these updates will be committed in full synchronization with a DB2
maintenance  and DLI  update. In  effect, it  is an  implementation of
"distributed unit of  work." As you see, no single  DBMS exists in the
above example.

Here  is an  enterprise with  a  common  customer table  in a  central
database. Further,  assume that the  enterprise has offices  organized
with their  own local accounts  and several central  account servicing
groups organized  around business functions.  When an account  service
operator speaks with a customer, whether in a local or central office,
he or  she requires access to  all the customer's records  and account
information. Assume that if activity is required against more than one
data object, all activity is collected before any processing occurs.

Implementation  of  this  scenario   can  be  accomplished  using  the
following programs or transactions:

* Customer unit of work  coordinator. This main GUt-driven application
  uses subordinate GUt transactions to  identify the customer, set the
  domain of customer accounts, and process actions against an account.

* Customer  identification dialog.  The GUI-driven  dialog uses remote
  procedures to  access the central  customer database, then  presents
  lists of  candidate information for operator  selection. This dialog
  ultimately results in the identification of a unique set of customer
  records.

* Customer  database accessing  module. This  module is  one (or more)
  GUI-driven application, based on the account type, that presents the
  details of an account and schedules account service processors.

* Account service processor. This set  of paired presentation and data
  processing  modules collects,  presents, and  maintains the  account
  database  records.  The  presentation   component  executes  on  the
  workstation,  and  the  data-processing  component  executes  on the
  processor that supports the account database.

* Customer  records  processor.  This  similar  set  of paired modules
  maintains customer records.

These components communicate via  a message-passing protocol. All data
communicated among application modules are  contained in a data stream
that  holds  the  identity  of  both  the  source  and the destination
process,  as well  as the  identity of  the user  and the  node on the
network where the user is located. The  data are in a form that can be
translated   to  the   appropriate  code   system  by   a  transparent
communications service.

The customer unit of work coordinator is a program that is external to
the CICS environment. It is primarily a scheduler of subordinate tasks
and  a  Presentation  Manager  (PM)  window  handler.  The application
communicates to CICS through the  External Call Interface. In general,
this   program   carries   on   distributed   transaction   processing
conversations with other coordinators  and the customer identification
dialog.  In  addition,  should  the  application  require  maintenance
approval, this  module collects the  maintenance request messages  and
stores  them in  a work  queue for  subsequent approval and execution.
These  messages are  stored in  a transient  data queue  or a  special
work-in-process database. If approval is not required, the appropriate
processors are scheduled using Distributed Program Linking (DPL).

The  Customer  Identification  Dialog   is  a  quasi-independent  CICS
transaction that uses a PM GUI to  interact with the user. It does not
perform  direct  database  I/O.  Instead,  it  uses  DPL to invoke the
customer   database   accessing   module.   Normally,   these  modules
communicate in transient data. The idea behind this module is to allow
for selection based  on more user friendly criteria,  such as phonetic
or caller  ID. In such a  scenario, the business application  needs to
maintain the alternate identification elements as an object.

This  function  is  accomplished  by  means  of  the customer database
accessing module. To allow the  object-like processing of the customer
database, all access to this data is processed by requests to a common
module.  This  relationship   will  be  true  of  most   data  in  the
applications  designed  to  this  proposed  architecture.  Examples of
object-like behaviors are  the maintenance of phonetic keys  tied to a
name  or accessing  customer records  via a  phone number  or zip code
address. For functions such as these to work, all related data need to
be maintained as a unit.

Normally, it would violate relational normalization rules. However, if
one  modified the  rules to   account for  these object  behaviors and
assured all maintenance  occurred in a module that  was aware of these
behaviors,  then normal  relational  processing  is possible.  In this
proposal,  the  account  service  processor  and  the customer records
processor are further examples of these programs.

The  idea behind  account service  coordinator functions  is to  treat
business  processes  in  a  similar  way  as  the  previous method for
accessing  data. Therefore,  processes can  be distributed  in a  more
flexible manner. Processing could be performed where the various types
of accounts are stored while still  supporting a local or central user
interface application.

ISSUES AND DIRECTION

A few issues block the way of  a largescale acceptance to this type of
architecture.  One  of  the  most  important  is  cost.  To  use  this
architecture, a workstation requires  OS/2 2.0, OS/2 Extended Services
(Communications Manager), and CICS OS/2 for a grand total of more than
$1,000  per workstation  for just  software. In  addition, the servers
require a  supported DBMS, such as  ES Database Manager. IBM  would be
committing  a  disservice  to  its  best  customers  if  it missed the
opportunity to  let them move  to distributed systems.  These products
need to be commodity priced. IBM  has done much in this direction with
their  pricing  of  OS/2  2.0,  and  it  needs  to  do  the  same  for
Communications Manager and CICS OS/2 for client workstations.

Also, cost-effective ways  to allow an enterprise to  evolve over time
to the  distributed applications environment need  to be developed. In
the  meantime,  workstations  need  to  access  3270  terminal  (LU.2)
applications at  the same time  as peer-to-peer (LU6.2)  applications.
Not every  workstation is on  a LAN, but  all are now  part of a  3270
network.

Like PCs in the 1980s, transaction management will be the key issue of
the  1990s and  deeply affect  the scope  and direction of distributed
applications.  Instead  of  having  territorial  wars  between  PC and
mainframe developers, we should all look to the benefits each platform
offers. There need not be an  either/or, take it or leave it approach,
if we recognize  that we are all in the  business of serving our users
and  companies. If  not, our  users  will  continue to  be subject  to
mainframe tyranny, while our companies are harassed by PC anarchists.

Mike  Poolev  has  been  involved  in  designing  applications for the
financial services  industry for more  than 25 years.  He is currently
responsible for  the definition of a  generalized enterprise model and
an architecture for coopertive applications.
------------------------------------------------------------------------


Newsgroups: comp.os.os2.advocacy