topic Re: Error %ILINK-E-IMEXP0 - Linking Cobol Program w/ Multimensional Tables - in Operating System - OpenVMS

Error %ILINK-E-IMEXP0 - Linking Cobol Program w/ Multimensional Tables -

idiazr — Fri, 04 May 2012 21:22:10 GMT

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

PROGRAM-ID. My_program.

77 NUM-ELEM PIC 9(05).

01 TABLE2.

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.

01 TABLE3.

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.

PROCEDURE DIVISION.

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)

END-PERFORM

END-PERFORM.

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 ".

stop run.

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

Re: Error %ILINK-E-IMEXP0 - Linking Cobol Program w/ Multimensional Tables -

Hoff — Fri, 04 May 2012 21:47:04 GMT

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.

Re: Error %ILINK-E-IMEXP0 - Linking Cobol Program w/ Multimensional Tables -

H.Becker — Sat, 05 May 2012 14:42:36 GMT

As said in another thread, the linker simply reports that after collecting all the modules and their sections, the generated image does not fit into the P0 address space.

It seems you just have a single source and object module. Analyze/object should show you the sizes of the ELF sections. From that you can estimate how much VA space is required.

No, this has nothing to do with stack and other program data in P1. The I64 linker does not determine the stack space. Also the l64 linker can not check whether the stack or the I/O space fits into P1.

You need to move some (code or) data out of P0. Code (and unwind data) is usually not that big, data is the problem. It depends on the compiler whether you can move code (and unwind data always follows code) and/or data into P2. See the compiler manual and the linker qualifier /segment.

There is a small chance that the missing VA space is only a couple of pages. Tweaking the linker options and qualifiers may give you just that. Have a look at the /segment qualifier, try to use a smaller /bpage value, try to use a single cluster, try to minimize the number of image segments.

Re: Error %ILINK-E-IMEXP0 - Linking Cobol Program w/ Multimensional Tables -

Hein van den Heuvel — Sat, 05 May 2012 16:36:21 GMT

[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!

Hein

Re: Error %ILINK-E-IMEXP0 - Linking Cobol Program w/ Multimensional Tables -

Hoff — Sat, 05 May 2012 16:16:35 GMT

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.

Re: Error %ILINK-E-IMEXP0 - Linking Cobol Program w/ Multimensional Tables -

John Gillings — Sun, 06 May 2012 22:05:10 GMT

> 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.

Re: Error %ILINK-E-IMEXP0 - Linking Cobol Program w/ Multimensional Tables -

H.Becker — Mon, 07 May 2012 06:41:25 GMT

The VMS programming model is something like "ILP32/LLLP64", which means you need a long long data type to get 64-bit integers and a long pointer type to get 64-bit pointers. By default the VMS compilers are in the P32 mode: pointers are 32 bits. With the known segmentation of the (32-bit) virtual address space into regions P0, P1 and S0/S1 VMS additionally limits the available address space for a user program and its static data to P0. To use more than what fits into the P0 address space region, the programmer needs to set the compiler into a 64-bit pointer mode. The compiler should then set the ALLOC_64BIT PSECT attribute so that the linker can assign P2 virtual addresses to these sections. On Alpha this is supported by FORTRAN and only data can be moved to P2. On I64 there are more compilers that have a 64-bit mode and code and data can be moved to P2. You have to change the programming language/compiler or your design if your compiler doesn't have a 64-bit mode. On I64 the linker can help, if the compiler has the 64-bit mode but doesn't set the ALLOC_64BIT PSECT attribute.

Another more popular, but maybe less modern 64-bit environment with an LLP64 programming model shows a bigger but somehow similar limit (http://software.intel.com/en-us/articles/memory-limits-applications-windows/, or just google LNK1248). There the limit is in the executable file format. As said above, VMS executables allow bigger static data, but require compiler support.

Re: Error %ILINK-E-IMEXP0 - Linking Cobol Program w/ Multimensional Tables -

idiazr — Mon, 07 May 2012 14:18:42 GMT

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,

Thanks again,

Re: Error %ILINK-E-IMEXP0 - Linking Cobol Program w/ Multimensional Tables -

idiazr — Fri, 11 May 2012 13:37:36 GMT

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.

Regards,

Vidya "

Re: Error %ILINK-E-IMEXP0 - Linking Cobol Program w/ Multimensional Tables -

H.Becker — Fri, 11 May 2012 15:06:09 GMT

>>> It is because of generated image, especially <text>, exceeds P0 address space.

Please don't misinterpret "<text>", it is not ".text". The linker reports this problem when adding the short data segments to the VA space of the image. As far as I remember, there are no other earlier checks, whether some code or data segments exceed the P0 limit. As said before, code (and this is sometimes referred to as ".text") is usually not the problem.

>>> We would like to know how big is your Cobol application.

I already recommended to use analyze/object to look at the size of the ELF sections. That's exactly what the linker will collect into your image.

>>> This qualifier is recommended only if your short data segment has reached the limit of 4 MB.

That's not the case, here. SDATAEXC is the message when the short data segments exceed 4MB. So it's not recommended, here, but you can try it. It falls into the category of minimizing the number of image segments.

Again, you may be lucky with some linker options and qualifiers. But before trying this, I would determine the required VA space from the object module and its ELF sections. The sum needs to be below 1GB and then there needs to be enough room for the (linker generated) short data, max. 4MB plus some foot room and segment padding depending on the BPAGE size.