Seguridad del IBM i AS/400

Seguridad del IBM i AS/400

En la siguiente presentación expongo los conceptos de seguridad y gestión de la seguridad en la plataforma IBM i AS/400. 

Seguridad del ibm i as400 from Giovanny Guillen

Read More

RPG - SQL Embebido

SQL EN PROGRAMAS RPG

RPG permite el uso de operaciones SQL en lugar de uitlizar operaciones de base de datos, como READ, CHAIN, UPDATE, y DELETE.

¿Porqué utilizar operaciones SQL?

SQL es un lenguaje natural, facil de mantener y leer. 
SQL puede simplificar la lógica cuando múltiples registros son incluidos en una operación, como UPDATE o DELETE. 
Las operaciones son ejecutadas por medio de un optimizador de consultas. 
La migración de aplicaciones desde o al IBM i (AS/400) es facil si las aplicaciones estan escritas usando un lenguaje estandard como el SQL.
Las sentencias SQL son procesadas por el Proprocesador SQL. 

Reglas para la codificación en RPG. 

Las sentencias SQL se deben ingresar sobre las especificaciones C o en la sección de codificación. 
Deben comienzar SQL con el delimitador /EXEC SQL. 
La sentencias SQL se pueden ingrear sobre la misma linea donde comienza el delimitador o sobre una nueva linea. 
Se debe utilizar el delimitador de linea de continuación, un “+” (signo más) para continuar la codificación de sentencias en lineas subsecuentes. 
El delimitador de final /END-EXEC señala el fin de sus sentencia SQL.
Los fuentes de los programas RPG que contienen SQL deben ser del tipo SQLRPGLE.
Para crear los programas SQL RPG se debe utilizar el comando CTRSQLRPGI, el cual es requerido para llamar al Preprocesador SQL.
Nota: en la versión FREE-Form de RPG no se requiere el slash "/" ni el simbolo "+".

Ejemplo de una sentencia SQL UPDATE incrustada:

/Exec Sql 
+ Update Parts
+ Set PartDes = :DspDes,
+ PartQty = :DspQty,
+ PartPrc = :DspPrc,
+ PartDat = :DspDat
+ Where PartNum = :DspNum 
/End-Exec

Manejo de exepciones y errores.

SQL devuelve codigos de error al programa de aplicación cuando una excepción ocurre. Estos codigos de error pueden ser usados de dos maneras: 
Chequeando codigos de error en un area de comunicaciones SQL. 
Definiendo gestores globales de error con una sentencia WHENEVER. 

Area de comunicaciones SQL.

El preprocesador SQL automáticamente incluye el SQLCA (SQL Communication Area) en las especificaciones D del programa RPG antes de las especificaciones C. Por lo tanto, no es necesario codificar INCLUDE SQLCA en el programa fuente.

El SQLCA, incluido en el programa ILE RPG, contiene los siguientes campos:

D* SQL Communications area

D SQLCA DS

D SQLAID 1 8A INZ(X'0000000000000000')

D SQLABC 9 12B 0

D SQLCOD 13 16B 0

D SQLERL 17 18B 0

D SQLERM 19 88A

D SQLERP 89 96A

D SQLERRD 97 120B 0 DIM(6)

D SQLERR 97 120A

D SQLER1 97 100B 0

D SQLER2 101 104B 0

D SQLER3 105 108B 0

D SQLER4 109 112B 0

D SQLER5 113 116B 0

D SQLER6 117 120B 0

D SQLWRN 121 131A

D SQLWN0 121 121A

D SQLWN1 122 122A

D SQLWN2 123 123A

D SQLWN3 124 124A

D SQLWN4 125 125A

D SQLWN5 126 126A

D SQLWN6 127 127A

D SQLWN7 128 128A

D SQLWN8 129 129A

D SQLWN9 130 130A

D SQLWNA 131 131A

D SQLSTT 132 136A

D* End of SQLCA

Para determinar si una senteicna SQL fue exitosa, el sistema operativo devuelve los  valores de respuesta en las variables SQLCOD y SQLSTT. Los programas RPG deben chequear los valores de estas variables y validar: 

1. Si SQL encuentra un error mientras procesa la sentencia, la variable SQLCOD contendrá un valor negativo, y los primeros dos caracteres de la variable SQLSTT serán diferentes de "00", "01", o "02". 
2. Si SQL encuentra una advertencia (warning) pero en una condición válida durante el procesamiento de sentecias SQL, el SQLCOD tendrá un numero positivo y los dos primeros caracteres del SQLSTT serán "01". 
3. Si su sentencia SQL es procesada sin encontrar una condición de error o advertencia, el SQLCOD retornará 0 y SQLSTT será "0000".
4. Si no se encuentra un registro, SQL devuelve los valores SQLCOD = +100 o SQLSTT = "02000". 

El area de comunicaciones contiene muchos otros campos con información relacionada con la sentencia SQL ejecutada. Por ejemplo, la sentencia WHENEVER, es una alternativa en lugar de chequear los valores de SQLCOD o SQLSTT. Esta sentencia indica al SQL chequear SQLSTT y SQLCOD, y continuar la precesamiento  o bifurcar a otra area del programa si un error, exepcion, o advertencia existe como resultado de la ejecuciòn de una sentencia SQL. Un manejador de condiciones de excepción puede ser escrito para examinar los campos SQLCOD o SQLSTT para tomar una acción especifica para la situación de error o excepción.

La sentencia WHENEVER tiene la siguiente apariencia:

/Exec Sql
+ WHENEVER Condition Action
/End-Exec

Hay tres condiciones que se pueden especificar:

1. SQLWARNIN: SQLCOD contiene un valor positivo diferente de 100 
2. SQLERROR: SQLCOD contiene un valor negativo (condición de error) 
3. NOT FOUND: SQLCOD = +100 o SQLSTT = '02000' 

Se puede especifiar la acción que quiere para cada condición

1. CONTINUE: El programa continua con la siguiente sentencia 
2. GO TO etiqueta: El programa bifurca a la etiqueta (TAG) dentro del programa.

Cursores SQL

Las sentencias SQL son orientadas a multiples registros y pueden manejar un grupo de registros a la vez. Por ejemplo, con una sentencia DELETE puede borrar todos los artículos de un pedido. Para lograr el procesamiento de los datos devuelltos por SQL registro a registro, se necesita escribir un bucle y validar diferentes condiciones. 

De acuerdo con este comportamiento, una sentencia SELECT pone todos los registros seleccionados en una tabla resultado. Un programa transferira todos estos registros desde la tabla de resultado SQL a un subfile. Para acceder a una tabla resultado, SQL provee una tecnica llamada cursor. Este es ustilizado para mantener una posición en la tabla resultado, permitiendo trabajar con los renglones en la tabla resultado y hacer que esten disponibles para el programa. Un programa puede tener varios cursores, aunque cada uno debe tener un único nombre.

Sentencias para el uso de cursores: 

1. DECLARE CURSOR: define el nombre del cursor y especifica los renglones a ser recuperados con una sentencia SQL incrustada. 
2. OPEN: abre el cursor para su uso dentro del programa. El cursor debe estar abierto antes de que cualquier registro puede ser recuperados. 
3. FETCH: recupera registros desde la tabla resultado o posiciona el cursor sobre otro registro. 
4. CLOSE: cierra el cursor.

Los siguientes recortes de código muestran el uso de un cursor:

/Exec Sql
+ DECLARE Cursor1 CURSOR FOR
+ SELECT * FROM Pedidos
+ ORDER BY Nroped
+ FOR FETCH ONLY
/End-Exec

/Exec Sql
+ OPEN Cursor1
/End-Exec


/Exec Sql
+ FETCH Cursor1 INTO :SF1DS
/End-Exec


/Exec Sql
+ CLOSE Cursor1
/End-Exec

SQL soporta dos tipos de cursores: serial y scrollable, que determina los metodos de posicionamiento que pueden ser usados.

1. Cursor serial: es definido por defecto, si la palabra clave SCROLL no es usada. Con un cursor serial, cada registro de la tabla resultado puede ser tomado unicamente una vez por cada OPEN del cursor. Cuando un cursor es abierto, este es posicionado antes del primer registro. Con cada sentencia FETCH, el cursor es movido al siguiente registro. Si se especifican variables de programa (con la clausula INTO en la sentencia FETCH), SQL mueve el contenido del regiestro actual a la variable de programa. Esta secuencia es repetida cada vez que emite la sentencia FETCH, hasta que el end-of-file (fin de archivo - SQLCOD = 100) es alcanzado, cerrando el cursor. Para usar otra vez el cursor, se debe primero cerrar y entonces volver a emitir la sentencia OPEN.
2. Cursor desplazable: Con un cursor desplazable, los registros de la tabla resultado pueden ser tomados muchas veces. El cursor se mueve a travez de la tabla resultado en función a la opción de posicion especificado en la sentencia FETCH. Cuando un cursor es abierto, este se posiciona antes del primer renglon en la tabla resultado. Con una sentencia FETCH, el cursor es posicionado sobre el renglon en la tabla resultado que se especifique por la opciòn de posiciòn.

Las siguientes son opciones de desplazamiento, que se usan para posicionar el cursor cuando emite la sentencia FETCH:

1. NEXT Posiciona el cursor sobre el siguiente renglon. (opcion por omisión) 
2. PRIOR Posiciona el cursor sobre el renglon previo. 
3. FIRST Posiciona el cursor sobre el primer renglon. 
4. LAST Posiciona el cursor sobre el último renglon. 
5. BEFORE Posiciona el cursor antes del primer renglon. 
6. AFTER Posiciona el cursor despues del ultimo renglon. 
7. CURRENT No cambia la posición del cursor. 
8. RELATIVE n Posiciona el cursor en n renglones relativo a la posiciòn actual. 

Read More

Programacion RPG - Operaciones

Programacion RPG Operaciones

En esta entrega presento las operaciones básicas, de control, decisiones y gestión de archivos más utilizadas en RPG.

Programacion RPG Operaciones from Giovanny Guillen

Read More

Programacion RPG - Especificaciones de Entrada y Salida

Programacion RPG Especificaciones de Entrada y Salida

En esta entrega presento como llevar a cabo las definiciones de entradas y salidas en RPG.

 from Giovanny Guillen

Read More

PROGRAMACION RPG

PROGRAMACION  RPG

En esta serie de presentaciones realizaré una introducción sobre los conceptos, programación y características avanzadas de este potente lenguaje muy utilizado en sistemas IBM i – AS/400.

Programación RPG - Conceptos from Giovanny Guillen

Read More

IBM i Screen Design AID - SDA

IBM i Screen Design AID - SDA

En esta entrega relacionada con el sistema IBM i - AS/400 presento la herramienta de diseño de pantallas SDA.

IBM i - AS/400 - SDA from Giovanny Guillen

Read More

IBM i - Manejo de Archivos y Datos

IBM i - Manejo de Archivos y Datos

En esta presentación describo como crear archivo de datos y vistas lógicas en el IBM i -AS/400 utilizando el lenguaje DDS.

IBM i - Manejo de archivos y datos from Giovanny Guillen

Read More

The History of the "System i" (eServer iSeries or AS/400)

The History of the "System i" (eServer iSeries or AS/400)

The history of the "System i" (eServer iSeries or AS/400), began with a computer which IBM called the IBM 1400. IBM 1400 Series was a series of second-generation transistorized computers midrange oriented administrative tasks that IBM marketed in early 1960. That machine is operated as independent systems, along with an IBM computer punch cards, or as a support team of other computer systems.

The 1400 series machines stored information in a magnetic core memory (also called "ferrite core") as strings of variable length, ending in a particular flag. The arithmetic was performed character by character. The entrance and exit were on punch cards, magnetic tape, and printer of the high-speed line. The first magnetic disk drives were available.

The Programming Languages the 1400 series included Symbolic Programming System (SPS, assembler language), Autocode, COBOL, FORTRAN, and RPG.

The System/360 replaced those machines and low-level computers like the IBM System/3 and the subsequent System/32, System/34, System/36, System/38, and AS/400.

The System/3:

The System/3 (presented 1,969 1,985 discontinued) was a computer for new customers and organizations which was still using IBM computers of the series 1400. It was the first member of what referred to as IBM midrange computers or minicomputers, and the operating system was based on batch processes. Thus IBM introduced the S/3 an online program called CCP (Communications Control Program. "), Which runs as a batch program, then by 1975 the operating system called SCP (system control program." )

The System/32:

The IBM System/32 was a computer-oriented small and medium businesses, primarily for accounting and ERP applications. Used as the main programming language RPGII. This machine was the successor to the IBM System/3 in the line of IBM midrange computer.

The team seemed a desk and had a built-in printer. It was between 16 KB to 32 KB of memory, a hard disk that was available in only 5 MB, 9 MB or 13 MB in size, and a floppy drive eight inches. Among the software that is owned:

- SEU (useful for editing program sources),

- DFU (useful for editing and query data files, and to generate reports)

- OCL (Operations Control Language command language and online),

- # LIBRARY (Directory where is stored executable code),

- Word Processor.

The System/34:

The IBM System/34 was a minicomputer marketed by IBM from 1978 to 1983. It was a multi-user, multi-tasking successor to the System/32. Used as the main programming language RPGII. It had 64K of memory and a set of boxes of 8-inch diskettes. Similarly implemented the benefits inherited from the Mainframe tale as programmable job queues and priority levels.

The operating system was the System Support Program, or SSP, which contained support for multiprogramming, job queues, printer queues, security and support for indexed files.

The System/36:

The IBM System/36 was a minicomputer marketed by IBM from 1983 to 2000. The system was entirely multi-user, multi-tasking successor to the System/34. Like the previous systems and System/34, the System/36 used as the main programming language RPGII. Similarly had a box set of 8-inch diskettes. The System/36 also had many mainframe features such as programmable job queues and scheduling priority levels.

Features. 

This machine was flexible and powerful:

• Allowed 80 monitors and printers that are connected. All users could access the system's hard disk or printer.

• Provided password security and resources, allowing control over who was authorized to access any program or file.

• It supports devices up to a mile of the system drive.

• Users can mark a line through dial-up, from anywhere in the world and have a connection to 9600 baud (which was very fast in the 1980s), an excellent technology for connections that use only text screen and no graphics.

• It allowed the creation of databases of enormous size.

• It came to support four hard drives in his expanded cabinet which could hold up to 1453 gigabytes.

The System/38:

The System/38 was a platform built midrange server. The system offers a range of innovative features, which became available commercially in August 1979

The System/38 worked with a 48-bit address, and the operating system based on security as part of its architecture, where users could have controlled access to each object or library. The System/38 has been maintained and expanded in the AS/400 computer lines, ESRI, iSeries or System i. Among the programming languages available were included RPG III, COBOL, BASIC, and PL/I. The language of operational control of the System/38 was called CL, "Control Language." CL programs, similar in concept to the shell scripts, it could be compiled and executed natively. 

AS/400, eServer iSeries or System i

The IBM AS/400 was introduced in 1987 and later renamed the eServer iSeries in 2000. As part of IBM's Systems brand initiative in 2006, was again renamed as  "System i." Today we find in critical services like banking and accounting of large companies due to their high availability robustness. The operating system uses called OS/400. Among the programming languages available for developing applications include RPG (RPGILE and Free) and COBOL, supplemented by the interfaces in Java. As integrated DB2 database as part of the operating system.

In April 2008, IBM announced its integration with the System p platform This product line was renamed Consolidated Power Systems and has the support of the "System i" (formerly i5/OS and OS/400), similarly provides native support for AIX and Linux operating systems which were supported only with hardware not native.

The operating system was initially called OS/400 (following the naming scheme that gave birth to OS / 2 and OS/390). It was later known as i5/OS in line with the introduction of the eServer i5 servers with POWER5 processors. Finally, IBM gave it the name of "IBM i" coinciding with version 6.1.

Features include a handle integrated database (DB2/400), a menu-driven interface, multi-user support, terminals 5250, printers, and security, communications and web-based applications that could natively be implemented using service in WebSphere Application Server or PHP / MySQL using the Apache web server.

In the "System i" everything is an object, but also offers a set of Unix-like file directories using an integrated file system. This computer implements the Java compatibility through a native port of the Java virtual machine.

The IBM "System i" (known as AS/400) System/38 was a continuation of maintaining an integrated architecture with a database manager, adding compatibility with the similarly System/36 source.

It is one of the computer systems to achieve a C2 security rating from the NSA. In 1995 it extended the architecture with the objective of using a processor and 64-bit operating system. In 2000 the name was changed to IBM AS/400 iSeries as part of IBM's initiative aimed at eBusiness. IBM expanded the product line in 2004 with the introduction of the i5 servers, the first to use the IBM POWER5 processor. The system architecture allows future implementation of 128-bit, when available. Existing applications can use the new hardware without modification.

Read More