Specifications

Chapter 1. General usage 3
1.3 Sparse files
Earlier releases of zPDT (and the alcckd utility, in particular) created Linux sparse files. A
sparse file typically has a larger logical size than physical size. In a sparse file, only the disk
sectors that are changed are actually stored on disk. Other sectors logically contain zeros but
do not occupy space on the disk. Starting with release E41.33 (known as “GA 2.2”) alcckd no
longer creates sparse files. The new version takes longer to create a CKD volume because it
completely writes all the tracks for the volume.
While it is unlikely, a few users may have sparse files (for an emulated 3390 volume) created
under an early release of zPDT. These will work correctly, although the actual disk space
used may be misleading if the volume has not been fully written.
Previous versions of alcckd provided a parameter, -z, that would prevent sparse allocation.
This parameter is no longer meaningful.
The creation of a sparse file is mostly transparent to users, but it had a few side effects:
򐂰 It could cause disk space to be overcommitted. We might create 20 new 3390-3 volumes
(about 250 MB each at the time of creation in sparse format), checking each time to see if
there is sufficient free space on the drive. When we later write data to these volumes,
causing them to expand, they could overflow the available space on the drive. That is, the
sparse files might cause a future failure due to lack of disk space.
򐂰 A sparse file is expanded when data is written. This takes time for Linux disk allocation
functions. Writing a large System z data set might cause so much Linux overhead that
z/OS encounters timeout errors on the emulated drive.
򐂰 As a sparse file grows, the new sectors may be intermixed with other growing volumes and
produce a highly fragmented file. This can have minor performance effects.
The current operation of alcckd should be transparent to most users, except for the longer
time to create a new 3380/3390 emulated volume.
1.4 Security exposures
While most zPDT usage occurs in environments where base Linux security is not a significant
concern, the following items may be of concern to some users.
1.4.1 Reducing root usage
Once zPDT is installed, only two functions normally require running as root. These are the
SecureUpdateUtility command and the clientconfig command. This root usage may be
avoided by taking the following steps:
1. Select a userid (not root) who will be allowed to use the SecureUpdateUtility command.
2. As root (probably when installing zPDT) issue the command:
# SecureUpdate_authority -a <userid> (specify your selected userid)
This command is issued only once. To remove a userid from the authorized list issue:
# SecureUpdate_authority -d <userid>
3. Thereafter, use the zpdtSecureUpdate command while operating as the selected userid.
This command automatically switches to the /usr/z1090/bin directory and executes the