PDF de programación - attitudes 300

Imágen de pdf attitudes 300

attitudes 300gráfica de visualizaciones

Actualizado el 21 de Marzo del 2018 (Publicado el 22 de Noviembre del 2017)
251 visualizaciones desde el 22 de Noviembre del 2017
4,7 MB
16 paginas
Creado hace 5a (17/11/2014)
Información sobre Power Systems, incluidos AS/400, iSeries y System i

Año 28 - Noviembre-Diciembre 2014

Nº 300 Precio: 7 Euros

COLABORACIONES
Encontrar una Vista de una Vista...

Las DDL del SQL (Data Definition
Language) ofrecen muchas ventajas, una
de las cuales es la posibilidad de definir
una vista de una vista. Esto puede llevar
a sencillas o complejas estructuras me-
diante el uso de vistas de una vista de
una vista… Creo que podemos hacernos
una idea. Pero una de las dificultades con
esta técnica es que una vez creada, es
difícil determinar la profundidad de las
dependencias de las vistas. El mandato

DSPDBR (Display Database Relations)
le dirá que vistas son inmediatamente
dependientes de una vista, pero no de las
dependientes de esas.
En este artículo vamos a conocer un
Stored Procedure que proporcionará una
lista completa de las vistas dependientes
y todas las que dependan de las anterio-
res, y así hasta el final.

Sigue en página 11

¿El estado de la seguridad en
IBM i? Notablemente mejorable

Las empresas continúan asumiendo
riesgos innecesarios al seguir sin prote-
ger adecuadamente sus entornos IBM i,
según el informe 2014 del Estado de la
Seguridad en IBM i publicado por Power-
Tech. Si bien se detectaron todo tipo de
deficiencias en seguridad que van desde
perfiles de usuario demasiado potentes al
uso de niveles de seguridad muy laxos,
lo más notorio tiene quizás que ver con la
pobre gestión de contraseñas.
La mala práctica en la gestión de cla-
ves deja a muchas instalaciones IBM i

expuestas a hacker externos y amenazas
internas. No va a encontrar problemas de
contraseñas a nivel de Heartbleed, dónde
billones de contraseñas instantáneamente
resultaron vulnerados. Pero considerando
el nivel de ajuste disponible en el sistema
operativo IBM i a través de sus facilida-
des y configuraciones, como la capacidad
de forzar a los usuarios a utilizar contrase-
ñas fuertes y con duraciones limitadas, es
realmente reprobable que las contraseñas
no sean más seguras de lo que son.

Sigue en página 9

SUMARIO

Colaboraciones

6

2

Cursores de Paginación
Funciones SQL que desconoce
tener
¿El estado de la seguridad en
IBM i? Notablemente mejorable 9
Encontrar una Vista de una Vista
de una Vista...

Consulting

11









Restauración de autorizaciones
privadas con RSTUSRPRF 14
Procesador externo de tarjetas de
crédito y *LOOPBACK

15

Novedades

Gestión centralizada de
comunicaciones 8

Funciones SQL que desconoce tener

¿Qué pensaría si le dijera que puede
que tenga algunas funciones SQL muy po-
tentes en su sistema que desconoce? ¿Qué
le parece si le digo que ni siquiera se sabe
como se llaman? ¿Sabe que podría utilizar
sus rutinas existentes RPG en consultas
SQL? ¿Le interesaría?
Es fácil realizar que las funciones SQL
de los subprocedimientos en programas de
servicio. Por ejemplo, he aquí el código

fuente de un módulo RPG con el que un
programa de servicio es construido.
No tiene que utilizar RPG free-form,
como yo he hecho al realizar esta ilustra-
ción. El RPG de formato fijo funciona igu-
lamente.
He basado este módulo ilustrativo en
un proyecto en el que he trabajado recien-
temente. Tuve que trabajar con datos don-
de un solo valor almacenaba la ciudad,

estado, código postal y país. Tenía que en-
contrar la manera de separar las distintas
partes de la dirección. Este ejemplo es una
versión simplificada que extrae la ciudad,
estado y código postal (americano). En
esta versión, asumo que la ciudad está se-
guida de una coma y un espacio, luego el
estado, un espacio y finalmente el código
postal.

Sigue en página 6

COLABORACIONES

Cursores de Paginación

Querría compartir con ustedes una de las técnicas que
empleo para paginar listas grandes al utilizar SQL
insertado en RPG. Este método se me ocurrió cuando
necesitaba escribr una rutina que pudiese ser utilizada en
una pantalla interactiva (pantalla verde) y en un entorno
web. Había dos retos importantes:

• El tamaño de una página puede variar. Esto fue fácil
de manejar.Solo tuve que decidir el tamaño máximo de la
página.
• El interfaz web no sería persistente. Lo que significa
que diferentes trabajos de servidor estarían manejando
distinta solicitudes de paginación. Esto a su vez, significa
que el cursor (para la sentencia SELECT de SQL) tenía
que cerrarse después de cada recuperación. Pero, el SQL
Query Engine (SQE) es muy inteligente y el trabajo hecho
para un trabajo podría ser utilizado por otro. Por ello, la
apertura y cierre del cursor de cada solicitud de página
tiene un impacto mínimo.
LOS REQUISTOS
Además de recuperar la página de información
requerida, había otros requisitos sobre como se solicitaba

la información e información adicional que sería devuelta
desde la rutina. La rutina requería parámetros de entrada
para especificar:

• El número de filas en una página.
• Qué página recuperar.
• Un valor de desplazamiento de la página a recuperar.
Por ejemplo, la página recuperada es el parámetro
anterior más este valor. Esto permite la lógica de ir
adelante y atrás en una ejecución.

La rutina requería parámetros de salida que

especificaran:

• La página requerida.
• El número total de páginas.
• El número total de filas.
• El número de filas en esta página.
El interfaz de llamada para una de estas rutinas de

paginación es el siguiente:

ATTITUDES Nº 300

2

Noviembre-Diciembre 2014

COLABORACIONES


 


 

d get_list_Employees...
d pr
extProc('get_list_Employees')
d department 10a const
d currentPage 10i 0 const
d nextPage 10i 0 const
d pageSizeIn 10i 0 const
d currentPageIs 10i 0
d totalpages 10i 0
d totalRows 10i 0
d gotRows 10i 0
d data likeDS(b_list_Employees)

d dim(9999)
 

d b_list_Employees...
d Ds qualified template
d employee 5a
d fullName 50a varying
d library 10a

d salary 15p 2
 

Ahora veamos el siguiente código que muestra la
definición de la plantilla b_list_Employees, que se utiliza

en la definición de la variable array del host utilizada en
la recuperación de datos.

La parte del SQL
El hecho de que el cursor se abra y se cierre en cada
llamada significa que el SQL insertado es bastante claro. El
siguiente trozo de código muestra una rutina de paginación
SQL. El proceso es el siguiente:

• Declarar el cursor. El cursor se define como un cursor
no sensible para asegurarse que se devuelve el número de
filas correcto en el siguiente GET DIAGNOSTICS.

• Abrir el cursor.
• Utilizar GET DIAGNOSTICS para determinar el

número otal de filas en el set de resultados.

• Llamar al subprocedimiento calculate_Page_Data()
para calcular valores de parámetro devueltos (número
páginas totales, etc) pero, lo que es más importante, para
calcular el desplazamiento a la primer fila que recuperar del
set de resultados. Luego veremos el subprocedimiento.

• Utilizar una captura multi-línea para recuperar el
número de filas solictiado (tamaño de página) del set de
resultados. FETCH RELATIVE se utiliza con el
desplazamiento de fila calculado para asegurarse de
recuperar la página correcta.

• Obtener el número de filas recuperadas.
• Cerrar el cursor.

ATTITUDES Nº 300

3

Noviembre-Diciembre 2014

COLABORACIONES


 

p get_list_Employees...
p b export
d pi
d department 10a const
d currentPage 10i 0 const
d nextPage 10i 0 const
d pageSizeIn 10i 0 const
d currentPageIs 10i 0
d totalpages 10i 0
d totalRows 10i 0
d gotRows 10i 0
d data likeDS(b_list_Employees)
d dim(9999)

d pageSize s 10i 0
d rowOffset s 10i 0

/free

exec SQL
declare C001 insensitive scroll cursor for
select empno, firstNme || ' ' || lastname, salary
from employee
where workdept = :department
order by empno
for read only;

exec SQL
open C001;

exec SQL
get diagnostics :totalRows = DB2_NUMBER_ROWS;

calculate_Page_Data(currentPage
:nextPage
:pageSizeIn
:%elem(data)
:currentPageIs
:totalpages
:totalRows
:pageSize
:rowOffset
);

exec SQL
fetch relative :rowOffset from C001
for :pageSize rows into :data;

gotRows = SQLERRD(3);

exec SQL
close C001;

return;
/end-Free

p e
 

ATTITUDES Nº 300

4

Noviembre-Diciembre 2014

COLABORACIONES

EL SUBPROCEDIMIENTO
CALCULATE_PAGE_DATA()
Ya que el proceso de cálculo de datos de página será
el mismo en todos los procedimientos de paginación SQL
que utilicen este método, tiene sentido ponerlo en su
propio subprocedimiento que llamamos calculate_Page_
Data(). Se muestra más aba
  • Links de descarga
http://lwp-l.com/pdf7618

Comentarios de: attitudes 300 (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios
Es necesario revisar y aceptar las políticas de privacidad