JCL to find if a dataset is empty

In your batch job, if there is a need to check for empty dataset, you can do it using IDCAMS.

//*-------------------------------------------------------------------*/
//* This JCL is to find if a file is empty or not. If there are no    */
//* records, the return-code will be 4.                               */
//*-------------------------------------------------------------------*/
//STEP01   EXEC PGM=IDCAMS
//SYSPRINT  DD SYSOUT=*
//IN1       DD DISP=SHR,DSN=your.dataset.name
//SYSIN     DD *
  PRINT INFILE(IN1) COUNT(001)
/*

If you have ICETOOL at your site, you can use that as well.

//*-------------------------------------------------------------------*/
//* This JCL is to find if a file is empty or not using ICETOOL.      */
//* If there are no records, the return-code will be 12               */
//*-------------------------------------------------------------------*/
//STEP01  EXEC PGM=ICETOOL
//TOOLMSG  DD SYSOUT=*
//DFSMSG   DD SYSOUT=*
//IN       DD DISP=SHR,DSN=your.dataset.name
//TOOLIN   DD *
COUNT FROM(IN) EMPTY
/*

APF Authorization

When someone says, "you need to APF authorize this dataset", what do they mean?

Well, APF means "Authorized Program Facility". In a z/OS environment, APF is a facility that permits the identification of programs that are authorized to use restricted functions.

To find the datasets that are APF authorized:

1. Type TSO ISRDDN in your ISPF session (some shops need just ISRDDN with no TSO prefix) and hit enter.

2. Type APF and hit enter. It'll bring up a list of all datasets that are APF authorized.

Remember that, if you like to use a APF authorized dataset in a job STEPLIB, make sure all the datasets in the STEPLIB are APF authorized.

ISRDDN

When you log on to your mainframe TSO (Time Sharing Option) session, you can use the TSO supplied commands. Apart from those commands, if you know how to code in REXX or CLIST, you can come up with your own commands.

There are also occasions when you use commands written by some 3rd party vendors. For example, Quick Reference - you invoke their product by typing "QW keyword". Sometimes you wonder, how does TSO know these commands exist or where to get the source/load from - the source could be in a lot of different datasets.

When you logon into your TSO session, the system preallocates a bunch of datasets. This is determined by your logon PROC. Usually the system programmer determines the appropriate logon PROC for each user. For example, a developer might need a set of datasets preallocated, while a DBA might need a different set of datasets preallocated. So, when you type QW in the command line, TSO searches in these datasets and executes it.

To find out which are all the datasets that have been allocated to your TSO session, type ISRDDN (in some shops, you may have to type TSO ISRDDN) in the command line and hit enter. You will get all the datasets that are allocated and the corresponding DD names. If you want to find the source of a particular CLIST, REXX, Panel, etc., just type "M membername" (without quotes). e.g. M qw -- will search for the source code or load for QW.

"HIDE EXCLUDE"

When you are editing a dataset in ISPF, you can exclude lines by typing 'x' in the line number area. When you do that, you see the excluded lines as a row of dots. You now have the option of entering 'HIDE EXCLUDE' on the command line. The line of dots disappears and is replaced with a solid line in the number area.

RESET will behave as before; RESET HIDE will return the row of dots to your display.

Migrate dataset to tape

HMIGRATE command with no option specified on a dataset migrates the dataset to MIGRAT. To migrate a dataset to TAPE (MIGRAT2) directly, issue the following command:

HMIG 'dataset name' ML2

HRECALL with DFDSS option

When you need a dataset that has been migrated to tape, you can issue the HRECALL command. However, if the recalled dataset doesn’t fit in one volume the command fails. To get through this, you can have it span multi-volumes using the following command:

HSEND RECALL ‘migrated-dataset-name’ DFDSSOPTION(VOLCOUNT(ANY))

‘TTR’ in PDS and PDSE

Partitioned Data Set uses an addressing scheme called TTR (Track-Track-Record) which is based on the DASD geometry. TTR addresses are stored in hexadecimal format. So an address of X’002E26′ would mean track number X’002E’ and record X’26′. The name TTR comes from the fact that first two bytes of the address denote track number and third byte denotes record number. This dependence on the DASD geometry makes it very difficult to migrate PDS from one type of DASD to another one, e.g. from 3380 to 3390.

The PDSE addressing scheme is not dependent on the physical device geometry. It uses a ’simulated’ 3-byte TTR address to locate the members & the records which makes the migration easier. Incidentally, this simulation of addresses places some limitations on the number of members and the number of records per member in a PDSE. A TTR address of X’000001′ in a PDSE points to the directory. The addresses from X’000002′ to X’07FFFF’ point to the first record of each member, which is why there is a limit of 524,286 members. The addresses from X’100001′ to X’FFFFFF’ point to records within each member, which is why there is a limit of 15,728,639 records in each member.