05-04-2012 02:22 PM
I can´t link a Cobol program,
>link /map my_program
%ILINK-E-IMEXP0, generated image, at least a short data segment, exceeds the P0 address space
77 NUM-ELEM PIC 9(05).
05 LOCAL2 OCCURS 1 TO 10000 TIMES DEPENDING ON NUM-ELEM.
10 COTRAN2 OCCURS 16 TIMES.
15 CCOSTO2 OCCURS 100 TIMES.
20 TICREDI2 OCCURS 10 TIMES.
25 CASES PIC S9(07)V99 COMP-3.
05 LOCAL3 OCCURS 1 TO 10000 TIMES DEPENDING ON NUM-ELEM.
10 COTRAN3 OCCURS 16 TIMES.
15 CCOSTO3 OCCURS 100 TIMES.
20 TICREDI3 OCCURS 10 TIMES.
25 VAL-TRX PIC S9(13)V99 COMP-3.
MOVE 10000 TO NUM-ELEM
PERFORM VARYING I FROM 1 BY 1 UNTIL I >= NUM-ELEM
PERFORM VARYING J FROM 1 BY 1 UNTIL J > 16
PERFORM VARYING C FROM 1 BY 1 UNTIL C >= 100
PERFORM VARYING K FROM 1 BY 1 UNTIL K >= 10
ADD 1 TO VALOR (I, J, C, K) VAL-TRX (NUM-ELEM, J, C, K)
VAL-TRX (I, J, C, 10) VAL-TRX(NUM-ELEM, J, C, 10)
VAL-TRX (I, J, 100, K) VAL-TRX (NUM-ELEM, J, 100, K)
VAL-TRX (I, J, 100, 10) VAL-TRX (NUM-ELEM, J, 100, 10)
DISPLAY " VAL-TRX (1, 1, 1, 1) " VAL-TRX (1, 1, 1, 1) CONVERSION " " " VAL-TRX (1, 1, 100, 1) " VAL-TRX (1, 1, 100, 1) CONVERSION.
DISPLAY " VAL-TRX (1, 1, 1, 10) " VAL-TRX (1, 1, 1, 10) CONVERSION " " " VAL-TRX (1, 1, 100, 10) " VAL-TRX (1, 1, 100, 10) CONVERSION.
DISPLAY " VAL-TRX (NUM-ELEM, 1, 1, 1) " VAL-TRX (NUM-ELEM, 1, 1, 1) CONVERSION " " " VAL-TRX (NUM-ELEM, 1, 100, 1) " VAL-TRX (NUM-ELEM, 1, 100, 1) CONVERSION.
DISPLAY " VAL-TRX (NUM-ELEM, 1, 1, 10) VAL-TRX (NUM-ELEM, 1, 1, 10) CONVERSION " " " VAL-TRX (NUM-ELEM, 1, 100, 10) " VAL-TRX (NUM-ELEM, 1, 100, 10) CONVERSION.
display "END OK my_program ".
Questions: My I use some parameters for LINKING?
Best regards and thank you,
Enviroment : itanium machine
HP COBOL V2.9-1453
OpenVMS IS 64 OS v8.3-1
05-04-2012 02:45 PM - edited 05-04-2012 02:47 PM
That's possibly an oddity with the environment, but it looks rather more like the code and the data structures are too big to fit into the available address space.
COBOL doesn't particularly implement 64-bit addressing on OpenVMS Alpha or on OpenVMS I64, and your code doesn't appear to fit into the available one-gigabyte P0-space virtual address space, and the available one gigabyte P1-space stack space. You're either going to need to make those arrays smaller (and potentially implement some form of data paging, if you need that much data), page the stuff in and out with a COMMON or a section or analogous, or move this application to a language that does provide 64-bit addressing and move your data into 64-bit (P2-space) address space, or move to a platform that offers 64-bit COBOL.
COBOL does have some baseline 64-bit pointer support, but not enough to get anywhere.
05-05-2012 07:42 AM
05-05-2012 08:32 AM - edited 05-05-2012 09:36 AM
[snide remark removed.]
'Normal' VMS Programs, in the 32-bit VAX, but also on the 64-bit Alpha and Itanium, have only 1 GB of normal process space for code, data and stack. 1/4 of the 4GB limit imposed by the old 32-bit implementation.
The program requests 2 arrays of 10000*16*100*10 = 160,000,000 element.
So even at 3 bytes each, you'd be out of 1GB space right there.
Is that 10,000 just a nice big number or a hard requirement?
If just for testing you change that to 1,000 you will see:
Level Name Size Bytes Usage ----- ---------- ---------- ---------- -------- 25 CASES 9 5 COMP-3 05 LOCAL2 80,000 80,000 DISPLAY 05 LOCAL3 128,000 128,000 DISPLAY 77 NUM-ELEM 5 5 DISPLAY 01 TABLE2 80,000,000 80,000,000 DISPLAY 01 TABLE3 128,000,000 128,000,000 DISPLAY 25 VAL-TRX 15 8 COMP-3
So that would fit.
I hope you also recognize how NUM-ELEM wil be a piece of string, to be converted to long a billion times over ( using OTS$CVT_DEC8_1_TO_UINT64).
For yucks and education, compile with /MACHINE/LIST and look at the expansion of the line with VAL-TRX (NUM-ELEM, J, C, K)
Now change NUM-ELEM to the the PIC 9(9) COMP that it supposed to be and compare the code expansion.
Anyway... this program needs to be changed and CObol is not going to be the best language to do the job.
If the array will stay the size it is declared today, then it can only live in P2 space.
You may want to process it once 'num-elem' at a time, either with double mapping otherwise calling to a subroutine pointing to one element at a time.
Best of luck!
05-05-2012 09:16 AM
Um, Hein? I'd expect that the OP was probably expecting that a computing system that is theoretically capable of addressing sixteen exabytes of virtual memory would be able handle a few gigabyte-sized arrays.
Certainly without resorting to RSX-11M/M+ TKB-style shenanigans, and without re-coding the application memory management implementation.
That COBOL and VMS would do the correct thing here.
(If I didn't know the details of the environment and the implementation, I would too.)
Particularly given how (most, modern, typical) 64-bit environments usually implement exactly this flat model.
And clearly the OP found the segmented address space confusing, and the error messages cryptic.
I'd presume this question to be as much a bug report as a question, too. And unfortunately, VMS is locked into this (bad, confusing, poor, segmented) design. And COBOL, too, unfortunately lacks 64-bit.
05-06-2012 03:05 PM
> 32-bit VAX, but also on the 64-bit Alpha and Itanium, have only 1 GB of normal
> process space for code, data and stack. 1/4 of the 4GB limit imposed by the old 32-bit implementation.
Not often I catch an error in one of Hein's posts... Small correction. Processes have 1GB for user code and data (P0 space). The stack lives in a separate 1GB region, also used for some system code and data (P1 space). There are vast tracts of 64 bit virtual address space available (P2 space), but you have to work to exploit it. Some languages make it easier than others, unfortunately for you, COBOL is NOT one of them.
Back in 1991 or so when Alpha was introduced, the "stretched" 32 bit VA was a very clever way to introduce some 64 bit capability while maintaining compatibility with 32 bit programs. 20 years later one would have hoped that stepshad been taken to move VMS from a 32 bit operating system with some 64 bit stuff tacked on the side, to be more like a real 64 bit operating system. Unfortunately that hasn't happened, and is unlikely in the future.
If you need to maintain your COBOL logic, you could abstract the data structures into an external module written in a more 64 bit friendly language. Take your pick, Fortran, C, whatever you have compiler for etc... A fairly simple model would be to implement each table as a pair of routines, a function to read a value:
Value= GET_TABLE_VALUE(dim1,dim2,dim3,...) of TABLE type
and a function to write a value (optionally returning the old value):
OldValue = PUT_TABLE_VALUE(NewValue,dim1,dim2,dim3,...) of TABLE type
Routines are fairly trivial, appropriate 64bit structure definitions, and references set or return the value. You COBOL code doesn't change much, just replace references to the structure with calls to the routines.
Ugly, but unfortunately necessary.
05-06-2012 11:41 PM
05-07-2012 07:18 AM
Thank you for all smart people,
When I change first occurs (10000 for 1000) , the program linked ok, I'll check if I need 10000 occurs and change the solution not the language,
05-11-2012 06:37 AM
I received this answer from HP.com support ( http://www.openvms.compaq.com/commercial/cobol/)
"We see this error message when linker does a check if short data fits in P0 space and it exceeds P0 address space(1GB limit).
It is because of generated image, especially <text>, exceeds P0 address space.
We would like to know how big is your Cobol application.
Can you check using qualifier "/SEGMENT_ATTRIBUTE=SHORT_DATA=WRITE" with the linker?
Notes from Linker Manual,
With the /SEGMENT_ATTRIBUTE qualifier you can change some attributes for a class of sections (SHORT_DATA, CODE, and SYMBOL_VECTOR).
The /SEGMENT_ATTRIBUTE=SHORT_DATA=WRITE command qualifier allows you to combine the read-only and the read-write short data segments into a single segment, reclaiming up to 65,535 bytes of unused, read-only space (default value for /BPAGE).
This qualifier is recommended only if your short data segment has reached the limit of 4 MB.
05-11-2012 08:06 AM