Moving from 3390-3 to 3390-9

, , , ,
1

Any gotchas in moving a DATA component from 3390-3 to 3390-9 devices on z/os? (ADABAS 7.4.3 and z/os 1.7)

The steps I have in mind are:

Run ADAFRM to allocate and format ADABAS.XXX.DATA.NEW with DSNTYPE=LARGE specified on DD (around 30 mod 3390-9 volumes)
Save current database (DATA component has 59 3390-3 volumes)
Rename ADABAS.XXX.DATA as ADABAS.XXX.DATA.OLD
Rename ADABAS.XXX.DATA.NEW as ADABAS.XXX.DATA
Restore database
Increase size (ADADBS INCREASE)

My understanding is that no changes should be required to existing JCL or parameters once the dataset has been created.

It

2

Hi,

We did this about one year ago, as described by Mark above, with no problems, and no additional work. One year later we are asking why load testing shows so much worse performance than it did a year ago.

From DASD performance data, it looks like the queuing for I/O is much worse on 3390-9 than on 3390-3. Makes sense: since we don’t have PAV (parallel access volumes) three times as much data is going to one volume as there was before. Under extreme loads, this has caused a backlog of I/O, resulting in a severe adabas thread shortage.

We are recommending reversion to mod 3, and will only reconsider mod 9 when we have Parallel Access Volumes available to us.

Has anyone else had a similar experience?

Frances

PS: Another gotcha with using mod 9’s is that if you have a mod 3 dataset, you can’t just add the mod 9 volume to the end since the dataset has to have been defined with DSNTYPE=LARGE in the first place. i.e. either add DDDATAR2 or rebuild the whole dataset as described by Mark above.

3

Ist diese Vorgehensweise analog für den Device Typ Wechsel von 2002 auf 2008?
Hintergrund: Wir brauchen mehr Platz, da Device 2002 nur 8K und 2008 hat schon 32K

1: ADAFRM mit dem neuen DEVICE Typ
2: ADASAV
3: ADARESTORE
4: ADADBS INCREASE

PS: Ich bin noch relativ neu auf diesem Gebiet und habe das noch nie gemacht, dies bitte bei euren Antworten berücksichtigen. Danke

4

Es sieht richtig aus. Auch wenn ich kenne Device Typen 2002 und 2008 nicht.

5

When moving from one hardware device type to another the ADASAV SAVE/RESTORE utility can be used, but when the logical device type of Adabas is going to change then then ADASAV SAVE/RESTORE does not work.

The data has to be either

  • file by file to be unloaded and loaded by ADAULD and ADALOD or ADAORD RESTRUCTUREF and ADAORD STORE
  • or the whole database can be unloaded with ADAORD RESTRUCTUREDB and loaded with ADAORD STORE ALLFILES

Following steps are recommended:

  • ADASAV of whole database (to have a backup, is not really needed any further)
  • ADAORD RESTRUCTUREDB (seq output file has to be big enough to contain the whole database)
  • ADAFRM with new device type (consider WORK device type to be large enough , maybe you use for this as well a new device type.
  • ADADEF with new device type and same CP file number as previous
  • ADAORD STORE ALLFILES

If you have a big database and cannot afford to be offline for a long time you might consider to add another DDATARx with the ADADBS ADD function and use for this new DATA device the new DEVICE type only. Files needing this DEVICE type can then be located on this DATA.

Also there the WORK dataset probably needs to be adjusted, but this is less downtime.

To change the WORK device you should format a new WORK with ADAFRM. Stop the database, run ADADEF NEWWORK supplying both WORK datasets and then start the database again with the new WORK dataset.

6

Vielen Dank Ursula für die ausführliche Antwort

7

We were provided 3390-9 volumes to add to our existing databases which use 3390-3 volumes. They are already formatted as device type 8391 which is valid for both kinds, and it has already been confirmed I can add these in with no issues and not even introducing a mixed DS type scenario.

I ran into trouble, though, when I went to format these. We like to do full-pack allocations because adding parts of volumes could lead to some bad results in case we ever needed to reformat the database again before doing a restore. With the 3390-3s, we would format a new container with something like:

//DDASSOR1 DD DSN=hlq.ASSOR1,SPACE=(3338,3338),VOL=SER=(xxxxxx,xxxxxx,xxxxxx,…)

To add space to an existing container, we would do something like:

//DDASSOR1 DD DSN=hlq.ASSOR1,SPACE=(0,3338),VOL=SER=(xxxxxx,xxxxxx,xxxxxx,…)

We would format or add space only in full pack increments.

Now, with the 3390-9s, there are 10016 cylinders available. However, I learned in trying this that this is invalid:

//DDASSOR2 DD DSN=hlq.ASSOR2,SPACE=(10016,10016),VOL=SER=(xxxxxx)

Primary extents are limited to 65,535 blocks which is just a fraction cylinder higher than 3338 cylinders. Ok, so I figured I should be able to revert back to:

//DDASSOR2 DD DSN=hlq.ASSOR2,SPACE=(3338,3338),VOL=SER=(xxxxxx)

3338*3 = 10014, so I would leave 2 cylinders on the table by doing this, but it should take 3 extents on each volume before jumping to the next one, right? Wrong! It formats the first 3338 cyl and then dies with a B37-04!

Is there any way with 3390-9s to make use of full pack allocations like we did before, since that is what I would ideally like to do? If not, how do I format these to make use of the most number of cylinders available on a 3390-9 device?

Thanks in advance!

-Brian

8

From a SAG SR, they recommended I add DSNTYPE=LARGE to the DD card that formats and catalogues the dataset.

I saw this mentioned at the top of this thread too but I am not familiar with it. Are there any other JCL coding considerations when using it or any gotchas?

If just adding this will let me code:

//DDASSOR2 DD DSN=hlq.ASSOR2,SPACE=(10016,10016),VOL=SER=(xxxxxx)

…then I should be ok, right?

-Brian

9

To further clarify, do I only need to add DSNTYPE=LARGE to the format step, or to every job that subsequently references this dataset (e.g. MPM nucleus proc, ADASAV DELTA jobs, ADAREPs, etc.).

Also, I would like to confirm there will be no issue with an Adabas nucleus which has:

//DDASSOR1 DISP=SHR,DSN=hlq.ASSOR1 /* has default DSNTYPE
//DDASSOR2 DISP=SHR,DSN=hlq.ASSOR2 /* has DSNTYPE=LARGE

-Brian

10

You would only need to specify DSNTYPE=LARGE when cataloguing the dataset, not when referencing with DISP=SHR or DISP=OLD. On further increases that involve a catalogue you may need to remember to add this.

11

Thanks for the feedback.

I tested an initial allocation of the new container with the DSNTYPE=LARGE parm and it worked fine allocating 10016 cyl. Also tested increasing space on an existing container and also had no issues. We should be good the next window we receive.

-Brian