Skip to main content

Hello. The file 1-lunes.bat contains the instructions to make a backup and run a program as shown below:

CD D:\\catalina-gas\\inventar

runcobol.exe averaver.cob c=windows.cfg L=WOWRT.DLL

CD D:\\catalina-gas\\creditos

runcobol.exe solito.cob c=windows.cfg L=WOWRT.DLL

CD D:\\catalina-gas\\pagar

runcobol.exe solito.cob c=windows.cfg L=WOWRT.DLL

RMDIR /S  /Q f:\\backup\\catalina-gas\\lunes

XCOPY /E /I /Y D:\\catalina-gas f:\\backup\\catalina-gas\\lunes

 

1-monday.bat runs perfectly when it receives a direct clip to the shortcut on the Desktop but if it is placed as a Windows task in task scheduler program script D:\\catalina-gas\\backup\\1-monday.bat the program AVERAVER.COB produces an error: Cobol configuration 410 error processing configuration

 

My question is: Why does 1-monday.bat run perfectly by clipping a shortcut and produce a 410 error when Windows runs it in the task scheduler?

Hello. The file 1-lunes.bat contains the instructions to make a backup and run a program as shown below:

CD D:\\catalina-gas\\inventar

runcobol.exe averaver.cob c=windows.cfg L=WOWRT.DLL

CD D:\\catalina-gas\\creditos

runcobol.exe solito.cob c=windows.cfg L=WOWRT.DLL

CD D:\\catalina-gas\\pagar

runcobol.exe solito.cob c=windows.cfg L=WOWRT.DLL

RMDIR /S  /Q f:\\backup\\catalina-gas\\lunes

XCOPY /E /I /Y D:\\catalina-gas f:\\backup\\catalina-gas\\lunes

 

1-monday.bat runs perfectly when it receives a direct clip to the shortcut on the Desktop but if it is placed as a Windows task in task scheduler program script D:\\catalina-gas\\backup\\1-monday.bat the program AVERAVER.COB produces an error: Cobol configuration 410 error processing configuration

 

My question is: Why does 1-monday.bat run perfectly by clipping a shortcut and produce a 410 error when Windows runs it in the task scheduler?

What directory contains windows.cfg?  

My guess is that in your desktop shortcut, somehow the RUNCOBOL environment variable contains the directory in which windows.cfg is located. 

Perhaps the task scheduler is running as a different user, and the RUNCOBOL environment variable is not initialized to the expected value(s).

What directory contains windows.cfg?  

My guess is that in your desktop shortcut, somehow the RUNCOBOL environment variable contains the directory in which windows.cfg is located. 

Perhaps the task scheduler is running as a different user, and the RUNCOBOL environment variable is not initialized to the expected value(s).

D:\\catalina-gas\\backup

What directory contains windows.cfg?  

My guess is that in your desktop shortcut, somehow the RUNCOBOL environment variable contains the directory in which windows.cfg is located. 

Perhaps the task scheduler is running as a different user, and the RUNCOBOL environment variable is not initialized to the expected value(s).

Volume in drive D is Misprogramas

 Volume Serial Number is 80F4-A930

 

 Directory of D:\\catalina-gas\\backup

 

[.]                 [..]                1-lunes.bat         2-martes.bat

3-miercoles.bat     4-jueves.bat        5-viernes.bat       6-sabado.bat

7-domingo.bat       Backup-Diario.lnk   BACKUPWG.COB        BACKUPWG.wow

confirmar_0.bmp     domingo_0.bmp       folder.doc          jueves_0.bmp

logfont.cpy         lunes_0.bmp         martes_0.bmp        miercoles_0.bmp

regresar_0.bmp      sabado_0.bmp        viernes_0.bmp       windows.CFG

windows.cpy        

What directory contains windows.cfg?  

My guess is that in your desktop shortcut, somehow the RUNCOBOL environment variable contains the directory in which windows.cfg is located. 

Perhaps the task scheduler is running as a different user, and the RUNCOBOL environment variable is not initialized to the expected value(s).

The windows.cfg, the file is in every folder where any program is executed

The windows.cfg, the file is in every folder where any program is executed

Does windows.CFG have adequate permissions for the user being used by the task scheduler?

I think I would add dir *.* >debug.txt into the BAT before each runcobol.  This might help???

Does windows.CFG have adequate permissions for the user being used by the task scheduler?

I think I would add dir *.* >debug.txt into the BAT before each runcobol.  This might help???

Sorry Tom, still giving the same error.

Sorry Tom, still giving the same error.

Ok, Wascar.

Error 410 is very specific - the configuration file cannot be found.

The C command line option uses a pathname.  One thing you could try is to specify a non-relative pathname.  Your current C=windows.cfg would seem to need the configuration file in each of the current directories.  (I looked at User's Guide.  My assumption that the RUNCOBOL environment variable would be involved, but I cannot find this documented.)

Other than simply not being in a directory, the next most likely cause would be that the file exists, but does not have read permission for the user.  (If this were Unix/Linux, upper and lower case make a difference, but this is Windows where case is ignored.)

Sorry Tom, still giving the same error.

Did you ever solve this issue?

Did you ever solve this issue?

Hello, I did everything you told me but nothing works. I have decided not to continue with this because I cannot find solutions.

Hello, I did everything you told me but nothing works. I have decided not to continue with this because I cannot find solutions.

I have emailed you a test script to help diagnose the problem.  Sorry for going to email, but I see no way to attach a file to this post.

What directory contains windows.cfg?  

My guess is that in your desktop shortcut, somehow the RUNCOBOL environment variable contains the directory in which windows.cfg is located. 

Perhaps the task scheduler is running as a different user, and the RUNCOBOL environment variable is not initialized to the expected value(s).

The solution was closely related to this diagnosis.  The Task Scheduler places the 'start in' directory in a very obscure location.  Once Wascar set the start in directory in the scheduled task, he reports the program runs.

The solution was closely related to this diagnosis.  The Task Scheduler places the 'start in' directory in a very obscure location.  Once Wascar set the start in directory in the scheduled task, he reports the program runs.

Tom: thanks for helping Wascar with this problem and posting the update.

Terms & ConditionsAccessibility statement