Hoy quiero explicarles de forma directa qué es un archivo físico de código fuente (Source Physical File), cómo lo manejamos tradicionalmente en el sistema y cómo estamos evolucionando hacia estándares más modernos con SQL y Git.

📝 ¿Qué es un Source Physical File?

En el AS/400, es un archivo que utilizamos para guardar el código fuente de diferentes tipos de objetos.

Para crearlo, usamos el comando CRTSRCPF. Un ejemplo clásico:

CRTSRCPF FILE(IROBO1/QRPGSRC) RCDLEN(112) TEXT('SOURCE PHYSICAL FILE')

💡 Datos técnicos a tener en cuenta:

Puede almacenar hasta 32,767 miembros.
El archivo en sí es un "objeto" para el sistema, pero el miembro (el código) no lo es. El objeto real se genera únicamente cuando compilamos ese miembro.

🔍 Cómo ver y gestionar los miembros

Para trabajar con los miembros dentro de un archivo físico, el comando del día a día es WRKMBRPDM. La pantalla verde nos muestra algo así:

                           Work with Members Using PDM                 PUB1     
                                                                                
 File  . . . . . .   QRPGLESRC                                                  
   Library . . . .     IROBO1               Position to  . . . . .              
                                                                                
 Opt  Member      Type        Text                                              
      ACCOUNT     PF          ACCOUNT RELATED INFORMATION                       
      PRINT1      PRTF        PRINTER DDS RLU GENERATED                         
      PRINT1PGM   RPGLE       rpgle program for print1

✨ Tip rápido: Si quieres agregar un código fuente nuevo desde esta pantalla, simplemente presiona F6.

📐 Estructura y Longitudes del Archivo

Internamente, el archivo físico tiene una estructura de columnas muy estricta:

Primeras 12 Columnas	Siguientes 80 Columnas	Últimas 12 Columnas
Número de serie y Fecha	Código fuente	Comentarios

Si quieren verificar esta estructura en crudo, pueden tirar este query:

RUNQRY QRYFILE ((QRPGLESRC *LAST))

Sobre las longitudes (¡Muy importante!):

Longitud por defecto del sistema: 92
Longitud recomendada: 112

⚠️ Ojo aquí: Si copias código desde un archivo que tiene longitud 112, asegúrate de que el archivo de destino también sea de 112. Si no, el código se cortará y el programa no va a compilar.

🛠️ Viendo los detalles internos (DSPFD)

Si necesitas ver los detalles a nivel de sistema del archivo, el comando es DSPFD.

Ejemplo: DSPFD IROBO1/QRPGLESRC

Este comando te da información vital:

Identificadores de Nivel (Level Identifiers): Son marcas de tiempo ("hashes") de la creación del archivo, miembro o formato. Son cruciales porque evitan que el sistema restaure versiones incorrectas por error o que un programa intente leer una tabla que fue modificada (Level Check).
Capacidad: Cuántos registros tienes y cuál es el límite de crecimiento.

Para filtrar y ver solo la lista de miembros sin tanta información extra, usamos:

DSPFD FILE(IROBO1/QRPGLESRC) TYPE(*MBRLIST)

🚀 La Alternativa Moderna: SQL y el IFS

Los Source Physical Files y WRKMBRPDM son súper robustos, pero el desarrollo en IBM i ha evolucionado. Hoy en día, las mejores prácticas apuntan a trabajar como lo hacemos en cualquier otro entorno de desarrollo moderno.

Esto se divide en dos grandes cambios que aplico y recomiendo:

1. SQL como reemplazo de DDS

Históricamente, definíamos las bases de datos usando DDS dentro de un Source Physical File.

La vía moderna es usar SQL (DDL). Crear tablas con un simple CREATE TABLE es más rápido, el motor del sistema lo procesa de forma más eficiente y cualquier desarrollador Backend puede entender tu base de datos de inmediato.

2. El IFS y Git

Para guardar el código fuente (RPG, SQL, etc.), la tendencia es salir de la "pantalla verde" (SEU) y olvidarnos del límite de 112 caracteres.

Lo ideal es guardar el código en el IFS (Integrated File System) como archivos de texto normales (.rpgle, .sql). Las ventajas son masivas:

Puedes usar VS Code con la extensión de IBM i.
Te permite implementar control de versiones real utilizando Git (GitHub, GitLab, etc.).

🏷️ Convenciones de Nombres Modernas

Antes, el sistema nos obligaba a usar nombres de máximo 10 caracteres, creando cosas ilegibles como CUSTDTAPF.

Gracias a SQL, ahora podemos (y debemos) usar Nombres Largos (Long SQL Names) de hasta 128 caracteres.

La regla de oro: Sé descriptivo.
Estándar: Usa snake_case (palabras_separadas_por_guion).
Ejemplo: En vez de CUSTDTAPF, usa customer_master_data.

💡 El truco de retrocompatibilidad:

Si tienes programas RPG heredados que obligatoriamente necesitan el nombre corto de 10 caracteres, SQL te permite tener lo mejor de ambos mundos usando FOR SYSTEM NAME. Así creas una tabla moderna, pero el sistema le mantiene un "alias" corto para el código viejo:

SQL

CREATE TABLE my_company_customer_data FOR SYSTEM NAME CUSTDTAPF (
    customer_id INT NOT NULL,
    customer_name VARCHAR(100),
    PRIMARY KEY (customer_id)
);

¡Espero que esta guía les sirva para entender las bases y animarse a modernizar sus desarrollos! Cualquier duda, lo vemos en los comentarios.