The file handler mapping procedure to environment variables should be identical between native and managed code applications.
I just tested here using VC 2.3 and it works in a managed code project by setting the dd_OLD environment variable either in the app.config file or directly in the environment of the computer.
I used:
select test-file assign to "OLD\\testfile.dat"
and set dd_OLD = C:\\temp
and when I opened the file it correctly found c:\\temp\\testfile.dat
What product version are you using?
We're using VC 2.3. We are still fooling around with using ASPX to call COBOL DLLs. We've ditched the idea of using native COBOL DLLs because we never could get around that "wrong format" error and now we're trying managed COBOL. IIS is running under LocalSystem. The ASPX program is running under a "service account" used to run the web site. We've logged into the web server under the service account and created the dd_old environment variable with the required path as its value. And CORRECTION, we're getting "directory not found" vice "file not found".
Where is app.config? Is this machine.config or web.config? Is it to be set in the ASPX project or the COBOL project?
Actually for a C# ASP.NET application I don't believe that you can automatically set environment variables in web.config as the values you set are simply string pairs that can be read by your application.
If you are calling a COBOL program from within a C# ASP.NET application then you should be using RunUnits to do this or else the program will not be thread safe. Environment variables that are set prior to the opening of the COBOL files, (in computer environment or in application) will be picked up in the COBOL program.
Example: variable dd_NEW could be set in computer's environment also but here it is set by the calling C# program.
protected void Button1_Click(object sender, EventArgs e)
{
System.Environment.SetEnvironmentVariable("dd_NEW", "C:\\\\temp");
MicroFocus.COBOL.RuntimeServices.RunUnit myRunUnit =
new MicroFocus.COBOL.RuntimeServices.RunUnit();
try
{
// Call the COBOL program
COBPROG cp = new COBPROG();
myRunUnit.Add(cp);
myRunUnit.Call("COBPROG", "11111111111111111111");
}
finally
{
// Destroy the run unit
myRunUnit.StopRun();
}
}
COBOL program:
program-id. COBPROG.
environment division.
select test-file assign to "NEW\\myfile.dat"
organization is line sequential
file status is file-status.
data division.
file section.
fd test-file.
01 test-record pic x(20).
working-storage section.
01 file-status pic x(2) value spaces.
01 myvar string.
linkage section.
01 myparams pic x(20).
procedure division using by value myparams.
open output test-file
move myparams to test-record
write test-record
close test-file
goback.
Actually a better place to set the environment variables would be within the instantiated RunUnit itself so that this would not be set globally.
There is a SetEnvironmentVariable method in the RunUnit class:
Example:
MicroFocus.COBOL.RuntimeServices.RunUnit myRunUnit =
new MicroFocus.COBOL.RuntimeServices.RunUnit();
try
{
// Call the COBOL program
COBPROG cp = new COBPROG();
myRunUnit.Add(cp);
myRunUnit.SetEnvironmentVariable("dd_NEW", "C:\\\\temp");
myRunUnit.Call("COBPROG", "11111111111111111111");
}
finally
{
// Destroy the run unit
myRunUnit.StopRun();
}
The programmer actually doing the work has opted for setting all of the required environment variables within the ASPX front-end menu page program, so they will be available to all subsequently called ASPX task-starting programs and managed-COBOL batch programs.
But thank you for the info on RunUnit. I'll read up on that.
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.