Footprint Synchronization

 is a set of encrypted data placed by
processors in generated source, object, or load modules. Footprints contain location and event information from the Master Control File record for the element:
  • Site ID
  • Environment
  • Stage Number
  • System
  • Subsystem
  • Type
  • Element Name
  • Version and Level
  • Date and time the output was created
By relating an output to an element, footprints let you:
  • Keep source synchronized with executables
  • Display source information from executables
How Synchronizing Source and Executables Works
helps you to keep source synchronized with executables by comparing the date and time that the element was last generated (from the Master Control File) with the date and time information in the footprint.
Use this capability by doing the following:
  • Including the FOOTPRNT=VERIFY statement in processors. This option automates footprint verification each time the processor runs.
  • Running footprint reports. Running footprint reports on a regular basis helps you to monitor footprints. The following describes the footprint reports
      CONRPT80 -- Library Member Footprint Report
      Footprint information stored in the members of load and non-load libraries.
      CONRPT81 -- Library CSECT Listing
      CSECTs in a load library, along with corresponding member names and link-edit compile dates, and the footprint, if available.
      CONRPT82 -- Library Zapped CSECT Profile
      CSECTs that were zapped from a load library.
      CONRPT83 -- Footprint Exception Report
      Members, CSECTs, or load modules that have no footprint or whose footprints were corrupted.
 For more information about reports, see 
Footprint Reports
Source Input from Executables
uses footprints to let you display:
  • A list of members in a library, with footprint information for each.
  • A list of CSECTs for a specific load module, with footprint information for each CSECT and for the load module.
If a member, CSECT, or load module is footprinted,
lets you display information (current source, change history, changes at the current level, summary of levels, Master Control File information) about it from this selection list.
Footprints are stored in the following locations:
  • Library data sets
  • Sequential object data sets
  • Load libraries
 Sequential source is not footprinted.
Footprints and Library Data Sets
For a source or object data set stored in a PDS or a ELIB data set, the footprint is kept in the user data area of the directory. Do not use the ISPF RESET STATISTICS function (3.5) to reset statistics of a footprint library. Doing so overwrites the footprint, which results in future compromise messages such as C1G0118C.
Footprint information is stored in library data sets as noted below:
  • For the
    Interface, it is stored as a history record.
  • For the
    Interface, it is stored as a COMMENT field.
Footprints and Sequential Object Data Sets
For a sequential data set that is an object deck, the footprint is stored as an IDENTIFY statement at the end of the object code.
For a previously footprinted sequential data set (object deck only) that is stored in a PDS (using FOOTPRNT=CREATE), there is a footprint (part of an IDENTIFY statement) at the end of the data set and in the user data area of the directory. If the sequential data set (object deck only) and PDS member are created by the same processor, they are in sync.
Footprints and Load Libraries
For a PDS load module, CSECT footprints are kept in the user IDR record of the load module, one footprint for each CSECT. The footprint for the load module is stored in the ZAPIDR record for that load module.
 Footprinting of the load module PDS directory is not allowed because this would compromise the ability of the load module to execute. For PDS load module footprints, a user update to the IDR or a zap applied to the load module compromises the footprint.
Footprints and PDS/E Load Libraries
For PDS/E load library members, known as 
program objects
, CSECT footprints are stored in the same fashion as they are in conventional load module members. For example, footprint data is introduced through an IDENTIFY card added to the input object modules, and the binder incorporates these footprints into IDRU records in the program object. The module-level footprint is also stored in a special IDRU record and is added using the IEWBIND programming interface. All footprint data is extracted from program objects using the IEWBIND interface.
Footprints and USS Directories
For source stored in an USS directory, the footprint associated with the source is placed in a footprint subdirectory named @EFP. When a file is created or deleted from the directory, the corresponding footprint is written to or removed from the @EFP subdirectory. The @EFP subdirectory is dynamically created if the directory does not exist. The @EFP subdirectory is not deleted when the last footprint is removed.