6.11 CKD DASD De
vices

6.11.1 Function

This device statement is used to define a CKD DASD device to the Hercules configuration. The argument
specifies the name of a file that contains the CKD DASD image or the INET address of a Hercules shared
device server.

The file consists of a 512-byte device header record followed by fixed length track images. The length of
each track image depends on the emulated device type and is always rounded up to the next multiple of
512 bytes.

Volumes larger than 2 GB (for example the 3390, model 3) can be supported by spreading the data
across more than one file. Each file contains a whole number of cylinders. The first file (which contains
cylinders 0-2518 in the case of a 3390) usually has “_1” as the last two characters of its name. The
ckddasd driver allocates the remaining files by replacing the last characters of the file name by the
characters “_2”, “_3” and so on.

If your operating system supports large file sizes (or 64-bit offsets) then volumes larger than 2GB can be
kept in a single file. The two character suffix is not used in this case.

Alternatively the argument may specify the name of a file containg a compressed CKD DASD image
(CCKD DASD files). The CKD driver will automatically detect whether the file contains a regular CKD
image or a compressed CKD image.

6.11.2 Syntax

Descriptive

filename [sfshadowfile





type]


or

ipname [ ] [
] n]

Diagram






Êʬ¬¬ ¬¬¬ ¬¬¬ filename ¬¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬Ê







shadowfile

ʬ¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬§¬¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬§¬¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬Ê



ʬ¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ÊÍ


type


or








Êʬ¬¬ ¬¬¬ ¬¬¬ ipname ¬¬¬¦¬¬¬¬¬¬¬¬¬¬¬¬¬¦¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬Ê







ʬ¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬§¬¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ÊÍ


n

6.11.3 Parameter

devaddr

This is the device address.

devtype

This is the device type. Valid device types are 2311, 2314, 3330, 3350, 3375, 3380,
3390 and 9345.

filename

This specifies the filename (and optionally the path) of the file containing the DASD
image.

shadowfile

A shadow file contains all the changes made to the emulated DASD device since it
was created, maintained until the next shadow file is created. The moment of the
shadow file’s creation can be thought of a snapshot of the current emulated DASD
at that time, as if the shadow file is later removed the emulated DASD reverts back
to the state it was when the snapshot was taken.

Using shadow files, the base files can be kept on a read-only device like CDROM
or can be defined as read-only thus ensuring that these files can never be corrupt-
ted.

The shadow file does not have to actually exist when it is defined in the configu-
ration file. The shadow operand of the sf= parameter is simply a filename template
that will be used to name the shadow file whenever one is be created. Shadow files
are created using the sf+ xxxx or sf+ * commands.

The shadow file name must have a position where the shadow file number will be
set. This is either the character preceding the last period after the slash or the last
character if there is no period. For example: sf=shadows/linux1_*.dsk.

Hercules console commands are provided to add a new shadow file, remove the
current shadow file (with or without backward merge), compress the current
shadow file and display the shadow file status and statistics.

Please note, that the “sf” parameter has to be coded in lowercase letters otherwise
an error message is presented.

Details on how to work with shadow files can be found in chapter

8.152 ff.

[NO]SYNCIO

SYNCIO enables possible “synchronous” I/O. This is a DASD I/O feature wherein
guest I/O requests are completed “synchronously” during the actual emulated exe-
cution of the SIO / SSCH (START IO / START SUBCHANNEL) instructions rather
than being deferred and executed asynchronously in a separate device I/O thread.

Only I/O which are known to be able to be completed without actually needing to
perform any actual host I/O are completed synchronously (e.g. whenever the data
being requested is found already be in the cache). If the requested data could not
be found in the cache then actual host I/O will need to be done and the request is

Previous Page Next Page