Re: configuration of c/s application

[Vern Hamberg <hambergv@xxxxxxxxxxxxxx>]

Dan

At 12:55 PM 1/13/98 -0500, you wrote:
>This is our project in a nutshell - Visual Basic-developed applications on
>a Win 95/NT client, possibly downloaded from a file server, pointing to an
>AS/400 via Client Access and TCP/IP and accessing databases via ODBC.  Our
>group is now thinking about the network architecture and they are asking me
>questions.  Some think we load Client Access on an NT file server and have
>all clients "funnel" through that connection to the AS/400.  This can be
>done, I'm sure, but I wonder if it is the most efficient method, especially
>because users may number in the hundreds.  Should the VB application reside
>on the PC instead, communicating directly with the AS/400?  If so, how best
>to communicate with the AS/400 across the WAN?  Is it good to have Client
>Access on dozens or hundreds of PCs talking to one AS/400?
>
>My real question is, how do we size client server applications and how do
>we best deploy them?  Where do we go for information on this subject?  I
>realize that this is an open-ended question, but I must start somewhere.

We're involved in something like this. Here are some thoughts (JMHO).

Client Access needs to be loaded on each client PC, not on an NT server
(unless you're using Citrix' setup, and CA's not proven to work this way,
AFAIK).

Avoid any attempt to talk you into SNA Server. Performance white papers on
the benefits of this kind of connection are at least 2 years old and have
nothing to do with present reality. Direct TCP/IP is the way to go now, and
is very good.

Another respondent said not to use ODBC. I disagree. There are definite
security issues, but they are manageable. There are a couple info APARs at
the Client Access site at IBM that discuss ODBC concerns, including
security. Similar concerns exist for ALL TCP/IP applications, like the fact
that LMTCPB is not honored over any network connection. I.e., a person in
an FTP session where PC is client and 400 is server can execute any command
within the session, with the QUOTE RCMD facility. Client Access (and PC
Support) always had this problem, although it was not well-known.

The ODBC driver with CA 95/NT is quite good, vis-a-vis performance.
Ultimately, your access path structure will have a lot to do with good
performance. Take a good look at shared access paths. Take the opportunity
to recreate logicals insuch a way that sharing is optimized (longer key
first, then successively smaller subsets, I think). Also, have access paths
to support the queries you need to use.

The manual, _Client Access for Windows 95 ODBC User's Guide_, is excellent.
There's a lot of good info about ODBC programming, as well as VB.

We have a contracting firm (don't ask <g>) writing an app that is
essentially what I call a 'logical' 3-tier C/S structure. This is the
preferred configuration, I believe. What it means is that the client VB app
handles mostly presentation & user input, while data retrieval (and
business rules) are handled by a separate program (app) on a middleman
server. Finally, the backend database (DB2/400 here) serves the data as
requested by the middleman.

I call this logical, because there is nothing here about physical hardware
locations for the various components, other than, perhaps, that the
database is on an AS/400. But the backend data server could, conceivably,
be anything from an MS Access database on the client, to SQL Server, to
Oracle on a Unix box, or whatever.

In our case, the middleman will reside on 1 or more NT Server boxes. We may
need more than one, in a load-leveling scheme, in case traffic gets too
intense. The client app will request data or actions to be performed by the
middleman server, which will go to the 400 for the data or, maybe, stored
procedures (which, interpreted, means RPG, etc., programs). The middleman
is also responsible for validation rules, etc., upon input from the client.

This structure definitely requires careful planning and design. It gives at
least the benefit of separating function, so that you knowexactly  what
program has responsibility for what actions.

Having each PC communicate directly to the 400 is, in and of itself, not a
problem. Terminal emulation does it all the time, and the traffic is not
constant from any one PC. Screen information is, at most, about 2K in any
single transmission, and usually far less. VB apps would probably not be
much bigger, if at all. It depends, of course.

There is much more. The magazine, Visual Basic Programmer's Journal, often
has articles about these matters. IBM has some 400 manuals on the subject,
as well as redbooks.

Hope this rambling helps a little.

Cheers

Vernon Hamberg
Systems Software Programmer
Old Republic National Title Insurance Company
400 Second Avenue South
Minneapolis, MN 55401
(612) 371-1111 x480


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---