I'm trying to run idebug with a COBOL program localy in an AIX machine.
The COBOL source program as an ACCEPT statment (ACCEPT PG-PARAMETERS FROM PARAM.)
The program execute correctly withot the idebug.
When the program is executed with the idebug it got stack in the ACCEPT clause.
I believe that I'm not passing correctly the parameter in the command line.
The program is compiled as follow:
cob2 -g -o testdbg testdbg.cbl
The idebug is executed in a xterm with the command:
idebug -qlang=COBOL -- testdbg "ABCDFIRSTPA"
I tryed other idebug combinations like: idebug -qlang=COBOL -- testdbg < param.lst. When param.lst containst the parameters.
SYSIN IS PARAM.
02 PARAMETER-CODE PIC X(004).
02 PARAM-NAME PIC X(006) VALUE SPACES.
display "start "
ACCEPT PG-PARAMETERS FROM PARAM.
display "PARAM: " PG-PARAMETERS
Pinned topic Idebug - how to pas parameter from the command line
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-11-01T19:58:41Z at 2012-11-01T19:58:41Z by SystemAdmin
Dwayne_M 10000005FD27 Posts
Re: Idebug - how to pas parameter from the command line2009-07-06T17:45:17ZThis is the accepted answer. This is the accepted answer.The syntax to use when specifying the program to debug an its arguments when invoking the IBM Debuger for AIX is:
idebug programname programarguments
Which COBOL compiler are you using to compile your testcase? The statement
SYSIN IS PARAM.
only names PARAM as an alias or mnemonic for SYSIN, so the program which you provided still is expecting its input to be entered from the console (i.e. SYSIN) - the program is not reading the arguements specified on the command line when invoking the program. So whether or not the program is being run inside the debugger it will stop at the ACCEPT and wait for its input before continuing.
SystemAdmin 110000D4XK549 Posts
Re: Idebug - how to pas parameter from the command line2012-11-01T19:58:41ZThis is the accepted answer. This is the accepted answer.hardware is streamlined through interrupt systems.
i acquired the same software through foxconn... ie burn/heat testing software
i would imagine the heat software is designed to burn test the computer to failure, or what would be the point?
trying to verify a chipset.cmd.drv.sys file would be redundant