Programa de soporte del sistema

System Support Program ( SSP ) fue el sistema operativo de las minicomputadoras IBM System/34 y System/36 . SSP fue un sistema operativo basado en comandos lanzado en 1977. ^[1]

El SSP originalmente contenía aproximadamente 60 comandos que se implementaron en el System/34 desde 1977 hasta 1983 en diferentes versiones llamadas releases. El Release 1 se publicó con el S/34 original en 1977. El Release 9 se publicó en 1981. En 1983, IBM reempaquetó el SSP en una nueva computadora llamada IBM System/36 , que no era compatible con el código objeto del S/34. En 1994, IBM reempaquetó el SSP en un modelo actualizado del S/36 llamado Advanced/36 . El A/36 era un IBM AS/400 que tenía el SSP implementado como una " máquina virtual ".

Las principales versiones de SSP incluyen:

• S/34
  • S/34 versión 1.0 : se envió con el primer S/34 en 1977. ^[1]
  • S/34 Release 8.0 – parece ^{[ cita requerida ]} haber sido publicado alrededor de 1980.
  • S/34 Versión 9.0 : este fue el último lanzamiento del S/34 alrededor de 1980.
• S/36
  • S/36 versión 1.0 : aparentemente, este ^{[ cita requerida ]} se envió con el primer S/36 en 1983.
  • S/36 versión 2.0 : esta versión es compatible con la unidad de cinta 8809.
  • Versión 4.0 de S/36 : esta fue la versión en la que se le otorgaron a S/36 5 colas de trabajos. ^{[ cita requerida ]}
  • S/36 versión 5.1 : esta versión de 1988 fue el último cambio importante en las plataformas 536X.
  • S/36 Release 6.0 – también conocido como VASP o Value-Added Support Product ^{[ cita requerida ]} , esta versión agregó funcionalidad que permitió llamadas de programa en RPG, y también proporcionó software para calcular el tamaño de AS/400 que el usuario necesitaría al actualizar. El VASP fue controvertido ^{[ cita requerida ]} . Circulaban rumores en los periódicos de la industria ^{[ cita requerida ]} de que el cliente no podría volver a 5.1 si 6.0 no funcionaba adecuadamente. Las llamadas de programa con RPG CALL/PARM eran inferiores a los diseños RPGIII e inferiores a los productos complementarios del cliente. ^{[ cita requerida ]}
  • Versión 7.1 de S/36 : esta versión de 1994 se envió con el Advanced/36 (modelos 9402-236). Las primeras máquinas A/36 no funcionaban con una versión anterior y también eran incompatibles con la 7.5 (aunque técnicamente es cierto que el código de objeto de programa de una máquina 7.1 se ejecutaba en una 7.5 y viceversa, además, muchas 9402-236 se actualizaban a 9402-436, cambiaban la placa base e instalaban un nuevo código LIC y restauraban una copia de sus archivos y listo, todo funcionaba). Circulaban rumores de que los compiladores de versiones anteriores no funcionarían en el Advanced/36, pero resultaron infundados. Había razones por las que un programador preferiría usar el compilador RPGII 5.1 en lugar del compilador 7.x, supuestamente más avanzado.
  • Versión 7.5 del S/36 : esta versión de 1995 se envió con la segunda y última ola del Advanced/36 (9402-436). Funciones como WRKSYSVL permitían al operador cambiar la hora del sistema sobre la marcha, lo que era interesante porque los complementos del cliente para hacer esto a través de subrutinas de ensamblador no funcionaban en el Advanced/36. Sin embargo, las rutinas de ensamblador para hacer cosas como abrir/cerrar archivos, recuperar el VTOC, etc. funcionaban perfectamente en las versiones 7.1 y 7.5.
  • Guest/36 : esta es la versión 7.5, pero podría configurar un M36 (un invitado) en un AS/400 (que ejecute OS/400 V3R6 a V4R4) y funcionaría igual que el 9402-436, excepto que además de tener esta "partición" de invitado, también tendría OS/400 si lo deseaba. Por lo tanto, si el 9402-436 que venía en 3 velocidades 2102, 2104 y 2106 (el último era aproximadamente 2,7 veces más rápido que el básico) no era lo suficientemente rápido, podría obtener una máquina 9406-xxx e instalar un "guest/36" en ella. Y, de hecho, podría instalar más de un guest/36. Había algunas limitaciones en cuanto a la cantidad de estaciones de trabajo conectadas, pero tener dos Guest/36 ejecutándose en un AS/400 y configurar DDM (gestión de datos distribuidos) entre ellos e incluso con OS/400 para alojar archivos grandes, era algo que se podía hacer fácilmente. Si bien el S/36 y el A/36 funcionaban en su mayor parte solo con terminales conectadas mediante twinax, en un Guest/36 (o M/36), todos los terminales podían estar en una LAN que ejecutara TCP/IP y ser dispositivos virtuales en el entorno Guest/36.
  • S36EE (entorno de ejecución S/36) : este entorno se soportaba de forma nativa en el AS/400 y sus sucesores (iSeries, IBM i), lo que permite al usuario seguir ejecutando sus programas y procedimientos s/36 sin tener que convertirlos. Muchos de los procedimientos del sistema también funcionan con este entorno. Aunque normalmente era "más lento" porque tenía que pasar por pasos adicionales, hoy en día, con máquinas tan rápidas, la velocidad de un S36EE es mucho más rápida que la velocidad de ejecución del A/36. Por ejemplo, un trabajo tardaba 12 minutos en ejecutarse en un Adv/36 y 20 segundos en ejecutarse en modo S36EE. Sin embargo, el código objeto NO es compatible con los S/36 y A/36 anteriores, lo que significa que había que volver a compilar todos los programas y menús. Sin embargo, una ventaja es que no solo se pueden ejecutar S36EE, sino también aplicaciones OS/400. Puede acceder a las tablas de bases de datos en sus programas S/36, puede llamar a programas RPG/400 y RPGIV desde un programa S/36. Por lo tanto, si bien técnicamente no es SSP, parece SSP, actúa como SSP y ejecutará sus programas/procedimientos S/36.

Limitaciones en los sistemas operativos S/36, A/36 y M/36: La cantidad máxima de espacio en disco que un sistema podía utilizar era de 4 GB (por ocurrencia del sistema operativo, por lo que una máquina que ejecutaba dos "particiones" M36 podía tener 4 GB en cada una. Otra limitación era el tamaño del programa, que no podía superar los 64 KB. Si tenía un programa que era más grande que eso, tenía que ser creativo en los últimos años cuando entró en vigencia call/parm, ya que movería el código a un programa llamado, porque si el programa base era de 63 kb, por ejemplo, podría llamar fácilmente a un programa llamado de 20 kb. Tampoco podía tener más de alrededor de 8000 archivos en la máquina. También había restricciones en la cantidad de archivos que podía traer a un programa (de nuevo, podía evitarlo colocando archivos en programas llamados y pasando el resultado de vuelta. La cantidad máxima de registros que podía cargar inicialmente era de aproximadamente 8 millones y el máximo que un archivo podía contener era de aproximadamente 16 millones. Ninguna de estas limitaciones existe en S36EE (no hay son unos pocos números máximos de archivos en un programa, pero mucho más grandes que en SSP nativo).

Al utilizar SSP, el operador puede crear, eliminar y administrar objetos S/34-36 como bibliotecas, archivos de datos , menús , procedimientos , miembros de origen y archivos de seguridad.

SSP contiene módulos como DFU, SEU, SDA y WSU que permiten a los operadores crear bibliotecas y archivos, ingresar información en esos archivos, generar informes simples y mantener una estructura de menú que simplifica el acceso a la información. Advanced/36 no admite WSU. La seguridad de contraseñas y recursos también se implementa a través de SSP, al igual que las comunicaciones remotas, que hoy en día son similares a las redes de acceso telefónico .

SSP es un sistema operativo basado en disco . Los programas informáticos pueden ejecutarse desde el disco fijo, pero no desde disquetes o cintas. El complemento de un System/34 5340 o System/36 5360/5362 es una matriz de discos fijos de uno a cuatro discos fijos, al menos un terminal de ordenador y una unidad de disquete de 8" , opcionalmente equipada con dos unidades de cargador que pueden contener 10 disquetes cada una y tres ranuras para disquetes. AS/36 5363/5364 tiene una unidad de disquete de 5-1/4". Las computadoras S/36 pueden configurarse con una unidad de cinta de carrete a carrete 8809 (800/1600 bpi) o una unidad de cinta de cartucho 6157 de 1/4" (QIC). Las computadoras A/36 tienen una unidad QIC de alta densidad, pero la unidad de disquete de 5,25" u 8" (simple) era opcional, al igual que una unidad de cinta 9348-001 de 9 pistas (carrete a carrete) de 1600/6250 bpi.

Los procedimientos SSP utilizan programas de utilidad, que en algunos casos pueden ser más útiles para el programador informático que los propios procedimientos SSP. $MAINT es la utilidad de biblioteca, utilizada en ALOCLIBR, BLDLIBR, FROMLIBR, LIBRLIBR, REMOVE, CONDENSE, LISTLIBR y TOLIBR . $COPY es la utilidad de archivo utilizada en SAVE, RESTORE, COPYDATA y LISTDATA . Existen muchas otras utilidades, incluidas $FBLD , $LABEL , $DUPRD , $INIT , $DELET , $HIST , $CNFIG , #GSORT , $PACK y $PROF , que son más flexibles a nivel de programa de lo que pueden ser los procedimientos SSP asociados.

Se utilizó el procedimiento CNFIGSSP para configurar el sistema, incluidos los dispositivos. A cada dispositivo se le asigna un identificador de dos caracteres. La primera letra debe ser alfabética y la segunda alfanumérica. El sistema también reservó determinados identificadores; por ejemplo, el dispositivo no puede llamarse I1 o F1. I1 es el nombre de la unidad de disquete; F1 es el nombre que el sistema le da al disco duro (significa "disco fijo", ya que no es un paquete de discos extraíbles).

Para aplicar CNFIGSSP , el sistema debe estar dedicado (no debe haber otros usuarios conectados ni programas en ejecución). El sistema debe estar activado por IP (reiniciado). Cuando finalice la IPL, los nuevos dispositivos aparecerán en la pantalla de estado.

SDA permite al operador crear formatos de pantalla o menús. Se pueden habilitar o deshabilitar las teclas de comando. Se pueden crear y condicionar campos de entrada, campos de salida y constantes. Las condiciones (en RPG se denominan indicadores ) pueden hacer que los campos desaparezcan o cambien de color.

SEU es un editor de texto que permite la entrada de datos línea por línea. Se utilizan formularios especiales para ayudar al operador a introducir datos en programas RPG u otros tipos de lenguajes basados ​​en formularios (WSU, Sort, SDA, etc.).

SORT tiene entre uno y ocho archivos de entrada, que pueden tener cualquier longitud de registro válida. Tiene un archivo de salida, de cualquier longitud indicada, que puede contener entre cero y más de ocho millones de registros.

Una ordenación puede contener registros completos o solo direcciones de 3 bytes que apuntan a registros en un archivo asociado. Esto se denominaba archivo de salida de direcciones o ADDROUT . Cuando se utilizaba una ruta Add, el programa leía estas direcciones de 3 bytes y luego obtenía los registros asociados del archivo maestro.

Se trataba de un lenguaje de tipo RPG que funcionaba en SSP. Estaba enfocado en programas de entrada de datos. WSU era gratuito, pero no tuvo una gran aceptación debido a sus limitaciones.

Es un elemento gratuito suministrado por IBM que se utiliza para ver y cambiar valores de campo en registros individuales.

Se puede utilizar DFU

• por programadores para actualizar archivos de bases de datos sobre la marcha sin escribir programas
• por programadores para crear programas simples para realizar operaciones básicas en un archivo de base de datos
• por el personal de ingreso de datos para agregar o eliminar registros de un archivo, o para imprimir registros.

Los programas de lenguaje de alto nivel requieren que OCL esté activado. OCL se utiliza para cargar programas en la memoria del sistema e iniciarlos (un proceso llamado ejecución) y asignar recursos como archivos de disco, impresoras, miembros de mensajes, memoria y espacio en disco a esos programas. Otras capacidades, como mostrar texto en la pantalla, pausar mensajes, etc., hacen que OCL sea más potente.

RPG II fue modificado a partir de la época de System/3 para permitir el acceso al "archivo WORKSTN" y permitir que un lenguaje basado en tarjetas perforadas interactuara con una persona sentada frente a un teclado y un monitor. Un archivo WORKSTN era un archivo de salida (escribía en el monitor) y también un archivo de entrada (porque aceptaba la entrada del teclado del usuario). Por lo tanto, se lo denominó archivo primario combinado o archivo de demanda combinada.

Las teclas de comando se convirtieron en indicadores RPG KA-KY, y los distintos formularios en pantalla se reconocían mediante distintos caracteres de control invisibles ocultos en los propios formularios. Dado que el usuario tenía que mostrar un formulario en la pantalla para poder escribir, RPG II proporcionó una forma para que un programa escribiera la salida antes de aceptar la entrada. Muchos programadores exitosos pasaron de utilizar el archivo WORKSTN primario combinado a utilizar un archivo de demanda combinada, que tenía códigos de operación para leer y escribir la pantalla. Incluso había una forma de codificar varios WORKSTN; varias personas podían iniciar sesión en la misma copia del mismo programa en la memoria. El tamaño de programa más grande era de 64k.

MRT = Programa de terminal de solicitante múltiple. SSP podía conectar hasta 7 terminales a un programa a la vez. Cualquier operador podía iniciar el programa en su terminal y luego se conectarían las terminales de otros operadores cuando seleccionaran el mismo programa. El programador podía controlar la cantidad máxima de terminales a las que se prestaría servicio.

SRT = Programa de terminal de solicitante único. No es un MRT.

NRT = Programa de terminal sin solicitante. Iniciado en una terminal, el NRT libera la terminal solicitante y continúa. Esto es similar a un programa MS-DOS TSR (Terminate and Stay Resident). Por definición, cualquier programa que se invocara o enviara al JOBQ era un NRT.

NEP = Programa sin fin. Este era típicamente un programa MRT interactivo que esperaba después de que todos los terminales se desconectaran hasta que algún terminal se volviera a conectar, evitando la sobrecarga de inicio. Esto se usaba comúnmente para permitir que los programas grandes se implementaran como una cadena de programas pequeños que pasarían los terminales de uno a otro mientras permanecían listos para continuar el procesamiento para otros terminales y/o transacciones posteriores. Los programas NRT también podían ser NEP si se escribían para que se repitieran y esperaran alguna condición que indicara que había trabajo por hacer. Los programas NEP normalmente no finalizaban hasta que se apagaba el sistema, a menos que se escribieran para reconocer alguna condición de terminación especial.

Cobol, Fortran y RPG generaban código objeto (tipo O). Basic sólo se interpretaba; una utilidad de compilación llamada BASICS creaba código de subrutina (tipo R). Los programas de Basic se podían guardar como fuentes para compatibilidad con otras computadoras, pero el texto del proyecto se conservaba en la subrutina (a menos que el programador usara el parámetro LOCK para mantenerlo privado).

Los procedimientos que utilizan OCL para iniciar programas y asignarles recursos son de tipo P.

Los miembros de origen de todos los objetos son de tipo S, con la excepción de Básico como se especificó anteriormente.

Los programas DFU generaron código de subrutina (R), al igual que los programas WSU.

Los formatos de pantalla generan código objeto.

Código objeto generado por los menús. Un menú es simplemente un formato de pantalla muy específico con un mensaje adjunto con dos signos de almohadilla ("##") como sufijo para contener la acción que se debe realizar cuando se elige el número asociado.

• El programador y operador de ayuda para la productividad (POP) era un programa de desarrollo muy utilizado. Se incluía con Advanced 36.
• MAPICS , el Sistema de Control de Información de Fabricación y Producción.
• IMAS, un paquete contable sencillo
• BPCS, un sistema de contabilidad más avanzado
• La colección de programas IBM Office/36 (DisplayWrite/36, IDDU, Query, etc.) fue muy popular a finales de los años 1980 y más tarde se incluyó en el paquete Advanced/36. El editor de texto System/34 fue un precursor de Office/36.
• El sistema de procesamiento de textos Britz era un editor de texto de propósito general que tenía capacidades de combinación de correspondencia, etiquetas y edición básica de archivos.

Hay cuatro tipos de seguridad en un sistema SSP:

• Seguridad de la insignia.
• Seguridad de contraseña.
• Seguridad de los recursos.
• Seguridad del menú.

La seguridad de la credencial se implementa mediante un dispositivo lector de banda conectado a un terminal de la serie 5250. Para iniciar sesión, el usuario no solo ingresa la información de usuario y contraseña, sino que también pasa la credencial por el lector.

Para trabajar con los identificadores de usuario y las contraseñas se utilizó el procedimiento SECEDIT. El perfil de usuario contiene un identificador de usuario alfanumérico de entre 1 y 8 caracteres, una contraseña alfanumérica de 4 caracteres, un código para la clasificación de seguridad del usuario (M [Master Security Officer], S [Security Officer], O [System Operator], C [Subconsola Operator] o D [Display Station Operator]) y una serie de otros parámetros predeterminados.

El procedimiento SECEDIT RESOURCE se utilizó para establecer clasificaciones de seguridad para objetos de archivo, biblioteca, carpeta y grupo. Se podían otorgar niveles de acceso de O (Propietario), C (Cambiar), U (Actualizar), R (Leer), E (Ejecutar) o N (Ninguno) para un usuario a un recurso en particular. Un objeto de grupo era una especie de sociedad de cartera que poseía uno o más objetos inferiores. Por ejemplo, otorgar acceso al grupo ACCOUNTG facilitó el establecimiento del acceso a todos los archivos de contabilidad. Los objetos de grupo también podían hacer referencia a archivos de grupo; el grupo UB hacía referencia a UB.OLD, UB.NEW, UB.01 o a cualquier nombre de archivo con el punto incrustado.

SECEDIT USERID también se utilizó para limitar la autoridad operativa de un usuario a un menú específico. Al ingresar una Y para el menú obligatorio y especificar un menú de inicio de sesión predeterminado, el oficial de seguridad podía impedir que el usuario accediera a cualquier programa que no se encontrara en ese menú de inicio de sesión. Un usuario restringido de esta manera solo podía ejecutar opciones del menú, enviar mensajes y cerrar sesión en el sistema.

El procedimiento PROF ("Perfil") se utilizó para trabajar con identificadores de usuario y contraseñas. El perfil de usuario contiene un identificador de usuario alfanumérico de entre 1 y 8 caracteres, una contraseña alfanumérica de 4 caracteres, un código para la clasificación de seguridad del usuario (M (Oficial de seguridad principal), S (Oficial de seguridad), O (Operador del sistema), C (Operador de subconsola) o D (Operador de estación de visualización) y una serie de otros parámetros predeterminados.

Se utilizó el procedimiento PRSRCID ("Seguridad de recursos de perfil por ID de usuario") para establecer clasificaciones de seguridad para objetos de archivos y bibliotecas. Se podían otorgar niveles de acceso O (Propietario), G (Cambiar), R (Leer), E (Ejecutar) o N (Ninguno) a un usuario para un recurso en particular.

El catálogo de discos impresos (VTOC, Tabla de contenido del volumen) mostraba todos los objetos protegidos con la notación 3 como protegidos.

SSP ofrece dos objetos de datos diferentes, denominados archivos y bibliotecas. Los archivos contienen registros, casi siempre con una longitud de registro fija. Las bibliotecas contienen programas que pueden hacer referencia a estos archivos y acceder a ellos. SSP contenía más de 80 comandos diferentes que permitían a los operadores crear, eliminar, copiar, editar/cambiar y proteger archivos y bibliotecas.

Una biblioteca o un archivo debe existir en una organización contigua en un disco fijo (sin embargo, una biblioteca puede contener una "extensión" de aproximadamente 50 bloques que deben reorganizarse y no se puede extender si se asigna a otros usuarios). Un archivo se puede organizar con un valor EXTEND o se puede asignar con FILE OCL para extenderse automáticamente. Todas las adiciones/actualizaciones/eliminaciones de registros esperan mientras se extiende el archivo. Es una política de sentido común crear valores de extensión lo suficientemente grandes como para minimizar la frecuencia de las extensiones. Las bibliotecas pueden tener "extensiones" que no sean contiguas. A veces, al compilar un programa, se creaba una extensión y, al hacer un "CONDENSE", se eliminaba si había suficiente espacio en la asignación principal para ella. De lo contrario, se hacía un ALOCLIBR para reasignar la biblioteca a un tamaño mayor.

Los archivos del S/36 pueden ser secuenciales (S), directos (D) o indexados (I). Un archivo indexado puede tener varios índices alternativos (X) y, de hecho, un archivo secuencial puede tener índices alternativos colocados en él, por lo que no hay un índice principal. Un archivo indexado contiene una clave, que debe ser contigua y puede tener hasta 60 caracteres de longitud; sin embargo, los índices alternativos pueden tener claves de tres partes que no sean contiguas entre sí. Las claves duplicadas en archivos indexados o de índice alternativo pueden estar permitidas o no. Un archivo con organización directa se crea con todos los registros agregados y no se puede extender automáticamente. Un archivo con organización secuencial o indexada se crea sin registros agregados. Un índice alternativo siempre tiene tantos registros como su padre, a diferencia de un archivo lógico de estilo System/38 que se crea con condiciones para filtrar los registros del padre.

En 1986, se agregó soporte para la Arquitectura de Gestión de Datos Distribuidos (DDM) a SSP. Esto permitió que los programas System/36 crearan, administraran y accedieran a archivos orientados a registros en sistemas remotos System/36, System/38 y mainframes IBM que ejecutaban CICS . También permitió que los programas en computadoras remotas System/36 y System/38 crearan, accedieran y administraran archivos en un System/36. Los modelos iniciales de archivos orientados a registros definidos por DDM se basaban en el sistema de archivos System/36.

El System/3 (1969) ejecutaba un sistema operativo por lotes basado en disco llamado System Control Program (SCP) (5702-SC1). Posteriormente, IBM introdujo un programa en línea para el System/3 llamado Communications Control Program (CCP), que se inició como un programa por lotes. El IBM System/32 (1975) ejecutaba un sistema operativo basado en disco también llamado System Control Program. El IBM System/38 (1978) ejecutaba un sistema operativo llamado Control Program Facility (CPF), que era mucho más avanzado que el SSP y no particularmente similar.

• Publicación de IBM SC21-8299, Información general para el sistema operativo SSP.

• Archivo Bitsavers de documentación de System/34: incluye documentación sobre SSP
• Archivo Bitsavers de documentación de System/36: incluye documentación sobre SSP