• •••••••• ••• ••• •• •• ••••••• •. ...:••••••

({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 interopera­bilidad 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 nece­sidad de explotar simultáneamente entornos de red distintos, y hacer­los 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 sucur­sales, 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écnica­mente su migración a una única arquitectura. Por otra parte, la revo­lució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 apli­caciones cliente/servidor. Su E-MAIL es:JMBLASCO@EIM.UB.ES

RPP Nº 7

75

ideal es una red local. El mismo usuariodeberá, en muchos casos, acceder a todosesos entornos, como mínimo secuencial­mente, y a ser posible, simultáneamente.Es lo que llamamos interoperabilidad.

Además, los protocolos de comunica­ció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ánea­mente y de un modo transparente para elusuario todos esos protocolosde comuni­cació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 infor­mático. Una pequeña empresa que dis­ponga de una red Novell estará utilizan­do 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 cual­quier acción con nuestra estación de trabajosin comprometer la estabilidad de las comuni­caciones, y ser capaces de cancelar las comu­nicaciones 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 masi­va 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 aplicacio­nes 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 debe­rán utilizar los programas. Al instalar un nuevodriver, muchas veces dejan de funcionar losantiguos, o se pierde alguna configuración cui­dadosa del CONFIG.SYS o del AUTOE­XEC.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 imposi­ble 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 comodi­dad 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 ape­nas memoria.

Estas son algunas de las reflexiones que meimpulsaron a considerar OS/2 como la plata­forma idónea para la mayoría de los usuariosuniversitarios, tamo ieorificos como adminis­trativos, 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 enton­ces: 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 empre­sa, en la que contaremos casi con seguridadcon algún tipo de mainframe. El caso más com­plejo 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 realiza­mos en nuestro or­denador, y sólo devez en cuando nosconectamos a unaNovel! para leer ograbar algún fi­chero, podemostolerar que el or­denador se "cla­ve" cada tanto poruna General Pro­tection Fault: re-botamos el orde­nador, y ya está.

Pero si una clavada significa restablecer comu­nicaciones 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 utiliza­mos no necesitamos delmultiprotocolo, ya quesólo existe uno.

Cuando la misma placade comunicaciones nece­sita manejar más de unprotocolo, se hace nece­saria la presencia de undiscriminador de proto­colo, 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 fun­cionase en la placa, implementando efectiva­mente lo que se conoce como una pila de pro­tocolos o protocol stack.

Un ordenador con DOS y Windows conec­tado a una red Novell normalmente utiliza undriver (IPX) que se encarga de manejar lospaquetes IPX utilizados para comunicarse conel servidor Netware. IPX controla en exclusi­va la tarjeta de red, y, si llega un paquete per­teneciente 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 (ODI2N­DIS.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 ver­sión nueva, si descontamos las versiones forWorkgroups y Windows NT, que es una pla­taforma 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 distin­tos tipos de red, adaptadores, etc.

Cuando dos programas residentes en ordena­dores 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 comuni­caciones 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 admi­nistración descentralizada, y no importa tantola fiabilidad como el intentar asegurarse de quelas comunicaciones siguen funcionando aun­que parte de la red deje de ser operativa: TCP/lPestá pensado para seguir funcionando aunquealgunos de los nodos caigan bajo fuego ene­migo.

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 apli­caciones y servicios de red quelos hacen útiles; en la Universidadde Barcelona, se utilizan todosellos.

La necesidad de multiproto­colo 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'acce­der 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 orde­nador (arriba a la izquierda) , y para cada unade las placas, los protocolos de comunicacio­nes que se utilizan sobre esas placas (arriba ala derecha). El resultado aparece en otro recua­dro (abajo a la izquierda), desde donde pode­mos cambiar los parámetros propios de la placao de cada uno de los protocolos de comunica­ciones 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 clien­te 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 aproxima­ció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 segun­da es la deficiente calidad de soporte que engeneral hemos sido capaces de obtener de losrevendedores de Novel!.

NDIS es una arquitectura multiprotocolo desa­rrollada por Microsoft, 3Com e IBM; la versión2 es la propia de OS/2. Los primeros produc­tos 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 conver­gencia 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 pla­cas yesos protocolos, y se encuentran enC:\IBMCOM\MACS y C:\IBMCOM\PRO­TOCOL. En el CONFIG.SYS, estas lineas se tra­ducen 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\MPTS­TART.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 eleccio­nes 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 PROTO­COL.INI correspondiente a la figura, comen­tando 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 proporcio­nado 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 refle­jado 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 últi­mo. 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 refe­rencia al mencionado PROTMAN.

Li sección [IBMLXCFG] establece cuálesson las placas y los protocolos que se utiliza­rá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 proto­colo 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 dis­pone de los privilegios adecuados para ello), yaumentan la profundidad del árbol corres­pondientemente. Como por ese método pode­mos 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 independientemen­te 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 dispone­mos de acceso a las placas y a los protocolosdefinidos. (No hemos entrado en el detalle parala instalación del cliente Novell, ni en la con­figuración de TCP/IP, que ocuparían demasia­do 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 aplica­ciones 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 comunicar­se 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 pro­tocolos; por otra, definir niveles de abstracciónen las comunicaciones, de modo que dos pro­gramas 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 posi­ble utilizar los nativos. Se tiende a pensar losdistintos protocolos como niveles de transpor­te, y definir APIs independientes de transporte.A la larga, estas tendencias no pueden sino redun­dar en programas más flexibles, redes más sen­cillas, 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, utili­zando el sistema CID deIBM). Al usuario lo que leinteresa es disponer deuna interface clara y lomás homogénea posible.Por ejemplo, si está conec­tado 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 soluciona­do.

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 con­seguir la interoperabilidad completa de los pro­tocolos usados en la Universidad; hoy día todose reduce a instalar MPTS y los demás produc­tos en orden. Sigue habiendo una serie de peque­ños problemas: por ejemplo, DB/2 1.2 debe ins­talarse 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 conec­tes") cada vez que se arranca una aplicación. Eluso simultáneo de TCPIIP 2.0 y el W( (por ejem­plo para disponer de X-Windows y las utilida­des 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 funcio­nalidad 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 per­mitir ir eliminando lospequeños problemas actua­les de instalación e integra­ción, haciendo de! acceso enconjunto a las distintas redesy servicios remotos una acti­vidad más sencilla y trans­parente. Con OS/2 Warp ytodo e! conjunto de softwa­re 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 nor­males de tipo PC, esa competencia es simple­mente 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