Browse Prior Art Database

Pin Text

IP.com Disclosure Number: IPCOM000121119D
Original Publication Date: 1991-Jul-01
Included in the Prior Art Database: 2005-Apr-03
Document File: 2 page(s) / 105K

Publishing Venue

IBM

Related People

Haggar, JD: AUTHOR [+3]

Abstract

This article describes the concept of Pin Text. The Pin Text allows an authorized application or system service to identify why a system resource is held in addition to identifying which unit of work holds the resource.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Pin Text

      This article describes the concept of Pin Text.  The Pin
Text allows an authorized application or system service to identify
why a system resource is held in addition to identifying which unit
of work holds the resource.

      Various operating system activities require the serialization
of system resources.  Operating systems typically provide customer
interfaces and diagnostic aids to identify which resources are held
and by which units of work, but provide no function to identify why
the resources are held.  For example, a system operator can use the
MVS DISPLAY command to determine which jobs have a particular device
allocated.  An operator can also use the DISPLAY command to find out
which jobs hold a particular Global Resource Serialization (GRS)
enqueue.  But, in either case, the system operator cannot determine
why the resource in question is held.

      Operating systems also track system resource ownership to
assist in problem determination.  This information allows dump
analysis programs and debuggers to quickly determine which units of
work hold certain resources.  For example, the Prefixed Save Area
(PSA) contains flags that indicate which locks the current unit of
work holds.  However, a dump analysis program cannot determine why
the resource was held. A debugger must often look at the operating
system source code to understand why the resources was held.

      The MVS Dynamic I/O Configuration function allows an
installation to dynamically change the I/O configuration definition.
This function introduces another reason for applications and system
services to serialize a resource, specifically to protect against
deletion of that resource. A Unit Control Block (UCB) is the MVS
representation of a device definition.  Therefore, when the
configuration definition of a device is dynamically deleted, the
operating system dynamically deletes the UCB for the device and
deletes or updates other device-related data structures. Also, when
the configuration definition of a device is dynamically modified, the
operating system dynamically deletes the UCB for the device and
dynamically adds a new UCB representing the new device definition.

      The operating system only permits the dynamic deletion of UCBs
for devices which are not in use.  A device must be off-line and
unallocated for the UCB to be deleted. However, many programs use
off- line/unallocated devices or look at...