SNA Server Set Future Net Protocols For Windows

mssnasvrSNA Server 4.0 extends the product’s already broad reach even further, pairing important new protocol gateway features with innovative data and transaction integration features. In particular, SNA’s new ability to provide seamless access to mainframe transaction code will provide Windows developers with the best of both worlds. For straight terminal access, organizations that don’t want to run IP directly on their host will find SNA Server the most complete option around.

Pros: Rich 3270 and 5250 emulation services; failover and load balancing; allows host COBOL components to be run using Microsoft’s Transaction Server; OLE DB host data access driver; new support for Physical Unit pass-through, compression and LU 6.2 security.

Cons: Server runs only on Windows NT 4.0; no Web-based management of server; OLE DB driver doesn’t provide an API set broad enough for many real-world uses.

Pressing forward on all fronts, Microsoft Corp.’s SNA Server 4.0 beefs up its already impressive SNA protocol gateway support with new tools that make it dramatically easier for Windows programmers to access host resources.

PC Week Labs evaluated a beta release of SNA Server 4.0, expected in the first quarter of next year (prices have not yet been announced), and found the package a soup-to-nuts host connectivity package, offering a wide variety of tools and services that make just about anything on a mainframe or AS/400 easy to access from a PC.

However, shops without Windows clients won’t find nearly as much value in SNA Server 4.0 as Windows-only shops will–OS/2 is particularly well-represented in organizations that require strong host connectivity. New features aside, SNA Server still provides a rich set of SNA gateway features that all organizations will be able to use.

In addition to testing 5250 terminal emulation over a TCP/IP link to an in-house IBM AS/400, we set up access to AS/400 shared folders using SNA Server; we then could access the shared folders from other systems with only the normal Windows networking client installed. SNA Server also supports 3270 connections to mainframes.

In addition to Windows NT, SNA Server provides client libraries for DOS, Windows 3.1 and Windows 95. Macintosh, OS/2 and Unix clients are available from third parties.

Newly supported in SNA Server 4.0 are Physical Unit pass-through, which enables SNA Server to support terminal hardware or printers that must be assigned particular Physical Unit identifiers; compression of SNA packets; and LU 6.2 security, which allows organizations to require that users access the host only through a particular LU connection.

SNA Server’s main competition, IBM’s Communications Server, already supports these SNA features.

SNA Server continues to provide robust failover and load balancing across groups of SNA Servers, a major advantage for organizations that must have host-access gateways that approach the reliability of the host systems to which they connect.

IBM’s Communications Server doesn’t provide as flexible support for failover or TN5250 emulation as SNA Server does–a big drawback for organizations that want to use TCP/IP-based clients to access AS/400 systems. (IBM plans to add TN5250 support in Communications Server 5.1, which is slated to ship at about the same time as SNA Server 4.0.)

Communications Server provides much greater deployment flexibility than Microsoft’s SNA Server, however, because the IBM product runs on a variety of operating systems. Communications Server also provides limited Web-based management, whereas SNA Server does not.

A new OLE DB driver

SNA Server’s new OLE DB driver can access both AS/400 physical and logical files, as well as mainframe sequential access method, virtual sequential access method and partitioned data sets.

We set up an OLE DB link to an AS/400 physical file and were able to browse, search and modify the original file directly from our PC. OLE DB is still a prototype technology, however, and we recommend that organizations hold off until more clients support it and until Microsoft overhauls the ADO (Active Data Object) libraries (which use OLE DB) to add critical core functionality.

In particular, ADO currently lacks (and badly needs) support for Binary Large Objects, user-defined data types, more flexible locking, and more precise date and time handling.

When these features are delivered, ADO will become a more realistic option for real-world development.

A big integration feature that will be put to use immediately is SNA Server’s COM (Component Object Model) Transaction Integrator for IBM’s CICS (Customer Information Control System) and IMS (Information Management System).

We don’t have a System 390, so we couldn’t test this feature ourselves, but what we saw will certainly catch the eye of shops that want to leverage proven debugged mainframe code in their Windows applications.

SNA Server includes a COBOL Wizard, which PC Week Labs used to import source code for a variety of CICS transactions written in COBOL. The COBOL Wizard parsed out CICS communication definitions from the source code and automatically built an equivalent COM object that runs in Microsoft’s Transaction Server. No mainframe code changes are required to support this feature.

Whenever any package calls this COM object, the COM object uses SNA Server to transparently call the associated mainframe code. Two-phase commit support between Windows and mainframe components is automatically provided by Transaction Server.

Transaction calls running in the other direction (from mainframe to PC) aren’t currently supported, a feature that would allow mainframe shops to off-load processing to less expensive PC systems.

You can leave a response, or trackback from your own site.

Leave a Reply

Sorry, no posts matched your criteria.