Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ACUCOBOL Putting Displays Within The Program Out To A File

Status
Not open for further replies.

klophockey

Programmer
May 25, 2016
41
0
0
US
Typically, in a Cobol program if you have a line such as
DISPLAY "Hello World".
It will be displayed on the on console output. Of course, adding the line to UPON CONSOLE assures that it gets there.

I am calling a Cobol program from a batch file and want the console output to go to a file. The file is defined by a system variable called 'runout'

Eg. call cobolpgm >> %runout%

This works with no issue when executing MFCobol or ISCobol.
However when attempted with ACUCobol, it sends the output to a console window.

Anyone have an idea for me?

Thank you very much.
 
I think you may need to use the following runtime options.
-b Inhibits terminal initialization; useful for running in background.

and one of
-o filename File to be opened for display output
+o filename File to which display output is appended

Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
Just wondering if you had another suggestion.
The +o option did not work and I think the documentation tells me why....IT HAS NO EFFECT ON WINDOWS and I am running in a Windows 10 environment (see below)

I tried to use the -t option and list a file name. The problem I ran into on that was that I wanted to use the same output file that was being populated by the batch script and it had a problem with not being able to be shared. That is why the +o option looked so good; because I could append to a file already open and in use. I could not see where there was another option of -t to use it as an 'append' situation.

However, I tried the -t option pointing to a new file name just to avoid the conflict of file names but there was nothing put in that file. What I am expecting to be put in the file are DISPLAY something statements within the Cobol program.
Here is the code I execute

set RUNTIME=%cobolHOME%\bin\crun32.exe -t %qaHOME%\suite\TestResultx.txt

Here is the documentation I found on the +o option. Not the last line of the documenation
-o This option must be followed by the name of a
file that will take the display output from the
program. This is similar to output redirection
on UNIX systems. If “+o” is used instead, then
the output is appended to the named file.
Remote name notation is not allowed for this
option.
This option has no effect on Windows
platforms

As always, thank you
 
did you try the "-b" option as I mentioned?
And sorry but I did miss the "no effect on Windows platform"

Its unfortunate as although I do have the manuals and software I can't currently test it to see if a combination would work.

There may be other options to redirect the output - but it would involve a bit of powershell/c# code to start the executable as a process with no window and grab the outputs - not desirable but feasible for many programs - not sure if this runtime would behave correctly.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
Thank you again for your generous time and expertise.
I did try the -b option but there was no difference other than the output did not come popping up in a second window for a quick moment.
Wish I could capture that fleeting popup window because it has the Display lines from the Cobol program.
Rats!!!!
 
try the following - there are ways of dealing with the variables but for now just to try it out.

open powershell_ise
copy the following code on to a new window
change the cobolhome path to the correct one as well as the output file location
then execute it


$abc = $args
$startInfo = $NULL
$process = $NULL
$standardOut = $NULL

$startInfo = New-Object System.Diagnostics.ProcessStartInfo
$startInfo.FileName = "cobolhome\bin\crun32.exe" # Add correct cobolhome here
$startInfo.Arguments = "-b " # add the required cobol program name and other parameters as required

$startInfo.RedirectStandardOutput = $true
$startInfo.UseShellExecute = $false
$startInfo.CreateNoWindow = $false

$process = New-Object System.Diagnostics.Process
$process.StartInfo = $startInfo
$process.Start() | Out-Null
$standardOut = $process.StandardOutput.ReadToEnd()
$process.WaitForExit()

# $standardOut should contain the results of of the cobol run
$standardOut|out-file "suite\TestResultx.txt"


Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
I am somewhat embarrassed by this post because one could easily say 'Duh' with respect to the resolution.

Before I tried the code suggested for handling variables, I had a fleeting idea I had to try first.

Since the code worked in ISCobol and MFCobol, I was confused why ACUCobol was so different. That became apparent in that wrun32.exe was called to run the Cobol program. Essentially a shell that I did not control (except for the suggested code you sent on 4-24).

The very second line of my first post says it all. I had (as the example code) DISPLAY "Hello World".

The implicit response of the system was to put that Display out to the console in ISCobol and MFCobol (redirected to a defined file).
In ACUCobol, I am assuming since I was within a shell, it put it out to the little pop up window for the program as it executed.

My 'shot in the dark' was to EXPLICITLY tell the program to put the Display out to the console. I coded it DISPLAY "Hello World" UPON CONSOLE.
I aimply added UPON CONSOLE to each line that was to be displayed.

The program worked as I had expected it should and send the Display to the designated file. I had executed my Cobol program with call cobolpgm >> %runout% where the 'runout' variable was a defined file path and name.

BOTTOM LINE - It does what it supposed to do without having to modify the runtime options for wrun32.exe.

Thank you very much for your input and support along the way. I just fell into the solution on a hunch and take no great credit for exerting wisdom.
Your input was measured, reasoned and valuable and significant chance of succeeding to resolve the issue. I appreciate your kindness in offering assistance where I certainly needed expertise beyond my abilities.

Have a great day.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top