File Handler behavior in managed code

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.