COBOL compilation with /NOOPTIMIZE option

[CORNU]

Hello,
we are running OpenVMS 8.4 on IA64 and we encounter a problem with the Cobol compiler.

The compiler options are /DEBUG /NOOPTIMIZE (as done in the previous 7.3.2 version on Alpha server).

when debugging we have the warning and no data accessible :

%DEBUG-W-UNALLOCATED, 'YA-ENR-REQMOD' is not allocated in memory (optimized away)

which refers to the /OPTIM param.

Any idea ?

[Shriniketan Bhagwat]

Hi,

Looks like this problem is fixed in VMS84I_UPDATE-V0400 kit. Please refer the section 5.2.49 from the release note.

==============================================

5.2.49 Debugger claims that the variable has been optimized

5.2.49.1 Problem Description:

When debugging a large PASCAL program if you attempt to
examine a variable, it fails with a message indicating
that the variable has been optimized. This happens
specifically in cases where the code is similar to the
PASCAL program as shown below:

$ type a2.pas

[INHERIT('file_name')]

PROGRAM USE(INPUT,OUTPUT);

BEGIN
READLN(Status);
WRITELN(Status);
END.

$ type b2.pas

[ENVIRONMENT('file_name')]

MODULE DEFINITIONS;

VAR
Status : UNSIGNED;
END.

Compiling b2.pas creates the file file_name.pen. The
variable "Status" is defined in b2.pas and used in
a2.pas. An examine of Status gives the following:

DBG> ex Status
%DEBUG-W-UNALLOCATED, 'STATUS' is not allocated in memory
(optimized away)

This problem has been fixed with changes to Pascal compiler
and debugger.

Images Affected:

- [SYSLIB]DEBUGSHR.EXE

Quix cases reporting this problem:

QXCM1001024131

5.2.49.2 Work-arounds:

None.

==============================================


Regards,
Ketan

[abrsvc]

RE: Katan

Two issues come to mind here:

1) What is the relationship of a "fix" for a Pascal problem to the Cobol problem posted?

2) I am unable to access the V0400 patch kit nor the release notes for it. Can you post them here? (I DO have access to the patch area, teh V0400 patch kit is not in the patch area. Why?)

Thanks,
Dan

[Hein van den Heuvel]

You have some good advice already.

- Is this critical to tackle a problem?
- the message possibly already tells you enough... the data was not 'touched'
- Is it a workaround to add an initialization (init or move) line for the variable to the program. Does that 'fix' it?
- Do you have a chance to test this on OpenVMS V8.3-1H1?
- If the problem persists for you, and blocks work, then perhaps with a (.TXT) attachment for a sample program, reduced to the minimum, to show the problem?

Cheers,
Hein

[P Muralidhar Kini]

Dan,

>> 1) What is the relationship of a "fix" for a Pascal problem to the Cobol problem
>> posted?
The VMS84I_UPDATE-V0400 kit has a similar problem fixed w.r.t to the pascal
compiler. The post here is related to Cobol compiler. Can it be that a similar fix
is required for a Cobol complier.

>> 2) I am unable to access the V0400 patch kit nor the release notes for it.
>> Can you post them here? (I DO have access to the patch area, teh V0400 patch
>> kit is not in the patch area. Why?)
I am able to view the release notes of the VMS84I_UPDATE-V0400 kit but unable
to download it (both AXP & I64). The release notes text is same as the one
posted by Ketan above.

CORNU,
Please forward your query to the HP's Office of OpenVMS programs interface
i.e. OpenVMS.Programs@hp.com.
This way your query would make its way to the compiler team here and they could
do a quick verification whether its a similar problem to what was fixed in
VMS84I_UPDATE-V0400 but for a Pascal compiler. This can then be taken forward.

Hope this helps.

Regards,
Murali

[John Gillings]

Cornu,

>The compiler options are /DEBUG /NOOPTIMIZE >(as done in the previous 7.3.2 version on >Alpha server).

/NOOPTIMIZE was a bad idea on Alpha, and it's an even worse idea on IA64. Maybe use it with /DEBUG when developing (but I tend to avoid even that, though it can make debugging a bit tricky). Always make sure your released code is compiled and tested with /OPTIMIZE.


>%DEBUG-W-UNALLOCATED... which refers to
>the /OPTIM param.

Regardless of the /NOOPTIMIZE qualifier, the nature of the IA64 architecture (and to a lesser extent Alpha) means that there is no such thing as unoptimized code. The compiler will always optimize to some extent. /NOOPTIMIZE really means "do as little optimization as possible".

>1) What is the relationship of a "fix" for
>a Pascal problem to the Cobol problem
>posted?

All compilers share some code generation and optimization. It's entirely plausible that the same issue reported for Pascal will affect other languages, and be fixed by the same update (though in this case there's insufficient information to say).

The "UNALLOCATED" warning is not an error, it just means the compiler hasn't created permanent storage for the variable, which will limit the times and places that it can be examined under DEBUG. You can still examine the variable when it's in scope by determining which register it's stored in and examining it directly (admittedly a non-trivial task on IA64). You can force the compiler to store it in memory with *DC SET VOLATILE around the declaration:

*DC SET VOLATILE
01 YA-ENR-REQMOD PIC 9(9) COMP.
*DC END-SET VOLATILE

As Hein has suggested, forcing initialization or perhaps DISPLAYing the variable may also convince the compiler to store it somewhere.

[Ana M. García Olivencia]

Hi all.

I don't know if you have solved the problem or not.

This is only to inform you that there is a patch for COBOL v3.0:

HP-I64VMS-COBOL-V0300-6-ECO1-1

Regards.

Ana