Software">
Pasos para CobolNet
Pasos para CobolNet
Pasos para CobolNet
Qué se obtiene
visual studio
Obtienes un proyecto en Visual Studio y un objeto OO-COBOL con la lógica de tu sistema. Todo
funcionando en NET y SIN cambiar de compilador.
El proyecto Visual Studio contiene un WINFORM (Windows Form) que será un clon de tu interfaz gráfica de
PowerCOBOL.
El objeto OO-COBOL contendrá todos los SCRIPTLETS de un FORM de PowerCOBOL adaptados a NET y al cual
la parte Visual Studio, puede llamar.
PCOB2NET genera fuentes COBOL sin utilizar ningún componente de terceros. El código generado es tuyo. Ya no
dependerás ni de PowerCOBOL ni tampoco de nosotros.
PowerCOBOL es un IDE completo propiedad de Fujitsu. Es utilizado por multitud de pequeñas empresas en el mundo.
Lamentablemente, como explicamos en nuestro documento aquí, su futuro está bastante comprometido hoy por hoy.
Desde luego, no es buena idea comenzar un desarrollo nuevo con este producto. Si tienes que invertir en COBOL para entornos
Windows, te recomendaría NetCOBOL para .NET. Los esfuerzos de Fujitsu y de GT Software (Distribuidora mundial de estos
productos) no van hacia PowerCOBOL sino hacia .NET con todos sus tipos de aplicaciones.
No obstante, muchas empresas ya tienen un sistema desarrollado con PowerCOBOL. El producto integra un compilador COBOL
de 32 bits. Lo será siempre según Fujitsu. La compañía que mantiene este software ya declaró hace años que no invertiría en la
mejora de PowerCOBOL. De momento, se mantiene en la cartera de productos de la serie NetCOBOL.
Concretamente, se mantiene como parte del producto NetCOBOL para Windows en su versión de 32 bits. Es la única manera
de adquirir hoy PowerCOBOL. Hemos sido distribuidores de NetCOBOL y otros productos de Fujitsu / GT-Software durante más
de 20 años. Sabemos de lo que hablamos.
Cuando salió Windows 10. El instalador de PowerCOBOL fallaba, si Windows era una instalación «fresca» en la máquina. Si
Windows había actualizado desde un Windows 8 o Windows 7 como UPGRADE, entonces los usuarios que ya tenían NetCOBOL
para Windows 32 bits, no tenían dificultades.
En aquella época, Fujitsu intentó hacer un comunicado que anunciaba la muerte de PowerCOBOL. Rápidamente, las protestas se
dejaron oír en todo el mundo. Naturalmente, no se le dio mucha publicidad a este fallo y sobre todo al anuncio. Fujitsu decidió
modificar la parte del instalador que fallaba (la de PowerCOBOL) y anunció que el producto seguiría en cartera dentro de
NetCOBOL para Windows 32 bits. Hasta hoy. ¿ Cuanto durará ? Nadie lo sabe.
En nuestra opinión, no lo tiene. Fujitsu anunció en la época que ya hemos comentado (salida de Windows 10), que lo mantenía
en cartera pero que no invertiría ningún recurso en la mejora del producto. No debemos esperar que esto cambie. Quizás vayan
modificando los instaladores para que se vaya pudiendo incorporar como hasta hoy, en la distribución de 32 bits de NetCOBOL
para Windows, pero no mejorará.
Incertidumbre de PowerCOBOL
En el peor de los casos, podríamos intuir que Fujitsu anunciara el final del soporte de PowerCOBOL. Esto sería factible. Ya lo hizo
una vez y nada les impediría volverlo a hacer de nuevo. ¿ Quien sabe ?
El mejor consejo que podemos dar es cambiar de entorno cuanto antes. No obstante, el cambio de lenguaje no es una opción
viable para muchas pequeñas empresas. Este tipo de migración de COBOL a otro lenguaje, requiere mucha inversión, sobre
todo en tiempo. Además, exige un cambio de mentalidad de los programadores que no siempre es fácil de gestionar.
Nosotros proponemos una migración de COBOL a COBOL. Parece quizás extraño pero es exactamente lo que hacemos.
Nosotros hablamos de modernización de COBOL y no de migración o cambio de lenguaje.
Consideramos que, existiendo tecnologías muy confiables y populares, cambiar de lenguaje no es una opción viable. COBOL
puede integrarse con las nuevas tecnologías a través de interfaces modernas con las cuales la lógica de negocio permanece en
COBOL y los impedimentos se transforman en soluciones.
Ya has invertido muchísimo tiempo y dinero en tu sistema. Tu lógica de negocio y tus reglas funcionales ya existen, las has
mantenido durante años. Cambiar de lenguaje significa no solamente una fuerte inversión en el nuevo desarrollo, sino también
una prueba de sistema exhaustiva y completa. Por lo tanto, muchas horas de trabajo. En su mayoría Los grandes consumidores
de MIPS (Millones de Instrucciones por Segundo) han desistido en el cambio de COBOL por otro lenguaje.
Si deseas cambiar de PowerCOBOL a otra plataforma más moderna, de manera automática o asistida, sin dependencias nuevas
de terceros, considera utilizar PCOB2NET. Tu sistema permanecerá en COBOL sin obsolescencia.
Una vez tu sistema esté en NET, podrás seguir con COBOL, cambiar a otro lenguaje de NET, simultanear ambas cosas, etc. Tu
decidirás que hacer según tus propias prioridades o posibilidades. Incluso podrías abandonar COBOL si lo deseas. Te
recomendamos que lo hagas si lo deseas pero te damos la opción de no correr riesgos y de hacerlo poco a poco, a tu ritmo y
sin presiones. PCOB2NET permite esto.
¿ Qué es PCOB2NET ?
pcob2net
PCOB2NET es una aplicación Windows para desarrolladores PowerCOBOL que permite clonar proyectos PPJ en
un entorno NET sin cambiar de compilador.
La herramienta puede leer internamente los PPJ, extraer toda la información de FORM, Controles, etc. y crear
una solución de Microsoft Visual Studio con un clon perfecto de cada uno de los FORM de PowerCOBOL.
Utiliza la tecnología WINFORM. Es decir, aplicación para escritorio de NET. Tal y como lo es PowerCOBOL.
Cada WINFORM estará pilotado por un CODE-BEHIND generado en C#. Tiene que ser C# para no tener que
invertir miles de dólares en el compilador de COBOL para .NET. PCOB2NET crea otro CODE-BEHIND como
OO-COBOL que compila con tu propio compilador. Los dos CODE-BEHIND pueden entonces comunicarse.
C# solo gestiona errores globales que puedan ocurrir en el WINFORM y únicamente contiene el código
necesario para interceptar y responder a los eventos de los controles del WINFORM que se han clonado a
partir de los controles PowerCOBOL. Para tratar y responder a los eventos, llama al CODE-BEHIND generado
en OO-COBOL.
PCOB2NET se presenta como una aplicación que tiene tres grandes fases. Se puede acceder a cada fase cambiando de pestaña.
Vamos a ir viendo cada etapa en esta página.
pcob2net
El flujo de trabajo que se sigue es obviamente por proyecto PowerCOBOL. Si tu aplicación se compone de
varios PowerCOBOL, tendrás que irlos convirtiendo todos. No tienes por qué hacer todos los FORM de un
mismo PowerCOBOL de golpe. Si algún FORM de un PPJ llama a otro FORM de otro PPJ diferente, puedes
hacer estos dos FORM y probarlos sin haber completado el resto.
Por lo tanto, la unidad de trabajo es el FORM de PowerCOBOL. PCOB2NET trabaja FORM a FORM y el flujo de
trabajo a nivel de cada FORM no es el mismo según el FORM sea de tipo MAIN o no lo sea. Un FORM de tipo
MAIN tiene un icono rojo en PowerCOBOL.
Cada conversión de FORM va a generar un proyecto de Visual Studio con tecnología WINFORM. Cada
WINFORM generado será o bien un EXE de .NET (aplicación para escritorio), o bien una DLL de .NET (aunque el
FORM sea parte de un mismo EXE en PowerCOBOL).
El PRIMING consiste en modificar el evento OPENED de cada FORM. Si algún FORM no tiene evento, debemos de crearlo.
Debemos de insertar unas líneas de código COBOL en la WORKING-STORAGE SECTION (WSS) y también una línea en la
PROCEDURE DIVISION.
La modificación es necesaria para que en cuanto el FORM cargue en tiempo de ejecución, se llame a una DLL suministrada con
PCOB2NET, que se encargará de explorar el FORM a partir de una referencia COM que se le pasa desde el propio SCRIPTLET
de PowerCOBOL.
Working-Storage
La imagen muestra el código que debe de ser insertado en el evento OPENED de cada FORM en PowerCOBOL.
Se añaden unas variables con el nombre del proyecto PowerCOBOL, Nombre del Módulo y Nombre del FORM en WSS.
Igualmente, añade unos objetos o referencias a COM. Estas apuntarán al propio FORM en ejecución.
En la PROCEDURE se añade un INCLUDE a un trozo de código COBOL suministrado. El código llamará a una DLL del producto
llamada XPCForm. Es la DLL que se encarga de extraer la información del FORM que recibe como referencia, y de escribir un
archivo XML en el directorio de ejecución.
Contenido de XML
El archivo XML tendrá el mismo nombre que el FORM en tu sistema. Contiene todos los datos relevantes del FORM y de todos
los controles que contiene. Este es el fichero que sirve para generar el clon de la parte gráfica en Visual Studio.
#INCLUDE en la PROCEDURE
include
Código interno del INCLUDE añadido a la PROCEDURE del FORM en su evento OPENED.
Acceso a FORM
Se crea una referencia al FORM actual. Se crea la referencia a la colección de controles presentes en el FORM.
Al pasar por este código en tiempo de ejecución, XPCForm escruta los SCRIPTLET internos de PowerCOBOL y crea un archivo
XML en el directorio de ejecución.
El PRIMING no termina aquí. Después de estas modificaciones debemos de compilar todo lo que hayamos modificado y
ejecutar la aplicación.
Debes ejecutar
No se trata de probar todo. Se trata de hacer que el flujo de ejecución pase por todos los eventos OPENED que hemos
modificado.
Algunas veces, creamos FORMS para casos de error. No debemos de olvidarnos de ellos en el PRIMING. Tanto en modificación
como en ejecución. Quizás debamos de esforzarnos un poco para crear las circunstancias de cada error y obligar a que estos
FORM se ejecuten o carguen durante la prueba para PRIMING.
Si tu aplicación PowerCOBOL tiene unos pocos FORM, no tendrás muchas dificultades para realizar el PRIMING de todos ellos.
Imagina que la aplicación tienes 5000 o más FORM de PowerCOBOL. La fase de PRIMING en estos casos ya puede ser costosa
en tiempo de desarrollo. Podemos ver claramente que la modificación de 5000 FORM puede conllevar muchas horas de trabajo.
Además, este tipo de procesos de modificaciones masivas son muy dados a errores de copiar y pegar. Podemos darnos cuenta
en compilación, o no. Si un FORM no está bien modificado, puede compilar bien, pero puede no funcionar o peor, no generar la
información correcta para la futura clonación, o incluso, falsear la información de otro FORM que está correctamente
modificado. Es muy importante prestar atención.
Por eso, hemos creado PC2NAP cuyo nombre viene de PCOB2NET AUTO PRIMING TOOL. Una herramienta donde seleccionas
el proyecto PowerCOBOL con el que trabajar. PC2NAP te da la opción de seleccionar qué FORM o FORMS quieres modificar
para el PRIMING. Seleccionas los FORM que quieres y listo. La utilidad modifica masivamente tu PowerCOBOL para todos estos
FORM. De esta manera, te aseguras que el PRIMING es correcto y solo queda compilar y ejecutar, pasando por todos los
OPENED.
PCOB2NET no tiene requerimientos especiales para lo que puede ser una máquina moderna:
¿ PowerCOBOL inaccesible ?
Si tu máquina no tiene acceso a la compilación de PowerCOBOL o NetCOBOL para Windows, PCOB2NET podría generar los
componentes para ti pero perderías la practicidad de la herramienta. Desde PCOB2NET puedes utilizar todo lo necesario como
tu compilador, Visual Studio, etc.
Vamos a ver los detalles de configuración de PCOB2NET. En esta primera pestaña, vamos a definir las carpetas de trabajo para
cada tipo de componente y también, cómo acceder al compilador.
config
Generales
WORK DIRECTORY: Se recomienda dejar su valor por defecto que es una carpeta temporal dentro del directorio de
instalación
GET PPJ PROJECT: Podemos seleccionar la ruta y el proyecto PowerCOBOL con el que vamos a trabajar
VS PROJECT PATH: Será la carpeta donde queremos que PCOB2NET genera los proyectos Visual Studio para cada FORM
VS EXECUTABLE PATH: PCOB2NET detectará automáticamente la versión de Visual Studio de tu PC.
Es posible que PCOB2NET no pueda localizar exactamente tu Visual Studio en algunos casos. Según hayas respetado o no el
directorio por defecto, la versión que tengas instalada, etc. Si, por alguna razón, PCOB2NET no detecta tu instalación de Visual
Studio, puedes pulsar el botón y navegar por tu máquina hasta la carpeta donde se encuentre DEVENV.EXE, que es el
ejecutable que lanza el IDE de Microsoft.
Componentes
CODE-BEHIND SRC: Será la carpeta donde deseas que PCOB2NET genere el fuente COBOL del código que manejará el
WINFORM resultante de la migración del FORM de PowerCOBOL a Visual Studio. Luego vemos un esquema de la
generación de componentes
CODE-BEHIND DLLs: Debes de elegir aquí el directorio donde desea que PCOB2NET genere las DLL de los fuentes
generado en el paso anterior
BROWSE FOR COBOL: PCOB2NET detecta la instalación local de NetCOBOL para Windows. Si, por alguna razón, no lo
detecta, puedes navegar por tu máquina hasta seleccionar la carpeta raíz de la instalación de NetCOBOL
Algunos usuarios instalan NetCOBOL para Windows con PowerCOBOL en una máquina de su red interna. Con las utilidades de
SCRIPTING y recursos compartidos, hacen que sea posible lanzar compilaciones PowerCOBOL en esta máquina desde cualquier
otro equipo de la red. No es muy habitual, no obstante, esto es posible. Por ello, PCOB2NET ofrece esta posibilidad.
Puedes seleccionar la ejecución de COBOL local o remota. En caso de elegir la ejecución remota, el nombre de la máquina
remota aparecerá como COBOL SERVER en la pantalla. En caso contrario, aparecerá el nombre de tu propia máquina.
Guardado de configuraciones
En cualquier momento, puedes guardar la configuración que tengas en pantalla pulsando sobre el botón SAVE SETTINGS. Esto
guardará la configuración actual en el archivo de configuración genérico de PCOB2NET. De este modo, la próxima vez que
abras la herramienta, PCOB2NET cargará esta configuración.
Desde el Menú general, puedes guardar la configuración actual en la carpeta de tu elección. Esto es práctico para manejar
varias migraciones para diferentes archivos PowerCOBOL y trabajar simultáneamente con ellos en diferentes carpetas.
Menú PCOB2NET
con el menu de PCOB2NET puedes hacer todo lo que necesites para tu migración. Tienes la posibilidad, como hemos
comentado, de guardar y manejar las configuraciones. Igualmente, puedes abrir el proyecto Visual Studio con el que estés
trabajando en un momento dado, etc. Es bastante intuitivo y no lo comentaremos aquí en detalle.
PCOB2NET – Generación de componentes
PCOB2NET genera automáticamente los componentes de software para la migración de cada uno de tus FORM de un proyecto
PowerCOBOL determinado. Para manejar esta pantalla, un proyecto de PowerCOBOL debe de ser detectado. Su referencia
vendrá o bien de la pestaña de configuración, o bien PCOB2NET obligará a abrir un proyecto PPJ desde esta misma pantalla.
genración código
La generación de los componentes de migración depende siempre del tipo de FORM de PowerCOBOL que
estas utilizando.
PowerCOBOL FORM
En PowerCOBOL, dentro de un mismo proyecto, se puede seleccionar cual será el formulario o FORM principal.
El MAIN FORM será el que se cargue primero al ejecutar el proyecto. Esto, lógicamente solo aplica a proyectos
de tipo EXE.
Como se puede ver en la imagen, Cada FORM de PowerCOBOL se convertira en una solución de Visual Studio (.SLN). A
su vez, según sea el FORM de tipo MAIN o de tipo SUB, La solución de Visual Studio será un EXE de .NET, o bien, Una
DLL de .NET.
FORM a WINFORM
El antiguo FORM de PowerCOBOL será ahora un WINFORM de .NET, y como todo WINFORM de .NET, tiene que tener un
CODE-BEHIND o código que maneja el formulario, que captura los eventos, etc. Pues el CODE-BEHIND del puro WINFORM,
PCOB2NET lo genera en C#. Tiene que ser código compilable en .NET.
Para aquellos que estén algo confundidos ahora, si quisiéramos tener COBOL dentro de este CODE-BEHIND, como tiene que
ser compilado en NET, nuestro compilador debería de ser para COBOL si, pero para COBOL en .NET. Como no queremos que
nuestro usuarios tengan que adquirir NetCOBOL para .NET e invertir miles de dólares más, generamos este CODE-BEHIND en
C#, gratuito, .NET, de Microsoft y para Windows.
¿Y qué es del código COBOL de nuestros SCRIPTLETS de PowerCOBOL? Pués PCOB2NET construye un Objeto de tipo COM,
que es una DLL de Windows normal y corriente. Una de estas que debes de registrar en Windows con REGSVR32. Todos
sabemos de qué trata esto.
Se construye de forma que el CODE-BEHIND de C# que gestiona el WINFORM, puede comunicarse via COM, con el CODE-
BEHIND generado en COBOL. Deberíamos de decir que se trata de OO-COBOL. El código no comienza por PROGRAM-ID. En
este caso, se trata de un objeto y comienza con CLASS-ID.
Nomenclatura
EL hecho de que, en nuestra jerga interna, llamemos a la parte COBOL del CODE-BEHIND (igual que a la parte C#), puede
prestar a confusión quizás al principio. El nombre del CODE-BEHIND en OO-COBOL será el nombre del FORM del que procede
con el sufijo CB y la extensión COB.
Conclusión
Este es el modo, en que PCOB2NET genera los componentes. Todo es automático, directo y limpio. COM no es nada nuevo.
Muchísimas cosas en el propio sistema operativo Windows, dependen y están basadas en la tecnología COM. PowerCOBOL
mismo, utiliza mucho COM internamente. De hecho, en la documentación de NetCOBOL para Windows, existe un manual
entero dedicado a la utilización de componentes COM en NetCOBOL.
De vuelta a la propia pantalla de generación de componentes de PCOB2NET. Verás que en esencia tenemos dos partes.
Izquierda y derecha. Lo primero que debemos de tener claro es con qué proyecto PowerCOBOL deseamos trabajar. La manera
de cambiar de proyecto PPJ y/o de FORM dentro de un mismo proyecto, es pulsar sobre el botón SELECT PPJ PROJECT.
A continuación, si hemos pulsado sobre el botón, se abrirá un diálogo para darnos la opción de seleccionar el FORM que
deseamos convertir a .NET. Después, debemos de confirmar o cambiar el tipo de FORM del que se trata. Seleccionaremos
STAND ALONE EXE (MAIN FORM). o bien COM DLL (SUB FORM), según sea nuestro FORM de PowerCOBOL de tipo MAIN o
SUB.
Generar el WINFORM
Seleccionado y confirmado el flujo de trabajo para nuestro FORM, aparecerá en la pantalla el nombre del FORM y podremos
pulsar el botón GENERATE WINDOWS FORM. Estamos en la parte izquierda de la pantalla.
Este proceso generará una Solución de Visual Studio en la carpeta que hayamos configurado en la primera pestaña. La
solución va a contener un WINFORM de NET y un CODE-BEHIND para el WINFORM escrito en C#. Cuando termine el proceso,
PCOB2NET nos preguntará si queremos abrir Visual Studio para trabajar con el proyecto. No se recomienda hacerlo. El CODE-
BEHIND del formulario aún no está «CABLEADO» o conectado con ningún CODE-BEHIND OO-COBOL. Si se abre el proyecto
Visual Studio en este momento y se modifica, el siguiente proceso podría no realizarse correctamente.
El nombre de nuestro proyecto Visual Studio será el mismo que el nombre de FORM de nuestro PowerCOBOL.
Ahora tenemos que generar la parte COBOL de nuestra conversión de FORM de PowerCOBOL a WINDOWS FORM. Para
hacerlo solo tendremos que pulsar sobre el botón GENERATE FUJITSU COBOL CODE-BEHIND. Nos encontramos en la parte
derecha de la pantalla.
Explorando PowerCOBOL
El proceso leerá el interior de todos los SCRIPTLETS asociados a cualquier control de PowerCOBOL dentro del FORM actual.
También creará un fuente OO-COBOL, una CLASE escrita en COBOL o un OBJETO. Cada SCRIPLET será un MÉTODO de esta
clase. Cada método será conectado con el CODE-BEHIND escrito en C# que se encuentra en su proyecto Visual Studio.
WIRING entre Visual Studio y OO-COBOL
Algunas veces podemos desear que se realice de nuevo el proceso de conexión entre C# y OO-COBOL. Disponemos de esta
opción seleccionando el proceso WIRING ONLY.
Magia de PCOB2NET
La magia ocurre en tiempo de ejecución, cuando operamos con el WINFORM. Por ejemplo, si el usuario hace clic en algún
control de tipo BOTON, el evento es capturado por el código C# digamos así. Este código C# llama entonces al CODE-BEHIND
OO-COBOL, y concretamente al método BOTON_CLICK que ha sido convertido por POCB2NET y replicado con su adaptación
dentro de nuestra clase (Método BOTON_CLICK). La ejecución pasa entonces al RUNTIME de NetCOBOL, se ejecuta el método
correspondiente, y al final del evento, se retorna al flujo de control de C#.
Soporte GUI
Esta magia es posible gracias a un componente interno de PCOB2NET llamado GUI SUPPORT que garantiza el soporte entre
las propiedades de los controles WINFORM y su nuevo tratamiento en la parte OO-COBOL. Esta DLL, digamos que adapta la
jerga de PowerCOBOL a .NET y OO-COBOL.
flow
NO conozco C#
Es normal que si nunca te has acercado a .NET en entornos Windows, no estés familiarizado con C#. Es el lenguaje de
programación más «natural» del ambiente .NET en Windows. Se pueden utilizar otros. Incluso COBOL puede ser un lenguaje de
.NET (solo con NetCOBOL para .NET).
No te preocupes, el código presente en el CODE-BEHIND de C#,, es únicamente para el control de errores, para poder entrar en
modo DEBUG, e igualmente para captar los eventos de los controles. Lógicamente también encontraremos el código que lanza
el método correspondiente de la parte OO-COBOL, a nivel de cada control.
No es difícil
Es un código muy repetitivo que solo se encarga de manejar el WINFORM a nivel global y a nivel de realizar una llama a OO-
COBOL para cada evento. Una vez hayas seguido una ejecución para uno de los eventos de cualquier WINFORM, tendrás claro
como sucede toda esta magia.
La inmensa mayoría de controles de PowerCOBOL nativos están soportados en PCOB2NET. A continuación te mostramos una
tabla con el resumen de cada control y su grado de soporte dentro de nuestra herramienta.
PowerCOBOL
WinForms Support
control Comment
control type/object level %
type/object
COBOL COPY pre-processed by the tool 100% #INCLUDE is passed through to NetCOBOL.
Command
Button 100%
Button
Embedded SQL passed through 100% The PowerCOBOL database and ADO
(ESQL) controls are currently not implemented and
PowerCOBOL
WinForms Support
control Comment
control type/object level %
type/object
EXTERNAL Shared objects 100% Fields are shared automatically across Forms
List Box ListBox 70% icons are not supported (see DGV, above)
Radio/Option
RadioButton 100%
button
SQL Host Embedded SQL 100% EXTERNAL HVs are shared across Forms if
PowerCOBOL
WinForms Support
control Comment
control type/object level %
type/object
Variables required.
Tool Bar ToolStrip 70% May require further CUSTOM* GUI Support.
* Los Items anotados con «CUSTOM*» PUEDEN ser añadidos fácilmente y trabajaríamos contigo para conseguirlo.
Cualquier otra cosa no presente en la lista podría tardar más pero no conocemos «nada que no pueda realizarse o sea
incompatible con la tecnología».
activex
Si utilizas algún componente de tipo ActiveX u OCX de terceros dentro de tu aplicación PowerCOBOL,
lógicamente no estará soportado dentro de POB2NET. No obstante, siempre podemos modificar la
herramienta para tu caso e incorporar soporte para tu componente. Esto tendría un coste que tendríamos que
valorar conjuntamente.
ActiveX / OCX – No soportados
Estos componentes están en desuso. Cada día se utilizan menos y a menudo, muchos productos ni siquiera los
permiten, por su inseguridad potencial (Internet Explorer y otros…).
No olvides que una vez tengas tu PowerCOBOL convertido a .NET, tendrás a tu disposición todos los controles
de Visual Studio para WINFORM. Además, existen en internet, una cantidad ingente de funcionalidades escritas
en diferentes lenguajes que podrás aprovechar en tu proyecto. Quizás, la funcionalidad de tu componente
externo ya exista en el mundo de WINFORM.
Ejemplo: PowerCOBOL tiene un control para llevar datos a Microsoft Excel. No vale la pena utilizar este control en PCOB2NET.
Las exportaciones de datos a Excel pueden hacerse dentro de .NET, una vez trasformado el proyecto PowerCOBOL. Los procesos
serán mucho más rápidos y más directos de programar. En general, lo mejor sería quitar o ignorar la funcionalidad de
PowerCOBOL y programarla directamente en Visual Studio con C#, o con C# y OO-COBOL.
Podemos ayudarte
Si tu ActiveX u OCX resulta imprescindible para ti, consúltanos, y estudiaremos la conversión de tu funcionalidad,
estudiando tanto tu PowerCOBOL como tu control. El presupuesto será gratuito o de pago, según sea la complejidad del
mismo. En cualquier caso, el estudio preliminar será sin coste alguno para ti, y te recomendaremos la mejor solución.
Existen OCX bastante complejos cuyo estudio podría llevarnos muchas horas. Si lo necesitas, podemos estudiar su viabilidad,
pero tendría un coste.
Finalmente, tras generar los componentes, deberemos de compilarlos. Para ello, podemos ir a la tercera y última pestaña de
PCOB2NET, donde podremos realizar, tanto la compilación, como el registro de los CODE-BEHIND de tipo OO-COBOL.
Recordamos que la parte COBOL de los SCRIPTLETS de PowerCOBOL es ahora una clase OO-COBOL que contiene todos
los SCRIPTLETS de PowerCOBOL a nivel de un mismo FORM. Cada SCRIPTLET es ahora un método de la clase.
Atención
En el área de trabajo aparecerán todos CODE-BEHIND de tipo OO-COBOL que hemos obtenido en el paso anterior con
PCOB2NET. La funcionalidad de esta pantalla es muy amplia. Permite realizar todo lo que necesitas a nivel de compilación,
revisión de errores, edición de fuente generado, edición manual definitiva, registro en Windows y visualización de LOG de
registro.
RUN COBOL: Podremos ejecutar nuestro compilador COBOL localmente o remotamente, según sea nuestra instalación de
NetCOBOL para Windows
Modificar el aspecto del área de trabajo para visualizar la ruta completa de los archivos o no
Marcar el registro automático en Windows de las DLL que compilen correctamente
Decidir si queremos compilar nuestros CODE-BEHIND en modo RELEASE o para DEBUG
Decidir si queremos visualizar solo los diagnósticos o todo el fuente en la revisión de la compilación
PCOB2NET informará de algunas estadísticas bajo el área de trabajo al realizar cualquier proceso.
Compilar OO-COBOL
Para compilar un CODE-BEHIND de tipo OO-COBOL, primero lo seleccionamos el tipo de proceso pulsando sobre el botón
COBOL o bien REGISTER COM, en el área de trabajo. Según sea el proceso, aparecerán los nombres de los fuentes para
compilar si hemos pulsado COBOL. O bien, los nombres de las DLL compiladas si hemos pulsado REGISTER COM.
A continuación pulsaremos el botón OK PROCESS THE SELECTED CODE-BEHINDS, y el proceso se lanzará. Nota que puedes
manejar múltiples componentes de golpe.
El proceso de compilación es asíncrono. Cada X segundos el control es devuelto a la pantalla para que determine si la
compilación a terminado. Si no ha terminado, preguntará si deseas prolongar el proceso otros X segundos más. Dependiendo
del número de componentes que has seleccionado, el tiempo trascurrido puede ser normal, o no. Si PCOB2NET detecta que
todo ha finalizado, tendrás de nuevo el control en la pantalla.
Opciones
Para lidiar con los errores de compilación o registro, tienes botones en la parte baja de la pantalla para:
Para que C#, que está gestionando nuestro nuevo WINFORM, pueda llamar a nuestra parte COBOL, debemos de registrar la DLL
generada como COM en OO-COBOL. Es decir que, debemos de registrar en Windows nuestra DLL de tipo OO-COBOL. Si no
realizamos el registro, el proyecto Visual Studio no funcionará.
El registro en Windows se realiza con la utilidad del sistema operativo llamada REGSVR32.EXE. Como ya sabes, pueden existir
dos lugares donde encontrar la utilidad. Esta estará en tu directorio de Windows y sub-directorio SYSTEM32, o bien en el sub-
directorio SYSWOW64. La existencia de este último sub-directorio y la elección del mismo, dependerá de si tu sistema
operativo es de 32 bits o 64 bits.
Microsoft REGSVR32
No explicaremos aquí la diferencia. Consulta la documentación de la utilidad en la web de Microsoft. Lo que si es importante
saber es que PowerCOBOL es un producto de 32 bits y que el CODE-BEHIND de tipo OO-COBOL o COM ha sido compilado por
NetCOBOL para Windows 32 bits, que es tu compilador actual. Por lo tanto vas a tener que registrar una DLL de tipo COM de 32
bits.
Registro automático
La herramienta PCOB2NET puede realizar este paso para ti automáticamente. No obstante, si deseas saber hacer estas cosas
manualmente, debes de tener todo esto en cuenta.
importante
En OO-COBOL, hay cosas que deben de ser cambiadas con respecto al COBOL o PowerCOBOL tradicional. Por
ejemplo, en casos de propiedades de clase los caracteres guion o ‘-‘ no pueden utilizarse. Puedes consultar
esto en el manual dedicado a COM en tu documentación NetCOBOL. Así mismo, los RECORDS o agrupaciones
COBOL con diferentes niveles de datos, no pueden ser utilizadas cuando van a ser parámetros de alguna clase.
PCOB2NET puede tener que cambiar algunos COPY. No re-escribe los tuyos. Genera otros nuevos cambiando
el nombre, en el mismo directorio que el original. Esto es totalmente transparente al usuario. No obstante,
algunos caracteres dejados por el editor original de PowerCOBOL, pueden molestar al generador de código, y
este puede generar COPY erróneo. (Tabulaciones etc…).
Limpieza de COPY
Revisa los COPY y quita los caracteres extraños de los mismos. Este es un consejo que damos siempre
para todas nuestras herramientas.
Cuando realizamos un proyecto de conversión, sea del tipo que sea, tarde o temprano, aparece la necesidad de modificar la
aplicación origen, debido al mantenimiento diario de la instalación o a nuevos requerimientos.
Planificación
Para iniciar el proyecto PCOB2NET, recomendamos que los equipos de Mantenimiento y de Conversión se reúnan y definan
una serie de estándares. Quizás, el mantenimiento de la aplicación deba de hacerse sin más y con toda urgencia. No obstante,
el equipo de conversión debe de conocer todos los componentes que han sido impactados por el cambio.
Si la conversión suele ser directa, tendrías que volver a generar el CODE-BEHIND de tipo OO-COBOL. Entendemos que directa
significa que, cuando conviertes, no tienes que editar el fuente generado y conservar los cambios manualmente. Si siempre
tienes que hacer cambios en el fuente generado, será más complejo. Si el cambio impacta algún FORM de PowerCOBOL,
deberás de generar de nuevo el proyecto Visual Studio y también la parte OO-COBOL.
Los cambios que afecten a los componente de tipo COPY podrían derivar en la recompilación de algunos OO-COBOL de la
parte PCOB2NET y también, el cambio de otros OO-COBOL por regeneración necesaria. Eventualmente, algún proyecto de
Visual Studio tendrá que ser cambiado o regenerado. Cuantas más pruebas realices y mejor entiendas los flujos de trabajo, el
funcionamiento de la configuración de carpetas, etc. mejor construirás los proyectos de conversión.
Después de haber convertido los proyectos PowerCOBOL a NET con PCOB2NET, tendrás que preparar tu entorno de desarrollo
continuo. Nos referimos al flujo de trabajo diario que deberás de preparar para cambios constantes e instalaciones en tus
clientes por cambios realizados.
Deberás de tener en cuenta algunos aspectos o detalles de la conversión de los cuales no hemos comentado por ahora nada, o
de los cuales no seas totalmente consciente, por no estar familiarizado con el desarrollo en .NET.
PCOB2NET ha generado unos proyectos Visual Studio para ti. Todos ellos están en la carpeta que has configurado desde el
principio. Algunos de ellos son los que derivan de los FORM de tipo MAIN en PowerCOBOL. Es decir, que son los ejecutables o
EXE. Otros son proyectos de tipo SUB-FORM en PowerCOBOL y son ahora todos DLL en .NET.
En el flujo de la conversión, PCOB2NET te da a elegir entre el flujo EXE y el flujo DLL. Al convertir un FORM de tipo SUB,
PCOB2NET te guía para que no olvides copiar la DLL que ha generado, a la carpeta donde apunta la variable de entorno de
sistema que te ha sugerido crear la primera vez.
Por lo tanto, aunque tengas todos los Visual Studio en una carpeta, los que sean de tipo DLL, no son ejecutados dentro de las
carpetas Visual Studio. El resultado de compilación de estos proyectos Visual Studio, es decir sus DLL, son copiadas a otra
carpeta. En tiempo de ejecución, cada DLL se va a buscar a esta última carpeta.
Quizás esta no es la manera en que quieres gestionar tus soluciones en Visual Studio. Es posible que decidas construir una
solución única y global para toda tu aplicación. Por lo tanto, en tu solución de Visual Studio final, tendrías de uno a N proyectos
de ejecutables, quizás cada proyecto compile en una carpeta distinta a la que había por defecto, y tendrías X proyectos de tipo
DLL. Teniendo, de esta manera, algo más voluminoso en un solo sitio, en lugar de una colección de pequeños proyectos.
Tu puedes decidir como montar tu proyecto definitivo. En este sentido, debes de saber, que si algún FORM tiene imágenes para
botones o para algún control, estas imágenes también será trasladadas al entorno PCOB2NET. En este caso a algún proyecto
Visual Studio. Debes de saber que, cuando PCOB2NET encuentra imágenes, crea una carpeta de imágenes en el proyecto de
Visual Studio correspondiente al FORM que estas trabajando. Dentro, guardará todas las imágenes que sean necesarias para
este FORM.
Con el tiempo, podrías encontrar imágenes repetidas a través de los distintos proyectos de Visual Studio. Quizás, lo mejor
podría ser, crear a priori una carpeta de imágenes para la conversión. Dentro, copiarías todas las imágenes de tu aplicación
(también iconos etc.). Por este motivo, PCOB2NET no asigna las imágenes que detecta y traslada al proyecto Visual Studio. Los
controles del FORM se dejan sin imágenes. PCOB2NET deja esto pendiente ya que a posteriori, cada cual quiere montar las
cosas a su manera.
Aspectos visuales
Si no estas familiarizado con este mundo, te sugiero que vayas haciendo pruebas tal y como PCOB2NET trabaja. Puedes hacer
las cosmética de tus WINFORM dentro de cada proyecto, tomando las imágenes de la propia carpeta local, o de la carpeta de
imágenes del proyecto de nivel EXE de lo que estás convirtiendo. La decisión es tuya. Pronto haremos algún documento o vídeo
sobre este tema.
Por configuración, decides las carpetas que PCOB2NET utilizará para generar el fuente COBOL de los CODE-BEHIND, y para las
DLL resultado de compilar estos componentes. En realidad, PCOB2NET genera el código fuente COBOL en la carpeta
correspondiente, monta un proyecto de NetCOBOL Project Manager dentro del directorio CWD configurado, compila en CWD y
copia todo lo relacionado con la compilación en la carpeta correspondiente, incluida la DLL.
Realmente PCOB2NET compila lanzado en BATCH el compilador del Project Manager de tu NetCOBOL. Pero no construye el
proyecto como tal. Es decir que no vas a encontrar ninguna carpeta ni proyecto de tipo PRJ en tus resultados de generación.
Debes de dominar todo esto.
Consejo práctico
El consejo es que cuando pienses en el montaje de tus proyectos definitivos, pienses también en construir los proyecto PRJ con
tu Project Manager, dentro de la carpeta que desees. Tendrás el fuente ya generado. Solo tendrás que configurar el proyecto
para compilarlo como COM SERVER. Tienes documentación en tu manual de NetCOBOL sobre COM. Esto te permitirá
posteriormente modificar cualquier CODE-BEHIND de tipo OO-COBOL y compilarlo etc. sin estar en relación con el tema
PCOB2NET. Tienes que ver a PCOB2NET como una herramienta de usar y desechar. Al menos mentalmente.
No olvidar REGSVR32
Deberás de saber gestionar tus proyectos Visual Studio y tus CODE-BEHIND de tipo OO-COBOL manualmente. De la misma
manera, deberás de saber registrar los COM a mano o desde la consola de comandos.
Cuando se termina un proyecto de conversión, debemos de tener clara la manera en que después se va a mantener la
aplicación. De hecho ya hemos comentado algo de este tema en esta página. Suponemos que tus soluciones finales de Visual
Studio están formadas y que tus PRJ de OO-COBOL están disponibles y registrados en Windows.
Igualmente, habrás realizado algunos SCRIPTS para instalar tu aplicación en tus clientes copiando los ejecutables, registrando
los COM etc. Esto es algo que debes de ir realizando mientras conviertes. Te recomiendo que, una vez estes familiarizado con la
generación de componentes, intentes pensar en la construcción de tus ambientes de desarrollo, pruebas y producción. Es algo
que debe de ser muy dinámico, rápido y fácil de hacer. Por supuesto, documenta, tanto el proceso de conversión, como el de
construcción de ambientes y también, el proceso de paso a producción.
Para lo que sigue, asumimos que ya tenemos todo convertido a .NET y que nuestra aplicación definitiva ya ha sido instalada en
producción en todos nuestros clientes, o en nuestros servidores etc.
Modificaciones en PowerCOBOL
Si nos surge la necesidad de cambiar algo en nuestro sistema después de haberlo convertido, Podemos hacer dos cosas que
vamos a ver ahora. Pero antes, debemos de pensar que hemos convertido la aplicación desde PowerCOBOL a NET para
abandonar PowerCOBOL. Cuanto antes lo tengas asumido mejor.
No hay pánico
Si ya estás familiarizado con la POO o Programación Orientada a Objetos y con algún lenguaje POO como C#, PYTHON,
JAVA, etc. te será más fácil. En cambio, si no lo estás, no te preocupes, ya tienes muchas cosas en las cuales te puedes inspirar
para hacer cosas nuevas. Si sabías hacerlo con PowerCOBOL, lo sabrás hacer con C# y OO-COBOL.
Ya sabes qué controles de Visual Studio con WINFORM se utilizan en cada caso, en lugar o como sustitución de los controles de
PowerCOBOL.
Copiar y Pegar
Simplemente, puedes ir a la superficie de diseño de tus WINFORM en Visual Studio, arrastrar nuevos controles al formulario,
borrar los que no necesites etc. Tendrás que «CABLEAR» tus controles con tu parte OO-COBOL. Quizás esto es lo que más te
puede despistar al principio. Piensa que tendrás muchos ejemplos dentro del código que ya está funcionando para copiarlo,
cambiar el nombre de control, y modificar adecuadamente. Es así de simple.
Después edita tu OO-COBOL con el editor que prefieras. Si utilizas NetCOBOL Project Manager, puedes utilizar el editor de
PowerGEM, que es el editor por defecto de NetCOBOL. También puedes cambiar y utilizar algún otro que tenga algún tipo de
ayuda específica para COBOL. Realizas los cambios en tu OO-COBOL. Tienes un archivo de código fuente COBOL independiente
que puedes editar con lo que prefieras.
Quizás tengas que crear algún método nuevo. Copia alguno que ya esté funcionando con un control equivalente al que hayas
añadido. Lo modificas con la nueva lógica y listo. Piensa que si tenías variables GLOBAL / EXTERNAL, etc. todo está
implementado en tu OO-COBOL. Solo tienes que comprender bien como funciona el flujo del código nuevo y replicar lo que
necesites para los nuevos controles, para la lógica etc.
En el futuro, después de convertir toda la aplicación, tendrás, como has visto la opción de seguir con COBOL a través del enlace
mágico entre C# de NET y OO-COBOL.
No obstante, también tendrías la opción de ir haciendo las cosas nuevas directamente en C#. Podrías aprovechar los cambios
para ir pasando de COBOL a C#, y al final, a tu ritmo, abandonar totalmente COBOL.
Esto está quizás muy lejos para ti ahora. No dudes en dar el primer paso abandonando PowerCOBOL. El resto llegará con el
tiempo. Por lo menos tu aplicación tendrá de nuevo un sitio en las nuevas tecnologías y nunca se quedará obsoleta. No tendrás
que decirle nunca más a un cliente que lo que pide no se puede realizar o no es compatible.
PCOB2NET
PowerCOBOL a NET
Ver el vídeo
PC2NAP
MIGTSET
Ver el vídeo
PowerCOBOL a NET
Envíanos tu aplicación PowerCOBOL y te devolvemos tu mismo sistema funcionando en NET con detalladas
instrucciones para que lo instales y lo pruebes.
Haznos llegar tus ficheros indexados COBOL y te devolvemos una base de datos normalizada que contendrá
todos las tablas y datos para SQL Server.
Prepara y envía tu aplicación PowerCOBOL y te devolvemos tu mismo sistema migrado y funcionando en NET y
manejando una base de datos SQL Server.
Términos y Condiciones
Política de Privacidad
Política de Cookies
Copyright © 2023 malsoftware.com