Currently I have one DCB DSORG=DA dataset to store data, for years... and this is about to reach current file allocation size limit of 4369 cylinders and I would need to increase that, however, when I try, I get the following error, even if I specify DSNTYPE=LARGE, which seems not to be accepted by DA:
Code:
REQUESTED SPACE EXCEEDS 65,535 TRKS
And unfortunately I can't change DSORG to PS, otherwise clear verbs and processes that use/consume this dataset no longer works.
I am currently studying the possibility of changing process to accept PS files, however that's going to take long and require many application changes... so I would like to check if there are any other alternative
As reference, this is the file allocation lastly used and working:
Thanks, Joerg. Do you think this is possible to convert BDAM to VSAM RRDS or other direct access structure? Would you have any tip on that if so?
I have been trying to split BDAM along volumes but it doesn't work, so I am now trying to change it to VSAM, but getting some errors.
Current BDAM details
Code:
HITTR LLDIR KEYLEN NUMINDEX BLKSIZE BLK/TRK CCHHR
74D202 1 19 158 16000 3 0028000001
EMPTY BLOCK TOTAL = 0
INDEX BLOCK TOTAL = 159
DATA BLOCK TOTAL = 89561
UNKWN BLOCK TOTAL = 0
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Joerg.Findeisen wrote:
Whatever application that is, you can't grow a DA dataset beyond 65535 Tracks.
I, too, fear this is correct.
But, what is the complete BDAM DCB in the program, used to read and write the BDAM data set.
In BDAM, there are several ways to access a record.
Relative record number.
Record address expressed as a TTR (which is where the 64K limit comes from.
Record addresss expressed as cccchhhhrr
Record key
As you may be aware, several years ago IDMS changed over to using EXCP instead of BDAM. Because of the way IDMS defines record addresses accessing records by relative record number seemed to me to be quite logical. Since, at least in theory, converting a relative record number to a TTR is very simple, my thought at the time IDMS wanted to cut out the middleman (in BDAM), but your difficulty suggests DSNTYPE=LARGE may have been the real reason.
You do have one other option: split the data base into multiple BDAM data sets. In essence, IDMS has been doing this for a long, long time.
I think you will have a great deal of difficulty converting the application to VSAM RRDS. The records are then addressed by the record's RBA, and there is no method to calculate an RBA from a record address when the data set contains mutilple CIs The RBA jumps in unpredictable way when jumping fo one CI to the next sequential CI.
