Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.kei.com!newsfeed.internetmci.com!in2.uu.net!news.new-york.net!ritz!jpletzke
From: jpletzke@ritz.mordor.com (Jonathan Pletzke)
Subject: Security and Data Transport to Host
Organization: Mordor International
Date: Fri, 29 Dec 1995 20:33:05 GMT
X-Newsreader: TIN [version 1.2 PL2]
Message-ID: <DKD7r5.IFx@ritz.mordor.com>
Lines: 41

I have been looking at the options available to connect a Smalltalk based 
client (any version) to a host system , in my case MVS DB2 and IDMS.

I have seen several strategies and am looking for discussion regarding 
these.  I do not believe that there is any one cut and dried approach.

1. Use a middleware product.  This means buying one if available (such as 
EDASQL or IBM DDCS) or rolling your own (custom comm server in C or 
Smalltalk (Gemstone?)).  Static SQL via these options is even tougher.

2. Use an interface to COBOL running on the local PC, converting 
everything into CICS transactions.  This seems the most secure, but the 
biggest waste of effort and monster maintenance problem.

There are pros and cons, and variants to the above methods of 
interfacing.  I am concerned that Client-Server does not fully address 
the security needs of the database, as well as user-authorizations for 
the various functionality available.  

My take on all this (opinion follows):
It seems that the best first steps for my client is to use as much 
off-the-shelf as possible.  With this in mind, we'll use a DDCS 
connection to DB2, store our own user privileges on the DDCS-DB2/2 
Server, use RACF on the host, and use static SQL (hopefully) via stored 
procedures on the DDCS server.  We will then either use stored 
procedures, or COBOL on the workstation to handle the non-SQL portion of 
our application that deals with IDMS.  It seems that Static SQL is 
essential to preserve the security of the data, to restrict selects, 
updates, and creates for each user profile.

In the past we've used expensive custom middleware.  This client cant 
afford the time delay, and does not suffer from the "not invented here" 
syndrome.

Any thoughts?

-Jonathan




