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!

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

Microfocus COBOL run time error 211

Status
Not open for further replies.
webrabbit

webrabbit

MIS
Jan 31, 2003
1,059
US
Microfocus COBOL 3.2.46

I am having trouble with the following program. Most of my applications I compile to a GNT and RUN them.
This program needs to be standalone, so I compile it as follows:

Xm cobol today,today.exe /LINKLIB"LCOBOL+COBAPI";
Code: 
 Identification Division.
 Program-ID.    TODAY.
 Author.        James C. Fairfield
 Installation.  Eurostar, Inc.
 Date-Written.  16 April 2003
     *>
     *> Creates a batch file to set the environment 
     *> variable TODAY to the current date in the form 
     *> mmddy.
     *>
 Environment Division.
 Input-Output Section.
 File-Control.
     Select BATCH-FILE Assign to 'TEMP.BAT'
         Organization is Record Sequential
         .

 Data Division.
 File Section.
 FD  BATCH-FILE.
 01  BATCH-RECORD        Pic X(15).

 Working-Storage Section.
 01  WORK-RECORD.
     05                  Pic X(10) Value 'SET TODAY='.
     05  WR-DATE         Pic 9(05).

 01  DATE-AREA.
     05  DATE-1          Pic 9(05).
     05  YEAR-2          Pic 9(01).
 01  redefines DATE-AREA.
     05  YEAR-1          Pic 9(01).
     05  DATE-2          Pic 9(05).

 Procedure Division.
     Accept DATE-1  from Date
     Move YEAR-1      to YEAR-2
     Move DATE-2      to WR-DATE
     Open Output BATCH-FILE
     Move WORK-RECORD to BATCH-RECORD
     Write BATCH-RECORD
     Close BATCH-FILE
     Stop Run
     .
The envronment is as follows:

PATH=R:\JR_DEV\UTIL;R:\JR_DEV\COBOL;R:\JR_DEV\COBOL\EXEDLL;R:\JR_DEV\COBOL\LBR;
C:\WINNT\SYSTEM32;C:\WINNT;C:\WINNT\SYSTEM32;U:.;Z:.;Y:.;W:.;
SET COBDIR=R:\JR_DEV\COBOL\EXEDLL;R:\JR_DEV\COBOL\LBR;R:\JR_DEV\COBOL\LIB;
SET LIB=R:\JR_DEV\COBOL\LIB;
SET COBCPY=R:\JR_DEV\JR\COPYLIB;

When I execute TODAY, I get error code 211 "Program not executable by run time system (fatal)".

If I compile the program to a GNT and RUN it, it works perfectly.

What do I need to do to fix this?
 
Sort by date Sort by votes
My guess is that there exists another today.exe in your PATH that is not the result of a Micro Focus COBOL compilation.

Within that environment, what happens if you just try to execute today.exe?

Tom Morrison
 
Upvote 0 Downvote
TODAY.EXE is in the current subdrectory. I get the same error if I give it a different name. I also get the same error with different programs with the same compile options. Other programs are more complicated, though, and have several subprograms. I chose TODAY as the smallest program for which I am getting this error.
 
Upvote 0 Downvote
3.2.46 was a 16 bit version designed to run on 16 bit Windows platforms such as 3.1. If you compiled and linked it (for DOS) on an old windows system it would probably run ok in a DOS window under 2000 although there are some limitations on that. I don't think that you can link a 16 bit application from a 32 bit windows version.

Try skipping the XM, that was an extended memory module that would not now be required.

Clive
 
Upvote 0 Downvote
If that does not work you could try a BUILD.

First make a line sequential file name BATCH.LBT containing the name of the GNT. ie. TODAY.GNT

Then make a config file named TODAY.CFG containing 3 records:
[PROGRAMS-TODAY]
TODAY.LBR
TOOLS.LBR
UTILS.LBR

Then from a command line type:
run BUILD TODAY /c TODAY.CFG /t TODAY /a TODAY.EXE TOOLS.LBR
and hit enter.

Hope that helps

Clive
 
Upvote 0 Downvote
All COBOL files (libraries, complier, etc.) are 3.2.46. The goal is to create a self-contained .EXE that will run with no attendant COBOL files. Using a build requires the Microfocus run-time system to be available at execution. I don't have any problem creating .EXEs that require the run-time system.
 
Upvote 0 Downvote
There are limitations to a static link, most notably the number of modules. Whether or not you link in the runtime modules, the modules are still there and they could just as easily be "there" in a build or a shared link, by including them separately.

Clive
 
Upvote 0 Downvote
The only difference between the shared and the 'static' run time systems is the way they are compiled. The 'static' runtime is compiled to object modules (OBJs) which can be included in a link whereas the shared runtime system is compiled and linked to a standalone module.

Static linking was intended for small one-off systems where all modules were linked together. Because the runtime system is relatively large it is pointless linking it it to every separate system or module. Indeed if you linked your program TODAY as a static link and it called another program TOMORROW also statically linked, at runtime you would be calling in a second redundant runtime system.

I am not at all clear what your objection to using the shared runtime is as it takes up no more space than if it were linked in.

Built applications run far more efficiently than shared links. Regardless of the path or the COBDIR, called modules are always looked for in the library (LBR) from where the initial application was launched. If the application is launched from a directory containing both the application and the runtime, a COBDIR environment variable is not even required.

Clive
 
Upvote 0 Downvote
I found this:

211 Program not executable by run-time system (Fatal)
You have tried to run a program that is incompatible with the current version of either your run-time system, your object file or your COBOL run-time library. For example, your run-time system does not run a program linked using a different object file format or COBOL run-time library.

If your object file is incompatible with the current version of either your COBOL run-time library or your run-time system, you should relink with the current version of your COBOL run-time library.


Clive
 
Upvote 0 Downvote
Shared runtime can also be compiled to .OBJ, then linked, to create a .EXE. The start-up code in the .EXE just loads the shared runtime system.

The purpose of static linking (in this case) is to create a stand-alone executable that can run on a computer that does not have the COBOL run-time libraries. TODAY does not call any modules other than run-time library modules, as you could tell if you read the program. I am able to do this with the same version of the compiler at home under Windows 98. It works fine when I port the .EXE to my other computer that does not have the COBOL runtime system. The problem is here at work under Windows 2000 Professional.
 
Upvote 0 Downvote
You never said that you had managed to run it on a system without a COBOL runtime. It appears that the problem is that your work computer does have a later COBOL runtime system. You might try changing your path and COBDIR to:

PATH=.;R:\JR_DEV\UTIL;R:\JR_DEV\COBOL;R:\JR_DEV\COBOL\EXEDLL;R:\JR_DEV\COBOL\LBR;C:\WINNT\SYSTEM32;C:\WINNT;C:\WINNT\SYSTEM32;U:.;Z:.;Y:.;W:.;
SET COBDIR=.;R:\JR_DEV\COBOL\EXEDLL;R:\JR_DEV\COBOL\LBR;R:\JR_DEV\COBOL\LIB;

ie. put a .; in each and try running your TODAY program from the directory where it resides or else temporarily remove the path and the cobdir.


Clive
 
Upvote 0 Downvote
ps. I did read your program but in another post you indicated that "Other programs are more complicated, though, and have several subprograms".

I feel like I'm talking to my ex-wife. Is your name Shirley?
:)

Clive
 
Upvote 0 Downvote
I never said that I got any program at work to run on a computer without a COBOL runtime system. I said that I have done this with other programs at home. The only difference (that I can determine) is that at work the o/s is Windows 2000 Professional, and at home it is Windows 98. The COBOL compiler is the same (3.2.46).

In regards to the sub-programs called by the more complicated programs, they are also compiled to .OBJ and linked with the main program. They are not separately linked.
 
Upvote 0 Downvote
Thanks for all the help guys. The user has agreed to let me put the run-time files on his computer. Case closed.
 
Upvote 0 Downvote
It occurs to me that maybe we have a misunderstanding on terminology. When you do a BUILD or a SHARED LINK you do not need the support of the whole Micro Focus runtime environment (which contains many other program products). You just need the COBOL runtime (coblib.dle) and utils.lbr and tools.lbr. If I remember correctly you may also need cobenv.dle for a build.

Clive
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

RichL32
  • Locked
  • Question
Microfocus Cobol Compiler for personal use
Replies
3
Views
623
mikrom
mikrom
A
  • Locked
  • Question
New COBOL Programming Course!
Replies
1
Views
342
SaltyTheFrog
SaltyTheFrog
C
  • Question
IBM AS400 COBOL Conditionally have a record blink
Replies
0
Views
120
chuckw0325
C
foxmuldr3
  • Locked
  • Question
RM/COBOL data extraction
Replies
15
Views
743
foxmuldr3
foxmuldr3
AMCM
  • Locked
  • Question
COBOL ERROR : Transfering data from txt file to another 1
Replies
12
Views
420
AMCM
AMCM

Part and Inventory Search

Sponsor

Back
Top