PL/I

UPTHRU y DOWNTHRU en grupos iterativos.

La construcción del paquete que consta de un conjunto de procedimientos y declaraciones para usar como una unidad. Las variables declaradas fuera de los procedimientos son locales para el paquete y pueden usar almacenamiento STATIC, BASED o CONTROLLED. Los nombres de los procedimientos utilizados en el paquete también son locales, pero se pueden convertir en externos mediante la opción EXPORTS de la instrucción-PACKAGE.

Manejo de interrupciones

La sentencia-RESIGNAL ejecutada en una unidad ON finaliza la ejecución de la unidad ON y genera la condición nuevamente en el procedimiento que llamó a la actual (pasando así el control a la unidad ON correspondiente). unidad para ese procedimiento).

La condición INVALIDOP maneja códigos de operación no válidos detectados por el procesador de la PC, así como operaciones aritméticas ilegales como la resta de dos valores infinitos.

La condición ANYCONDITION se proporciona para interceptar condiciones para las que no se ha proporcionado ninguna unidad ON específica en el procedimiento actual.

La condición STORAGE se genera cuando una instrucción ALLOCATE no puede obtener suficiente almacenamiento.

Otros compiladores de mainframe y miniordenadores

Varios proveedores produjeron compiladores para competir con IBM PL/IF o el compilador de optimización en mainframes y minicomputadoras en la década de 1970. En la década de 1980, el objetivo solía ser el subconjunto ANSI-G emergente.

• En 1974 Burroughs Corporation anunció PL/I para los B6700 y B7700.
• UNIVAC publicó un UNIVAC PL/I y en los años 70 también utilizó una variante del PL/I, PL/I PLUS, para la programación del sistema.
• De 1978 Data General proporcionó PL/I en sus plataformas Eclipse y Eclipse MV que ejecutan los sistemas operativos AOS, AOS/VS " AOS/VS II. En el idioma se redactaron varios programas de utilidad del sistema operativo.
• Paul Abrahams del Courant Institute of Mathematical Sciences de NYU escribió CIMS PL/I en 1972 en PL/I, arrancando por PL/I F. Sostenía "alrededor del 70%" de la compilación PL/I al CDC 6600
• CDC entregó un compilador de subconjunto optimizador PL/I para serie Cyber 70, 170 y 6000.
• Fujitsu entregó un compilador PL/I equivalente al PL/I Optimizer.
• Stratus Technologies PL/I es una aplicación ANSI G para el sistema operativo VOS.
• IBM Series/1 PL/I es un subconjunto extendido de ANSI Programming Language PL/I (ANSI X3.53-1976) para el sistema de programación en tiempo real IBM Series/1.

Compiladores PL/I para Microsoft.NET

• En 2011, Raincode diseñó un completo compilador legado para Microsoft. NET y. NET Plataformas básicas, llamada The Raincode PL/I compilador.

Compiladores PL/I para ordenadores personales y Unix

• En la década de 1970 y 1980 Digital Research vendió un compilador PL/I para CP/M (PL/I-80), CP/M-86 (PL/I-86) y Computadoras Personales con DOS. Se basó en el subconjunto G de PL/I y fue escrito en PL/M.
• Micro Focus implementó Open PL/I para sistemas Windows y UNIX/Linux, que adquirieron de Liant.
• IBM entregó PL/I para OS/2 en 1994, y PL/I para AIX en 1995.
• Iron Spring PL/I for OS/2 y más tarde Linux fue introducido en 2007.

Dialectos PL/I

• PL/S, un dialecto de PL/I, inicialmente llamado BSL fue desarrollado a finales de los años 60 y se convirtió en el lenguaje de programación del sistema para los mainframes IBM. Casi todo el software del sistema IBM mainframe en los años 1970 y 1980 fue escrito en PL/S. Difería de PL/I en que no había conversiones de tipo de datos, ningún entorno de tiempo de ejecución, las estructuras se mapearon de manera diferente, y la asignación fue un byte copy. Todas las cuerdas y arrays tenían alcances fijos, o utilizaban las REFER Opción. PL/S fue sucedido por PL/AS, y luego por PL/X, que es el idioma utilizado actualmente para el trabajo interno en los sistemas operativos actuales, OS/390 y ahora z/OS. También se utiliza para algunos componentes z/VSE y z/VM. IBM Db2 for z/OS también está escrito en PL/X.
• PL/C, es un dialecto instructivo del lenguaje de programación informática PL/I, desarrollado en la Universidad de Cornell en la década de 1970.
• Dos dialectos de PL/I llamados PL/MP (Machine Product) y PL/MI (Machine Interface) fueron utilizados por IBM en el software del sistema de las plataformas System/38 y AS/400. PL/MP se utilizó para implementar el llamado Microcódigo Vertical de estas plataformas, y se enfocó en el conjunto de instrucciones IMPI. PL/MI se dirige a la interfaz de máquina de esas plataformas, y se utiliza en la instalación del programa de control y la capa XPF de OS/400. El código PL/MP fue reemplazado principalmente por C++ cuando OS/400 fue portado a la familia de procesadores IBM RS64, aunque algunos fueron retenidos y retratados para la arquitectura PowerPC/Power ISA. El código PL/MI no fue reemplazado y permanece en uso en IBM i.
• PL/8 (o PL.8), llamado porque era alrededor del 80% de PL/I, fue desarrollado originalmente por IBM Research en la década de 1970 para la arquitectura IBM 801. Posteriormente obtuvo apoyo para las arquitecturas Motorola 68000 y System/370. Sigue utilizándose para varias tareas de desarrollo de sistemas internos IBM (por ejemplo, millicodo y firmware para sistemas z/Arquitecture) y ha sido rediseñado para utilizar un backend basado en gcc de 64 bits.
• Honeywell, Inc. desarrolló PL-6 para su uso en la creación del sistema operativo CP-6.
• Prime Computer utilizó dos dialectos PL/I diferentes como lenguaje de programación del sistema del sistema operativo PRIMOS: PL/P, a partir de la versión 18, y luego SPL, a partir de la versión 19.
• XPL es un dialecto de PL/I utilizado para escribir otros compiladores utilizando las técnicas de compilador XPL. XPL agregó un tipo de datos de cadena de heap a su pequeño subconjunto de PL/I.
• HAL/S es un lenguaje de programación aeroespacial en tiempo real, más conocido por su uso en el programa Space Shuttle. Fue diseñado por Intermetrics en la década de 1970 para la NASA. HAL/S fue implementado en XPL.
• IBM y varios subcontratistas también desarrollaron otra variante PL/I a principios del decenio de 1970 para apoyar el procesamiento de señales para la Marina llamada SPL/I.
• SabreTalk, un dialecto en tiempo real de PL/I solía programar el sistema de reservas aéreas Sabre.

Uso

Las implementaciones de PL/I se desarrollaron para mainframes a fines de la década de 1960, minicomputadoras en la década de 1970 y computadoras personales en las décadas de 1980 y 1990. Aunque su principal uso ha sido en mainframes, existen versiones PL/I para DOS, Microsoft Windows, OS/2, AIX, OpenVMS y Unix.

Ha sido ampliamente utilizado en el procesamiento de datos comerciales y para el uso del sistema para escribir sistemas operativos en ciertas plataformas. Se han construido sistemas muy complejos y potentes con PL/I:

• El Sistema SAS fue escrito inicialmente en PL/I; el paso de datos SAS sigue siendo modelado en la sintaxis PL/I.
• El pionero sistema de reservas aéreas online Sabre fue escrito originalmente para el IBM 7090 en ensamblador. La versión S/360 fue escrita en gran parte con SabreTalk, un compilador de subconjunto PL/I construido para un programa de control dedicado.
• El sistema operativo Multics fue escrito en gran parte en PL/I.
• PL/I fue utilizado para escribir una definición formal ejecutable para interpretar IBM's System Network Architecture.

PL/I no cumplió con sus partidarios' espera que desplace a Fortran y COBOL y se convierta en el actor principal de los mainframes. Siguió siendo un jugador minoritario pero significativo. No puede haber una explicación definitiva para esto, pero algunas tendencias en las décadas de 1970 y 1980 se opusieron a su éxito al reducir progresivamente el territorio en el que PL/I disfrutaba de una ventaja competitiva.

Primero, cambió la naturaleza del entorno de software de mainframe. Los subsistemas de aplicaciones para el procesamiento de bases de datos y transacciones (CICS e IMS y Oracle en System 370) y los generadores de aplicaciones se convirtieron en el foco de atención de los usuarios de mainframe. desarrollo de aplicaciones. Partes significativas del lenguaje se volvieron irrelevantes debido a la necesidad de usar las funciones nativas correspondientes de los subsistemas (como tareas y gran parte de la entrada/salida). Fortran no se usó en estas áreas de aplicación, limitando PL/I al territorio de COBOL; la mayoría de los usuarios se quedaron con COBOL. Pero a medida que la PC se convirtió en el entorno dominante para el desarrollo de programas, Fortran, COBOL y PL/I se convirtieron en lenguajes minoritarios superados por C++, Java y similares.

En segundo lugar, PL/I fue superado en el campo de la programación de sistemas. La comunidad de programación de sistemas de IBM no estaba lista para usar PL/I; en cambio, IBM desarrolló y adoptó un dialecto patentado de PL/I para la programación del sistema. – PL/S. Con el éxito de PL/S dentro de IBM y de C fuera de IBM, las fortalezas únicas de PL/I para la programación de sistemas se volvieron menos valiosas.

En tercer lugar, los entornos de desarrollo aumentaron las capacidades para el desarrollo de software interactivo que, una vez más, hizo que las fortalezas exclusivas de PL/I interactivas y de depuración fueran menos valiosas.

Cuarto, se agregaron a COBOL y Fortran funciones como programación estructurada, operaciones de cadenas de caracteres y orientación a objetos, lo que redujo aún más las ventajas relativas de PL/I.

En los mainframes, también estaban en juego cuestiones comerciales importantes. Los competidores de hardware de IBM tenían poco que ganar y mucho que perder con el éxito de PL/I. El desarrollo del compilador era costoso y los grupos de compiladores de IBM tenían una ventaja competitiva incorporada. Muchos usuarios de IBM deseaban evitar quedar atrapados en soluciones propietarias. Sin soporte inicial para PL/I por parte de otros proveedores, era mejor evitar PL/I.

Evolución del lenguaje PL/I

Este artículo utiliza el estándar PL/I como punto de referencia para las características del lenguaje. Pero una serie de características de importancia en las primeras implementaciones no estaban en el Estándar; y algunos fueron ofrecidos por compiladores que no son de IBM. Y el lenguaje de facto siguió creciendo después del estándar, impulsado en última instancia por los desarrollos en la computadora personal.

Características significativas omitidas del estándar

Multiproceso

Multithreading, bajo el nombre "multitarea", fue implementado por PL/IF, los compiladores PL/I Checkout y Optimization, y los compiladores más nuevos de AIX y Z/OS. Comprendía los tipos de datos EVENT y TASK, la TASK-option en la CALL-statement (Fork), la sentencia-WAIT (Unirse), DELAY(delay-time), EVENT-options en las sentencias de E/S de registro y la Declaración UNLOCK para desbloquear registros bloqueados en archivos EXCLUSIVO. Los datos de eventos identifican un evento en particular e indican si está completo ('1'B) o incompleto ('0'B): los elementos de datos de tareas identifican una tarea (o proceso) en particular e indican su prioridad en relación con otras tareas.

Preprocesador

El primer preprocesador de tiempo de compilación de IBM fue construido por el Centro de Programación Avanzada de IBM Boston ubicado en Cambridge, Massachusetts, y se envió con el compilador PL/IF. La declaración %INCLUDE estaba en el estándar, pero el resto de las funciones no. Los compiladores DEC y Kednos PL/I implementaron prácticamente el mismo conjunto de funciones que IBM, con algunas adiciones propias. IBM ha seguido agregando funciones de preprocesador a sus compiladores. El preprocesador trata el programa fuente escrito como una secuencia de tokens, copiándolos en un archivo fuente de salida o actuando sobre ellos. Cuando se encuentra un token %, se ejecuta la siguiente instrucción de tiempo de compilación: cuando se encuentra un token de identificador y el identificador ha sido DECLAREd, ACTIVATEd, y se le ha asignado un tiempo de compilación valor, el identificador se sustituye por este valor. Los tokens se agregan al flujo de salida si no requieren acción (por ejemplo, +), al igual que los valores de las expresiones de tiempo de compilación ACTIVATEd. Por lo tanto, una variable de tiempo de compilación PI podría declararse, activarse y asignarse usando %PI='3.14159265'. Las apariciones posteriores de PI serían reemplazadas por 3.14159265.

El tipo de datos admitido son DECIMALES FIJOS enteros y CHARACTER cadenas de longitud variable sin longitud máxima. Las declaraciones de estructura son:

• %[label-list:]DO iteration: statements; %[label-list:]END;
• %procedure-name: PROCEDURE (parameter list) RETURNS (type); statements...;
• %[label-list:]END;
• %[label-list:]IF...%THEN...%ELSE..

y las declaraciones simples, que también pueden tener una [etiqueta-lista:]

• %ACTIVATE(identifier-list) and %DEACTIVATE
• assignment declaración
• %DECLARE identifier-attribute-list
• %GO TO label
• %INCLUDE
• null declaración

La función permitía a los programadores usar identificadores para constantes, p. ej. números de pieza del producto o constantes matemáticas, y fue reemplazada en el estándar por constantes nombradas para datos computacionales. El estándar no admitía la compilación condicional y la generación iterativa de código fuente, posible con funciones de tiempo de compilación. Varios fabricantes implementaron estas instalaciones.

Adiciones a la programación estructurada

Se realizaron adiciones de programación estructurada a PL/I durante la estandarización, pero no se aceptaron en el estándar. Estas características fueron la sentencia-LEAVE para salir de un DO iterativo, la opción-UNTIL y la opción-REPEAT agregado a DO, y una declaración de caso de la forma general: SELECT (expresión) {CUANDO (expresión) grupo}... OTHERWISE grupo
Todas estas características se incluyeron en los compiladores PL/I Checkout y Optimización de IBM y en DEC PL/I.

Instalaciones de depuración

PL/IF había ofrecido algunas funciones de depuración que no se presentaron para el estándar pero que fueron implementadas por otros, en particular el prefijo de condición CHECK (lista de variables), CHECK en condición y SNAP. Los compiladores IBM Optimizing and Checkout agregaron características adicionales apropiadas para el entorno de programación mainframe conversacional (por ejemplo, una condición ATENCIÓN).

Características significativas desarrolladas desde el estándar

Se han realizado varios intentos para diseñar un tipo de miembro de estructura que pudiera tener uno de varios tipos de datos (CELL en los primeros IBM). Con el crecimiento de las clases en la teoría de la programación, se hicieron posibles los enfoques sobre una base PL/I: varios compiladores han agregado UNION, TYPE, etc.

PL/I había sido concebido en un mundo de caracteres de un solo byte. Dado que el soporte para los idiomas japonés y chino se volvió esencial, y los desarrollos en las páginas de códigos internacionales, el concepto de cadena de caracteres se amplió para acomodar cadenas amplias no ASCII/EBCDIC.

El manejo de la hora y la fecha se revisó para solucionar el problema del milenio, con la introducción de la función DATETIME que devolvía la fecha y la hora en uno de los 35 formatos diferentes. Varias otras funciones de fecha se ocupan de las conversiones hacia y desde días y segundos.

Críticas

Problemas de implementación

Aunque el lenguaje es fácil de aprender y usar, implementar un compilador PL/I es difícil y requiere mucho tiempo. Un lenguaje tan grande como PL/I necesitaba subconjuntos que la mayoría de los proveedores pudieran producir y que la mayoría de los usuarios dominaran. Esto no se resolvió hasta que "ANSI G" fue publicado. Las instalaciones de tiempo de compilación, exclusivas de PL/I, supusieron un esfuerzo de implementación adicional y pases de compilación adicionales. Un compilador PL/I era de dos a cuatro veces más grande que los compiladores Fortran o COBOL comparables, y también mucho más lento, supuestamente compensado por las ganancias en la productividad del programador. Esto se anticipó en IBM antes de que se escribieran los primeros compiladores.

Algunos argumentan que PL/I es inusualmente difícil de analizar. Las palabras clave de PL/I no están reservadas, por lo que los programadores pueden usarlas como nombres de variables o procedimientos en los programas. Debido a que el compilador PL/I(F) original intenta la corrección automática cuando encuentra una palabra clave utilizada en un contexto incorrecto, a menudo asume que se trata de un nombre de variable. Esto conduce a "diagnósticos en cascada", un problema resuelto por compiladores posteriores.

El esfuerzo necesario para producir un buen código objeto quizás se subestimó durante el diseño inicial del lenguaje. La optimización del programa (necesaria para competir con la excelente optimización del programa realizada por los compiladores de Fortran disponibles) es inusualmente compleja debido a los efectos secundarios y los problemas generalizados con el aliasing de las variables. La modificación impredecible puede ocurrir de forma asincrónica en los controladores de excepciones, que pueden ser proporcionados por "declaraciones ON" en los llamantes (invisibles). Juntos, estos hacen que sea difícil predecir de manera confiable cuándo se pueden modificar las variables de un programa en tiempo de ejecución. Sin embargo, en el uso típico, los controladores de errores escritos por el usuario (la ON-unit) a menudo no realizan asignaciones a variables. A pesar de las dificultades antes mencionadas, IBM produjo el PL/I Optimizing Compiler en 1971.

PL/I contiene muchas funciones que rara vez se usan, como soporte multitarea (una extensión de IBM para el lenguaje) que agrega costo y complejidad al compilador, y sus instalaciones de coprocesamiento requieren un entorno de programación múltiple con soporte para no- bloqueo de múltiples subprocesos para procesos por parte del sistema operativo. Los escritores de compiladores eran libres de elegir si implementar estas características.

Una variable no declarada, por defecto, se declara por primera vez; por lo tanto, una falta de ortografía puede generar resultados impredecibles. Esta "declaración implícita" no es diferente de los programas FORTRAN. Sin embargo, para PL/I(F), una lista de atributos permite al programador detectar cualquier variable mal escrita o no declarada.

Problemas del programador

Muchos programadores tardaron en pasar de COBOL o Fortran debido a la complejidad percibida del lenguaje y la inmadurez del compilador PL/IF. Los programadores estaban claramente divididos en programadores científicos (que usaban Fortran) y programadores de negocios (que usaban COBOL), con una tensión significativa e incluso disgusto entre los grupos. Sintaxis PL/I tomada de la sintaxis COBOL y Fortran. Entonces, en lugar de notar características que facilitarían su trabajo, los programadores de Fortran de la época notaron la sintaxis de COBOL y opinaron que era un lenguaje comercial, mientras que los programadores de COBOL notaron la sintaxis de Fortran y la consideraron un lenguaje científico.

Tanto los programadores de COBOL como de Fortran lo vieron como un "más grande" versión de su propio idioma, y ambos estaban algo intimidados por el idioma y no estaban dispuestos a adoptarlo. Otro factor fueron las pseudo-similitudes con COBOL, Fortran y ALGOL. Estos eran elementos PL/I que se parecían a uno de esos idiomas, pero funcionaban de manera diferente en PL/I. Tales frustraciones dejaron a muchos programadores experimentados con una visión negativa de PL/I y, a menudo, con una aversión activa por el lenguaje. Uno de los primeros archivos de fortuna de UNIX contenía la siguiente descripción irónica del lenguaje:

Hablando como alguien que ha colado en las complejidades de PL/I, estoy seguro de que sólo Hombres Reales podrían haber escrito un monstruo tan lleno de máquina, agarramiento de ciclos, todo-compasador. ¿Asignar un array y liberar el tercio medio? ¡Claro! ¿Por qué no? Multiply a character string times a bit string and assign the result to a flota decimal? ¡Adelante! Libre un parámetro de procedimiento variable controlado y reallocate antes de pasarlo de vuelta? Superar tres tipos diferentes de variable en la misma ubicación de memoria? ¡Lo que tú digas! ¿Escribir una macro recursiva? Bueno, no, pero los Hombres Reales usan rescan. ¿Cómo podría un lenguaje tan obviamente diseñado y escrito por Real Men no ser destinado para uso del Hombre Real?

En el lado positivo, el soporte completo para punteros a todos los tipos de datos (incluidos los punteros a estructuras), recursividad, multitarea, manejo de cadenas y amplias funciones integradas significaron que PL/I fue un gran avance en comparación con la programación. lenguas de su tiempo. Sin embargo, esto no fue suficiente para persuadir a la mayoría de los programadores o talleres para cambiar a PL/I.

El preprocesador de tiempo de compilación del compilador PL/IF era inusual (fuera del mundo Lisp) en el uso de la sintaxis y la semántica del lenguaje de destino (por ejemplo, en comparación con el preprocesador C& #39;s "#" directivas).

Temas especiales en PL/I

Clases de almacenamiento

PL/I ofrece varias 'clases de almacenamiento' para indicar cómo la vida útil de las variables' el almacenamiento debe administrarse: ESTÁTICO, AUTOMÁTICO, CONTROLADO y BASADO. La más sencilla de implementar es STATIC, que indica que la memoria se asigna e inicializa en el momento de la carga, como se hace en COBOL "working-storage" y Fortran temprano. Este es el valor predeterminado para las variables EXTERNAL. La clase de almacenamiento predeterminada de PL/I para las variables INTERNAL es AUTOMATIC, similar a la de otros lenguajes estructurados en bloques influenciados por ALGOL, como "auto& #34; clase de almacenamiento en lenguaje C y asignación de almacenamiento predeterminada en Pascal y "almacenamiento local" en IBMCOBOL. El almacenamiento para las variables AUTOMATIC se asigna al ingresar al bloque, procedimiento o unidad ON BEGIN en el que se declaran. El compilador y el sistema de tiempo de ejecución asignan memoria para un marco de pila para contenerlos y otra información de mantenimiento. Si una variable se declara con un atributo INITIAL, el código para establecerla en un valor inicial se ejecuta en este momento. Se requiere cuidado para administrar el uso de la inicialización correctamente. Se pueden ejecutar grandes cantidades de código para inicializar variables cada vez que se ingresa un ámbito, especialmente si la variable es una matriz o estructura. El almacenamiento de variables AUTOMATIC se libera al salir del bloque: las variables STATIC, CONTROLLED o BASED se utilizan para retener variables& #39; contenidos entre invocaciones de un procedimiento o bloque. El almacenamiento CONTROLADO también se gestiona mediante una pila, pero el programador gestiona la inserción y extracción de asignaciones en la pila mediante ALLOCATE y FREE declaraciones. El almacenamiento de las variables BASED se administra mediante ALLOCATE/FREE, pero en lugar de una pila, estas asignaciones tienen una duración independiente y se gestionan a través de OFFSET variables o POINTER.

El atributo AREA se utiliza para declarar montones definidos por el programador. Los datos se pueden asignar y liberar dentro de un área específica, y el área se puede borrar, leer y escribir como una unidad.

Compartir tipo de almacenamiento

Hay varias formas de acceder al almacenamiento asignado a través de diferentes declaraciones de datos. Algunos de estos están bien definidos y son seguros, algunos se pueden usar de manera segura con una programación cuidadosa y algunos son intrínsecamente inseguros y/o dependientes de la máquina.

Pasar una variable como argumento a un parámetro por referencia permite que se haga referencia al almacenamiento asignado del argumento mediante el parámetro. El atributo DEFINED (por ejemplo, DCL A(10,10), B(2:9,2:9) DEFINED A) permite que parte o la totalidad de una variable' s de almacenamiento para ser utilizado con una declaración diferente, pero coherente. La definición del idioma incluye un atributo CELL (más tarde renombrado como UNION) para permitir que diferentes definiciones de datos compartan el mismo almacenamiento. Esto no fue compatible con muchos de los primeros compiladores de IBM. Estos usos son seguros e independientes de la máquina.

La E/S de registros y el procesamiento de listas producen situaciones en las que el programador necesita ajustar una declaración al almacenamiento del siguiente registro o elemento, antes de saber qué tipo de estructura de datos tiene. Las variables basadas y los punteros son clave para este tipo de programas. Las estructuras de datos deben diseñarse de forma adecuada, normalmente utilizando campos en una estructura de datos para codificar información sobre su tipo y tamaño. Los campos se pueden mantener en la estructura anterior o, con algunas restricciones, en la actual. Cuando la codificación se encuentra en la estructura anterior, el programa debe asignar una variable basada con una declaración que coincida con el elemento actual (utilizando expresiones para las extensiones cuando sea necesario). Cuando la información de tipo y tamaño se mantenga en la estructura actual ("estructuras autodefinidas"), los campos que definen el tipo deben estar delante de los elementos dependientes del tipo y en el mismo lugar en cada versión de los datos. estructura. La opción REFER se utiliza para extensiones autodefinidas (por ejemplo, longitudes de cadena como en DCL 1 A BASADO, 2 N BINARIO, 2 B CHAR(LENGTH REFER A.N.), etc. – donde LENGTH se usa para asignar instancias de la estructura de datos. Para estructuras autodefinidas, cualquier campo de escritura y REFERED se coloca delante del "real&#34 Si los registros en un conjunto de datos, o los elementos en una lista de estructuras de datos, están organizados de esta manera, pueden manejarse de manera segura e independiente de la máquina.

Las implementaciones de PL/I (a excepción del compilador PL/I Checkout) no realizan un seguimiento de la estructura de datos utilizada cuando se asigna el almacenamiento por primera vez. Cualquier declaración BASED se puede usar con un puntero en el almacenamiento para acceder al almacenamiento, intrínsecamente inseguro y dependiente de la máquina. Sin embargo, este uso se ha vuelto importante para la "aritmética de punteros" (típicamente agregando una cierta cantidad a una dirección conocida). Este ha sido un tema polémico en informática. Además del problema de las referencias salvajes y los desbordamientos del búfer, surgen problemas debido a la alineación y la longitud de los tipos de datos utilizados con compiladores y máquinas particulares. Muchos casos en los que podría ser necesaria la aritmética de punteros implican encontrar un puntero a un elemento dentro de una estructura de datos más grande. La función ADDR calcula dichos punteros, de forma segura e independiente de la máquina.

La aritmética de punteros se puede lograr creando un alias de una variable binaria con un puntero como en
PUNTERO DCL P, N BINARIO FIJO(31) BASADO(DIRECCIÓN(P)); N=N+255;
Se basa en que los punteros tienen la misma longitud que los enteros FIXED BINARY(31) y están alineados en los mismos límites.

Con el predominio de C y su actitud libre y sencilla hacia la aritmética de punteros, los compiladores IBM PL/I recientes permiten que los punteros se utilicen con los operadores de suma y resta para brindar la sintaxis más simple (pero las opciones del compilador pueden rechazar estas prácticas donde la seguridad y la independencia de la máquina son primordiales).

Unidades ON y manejo de excepciones

Cuando se diseñó PL/I, los programas solo se ejecutaban en modo por lotes, sin intervención posible del programador en una terminal. Una condición excepcional como la división por cero abortaría el programa produciendo solo un volcado hexadecimal del núcleo. El manejo de excepciones PL/I, a través de unidades ON, permitió que el programa mantuviera el control frente a excepciones de hardware o sistema operativo y recuperara la información de depuración antes de cerrarse con más gracia. A medida que un programa se depuraba correctamente, la mayor parte del manejo de excepciones podía eliminarse o deshabilitarse: este nivel de control se volvió menos importante cuando la ejecución conversacional se convirtió en un lugar común.

El manejo de excepciones computacionales se habilita y deshabilita mediante prefijos de condición en sentencias, bloques (incluidas las unidades ON) y procedimientos. - p.ej. (TAMAÑO, NOSUBSCRIPTRANGE): A(I)=B(I)*C; . Las excepciones del sistema operativo para Entrada/Salida y administración de almacenamiento siempre están habilitadas.

La unidad ON es una sentencia única o bloque BEGIN introducido por una sentencia ON. Ejecutar la instrucción ON habilita la condición especificada, por ejemplo, ON ZERODIVIDE ON-unit. Cuando ocurre la excepción para esta condición y la condición está habilitada, se ejecuta la unidad ON para la condición. Las unidades ON se heredan a lo largo de la cadena de llamadas. Cuando se activa un bloque, procedimiento o unidad ON, las unidades ON establecidas por la activación invocadora son heredadas por la nueva activación. Pueden ser anulados por otra sentencia ON y pueden ser restablecidos por la sentencia REVERT. La excepción se puede simular utilizando la declaración SIGNAL, p. para ayudar a depurar los controladores de excepciones. El principio de herencia dinámica para unidades ON permite que una rutina maneje las excepciones que ocurren dentro de las subrutinas que usa.

Si ninguna unidad ON está en efecto cuando se genera una condición, se toma una acción estándar del sistema (a menudo esto es para generar la condición ERROR). La acción del sistema se puede restablecer utilizando la opción SYSTEM de la sentencia ON. Con algunas condiciones, es posible completar la ejecución de una unidad ON y volver al punto de interrupción (por ejemplo, STRINGRANGE, UNDERFLOW, CONVERSION, OVERFLOW, AREA y FILE) y reanudar la ejecución normal. Con otras condiciones como (SUBSCRIPTRANGE), se genera la condición ERROR cuando se intenta. Una unidad ON se puede terminar con un GO TO que evita el regreso al punto de interrupción, pero permite que el programa continúe ejecutándose en otro lugar según lo determine el programador.

Una unidad ON debe diseñarse para manejar las excepciones que ocurren en la propia unidad ON. La declaración ON ERROR SYSTEM; permite una trampa de error anidada; si ocurre un error dentro de una unidad ON, el control podría pasar al sistema operativo donde podría producirse un volcado del sistema o, para algunas condiciones computacionales, continuar la ejecución (como se mencionó anteriormente).

Las sentencias de E/S RECORD de PL/I tienen una sintaxis relativamente simple, ya que no ofrecen opciones para muchas situaciones, desde el final del archivo hasta los errores de transmisión de registros que pueden ocurrir cuando un registro es leído o escrito. En su lugar, estas complejidades se manejan en las unidades ON para las diversas condiciones de archivo. Se adoptó el mismo enfoque para la subasignación AREA y la condición AREA.

La existencia de unidades ON de manejo de excepciones puede tener un efecto en la optimización, porque las variables se pueden inspeccionar o modificar en unidades ON. Es posible que los valores de las variables que de otro modo se mantendrían en registros entre sentencias, deban devolverse al almacenamiento entre sentencias. Esto se discute en la sección anterior sobre Cuestiones de implementación.

IR A con un objetivo no fijo

PL/I tiene equivalentes para las instrucciones GO TO especializadas de COBOL y FORTRAN.

Existe sintaxis para COBOL y FORTRAN para codificar dos tipos especiales de GO TO, cada uno de los cuales tiene un objetivo que no siempre es el mismo.

• ALTER (COBOL), ASSIGN (FORTRAN):
  • ALTER paragraph_name_xxx Procede para_name_zzz.

    Hay otras restricciones/ayudas sobre estas, especialmente "en los programas... Atributo RECURSIVA, en métodos, o.. opción TERCERA."

  • ASIGN 1860 TO IGOTTAGO
    IGOTTAGO

    Una mejora, que añade documentación incorporada, es
    IGOTTAGO (1860, 1914, 1939)

    (que restringe el valor de la variable a "una de las etiquetas en la lista".)

• GO TO... basado en el valor subscript-like de una variable.
  • GO TO (1914, 1939, 2140), MYCHOICE
  • Vamos a... One para_ Dos para_ Tres muertes en IDECIDE.

PL/I tiene variables de etiqueta de sentencia (con el atributo LABEL), que pueden almacenar el valor de una etiqueta de sentencia y luego usarse en una sentencia GOTO.

LABL1:...
.
.
LABL2:...
.
.
.
MY_DEST = LABL1;
.
Vayan a My_DEST;
AQUI (LUCKY_NUMBER); /* menos 1, cero, o... */

AQUI(-1): PUT LIST ("I O U"); GO TO Lottery;
AQUI(0): PUT LIST ("No efectivo"); GO TO Lottery;
AQUI (1): PUT LIST ("Dollar Bill"); GO TO Lottery;
AQUI (2): PUT LIST ("TWO DOLLARS"); GO TO Lottery;

Las variables de etiqueta de declaración se pueden pasar a los procedimientos llamados y se pueden usar para regresar a una declaración diferente en la rutina de llamada.

Programas de muestra

Programa hola mundo

Hola2: proc opciones()principal); # lista ()¡Hola, Mundo! ');final Hola2;

Buscar una cadena

/* Lea en una línea, que contiene una cadena,/* y luego imprimir cada línea posterior que contiene esa cadena. */find_strings: procedimiento opciones ()principal); Declara patrón carácter ()100) variable; Declara línea carácter ()100) variable; Declara line_no fijo binario; on endfile ()Sysin) Para; # edición ()patrón) ()L); line_no = 1; do para siempre; # edición ()línea) ()L); si índice()línea, patrón) ■ 0 entonces # Patrón lista ()line_no, línea); line_no = line_no + 1; final;final find_strings;