I am new to COBOL programming.
I am making changes to a COBOL program which manipulates threads.I have introduced a file in the program to read a set of parameters and use it in the program. But whenever I compile the program I get the following warning:-
*1237-W
**Filehandling used with REENTRANT Directive
Now am I supposed to use the RENT option to compile this program? If so, then how should I compile using RENT option ie. the exact commands to be used.
Please help.
The error message number implies you are using Micro Focus COBOL, so depending on
the platform you can do:
Unix:
cob -C REENTRANT fred.cbl
Windows:
cobol fred.cbl REENTRANT;
cbllink fred.obj
or you can add the option to the actual source code itself eg:
$set REENTRANT
Related
I am pretty new to Informix and I have a program that I am adding some functionality to.
It seems that the program has some existing issues with it though.
When I run make -f makefile.mk I get success and the .4ge gets generated and I am able to run it.
However I am trying to get the program to run within informix 4gl interactive debugger but I get the error: Invalid module name [main] specified.
Any assistance would be greatly appreciated. Unfortunately I am unable to share code as the program contains confidential information
The Informix-4GL Interactive Debugger (ID) is for debugging programs compiled with the Informix-4GL Rapid Development System (RDS). The object files created by RDS (fglpc) have the extension .4go (I4GL p-code object file) and the executables are conventionally given the extension .4gi (I4GL p-code interpretable file — run using fglgo or ID's fgldb).
By contrast, the plain Informix-4GL (c-code) system uses an I4GL compiler to generate first ESQL/C code and then C code, and a C compiler to create regular object files (.o) and to create its executables, which are conventionally given the extension .4ge (I4GL c-code executable).
The ID cannot debug c-code executables. It can only debug p-code interpretable files.
On the face of it, therefore, your problem is that you are using the wrong tool for the job. Either you need to compile with RDS and create an interpretable, or you need to use a C code debugger such as GDB. However, be warned that debugging I4GL code with GDB is mainly an exercise in frustration as the bulk of the code is a series of function calls to library functions — or is an incredibly tortuous sequence of goto statements if you're debugging inside an I4GL report function. It is machine-generated C code; it is not intended to be comprehensible to humans.
I have the "wonderful" task of maintaining a legacy program that I didn't write. The Cobol program runs in a z/OS 2.2 environment and is compiled with IBM Enterprise Cobol 5.2. For debugging I would like to compile the program with the option CBL LIST, TEST (EJPD, SOURCE). Unfortunately, my source code has more than 999999 lines, so there is an error when compiling.
Is there a way to circumvent the limitation of the number of lines or is there only a way to split the program?
The 999999 limit on number of lines has been present since at least VS COBOL II, released in the mid-1980s. It's also present in Enterprise COBOL 6.3, the latest version prior to the compiler as of this update.
Perhaps someone is having you on, presenting you with uncompilable source. This is a compiler limit, and as #SaggingRufus has indicated, the solution would be to break the program up into multiple modules.
I would contend that a million+ lines of source code is incomprehensible.
Other mechanisms available to you include evaluating the code, looking for statements that span multiple lines for no good reason...
MOVE
A
TO
B
...is just silly.
As an aside, maintaining code you didn't write is part of the job. It used to be normal to put the new employees through a period of maintaining the existing code base to get them familiar with shop standards, etc.
Depending on the JES version, I believe you can you the WARNING parameter which would look something like this
//JOB10 JOB 1234,ME,LINES=(999999,WARNING)
This tells the system to continue even if the line limit is hit and only issue a warning.
Alternatively, you could output this compile listing to a file rather than a SYSOUT. Then the line limit would not apply
Also keep in a mind the having that many line in the JES spool is not a good thing, so I would recommend going the file route.
Is there any VM for Erlang that allows you to do compilation on the fly instead of compiling before?
There is a possibility to compile from the shell, thanks Martin.
Now, from the Erlang shell (or some other module!):
1> compile:file("mymod.erl").
{ok,mymod}
2> mymod:myfun().
Hello Joe
Is there any pros or cons with doing this?
Will you still be able to hot swap code?
Is it the regular use-case to handle code?
What benefits does the compiler give you in the end then?
From the Erlang shell, you can compile a module on the fly using c("path/to/module.erl"). You can also access this functionality through the compile module, specifically the compile:file/{1,2} functions.
For example, suppose we have a file mymod.erl:
-module(mymod).
-export([myfun/0]).
myfun() -> io:format("Hello Joe~n").
Now, from the Erlang shell (or some other module!):
1> compile:file("mymod.erl").
{ok,mymod}
2> mymod:myfun().
Hello Joe
See Erldocs on the compile module for more information.
You can do a great deal with the Erlang compiler in runtime. For example, you can dynamically generate code for a module (use erl_syntax!) and then compile it without even writing it to a file using compile:forms/{1,2}.
(Insert standard speech on great power and great responsibility.)
Will you still be able to hot swap code?
Yes.
Is it the regular use-case to handle code?
No. Normally Erlang code is compiled ahead of time into BEAM bytecode. Depending on whether Erlang was started in embedded or interactive mode, the modules are either loaded on startup, or dynamically as they are referenced. If you are building a release, you basically have to compile ahead of time.
What benefits does the compiler give you in the end then?
Well, for one thing, we can build compact releases without unnecessary components like the compiler. Of course, we also get all the traditional benefits of ahead-of-time compilation, particularly that of not having to waste time compiling all the time.
To sum it up, unless you fully understand the implications and have a very good reason not to compile your code ahead of time, please follow the standard practices.
The Erlang VM can only run compiled code! If you want to interpret Erlang code then you need an interpreter. The module erl_eval implements an Erlang interpreter and is part of the standard Erlang/OTP distribution. It is used by the Erlang shell to interpret the expressions entered.
All code handling in the Erlang VM, whether compiling, loading or updating, is done at the module level so it is impossible to compile or load a just one function. The Erlang compiler is written in Erlang and always available and can compile to either a file or a binary which can be immediately loaded into the system. As #MartinTörnwall has pointed out compiling a module from the shell using c(module) is in essence compiling on the fly.
So there would be no problems in automatically compiling code on the fly when it is used, at the module level. It is just that the current system is not designed to work that way and by default when it tries to load a module it only looks for the pre-compiled object file, the .beam file.
Erlang has an interpreter escript. Entire Erlang archive can be written in script. Almost all features are available.
By default, the script will be interpreted. You can force it to be compiled by including the -mode(compile). in the script.
Though it depends on the way you design your application, regular practice is to have .erl files which are compiled and run than having escript files.
So now you have many options.
Compile .erl file to .beam using c(my_module) this auto loads the .beam file. So the existing VM can run it on the fly. On in code you can use compile module functions like file, purge and load to load and run it on the fly.
Compile and keep the .erl files using erlc, erl -make, rebar, etc (Erlang has rich support) and then run it. You can build archives, boot scripts, rel etc to manage running and release of the Erlang software. This usually is the practice for production.
Use escript and run everything in interpreted mode.
Use escript and give -mode(compile) option to tell Erlang VM that at runtime (when starting to run escript) compile the code and run the compiled code (in memory)
Is there any pros or cons with doing this?
Compiled code is faster than interpreted code. I dont see any other right now in Erlang as pretty much everything is supported in both. Erlang even supports combination (Calling compiled code from interpreted code)
Will you still be able to hot swap code?
Yes in all cases. Your code also should be able to handle this.
Is it the regular use-case to handle code?
Option 2 for production. Option for 1 for learning / simple development. Option 3 and 4 in need basis for specific requirements (May be one time running).
What benefits does the compiler give you in the end then?
To make it clear, erlc program provides a common way to run all compilers in the Erlang system and compile module gives an interface to Erlang compilers. Compiler gives intermediate binary .beam file which helps in running Erlang code faster than interpreted counterpart. They also catch syntax errors (compilation errors).
If I compile a regular .lua file with luac, can the result be ran without the Lua library or interpreter installed?
No. You can run it on a version of Lua that was built without the compiler, but you still need the Lua interpreter to execute the code.
Incidentally, the compiled Lua bytecode is also machine-specific; i.e. you can't compile on one architecture and then run that output on another architecture unless you understand the subtleties (endianness, sizes of types, etc.).
If your code doesn't use any dynamic load-based facility (that's loadstring, loadfile, require, etc.) you can strip Lua library to just a VM, because what compiler emits is code to be run on this virtual machine. This can easily cut Lua already small footprint to 1/3 fraction of original.
However, since this is NOT a native binary code for any currently existing architecture, you still CAN'T run it directly without assistance of VM.
So here is the problem: Recently someone bought a new PC for server to replace an older dating from before 1985 (i wonder how it is possible to work daily from then) .
He wants to put there the old COBOL software and he isnt willing in any means to rewrite it to something better..
So is there any compiler for 1985 cobol? For nowadays red hat linux? Googling it found opencobol and other few but all converted the code to c... Seems too compilacted too me..
UPDATE AS REQUESTED
AIX was the old system
What's the problem with converting the COBOL to C and then compiling? As long as it works. Early C++ environments were implemented in the same way: they converted the C++ to C, and then invoked the C compiler.
Converting the COBOL to C allows them to use high-level abstractions that implement the COBOL equivalents in C. They can leverage the standard C libraries, and also convert the COBOL data access code into calls to widely available databases like MySQL. Finally, converting to C and then compiling leverages the vast amount of development effort that went into code generation. Were they to try compiling directly to object code, they'd have to generate the intermediate code expected by the GNU compiler subsystem, or they'd have to go directly to object code. Either one of those would be much more complicated than converting to C, meaning that the likelihood of bugs in the COBOL compiler would be much higher.
From where I sit, I'd say OpenCOBOL is worth looking into. Note that they say they implement "a substantial part of the COBOL 85 and COBOL 2002 standards." You probably want to make sure that they implement the parts that you need.
I would also suggest that you look into TinyCOBOL.
You don't mention when the application, or AIX was last updated. If these were updated in the last few years, you may be able to port the application, without re-compiling. You should check to see what COBOL compiler was used originally, e.g IBM, RM/COBOL, AcuCOBOL, etc. It might be possible to buy a run-time only version (will execute, but not compile), which would be cheaper than buying a compiler.
A company called Micro Focus make a cobol compiler for Windows but I can assure you it is not cheap at all!
Standard method for doing this is called migrating and involves a number of steps including converting source file to a textfile format or a filetype compatible with the target computer, using an approved method of converting to a file and writing to magtape with compatible recording method of Phase encoding or to disk or other data medium possibly in the ASN.xx mode, transferring to the new computer to then read in the file (through ASN.yy) and store it in a native or import file format, then either use a utility to convert it to the sourcefile format or by running the program development environment to access the native text file or import file and saving the content as a native sourcefile. Perform manual checks and amendments to the source or script code and then compile the program and repeat alterations until a working version is achieved. Create test data files on the new computer and create a new jobfile or macro to run the job in the development environment. When fully tested the program can be run live using data files and live macros or jobfiles migrated over from the old system or newly created in more or less the same way as bringing over the source code. An important point is that the live data must be read into a specialized data takeon or loading program to achieve a populated database before any new transactions occur in the case of a structured datafile being necessary. When moving from AIX or other versions of Unix to an entirely different operating system the characters for end of line and linefeed and end of record may need specific conversion if they are not handled by a file format convertor or exporter utility.