Problem:

How can I change my Oracle password without having to recompile my COBOL programs?

Resolution:

Propose using environment variables and having COBOL access those.

Since Unix jobs are started by a shell, you can use this to your advantage when connecting to an Oracle database.

Your programs will run under your userid or they will have their own userid. If your userid is warren, then that userid is defined in your .profile file and it exists in your environment as $USER.

Lets assume that warren is the same userid that you use to connect to Oracle.

Now we need your Oracle password. Suppose it is braveheart. You would manually connect to Oracle as warren/braveheart.

You can create an environment variable for the Oracle password. We do that from the Unix command line by typing: export ORA_PASS=braveheart

Now that is in your environment as $ORA_PASS. Now that these variables exist in your environment, you can have your COBOL program access them by using the COBOL syntax:

1) DISPLAY UPON ENVIRONMENT-NAME.

2) ACCEPT FROM ENVIRONMENT-VALUE.

Here is a demo COBOL program that demonstrates how to do this:

 
       IDENTIFICATION DIVISION. 
       PROGRAM-ID. ERR114. 
       ENVIRONMENT DIVISION. 
       INPUT-OUTPUT SECTION. 
       FILE-CONTROL. 
       DATA DIVISION. 
       FILE SECTION. 
       WORKING-STORAGE SECTION. 
       01  WS-USER-FIELD   PIC X(15)   VALUE SPACES. 
       01  WS-PASS-FIELD   PIC X(15)   VALUE SPACES. 
      ***************************************************************** 
       PROCEDURE DIVISION. 
           DISPLAY "USER" UPON ENVIRONMENT-NAME. 
           ACCEPT WS-USER-FIELD FROM ENVIRONMENT-VALUE. 
           DISPLAY WS-USER-FIELD. 
           DISPLAY "ORA_PASS" UPON ENVIRONMENT-NAME. 
           ACCEPT WS-PASS-FIELD FROM ENVIRONMENT-VALUE. 
           DISPLAY WS-PASS-FIELD. 
           STOP RUN. 

Explanation: The statement: DISPLAY "USER" UPON ENVIRONMENT-NAME causes COBOL to select the environment variable named $USER

The statement: ACCEPT WS-USER-FIELD FROM ENVIRONMENT-VALUE causes COBOL to write the value stored in environment variable $USER into the COBOL variable WS-USER-FIELD

The statement: DISPLAY "ORA_PASS" UPON ENVIRONMENT-NAME causes COBOL to select the environment variable named $ORA_PASS

The statement: ACCEPT WS-PASS-FIELD FROM ENVIRONMENT-VALUE causes COBOL to write the value stored in $ORA_PASS into the COBOL variable WS-PASS-FIELD

Now you have the Oracle userid stored in WS-USER-FIELD and the ORACLE password stored in WS-PASS-FIELD.

Next you can move these values to the Oracle host variable that you will use in the CONNECT statement.

In the future, when you change your Oracle password, you change the value stored in your environment variable from the Unix command line by typing: export ORA_PASS=stagehand

The next time the program runs, it reads in the new value without requiring a recompile.

Problem:

My program appears to be losing its ability to perform thru exit. It falls to the next para instead of returning to the location where it was performed from. .

Resolution:

This customer's program presumably has some mainframe heritage, and was coded in such a way as to rely on implementation-specific behaviour that the mainframe gives. 

Fortunately we can emulate this behavior using the checker directive PERFORM-TYPE(OSVS).

It specifies the behavior of return jumps from nested PERFORM statements.

PERFORM-TYPE"OSVS" provides compatibility with the mainframe behavior of OS/VS COBOL and DOS/VS COBOL.

The following program demonstrates having an inner PERFORM (paragraph TESTER) fall into a new SECTION instead of returning to the controlling SECTION: 

       IDENTIFICATION DIVISION.
       PROGRAM-ID. PROGRAM1.
       ENVIRONMENT DIVISION.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  COUNTER           PIC 9       VALUE 0.
       01  SUB               PIC 9.

       PROCEDURE DIVISION.
       MAIN SECTION.
       BEGIN.
           PERFORM PROCESS
           DISPLAY "NORMAL TERMINATION"
           STOP RUN.
     
       PROCESS SECTION.
           DISPLAY "STARTING PROCESS SECTION".

       PROCESS-LOOP.
           PERFORM TESTER VARYING SUB FROM 1 BY 1 UNTIL SUB >= 10
           GO TO PROCESS-EXIT.     
       TESTER.
           IF (COUNTER = 6) 
               GO TO PROCESS-EXIT
           ELSE 
               ADD 1 TO COUNTER
           END-IF.
       PROCESS-EXIT.
           EXIT.
     
       FALL-THROUGH SECTION.
       ALERT.
           DISPLAY "*** FALL THROUGH CODE ***"
           STOP RUN.
       END PROGRAM PROGRAM1.


The program falls through when compiled using cob -vug Program1.cbl 
[support@rhsupv2 100500]$ cobrun Program1
STARTING PROCESS SECTION
*** FALL THROUGH CODE ***

The program succeeds when compiled using cob -vug demo.cbl  -C'PERFORM-TYPE(OSVS)'
[support@rhsupv2 100500]$ cobrun Program1
STARTING PROCESS SECTION
NORMAL TERMINATION

Problem:

How do I generate a file of test data for testing COBOL syntax?

Resolution:

There is a website, http://www.briandunning.com/sample-data/, that has free sample data for testing. They are 500 records. For a nominal price, you can download even larger data.

The files are comma delimited and line sequential. Therefore, a basic COBOL program can be written to format the data into a usable format.

For example, to test sorting, I downloaded a real estate file that contained the fields: street, city, zip, state,
beds, baths, sq__ft, type, sale_date, price, latitude, longitude.

The following program allowed me to turn the comma delimited file into a formated COBOL sequential file:

       program-id. Program1 as "Program1".

       environment division.
       configuration section.

       input-output section.
       file-control.
           select infile assign to "realestate.csv"
              organization is line sequential.

           select outfile assign to "realestate.dat".

       data division.
       file section.
       fd  infile.
       01  in-rec  pic x(120).

       fd  outfile.
       01  out-rec pic x(120).

       working-storage section.
       01 rec-size  pic 9(5).
       01 ws-eof    pic x value "n".
          88 at-end  value "y".
       01 ws-rec.
           05 out-address   pic x(36).
           05 out-city      pic x(16).
           05 out-zip       pic 9(05).
           05 out-state     pic x(02).
           05 out-bedrm     pic x(01).
           05 out-bath      pic x(01).
           05 out-sqft      pic 9(05).
           05 out-type      pic x(12).
           05 out-saledate  pic x(24).
           05 out-price     pic 9(6).
           05 out-lat       pic 99V9(6).
           05 out-long      pic s9(3)V9(4).

       procedure division.
       main-para.
           open input infile.
           open output outfile.
           read infile
               at end set at-end to true.
           perform 100-read
              until at-end.
           close infile, outfile.
           goback.

       100-read.
           read infile
               at end set at-end to true
                  go to 100-exit
               not at end
                   unstring in-rec       delimited by ","
                       into out-address
                            out-city
                            out-zip
                            out-state
                            out-bedrm
                            out-bath
                            out-sqft
                            out-type
                            out-saledate
                            out-price
                            out-lat
                            out-long
                    end-unstring
           end-read.

           write out-rec from ws-rec.
       100-exit.
           exit.
       end program Program1.

 Problem:

 How do I retrieve the program id (PID) on a Unix machine running Server Express?

 Resolution:

These two demos demonstrate how to retrieve the program id (PID) on a Unix machine running Server Express:

::::::::::::::
demo1.cbl
::::::::::::::
       program-id. Program1 as "demo".
       environment division.
       configuration section.

       data division.
       working-storage section.      
      $IF P64 set
       77  long                pic s9(18) comp-5 is typedef.
       77  uns-long         pic  9(18) comp-5 is typedef.
      $ELSE
       77  long                pic s9(9)  comp-5 is typedef.
       77  uns-long         pic  9(9)  comp-5 is typedef.
      $END
       01 current-pid     long.

       procedure division.
           call 'getpid' returning current-pid.
                display "PID is " current-pid.          
           goback.
       end program Program1.

::::::::::::::
demo2.cbl
::::::::::::::
       program-id. Program1 as "demo".
       environment division.
       configuration section.

       data division.
       working-storage section.
      
       procedure division.
                call 'getpid'.
           display return-code.
           goback.
       end program Program1

Problem:

Resolution:

Problem:

Solution:

Problem:

When using the (RM) variable and sending the screen output to a dump file, the generated file includes not only "text" but ANSI codes (unexpected or 'funny' characters).

It gives the 'header - funny characters' with the RM directive. Using MF directive it is all ok.

cob -v -C DIALECT'(RM)'
test.CBL
cobrun test > OUTPUT.TXT

'Funny' characters will show up in the output file

Resolution:

The 'funny' characters are terminal control characters, used to clear the screen, position the cursor at the upper-left prior to the display, and to restore the screen to its former state after the program terminates.

This is the default behavior of DISPLAYs in the RM world.

One way to inhibit this would be to add UPON SYSOUT (or UPON CONSOLE) to the DISPLAY statements:

DISPLAY "LINEA 1" UPON SYSOUT.

DISPLAY "LINEA 2" UPON SYSOUT.

In Visual COBOL you can use the directive DISPLAY(CONSOLE) to force all unqualified DISPLAY statements to effectively be UPON CONSOLE.

Problem

The following error is shown during installation of Visual COBOL for Eclipse.  

Error extracting 'SETUP_1.CAB': Failure writing to target file.

Resolution:

The Visual COBOL installation process does not have sufficient permissions to write files to the local drive and installation directory.

Restart the installation procedure using Administrator rights, ensuring that the Installation has sufficient permissions to the installation trget directory.

Problem

When adding a new Cobol source file to Visual COBOL for Eclipse project it does not compile.

 
Resolution:

Ensure that the affected source file is set to be built, not ignored by the COBOL compiler.

This is set by right clicking on the affected source file in the COBOL Explorer view, on the context menu that appears, look for the entry called "Build Action", and ensure that option "Compile" is selected within this.

Problem

What needs to be done to set the first program to run or debug, in a Visual COBOL project containing multiple source files that compile to single executable target?

 
Resolution:

Open the Project Properties, and navigate to the Application Tab.

In the Entry point Textbox type in the new program name e.g. "Program2".

Save everything and rebuild the whole project.

Trying to run or debug will show that the program "Program2" is started first.

Setting this option tells the Micro Focus runtime which program should be the starting program.

Problem

Cannot install Visual COBOL 2.2 Update 2 - Error 0x81f40001 - Setup has detected one or more Hotfixes are installed.

 
Resolution:

You are upgrading Visual COBOL and have hotfixes installed for the previous Version.  To resolve this issue please un-install these Hotfixes first via the Windows > Control Panel > Programs and features, thereafter the installation of the newer Visual COBOL Version will be successful.

It is recommended to also review the Visual COBOL Release Notes related to the version to confirm the above.

Problem

The Eclipse .Log file records any activity from the IDE, including exceptions and errors. This information is often very detailed and useful for troubleshooting issues, but it is not easy to read.

Can it be simplified?

 
Resolution:

The Eclipse IDE offers a View which extracts only the header line of each entry in the.>Log file, allowing for easier reading of the file contents.  

To view this in Eclipse go to Window>Show View>Other>General>Error Log.

Problem

When SQL programs contain host variables that are declared as COMP, compiling with OpenESQL on Windows and moving the INT code to a non-Intel platform gives incorrect values in the COMP variables.

Resolution

Database applications that use COMP host variables and are compiled with OpenESQL, can only be used on platforms with the same native byte ordering.

This is because the OpenESQL pre-compiler inserts additional code for COMP host variables on Intel (little-endian) platforms to handle the reverse byte ordering of COMP, compared to the native byte ordering.

Thus when you transfer the compiled code to a non-Intel (big-endian) system such as AIX, the additional code for handling COMP causes byte swapping problems.

There are two solutions to the problem:

1. Use COMP-5 instead of COMP for host variables. This has the added advantage of being more efficient compared to COMP.
2. Recompile the source on the target platform, as the OpenESQL pre-compiler will not insert the additional code for handling COMP's on non-Intel platforms.

Problem:

 Solution:

When attempting to install a Visual COBOL product on a Unix/Linux machine the following error is encountered.
PRN of product at /...
does not match PRN of update product.
PRN of install product :- .....
PRN of update product :-...

Some users have COBDIR set in either /etc/profile or .profile, or a similar login profile. Fix packs and hot fixes require that COBDIR set to the directory COBOL is installed. A check in the install is then performed to validate version of COBOL installed there matches the version contained in the hot fix or fix pack. In this situation ensure COBDIR is set to the COBOL installation directory that is the update target.

Complete product installs, such as updates, should be performed in an empty or newly created directory. In these situations, COBDIR should not be defined. If COBDIR is set, then the solution is to unset COBDIR. This will enable the installation of the complete product.

The user can launch a normal remote application session using the remote run configuration but not launch a remote debugging session under the debug configuration pointing the same Xserver.

This problem has been manifested when the use launches Devhub's startrdodaemon after first logging onto the Unix/Linux machine from the console as root, then launching a terminal session from the console, then launching the startrdodaemon from the terminal session.

Resolution:

Logon onto the Unix/Linux machine via remote ssh or from the console with a non-user id, then su to root in the terminal session, before launching the startrdodaemon.

aspbuttonerror.zips is a testBOMPPROGnew.zip

Problem

When deploying a service interface to an enterprise server instance, why does Eclipse display an 'Invalid thread access' error message?

Resolution

When deploying a service Interface, the following error message box may be displayed:

This message indicates that an 'object' has not yet been saved prior to deploying. It could be that a Program has not been saved. This message also occurs if an Operation has been added but not saved.

To resolve this issue, you can issue the Save All command either by using the icons on the toolbar:

or by clicking on 'File' and using the dropdown menu:

Problem:

In Net Express and Server for COBOL, the syntax to run the Data File Converter (DFCONV) command line is the following:

run dfconv profile-fname [input-fname] [output-fname]

In Visual COBOL or COBOL Server, running the above command line fails with the following error:

Resolution:

In Net Express and Server for COBOL, the DFCONV is a .lbr, which requires the RUN trigger program to execute it while in Visual COBOL and COBOL Server, DFCONV is a .exe. In other words, DFCONV must be executed without the RUN command:

dfconv profile-fname [input-fname] [output-fname]

Note: Since there is DFCONV.DLL in Visual COBOL and COBOL Server, the RUN command actually tried to run it and resulted to the Error 114.

Problem

 error undefined symbol _mFsoload

 Resolution

This simple example demonstrates how well Visual COBOL can integrate with PYTHON.

It covers the core subjects of COBOL and C build, BASIC PYTHON scripting and execution.

Here is the output

Output

/home/tonyt/test/tmp >. ./doit.sh
COBDIR set to /home/products/vcdevhub22upd2preGA
cob64 -C nolist -Zv helloworld.c program1.cbl 
helloworld.c:
program1.cbl:
* Micro Focus COBOL                  V2.2 revision 002           Compiler
* Copyright (C) Micro Focus 1984-2014. All rights reserved.
* Accepted - verbose
* Accepted - nolist
* Compiling program1.cbl
* Total Messages:     0
* Data:         320     Code:          78
* Micro Focus COBOL Code Generator
* Copyright (C) Micro Focus 1984-2014. All rights reserved.
* Accepted - verbose
* Accepted - pic
* Generating program1
* Data:          88     Code:         544     Literals:          32

LD_LIBRARY_PATH     </home/products/vcdevhub22upd2preGA/lib>
LD_PRELOAD          </home/products/vcdevhub22upd2preGA/lib/libcobcrtn64.so:/home/products/vcdevhub22upd2preGA/lib/libcobrts64.so:/home/products/vcdevhub22upd2preGA/lib/libcobmisc64.so:/home/products/vcdevhub22upd2preGA/lib/libcobscreen64.so:/home/products/vcdevhub22upd2preGA/lib/libcobtrace64.so>
sys.path            <
['/home/tonyt/test/tmp', '/usr/lib64/python26.zip', '/usr/lib64/python2.6', '/usr/lib64/python2.6/plat-linux2', '/usr/lib64/python2.6/lib-tk', '/usr/lib64/python2.6/lib-old', '/usr/lib64/python2.6/lib-dynload', '/usr/lib64/python2.6/site-packages', '/usr/lib64/python2.6/site-packages/gst-0.10', '/usr/lib64/python2.6/site-packages/gtk-2.0', '/usr/lib64/python2.6/site-packages/webkit-1.0', '/usr/lib/python2.6/site-packages', '/usr/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info']
>

before c call
Started Hello World
program 1 has started
after c call

At the end of the output it shows Python calls, C then C calls COBOL, returning back to PYTHON.

The doit.sh script below shows displays from PYTHON, C and COBOL.

Here is the doit.sh

doit.sh

#
# set cobol environment
#
unset LD_LIBRARY_PATH
. /home/products/vcdevhub22upd2preGA/bin/cobsetenv
COBMODE=64
export COBMODE
#
# create c program
#
cat >helloworld.c <<EOF
/* Hello World program */

#include<stdio.h>

main()
{
    cobinit();
    printf("Started Hello World\n");
    program1();
    cobtidy();
}
EOF
#
# create cobol program
#
cat >program1.cbl <<EOF
       program-id. program1 as "program1".

       environment division.
       configuration section.

       data division.
       working-storage section.
       01 in_data        pic x(10) value "prog1 data".

       procedure division.

           display "program 1 has started"
      *     call "Program2" using in_data.
           
           goback.

       end program program1.

EOF
#
# build the .so file
#
cob -Zv helloworld.c program1.cbl
#
# create python script
#
cat >mytest.py <<EOF
import ctypes
import sys, os
print
print "LD_LIBRARY_PATH     <" + os.environ['LD_LIBRARY_PATH'] + ">"
print "LD_PRELOAD          <" + os.environ['LD_PRELOAD'] + ">"
print "sys.path            <" 
print sys.path 
print ">"
print
#
mylib = ctypes.CDLL("./libhelloworld.so")
print "before c call"
mylib.main()
print "after c call"
exit()
EOF
#
# run the python file
#
# get these modules loaded
#
export LD_PRELOAD=$COBDIR/lib/libcobcrtn64.so:$COBDIR/lib/libcobrts64.so:$COBDIR/lib/libcobmisc64.so:$COBDIR/lib/libcobscreen64.so:$COBDIR/lib/libcobtrace64.so
#
# run the python script
#
python mytest.py
#
# remove the LD_PRELOAD
#
unset LD_PRELOAD
#
# end
#

Create a tmp directory as in ouput above,

Enter the doit.sh code into a doit.sh script in the tmp directory,

Change the cobsetenv comand to point at your COBDIR and,

Execute the doit.sh to get it to work.

The key is the LD_PRELOAD for a simple c calling COBOL library