ERROR-060, AC-Extent space allocation failed for file 55.

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         

Any help will be appreciated.

Thank You

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.


Graeme Lane

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

where should I check?


please find attached file which contains detail of two DB.


File 55 exit in DATA-BASE-161.

I was uploading file from DATA-BASE-161 to DATA-BASE-225 (test DB)
ADAREP.pdf (739 KB)

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.

How we check physical block number of Associator and data for file 55?


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

what about Physical Layout?
Does it gives physical block number of Associator and data for file 55?

Screen1.docx (38.1 KB)

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

Sorry Wolfgang for cross-posting. I am a bit slow today.

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.

What parameters do you run your ADAREP with ?

No problem at all, Brian :wink:


I have attached required info for ADREP161.




Thank You
Screen2.docx (95.5 KB)

Based on your screenshots of ADAREP and the initial post, I think i know what is happening.

You are doing an:


You should use:


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.


Please find attached Physical Layout of the Database.
I highlighted file 55 for your ease. I copied only file 55 info.

I need to find out the physical block number of Associator and data for file 55.



ADAREP161 is in our production and I do not have control to change any thing in it but I will share with my co worker.

PhysicalLayoutoftheDatabase.docx (138 KB)

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:


If so, please change your utility parms to say:


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 did check that.
Please see ADAREP file.

But I am looking for physical block number of particular file.
I think its give you info on Database level.


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.