LLevamos trabajando 11 años en SQL con COBOL como standar, y yo que soy RPGero alguno hago en RPG. Trabajamos en 3 grandes aplicaciones, una de ellas esta totalmente desarrollada en SQL (definicion de tablas y programas), las otras dos son antiguas que seguimos manteniendo y mejorando, una de ellas ha sido pasada totalmente desde DDS a SQL, los programas existentes no se han tocado aunque se intenta adaptarlos cuando se necesita modificarlos, y los de nuevo desarrollo son CBLSQL como standar. La otra aplicacion proviene de entorno 36, osea definiciones internas, se esta trabajando en pasarala a SQL y esto es bastante mas costoso, los programas existentes no se cambian y solo los nuevos se intentan hacer CBLSQL, en un futuro cuando tengamos bien definida esa DB se estandarizara el CBLSQL. No se si es la mejor opcion pero es la que hemos elegido, eso si para el control de todo tenemos 1 persona por aplicacion dedicada unica y exclusivamente al mantenimiento, control y desarrollo de las DB. (Somos unos 40 desarrolladores). Recomendacion, merece la pena, pero hacerlo con cuidado y sin prisas, ah! ojo con los tiempos de proceso. Un pgm que en RPG tardaba menos de 1min en ejecutar, si no se han definido correctamente las sentencias SQL necesarias puede llegar a tardar dias. Y os juro que nos ha pasado. El DB2-400 es muy suyo.
Saludos. Rafael ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Javier Mora Sent: 13 February 2007 18:41 To: Forum AS/400 en castellano Subject: Otra de SQL vs DDS - dudas existenciales Hola a todos: Llevo más de 15 años desarrollando software sobre AS/400 e iSeries en RPG y DDS. De hecho, hoy todavía sigo utilizando DDS tanto para archivos de base de datos, pantallas e impresión. Desde mediados de los 90 llevo leyendo artículos sobre las iniciativas de IBM para que los desarrolladores empleen SQL en lugar de DDS/operaciones E/S en sus aplicaciones. Muchos de vosotros ya habéis dado el salto desde hace años. ¿Porqué yo todavía ni le he intentado? Recientemente he leído un artículo más sobre este asunto, en el que apunta una serie de razones que me convencen. Pero aún así, sigo con ciertas dudas existenciales. Tengo claro que podría empezar por sustituir archivos físicos y lógicos por tablas e índices. Ganaré en mucha en potencia expresiva. Lo que no tengo tan claro es el empleo de sentencias insert, update, delete para sustituir los write, update o delete de la E/S tradicional de RPG. Mis dudas son sencillas y simples: 1) Por el estilo de programación que hemos utilizado toda la vida, empleamos herramientas del estilo de DSPPGMREF para analizar el impacto de los cambios que queremos realizar en la aplicación. Por ejemplo, añadir un campo en un archivo, la división de un archivo en dos (formas normales), etc. Este mandato tiene controlado los programas llamados, programas de servicio y los archivos utilizados por los programas de aplicación. Si empiezo a utilizar SQL "incrustado" en mis programas voy a perder esta herramienta, ¿existe algún otro medio para realizar un análisis de impacto? No quiero realizar búsquedas en los fuente. ¿Estoy equivocado en esta apreciación? ¿Gano más que pierdo? 2) Siempre he creído tener claros conceptos como archivos físicos, lógicos y vías de acceso, pero ahora se me entremezcla todo con SQL. No se porqué. ¿Qué diferencia existe entre un índice y una vía de acceso o un lógico? 3) ¿Es realmente factible un entorno mixto? Es decir, dejar las aplicaciones actuales trabajando con E/S nativa pero los archivos definidos ya en SQL. ¿Es necesario realizar algún ajustes en los programas ya en producción? 4) ¿Estoy paranoico? ;-) Lo dejo aquí. Creo que me he enrollado demasiado. No sé si los ya lleváis trabajando con SQL años tuvisteis estas dudas existenciales. Un saludo a todos y gracias por "escuchar" mis lamentos. Cualquier comentario será bienvenido. Javier Mora
__________________________________________________ Forum.HELP400 es un servicio más de NEWS/400. © Publicaciones Help400, S.L. - Todos los derechos reservados http://www.help400.es _____________________________________________________ Para darte de baja visita la siguente URL: http://listas.combios.es/mailman/listinfo/forum.help400
