In order to create new DASD volumes on your MVS system, you need to complete three tasks:
create a DASD image in a file on the host operating system,
attach the DASD image to your Hercules' configuration, either dynamically or in the Hercules' configuration file, and
initialize the DASD image for use by MVS.
To create the DASD image, you will need to execute the dasdinit program in a console window (LINUX) or Command Prompt window (Windows). The dasdinit executable is included in the Hercules distribution package. The command format is:
dasdinit -a <filename> <devtype> <volser>
The -a parameter instructs dasdinit to create alternate tracks in the DASD image. Alternate tracks on physical devices are used for error recovery when bad tracks are encountered during I/O operations. Although alternate tracks are not utilized under Hercules' emulation, most MVS utilities and programs will not function properly, if at all, without the presence of the alternate tracks.
The <filename> parameter provides the name of the file on the host operating system (Linux, Windows, etc) in which the DASD image will be written. Note that dasdinit will not overwrite an existing file, so the name specified must not refer to an existing file.
A convention used by some is to use the volume serial number as the name of the file and the address at which the DASD is attached as the extension, for example:
Another convention is to use the volume serial number as the name of the file and the DASD type as the extension, for example:
Whatever naming convention you choose to use for the host operating system file is up to you.
The <devtype> parameter specifies the type of DASD image: 2314, 3330, 3350, etc. Some of the device types have several different models, which are specified differently for the dasdinit utility and in the UNIT parameter on an MVS DD statement:
Device and Model Description dasdinit model specification MVS UNIT specification 3330 model 1 (404 data cylinders) 3330 3330 3330 model 2 (808 data cylinders) 3330-2 3330-1 3340 model 35 (348 data cylinders) 3340 3340 3340 model 70 (696 data cylinders) 3340-70 3340 There are also various models of the 3380 and 3390, but anything above the first model approaches/exceeds maximum host file size, so I choose
to stick to only the first model of each.
The <volser> parameter specifies the volume serial number written to the DASD image and provides the means for MVS to uniquely identify each volume from other DASD volumes. There must not be multiple DASD volumes visible to MVS with the same volume serial number. Since the initialization process (task three in the list above) will rewrite the volume serial number, I usually specify SCRTCH or 111111 as the volume serial number to dasdinit, and then assign the volume serial number that I plan to use for the volume during the initialization on the MVS system.
An extensive table of DASD
geometry information, which includes the number of data and alternate cylinders,
is available in message
#2833. A second source of geometry information is the table available
from the files section in disk-sizes.txt.
Beginning with version 2.17 of Hercules, it is not really necessary to know the
number of cylinders present in each of the DASD types, but these tables are
available if you would like to know how much storage is available for each of
In order to attach an emulated device to Hercules while it is running, you will need to be in the text console display because there is no equivalent command in the graphical display. The command syntax is:
attach <address> <devtype> <filename> [cu=3880]
The <address> parameter specifies the hardware address at which the device is to be attached and consists of the Channel and Unit Address (cuu). The address you use will depend upon the configuration that was specified during System Generation and must be an available address generated for the type of device you are attempting to attach (ie, if the device you are attempting to attach is a 3330 DASD, the address you use must have been generated for a 3330 DASD).
The <devtype> parameter specifies the type of DASD image: 2314, 3330, 3350, etc. For the 3330 (and 3340, both of which has a sub-model with very different capacities), it doesn't seem to matter to Hercules whether the DASD image specified with <devtype> 3330 is the 3330-1 or 3330-11 (or <devtype> 3340 is the 3340-35 or 3340-70); MVS does just fine with a plain old 3330 specified here.
The <filename> parameter provides the name of the file on the host operating system in which the DASD image is contained (where it was written by dasdinit). Note that if you are using a directory structure to organize your DASD files in a subdirectory beneath the directory where Hercules was started, you will need to include a path designation. Since my DASD image files are contained in the 'dasd' subdirectory under the directory where I start Hercules, my filenames are in the form of:
The separator characters in the path name may be either a forward slash (/) or a backward slash (\). Even though I am now using Windows, since I used LINUX for a number of years, I typically use the forward slash.
The cu=3880 parameter is required for 3390 type DASD and specifies that the device controller to be emulated for the device should be a model 3880. The default device controller chosen by Hercules will cause some errors from MVS utilities.
In order to permanently add an emulated DASD volume to Hercules, you will need to add a line to your Hercules configuration file referencing the volume. The syntax of this line is:
<address> <devtype> <filename> [cu=3880]
Because the DASD needs to be initialized before it can be used
by MVS, I prefer to dynamically add a DASD device, initialize it, and then make
the addition of the device to the configuration file. This avoids any
problems that might be caused by MVS attempting to access an un-initialized DASD
volume during IPL.
Although the dasdinit program creates the DASD image, MVS requires additional information that is not written by dasdinit, specifically a Volume Table of Contents (VTOC) needs to be written to the image. To accomplish that, you need to use ICKDSF to initialize the volume before it is placed online for use by MVS programs.
The version of ICKDSF that installs by default with MVS 3.8 is Release 6. That version of ICKDSF will not initialize 3380 or 3390 device types. However, on the same product tape, there is included Release 13 of ICKDSF. The catch is that Release 13 will not initialize 3340 or 3350 device types without reporting an error; the error doesn't seem to hinder the initialization, but it is disconcerting to see. If you have followed my instructions for installing MVS 3.8j, you will have both versions of ICKDSF on your system. If you did not, you can grab the jobstream fdz1d02 from the installmvs.rar archive and the product tape from the distribution tapes archive and run that job to install ICKDSF Release 13 into your SYS1.LINKLIB under the name ICKDSF13, which will happily reside alongside the Release 6 version which is of course stored as just ICKDSF. Then it is simply a matter of modifying the EXEC statement in the job you use to initialize DASD volumes to ensure that you are executing the correct version for the type of DASD you intend to initialize.
In order to use either version of ICKDSF, the volume(s) to be initialized must be offline. If you have dynamically added the volume to Hercules while MVS is already running under Hercules, the volume is 'offline' by default. However, if you added the volume to the configuration file and IPLed MVS, you will need to vary the device offline. On the MVS console, enter these two commands:
v <address>,offline s dealloc
The <address> parameter specifies the address of the DASD
device to be placed in offline status. The second command starts a
cataloged procedure which runs IEFBR14 to allow MVS to process the vary command
and place the volume offline
The JCL to initialize a 3340 or 3350 DASD volume is:
//ICKDSF JOB (1),ICKDSF,CLASS=A,MSGCLASS=X //ICKDSF EXEC PGM=ICKDSF,REGION=4096K //SYSPRINT DD SYSOUT=* //SYSIN DD * INIT UNITADDRESS(<address>) NOVERIFY VOLID(<volser>) OWNER(HERCULES) - VTOC(0,1,<extent>) /* //
The JCL to initialize any type of DASD volume other than 3340 or 3350 is:
//ICKDSF JOB (1),ICKDSF,CLASS=A,MSGCLASS=X //ICKDSF EXEC PGM=ICKDSF13,REGION=4096K //SYSPRINT DD SYSOUT=* //SYSIN DD * INIT UNITADDRESS(<address>) NOVERIFY VOLID(<volser>) OWNER(HERCULES) - VTOC(0,1,<extent>) /* //
The <address> parameter in the control card specifies the address at which the DASD image to be initialized is attached to Hercules.
The <volser> parameter specifies the volume serial number to be written to the pack.
The <extent> sub-parameter specifies how many tracks to allocate to the VTOC. I typically allocate an entire cylinder to the VTOC, which is more than adequate and may actually be overkill. The other positional sub-parameters in the VTOC parameter specify the cylinder and head, respectively, where the VTOC is to start. On physical disks, it was common practice to locate the VTOC in the middle of the volume for performance considerations. But under Hercules it is acceptable to place the VTOC at track 1. Note that track 0 is reserved for the volume serial number and so must not be used as the VTOC beginning address.
The JCL should be modified to meet your requirements and submitted to MVS. You will be asked to confirm that you actually want to initialize the volume at the address specified:
*06 ICK003D REPLY U TO ALTER VOLUME 253 CONTENTS, ELSE T
The reply of 'U' allows the initialization to proceed. There will be a number of informational messages printed in the SYSPRINT output during the executing of ICKDSF. The most important thing to verify is that the return code for the job is 0000.
After the volume is initialized, it must be placed online before MVS will be able to utilize the volume. On the MVS console issue the command:
v <address>,online m <address>,vol=(sl,<volser>),use=<useclass>
The <address> parameter specifies the address of the DASD device to be placed in online status.
The <volser> parameter specifies the volume serial number of the volume.
The <useclass> parameter should specify STORAGE, PUBLIC, or PRIVATE. A description of these use attributes is included below under Storage Use Classes.
If this is to be a permanent addition to your configuration, you
should add the volume to the VATLST member in SYS1.PARMLIB. The procedure
to accomplish this is discussed below.
The VATLST00 member of SYS1.PARMLIB controls the mounting of DASD volumes at IPL. Each line of this member contains the information pertaining to a single DASD volume. You will need to add an entry (a line containing five parameters) for each DASD volume you add to your system.
If you have TSO installed on your system, you can easily edit this member to make the addition. If you do not have TSO installed, you will have to use the MVS utility IEBUPDTE to make the changes. I will describe the process to use if TSO is not installed as that is the more difficult process. First you need to find out the current contents of VATLST00 and for that you can use the IEBPTPCH utility:
//IEBPTPCH JOB CLASS=A,MSGLEVEL=(1,1) //IEBPTPCH EXEC PGM=IEBPTPCH //SYSPRINT DD SYSOUT=A //SYSUT1 DD DSN=SYS1.PARMLIB(VATLST00),DISP=SHR //SYSUT2 DD SYSOUT=A //SYSIN DD * PRINT MAXFLDS=1 RECORD FIELD=(80) /* //
For my system, this produces the following output:
MVSRES,0,2,3350 ,Y SYSTEM RESIDENCE (PRIVATE) 00000001 PAGE00,0,2,3350 ,Y PAGE DATASETS (PRIVATE) 00000006 SMP001,1,1,3350 ,N DISTRIBUTION LIBRARIES (PUBLIC) 00000011 SPOOL1,0,2,3350 ,Y JES2 DATASETS (PRIVATE) 00000016 WORK01,1,1,3330 ,N WORK PACK (PUBLIC) 00000021 WORK02,1,0,3350 ,N WORK PACK (STORAGE) 00000026 MVS601,1,1,3330-1 ,N WORK PACK (PUBLIC) 00000031
Note that the numbers in columns 73 through 80 are sequence numbers. The parameters specified for each volume are:
Columns 1 through 6 (six characters) contain the volume serial number.
Column 8 (one character) is 0 for permanently resident volumes, and 1 for reserved volumes. These states are no longer very relevant, and you can use 0 in most cases.
Column 10 (one character) is the use attribute. STORAGE is denoted by 0, PUBLIC by 1, and PRIVATE by 2. A description of these use attributes is included below under Storage Use Classes.
Columns 12 through 19 (eight characters, left justified) is the device type. MVS will probe the device at IPL time and if the device it finds with this volume serial number is not the device type specified here, MVS will dismount the volume. If you have the next parameter as Y and this happens, MVS will stop until you mount the correct volume type with this volume serial number; an entry of N will let MVS proceed after dismounting the incorrect volume.
Column 21 (one character) indicates whether the operator should be requested to mount the volume if it is not found during IPL. In most cases you should specify N (for NO) in this column.
Columns 23 through 71 may be used for comments.
In order to add a new 3350 work volume to the VATLST00 entries shown above using IEBUPDTE, the following job would be used:
//IEBUPDTE JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //IEBUPDTE EXEC PGM=IEBUPDTE,REGION=1024K //* //SYSUT1 DD DSN=SYS1.PARMLIB,DISP=SHR //SYSUT2 DD DSN=SYS1.PARMLIB,DISP=MOD //SYSPRINT DD SYSOUT=A //SYSIN DD * ./ CHANGE NAME=VATLST00,LIST=ALL WORK03,1,0,3350 ,N WORK PACK (STORAGE) 00000031 ./ ENDUP //
The sequence number of the card to be added (columns 73 through 80) is 00000031, which directs IEBUPDTE to place this new line following the lines already present in the VATLST00 member.
At the next IPL after submission of this job, MVS will look for
a 3350 volume with the volume serial number WORK03 and the volume will be made
available as a STORAGE volume.
A DASD volume is always mounted with one of the following use attributes:
PRIVATE - new datasets will be created on this volume only if the user (via JCL or the TSO ALLOCATE command) specifies the volume serial of this disk volume.
PUBLIC - MVS may place a temporary dataset on this volume, if the user (via JCL or otherwise) did not specify a volume serial for the temporary dataset. Datasets may also be placed on the volume by specifying the volume serial, as with PRIVATE volumes. A temporary dataset is one with a DSNAME beginning with an ampersand and/or with a disposition equivalent to NEW,DELETE.
STORAGE - MVS places permanent datasets on this volume if the user did not supply a volume serial for the datasets. In addition, temporary datasets and datasets placed by volume serial may also be placed on the volume.
Generally, when you are adding new storage space to the system, it is also a good time to think about how that storage space will integrate with the catalog structure you have in place for the system. So I will include an overview of User Catalogs here.
During the System Generation, a VSAM Master Catalog was created. It resides on MVSRES and the dataset name of the catalog itself is SYS1.VSAM.MASTER.CATALOG. Although you can continue to catalog any new datasets you create in the Master Catalog, it is not considered a good practice and would undoubtedly not be allowed in any real world shop.
In my experience, shops set up user catalogs that group datasets either by project - payroll, accounts receivable, budget, etc - or by location, i.e. the DASD volume on which the dataset resides determines the user catalog into which the dataset is catalogued. The structure of catalogs you set up for your system is up to you, but I will describe here the way I have set mine up as a guide. Keep in mind that what I am documenting here is relevant to the status of my system as I am currently rebuilding it (and updating this documentation, as well) and may not exactly match the configuration referred to and/or documented in other pages on this site. Nor will it stay static for me ... it will change and grow as I add volumes. This is only to show you how to go about setting your own system up.
First, I should say that "behind the scenes" I have created the following DASD volumes in addition to those that were created as I went through the SMP/SYSGEN processes:
PUB000 - 3380 primarily for TSO User datasets
PUB001 - 3390 with 50% allocated to a large VSAM Data Space for User clusters and 50% for User Datasets
MVS370 - 3375 for system storage
MVS380 - 3380 for system storage
SYSP01 - 3380 for all the datasets related to setting up my system, which I preserve across system rebuilds
SORTWK1 through SORTWK6 - 2314s for the MVT Sort utility
I decided to create two new User Catalogs - UCPUB000 into which all datasets created on PUB000 will be catalogued, and UCPUB001 into which all datasets created on PUB001 will be cataloged. The 'Systems Programming' volume - SYSP01 - has its own User Catalog (UCSYSP01 into which all datasets residing on SYSP01 are cataloged. As you can see, this leaves some volumes not specifically planned for, but a JOBCAT or STEPCAT card can be utilized to select the catalog explicitly, overriding automatic catalog selection based upon Alias information. The important thing that this process is to accomplish is to set up alternatives to control unchecked use of the Master Catalog for all user datasets. The names I have chosen for the user catalogs reflect mnemonically that they are user catalogs - UC as the first two characters of the name - and indicate the connection to the datasets which will be cataloged within them with the remainder of the name. The user catalogs themselves will be cataloged in the Master Catalog.
This is the jobstream that I used to create the User Catalogs and set up Aliases for them:
//DEFUCATS JOB 'JAY MOSELEY',CLASS=A,MSGLEVEL=(1,1),MSGCLASS=A //IDCAMS EXEC PGM=IDCAMS,REGION=4096K //SYSPRINT DD SYSOUT=* //PUB000 DD UNIT=3380,VOL=SER=PUB000,DISP=OLD //PUB001 DD UNIT=3390,VOL=SER=PUB001,DISP=OLD //SYSIN DD */* This User Catalog will contain NON-VSAM datasets that */ /* reside on volume PUB000. */ DEFINE USERCATALOG ( - NAME (UCPUB000) - VOLUME (PUB000) - CYLINDERS (20) - FOR (9999) - BUFFERSPACE (8192) ) /* An Alias is defined so that all datasets with a high- */ /* level qualifier of PUB000 will be catalogued in the */ /* User Catalog UCPUB000. */ DEFINE ALIAS ( - NAME (PUB000) - RELATE (UCPUB000) ) /* This User Catalog will contain NON-VSAM and VSAM objects */ /* that reside on volume PUB001. Half of the volume will be */ /* allocated at the same time for use as a VSAM Dataspace. */ /* The User Catalog is sub-allocated from that Dataspace. */ DEFINE USERCATALOG ( - NAME (UCPUB001) - VOLUME (PUB001) - CYLINDERS (556) - FOR (9999) - BUFFERSPACE (8192) ) - DATA (CYLINDERS (30) ) - INDEX (CYLINDERS (15) ) /* An Alias is defined so that all datasets and VSAM objects */ /* with the high-level qualifier of PUB000 will be */ /* catalogued in the User Catalog UCPUB001. */ DEFINE ALIAS ( - NAME (PUB001) - RELATE (UCPUB001) ) /* //
When I bring a volume into the system from a prior functioning system that has its own catalog on the volume, I use the following jobstream to import that catalogs and set up Aliases to it:
//UCSYSP01 JOB (SYS),'IMPORT UCAT SYSP01',CLASS=S,MSGCLASS=X //IDCAMS01 EXEC PGM=IDCAMS,REGION=4096K //SYSPRINT DD SYSOUT=* //SYSP01 DD UNIT=3380,DISP=OLD,VOL=SER=SYSP01 //SYSIN DD * /* THERE IS A USER CATALOG IN EXISTENCE ON SYSP01 THAT */ /* CONTAINS CATALOG ENTRIES FOR THE DATASETS ON THAT VOLUME. */ /* IT IS CONNECTED TO THE MASTER CATALOG AND AN ALIAS IS */ /* DEFINED TO RELATE FUTURE DATASETS REFERENCES TO IT. */ IMPORT CONNECT OBJECTS((UCSYSP01 VOLUME(SYSP01) DEVT(3380))) DEFINE ALIAS(NAME(SYSP) RELATE(UCSYSP01)) //
Again, I will emphasize that I am providing this as a guide to setting up your own User Catalogs. You will have to decide what user catalogs you need for your system and prepare an appropriate jobstream using this example as a guide . If you are unfamiliar with VSAM Catalogs, I have written more about them in my VSAM Tutorial.
Once you have set up User Catalogs, you should modify the Master Catalog so that any changes to the catalog, such as adding new entries or modifying existing entries, will require a password. The jobstream I used for that is:
//MASTERPW JOB 'JAY MOSELEY',CLASS=A,MSGLEVEL=(1,1),MSGCLASS=A //IDCAMS EXEC PGM=IDCAMS,REGION=4096K //SYSPRINT DD SYSOUT=A //SYSIN DD */* ALTER THE MASTER CATALOG TO REQUIRE A PASSWORD IN ORDER TO COMPLETE ANY UPDATE OPERATIONS */ALTER SYS1.AMASTCAT UPDATEPW(SYSPROG)/* //
The password, shown above in blue, may be from 1 to 8 alphanumeric characters of your choice. I want to repeat that adding password protection to the Master Catalog does not prevent you from adding (or deleting) datasets entries from it, but the password must be supplied by the operator (or in the jobstream) in order for the Master Catalog to be updated.
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:
This page was last updated on January 17, 2015 .