Conference clusta::acms

4115.0. "Problem with debugging COBOL/CDD programs" by CSC32::E_VAETH (Suffering from temporary brain cramp, stay tuned) Fri Feb 28 1997 10:01

I posted this in the CLT::DEC_COBOL_IFT notes conference.  I was asked to post
it here as well. The customer feels that ACMS/DEBUG on his COBOL program on
OpenVMS Alpha is useless.  Is the following expected behavior???

Thanks,

Elin

       <<< CLT::DISK$CLT_LIBRARY3:[NOTES$LIBRARY]DEC_COBOL_IFT.NOTE;1 >>>
             -< DEC COBOL notes [kits/docs - 2, performance - 7] >-
================================================================================
Note 580.0          Problem with debugging COBOL/CDD programs          2 replies
CSC32::E_VAETH "Suffering from temporary brain cramp, stay tuned"  114 lines 
27-FEB-1997 21:51
--------------------------------------------------------------------------------
Hi,

I have been working with a customer using DEC COBOL in their ACMS
and Oracle environment on OpenVMS Alpha.  It has been interesting 
to say the least.

Problem:

They work in an ACMS environment.  DEC COBOL is the compiler, Oracle 
is their database.  They were on DEC COBOL 2.3.  They found that
when they ran ACMS/DEBUG on the COBOL programs, that ACMS could not
locate the directory where the CDD pieces reside.  They use logicals
to point to where the CDD dictionary stuff resides. Then in their
COBOL programs, they:

	COPY 'SIS_DBCOPY.STUDENT'                 FROM DICTIONARY.
	
Investigation showed that (at their site using DEC COBOL 2.3) the
path for the CDD record included the logical name instead of
translating it. This was evident when we examined the COBOL object
module.  They would  end up with weird stuff.  Their COBOL program
has a copy statement like this:

	COPY 'SIS_DBCOPY.STUDENT'                 FROM DICTIONARY.

After compiling for debug, the object module shows that COBOL didn't 
evaluate the path correctly:

	(from the their object code)
	SIS_TP_TKDISK:[TP_TPSIS_DEV.USERS.SISPROG]SIS_DBCOPY.STUDENT;

Note that SIS_DBCOPY.STUDENT should be STUDENT.

Well, I tested using the 2.4 compiler and never saw this behavior. I
saw the opposite, that is *no path* for the copy module was 
embedded in the object code at all.  I asked the customer to try the 
2.4 compiler.  They did.  Now they don't get the incorrect CDD path
embedded in the object module, they get what I get, nothing! 

They say that this makes running ACMS/DEBUG completely useless.
Apparently ACMS/DEBUG needs to find correct CDD path in the object
code.  I checked with our ACMS folks and apparently ACMS has nothing
to do with this.  

I worked with an Oracle person and they too saw the incorrect
behavior running DEC COBOL 2.3-795.  The following test case shows
the problem with the incorrect translation of the CDD path in the
object module if you compile using the 2.3-795 compiler.   And it
will show that *nothing* gets in the object code using the 2.4 
compiler.  The customer says that either way, they cannot use
ACMS/DEBUG on their COBOL programs because of this.  

$ sear tst.obj sis
%SEARCH-I-NOMATCHES, no strings matched
$ sear tst.obj sis_dbcopy
%SEARCH-I-NOMATCHES, no strings matched
$ sear tst.obj dbcopy
%SEARCH-I-NOMATCHES, no strings matched

Is this expected behavior??

Thanks,

Elin

$ replace all occurrences of
$ DISK:[DIRECTORY.DIRECTORY] with one that will apply to your site.
$
$ mcr CDO
define dictionary disk:[directory.directory].
CDO>EXIT

$ define cdd$default  disk:[directory.directory]
$ define sis_dbcopy  disk:[directory.directory]
$ set default disk:[directory.directory]
$mcr cdo
Welcome to CDO V6.1
The CDD/Repository V6.1 User Interface
Type HELP for help
CDO> define field filler datatype text size 2.
CDO> define field afld datatype text size 10.
CDO> define record tes_record.
cont> filler.
cont> afld.
cont> filler.
cont> end tes_record record.
CDO> exit
$ create tst.cob
identification division.
program-id.  tst.
environment division.
input-output section.
file-control.
      select datafile
          assign to 'tst.dat'
          organization is sequential
          file status is fs.
data division.
file section.
fd datafile.
copy 'sis_dbcopy.tes_record' from dictionary.
working-storage section.
01  fs         pic xx.
procedure division.
start-here.
open output datafile.
      move spaces to tes_record.
      move all 'a' to afld.
      write tes_record.
      display tes_record.
      close datafile.

$ cob/noopt/debug/copy/list tst
    

I have more information from the customer.

The customer says he has no problem running COBOL programs in DEBUG mode that
copy CDD records *outside* ACMS.

He has no problem ACMS/DEBUG'ging COBOL program with COBOL COPY modules.

The problem is *only* when running ACMS/DEBUG where the COBOL modules are
copying in CDD record definitions.

Does ACMS inspect the object code looking for a path to the CDD record?  

Thanks,

Elin

    
    
    	The ACMS debugger creates a sub-process and runs the VMS debugger
    	to debug the server process.
    
    	They might be running into a quota problem with the ACMS/DEBUG
    	environment.  The task debugger runs in the main process, the
    	workspace looker in a sub-process, and each server that is started
    	in separate sub-processes.  There is a quota checking command
    	procedure on the freeware CDROM (and also available on the web)
    	that might help.
    
    	Bill
    

I have asked the customer to increase their quota's and let me know what
happens.  

thanks,


Elin

acms v4.1-0, alpha, ovm sv6.2, cdd v6.1, debug v6.2-103r

I have been working with Elin on this, and I'm seeing some results that
I don't understand.   Perhaps it can be explained as the way that
cobol is supposed to work in debug, but I don't think so.

The problem that I am seeing is that it is real tricky/difficult to
examine passed workspaces in a server procedure.  For some reason,
if the name of the cobol variable contains underscores (_), you
have to replace them with hyphens (-) when examining them
in the debugger.  Otherwise, you get a message from the debugger
saying that the symbol is not in the symbol table.

To demonstrate this, use our good old Avertz example.  It already builds
everything in debug, so you only have to follow directions.

Once the task group (.tdb) and servers are built, do the following.

acms/debug/workspace vr_task_group.tdb
ACMSDBG> sel vr_reserve_task

 - at the forms input, select customer id 1, site id 1 and cartype 1.
This will result in the vr_read_server being started.  At the debug
prompt, set a break on vr_res_details_proc.

Once you're at the dbg> prompt, try to examine any of the workspaces
that are passed as arguments.  I found that if I used the names
as they are in the program, the debugger didn't know what they were.
If I used hyphens in place of underscores in the names, I could
successfully examine the variables.

Is this the way it's supposed to work?

Jerry (someone who neither knows nor likes cobol)

    Jerry, that makes perfect sense:
    
    cobol024.release_notes:
    
         o  When using the debugger, you may notice that variable names that
            contain underscores and hyphens may have been changed, under cer-
            tain circumstances. These problems have been corrected in the de-
            bugger which will be available in a release of OpenVMS Alpha af-
            ter V7.0.
    
            Specifically, variable names that are "local" to your COBOL pro-
            gram (that is, names that are not visible to other separately com-
            piled program modules) have any underscores changed to hyphens when
            reported to the debugger. Thus, the data item "A_B" can only be
            ref-erenced as "A-B" in a debugging session.
    
            Names that are visible to other separately compiled program mod-
            ules (for example, EXTERNAL items, PROGRAM-ID names, etc.), have
            any hyphens in their names changed to underscores when reported to
            the debugger. Thus, the PROGRAM-ID name "SUBR-CALL" can only be ref-
            erenced as "SUBR_CALL" in a debugging session.
     
    Based on the input from the customer, they say that ACMS cannot find
    the record at all.  They have not used the ' symbol is not in the
    symbol table' term.  However, they may be *meaning* that. Although, as
    you also noticed, they have not provided complete accurate data to us. 
    Maybe it is time to go back to them and get more *detailed*.
    
    Thanks,
    
    -elin