COBOL On Wheelchair, crea tu propio backend para iOS Apps con COBOL (por @jmoreno78).

Autor: | Última modificación: 9 de abril de 2024 | Tiempo de Lectura: 3 minutos
Temas en este post: ,
jesus_and_the_dinosaurs_backend para iOS Apps
¿Quien ha dicho que los dinosaurios estaban olvidados de Dios?
La verdad sea dicha, el COBOL no goza de una gran presencia en los medios, no porque sea una tecnología en desuso o cosa del pasado (como algunos se empeñan en decir) sino, principalmente, por la falta de noticias. Por ese motivo, todavía me sorprende que una noticia con tanto impacto en el mundo de la informática financiera haya pasado desapercibida: la semana pasada se presento COBOL On Wheelchair, un framework para realizar aplicaciones web usando COBOL como lenguaje de programación de base. Desde los principios de Internet, se ha estado buscando la manera de poder utilizar toda la base de software instalada en los mainframes de entidades financieras y aseguradoras de todo el mundo en las aplicaciones web. Hasta la fecha, se estaba utilizando Java o .Net para la capa de presentación y mediante el CICS Transaction Getway (CGT) IBM nos había permitido acceder a los backends desarrollados en COBOL en los cuales residía toda la lógica del negocio. Ahora, gracias a la partición UNIX que todos los mainframes de la serie Z traen consigo, es posible instalar un servidor Apache y utilizar este impresionante y ligero framework para presentar una página web, devolver un json, etc.
IBM 3279: ¡Ahora con gráficos!
IBM 3279: ¡Ahora con gráficos!
Ni que decir tiene que el mundo mainframe anda revolucionado estos días, sobre todo por la posibilidad a largo plazo de ir eliminando tecnologías tan problemáticas como Java o .Net. Aunque se trata de un proyecto Open Source, es posible que IBM termine siendo uno de los principales supporters como sucede con otros proyectos Open Source, tal es el caso de Eclipse. Para que veáis este framework en todo su esplendor, os dejo un pequeño tutorial de lo que supondría realizar un backend para una lista de tareas con este framework.

Configuración de métodos

Desgraciadamente, en este punto del proyecto todavía no es posible construir API´s REST. Por ese motivo crearemos métodos para cada una las opciones de nuestro servicio. Esto se lleva a cabo en el fichero config.cbl
move "/getAllTasks"         to routing-pattern(1).
move "getTasks"             to routing-destiny(1).

move "/newTask/%task"       to routing-pattern(2).
move "newTask"              to routing-destiny(2).

move "/deleteTask/taskId"   to routing-pattern(3).
move "deleteTask"           to routing-destiny(3).
El array de rutas permite almacenar hasta 99 métodos, pero es fácilmente ampliable a 999 cambiando el número de ocurrencias del array y pasando el tamaño del indice a 9(3). Como vemos, es bastante sencillo. Cada uno de estos métodos es un programa COBOL almacenado en la carpeta /controllers/ del proyecto con extensión .cbl.

Picando en COBOL como si no hubiera un mañana.

El COBOL no es un lenguaje complicado, solo hay que tener en cuenta alguna de sus particularidades, como que la definición de las variables debe realizarse en una zona concreta del programa y que la estructura de dicho programa no puede ser alterada. Una vez que nos hayamos acostumbrado a esta rigidez, desarrollar aplicaciones web con COBOL será coser y cantar. En concreto, vamos a ver el controlador del método getAllTasks:
identification division.
program-id. getTasks.

data division.
working-storage section.

  01 the-vars.

    03  task-vars OCCURS 99 times.

      05 task-id           pic 9(3).
      05 task-desc         pic X(256).   
      05 task-created-at   pic X(26).   

    03  error-vars.

      05 error-code        pic 99.
      05 error-desc        pic x(100).  

  01 the-indexes.
    03 in-curtask          pic 99.

  01 the-switches.
    03 sw-curtask          pic 9
      88 fin-curtask      value 1.
      88 no-fin-curtast   value 0.

EXEC SQL
  INCLUDE SQLCA
END-EXEC.

EXEC SQL DECLARE curtask CURSOR FOR
  SELECT task_id, task_desk, task_created_at FROM tasks  
END-EXEC.

linkage section.

procedure division.

  perform open-curtask

  perform
  varying in-curtask from 1 by 1
   until in-curtask = 99
      or fin-curtask

      EXEC SQL
        FETCH curtask 
         INTO :task-id(in-curtask),
              :task-desc(in-curtask),
              :task-created-at(in-curtask)
      END-EXEC
      if SQLCODE = 100
        set fin-curtask to true
      end-if

  end-perform

  perform close-curtask

  call 'template' using task-vars "tasks-json.cow".

  goback.

  open-curtask
    EXEC SQL
       OPEN curtask
    END-EXEC

  close-curtask
    EXEC SQL
      CLOSE curtask
    END-EXEC

end program getTasks.

Displayando un json

El propio framework soporta la instrucción display para devolver los datos al servidor para que los pinte. Para ello, hay que crear una plantilla con nombre tasks-json.cow en la carpeta /views.
{
    "tasks": [
        <% task-vars.each do %>
            { "id":<%= task-id %> ,  
              "task":<%= task-desc %> ,  
              "createdAt":<%= task-created-at %> , }, 
        <% end %>
    ]
}

Conclusiones.

Usar un mainframe para alojar el backend de una aplicación web o móvil con COBOL nunca había sido tan fácil. Ya os digo que oiréis hablar de esto porque el avance es espectacular.
El Movimiento RetroGeek ha llegado con fuerza: ¡súbete al carro antes que sea tarde!
El Movimiento RetroGeek ha llegado con fuerza: ¡súbete al carro antes que sea tarde!