I was restoring production database file, HELLO161, file 55, to TST225 (Database).
I have encountered following error:
ERROR-060, AC-Extent space allocation failed for file 55.
O Not enough free space available
O Conflicting ACRABN parameter.
O More than the maximum possible number of ISNS
An attempt was made to allocate AC-SPACE for 300252 ISNS
Starting at RABN 1141755
on device 8390
Let me get in before Brian and point out the game of Russian roulette that your company is playing by not providing an appropriate level of training/mentoring for the role it is asking you to perform. Click, click, click, … ?
The knowledge and skills imparted in such training would have allowed you to interpret the error message and determine the cause of the problem.
Three possibilities are suggested in the ERROR-060. Let’s work through them in order starting with the least likely.
O More than the maximum possible number of ISNS. This translates to MAXISN > a very large number. It looks like you haven’t entered an obscenely large MAXISN (300252?) so we can discount this one. The maximum value allowed depends on the version of Adabas you are running (which you haven’t mentioned).
O Conflicting ACRABN parameter. Have you specified an ACRABN? If not, move on to the next option. If you did check that the AC RABN (1141755?) is available and that there is enough free space after it to fit the AC (address converter) extent for the file (RABNSIZE * MAXISN). It looks like you are dealing with a test database where component placement probably isn’t important so remove any xxRABN parameters and try again.
O Not enough free space available. There isn’t a big enough chunk of free ASSO available to fit the address converter for the file (RABNSIZEMAXISN). Assuming 3 byte RABNS you will need a 3300252/3440(8390 ASSO block size) = 262 contiguous free blocks of ASSO to load the AC. Even if you find the 262 ASSO blocks, I suspect that you’ll next be tripping over allocations for UI, NI and maybe even DATA.
Good luck Dawar, I hope the next chamber isn’t loaded.
If you did check that the AC RABN (1141755?) is available and that there is enough free space after it to fit the AC (address converter) extent for the file
Graeme’s response was quite complete, and hopefully you will understand the issue you had.
If you still have doubts, please include some more information about the database versions (source and target), current allocations in the source and target environments, the parms you specified in the utility, and perhaps most important for the error you got, the MAXISN settings for source and target.
Pre-Adabas 8 you were limited to 5 extents per part (AC/NI/UI/DS). Sounds to me like you don’t have enough unused space in your ASSO for the AC extent required for the MAXISN of your source file, but other possibilities exist too for this error, especially if you are providing certain parms.
The pdf you posted doesn’t tell a lot in excess of whom you are working for …
There are 2 places in the ADAREP output which show the exact locations of various blocks for a certain file
***********************************
* *
* Physical Layout of the Database *
* *
***********************************
From To Number Dev Table File VOLSER
Blk Blk of Blks Type Type Number
1031 - 1062 32 8393 PPT 0 FSM044
1063 - 1064 2 8393 DSST 0 FSM044
1065 - 1074 10 8393 UNUSED 0 FSM044
1075 - 1076 2 8393 AC 9 FSM044
1077 - 1093 17 8393 NI 9 FSM044
1094 - 1105 12 8393 UI 9 FSM044
1106 - 1171 66 8393 AC 8 FSM044
1172 - 1188 17 8393 NI 8 FSM044
1189 - 1190 2 8393 UI 8 FSM044
and the file details
List I Dev Block I Space Alloc. I From To I Unused Space I
Type I Type Lngth I Blocks Cyl I RABN RABN I Blocks Cyl I
I I I I I
-----I------------I------------------I---------------------I------------------I
I I I I I
AC I 8393 4092 I 2 0I 1451 1452I I
NI I 8393 4092 I 2 0I 1453 1454I 1 0I
UI I 8393 4092 I 2 0I 1455 1456I I
DSST I 8393 4092 I 1 0I 1063 1063I I
I I I I I
DS I 8393 27644 I 30 1I 2058 2087I 29 0I
I I I I I
-------------------------------------------------------------------------------
The PHYSICAL LAYOUT section of ADAREP only tells you the database’s physical extents:
P H Y S I C A L L A Y O U T
DD- I Dev I Nmbr of I Nmbr of Extents in Blk. I Block I Nmbr of I
Names I Type I Cyls I Blocks From To I Lngth I M-Byte I
I I I I I I
-------I------I---------I----------------------------------I-------I----------I
I I I I I I
ASSOR1 I 8391 I 73436 I 13218468 1 13218468 I 4136 I 52138 I
I I I I I I
DATAR1 I 8391 I 163562 I 12267145 1 12267145 I 10796 I 126300 I
I I I I I I
WORKR1 I 8391 I 2000 I 119996 1 119996 I 13682 I 1565 I
I I I I I I
-------------------------------------------------------------------------------
File level extents are further below where you can see the allocations and block ranges:
*********************************
* *
* File 54 (V-CUST-NOTES ) * 2012-03-10 16:53:48
* *
*********************************
TOP-ISN = 363,598 Highest Index Level = 4
MAX-ISN Expected = 397,055 Padding Factor ASSO = 10%
Records Loaded = 363,598 Padding Factor DATA = 5%
MIN-ISN = 1 Length of Client NR = 0
MAX-ISN formatted = 397,055
Number of Updates = 389,454 ISNSIZE = 3
MAX COMP REC LEN = 10,792 Date Loaded = 1995-10-15
BLK/ADD DS EXT = 0 Time Loaded = 09:40:21
BLK/ADD UI EXT = 0 Date of last update = 2012-03-10
BLK/ADD NI EXT = 0 Time of last update = 08:56:49
ADAM File No DSF Utility change flags:
Ciphered File No Save entire Index = No
ISN Reusage Yes Save entire ADDR CONV = No
Space Reusage Yes Save entire DATA STOR = No
Coupled Files None 0 Blocks changed by utilities
Expanded File No
USERISN No
NOACEXTENSION No
MIXDSDEV No
PGMREFRESH No
Multi Client File No
Privileged usage No
Online INVERT None
Index Compressed Yes
Spanned Rec Supp No
Two Byte MU/PE No
LOB file No
LOB Fields No
RPLUPDATEONLY No
READONLY-MODE No
System Fields No
ADABAS version needed for this file: V71 or later
Free space available for file extents: At least 234 extents
List I Dev Block I Space Alloc. I From To I Unused Space I
Type I Type Lngth I Blocks Cyl I RABN RABN I Blocks Cyl I
I I I I I
-----I------------I------------------I---------------------I------------------I
I I I I I
AC I 8391 4136 I 384 2I 1338735 1339118I I
NI I 8391 4136 I 14308 79I 1339119 1353426I 3924 21I
UI I 8391 4136 I 457 2I 1353427 1353883I 182 1I
FDT I 8391 4136 I 4 0I 755 758I I
DSST I 8391 4136 I 3 0I 2996 2998I I
I I I I I
DS I 8391 10796 I 8962 119I 1678406 1687367I 881 11I
I I I I I
-------------------------------------------------------------------------------
Please provide that for source and target, your db versions for both, and your utility parms you are specifying.
That part in your document is just the overview of the available containers,
for the allocations for a specific file you will need to look for the sections I
pointed out earlier, either look for
***********************************
* *
* Physical Layout of the Database *
* *
***********************************
which details the allocation per volume, or the detail print for every file
will give you the exact block allocations, the latter will only be printed
when you do not run your ADAREP with the NOFILE parameter.
Based on your screenshots of ADAREP and the initial post, I think i know what is happening.
You are doing an:
ADASAV RESTORE FILE=55
You should use:
ADASAV RESTORE FMOVE=55
This will allow it to place the blocks where there is room in your target db. FILE= tries to put them in the exact same RABN range, and the block 1141755 must be occupied in your target.
I am confused by your comment. There’s nothing you need to change in db161. The thing you need to change is the utility you are running to do the restore from a backup (which is what I believe is going on).
We could make more progress if you provide your utility parms you are running, but my guess here is that you are running:
ADASAV RESTORE FILES=55
If so, please change your utility parms to say:
ADASAV RESTORE FMOVE=55
so that it cares not what file is stored in the specific block numbers that production happens to be allocated to.
From the information you highlighted in your screenshots only the last one (DS = Data Storage)
is Data, all other blocks are Associator, a description of the abbreviations (which I think anyone
with at least minimal knowledge of Adabas structures should be able to identify without having
to look them up) can be found here at the end of the section
I’m as confused as Brian is, to be honest, in the “From Blk” and “To Blk” columns
you see the exact physical block (RABN) locations of the various elements of
Data (only DS) and Asso (everything else) components, so I’m not sure what
questions this leaves open ?!?
You didn’t provide any information about your target db allocations for us to see what file is occupying the block in question (we know file 55 is occupying the source db rabn range), and you still haven’t provided the parms you are submitting for your restore job.
I am pretty sure my suggestion will fix your problem, but without you providing any more relevant info, I am not sure what more we can do to help.
Please try my suggestion and let me know how it goes.
