vDos in Windows task scheduler

[modelo64]

Hello everybody.

As I explained in another post, I currently have a system developed in RM-Cobol running on Windows 8 (32 bits).

On the installed system I have several tasks scheduled in the Windows task scheduler.

They all run from .BAT files, many of which have calls to RM-Cobol programs.

Currently they all run without problems.

The problem started with the need to migrate these computers to Windows 10 or higher.

Unfortunately on Windows 10 or higher, all .BAT files that contain calls to RM-Cobol programs do not work because the RUNCOBOL is 16-bit.

Then, I need to know how I can include in those .BAT files the previous call to the vDos environment, so that the RM-Cobol programs to which it calls can be executed.


For example, this is a .BAT file that I currently have scheduled to run every half hour in the Windows 8 task scheduler:

rem PROCWEB.BAT

rem ------------------Start the procedure
@echo off
cmd.exe /c
F:
cd \
cd PROGRAM
cls
rem ------------------Start web file migration process
RUNCOBOL PMW01SAM K
RUNCOBOL PMW01SPS K
rem ------------------Completes web file migration process
cls
rem ------------------Finishes the procedure


As you can see, there is nothing special about it.

Only the call to cmd.exe /c, the change of drive and directory, and the call to the RM-Cobol programs.

Except for the last one, the call to vDos would not be necessary....

Then, so that the RM-Cobol programs can run in the vDos environment, how should I make the call to the RUNCOBOL statements in those .BAT files? 

> modelo64

[Jos]

A suggestion: Set the extension of DOS batch files to BAT, those of Windows to CMD. Just to clarify what they are meant for.

More than one option to create tasks starting RUNCOBOL in vDos, one:

Create a subdirectory PROCWEB in (Windows) F:\PROGRAM, and create an autoexec.txt file in that, with:

USE F: ..\..\
F:
CD PROGRAM
RUNCOBOL PMW01SAM K
RUNCOBOL PMW01SPS K
EXIT

For transparency of the logic, also copy vDos.exe to F:\PROGRAM\PROCWEB. Then schedule F:\PROGRAM\PROCWEB\vDos.exe.

Jos

[modelo64]

I think it's a very good practice to separate batch files into those for DOS and those for Windows. I will implement it.

So, if I understood correctly, I should create a folder for each task I would like to add in the task scheduler, when it includes a call to a RM-Cobol program.

And in each of those folders, I should also include the vDos.exe and an autoexec.txt with the calls to those RM-Cobol programs.

In my case it will be about 8 tasks to program, but well, if that is the solution, I will do it that way.

I thought that maybe there was an "option" to make a call to vDos with some "parameter" as to be able to execute "something" inside the vDos environment and finish.

So, that "option" involves creating different vDos environments with their own autoexec.txt, to be called in each case.

I will try to implement it and then I will comment the results.

Thanks!

Note:

In tasks with many calls to RM-Cobol programs (I have a few) or where the processes take some time, I guess this option will work properly and will not stop execution only if we have the license, so that the "About popup" window does not appear in the middle of the scheduled task.

It is one more reason to justify the purchase of the license in the Organization where I work....

> modelo64

[Jos]

Well it was one option. Another would be to create a directory RM-TASKS with vDos.exe, batch (.BAT) files like PROCWEB.BAT, and an autoexec.txt like (assuming the batch files end with an EXIT themselves):

USE F:..\...\
F:
CD PROGRAM
C:%WIN_VDOS%.BAT

PROCWEB.BAT would then be:

RUNCOBOL PMW01SAM K
RUNCOBOL PMW01SPS K
EXIT

And schedule F:\PROGRAM\RM-TASKS\vDos.exe batch_file_to_start.
Parameters to vDos.exe will be assigned to the DOS/vDos WIN_VDOS environment variable.

The About popup can indeed affect automated tasks without user involvement.

Jos

[modelo64]

I like this option better, it seems to me more "clear" than the previous one, where I had to create several folders, one for each task.

This is like the "option" that I imagined in the previous lines where the call was passed a "parameter" to execute "something" inside the vDos environment.

I'll give it a try and then report my experiences.

Thanks again!

> modelo64