OS/2 - EPBcn - Espacio Psicoanalítico de Barcelona · OS/2 Interoperabilidad de redes y...
Transcript of OS/2 - EPBcn - Espacio Psicoanalítico de Barcelona · OS/2 Interoperabilidad de redes y...
• •••••••• ••• ••• •• •• ••••••• •. ...:••••••
({j) SCD'¡jlJe
•••• •••••• ••• ••• •... ' ... ', .•••• ••••••• ••••.....:(e)
OS/2
Interoperabilidad de redes y
multiprotocolo en OS/2 Warp 3.0
STE artículo es una introducción a la interoperabilidad de redes y el multiprotocolo en OS/2 Warp 3.0, y recogealgunas de las experiencias desarrolladas por él autor en diversassecciones de la Universidad de Barcelona (Servicios Informáticos dela UB, Servicio de Lengua Catalana y Escuela de Idiomas Modernos)durante los últimos cuatro años.
El problema de la interoperabilidad
Cada día más instalaciones informáticas se encuentran con la necesidad de explotar simultáneamente entornos de red distintos, y hacerlos interoperables entre sí. Una pequeña empresa puede tener susbases de datos en un AS/400 y utilizar a la vez una red Novell o LANServer; una gran emp,resa contará probablemente con un mainframepara las aplicaciones corporativas, redes locales en las distintas sucursales, y probablemente algunos minis. Las aplicaciones son caras yestán optimizadas para el tipo de plataforma para el que fueron diseñadas, lo que en muchos casos hace inviable económica o técnicamente su migración a una única arquitectura. Por otra parte, la revolución microinformática de los últimos años ha puesto unmicroordenador en cada puesto de trabajo, y para esos entornos lo
José María B/asco
José María Blasco, nacido en 1960, es Licenciado en Matemáticas por la Universidadde Barcelona. Ha sido profesor de Program(lción en la Facultad de Infortmitica deBarcelona, y Coordinador Nacional de la red EARN en Alemania. Ha ti'a6ajado comaanalista de sistenws para los Servicios Informáticos de la Univesidad de Barcelona y laempresa alemana GMD. En la actualidad trabaja como integrador de sistemas y consul·tal' informático independiente. Sus lemas de interés más recientes son las redes, enlomasobjetLlales de trabajo y desarrollo, las plataformas de integración como OS/2, y las aplicaciones cliente/servidor. Su E-MAIL es:[email protected]
RPP Nº 7
75
ideal es una red local. El mismo usuariodeberá, en muchos casos, acceder a todosesos entornos, como mínimo secuencialmente, y a ser posible, simultáneamente.Es lo que llamamos interoperabilidad.
Además, los protocolos de comunicación utilizados diferirán en cada caso (IPXpara Novell Netware, NetBIOS para LANServer, LAN Manager y Windows forWorkgroups, IP para el acceso a hostsUnix, SNA para el acceso a mainframesIBM, ... ). Una estación de trabajo idealdeberá ser capaz de manejar simultáneamente y de un modo transparente para elusuario todos esos protocolosde comunicación, de modo que el usuario pueda accec
der a los diversos recursos que la red a laque tiene acceso le ofrece, sin necesidadde saber cuál es la tecnología subyacente,concentrándose así en qué desea hacer envez de en dónde están los datos, o, mucho
.peor, en cómo acceder a ellos.Una preocupación de este estilo es de
importancia cada vez mayor a medida quecrece la complejidad de un parque informático. Una pequeña empresa que disponga de una red Novell estará utilizando multiprotocala si instala Windows farWorkgroups 3.1 (lPX para Novell yNetBIOS pata WfW), pero si se usa WfW3.11 podrá operar tan solo con IPX.Acceder simultáneamente a redes Novell,minis Unix y unos cuantos AS/400 seráalgo más complicado, y la complejidad
2
Figura A Acceso simultáneo a DOS, Windows, OS/2, unmoinframe IBM 3090 con emulación de terminal 3270,y un mini Unix con X-Windows. La captura de pantalla es de 1992
la plataforma se convierte en un asunto muchomás grave.
Necesitamos además poder realizar cualquier acción con nuestra estación de trabajosin comprometer la estabilidad de las comunicaciones, y ser capaces de cancelar las comunicaciones colgadas sin afectar a las demás.Queremos decir que hemos de poder ver esevideo que nos envió el jefe mientras estamosformateando un disco óptico o un diskette, ymientras se está realizando un download deFTP en una ventana y una reorganización masiva de una base de datos remota en otra, y todoeso con la asiduidad necesaria, y sin temer porlos resultados de las demás sesiones si una deellas nos da algún problema. Y, naturalmente,sin perder la posibilidad de usar las aplicaciones OS/2, DOS Y Windows a las que estamosacostumbrados.
En DOS/Windows la interoperabilidad esun drama. Cada protocolo requiere de una seriede drivers específicos, que ocupan parte de lasiempre escasa memoria que más tarde deberán utilizar los programas. Al instalar un nuevodriver, muchas veces dejan de funcionar losantiguos, o se pierde alguna configuración cuidadosa del CONFIG.SYS o del AUTOEXEC.BAT, o, aún peor, del WIN.INI. Una vezse han solucionado los problemas (si es que esposible hacerlo), nos encontramos con que elespacio máximo para ejecutar un programa hadecrecido hasta tal punto que se hace imposible cargar aplicaciones que antes funcionabancorrectamente. En OS/2 nada de esto sucede,ya que es posible tener tantos drivers cargadoscomo se quiera y disponer aún de 620K en cadasesión DOS para poder ejecutar con comodidad los programas que deseemos; esto se debea que los drivers OS/2 se cargan en el espaciode memoria de OS/2, y los servicios de red sevirtualizan en cada sesión DOS, sin ocupar apenas memoria.
Estas son algunas de las reflexiones que meimpulsaron a considerar OS/2 como la plataforma idónea para la mayoría de los usuariosuniversitarios, tamo ieorificos como administrativos, desde la apari -ón de la versión 2.0.OS/22.0 apareció a la \-ez que Windows 3.1,y en aquel rnomemo la ineroperabilidad enWindows era simplemente imposible (la cosano ha mejorado mucho de de entonces), yWindows como plataforma era -urna menteinestable (cosa ue no ha ambia o). Por otraparte, O 1 ha madllI'ado mu -ho desde entonces: hemos t nido oc ióu de abajar <-on OS/22.0 LA O 12.0 G.\. O __ .1. O 22.11, YOS/2 3.0 Warp \"ersion or \\;Jldows y FullPack), además de la - d: "_ a \- r iones betas,
&.;.. 1 CQI1 .' lSO%·
crecerá si nos trasladamos a una gran empresa, en la que contaremos casi con seguridadcon algún tipo de mainframe. El caso más complejo posible lo podremos encontrar en algunosentornos universitarios, donde a la diversidadpropia de toda institución grande habremos deañadir la derivada de la variedad de equipos,producto de la autonomía de compra de losdiversos departamentos.
Cuando nos enfrentamos a entornos de redcomplejos, la estabilidad de la plataforma se
convierte en unacuestión cruciaLSi la mayoría deltrabajo lo realizamos en nuestro ordenador, y sólo devez en cuando nosconectamos a unaNovel! para leer ograbar algún fichero, podemostolerar que el ordenador se "clave" cada tanto poruna General Protection Fault: re-botamos el ordenador, y ya está.
Pero si una clavada significa restablecer comunicaciones con seis o siete servidores distintos(que además utilizan diversas tecnologías), variasbases de datos, y unas cuantas sesiones conmainframes y hosts Unix, la inestabilidad de
Este documento proporciona intonnación acerCa de lasconversiones entre dilerentes fonnatos de archivo. Tommodilicadores de opciones de conversión para el archiv
.~ --~-~lh,Jar""c....hl..d.·vo~s~par~a...m~a."pe"l'0-'1"de~fu""eJ.nt~es~. .,;¡.,....do.-Lc.u,;.,w.....f:!Fl+,
Laf.j.Z2 t&fn ~ See 1~ :i~2i~- . A
En DOSrWindows lainteroperabilldad es undrama. Cada protocolo
requiere de una sel;e dedrivers específicos, que
ocupan parte de la. siempreescasa menloria que más
tarde deberán utillzm'los programas.
<!~ yerfuso~.l1za:
RPP Nº 7
76
~: OS/2
T(~p/IP está pensadopara seguh' funcionandoaunque algunos de los
nodos caigan bajoluego enemigo,
cOIDtmicaci.onesvan a utHizm.·,
Cuando dosprogramas residentes
en ordenadoresdistintos necesitanconnullcal~c,deben
estar de acucl'do enCótno "an a hacerlo,
es decir, en quéprotocolo de
Server y DB/2 puedenhablar los dos NetBIOS olos dos IP (utilizandoNetBIOS sobre IP), con loque si éstas son las únicasaplicaciones que utilizamos no necesitamos delmultiprotocolo, ya quesólo existe uno.
Cuando la misma placade comunicaciones necesita manejar más de unprotocolo, se hace necesaria la presencia de undiscriminador de protocolo, que examine lospaquetes que provienen dela red y los reencamine aldriver y al programa ade-cuado. Con eso se consi-gue que cada protocolopueda operar como si fuese el único que funcionase en la placa, implementando efectivamente lo que se conoce como una pila de protocolos o protocol stack.
Un ordenador con DOS y Windows conectado a una red Novell normalmente utiliza undriver (IPX) que se encarga de manejar lospaquetes IPX utilizados para comunicarse conel servidor Netware. IPX controla en exclusiva la tarjeta de red, y, si llega un paquete perteneciente a otro protocolo, lo descarta o da unerror. Por el contrario, cuando contamos conun protocol stack, el control de la tarjeta dered lo realiza un programa (en el caso de NDISpara OS/2, PROTMAN) que examina cadapaquete, decide de qué protocolo se trata, y loentrega al driver específico de ese protocolo. Eldriver no controla la tarjeta de red, sino que secomunica de forma ordenada con PROTMANpara permitir la operación simultánea de variosdrivers, cada uno encargado de un protocolo distinto. Por ejem
plo, NovelJ sobre NDIS en OS/2cuenta con un driver (ODI2NDIS.OS2) que recoge los paquetesIPX de PROTMAN y los entrega ala pila NoveJl (LSL.SYS, IPX.SYS,SPX.SYS, etc), y viceversa.
En OS/2, el protocol stack másconocido es NDIS, aunque Novellproporciona una versión de ODIpara OS/2, con una funcionalidadequivalente. El problema con ODIde Novell es que si se desea utili·zar productos no Novell, que soncasi todos NDIS, habremos de con-
tar con un emulador de NDIS sobre ODI (la opción ODINSUPdel cliente Novell para OS/2), con lo que terminamos por tener
El multiprotocolo
y sin mencionar los distintos Service Packs, allídonde Windows no ha producido ninguna versión nueva, si descontamos las versiones forWorkgroups y Windows NT, que es una plataforma distinta, cara e incompatible. Y lomismo ha sucedido con los productos de red ysu capacidad para trabajar juntos. Desde 1992hasta ahora se ha simplificado enormementela instalación de los diversos productos de reddisponibles para OS/2, además de haberseampliado notablemente el soporte para distintos tipos de red, adaptadores, etc.
Cuando dos programas residentes en ordenadores distintos necesitan comunicarse, debenestar de acuerdo en cómo van a hacerlo, esdecir, en qué protocolo de comunicaciones vana utilizar. Para simplificar, cada protocolo esuna especie de "lenguaje de red" distinto. Hayarquitecturas de red, como SNA de IBM, quetienden a una administración centralizada ypriman la fiabilidad y la detección de errores:si un ordenador de comunicaciones de un bancodeja de funcionar, una zona entera de oficinaspuede quedar sin servicio, y por lo tanto esesencial asegurar la fiabilidad de las comunicaciones y saber cuáles son los equipos que hayque reemplazar si surge algún problema. Otrasarquitecturas, como TCP/IP, que fue diseñadopara el departamento de defensa de los EstadosUnidos de América para operar fiablemente entiempo de guerra, están pensadas para la administración descentralizada, y no importa tantola fiabilidad como el intentar asegurarse de quelas comunicaciones siguen funcionando aunque parte de la red deje de ser operativa: TCP/lPestá pensado para seguir funcionando aunquealgunos de los nodos caigan bajo fuego enemigo.
Igualmente, hay protocolos pensados paragrandes redes (como el propioTCP/lP o SNA), y protocolos queno pueden ir más allá de una redlocal (como NetBIOS). Para cadauno de esos protocolos hay aplicaciones y servicios de red quelos hacen útiles; en la Universidadde Barcelona, se utilizan todosellos.
La necesidad de multiprotocolo aparece cuando intentamosacceder simultáneamente a doso más servicios de red que utili-zan protocolos distintos. Nóteseque esto no sucede siempre que queremos'acceder a dos servicios distintos: por ejemplo, LAN
RPP Nº 7
77
052
NDIS, LAPS, MPTS
Figura B Pantalla de configuración de MPTS (LAPS¡
DriverName " tcpbeui$Bindings • EL.3I.BM02 nifOS2TRACEMASK ~OXO SESSIONS • 130 .NCBS = 225NAMÉS = 21SELECTORS =;15OSEMAXDATAGRAM = "NO"NETBIOSTIMEOUT • 500NETBIOSRETRIES = 2,NAl'1ECACHE = OPRELOADCACHE ··"NO"NAMESFILE - O·DATAGRAMPACKETS • 20PACKETS. - 50
[TCPIP.:.n",Ú
ODI2NDI nif =ODI2NDI. NIFTCPBEuI=nif = TCPBEUI;NIFTCPIP ¡lif. = TCPIP .. NIFEL3IBM02_nif= EL3IBM02.nif
[NETBIOS]
Listado 1.- Fichero PROTOCOL.lNI
DrivetName = ELNK3$M~xTransrnits = 20
[PROT_MANl
DRIVERNAl'1E' = PROT¡ilAN$
[EL3IBM02_nH l
DriverName ~ TCPIP$Bindings :.. EL3IBM02_nif
[IBMLXCFG]
DriverName ",'netbi'ós$ADAPTERo = tcpbeúi$,O.
[ODI2NDI~nifJ
·Dr.iv~rName .. 'odi2ndi$Bindings." EL3IBM02 niÍNETADDRESS = "002-OAF43EC77"TOKEN-RING '"" "no"TOKEN-RING SNAP = "no"ETHERNET ·S02.3;': "yes';ETBERNET"'-S02.2 = "no".ÉTHERNET=Ir 7 "no"E;THERNET SNAP ",'''no''TRACE = OxO
ce la pantalla de configuración del programa.El programa nos permite elegir la(s) placa(s)
de comunicaciones de que dispone nuestro ordenador (arriba a la izquierda) , y para cada unade las placas, los protocolos de comunicaciones que se utilizan sobre esas placas (arriba ala derecha). El resultado aparece en otro recuadro (abajo a la izquierda), desde donde podemos cambiar los parámetros propios de la placao de cada uno de los protocolos de comunicaciones asociados con esa placa.
La interface gráfica es bastante sencilla,teniendo en cuenta la complejidad subyacente
Seleccione Blénal "naUtar,
Configuración actual---
Para edllar parámetros de controlador. seleccione uno de1"5 elementos siguientes y después seleccione Editar.
protocolos sobre la pila NDIS, que a su vez seasienta sobre la pila ODI. Implementar Novellsobre NDIS requiere del mismo truco, pero alrevés, ya que Novell sólo proporciona un cliente ODI para OS/2. En este caso, tenemos elcliente Novell corriendo sobre la pila ODI, quecorre sobre la pila NOlS (se trata del driverODI2NDI.SYS de IBM).
Nos decidimos por la segunda aproximación (es decir, l\1DIS y OOl sobre NDIS) por dosrazones: la primera es que, excepto el clienteNovell, todos los productos que utilizamos(acceso a LAN Server, DB/2, emulación 3270,TCP/IP, etc.) están escritos para NDIS; la segunda es la deficiente calidad de soporte que engeneral hemos sido capaces de obtener de losrevendedores de Novel!.
NDIS es una arquitectura multiprotocolo desarrollada por Microsoft, 3Com e IBM; la versión2 es la propia de OS/2. Los primeros productos de IBM requerían la construcción a mano,o al menos la modificación, de los diversosficheros que definen el acceso a la red, peroúltimamente se está produciendo una convergencia de los programas instaladores en lo queprimero se bautizó como LAPS (LAN Adapteran.d Protocol Support) y ahora se conoce (en laversión que viene con LAN Server 4.0) comoAnynet o MPTS (Multiple Protocol TransportServices). Las noticias que tenemos de las betasde ia versión cliente de OS/2 Warp 3.0 indicanque probablemente esas capacidades estaránintegradas en la versión base de ese producto.
Instalar soporte para multiprotocolo con elMPTS de LAN Server 4.0 es muy sencillo: bastacon utilizar las diversas posibilidades que ofre-
...t1<)Ur~e16n dO' I APS • ._ .
Seleccione un adaptador de red y luego los protocolos que lo acompañan.
Adaptadores de red ···Protocolos -.-_.
Adaptador 1614 Busmaster EISA IB~l I "1 ~~M OS/2 N'ETBIOS IAdaptador 1614 de Red en Anillo Raco Soporte de Peticionario Net', IAdaptador 1.6!~!~~2oke~Express~t~'j ~~~_~~:~ NETB~O~SOBR~:~ I
~ l;.ambl2lrll 01ros adaptadores... 1 Ii Aliadlr I rOtros Qro~ocolos ... 11
9 .. Soporte de Peticionario Netware de IBM I . ªIen 19 - IBM OS/2 NETBIOS SOBRE TCP/IP
e -IBM T~!,~~_._______ ..J rC2l~~-;¡;-1 1L-==~~d=lt=a:;:r~I!:1=EI-~lm~¡;;=·~::r-~I_.::.:C=--;;=~=bl=21r~.!!~T=m=·;r-=..~=.,.==~'_I~::;-;;;;._::._=..=..=.. ,~I_:..:::=AY:=u=d=a:I_.J
RPP Nº 7
78
OS/2
Figura e Novell Netware e IBM LAN Server seintegran de un modo homogéneo en OS/2
TCP/IP), TCPIP (TCP/IP), y EL3IBMOS2, parael driver NDIS de la placa 3Com Etherlink III.Los ficheros NIF a los que se hace referenciaguardan los valores por defecto para esas placas yesos protocolos, y se encuentran enC:\IBMCOM\MACS y C:\IBMCOM\PROTOCOL. En el CONFIG.SYS, estas lineas se traducen por inclusiones de los correspondientesdrivers:
DEVICE=C:\MPTN\PROTOCOL\MPTN.SYSDEVICE=C: \ MPTN\ PROTOCOL\ LIPC. SY8DEVICE=C: \ MPTN\ PROTOCOL\ INET. 8Y8DEVICE=C: \ MPTN\ PROTOCOL\ IFNDI8. 8Y8RUN=C:\MPTN\BIN\CNTRL.EXE IP mptn_os$mptn_in$CALL=C:\OS2\CMD.EXE IQ IC C:\MPTN\BIN\MPTSTART.CMDRUN=C:\lBMCOM\PROTOCOL\NBTCP.EXEDEVICE=C:\IBMCOM\PROTOCOL\TCPBEUI.OS2DEVICE=C: \IBMCOM\PROTOCOL\ODI2NDI:OS2DEVICE=C: \IBMCOM\PROTOCOL\NETBIOS.082DEVICE=C: \lBMCoM\MAC8\ELNK3 .082
vi--'
-=:J~kJ
~JSeudónimos para el Dominio EIM
CJ NetWare
El BACa
El BIBLIa
Iªl CAUCHY
• Reel - Vista ele árbol
del problema. La implementación también esbastante sencilla: los resultados de las elecciones del usuario se guardan en un fichero ASCIIllamado PROTOCOL.INI, que se encuentraen el directorio C:\IBMCOM (suponiendo,como lo haremos en todo el artículo, que C: esla unidad de boot de OS/2), y en CONFIG.SYS;de sincronizar esos dos ficheros se encargaMPTS. Vamos a examinar elfichero PROTOCOL.INI correspondiente a la figura, comentando a la vez algunos de los efectos que tienenlas distintas opciones en el CONFIG.SYS.
Hay que resaltar que este fichero ha sidogenerado automáticamente. por MPTS; nosotrossólo tuvimos que especificar en el programaMPTS la dirección de placa y el tipo de framepara el cliente Novell, ya que éste lo requiere.
La sección [PROT_MAN] establece cuál esel administrador de protocolos o (PROTocolMANager). Este es, por defecto, el proporcionado por el sistema, PROTMAN.OS2:
Los demás apartados de PROTOCOL.INIespecifican los parámetros correspondientes alos protocolos y placas utilizados; si el usuariocambia algún parámetro, el cambio queda reflejado en PROTOCOL.INI, mientras que losficheros .NIF originales no se cambian; MPTSrealiza una fusión de los distintos .NIFs conPROTOCOL.INI, dando primacía a este último. Por ejemplo, en la sección para soporteNovell se observa la presencia de una direc-.
1\1)IS es lila arquitectura mu1tiprotoco~
lo desarrollada por :MiCl'OSOft,
3Comem.M
DEVICE=C: \IBMCOM\PROTOCOL\LANPDD.OS2DEVICE=C: \IBMCOM\PROTOCOL\LANVDD.OS2DEVICE=C: \lBMCOM\LANMSGDD.OS2 II:C: \lBMCOMDEVICE=C:\IBMCOM\PROTMAN.OS2 II:C:\IBMCOM
Las primeras líneas virtualizan la red para lassesiones DOS; la tercera añade soporte paramensajes y errores de red, y la cuarta es la referencia al mencionado PROTMAN.
Li sección [IBMLXCFG] establece cuálesson las placas y los protocolos que se utilizarán en conjunto. Aquí encontramos referenciasa ODI2NDI (ODI sobre NDIS, para el clienteNovel!), TCPBEUI (para NetBIOS sobre
ción hardware de placa (requerida por Novel!para el cliente OS/2). Se observará también lapresencia de enlaces (bindings) de cada protocolo a una o más de las placas (son las líneas"Bindings =" de las secciones correspondientesa los protocolos).
Un.a vez están cargados todos los drivers, seejecutan las siguientes dos utilidades:
CALL=C:\ IBMCOM\PROTOCOL\NETBIND.EXERUN=C:\IBMCOM\LANMSGEX.EXE
NETBIND activa las placas y los protocolosde comunicación, y avisa si hay algún error, a
RPP NI! 7
79
s'/s
Figura O
AbrirValoresAyuda
Crear somQra...SURrlmlr...
Recojer
Acceder a otro...Desconexión...Asignar unidad...B!!!:t~ar ...
PO P1
l:tJII..
MAILQUEUE
la cual cuelgan los servidores accesibles; losservidores, a su vez, pueden abrirse (si se dispone de los privilegios adecuados para ello), yaumentan la profundidad del árbol correspondientemente. Como por ese método podemos ir abriendo sucesivamente carpetas hastallegar al último subdirectorio, disponemos deuna visión integrada de la red, una especie deAdministrador de Ficheros de Windows, peroen serio, objetual, de red, y con la ventaja deque no es necesario asignar letras de unidadpara operar con los ficheros (si disponemos deprogramas que soporten UNCs).
Si lo que deseamos es trabajar con letras deunidad, no hay nada más sencillo (Figura O).
Basta con señalar la carpeta de red deseaday asignarle una letra de unidad. Nótese que elprocedimiento es el mismo independientemente de que estemos trabajando con Netware o conLAN Server.
Las interfaces de usuario
través de LANMSGEX. Si todo funciona bien,estamos preparados para trabajar, y disponemos de acceso a las placas y a los protocolosdefinidos. (No hemos entrado en el detalle parala instalación del cliente Novell, ni en la configuración de TCP/IP, que ocuparían demasiado espacio, aunque son igualmente sencillas).
Conclusión y perspectivas
MPTS incluye NetBIOS sobre TCPIIP, para podercorrer aplicaciones NetBIOS sin utilizar NetBIOSnativo (10 cual permite tener clientes de aplicaciones NetBIOS que estén fuera de la LAN oMAN de origen), y, curiosamente, un nivel deTCPIIP sobre NetBIOS, para correr aplicacionesTCP/IP en una LAN que ya está utilizandoNetBIOS nativo sin incurrir en el esfuerzo extrade utilizar el multiprotocolo. La estrategiaAnyNet de IBM permite correr programas APPC(una especificación API originalmente pensadapara SNA) sobre TCP/IP. Algunas aplicaciones(como el Person-to-Person [P2P] incluido en elBonusPack de OS/2 Wárp) pueden comunicarse indistintamente mediante IP, IPX o NetBIOS,o un módem, dependiendo del software instalado;la funcionalidad es la misma. Éstas parecen serlas tendencias generales del software: por unaparte, soporte y coexistencia de todos los protocolos; por otra, definir niveles de abstracciónen las comunicaciones, de modo que dos programas puedan comunicarse sin que importe elprotocolo utilizado; finalmente, como hemosvisto, se empiezan a encapsular unos protocolosen otros para los casos en los que no sea posible utilizar los nativos. Se tiende a pensar losdistintos protocolos como niveles de transporte, y definir APIs independientes de transporte.A la larga, estas tendencias no pueden sino redundar en programas más flexibles, redes más sencillas, y, en general, en más facilidad de uso delas redes. LAN Distance un producto de IBM,permite que un portátil o en general cualquierordenador conectado vía módem actúe como
Obviamente, lo que hemos contado hasta aquíno tiene que ser manejado, en general, por elusuario, sino por el administrador de la red (Elprocedimiento puede incluso automatizarse, demodo que pueda instalarse una estación OS/2con clientes de diversos tipos de modo total-
mente desatendido, utilizando el sistema CID deIBM). Al usuario lo que leinteresa es disponer deuna interface clara y lomás homogénea posible.Por ejemplo, si está conectado a servidores Novelly LAN Server a la vez, leinteresará que el númerode diferencias en elmomento del uso de losrecursos que publican seamínimo. En OS/2 el temaestá bastante solucionado.
La Figura e muestrauna vista de árbol de lared; cada tecnología dered tiene una carpeta, de
El uso simultáneode TCP/IP 2.0 Y elL\K (pOI' ~emplo
para disponer deX·Windows y las
utilidades como(iopher, VVebE~lPlorero 'Reuieve SoftwareTpdates" a la vez)
requiere de "tUl Ot'dende instalacióne pecifico.
RPP N2 7
80
OS/2
OS/2 2.0 aparccióa la "cz quc'Yindows a.l, y cnaquel momento laint\.."Toperabilldad en"Tindows erasimpll:"'mcnteimposible.
un miembro de pleno derecho de la red a la quese conecta: desde mi casa me conecto con LANDistance a mi servidor, y si allí tengo LAN Serversobre NetBIOS, TCPIIP, Novell IPX y SNA, esomismo tengo en casa.
Los programas de instalación y administraciónse están haciendo más sencillos, más fiables ymás potentes. Cuando apareció en e! mercadoOS/22.0, nos llevó meses averiguar cómo conseguir la interoperabilidad completa de los protocolos usados en la Universidad; hoy día todose reduce a instalar MPTS y los demás productos en orden. Sigue habiendo una serie de pequeños problemas: por ejemplo, DB/2 1.2 debe instalarse después de MPTS y LAN Requester 4.0si se desean evitar algunos problemas con UPM;y e! Internet Access Kit del BonusPack de Warp,aunque de hecho funciona con MPTS, avisa deposibles incompatibilidades (que no existen) y daun mensaje para conectarse por modem (al queparadójicamente hay que contestar "no te conectes") cada vez que se arranca una aplicación. Eluso simultáneo de TCPIIP 2.0 y el W( (por ejemplo para disponer de X-Windows y las utilidades como Gopher, WebExplorer o "RetrieveSoftware Updates" a la vez) requiere de un orden
de instalación específico. Queda por ver de quémodo habrá integrado IBM toda esa funcionalidad en la versión cliente de OS/2 Warp 3.0,que por lo que parece se va a llamar WarpConnect y está por salir encualquier momento.Probablemente el ofrecertodos los productos juntosen un sólo paquete va a permitir ir eliminando lospequeños problemas actuales de instalación e integración, haciendo de! acceso enconjunto a las distintas redesy servicios remotos una actividad más sencilla y transparente. Con OS/2 Warp ytodo e! conjunto de software de redes disponible paraWarp, IBM está poniendoel listón muy alto a sus futu-ros competidores; en estos momentos, para lagestión real, estable, sólida y productiva deentornos de red en estaciones de trabajo normales de tipo PC, esa competencia es simplemente inexistente.O
:..~¿~:~.~.~\~Us errores :
••••••••••••••
Solución al problema planteado el mes anterior.
El rn:es anterior vimos que el código escrito en eH producía un grave error a~ n~ libe~
raí' la memoria reservadá, con lo cual. el sistema podría quedarse rápidamente sin surecurso más pteciado. Esto eratácil de ver si ejecutábamos paso a paso el programa. El'mensaje "Libero los bytes reservados para el hijo" no figuraba en la salida estándar. Lasohición es tan sencilla como declarar el destructor de la clase base del tipo virtual (verc6digo). De eSta forma se ejecutarán ambos destructores,el d~laclase bas'e y el de la clase derivada. El orden de ejecución deambos es inverso al de llamada, es decir, primero se ejecutará el de la clase derivada y luego el de la clase base. Señalar que el
.destructorde Una cla,se derivada de una clase base con un destructor virtual siemprees virtual.
strcpy (cadena:-padre, "Soy el hijo,");DatosHijo =new inl (1000); } I I R~servo espacio poro] 000 int,
c1ass padre { "char codena_padre[301;public:padreO {strcpy{cadena-,podre, "Este es el podre,");}virtual "'padreO { cout « "Adios," «endl; }virtual void Impr.imeCadenaO { coui « codena_padre « eridl; }1; , . .
dosshijo : public padre{ " ,
char cadenaJlOdre[30];inl 'DatosHijo;public:hiloO {
-hijoO{coul« "Libero los bytes reservados paro el hijo." « endl;delete DatosHijo;}, ' II Libero'memoria,
void ImprimeCadeno O( coút <<: cadena_padre « endl; }~ ,
Abe/ Bart%mé Rodríguez
RPP Nº 7
81