UNIT
With SMS, you do not need to use the UNIT parameter to specify a device for an SMS-managed data set. Use the STORCLAS parameter or let an installation-written automatic class selection (ACS) routine select a storage class for the data set.
Also with SMS, for a non-SMS-managed data set, if your storage administrator has set a system default unit under SMS, you do not need to specify UNIT. Check with your storage administrator.
Use the UNIT parameter to ask the system to place the data set on:
A specific device.
A certain type or group of devices.
The same device as another data set.
The UNIT parameter can also tell the system how many devices to assign and request that the system defer mounting the volume until the data set is opened.
DD statement DDX requests two 3480 tape devices, DD statement DDZ requests the same two devices as DDX. Note that the operator will have to change volumes on the two 3480 devices during execution of the job step.
DD statement DDY requests one 3480 tape device.
VOL
Data sets on system-managed tape volumes exhibit both SMS and non-SMS characteristics. When necessary, data sets on a system-managed tape volume are distinguished from system-managed DASD data sets. Otherwise, the term system-managed data sets refers to both data sets on a system-managed tape volume and system-managed DASD data sets.
With SMS, consider the following:
All volumes in a multi-volume data set should reside in the same
system-managed tape library and must belong to the same tape storage group.
If all of the volumes do not reside in the same tape library, the installation can enter the volumes through the DFSMS installation exit, CBRUXVNL.
You cannot make a specific volume reference to a scratch volume.
You do not need to use the VOLUME parameter to specify volumes for new
data sets.
You cannot override the volume count for an existing system-managed DASD data set (but you can specify a volume count when you create a new
system-managed DASD data set).
If the storage administrator has specified a system default unit name and you do not code a UNIT name for non-system-managed data sets, then the system uses the volumes associated with the default unit name. In this case, you do not need to code the VOLUME parameter. Check with your storage administrator to determine whether a default unit name has been specified.
Use the VOLUME parameter to identify the volume or volumes on which a data set resides or will reside. You can request:
A private volume
Retention of the volume
A specific volume by serial number
The same volume that another data set uses
You can also specify which volume of a multivolume data set is to be processed first and, for an output data set, the number of volumes required.
A nonspecific volume request is a DD statement for a new data set that can be assigned to any volume or volumes. To make a nonspecific volume request for a new data set, either:
Omit the VOLUME parameter.
Code a VOLUME parameter but omit a SER or REF subparameter.
The DD statement requests an existing data set, which resides on the direct access volume, serial number 548863. Since PRIVATE is coded, the system will not assign to the volume another data set for which a nonspecific volume request is made and will demount the volume at the end of the job.
SYSOUT:
Use the SYSOUT parameter to identify this data set as a system output data set, usually called a sysout data set. The SYSOUT parameter also:
Assigns this sysout data set to an output class. The attributes of each output class are defined during JES initialization; the attributes include the device or devices for the output class.
Optionally requests an external writer to process the sysout data set rather than JES. An external writer is an IBM- or installation-written program.
Optionally identifies the forms on which the data set is to be printed or
punched.
Optionally refers to a JES2 /*OUTPUT statement for processing parameters.
The sysout data set is processed according to the following processing options, in override order:
The options specified on this sysout DD statement.
The options specified on a referenced OUTPUT JCL statement.
The options specified on a referenced JES2 /*OUTPUT statement or on a JES3 //*FORMAT statement.
The installation default options for the requested output class.
SYSPRINT
The SYSPRINT data set contains the generated output listing. The entry in the List ID field determines the destination of the output listing.
The manner in which you posed your SYSOUT/SYSPRINT question defines them as JCL DDNAMEs. In that context a //SYSOUT dataset is usualy (but not always) used to contain the results of DISPLAY stmts (COBOL pgms) and/or WTOs (assembler pgms). I'm not sure of how or if other language pgms use these DDNAMEs.
//SYSPRINT datasets usually (but not always) contain utility listings, error msgs and such.
But remember, they are just DDNAMEs , like //OUTDD, //MYSTUFF, or even //FRED. They can be used for anything thhat the above mentioned names could be conceivably used for.
That being said, //SYSOUT (not to be confused with the SYSOUT of SYSOUT=x fame, addressed by mdtendulkar, above) does have a special use in (as I stated above) COBOL and assembler pgms when the special DISPLAY or WTO stmts are used. In that case, //SYSOUT should not be used for any other purpose.
While I SAY you could use these two DDs in many ways, to make the point that they are just DDNAMEs like any other, it's best to limit their use to their traditional roles.