The purpose of the information on this page is to report my efforts to evaluate the success or failure under MVS 3.8j of DASD types that have been made possible by the User Modifications originated by Jim Morrison in April, 2002, which were subsequently modified by Kevin Leonard, and, most recently, by Rob Prins. These modifications allow the use of DASD types in MVS 3.8j that were not available when MVS 3.8j was being sold and supported by IBM; in fact, these DASD types were all developed some time after MVS 3.8j was in use commercially. At the time MVS 3.8j was released, the 3350 was the latest model DASD provided by IBM. The User Modifications allow for MVS 3.8j to mount and recognize a significant group of DASD models that were developed years after MVS 3.8j was no longer IBM’s current Operating System, therefore MVS 3.8j was no longer being updated by IBM to recognize or support these modern DASD types.
In consideration of limitations in MVS 3.8j, it would seem relevant to only consider four specific models of the DASD enabled by the User Modification - the 3375, the 3380 model 1, the 3380 model 2, and the 3390 model 1. The reason for this is that in an unknown number of areas in the DASD control blocks of MVS 3.8j, the track address is stored in a signed half-word, which has a limit of 32,767. Hence the limit on DASD size is that the number of cylinders, when multiplied by the number of tracks per cylinder, must not exceed 32,767, or MVS 3.8j will fail, sometimes in minor ways and sometimes in very major ways. That said, you will see in the test series that follow below that I have chosen to also evaluate the usability of two DASD models that exceed this limitation: non-standard versions of the 3380-3 and the 3390-2. In the case of these two exceptions, it is possible to utilize them to achieve larger DASD capacity at the expense of sacrificing some functional capabilities.
The origin of the tests I am documenting here was a desire to answer the questions:
What is the largest DASD image that can be successfully used by MVS 3.8j?
Are the 3375/3380/3390 DASD reliable for use under MVS 3.8j?
For any DASD model that fails, under what condition(s) do they fail?
The four DASD models already mentioned - 3375, 3380-1, 3380-2, and 3390-1 - have a cylinder count that natively falls within the limit allowable by MVS 3.8j. However, since the utility supplied with Hercules for the creation of DASD images allows for custom sizes, I also wanted to determine if MVS 3.8j could use non-standard sized 3390-2 or 3380-3 that had been created with a custom size of 2,184 cylinders.
Note: If you read the sections below from top to bottom, as you would a book, you will see a great deal of repetition. That is because I mostly used the same programs and jobstreams, with modifications, for each test within a DASD model/type. However, I assumed most people would use this page as a reference resource, and would likely be reading only a single section at a time, hence the repetition of information. |
It should also be acknowledged that many people in the Hercules’ community, myself included, have been using several of these DASD models for all the various types of datasets that I will be testing below for some time. However, I don't know of anyone who has shared actual jobstreams or a process to demonstrate the outcomes of utilizing these DASD types under MVS 3.8j. Because the question was put to me by a couple of people, I elected to produce this page, showing the results of tests run on MVS 3.8j running under Hercules on my system.
Since a goal of at least some users of MVS 3.8j running under Hercules is to find the largest DASD on which data can be stored, I chose the 3390-2 as the first model to test. The standard 3390-2 has 2,226 cylinders, therefore the MVS 3.8j track address limit of 32,767 is immediately broken; because 2,226 cylinders, when multiplied by 15 tracks per cylinder is 33,390. I hoped that by creating a custom sized 3390-2, with only 2,184 cylinders, I could have a 3390-2 which would provide approximately 98% of the standard 3390-2 full capacity. A 3390-2 with 2,184 cylinders has a maximum track address of 32,760 (2,184 cylinders multiplied by 15 tracks per cylinder), which is within the 32,767 address limit.
MVS Device Support Facilities absolutely will not successfully initialize a non-standard size DASD image. Therefore it is necessary to use the Hercules dasdload utility to create the image, complete with Volume Table of Contents. The control file for dasdload I used is:
test01 3390-2 2184 sysvtoc vtoc trk 5 |
The output from executing dasdload with this control file was:
dasdload dasdload.ctlfile.txt test01.3390 2 Hercules DASD loader program Version 3.13 (c)Copyright 1999-2015 by Roger Bowler, Jan Jaeger, and others --------- test01 3390-2 2184 HHCDL006I Creating 3390 volume TEST01: 15 trks/cyl, 56832 bytes/track HHCDU044I Creating 3390 volume TEST01: 2184 cyls, 15 trks/cyl, 56832 bytes/track HHCDU041I 2184 cylinders successfully written to file test01.3390 HHCDA020I test01.3390 cyls=2184 heads=15 tracks=32760 trklen=56832 HHCDL009I Loading 3390 volume TEST01 --------- sysvtoc vtoc trk 5 HHCDL012I Creating dataset SYSVTOC at cyl 0 head 1 HHCDL013I Dataset SYSVTOC contains 5 tracks HHCDL057I VTOC starts at cyl 0 head 1 and is 5 tracks HHCDL014I Free space starts at cyl 0 head 6 HHCDL016I Total of 2184 cylinders written to test01.3390 |
You may notice that I have only allocated 5
tracks for the VTOC, which would be a severe under allocation for a
volume of this size. But, for testing, I wanted to have the
majority of the tracks on the DASD available to allocate to data in a
single dataset. The goals in the following tests are to see if
errors occur during allocating datasets, writing, and reading data from the
DASD.
I attached this DASD image to Hercules, varied it online to MVS, and mounted it as a private volume.
Because DASD volumes created with the dasdload utility force the VTOC convert routine to be run the first time the VTOC is updated, I allocated an empty dataset on the volume with IEFBR14, deleted the dataset, then produced a VTOC listing from the volume, which is available at: 3390-2_jcl_pdf/3390-2.emptyvtoc.pdf.
Goals:
create a single physical sequential dataset (DSORG=PS) utilizing as much of the available space on the test volume as possible,
fill that dataset with records of known content,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3390 was used to derive the optimum block size for 80 byte records:
Blocksize – 27,920 characters per block (98.5% track utilization)
Blocks per track – 2
Records per block – 349
Records per track – 698
On my 2,184 cylinder 3390-2 DASD, after allocating the VTOC, I had 32,754 tracks available, which will hold 22,862,892 records. The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from the dataset.
The jobstream for the test, with the COBOL program instream is available at: 3390-2_jcl_pdf/3390-2.ps.jcl. The SYSOUT for the job is available at: 3390-2_jcl_pdf/3390-2.ps.pdf. A VTOC list for the volume with the dataset on it is available at: 3390-2_jcl_pdf/3390-2.ps.vtoc.pdf.
The conclusion of this test is that a non-standard 3390-2 with the maximum number of possible cylinders of 2,184 can be successfully used to store physical sequential datasets.
Goals:
create a single partitioned dataset (DSORG=PO) utilizing as much of the available space on the test volume as possible,
create multiple members in the dataset, filling as much of the allocated space as possible,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3390 was used to derive the optimum block size for 80 byte records:
Blocksize – 27,920 characters per block (98.5% track utilization)
Blocks per track – 2
Records per block – 349
Records per track – 698
On my 2,184 cylinder 3390-2 DASD, after allocating the VTOC, I had 32,754 tracks available. I allocated 1 track to the directory of the PDS, and set the number of data records written to each of 6 members to 3,762,918. The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the member
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 25 records from each member.
The jobstream for the test, with the COBOL program instream is available at: 3390-2_jcl_pdf/3390-2.pds.jcl. The SYSOUT for the job is available at: 3390-2_jcl_pdf/3390-2.pds.pdf. A VTOC list for the volume with the dataset on it is available at: 3390-2_jcl_pdf/3390-2.pds.vtoc.pdf.
The conclusion of this test is that a non-standard 3390-2 with the maximum number of possible cylinders of 2,183 can be successfully used to store partitioned datasets.
Goals:
create a VSAM User Catalog on the volume,
create an Alias in the Master Catalog to catalog all datasets/VSAM objects created on the volume into the User Catalog on the volume.
The jobstream for the test is available at: 3390-2_jcl_pdf/3390-2.usercat.jcl.
Unfortunately, this task failed in a major way. After the job began executing, MVS completely locked up, requiring re-IPL. Following re-IPL, it appeared that some of the process for creating the User Catalog had been completed, as there was an entry in the VTOC for the non-standard 3390-2, but since it is impossible to view the output from the IDCAMS job to verify that the User Catalog was created with no errors, I decided to not continue further with this test.
The conclusion of this test is that a non-standard 3390-2 with the maximum number of possible cylinders of 2,183 can not be successfully used to contain a VSAM User Catalog.
Goals:
create multiple VSAM KSDS clusters on the volume, allocating space for the clusters from the unallocated space on the volume (the UNIQUE attribute during definition),
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
On my 2,184 cylinder 3390-2 DASD, after allocating the VTOC, I had 32,754 tracks available. My intention was to create and fill 3 clusters; by trial I determined I could write 4,132,788 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset (the key field for the Indexed Cluster)
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
Note: Since it was not possible to create a User Catalog on the volume, I have used a JOBCAT DD statement to utilize User Catalog UCPUB000 for this test.
The jobstream for the test, with the COBOL program instream is available at: 3390-2_jcl_pdf/3390-2.vsu.jcl. The SYSOUT for the job is available at: 3390-2_jcl_pdf/3390-2.vsu.pdf. The SYSOUT for the VTOC list for the volume with the datasets on it is available at: 3390-2_jcl_pdf/3390-2.vsu.vtoc.pdf.
The conclusion of this test is that a VSAM objects can be successfully allocated (unique) from available space on a non-standard 3390-2.
Goal:
create a VSAM Dataspace on the volume, to use all the available space.
Note: Since it was not possible to create a User Catalog on the volume, the Dataspace is catalogued in User Catalog UCPUB000.
The jobstream for defining the Dataspace is available at: 3390-2_jcl_pdf/3390-2.defspace.jcl. The SYSOUT for the job is available at: 3390-2_jcl_pdf/3390-2.defspace.pdf. A VTOC list for the volume with the Dataspace defined is available at: 3390-2_jcl_pdf/3390-2.defspace.vtoc.pdf.
The conclusion of this test is that a VSAM Dataspace can be successfully created on a non-standard 3390-2.
Goals:
create multiple VSAM ESDS clusters on the volume, sub-allocating space for the clusters from the Dataspace defined on the volume in the previous Test,
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
My intention was to create and fill 3 clusters; by trial I determined I could write 4,150,080 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
Note: Since it was not possible to create a User Catalog on the volume, I have used a JOBCAT DD statement to utilize User Catalog UCPUB000 for this test.
The jobstream for the test, with the COBOL program inline is available at: 3390-2_jcl_pdf/3390-2.vss.jcl. The SYSOUT for the job is available at: 3390-2_jcl_pdf/3390-2.vss.pdf.
This is the last test that requires this Dataspace, so I will delete it, along with the VSAM objects I have defined and loaded within the Dataspace. The jobstream for this is available at: 3390-2.delspace.jcl. The SYSOUT for the job is available at: 3390-2.delspace.pdf.
The conclusion of this test is that a VSAM objects can be successfully sub-allocated from Dataspace on a non-standard 3390-2.
Before I leave behind the Non-Standard DASD images, I opted to run tests on a 3380-3 created with a maximum of 2,184 cylinders. Since the standard 3380-3 has 2,655 cylinders, the MVS 3.8j track address limit of 32,767 is immediately broken, as 2,655 cylinders, when multiplied by 15 tracks per cylinder is 39,825. As with the Non-Standard 3390-2 above, limiting the cylinders to 2,184 gets the track address below that limit and gives a usable DASD volume that is 82% of the standard 3380-3 full capacity. The total storage in bytes is 300,998,880 less with the 3380-3 than the 3390-2, so likely anyone choosing to implement a Non-Standard size DASD, and consequently deal with the occasional irregularities, would probably choose the 3390-2; but I am going to include the testing here anyway.
As with the Non-Standard 3390-2, MVS Device Support Facilities absolutely will not successfully initialize the non-standard size DASD image. Therefore it is necessary to use the Hercules dasdload utility to create the image, complete with Volume Table of Contents. The control file for dasdload I used is:
test02 3380-3 2184 sysvtoc vtoc trk 5 |
The output from executing dasdload with this control file was:
dasdload dasdload.ctlfile.txt test02.3380 2 Hercules DASD loader program Version 3.13 (c)Copyright 1999-2015 by Roger Bowler, Jan Jaeger, and others --------- test01 3380-3 2184 HHCDL006I Creating 3380 volume TEST02: 15 trks/cyl, 47616 bytes/track HHCDU044I Creating 3380 volume TEST02: 2184 cyls, 15 trks/cyl, 47616 bytes/track HHCDU041I 2184 cylinders successfully written to file test02.3380 HHCDA020I test02.3380 cyls=2184 heads=15 tracks=32760 trklen=47616 HHCDL009I Loading 3380 volume TEST02 --------- sysvtoc vtoc trk 5 HHCDL012I Creating dataset SYSVTOC at cyl 0 head 1 HHCDL013I Dataset SYSVTOC contains 5 tracks HHCDL057I VTOC starts at cyl 0 head 1 and is 5 tracks HHCDL014I Free space starts at cyl 0 head 6 HHCDL016I Total of 2184 cylinders written to test02.3380 |
You may notice that I have only allocated 5 tracks for the VTOC, which would be a severe under allocation for a volume of this size. But, for testing, I wanted to have the majority of the tracks on the DASD available to allocate to data in a single dataset. The goals in the following tests are to see if errors occur during allocating datasets, writing, and reading data from the DASD.
I attached this DASD image to Hercules, varied it online to MVS, and mounted it as a private volume.
Because DASD volumes created with the dasdload utility force the VTOC convert routine to be run the first time the VTOC is updated, I allocated an empty dataset on the volume with IEFBR14, deleted the dataset, then produced a VTOC listing from the volume, which is available at: 3380-3_jcl_pdf/3380-3.empty.vtoc.pdf.
Goals:
create a single physical sequential dataset (DSORG=PS) utilizing as much of the available space on the test volume as possible,
fill that dataset with records of known content,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3380 was used to derive the optimum block size for 80 byte records:
Blocksize – 23,440 characters per block (98.7% track utilization)
Blocks per track – 2
Records per block – 293
Records per track – 586
On my 2,184 cylinder 3380-3 DASD, after allocating the VTOC, I had 32,754 tracks available, which will hold 19,193,844 records.
The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from the dataset.
The jobstream for the test, with the COBOL program inline is available at: 3380-3_jcl_pdf/3380-3.ps.jcl. The SYSOUT for the job is available at: 3380-3_jcl_pdf/3380-3.ps.pdf. A VTOC list for the volume with the dataset on it is available at: 3380-3_jcl_pdf/3380-3.ps.vtoc.pdf.
The conclusion of this test is that a non-standard 3380-3 with the maximum number of possible cylinders of 2,184 can be successfully used to store physical sequential datasets.
Goals:
create a single partitioned dataset (DSORG=PO) utilizing as much of the available space on the test volume as possible,
create multiple members in the dataset, filling as much of the allocated space as possible,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3380 was used to derive the optimum block size for 80 byte records:
Blocksize – 23,440 characters per block (98.7% track utilization)
Blocks per track – 2
Records per block – 293
Records per track – 586
On my 2,184 cylinder 3380-3 DASD, after allocating the VTOC, I had 32,754 tracks available. I allocated 1 track to the directory of the PDS, and set the number of data records written to each of 6 members to 3,198,876. The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the member
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 25 records from each member.
The jobstream for the test, with the COBOL program inline is available at: 3380-3_jcl_pdf/3380-3.pds.jcl. The SYSOUT for the job is available at: 3380-3_jcl_pdf/3380-3.pds.pdf. A VTOC list for the volume with the dataset on it is available at: 3380-3_jcl_pdf/3380-3.pds.vtoc.pdf.
The conclusion of this test is that a non-standard 3380-3 with the maximum number of possible cylinders of 2,184 can be successfully used to store partitioned datasets.
Goals:
create a VSAM User Catalog on the volume,
create an Alias in the Master Catalog to catalog all datasets/VSAM objects created on the volume into the User Catalog on the volume.
The jobstream for the test is available at: 3380-3_jcl_pdf/3380-3.usercat.jcl.
As with the 3390-2, this task failed in a major way. After the job began executing, MVS completely locked up, requiring re-IPL. Following re-IPL, it appeared that some of the process for creating the User Catalog had been completed, as there was an entry in the VTOC for the non-standard 3380-3, but since it is impossible to view the output from the IDCAMS job to verify that the User Catalog was created with no errors, I decided to not continue further with this test.
The conclusion of this test is that a non-standard 3380-3 with the maximum number of possible cylinders of 2,184 can not be successfully used to contain a VSAM User Catalog.
Goals:
create multiple VSAM KSDS clusters on the volume, allocating space for the clusters from the unallocated space on the volume (the UNIQUE attribute during definition),
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
On my 2,184 cylinder 3380-3 DASD, after allocating the VTOC, I had 32,754 tracks available. My intention was to create and fill 3 clusters; by trial I determined I could write 3,423,816 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset (the key field for the Indexed Cluster)
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
Note: Since it was not possible to create a User Catalog on the volume, I have used a JOBCAT DD statement to utilize User Catalog UCPUB000 for this test.
The jobstream for the test, with the COBOL program inline is available at: 3380-3_jcl_pdf/3380-3.vsu.jcl. The SYSOUT for the job is available at: 3380-3_jcl_pdf/3380-3.vsu.pdf. The SYSOUT for the VTOC list for the volume with the datasets on it is available at: 3380-3_jcl_pdf/3380-3.vsu.vtoc.pdf.
The conclusion of this test is that a VSAM objects can be successfully allocated (unique) from available space on a non-standard 3380-3.
Goal:
create a VSAM Dataspace on the volume, to use all the available space.
Note: Since it was not possible to create a User Catalog on the volume, the Dataspace is catalogued in User Catalog UCPUB000.
The jobstream for defining the Dataspase is available at: 3380-3_jcl_pdf/3380-3.defspace.jcl. The SYSOUT for the job is available at: 3380-3_jcl_pdf/3380-3.defspace.pdf. A VTOC list for the volume with the Dataspace defined is available at: 3380-3_jcl_pdf/3380-3.defspace.vtoc.pdf.
The conclusion of this test is that a VSAM Dataspace can be successfully created on a non-standard 3390-2.
Goals:
create multiple VSAM ESDS clusters on the volume, sub-allocating space for the clusters from the Dataspace defined on the volume in the previous Test,
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
My intention was to create and fill 3 clusters; by trial I determined I could write 3,428,532 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
Note: Since it was not possible to create a User Catalog on the volume, I have used a JOBCAT DD statement to utilize User Catalog UCPUB000 for this test.
The jobstream for the test, with the COBOL program inline is available at: 3380-3_jcl_pdf/3380-3.vss.jcl. The SYSOUT for the job is available at: 3380-3_jcl_pdf/3380-3.vss.pdf
This is the last test that requires this Dataspace, so I will delete it, along with the VSAM objects I have defined and loaded within the Dataspace. The jobstream for this is available at: 3380-3_jcl_pdf/3380-3.delspace.jcl. The SYSOUT for the job is available at: 3380-3_jcl_pdf/3380-3.delspace.pdf.
The conclusion of this test is that a VSAM objects can be successfully sub-allocated from Dataspace on a non-standard 3380-3.
MVS Device Support Facilities will be used to initialize the DASD volume, so the Hercules' dasdinit utility may be used to create the DASD image:
dasdinit -a test03.3390 3390 111111 HHCDU044I Creating 3390 volume 111111: 1114 cyls, 15 trks/cyl, 56832 bytes/track HHCDU041I 1114 cylinders successfully written to file test03.3390 HHCDI001I DASD initialization successfully completed. |
I attached this DASD image to Hercules, but did not vary it online to MVS, because it still must be initialized.
The jobstream to initialize the volume is available at: 3390-1_jcl_pdf/3390-1.ickdsf.jcl. The SYSOUT for the job is available at: 3390-1_jcl_pdf/3390-1.ickdsf.pdf.
You may notice that I have only allocated 5 tracks for the VTOC, which would be a severe under allocation for a volume of this size. But, for testing, I wanted to have the majority of the tracks on the DASD available to allocate to data in a single dataset. The goals in the following tests are to see if errors occur during allocating datasets, writing, and reading data from the DASD.
I varied the volume online to MVS and mounted it PRIVATE.
A VTOC listing for the empty volume is available at: 3390-1_jcl_pdf/3390-1.empty.vtoc.pdf
Goals:
create a single physical sequential dataset (DSORG=PS) utilizing as much of the available space on the test volume as possible,
fill that dataset with records of known content,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3390 was used to derive the optimum block size for 80 byte records:
Blocksize – 27,920 characters per block (98.5% track utilization)
Blocks per track – 2
Records per block – 349
Records per track – 698
On my 3390-1 DASD, after allocating the VTOC, I had 16,689 tracks available, which will hold 11,648,922 records.
The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from the dataset.
The jobstream for the test, with the COBOL program inline is available at: 3390-1_jcl_pdf/3390-1.ps.jcl. The SYSOUT for the job is available at: 3390-1_jcl_pdf/3390-1.ps.pdf. A VTOC list for the volume with the dataset on it is available at: 3390-1_jcl_pdf/3390-1.ps.vtoc.pdf.
The conclusion of this test is that a standard 3390-1 can be successfully used to store physical sequential datasets.
Goals:
create a single partitioned dataset (DSORG=PO) utilizing as much of the available space on the test volume as possible,
create multiple members in the dataset, filling as much of the allocated space as possible,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3390 was used to derive the optimum block size for 80 byte records:
Blocksize – 27,920 characters per block (98.5% track utilization)
Blocks per track – 2
Records per block – 349
Records per track – 698
On my 3390-1 DASD, after allocating the VTOC, I had 16,689 tracks available. I allocated 1 track to the directory of the PDS, and set the number of data records written to each of 6 members to 1,941,100. The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the member
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 25 records from each member.
The jobstream for the test, with the COBOL program inline is available at: 3390-1_jcl_pdf/3390-1.pds.jcl. The SYSOUT for the job is available at: 3390-1_jcl_pdf/3390-1.pds.pdf. A VTOC list for the volume with the dataset on it is available at: 3390-1_jcl_pdf/3390-1.pds.vtoc.pdf.
The conclusion of this test is that a standard 3390-1 can be successfully used to store partitioned datasets.
Goals:
create a VSAM User Catalog on the volume,
create an Alias in the Master Catalog to catalog all datasets/VSAM objects created on the volume into the User Catalog on the volume.
The jobstream for the test is available at: 3390-1_jcl_pdf/3390-1.usercat.jcl. The SYSOUT for the job is available at: 3390-1_jcl_pdf/3390-1.usercat.pdf. A VTOC list for the volume with the User Catalog on it is available at: 3390-1_jcl_pdf/3390-1.usercat.vtoc.pdf.
The conclusion of this test is that a standard 3390-1 can be successfully used to contain a VSAM User Catalog.
Goals:
create multiple VSAM KSDS clusters on the volume, allocating space for the clusters from the unallocated space on the volume (the UNIQUE attribute during definition),
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
On my 3390-1 DASD, after allocating the VTOC and the User Catalog, I had 16,689 tracks available. My intention was to create and fill 3 clusters; by trial I determined I could write 2,132,680 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset (the key field for the Indexed Cluster)
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
The jobstream for the test, with the COBOL program inline is available at: 3390-1_jcl_pdf/3390-1.vsu.jcl. The SYSOUT for the job is available at: 3390-1_jcl_pdf/3390-1.vsu.pdf. The SYSOUT for the VTOC list for the volume with the datasets on it is available at: 3390-1_jcl_pdf/3390-1.vsu.vtoc.pdf.
The conclusion of this test is that a VSAM objects can be successfully allocated (unique) from available space on a standard 3390-1.
Goal:
create a VSAM Dataspace on the volume, to use all the available space.
The jobstream for defining the Dataspase is available at: 3390-1_jcl_pdf/3390-1.defspace.jcl. The SYSOUT for the job is available at: 3390-1_jcl_pdf/3390-1.defspace.pdf.
The conclusion of this test is that a VSAM Dataspace can be successfully created on a standard 3390-1.
Goals:
create multiple VSAM ESDS clusters on the volume, sub-allocating space for the clusters from the Dataspace defined on the volume in the previous Test,
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
My intention was to create and fill 3 clusters; by trial I determined I could write 2,180,680 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
The jobstream for the test, with the COBOL program inline is available at: 3390-1_jcl_pdf/3390-1.vss.jcl. The SYSOUT for the job is available at: 3390-1_jcl_pdf/3390-1.vss.pdf.
This is the last test that requires this User Catalog and Dataspace, so I will delete the Alias, the User Catalog, and the Dataspace, along with the VSAM objects I have defined and loaded within the Dataspace. The jobstream for this is available at: 3390-1_jcl_pdf/3390-1.delspace.jcl. The SYSOUT for the job is available at: 3390-1_jcl_pdf/3390-1.delspace.pdf.
The conclusion of this test is that a VSAM objects can be successfully sub-allocated from Dataspace on a standard 3390-1.
MVS Device Support Facilities will be used to initialize the DASD volume, so the Hercules' dasdinit utility may be used to create the DASD image:
dasdinit -a test04.3380 3380 111111 HHCDU044I Creating 3380 volume 111111: 886 cyls, 15 trks/cyl, 47616 bytes/track HHCDU041I 886 cylinders successfully written to file test04.3380 HHCDI001I DASD initialization successfully completed. |
I attached this DASD image to Hercules, but did not vary it online to MVS, because it still must be initialized.
The jobstream to initialize the volume is available at: 3380-1_jcl_pdf/3380-1.ickdsf.jcl. The SYSOUT for the job is available at: 3380-1_jcl_pdf/3380-1.ickdsf.pdf.
You may notice that I have only allocated 5 tracks for the VTOC, which would be a severe under allocation for a volume of this size. But, for testing, I wanted to have the majority of the tracks on the DASD available to allocate to data in a single dataset. The goals in the following tests are to see if errors occur during allocating datasets, writing, and reading data from the DASD.
I varied the volume online to MVS and mounted it PRIVATE.
A VTOC listing for the empty volume is available at: 3380-1_jcl_pdf/3380-1.empty.vtoc.pdf.
Goals:
create a single physical sequential dataset (DSORG=PS) utilizing as much of the available space on the test volume as possible,
fill that dataset with records of known content,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3380 was used to derive the optimum block size for 80 byte records:
Blocksize – 23,440 characters per block (98.7% track utilization)
Blocks per track – 2
Records per block – 293
Records per track – 586
On my 3380-1 DASD, after allocating the VTOC, I had 13,269 tracks available, which will hold 7,775,634 records.
The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from the dataset.
The jobstream for the test, with the COBOL program inline is available at: 3380-1_jcl_pdf/3380-1.ps.jcl. The SYSOUT for the job is available at: 3380-1_jcl_pdf/3380-1.ps.pdf. A VTOC list for the volume with the dataset on it is available at: 3380-1_jcl_pdf/3380-1.ps.vtoc.pdf.
The conclusion of this test is that a standard 3380-1 can be successfully used to store physical sequential datasets.
Goals:
create a single partitioned dataset (DSORG=PO) utilizing as much of the available space on the test volume as possible,
create multiple members in the dataset, filling as much of the allocated space as possible,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3380 was used to derive the optimum block size for 80 byte records:
Blocksize – 23,440 characters per block (98.7% track utilization)
Blocks per track – 2
Records per block – 293
Records per track – 586
On my 3380-1 DASD, after allocating the VTOC, I had 13,269 tracks available. I allocated 1 track to the directory of the PDS, and set the number of data records written to each of 6 members to 1,295,640. The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the member
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 25 records from each member.
The jobstream for the test, with the COBOL program inline is available at: 3380-1_jcl_pdf/3380-1.pds.jcl. The SYSOUT for the job is available at: 3380-1_jcl_pdf/3380-1.pds.pdf. A VTOC list for the volume with the dataset on it is available at: 3380-1_jcl_pdf/3380-1.pds.vtoc.pdf.
The conclusion of this test is that a standard 3380-1 can be successfully used to store partitioned datasets.
Goals:
create a VSAM User Catalog on the volume,
create an Alias in the Master Catalog to catalog all datasets/VSAM objects created on the volume into the User Catalog on the volume.
The jobstream for the test is available at: 3380-1_jcl_pdf/3380-1.usercat.jcl. The SYSOUT for the job is available at: 3380-1_jcl_pdf/3380-1.usercat.pdf. A VTOC list for the volume with the User Catalog on it is available at: 3380-1_jcl_pdf/3380-1.usercat.vtoc.pdf.
The conclusion of this test is that a standard 3380-1 can be successfully used to contain a VSAM User Catalog.
Goals:
create multiple VSAM KSDS clusters on the volume, allocating space for the clusters from the unallocated space on the volume (the UNIQUE attribute during definition),
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
On my 3380-1 DASD, after allocating the VTOC and the User Catalog, I had 13,254 tracks available. My intention was to create and fill 3 clusters; by trial I determined I could write 1,386,504 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset (the key field for the Indexed Cluster)
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
The jobstream for the test, with the COBOL program inline is available at: 3380-1_jcl_pdf/3380-1.vsu.jcl. The SYSOUT for the job is available at: 3380-1_jcl_pdf/3380-1.vsu.pdf. The SYSOUT for the VTOC list for the volume with the datasets on it is available at: 3380-1_jcl_pdf/3380-1.vsu.vtoc.pdf.
The conclusion of this test is that a VSAM objects can be successfully allocated (unique) from available space on a standard 3380-1.
Goal:
create a VSAM Dataspace on the volume, to use all the available space.
The jobstream for defining the Dataspase is available at: 3380-1_jcl_pdf/3380-1.defspace.jcl. The SYSOUT for the job is available at: 3380-1_jcl_pdf/3380-1.defspace.pdf.
The conclusion of this test is that a VSAM Dataspace can be successfully created on a standard 3380-1.
Goals:
create multiple VSAM ESDS clusters on the volume, sub-allocating space for the clusters from the Dataspace defined on the volume in the previous Test,
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
My intention was to create and fill 3 clusters; by trial I determined I could write 1,386,504 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
The jobstream for the test, with the COBOL program inline is available at: 3380-1_jcl_pdf/3380-1.vss.jcl. The SYSOUT for the job is available at: 3380-1_jcl_pdf/3380-1.vss.pdf.
This is the last test that requires this User Catalog and Dataspace, so I will delete the Alias, the User Catalog, and the Dataspace, along with the VSAM objects I have defined and loaded within the Dataspace. The jobstream for this is available at: 3380-1_jcl_pdf/3380-1.delspace.jcl. The SYSOUT for the job is available at: 3380-1_jcl_pdf/3380-1.delspace.pdf.
The conclusion of this test is that a VSAM objects can be successfully sub-allocated from Dataspace on a standard 3380-1.
MVS Device Support Facilities will be used to initialize the DASD volume, so the Hercules' dasdinit utility may be used to create the DASD image:
dasdinit -a test05.3380 3380-2 111111 HHCDU044I Creating 3380 volume 111111: 1772 cyls, 15 trks/cyl, 47616 bytes/track HHCDU041I 1772 cylinders successfully written to file test05.3380 HHCDI001I DASD initialization successfully completed. |
I attached this DASD image to Hercules, but did not vary it online to MVS, because it still must be initialized.
The jobstream to initialize the volume is available at: 3380-2_jcl_pdf/3380-2.ickdsf.jcl. The SYSOUT for the job is available at: 3380-2_jcl_pdf/3380-2.ickdsf.pdf.
You may notice that I have only allocated 5 tracks for the VTOC, which would be a severe under allocation for a volume of this size. But, for testing, I wanted to have the majority of the tracks on the DASD available to allocate to data in a single dataset. The goals in the following tests are to see if errors occur during allocating datasets, writing, and reading data from the DASD.
I varied the volume online to MVS and mounted it PRIVATE.
A VTOC listing for the empty volume is available at: 3380-2_jcl_pdf/3380-2.empty.vtoc.pdf.
Goals:
create a single physical sequential dataset (DSORG=PS) utilizing as much of the available space on the test volume as possible,
fill that dataset with records of known content,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3380 was used to derive the optimum block size for 80 byte records:
Blocksize – 23,440 characters per block (98.7% track utilization)
Blocks per track – 2
Records per block – 293
Records per track – 586
On my 3380-2 DASD, after allocating the VTOC, I had 26,544 tracks available, which will hold 15,554,784 records.
The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from the dataset.
The jobstream for the test, with the COBOL program inline is available at: 3380-2_jcl_pdf/3380-2.ps.jcl. The SYSOUT for the job is available at: 3380-2_jcl_pdf/3380-2.ps.pdf. A VTOC list for the volume with the dataset on it is available at: 3380-2_jcl_pdf/3380-2.ps.vtoc.pdf.
The conclusion of this test is that a standard 3380-2 can be successfully used to store physical sequential datasets.
Goals:
create a single partitioned dataset (DSORG=PO) utilizing as much of the available space on the test volume as possible,
create multiple members in the dataset, filling as much of the allocated space as possible,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3380 was used to derive the optimum block size for 80 byte records:
Blocksize – 23,440 characters per block (98.7% track utilization)
Blocks per track – 2
Records per block – 293
Records per track – 586
On my 3380-2 DASD, after allocating the VTOC, I had 26,544 tracks available. I allocated 1 track to the directory of the PDS, and set the number of data records written to each of 6 members to 2,592,160. The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the member
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 25 records from each member.
The jobstream for the test, with the COBOL program inline is available at: 3380-2_jcl_pdf/3380-2.pds.jcl. The SYSOUT for the job is available at: 3380-2_jcl_pdf/3380-2.pds.pdf. A VTOC list for the volume with the dataset on it is available at: 3380-2_jcl_pdf/3380-2.pds.vtoc.pdf.
The conclusion of this test is that a standard 3380-2 can be successfully used to store partitioned datasets.
The goal is to verify that a VSAM User Catalog could be created on the DASD volume, with an ALIAS in the Master Catalog pointing to the User Catalog for High Level Qualifier of the Volume Serial Number.
The jobstream for the test is available at: 3380-2_jcl_pdf/3380-2.usercat.jcl.
As with both the non-standard 3390-2 and 3380-3, this task failed in a major way. After the job began executing, MVS completely locked up, requiring re-IPL. Following re-IPL, it appeared that some of the process for creating the User Catalog had been completed, as there was an entry in the VTOC for the TEST05 volume, but since it is impossible to view the output from the IDCAMS job to verify that the User Catalog was created with no errors, I decided to not continue further with this test.
The conclusion of this test is that a standard 3380-2 can not be successfully used to contain a VSAM User Catalog.
Goals:
create multiple VSAM KSDS clusters on the volume, allocating space for the clusters from the unallocated space on the volume (the UNIQUE attribute during definition),
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
On my 3380-2 DASD, after allocating the VTOC, I had 26,544 tracks available. My intention was to create and fill 3 clusters; by trial I determined I could write 2,773,008 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset (the key field for the Indexed Cluster)
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
Note: Since it was not possible to create a User Catalog on the volume, I have used a JOBCAT DD statement to utilize User Catalog UCPUB000 for this test.
The jobstream for the test, with the COBOL program inline is available at: 3380-2_jcl_pdf/3380-2.vsu.jcl. The SYSOUT for the job is available at: 3380-2_jcl_pdf/3380-2.vsu.pdf. The SYSOUT for the VTOC list for the volume with the datasets on it is available at: 3380-2_jcl_pdf/3380-2.vsu.vtoc.pdf.
The conclusion of this test is that a VSAM objects can be successfully allocated (unique) from available space on a standard 3380-2.
The goal is to verify that a VSAM Dataspace can be created on the non-standard 3390-2. This is a precursor to creating, writing to, and reading from VSAM objects sub-allocated within the Dataspace on the DASD volume.
Since the creation of a User Catalog on the volume failed, the Dataspace is catalogued in User Catalog UCPUB000.
The jobstream for defining the Dataspace is available at: 3380-2_jcl_pdf/3380-2.defspace.jcl. The SYSOUT for the job is available at: 3380-2_jcl_pdf/3380-2.defspace.pdf. A VTOC list for the volume with the Dataspace defined is available at: 3380-2_jcl_pdf/3380-2.defspace.vtoc.pdf.
The conclusion of this test is that a VSAM Dataspace can be successfully created on a standard 3380-2.
Goals:
create multiple VSAM ESDS clusters on the volume, sub-allocating space for the clusters from the Dataspace defined on the volume in the previous Test,
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
My intention was to create and fill 3 clusters; by trial I determined I could write 2,773,008 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
Since the creation of a User Catalog on the volume failed, the Dataspace is catalogued in User Catalog UCPUB000.
The jobstream for the test, with the COBOL program inline is available at: 3380-2_jcl_pdf/3380-2.vss.jcl. The SYSOUT for the job is available at: 3380-2_jcl_pdf/3380-2.vss.pdf.
This is the last test that requires this Dataspace, so I will delete it, along with the VSAM objects I have defined and loaded within the Dataspace. The jobstream for this is available at: 3380-2_jcl_pdf/3380-2.delspace.jcl. The SYSOUT for the job is available at: 3380-2_jcl_pdf/3380-2.delspace.pdf.
The conclusion of this test is that a VSAM objects can be successfully sub-allocated from Dataspace on a standard 3380-2.
MVS Device Support Facilities will be used to initialize the DASD volume, so the Hercules' dasdinit utility may be used to create the DASD image:
dasdinit -a test06.3375 3375 111111 HHCDU044I Creating 3375 volume 111111: 962 cyls, 12 trks/cyl, 35840 bytes/track HHCDU041I 962 cylinders successfully written to file test06.3375 HHCDI001I DASD initialization successfully completed. |
I attached this DASD image to Hercules, but did not vary it online to MVS, because it still must be initialized.
The jobstream to initialize the volume is available at: 3375_jcl_pdf/3375.ickdsf.jcl. The SYSOUT for the job is available at: 3375_jcl_pdf/3375.ickdsf.pdf.
You may notice that I have only allocated 5 tracks for the VTOC, which would be a severe under allocation for a volume of this size. But, for testing, I wanted to have the majority of the tracks on the DASD available to allocate to data in a single dataset. The goals in the following tests are to see if errors occur during allocating datasets, writing, and reading data from the DASD.
I varied the volume online to MVS and mounted it PRIVATE.
A VTOC listing for the empty volume is available at: 3375_jcl_pdf/3375.empty.vtoc.pdf.
Goals:
create a single physical sequential dataset (DSORG=PS) utilizing as much of the available space on the test volume as possible,
fill that dataset with records of known content,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3375 was used to derive the optimum block size for 80 byte records:
Blocksize – 17,600 characters per block (98.8% track utilization)
Blocks per track – 2
Records per block – 220
Records per track – 440
On my 3375 DASD, after allocating the VTOC, I had 11,502 tracks available, which will hold 5,060,880 records.
The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from the dataset.
The jobstream for the test, with the COBOL program inline is available at: 3375_jcl_pdf/3375.ps.jcl. The SYSOUT for the job is available at: 3375_jcl_pdf/3375.ps.pdf. A VTOC list for the volume with the dataset on it is available at: 3375_jcl_pdf/3375.ps.vtoc.pdf.
The conclusion of this test is that a standard 3375 can be successfully used to store physical sequential datasets.
Goals:
create a single partitioned dataset (DSORG=PO) utilizing as much of the available space on the test volume as possible,
create multiple members in the dataset, filling as much of the allocated space as possible,
read the records back and compare the content to what was expected to have been written.
The TSO command BLK3375 was used to derive the optimum block size for 80 byte records:
Blocksize – 17,600 characters per block (98.8% track utilization)
Blocks per track – 2
Records per block – 220
Records per track – 440
On my 3375 DASD, after allocating the VTOC, I had 11,502 tracks available. I allocated 1 track to the directory of the PDS, and set the number of data records written to each of 6 members to 843,040. The format of the 80 character record I am writing is:
columns 1 through 9 - sequence number of the record within the member
column 10 - blank
columns 21 through 80 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 25 records from each member.
The jobstream for the test, with the COBOL program inline is available at: 3375_jcl_pdf/3375.pds.jcl. The SYSOUT for the job is available at: 3375_jcl_pdf/3375.pds.pdf. A VTOC list for the volume with the dataset on it is available at: 3375_jcl_pdf/3375.pds.vtoc.pdf.
The conclusion of this test is that a standard 3375 can be successfully used to store partitioned datasets.
Goals:
create a VSAM User Catalog on the volume,
create an Alias in the Master Catalog to catalog all datasets/VSAM objects created on the volume into the User Catalog on the volume.
The jobstream for the test is available at: 3375_jcl_pdf/3375.usercat.jcl. The SYSOUT for the job is available at: 3375_jcl_pdf/3375.usercat.pdf. A VTOC list for the volume with the User Catalog on it is available at: 3375_jcl_pdf/3375.usercat.vtoc.pdf.
The conclusion of this test is that a standard 3380-1 can be successfully used to contain a VSAM User Catalog.
Goals:
create multiple VSAM KSDS clusters on the volume, allocating space for the clusters from the unallocated space on the volume (the UNIQUE attribute during definition),
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
On my 3375 DASD, after allocating the VTOC and the User Catalog, I had 11,487 tracks available. My intention was to create and fill 3 clusters; by trial I determined I could write 999,790 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset (the key field for the Indexed Cluster)
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
The jobstream for the test, with the COBOL program inline is available at: 3375_jcl_pdf/3375.vsu.jcl. The SYSOUT for the job is available at: 3375_jcl_pdf/3375.vsu.pdf. The SYSOUT for the VTOC list for the volume with the datasets on it is available at: 3375_jcl_pdf/3375.vsu.vtoc.pdf.
The conclusion of this test is that a VSAM objects can be successfully allocated (unique) from available space on a standard 3375.
Goal:
create a VSAM Dataspace on the volume, to use all the available space.
The jobstream for defining the Dataspase is available at: 3375_jcl_pdf/3375.defspace.jcl. The SYSOUT for the job is available at: 3375_jcl_pdf/3375.defspace.pdf.
The conclusion of this test is that a VSAM Dataspace can be successfully created on a standard 3375.
Goals:
create multiple VSAM ESDS clusters on the volume, sub-allocating space for the clusters from the Dataspace defined on the volume in the previous Test,
fill the clusters with records of known content,
read the records back and compare the content to what was expected to have been written.
My intention was to create and fill 3 clusters; by trial I determined I could write 999,790 records into each cluster. The format of the 125 character record I am writing is:
columns 1 through 9 - sequence number of the record within the dataset
column 10 - blank
columns 21 through 125 - rotating fill sequence, record #1 contains all A's, record #2 contains all B's, record #3 contains all C's ...
The final step of the job utilizes IDCAMS to print the last 50 records from each cluster.
The jobstream for the test, with the COBOL program inline is available at: 3375_jcl_pdf/3375.vss.jcl. The SYSOUT for the job is available at: 3375_jcl_pdf/3375.vss.pdf.
This is the last test that requires this User Catalog and Dataspace, so I will delete the Alias, the User Catalog, and the Dataspace, along with the VSAM objects I have defined and loaded within the Dataspace. The jobstream for this is available at: 3380-1_jcl_pdf/3380-1.delspace.jcl. The SYSOUT for the job is available at: 3380-1_jcl_pdf/3380-1.delspace.pdf.
The conclusion of this test is that a VSAM objects can be successfully sub-allocated from Dataspace on a standard 3375.
|
3390-2 |
3380-3 |
3390-1 |
3380-1 |
3380-2 |
3375 |
Sequential Dataset |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
Partitioned Dataset |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
VSAM User Catalog |
*failed* |
*failed* |
*succeeded* |
*succeeded* |
*failed* |
*succeeded* |
VSAM Dataspace |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
VSAM Objects sub-allocated |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
VSAM Objects unique |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
*succeeded* |
I hope that you have found my instructions useful. If you have questions that I can answer to help expand upon my explanations and examples shown here, please don't hesitate to send them to me:
Return to Site Home Page Frequently Asked Questions
This page was last updated on February 21, 2025 .