**** BINDER ERROR 19 **** Data block cannot be allocated
Tort
I am compiling a COBOL85 program and i am getting the below binder
error.
"**** BINDER ERROR 19 **** Data block cannot be allocated:
programname. Data block trying to fit below 32K "
My program call atleast 30 sub-programs for processing. I moved some
of my linkage section variables to Extended storage section and also
tried ?LARGEDATA complier directive. Still couldnt solve the above
issue. Could anyone please help!.
Thanks in advance!
Keith Dick
First, let me check what you mean when you said you moved some LINKAGE SECTION variables to EXTENDED-STORAGE. I hope you do not mean that you simply specified the ACCESS MODE in the LINKAGE SECTION to be EXTENDED-STORAGE. I hope you mean that you moved the variables that you pass in the CALL statement into the EXTENDED-STORAGE section. The wording of your post seems to indicate that you did that correctly, but I want to check to be sure.
That is the right direction to take, but it seems that you have not moved enough data into EXTENDED-STORAGE to solve the problem.
I am assuming that all of those sub-programs are COBOL. If some of them are TAL or another language, you might have to look at how much under 32K space they require.
The LARGEDATA directive only moves data items into EXTENDED-STORAGE if you name them explicitly or they are larger than the size you give in the LARGEDATA directive. The smallest size you can give for COBOL85 is 256, which means that any data item smaller than 256 bytes remains in WORKING-STORAGE. So if most or all of the space in your WORKING-STORAGE is taken by data items each smaller than 256 bytes, using LARGEDATA without naming the data items individually will not reduce the size of WORKING-STORAGE very much.
In case you are unclear of what the constraints are, let me outline them. A TNS program has only 64K words (16-bit words) of data stack, and for several reasons, only somewhat less than 32K words of the data stack is usable for the application program's data. The upper 32K words are reserved for the COBOL library's use, and some of the lower 32K words also are reserved for COBOL's use. The remaining part of the under 32K space is available for WORKING-STORAGE data items.
All WORKING-STORAGE data items for all of the programs in a run-unit must share that lower 32K words.
You can tell how much space each of your programs needs by looking at the last page of the compilation listing. The sum of Primary data words and Secondary data words is the amount of below 32K data that the program needs. Add them up for each of the programs included in the run-unit you are trying to create, and that will be the total amount of under 32K data it is requesting. If that total approaches 32,000, you will get BINDER ERROR 19. As I said, some of that under 32K area is taken by COBOL itself, so I cannot give you the precise amount of space you can use. It is somewhat less than 32K. One spot in the manual seems to say it is no more than 25K. That seems smaller than it ought to be to me, but it might be correct.
When you look at the data size shown at the end of the compiler listings, you might find one of your programs that is using a very large amount, and you can concentrate on reducing the WORKING-STORAGE needed by that program. If none of the programs uses a large amount of data space, then you will have to work in a number of your programs to reduce the total under 32K usage.
The simplest way to reduce the under 32K usage is just change the name of your WORKING-STORAGE section to EXTENDED-STORAGE. There are only a few things that will not work properly after such a change. I cannot recall any strictly COBOL features that will not work with data items in EXTENDED-STORAGE. There might be some restrictions that I am forgetting, but there will not be many such restrictions. I believe that you will get compilation error messages if your program does use something that does not work with EXTENDED-STORAGE data items. The only case I can think of right now that will not work with EXTENDED-STORAGE data items is when the program uses ENTER to call some Guardian procedures or TAL application procedures whose arguments include reference parameters that expect 16-bit addresses, those arguments must be in WORKING-STORAGE. I believe you will get compilation errors if you have cases of that.
So I think the simplest solution would be to change all of the WORKING-STORAGE sections to EXTENDED-STORAGE, and if you get compiler errors about certain data items, move them back into WORKING-STORAGE.
Note that the default for ACCESS MODE in the LINKAGE section is EXTENDED-STORAGE, so unless your program explicitly declares some of the LINKAGE section items to be ACCESS MODE STANDARD, you do not have to change the LINKAGE section to account for moving data items into EXTENDED-STORAGE.
If there is some reason that you cannot make all of your data be EXTENDED-STORAGE, then you can take the path of moving only selected items into EXTENDED-STORAGE until you have reduced the amount of space needed in the WORKING-STORAGE parts of all of your programs enough that, together, they fit in the space available under 32K.
dimandja
<<<
the simplest solution would be to change all of the WORKING-STORAGE
sections to EXTENDED-STORAGE
>>>
This worked for me everytime!