Een groeiend aantal bedrijven heeft uit strategische overwegingen besloten SNA (systems network architecture) geleidelijk te vervangen door de meer open, gedistribueerde architectuur TCP/IP. Een dergelijke overgang confronteert de gebruiker echter met de nodige beperkingen. Met name beheer en beveiliging van het netwerk eisen de aandacht bij het gebruik van TCP/IP in een mainframe-omgeving, aldus produktmanager Deric Villanueva.
Het feit dat IBM-systemen de afgelopen twintig jaar de grote bedrijfsomgevingen gedomineerd hebben, heeft één belangrijke reden: ze werken. IBM’s besturingssystemen (VSE, VM, MVS) en systems networking architecture (SNA) zijn ontworpen voor professioneel gebruik en hebben inmiddels hun betrouwbaarheid en beheerbaarheid ruimschoots bewezen. Bovendien heeft de praktijk uitgewezen dat ze in staat zijn om de informatiesystemen van de allergrootste bedrijven draaiende te houden. Nu het jaar 2000 dichterbij komt – de datum waarop velen meenden dat de stekker van het allerlaatste IBM-mainframe uit de muur getrokken zou worden – is de wetenschap dat het mainframe ons zal vergezellen naar de volgende eeuw bijna alom geaccepteerd. Deze kolos is geenszins gedoemd te verdwijnen; in plaats daarvan verandert zijn rol en wordt hij steeds meer ingezet ter ondersteuning van zakelijke informatiesystemen. De rol van SNA ontwikkelt zich eveneens.
SNA is een gecentraliseerd, hiërarchisch opgezet netwerkmodel dat aan verschillende componenten van een systeem een unieke rol toekent, om zo een efficiënte werking van netwerkapplicaties te bewerkstelligen. De besturingssystemen van mainframes zijn ontworpen als subcomponenten van de SNA-architectuur; de verbinding met het netwerk komt tot stand via Vtam (virtual telecommunications applications method). Applicatie-subsystemen hebben terminal-interfaces – bekend als lu’s (logical units) – via Vtam. Een 3270-terminalsessie bijvoorbeeld maakt gewoonlijk gebruik van LU 2. De Vtam-functie Sscp (systems services control point) onderhoudt, beëindigt en controleert lu-sessies.
Het netwerkmodel van de AS/400-omgeving is appn (advanced peer-to-peer networking). Appn is de volgende generatie van SNA en bouwt voort op de vele architecturale kwaliteiten van z’n voorloper. Binnen appn benadert een gebruiker het netwerk door middel van LU 6.2, dat ondersteund wordt via een applicatie-interface die bekend staat als Appc (application program to program communication). Appn creëert een zogenaamde class of service, waardoor gedistribueerde toepassingen beter beheerd kunnen worden.
TCP/IP
Vanwege de behoefte aan open, gedistribueerde computerarchitecturen en door de explosieve belangstelling voor het Internet – dat op dit protocol is gebaseerd – is de invloed van TCP/IP de laatste jaren sterk toegenomen. De rol van SNA is tanende en die van TCP/IP groeiende, omdat grote ondernemingen er meer en meer toe overgaan om hun zakelijke applicaties op Unix-platforms te draaien. Unix gebruikt van huis uit het TCP/IP-protocol. Ook IBM is ertoe overgegaan TCP/IP in haar bedrijfseigen besturingssystemen, OS/400 en MVS, te implementeren.
TCP/IP is een zogeheten peer to peer netwerkarchitectuur die gebaseerd is op het gegeven dat elke locatie die met IP geadresseerd kan worden, een host kan zijn. TCP/IP kent geen hiërarchische opbouw. TCP/IP-knooppunten communiceren met elkaar door middel van software voor verschillende applicatietypen, die zowel op de client als de server draait. Voor bijvoorbeeld een Telnet-sessie moet het netwerk-knooppunt over een Telnet-client beschikken, terwijl de host-computer een Telnet-server moet hebben draaien. Andere toepassingen zijn ftp (file transfer protocol) voor bestandsoverdracht en Snmp (simple network management protocol) om gegevens over netwerk-knooppunten op te vragen.
Applicaties binnen TCP/IP-netwerken krijgen toegang tot de transport-services door middel van een socket, die gezien moet worden als een recht-toe-recht-aan interface van het type ‘open-lees-schrijf’. Microsoft heeft een versie van deze interface, bekend onder de naam Windows Sockets (Winsock), in zijn Windows-produkten ingebouwd.
Naarmate netwerken groeien en de technologie complexer wordt, zoeken automatiseringsafdelingen naar manieren om het onderhoud van hun systemen te vereenvoudigen. Een methode om dit te bereiken, is de standaardisatie op een enkel netwerkprotocol. Vanwege de toenemende ondersteuning door diverse computerplatforms ligt TCP/IP dan voor de hand. Gelet op de huidige stand van zaken van deze technologie is de volledige vervanging van SNA door TCP/IP echter niet altijd een werkbare oplossing. SNA beschikt namelijk over enkele bedrijfskritische functies die TCP/IP eenvoudigweg niet biedt. De informatiseringsmanager dient dan ook precies te weten wat TCP/IP wel en niet kan, en een nauwkeurige afweging te maken van de verschillen in functionaliteit voor zowel eindgebruikers als systeembeheer, alvorens hij de beslissing neemt dit protocol binnen het bedrijfsnetwerk te introduceren. Het hieronder volgende voorbeeld uit de mainframe-wereld laat zien wat er gebeurt als SNA volledig vervangen wordt door TCP/IP.
TCP/IP met TN3270
Het voorbeeld betreft een recht-toe-recht-aan implementatie van TCP/IP in een mainframe-omgeving. Een Telnet-client maakt contact met een Telnet-server op het mainframe. Omdat de client via Telnet inlogt, is dat ook de plaats waar de sessie-services ondersteund worden.
Veronderstel dat de gebruikers hun SNA-toepassingen zonder verlies van functionaliteit willen draaien via TN3270 (de standaard voor 3270-sessies over Telnet). Dit betekent dat de volgende services onveranderd via TCP/IP beschikbaar moeten zijn: bestandsoverdracht, terminal-emulatie en afdrukfunctionaliteit. Met TN3270 levert bestandsoverdracht geen probleem op; terminal-emulatie en afdrukfuncties laten daarentegen enige beperkingen zien waarmee eindgebruikers te maken kunnen krijgen.
Het verzenden en ontvangen van bestanden is vanzelfsprekend een belangrijke functie binnen elk gedistribueerd verwerkingssysteem. Tegenwoordig wordt hier vooral een op 3270 gebaseerd mechanisme (Ind$file) voor gebruikt, dat ontwikkeld is om bestanden tussen PC’s en host-systemen te verzenden. Deze functie biedt niet alleen de mogelijkheid om een bestand te identificeren en te verzenden, maar handelt ook de verschillen in bestandsstructuur tussen PC’s en mainframes af. Bestandsoverdracht door middel van Ind$file kan onder TCP/IP worden afgehandeld zonder enige beperking in functionaliteit. Een van de belangrijkste afdrukfuncties is de bevestiging dat een afdruktaak ook daadwerkelijk is afgerond. Onder TN3270 is 3287 printer-emulatie alleen beschikbaar als bedrijfseigen oplossing van diverse makers van connectiviteitssoftware. In andere gevallen wordt de TCP/IP-standaard lpr/lpd (line print requester/line print daemon) gebruikt om afdrukopdrachten vanuit SNA-toepassingen naar een specifieke printer te sturen. Maar lpr/lpd is echter niet in staat om de genoemde afdrukbevestiging door te geven. Binnen een financiële omgeving, waar bijvoorbeeld een effectenhandelaar een bevestiging nodig heeft dat een order om aandelen te kopen ook inderdaad is ontvangen, is dit vanzelfsprekend een bedrijfskritische functie. Maar ook voor boekhoudafdelingen is het van belang; men moet er immers zeker van zijn dat bepaalde cheques geprint zijn.
Een andere SNA-functie die in TN3270 ontbreekt en waar eindgebruikers gewend zijn mee te werken, is de standaard- ondersteuning voor de attention– (attn) en system request– (Sysreq) toetsen. De laatste is met name handig wanneer een gebruiker heen en weer wil schakelen tussen verschillende applicaties. Deze toets koppelt de gebruiker los van de ene toepassing, maar laat de verbinding naar de host in stand. Daardoor kan hij een andere toepassing benaderen. Dit bespaart niet alleen tijd, maar geeft de gebruiker tevens meer controle over z’n werk.
TN3270E-oplossingen
De bovengenoemde beperkingen van SNA-applicaties die onder TCP/IP draaien, zijn grotendeels uit de wereld geholpen door een recentelijk geaccepteerde standaard die bekend staat als TN3270E (Extended). Dit uitgebreidere protocol, gespecificeerd in de RFC 1647 van het Ietf (Internet engineering task force), is gebaseerd op een document dat is geproduceerd door een senior-ontwikkelaar van WRQ, de eerste leverancier die client-ondersteuning voor TN3270E bood.
Deze nieuwe specificatie heeft aan het afdrukken via TCP/IP het soort controle toegevoegd dat bepaalde mainframe-operaties vereisen. Naast het bevestigen van een afdrukopdracht voorziet TN3270E ook in resource association en Sscp-ondersteuning.
LU-devices in een SNA-netwerk zijn zogenaamde ‘bekende’ resources: via hun specifieke netwerkadressen kunnen ze aan bepaalde gebruikers of groep gebruikers worden toegewezen. De mogelijkheid om deze resources te groeperen is van groot belang, want dat maakt het mogelijk dat applicaties hun afdrukuitvoer direct naar d�e printer sturen die gekoppeld is aan een bepaalde gebruiker of werkgroep.
Ondersteuning voor Sscp is belangrijk voor de functionele mogelijkheden van een 3270-gebruiker, omdat hij daardoor tijdens een sessie de beschikking krijgt over veel SNA-functionaliteit.
Snmp
TCP/IP mist een significant aantal beheerfuncties waarmee gebruikers van SNA-networking vertrouwd zijn. In de SNA-omgeving gebruiken systeembeheerders Netview, een state-of-the-art beheersysteem waarmee netwerkbeheerders al het verkeer tot op de LU-laag kunnen bekijken. Netview voorziet in de mogelijkheid om het prestatieniveau van het SNA-verkeer a priori te modelleren en tijdens gebruik te controleren. Tevens zijn er gegarandeerde responstijden mee in te stellen. Daarnaast beschikt Netview over uitgebreide tools voor troubleshooting.
De datastroom binnen TCP/IP is niet-deterministisch van aard. Dit betekent dat het niet mogelijk is om netwerkverkeer te modelleren of te voorspellen. Gegarandeerde responstijden zijn derhalve binnen een TCP/IP-omgeving niet realiseerbaar. Snmp – de managementstandaard binnen TCP/IP-omgevingen – is niet in staat de protocollen of de gegevensstroom te beheren op de manier zoals Netview dat doet. Wanneer SNA-gegevens eenmaal het TCP/IP-netwerk binnengaan, verliest Snmp deze uit het oog.
Er wordt aan gewerkt om dit zwarte gat in Snmp te dichten. SNA-mib’s (management information blocks) bestaan al op sommige gateways. En diverse partijen onderzoeken de mogelijkheid om Netview aan Snmp te koppelen of om het TCP/IP beheerprotocol uit te breiden. Niettegenstaande deze inspanningen zullen aan TCP/IP gerelateerde beheerkwesties de komende jaren blijven bestaan.
Een ander beheerprobleem heeft betrekking op beveiliging. Racf (resource access control facility, het beveiligingsmodel binnen de mainframe-wereld) beperkt de toegang tot applicaties en subsystemen. Kerberos – de beveiligingsstandaard van TCP/IP – beperkt alleen de toegang tot servers, maar niet die tot specifieke applicaties of subsystemen.
Racf werkt onder TCP/IP met een bijna volledige functionaliteit. De enige uitzondering is dat een eindgebruiker niet kan inloggen op een specifieke terminal. IBM’s laatste implementatie van TCP/IP bevat hiervoor echter een oplossing, waardoor een specifiek IP-adres wèl aan een specifieke LU toegekend kan worden. IBM werkt ook aan integratie van Kerberos en Racf, waardoor Racf-validaties toegankelijk worden voor Kerberos.
Netwerkbeheer en beveiliging verdienen de meeste aandacht bij het gebruik van TCP/IP in een mainframe-omgeving.
Hieronder komen de gevolgen aan de orde van een migratie van SNA naar TCP/IP binnen de AS/400-omgeving.
TN5250
Wat betekent de migratie van SNA naar TCP/IP voor de gebruikers? Het toepassen van TCP/IP in een AS/400-omgeving is alleen zinvol in combinatie met Versie 3 Release 1 (V3R1) van het besturingssysteem OS/400. IBM heeft de implementatie van TCP/IP in deze versie drastisch verbeterd. In eerdere versies was het toepassen van TCP/IP binnen de AS/400-omgeving praktisch onmogelijk, omdat het tot prestatieproblemen leidde en bovendien het aantal mogelijke connecties aanzienlijk beperkte.
Het gebruik van het TCP/IP-protocol binnen een AS/400-omgeving vereist een Telnet-client die verbinding maakt met een Telnet-server op de AS/400. TN5250 is de standaard voor AS/400-sessies onder Telnet. De 5250-functies die AS/400-gebruikers willen toepassen zijn terminal-emulatie, afdrukken, het delen van bestanden en bestandsoverdracht. Met 5250 zijn de eerste drie functies echter beperkt beschikbaar, terwijl de laatste in het geheel niet werkt.
Met betrekking tot terminal-emulatie biedt TN5250 bijna alle functionaliteit van z’n Appc-equivalent, de display station passthrough. Alleen enkele PC-Organizer-functies, zoals Strpccmd, zijn niet beschikbaar onder Telnet.
Lpd-afdrukken is grofweg het equivalent van lokaal afdrukken zoals dat binnen Appn gebeurt. Alleen op het gebied van font-mapping blijft lpd wat achter. Lpr is een benadering van Virtual Print, een methode voor een PC-werkstation om de afdrukopdrachten naar host-printers te sturen.
Het concept van het delen van bestanden heeft z’n oorsprong binnen de TCP/IP-wereld met nfs (network file system). In de AS/400-wereld maken Shared Folders – een Appn-toepassing – het delen van bestanden mogelijk. Nfs en Shared Folders hebben in essentie dezelfde functionaliteit. Nfs vereist wat meer software op de AS/400 en voegt een extra beheerlaag toe, maar de eindgebruiker merkt geen enkel verschil. Met nfs kan elke computer worden ingericht als een file-server waarvan de bestanden, die zich op de lokale schijf van de gebruiker lijken te bevinden, voor iedereen toegankelijk zijn.
Bestandsoverdracht – of beter gezegd data transfer – is het grote struikelblok van TCP/IP binnen de AS/400-omgeving. Er ligt een enorme hoeveelheid bedrijfsinformatie opgeslagen in IBM’s DB2-databases, met meer dan 300.000 licenties voor DB2/400. Onder Appn is de gebruiker in staat om zeer geavanceerde zoekopdrachten voor deze databases te formuleren, waarbij hij of zij de informatie per veld kan opvragen, in plaats van per bestand. Met het protocol voor bestandsoverdracht (ftp) van TCP/IP is slechts een héél bestand te verzenden en ontbreekt ondersteuning voor SQL-queries. Maar ook bij de verzending van een heel bestand functioneert ftp niet altijd even onberispelijk. De meeste AS/400-databases slaan numerieke gegevens op in zogenaamde packet-fields, maar ftp weet geen onderscheid te maken tussen alfanumerieke data en deze ‘packet-fields’. Om deze reden leiden de meeste bestandsverzendingen via ftp binnen een AS/400-omgeving tot beschadigde gegevens.
Mptn-oplossingen
De Mptn-technologie (multi-protocol transport networking) die is ontwikkeld door IBM, heft deze beperking op en stelt applicaties in staat een sessie tussen twee incompatibele netwerken op te bouwen, gegevens te verzenden en een toepassing op zo’n incompatibel netwerk te draaien. Zo kan een toepassing die geschreven is voor Appc/LU 6.2 via Mptn onder TCP/IP draaien. Mptn maakt hiertoe een vertaalslag via een mechanisme dat common transport semantics heet. De calls die een toepassing naar een specifiek netwerk maakt (Appn), worden geïnterpreteerd en vertaald naar acties op een ander netwerk (sockets). Door middel van Mptn kan een toepassing dus gewoon ‘zijn eigen taal blijven spreken’ (in dit geval Appc), maar toch getransporteerd worden over elk type netwerk. Met Mptn vervalt dus de noodzaak voor werkstations om meerdere protocollen te laden; er wordt slechts een enkel protocol gebruikt om applicaties transparant onder Mptn te draaien.
IBM’s produktnaam voor Mptn is Anynet. Elke AS/400 – draaiend onder OS/400 V3R1 – die IBM op dit moment verkoopt, beschikt over een Anynet-server. Als er ook een client-deel aanwezig is, neemt Mptn de beperkingen van TCP/IP op het gebied van terminal-emulatie, afdrukken, delen van bestanden en dataverzending voor z’n rekening.
Effecten op netwerkbeheer
TCP/IP leidt tot enkele beperkingen met betrekking tot het netwerkbeheer. TN5250 kan bijvoorbeeld niet gebruikt worden om een logical unit via zijn naam te benaderen, omdat TCP/IP dergelijke randapparatuur uit een beschikbare ‘pool’ willekeurig aan een gebruiker toekent. Er is geen methode om zo’n randapparaat zelf toe te kennen. Afdrukken met lpd en lpr kan een zware belasting voor de AS/400 betekenen, omdat de host-machine verantwoordelijk is voor het converteren van Ebcdic naar het karaktergeoriënteerde formaat van TCP/IP. En dat kan vele processor-cycli kosten. Maar het echte beheerprobleem treedt op met client/server-applicaties die voor Appn zijn geschreven. Zolang deze niet herschreven zijn, zullen ze niet onder TCP/IP draaien, omdat significante delen van de AS/400 gesloten zijn voor directe toegang via TCP/IP. Krachtige functies – zoals data-queues en message-queues – kunnen weliswaar beschikbaar worden gemaakt via Lipi’s (licensed internal program interfaces), maar deze zijn weer alleen via Appn toegankelijk.
In zijn poging om de AS/400 als de ideale computer voor een open, gedistribueerde computeromgeving te positioneren, probeert IBM iets aan deze beperkingen van TCP/IP te doen. Het bedrijf heeft beloofd de Lipi’s toegankelijk te maken voor Windows Sockets, de open api (application program interface) voor TCP/IP.
Andere opties
Buiten Mptn zijn er gateways en emulatoren beschikbaar die het mogelijk maken om de twee verschillende netwerktypen naast elkaar te gebruiken zonder dat de eindgebruiker daarvan hinder ondervindt. Voorbeelden daarvan zijn Microsofts SNA Server en het door IBM en Novell samen ontwikkelde Netware voor SNA. De clients hoeven binnen deze omgevingen slechts één netwerkprotocol-stack te draaien – TCP/IP – alsmede emulatie-software. Deze software wordt over het netwerk getransporteerd naar de gateway, die SNA-sessies en netwerkservices ondersteunt. Van de gateway naar de host verloopt alles via SNA. Bestaande applicaties hoeven niet gemodificeerd te worden om binnen deze configuratie te draaien; de eindgebruiker beschikt over alle SNA- of Appc-functionaliteit waar hij of zij aan gewend was.
Data link switching (Dlsw) is een andere optie om TCP/IP met SNA te integreren. Dlsw is een technologie van IBM waarmee SNA via routers verzonden kan worden door gebruik te maken van IP-inkapseling. Een nadeel van dlsw is dat het niet in alle situaties feilloos werkt, in het bijzonder niet wanneer bijkantoren toegang moeten hebben tot SNA-toepassingen. Daarnaast biedt Dlsw uitsluitend een oplossing voor netwerktransport en verschaft het geen interoperabiliteit of integratie van gebruikers of applicatiesystemen.
Nauwe samenwerking
TCP/IP- en SNA-applicatiesystemen en -netwerken vereisen een nauwere integratie. Gegeven de verschillen tussen beide architecturen zullen zij naast elkaar moeten bestaan, totdat een bedrijf besluit geheel over te stappen naar de architectuur van de volgende generatie.
Voor het bouwen van zo’n nieuw, heterogeen netwerk is een nauwe samenwerking van een bedrijf met een of meer strategische verkooppartners van wezenlijk belang. En hoewel het verlaten van de traditionele IBM-omgeving als uitdaging kan worden ervaren, wordt daarmee ook onbekend terrein betreden. Geen enkel bedrijf kan het zich veroorloven een dergelijke migratie in gang te zetten zonder een goed doortimmerd overlevingsplan opgesteld te hebben. Een ononderbroken functioneren van de informatiesystemen is immers van essentieel belang voor de meeste organisaties.
Bij het plannen, initiëren en onderhouden van de systemen van de volgende generatie zullen bedrijven een grondige analyse van hun informaticabehoeften en van hun IT-leveranciers moeten maken. In de meeste organisaties die mainframes en midrange-systemen van IBM gebruiken, is al een aanzienlijke expertise met SNA aanwezig die aangewend kan worden voor dit deel van het migratietraject. Voor het andere deel van dit traject zullen bedrijven echter een grondige kennis op het gebied van TCP/IP verlangen van hun IT-leveranciers. Alleen wanneer deze IT-partners bereid zijn te luisteren en meer inzicht krijgen in de operationele aspecten die zich aandienen wanneer TCP/IP in het bedrijfsnetwerk wordt geïmplementeerd, kan een dergelijke ingrijpende operatie met succes worden afgerond.
Deric Villanueva is produktmanager van Reflection produkten voor IBM netwerkcommunicatie bij WRQ.
