CALL a programas externos en Windows 8

[Gusaiello]

Hola a todos. Necesito de vuestra ayuda.

Estoy usando AcuCobol GT 5.1 para Windows, y en algunos casos necesito interactuar con otros programas, para ser mas específico, con RAR.EXE (el conocido compresor), y con WSPOOLER.EXE (envia comandos a las impresoras fiscales Hasar).

La cosa es que bajo Windows XP o 7 todo funciona perfectamente, pero cuando intento ejecutar el mismo programa bajo Windows 8 no funciona.

La sentencia utilizada es CALL "C$SYSTEM" USING COMANDO, 96. (32 = oculto + 64 = usar el intérprete de comandos del sistema - cmd.exe).
donde COMANDO puede ser WSPOOLER -p3 etc. etc, o RAR.EXE etc. etc (no viene al caso indicar los parámetros de cada comando).

El tema es que cada uno de estos comandos genera respuestas, ya sea un archivo comprimido o un archivo con respuestas que luego debo analizar, pero (y aqui viene el problema) cuando esto ocurre bajo Windows 8, la ejecución no se detiene mientras el comando esta en proceso, al contrario, continúa con la sentencia siguiente, y claro, cuando quiero abrir los archivos de respuestas para ver que pasó, me encuentro con que no existen.

Probé con THREAD para invocar al comando y WAIT FOR THREAD, para obligar la detención del programa, sin éxito, con lo único que logré hacer que las cosas mas o menos funcionen es con CALL "C$SLEEP" USING TIEMPO, lo cual hace que el programa se detenga forzosamente un tiempo determinado, en lugar del tiempo estrictamente necesario.

Alguien sabe si hay alguna forma de hacer que el querido Windows 8 espere a la finalización de los programas externos antes de continuar con la ejecución de mi programa cobol?

Desde ya muchas gracias de antemano.

[Kuk]

Gusaiello, yo creo que es complicado cambiar esto. Porque, si es tema del SO, por lo pronto no será nada fácil cambiarlo y hasta dudo que sea posible... Pero aunque se pueda, no te lo aconsejaría porque puede haber otras cosas en el SO o en programas creados para dicho SO que necesiten justamente dicho comportamiento para funcionar y no el que necesitas tú.

Yo creo que es más bien el Run-Time del Acu el que no funciona igual en Windows XP, 7 y 8. Yo buscaría en las opciones del Run-Time, si es que hay algo a parametrizar en este aspecto.
No he usado nunca Acu, pero por ejemplo en Fujitsu PowerCOBOL hay 2 modos de invocar programas externos, "Execute" el cual ejecuta y continua con la siguiente sentencia, y "ExecuteSync" el cual ejecuta en modo sincronizado, lo cual quiere decir que espera el retorno del programa llamado. Mira el manual, a lo mejor hay algún comando alternativo que nunca has usado porque te funcionaba este.

Si no encuentras nada, lo único que se me ocurre es que montes un bucle llamando al "SLEEP" leyendo esos ficheros. Si se rellenan de una sola vez, en cuanto veas que hay datos dentro paras el bucle. Si se rellenan por partes, buscas una cadena, algo que suele haber al final del fichero para así saber que ha finalizado la escritura en él y puedes tratarlo.

[Gusaiello]

Gracias Kuk.

En AcuCobol existe lo mismo que en Power, hay diferentes formas de llamar a programas externos, y es a través de los parámetros que se le indican a "C$SYSTEM", justamente estoy intentando ejecutar con parámetros que hacen la ejecución sincrónica, pero no hay caso.

Por eso creo que es correcta tu apreciación de que el runtime de acu no se comporta correctamente bajo Windows 8, cosa que sí hace bajo XP.

Por suerte este martirio se termina, ya que tengo entendido que Windows 10 retorna a la interfase de usuario similar a la de Windows 7.

[Kuk]

Gusaiello, según tengo entendido, el Windows 10 comparte los 2 modos, aunque sí que trae por defecto y de base el modo escritorio.

Acabo de hurgar por internetes un poco, y lo que he leído es que en la versión 9.2.0 se resuelve dicho problema, y efectivamente se trata de un problema en el Run-Time de las versiones anteriores: Windows 8 and C$SYSTEM - Extend and AcuCOBOL - Forum - Extend and ACUCOBOL - Micro Focus Community
(http://community.microfocus.com/microfocus/cobol/extend_and_acucobol/f/20/t/9435.aspx)

[Rapinto]

Gusaiello,

Não sei se AcuCobol pode fazer CALL ao kernel do Windows.
Se puder, este código (em Fujitsu Cobol) executa o que pretendes:


@OPTIONS NOALPHA
IDENTIFICATION DIVISION.
PROGRAM-ID. EXECUTEPROGWAIT.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 STARTUPINFO.
03 CB PIC S9(009) COMP-5.
03 LPRESERVED PIC X(1024).
03 LPDESKTOP PIC X(1024).
03 LPTITLE PIC X(1024).
03 DWX PIC S9(009) COMP-5 VALUE ZERO.
03 DWY PIC S9(009) COMP-5 VALUE ZERO.
03 DWXSIZE PIC S9(009) COMP-5 VALUE ZERO.
03 DWYSIZE PIC S9(009) COMP-5 VALUE ZERO.
03 DWXCOUNTCHARS PIC S9(009) COMP-5 VALUE ZERO.
03 DWYCOUNTCHARS PIC S9(009) COMP-5 VALUE ZERO.
03 DWFILEATTRRIBUTE PIC S9(009) COMP-5 VALUE ZERO.
03 DWFLAGS PIC S9(009) COMP-5 VALUE ZERO.
03 WSHOWWINDOW PIC S9(005) COMP-5 VALUE ZERO.
03 CBRESERVED2 PIC S9(005) COMP-5 VALUE ZERO.
03 LPRESERVED2 PIC S9(009) COMP-5 VALUE ZERO.
03 HSTDINPUT PIC S9(009) COMP-5 VALUE ZERO.
03 HSTDOUTPUT PIC S9(009) COMP-5 VALUE ZERO.
03 HSTDERROR PIC S9(009) COMP-5 VALUE ZERO.
*
01 PROCESS-INFORMATION.
03 HPROCESS PIC S9(009) COMP-5 VALUE ZERO.
03 HTHREAD PIC S9(009) COMP-5 VALUE ZERO.
03 DWPROCESSID PIC S9(009) COMP-5 VALUE ZERO.
03 DWTHREADID PIC S9(009) COMP-5 VALUE ZERO.
*
01 NORMAL-PRIORITY-CLASS PIC S9(009) COMP-5 VALUE 32.
01 INFINITE PIC S9(009) COMP-5 VALUE -1.
*
01 LINHA PIC X(1024).
*
01 STRNULL PIC X(1) VALUE X"00".
01 STRZERO PIC X(001) VALUE X"00".
01 STRUM PIC X(001) VALUE "1".
01 RET PIC S9(009) COMP-5 VALUE 0.

PROCEDURE DIVISION.
MAIN SECTION.
MAIN-00.
*
MOVE "REGSVR32.EXE D:\RPS14_SRC\RELEASE\RPSKEYBOARD.DLL" TO LINHA.
MOVE X"00" TO LINHA(64:1).
MOVE 3143 TO CB.
CALL "CreateProcessA" WITH STDCALL USING
BY VALUE STRNULL
BY REFERENCE LINHA
BY VALUE STRZERO
BY VALUE STRZERO
BY VALUE STRUM
BY VALUE NORMAL-PRIORITY-CLASS
BY VALUE STRZERO
BY VALUE STRNULL
BY REFERENCE STARTUPINFO
BY REFERENCE PROCESS-INFORMATION
RETURNING RET.

CALL "WaitForSingleObject" WITH STDCALL USING
BY VALUE HPROCESS
BY VALUE INFINITE.


CALL "TerminateProcess" WITH STDCALL USING
BY VALUE HPROCESS
BY VALUE STRZERO.

CALL "CloseHandle" WITH STDCALL USING
BY VALUE HTHREAD.
CALL "CloseHandle" WITH STDCALL USING
BY VALUE HPROCESS.
MAIN-95.
MAIN-99.
EXIT.
END PROGRAM EXECUTEPROGWAIT.



Este exemplo chame o "regsvr32.exe" para registar uma DLL.

Un saludo,
Rui Pinto

[eage1969]

la solución a tu problema

CALL "C$SYSTEM"
USING CMD-LINE, FLAGS
GIVING EXIT-STATUS

CMD-LINE ingresas el comando a ejecutar.
FLAGS el código de error que envias para que entienda el Windows lo que necesitas. por ejemplo si envias a ejecutar un archivo .bat y deseas que cuando teermine el bat regrese al programa cobol mandas con el código de error CSYS-SHELL
EXIT-STATUS 0 ok / -1 comando no termina el proceso

---------- Post añadido : 14:35 ---------- Post anterior : 14:34 ----------

te envio algunnnos flag de error
FLAGS

The FLAGS field specifies various options about how the command should be run. Determine the value of the FLAGS field by adding together the values corresponding to the following options:

CSYS-ASYNC (value 1): This option causes the command to run independently of the COBOL program. After starting the command, the COBOL program continues. When this option is specified, EXIT-STATUS returns undefined results. When this flag is not used, the COBOL program waits for the command executed to finish before the COBOL program continues. CSYS-ASYNC is functional only on Windows and UNIX systems.



Note: On UNIX machines, specifying CSYS-ASYNC with a program that tries to do input or output to the terminal is not supported.


CSYS-NO-IO (value 2): For character-based systems, the runtime normally sets the terminal to its default state prior to running the command, and resets it back to the state needed by the runtime when the command finishes. This option ensures that the called application runs correctly if the application uses the screen. However, CSYS-NO-IO also causes the runtime to "forget" the contents of the screen. This happens because the command executed may display information on the screen that ACUCOBOL-GT is not aware of. Because of this, windows created after a call to C$SYSTEM may not correctly restore the screen contents when these windows are closed. You can avoid this problem by re-initializing the screen after C$SYSTEM returns. You can do this by erasing the screen or closing a floating or pop-up window that covers the entire screen (the window must have been created by the C$SYSTEM call).

If the command to be executed will not perform any screen I/O, then you can request that C$SYSTEM retain ACUCOBOL-GT's memory of the original screen by using the CSYS-NO-IO option. This will avoid the problem described above. The option has no effect in Windows, where the command runs in its own window.

CSYS-MAXIMIZED (value 4): This option causes the command to run in a maximized window. This is functional only when you are running under Windows.

CSYS-MINIMIZED (value 8): This option causes the command to run in a minimized window. In addition, the COBOL program remains the active program retaining the keyboard focus and keeping the active appearance. This is functional only when you are running under Windows.

CSYS-COMPATIBILITY (value 16): This option causes the command to run in a window that is compatible with the way the SYSTEM library routine works. Use this option if you want to modify a call to SYSTEM and change this call to C$SYSTEM. There are very few differences between the default behavior of SYSTEM and C$SYSTEM, so this option is rarely needed. The only known difference involves the Microsoft Word application. If you use SYSTEM to start Microsoft Word, it always starts in a "normal" sized window, that is, the window size suggested by Windows. If you use C$SYSTEM to start Microsoft Word (with no FLAGS specified), then Word adopts the last window size it previously used. Supplying a flag of CSYS-COMPATIBILITY causes C$SYSTEM to behave the same as SYSTEM. Of course, if you prefer the behavior of C$SYSTEM, the flag should not be used. In comparison with SYSTEM, C$SYSTEM generally conforms more closely to the way Windows itself launches programs. The CSYS-COMPATIBILITY flag is recommended only if you change a SYSTEM call to a C$SYSTEM call and you observe a difference you do not like.

CSYS-HIDDEN (value 32): This option runs the command in a hidden window. Note that some applications, particularly those that routinely interact with the user, may get confused if you "hide" the command. This works well, however, for executing system tasks that do not have a user interface, such as executing a batch file that renames a series of files. This option is functional only when you are running under Windows.

CSYS-SHELL (value 64): When this option is specified, C$SYSTEM uses the host's command-line processor (the host's shell) to execute the command. Otherwise, the command may be executed without the command-line processor. This option affects only Windows (non-Windows versions always use the host's shell). For Windows applications that create their own windows, you should avoid using the shell - the application will not receive the initial window size request specified in FLAGS. For ".COM" and ".BAT" programs, and other built-in shell commands such as COPY and DIR, you must use the shell or the command may not execute.

The effect of this option is to prefix the command with the value of the COMSPEC environment variable and "/C". Under Windows, this will usually result in a prefix like "C:\COMMAND.COM /C". Under Windows NT, the prefix will typically be "CMD.EXE /C".

CSYS-DESKTOP (value 128): This option is for applications running in the thin client environment. It indicates that the application wants to run the command on the client system rather than the application server. When the command executes, unless the CSYS-ASYNC option is also specified, the thin client appears to "hang" while the application waits for the command's termination status. This behavior can be avoided with the CSYS-ASYNC flag. The CSYS-ASYNC flag causes the command to be run asynchronously.

If CSYS-DESKTOP is specified but the calling program is not running under thin client, the flag is ignored and the command is run on the same machine as the calling application.

CSYS-INHERIT-HANDLES (value 256): This option causes the new process to inherit each inheritable handle owned by the calling process. This includes "stdin", "stdout", "stderr", and other file handles that the calling process has open.

Note that because the called process inherits many open files, it is vulnerable to running out of file handles.

This option is needed when an Alternate Terminal Manager runtime calls C$SYSTEM to run a batch program which in turn calls another Alternate Terminal Manager runtime. Without this option, the called program will not display any output to the screen.

[Kuk]

eage1969, usa el resalto de sintaxis. Y cuando hay un texto así de grande, mejor meterlo en un fichero Word o incluso TXT. ;)

[hwguerra]

Gusaiello,
Estimado quisiera hacerte una pregunta si me podes ayudar con la llamada (CALL SYSTEM)
al WSPOOLER.EXE de HASAR que lei algún comentario tuyo en donde se me plantea el mismo problema. Tal vez lo hayas podido solucionar....
Si me podes dar una mano mi mail es: [email protected]
De antemano agradezco tu respuesta
Walter Guerra

---------- Post añadido : 17:19 ---------- Post anterior : 17:11 ----------

Kuk,
Hola Kuk hoy me agregué al foro de COBOL pero no entiendo como tengo que hacer
para hacerle alguna pregunta a un usuario que tuvo el mismo problema que tengo hoy yo
para saber como lo solucionó....
Si me podes contestar te agradezco mi mail es [email protected]
Saludos y gracias.

[Kuk]

hwguerra, para aprender a manejarte en el foro, entra aquí: [Información] "No sé dónde y cómo publicar posts..." - COBOL Foro (http://cobolforo.es/showthread.php?t=561)

[jorgeamedina2020]

@Gusaiello, Hola, como estas?, me interesa conseguir el AcuCobol 5.1 para Dps y Windows, si es posible, hay alguna posibilidad de poder brindarme una copia?, gracias y saludos.

- - - Updated - - -

@Gusaiello, Perdon, me exprese mal, me interesa conseguir el AcuCobol 5.1 para trabajar en modo Consola (Dos) y modo Windows, si es posible, hay alguna posibilidad de poder brindarme una copia?, mi email es jorgeamedina2020gmail.com o [email protected]. desde ya gracias y saludos.