Package Information Management Tasks

Package information management tasks retrieve or manage metadata and control information for a package. Such information includes title and descriptions, general parameters, user-defined package variables, install information, promotion history for the package, promotion history for package components, and the like. Typical commands include list, unfreeze, and refreeze.

Serena XML supports the follow information management tasks for packages:

• *List Package Description - PACKAGE GEN_DESC LIST	• *List Package Implementation Instructions - PACKAGE IMP_INST LIST
• *List General Package Parameters - PACKAGE GEN_PRMS LIST	• *List Package Approvers - APPROVER PKG LIST
• *Unfreeze Package Parameters - PACKAGE GEN_PRMS UNFREEZE	• *List Affected Applications - PACKAGE AFF_APLS LIST
• *Refreeze Package Parameters - PACKAGE GEN_PRMS REFREEZE	• *List Participating Packages - PACKAGE PRT_PKGS LIST
• List User-Defined Package Variables - *PACKAGE USR_RECS LIST	• *List Linked Packages - PACKAGE PKG_LINK LIST
• *List Package Install Sites - SITE PKG LIST	• *List Package Library Types - LIBTYPE PKG LIST
• *Unfreeze Package Install Sites - PACKAGE SITES UNFREEZE	• *List Package Promotion History - PACKAGE PRM_HIST LIST
• *Refreeze Package Install Sites - PACKAGE SITES REFREEZE	*• Package Promoted Component List - PACKAGE PRM_CMP LIST
• List Package Installation Dependencies - *PACKAGE SCH_RECS LIST	*• List Reasons for Backout or Revert - PACKAGE REASONS LIST

...

List Package Description - PACKAGE GEN_DESC LIST

Serena XML lists the package description for one package. Multiple package descriptions require multiple requests. Descriptions for baselined packages are accessible as long as the package master record remains in the package database.

The Serena XML service/scope/message names for a package description list message are:

<service name="PACKAGE"> 
<scope name="GEN_DESC"> 
<message name="LIST">

These tags appear in both request and reply messages.

PACKAGE GEN_DESC LIST — Requests

The package description list requires a package name as input. Wildcard characters are not accepted in the <package> tag.

The following example shows how you might code a package description list request in Serena XML. Data structure details for the <request> tag appear in the following exhibit. This data structure is common to many package requests in Serena XML.

Example XML — PACKAGE GEN_DESC LIST Request

<?xml version="1.0"?> 
<service name="PACKAGE">
    <scope name="GEN_DESC">
        <message name="LIST">
            <header>
                <subsys>8</subsys>
                <product>CMN</product>
            </header>
            <request>
                <package>ACTP000007</package>
            </request>
        </message>
    </scope>
</service>

...

Exhibit 4-36.PACKAGE GEN_DESC LIST <request> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), fixed	ZMF application name. Same as first 4 bytes of package name.
<package>	Required	1	String (10), fixed	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name.

...

PACKAGE GEN_DESC LIST — Replies

Replies to a package description list request return no more than one <result> tag. The <result> contains zero to many package description entries for a single package.

The result is followed by a standard <response> tag that indicates the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher.

An example XML reply message for the package description list follows. Data structure details for <result> tag appear after the example, in Exhibit 4-37.

Example XML — PACKAGE GEN_DESC LIST Reply

<?xml version="1.0"?> 
<service name="PACKAGE">
    <scope name="GEN_DESC">
        <message name="LIST">
            <result>
                <package>ACTP000007</package> <applName>ACTP</applName>
                <packageId>000007</packageId>
                <packageDesc>SER5904E</packageDesc>
            </result>
            <response>
                <statusMessage>CMN8700I - LIST service completed</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8700</statusReasonCode>
            </response>
        </message>
    </scope>
</service>

...

Exhibit 4-37. PACKAGE GEN_DESC LIST <result> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), fixed	ZMF application name. Same as first 4 bytes of package name.
<package>	Required	1	String (10), fixed	Fixed-format ZMF package name.
<packageDesc>	Optional	0 - 46	String (72), variable	General description of package contents. Up to 46 lines of 72 bytes each are allowed by ZMF.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name.

...

List General Package Parameters - PACKAGE GEN_PRMS LIST

General parameters for a package include descriptive items entered during package creation and update, as well as programmatically maintained status, audit trail, and release information. The Serena XML function to list general package parameters retrieves this information for any package master record, even after a package has been baselined.

User-defined package variables, package install information, and package approver lists require other Serena XML functions for access.

The Serena XML service/scope/message names for a request to list general package parameters are:

<service name="PACKAGE"> 
<scope name="GEN_PRMS"> 
<message name="LIST">

These tags appear in both request and reply messages.

PACKAGE GEN_PRMS LIST — Request

The syntax for a request to list general package parameters is identical to that for many package information management functions, including the package description list.

PACKAGE GEN_PRMS LIST — Replies

The Serena XML reply to a general package parameters list request contains one <result> tag for the package named in the request.

A standard <response> tag follows the <result> to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher.

An example reply message listing general package parameters appears below. Data structure details for the <result> tag appear after the example in Exhibit 4-38.

Example XML — PACKAGE GEN_PRMS LIST Reply

<?xml version="1.0"?> 
<service name="PACKAGE">
    <scope name="GEN_PRMS">
        <message name="LIST">
            <result>
                <package>ACTP000007</package> <applName>ACTP</applName>
                <packageId>000007</packageId>
                <packageLevel>1</packageLevel>
                <packageType>1</packageType>
                <packageStatus>3</packageStatus>
                <dateCreated>20090127</dateCreated>
                <timeCreated>082516</timeCreated>
                <dateFrozen>20090127</dateFrozen>
                <timeFrozen>082824</timeFrozen>
                <dateApproved>20090127</dateApproved>
                <timeApproved>083154</timeApproved>
                <dateSent>20090127</dateSent>
                <timeSent>083210</timeSent>
                <dateReceived>20090127</dateReceived>
                <timeReceived>083238</timeReceived>
                <dateInstalled>20090127</dateInstalled> 
                <timeInstalled>083537</timeInstalled>

...

                <dateBaselined>20090127</dateBaselined> 
                <timeBaselined>083656</timeBaselined> 
                <requestorDept>IDD</requestorDept>
                <requestorName>USER24</requestorName>
                <requestorPhone>5555555</requestorPhone>
                <workChangeRequest>USER24</workChangeRequest>
                <packageTitle>SER5906E</packageTitle>
                <creator>USER24</creator>
                <lastPromotionAction>0</lastPromotionAction>
                <schedulerType>2</schedulerType>
                <isPostApprovalPending>N</isPostApprovalPending>
                <isPostApproversAdded>N</isPostApproversAdded>
                <isPostRejected>N</isPostRejected>
                <isShortApproverListUsed>N</isShortApproverListUsed>
                <tempChangeDuration>000</tempChangeDuration>
                <isStageLibsDeleted>N</isStageLibsDeleted> 
                <isLinkedPackage>N</isLinkedPackage>
                <isCmnSchedulerUsed>N</isCmnSchedulerUsed>
                <isManualSchedulerUsed>Y</isManualSchedulerUsed>
                <isOtherSchedulerUsed>N</isOtherSchedulerUsed>
                <isAuditPending>N</isAuditPending>
                <isFreezePending>N</isFreezePending>
                <isApprovalPending>N</isApprovalPending>
                <isXNodeBuildRequired>N</isXNodeBuildRequired>
                <isInstallPending>Y</isInstallPending>
                <isRevertPending>N</isRevertPending>
                <isReverseRippleSubmitted>N</isReverseRippleSubmitted>
                <isBackedOut>N</isBackedOut>
                <isXNodeBuildPending>N</isXNodeBuildPending>
                <generalComponentStatus>4</generalComponentStatus>
                <nonSourceComponentStatus>4</nonSourceComponentStatus>
                <sourceLoadComponentStatus>4</sourceLoadComponentStatus>
                <utilityInfoStatus>4</utilityInfoStatus>
                <siteInfoStatus>4</siteInfoStatus>
                <customComponentStatus>4</customComponentStatus>
                <nearestInstallDate>20090127</nearestInstallDate>
                <problemActionCode>2</problemActionCode>
                <stageDevLibModel>CMNTP.SERT8.DEV.ACTP.\#000007</stageDevLibModel>
                <stageProdLibModel>CMNTP.SERT8.PRD.ACTP.\#000007</stageProdLibModel>
                <stageLibStatus>2</stageLibStatus>
                <installTimeExpiration>0200</installTimeExpiration>
                <packageCheckedIntoRelease>N</packageCheckedIntoRelease>
            </result>
            <response>
                <statusMessage>CMN8700I - LIST Package service completed</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8700</statusReasonCode>
            </response>
        </message>
    </scope>
</service>

...

Exhibit 4-38. PACKAGE GEN_PRMS LIST <result> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), fixed	ZMF application name. Same as first 4 bytes of package name.
<auditLockUserid>	Optional	0 - 1	String (8), variable	Userid who locked package for audit.
<auditReturnCode>	Optional	0 - 1	String (2), variable	Return code issued by ZMF package audit. Values: 00 = No major errors found 04 = Errors found 08 = Major errors found 12 = Possibly fatal errors found
<complexSuperPackage>	Optional	0 - 1	String (10), fixed	Name of complex/super package to which this participating package belongs. NOTE: Returned only if value of <packageLevel> = 4.
<complexSuperPackageAppl>	Optional	0 - 1	String (4), variable	Package application. NOTE: Returned only if value of <packageLevel> = 4.
<complexSuperPackageNumber>	Optional	0 - 1	String (6), fixed	Package number. NOTE: Returned only if value of <packageLevel> = 4.
<creator>	Optional	0 - 1	String (8), variable	TSO user ID of package creator.
<customComponentStatus>	Optional	0 - 1	String (1)	Status code for custom components of package as a group. Values: 0 = Active 1 = Approved 2 = Checked out 3 = Demoted 4 = Frozen 5 = Inactive 6 = Incomplete 7 = Promoted 8 = Refrozen 9 = Rejected A = Remote promoted B = Submitted C = Unfrozen
<dateApproved>	Optional	0 - 1	Date (8), yyyymmdd	Date package approved.
<dateBaselined>	Optional	0 - 1	Date (8), yyyymmdd	Date package baselined.
<dateBackedOut>	Optional	0 - 1	Date (8), yyyymmdd	Date package backed out.
<dateCreated>	Optional	0 - 1	Date (8), yyyymmdd	Date package created.
<dateFrozen>	Optional	0 - 1	Date (8), yyyymmdd	Date package frozen.
<dateInstalled>	Optional	0 - 1	Date (8), yyyymmdd	Date package installed.
<dateMemoDeleted>	Optional	0 - 1	Date (8), yyyymmdd	Date package logically deleted.
<dateReceived>	Optional	0 - 1	Date (8), yyyymmdd	Date package received.
<dateRejected>	Optional	0 - 1	Date (8), yyyymmdd	Date package rejected.
<dateReverted>	Optional	0 - 1	Date (8), yyyymmdd	Date package reverted.
<dateSent>	Optional	0 - 1	Date (8), yyyymmdd	Date package sent.
<dateTempChangeCycled>	Optional	0 - 1	Date (10), yyyymmdd	Date when temporary change package expired.
<generalComponentStatus>	Optional	0 - 1	String (1)	General status code for all package components as a group. Values: 0 = Active 1 = Approved 2 = Checked out 3 = Demoted 4 = Frozen 5 = Inactive 6 = Incomplete 7 = Promoted 8 = Refrozen 9 = Rejected A = Remote promoted B = Submitted C = Unfrozen
<installTimeExpiration>	Optional	0 - 1	Time (8), hhmm	Ending time for installation window on next planned install, 24-hour. NOTE: No punctuation included in time returned by ZMF.
<isApprovalPending>	Optional	0 - 1	String (1)	Y = Yes, approval pending N = No, approval not pending
<isAuditPending>	Optional	0 - 1	String (1)	Y = Yes, audit pending N = No, audit not pending
<isBackedOut>	Optional	0 - 1	String (1)	Y = Yes, package backed out N = No, package not backed out
<isCmnSchedulerUsed>	Optional	0 - 1	String (1)	Y = Yes, package uses ZMF installation scheduler N = No, ZMF scheduler not used NOTE: Value should be "Y" if <schedulerType> = 1. NOTE: Value should be "N" if <schedulerType> = 2 or 3.
<isFreezePending>	Optional	0 - 1	String (1)	Y = Yes, package freeze pending N = No, freeze not pending
<isInstallPending>	Optional	0 - 1	String (1)	Y = Yes, package install pending N = No, install not pending
<isLinkedPackage>	Optional	0 - 1	String (1)	Y = Yes, this package is linked N = No, not a linked package
<isManualSchedulerUsed>	Optional	0 - 1	String (1)	Y = Yes, manual installation N = No, install is automated NOTE: Value should be "Y" if <schedulerType> = 2. NOTE: Value should be "N" if <schedulerType> = 1 or 3.
<isOtherSchedulerUsed>	Optional	0 - 1	String (1)	Y = Yes, package uses 3rd-party installation scheduler N = No 3rd-party scheduler used NOTE: Value should be "Y" if <schedulerType> = 3. NOTE: Value should be "N" if <schedulerType> = 1 or 2.
<isPostApprovalPending>	Optional	0 - 1	String (1)	Y = Yes, post-approval pending N = No post-approval
<isPostApproversAdded>	Optional	0 - 1	String (1)	Y = Yes, post-approver list added N = No, list not added
<isPostRejected>	Optional	0 - 1	String (1)	Y = Yes, package post-rejected N = No, not post-rejected
<isReverseRippleSubmitted>	Optional	0 - 1	String (1)	Y = Yes, baseline reverse ripple job submitted. N = No, baseline reverse ripple job not submitted.
<isRevertPending>	Optional	0 - 1	String (1)	Y = Yes, package revert pending N = No, revert not pending
<isShortApproverListUsed>	Optional	0 - 1	String (1)	Y = Yes, post-approver list has emergency approvers only N = No, not using emergency list of package approvers
<isStageLibsDeleted>	Optional	0 - 1	String (1)	Y = Yes, staging libraries deleted N = No, staging libs not deleted
<isXNodeBuildPending>	Optional	0 - 1	String (1)	Y = Yes, JCL install build pending N = No, JCL build not pending
<isXNodeBuildRequired>	Optional	0 - 1	String (1)	Y = Yes, JCL install build required N = No, JCL build not required
<lastBackoutUserid>	Optional	0 - 1	String (8), variable	TSOID of the last package backout.
<lastPromoter>	Optional	0 - 1	String (8), variable	TSO user ID of most recent promoter/demoter.
<lastPromotionAction>	Optional	0 - 1	String (1)	Code for most recent promotion action. Values: 0= No promotion 1= Full demotion 2= Full promotion 3= Reverted 4= Selective demotion 5= Selective promotion 6= First promotion
<lastPromotionDate>	Optional	0 - 1	Date (10), yyyymmdd	Date of most recent promotion action.
<lastPromotionLevel>	Optional	0 - 1	String (2), variable	Most recent promotion level in user-defined promotion hierarchy.
<lastPromotionName>	Optional	0 - 1	String (8), variable	Name of most recent promotion action.
<lastPromotionSite>	Optional	0 - 1	String (8), variable	Site name where most recent promotion action took place.
<lastPromotionTime>	Optional	0 - 1	Time (8), hhmmss	Time of most recent promotion action, 24-hour format.
<lastRevertUserid>	Optional	0 - 1	String (8), variable	TSOID of the last package revert.
<nearestInstallDate>	Optional	0 - 1	Date (8), yyyymmdd	Next planned installation date among prescheduled site installs.
<nonSourceComponentStatus>	Optional	0 - 1	String (1)	Status code for non-source package components as a group. Values: 0 = Active 1 = Approved 2 = Checked out 3 = Demoted 4 = Frozen 5 = Inactive 6 = Incomplete 7 = Promoted 8 = Refrozen 9 = Rejected A = Remote promoted B = Submitted C = Unfrozen
<otherProblemAction>	Optional	0 - 1	String (44), variable	Text of "Other" instructions if installation problem occurs. NOTE: Returned when value of <problemActionCode> = 3.
<package>	Required	1	String (10), fixed	Fixed-format ZMF package name.
<packageCheckedIntoRelease>	Optional	0 - 1	String (1)	Y = Yes, checked into release N = No, not checked into release
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name.
<packageLevel>	Optional	1	Integer (1)	Code for package complexity level. Values: 1 = Simple package 2 = Complex package 3 = Super package 4 = Participating package NOTE: If value = 4, name of complex/super package is returned in <complexSuperPackage>.
<packageStatus>	Required	1	String (1)	Code for status of package in lifecycle. Values: 1 = Approved 2 = Backed out 3 = Baselined 4 = Complex/super pkg closed 5 = Deleted (memo delete) 6 = Development 7 = Distributed 8 = Frozen 9 = Installed A = Complex/super pkg open B = Rejected C = Temporary change cycle completed NOTE: Only values 6 or A should be returned for package create.
<packageTitle>	Optional	0 - 1	String (72), variable	Working title for package. Appears on most listings & reports.
<packageType>	Optional	0 - 1	String (1)	Package install type code. Values: 1 = Planned permanent 2 = Planned temporary 3 = Unplanned permanent 4 = Unplanned temporary NOTE: For code values = 2 or 4, <tempChangeDuration> also required. NOTE: For code values = 3 or 4, <reasonCode> also required.
<problemActionCode>	Optional	0 - 1	Integer (1)	Code for action to take if problem occurs in package install. Values: 1 = Hold production & contact developer for instructions 2 = Back out change, then proceed with production 3 = Other instructions NOTE: If value = 3, instructions in <otherProblemAction> tag also returned.
<reasonCode>	Optional	0 - 1	String (3), variable	Customer-defined reason code for unplanned package installation. NOTE: Returned if value of <packageType> = 3 or 4.
<release>	Optional, ZMF with ERO only	0 - 1	String (8)	Name of ERO release with which package is associated.
<releaseArea>	Optional, ZMF with ERO only	0 - 1	String (8)	Name of starting release area for release package checkin.
<releaseJoinedDate>	Optional	0 - 1	Date (8), yyyymmdd	Date package joined release.
<releaseJoinedTime>	Optional	0 - 1	Time (6), HHMMSS	Time package joined release.
<requestorDept>	Optional	0 - 1	String (4), variable	Workgroup or department code for package requestor.
<requestorName>	Optional	0 - 1	String (25), variable	Name of developer or contact person requesting package create.
<requestorPhone>	Optional	0 - 1	String (15), variable	Phone of developer or contact person requesting package create.
<schedulerType>	Optional	0 - 1	Integer (1)	Code for type of installation scheduler. Values: 1 = ChangeMan scheduler 2 = Manual install 3 = Other automated scheduler
<siteInfoStatus>	Optional	0 - 1	String (1)	Status code for site components of package as a group. Values: 0 = Active 1 = Approved 2 = Checked out 3 = Demoted 4 = Frozen 5 = Inactive 6 = Incomplete 7 = Promoted 8 = Refrozen 9 = Rejected A = Remote promoted B = Submitted C = Unfrozen
<sourceLoadComponentStatus>	Optional	0 - 1	String (1)	Status code for source & load components of package as a group. Values: 0 = Active 1 = Approved 2 = Checked out 3 = Demoted 4 = Frozen 5 = Inactive 6 = Incomplete 7 = Promoted 8 = Refrozen 9 = Rejected A = Remote promoted B = Submitted C = Unfrozen
<stageDevLibModel>	Optional	0 - 1	String (36), variable	Qualified name of model library to use when staging from development environments outside ZMF control.
<stageLibStatus>	Optional	0 - 1	String (1)	Status code for package staging library. Values: 1 = Absent 2 = Present 3 = Archived
<stageProdLibModel>	Optional	0 - 1	String (36), variable	Qualified name of model library to use when staging from ZMF baseline or production libraries.
<tempChangeDuration>	Optional	0 - 1	Integer (3)	Number of days for temporary package to remain in production. NOTE: Returned if value of <packageType> = 2 or 4.
<timeApproved>	Optional	0 - 1	Time (6), hhmmss	Time package approved, 24-hour.
<timeBackedOut>	Optional	0 - 1	Time (6), hhmmss	Time package backed out, 24-hour.
<timeBaselined>	Optional	0 - 1	Time (6), hhmmss	Time package baselined, 24-hour.
<timeCreated>	Optional	0 - 1	Time (6), hhmmss	Time package created, 24-hour.
<timeFrozen>	Optional	0 - 1	Time (6), hhmmss	Time package frozen, 24-hour.
<timeInstalled>	Optional	0 - 1	Time (6), hhmmss	Time package installed, 24-hour.
Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<timeMemoDeleted>	Optional	0 - 1	Time (6), hhmmss	Time package logically deleted, 24-hour format.
<timeReceived>	Optional	0 - 1	Time (6), hhmmss	Time package received, 24-hour.
<timeRejected>	Optional	0 - 1	Time (6), hhmmss	Time package rejected, 24-hour.
<timeReverted>	Optional	0 - 1	Time (6), hhmmss	Time package reverted, 24-hour.
<timeSent>	Optional	0 - 1	Time (6), hhmmss	Time package sent, 24-hour.
<timeTempChangeCycled>	Optional	0 - 1	Time (6), hhmmss	Time when temporary change package expired, 24-hour format.
<utilityInfoStatus>	Optional	0 - 1	String (1)	Status code for scratch/rename components of package as a group. Values: 0 = Active 1 = Approved 2 = Checked out 3 = Demoted 4 = Frozen 5 = Inactive 6 = Incomplete 7 = Promoted 8 = Refrozen 9 = Rejected A = Remote promoted B = Submitted C = Unfrozen
<workChangeRequest>	Optional	0 - 1	String (12), variable	Work order ID or change request number for package.

...

Unfreeze Package Parameters - PACKAGE GEN_PRMS UNFREEZE

The Serena XML function to unfreeze general package parameters unlocks those parameters for change. You can then change the scheduled installation date or implementation instructions, make a temporary change permanent, or update the package description to better fit the delivered code. The package and its components remain frozen overall.

The Serena XML service/scope/message tags for a general package parameters unfreeze message are:

<service name="PACKAGE"> 
<scope name="GEN_PRMS">
<message name="UNFREEZE">

These tags appear in both requests and replies.

PACKAGE GEN_PRMS UNFREEZE — Requests

The <request> tag syntax for a general package parameters unfreeze request is identical to that for many package information management functions, including the package description list and package general description list. Only the name parameters in the high-level <scope> and <message> tags differ, as shown above.

PACKAGE GEN_PRMS UNFREEZE — Replies

The Serena XML reply message to an unfreeze request for general package parameters does not return a <result> data structure. It does, however, return a standard <response> data structure to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher.

Refreeze Package Parameters - PACKAGE GEN_PRMS REFREEZE

The Serena XML refreeze function for general package parameters resets these previously unfrozen parameters to frozen status, locking them down against change.

The Serena XML service/scope/message tags for a general package parameters refreeze message are:

<service name="PACKAGE"> 
<scope name="GEN_PRMS">
<message name="REFREEZE">

These tags appear in both requests and replies.

PACKAGE GEN_PRMS REFREEZE — Requests

The tag syntax for a general package parameters refreeze request is identical to that for an unfreeze request. Only the name parameter in the high-level <message> tag differs, as shown above.

PACKAGE GEN_PRMS REFREEZE — Replies

The Serena XML reply message to a refreeze request for general package parameters does not return a <result> data structure. It does, however, return a standard <response> data structure to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher.

List User-Defined Package Variables - PACKAGE USR_RECS LIST

Serena XML supports up to 72 user-defined package variables established by users when they customize ChangeMan ZMF. These are stored in the package master record with the general parameters for a package, but are listed separately.

The Serena XML service/scope/message names for a message to list the user-defined variables for a package are:

<service name="PACKAGE"> 
<scope name="USR_RECS"> 
<message name="LIST">

These tags appear in both requests and replies.

Naming Conventions for User-Defined Variables in Serena XML

Serena XML tag names for user-defined package variables take the general form:

<userVarLenxxyy> where:

• xx = length of variable data in bytes, formatted as 1-digit or 2-digit integer

• yy = unique 2-digit integer identifier for this particular variable of length xx

For example, <userVarLen103> represents the third user-defined variable with a length of one byte. Similarly, <userVarLen4405> is the fifth variable with a length of 44 bytes.

ChangeMan ZMF stores these values for user reference at customized exit points, but otherwise ignores them; internally, they are meaningless. Similarly, Serena XML retrieves these values without respect to any meaning they may hold for the user. It is the user’s responsibility to know the meaning of these variables and to manage them accordingly.

PACKAGE USR_RECS LIST — Requests

The following example shows how you might code a request to list user-defined variables for a package in Serena XML. Notice the similarity of this syntax with that of many other package requests.

Example XML — PACKAGE USR_RECS LIST Request

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="USR_RECS">
        <message name="LIST">
            <header>
                <subsys>8</subsys>
                <product>CMN</product>
            </header>
            <request>
                <package>IMSQ000012</package>
            </request>
        </message>
    </scope>
</service>

PACKAGE USR_RECS LIST — Replies

User-defined variable lists for a package return nor more than one <result> tag. This tag is followed by a standard <response> tag that indicates the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher.

An example XML reply to a user-defined variable list request appears below. Because the reply may contain values for up to 72 user-defined variables, many optional tags for these variables are omitted for clarity. Data structure details for the <result> tag follow the example in Exhibit 4-39.

Example XML — PACKAGE USR_RECS LIST Reply

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="USR_RECS">
        <message name="LIST"> 
            <result\> 
                <package>IMSQ000012</package> 
                <applName>IMSQ</applName> 
                <packageId>000012</packageId> 
                <userVarLen199>Y</userVarLen199> 
                <userVarLen301>NO</userVarLen301>
                <userVarLen302>NO</userVarLen302>
                <userVarLen303>NO</userVarLen303>
                <userVarLen304>NO</userVarLen304>
                <userVarLen305>NO</userVarLen305>
                <userVarLen306>NO</userVarLen306>
                <userVarLen401>NO</userVarLen401>
                <userVarLen402>NO</userVarLen402>
                <userVarLen403>NO</userVarLen403>
                <userVarLen404>NO</userVarLen404> 
            </result> 
            <response\> 
                <statusMessage>CMN8700I - LIST User record service completed</ statusMessage>
                <statusReturnCode>00</statusReturnCode> 
                <statusReasonCode>8700</statusReasonCode> 
            </response> 
        </message> 
    </scope> 
</service>

Exhibit 4-39. PACKAGE USR_RECS LIST <result> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name.
<package>	Required	1	String (10), variable	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name.
<userVarLen101> . . . <userVarLen115> <userVarLen199>	Optional	0 - 1 each	String (1)	User-defined in ZMF. Total of 16 individually named 1-byte tags supported. NOTE: See topic "Package User Information" in the ChangeMan ZMF Customization Guide.
<userVarLen201> . . . <userVarLen211>	Optional	0 - 1 each	String (2), variable	User-defined in ZMF. Total of 11 individually named 2-byte tags supported.
<userVarLen301> . . . <userVarLen310>	Optional	0 - 1 each	String (3), variable	User-defined in ZMF. Total of 10 individually named 3-byte tags supported.
<userVarLen401> . . . <userVarLen410>	Optional	0 - 1 each	String (4), variable	User-defined in ZMF. Total of 10 individually named 4-byte tags supported.
<userVarLen801> . . . <userVarLen810>	Optional	0 - 1 each	String (8), variable	User-defined in ZMF. Total of 10 individually named 8-byte tags supported.
<userVarLen1601> . . . <userVarLen1605>	Optional	0 - 1 each	String (16), variable	User-defined in ZMF. Total of 5 individually named 16-byte tags supported.
<userVarLen4401> . . . <userVarLen4405>	Optional	0 - 1 each	String (44), variable	User-defined in ZMF. Total of 5 individually named 44-byte tags supported.
<userVarLen7201> . . . <userVarLen7205>	Optional	0 - 1 each	String (72), variable	User-defined in ZMF. Total of 5 individually named 72-byte tags supported.

Tip

Tags: <userVarLen101> to <userVarLen7205>. See topic "Package User Information" in the ChangeMan ZMF Customization Guide.

List Package Install Sites - SITE PKG LIST

The planned install sites for a package can be listed using Serena XML. This function assumes that the sites themselves already exist, thanks to site maintenance performed elsewhere by the ChangeMan ZMF administrator. The function also assumes that package create or update operations have already assigned install sites to the package. If neither condition is met, no sites will be returned by the package install site list function.

The Serena XML service/scope/message tags for a package install site list message are:

<service name="SITE"> 
<scope name="PKG">
<message name="LIST">

...

These tags appear in both requests and replies.

The service name is "site", not "package", because XML Services calls the low-level site maintenance service in ChangeMan ZMF to perform most tasks associated with this function. The scope name, "pkg", identifies this function as a package-level site service.

SITE PKG LIST — Requests

Serena XML supports two kinds of package install site lists:

• All Install Sites for Package — Name the desired package in the <package> tag. Omit the <siteName> tag. All install sites for the named package are returned, together with site descriptions and installation status information.

• Package Install Status for Site — Name the desired package in the <package> tag and the desired install site in the <siteName> tag. Installation status information is returned for the named package and site.

The following example shows how you might code a Serena XML request to list install status for one remote install site associated with a package.

Example XML — SITE PKG LIST Request

<?xml version="1.0"?>
<service name="SITE">
    <scope name="PKG">
        <message name="LIST">
            <header>
                <subsys>8</subsys>
                <product>CMN</product>
            </header>
            <request>
                <package>IMSQ000012</package>
            </request>
        </message>
    </scope>
</service>

...

SITE PKG LIST — Replies

The Serena XML reply to a package install site list request contains zero to many <result> tags. Each <result> tag contains site description and install status information about one remote site associated with the named package.

A standard <response> tag follows the <result>, where it can serve as an end-of-list marker. It reports the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher.

The example below shows what a package install list reply message might look like. Data structure details for the <result> tag appear after the example in Exhibit 4-40.

Example XML — SITE PKG LIST Reply

<?xml version="1.0"?>
<service name="SITE">
    <scope name="PKG">
        <message name="LIST">
            <result>
                <package>IMSQ000012</package>
                <applName>IMSQ</applName>
                <packageId>000012</packageId>
                <siteName>SERT8</siteName>
                <installDate>20081231</installDate>
                <fromInstallTime>010000</fromInstallTime>
                <toInstallTime>020000</toInstallTime>
                <contactName>DDDDDDDD</contactName>
                <contactPhone>1234567</contactPhone>
                <alternateContactName>DDDDDDDD</alternateContactName>
                <alternateContactPhone>1234567</alternateContactPhone>
                <siteLibModel>CMNTP.SERT8.DEV.IMSQ.\#000012</siteLibModel> 
                <dateSent>20081028</dateSent>
                <timeSent>101800</timeSent>
                <dateReceived>20081028</dateReceived>
                <timeReceived>101800</timeReceived>
                <dateInstalled>20081028</dateInstalled>
                <timeInstalled>101900</timeInstalled>
                <dateBackedOut>20081212</dateBackedOut>
                <timeBackedOut>070200</timeBackedOut>
                <dateReverted>20081212</dateReverted>
                <timeReverted>070500</timeReverted>
                <backoutReasons>TEST</backoutReasons>
                <backoutReason01>TEST</backoutReason01>
                <db2InstallBindJobCount>00</db2InstallBindJobCount>
                <db2BackoutBindJobCount>00</db2BackoutBindJobCount>
                <db2RippleBindJobCount>00</db2RippleBindJobCount>
                <db2ReverseRippleBindJobCount>00</db2ReverseRippleBindJobCount>
                <revertUserid>USER24</revertUserid>

...

                <backoutUserid>USER24</backoutUserid>
                <siteStatus>DEV</siteStatus>
            </result>
            <response>
                <statusMessage>CMN8700I - Site Name service completed</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8700</statusReasonCode>
            </response>
        </message>
    </scope>
</service>

Exhibit 4-40. SITE PKG LIST <result> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<alternateContactName>	Optional	0 - 1	String (25), variable	Name of alternate analyst or point of contact for install problem.
<alternateContactPhone>	Optional	0 - 1	String (15), variable	Phone number of contact in <alternateContactName>.
<applName>	Optional	0 - 1	String (4), fixed	ZMF application name. Same as first 4 bytes of package name.
<backoutReason01> . . . <backoutReason09>	Optional	0 - 1 each	String (72), variable	Up to nine sequential notations for reason package backed out at site. NOTE: If <dateBackedOut> is non-zero, <backoutReason01> is required.
<backoutReasons>	Optional	0 - 1	String (72), variable	Reason package backed out at site.
<backoutUserid>	Optional	0 - 1	String (8), variable	USERID that performed backout.
<contactName>	Optional	0 - 1	String (25), variable	Name of analyst originating package, or point of contact for install problem.
<contactPhone>	Optional	0 - 1	String (15), variable	Phone number of contact in <contactName>.
<dateBackedOut>	Optional	0 - 1	Date (8), yyyymmdd	Date package backed out at site.
<dateInstalled>	Optional	0 - 1	Date (8), yyyymmdd	Date package installed at site.
<dateReceived>	Optional	0 - 1	Date (8), yyyymmdd	Date package received at site.
<dateReverted>	Optional	0 - 1	Date (8), yyyymmdd	Date package reverted.
<dateTempChangeCycled>	Optional	0 - 1	Date (8), yyyymmdd	Date temporary change expired.
<dateSent>	Optional	0 - 1	Date (8), yyyymmdd	Date package sent to site.
<db2BackoutBindJobCount>	Optional	0 - 1	Integer (2), fixed	Number of DB2 backout bind jobs executed at site. NOTE: Requires ZMF DB2 Option.
<db2InstallBindJobCount>	Optional	0 - 1	Integer (2), fixed	Number of DB2 install bind jobs executed at site. NOTE: Requires ZMF DB2 Option.
<db2ReverseRippleBindJobCount>	Optional	0 - 1	Integer (2), fixed	Number of DB2 baseline reverse ripple bind jobs executed at site. NOTE: Requires ZMF DB2 Option.
<db2RippleBindJobCount>	Optional	0 - 1	Integer (2), fixed	Number of DB2 baseline ripple bind jobs executed at site. NOTE: Requires ZMF DB2 Option.
<fromInstallTime>	Optional	0 - 1	Time, hhmmss	Start time for period during which installation of package is planned at named site, 24-hour format.
<installDate>	Optional	0 - 1	Date, yyyymmdd	Planned site install date for package.
<package>	Required	1	String (10), fixed	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name.
<revertUserid>	Optional	0 - 1	String (8), variable	TSOID of reverter.
<siteLibModel>	Optional	0 - 1	String (32), variable	Fully qualified z/OS data set name of library used as model for library setup when package is installed.
<siteName>	Optional	0 - 1	String (8), variable	ZMF name of install site.
<siteStatus>	Optional	0 - 1	String (3), variable	Determined site status.
<timeBackedOut>	Optional	0 - 1	Time (8), hhmmss	Time package backed out, 24-hour.
<timeInstalled>	Optional	0 - 1	Time (8), hhmmss	Time package installed, 24-hour.
<timeReceived>	Optional	0 - 1	Time (8), hhmmss	Time package received, 24-hour.
<timeReverted>	Optional	0 - 1	Time (8), hhmmss	Time package reverted, 24-hour.
<timeSent>	Optional	0 - 1	Time (8), hhmmss	Time package sent, 24-hour.
<timeTempChangeCycled>	Optional	0 - 1	Time (8), hhmmss	Time temporary change expired, 24-hour format.
<toInstallTime>	Optional	0 - 1	Time, hhmmss	End time for period during which installation of package is planned at named site, 24-hour format.

Unfreeze Package Install Sites - PACKAGE SITES UNFREEZE

The Serena XML function to unfreeze package install sites unlocks these site assignments for change. The XML service/scope/message tags for a package-level site unfreeze message are:

<service name="PACKAGE"> 
<scope name="SITES">
<message name="UNFREEZE">

These tags appear in both requests and replies.

PACKAGE SITES UNFREEZE — Requests

The <request> tag syntax for a package install site unfreeze request is identical to that for for many package information management functions, including the package description list and package general description list. Only the name parameters in the high-level <scope> and <message> tags differ, as shown above.

PACKAGE SITES UNFREEZE — Replies

The Serena XML reply message to an unfreeze request for package install sites does not return a <result> data structure. It does, however, return a standard <response> data structure to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher.

Refreeze Package Install Sites - PACKAGE SITES REFREEZE

The Serena XML refreeze function for package install sites resets these previously unfrozen assignments to frozen status, locking them down against change.

The XML service/scope/message tags for a package-level site refreeze message are:

<service name="PACKAGE"> 
<scope name="SITES">
<message name="REFREEZE">

These tags appear in both requests and replies.

PACKAGE SITES REFREEZE — Requests

The <request> tag syntax for a general package parameters refreeze request is identical to that for an unfreeze request. Only the name parameter in the high-level <message> tag differs, as shown above.

PACKAGE SITES REFREEZE — Replies

The Serena XML reply message to a refreeze request for package install sites does not return a <result> data structure. It does, however, return a standard <response> data structure to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher.

List Package Installation Dependencies - PACKAGE SCH_RECS LIST

ChangeMan ZMF captures package installation dependencies in the package installation schedule records. Serena XML can list all such dependency records for a package, or can selectively determine whether a dependency exists between a package and a particular job.

The Serena XML service/scope/message names for message to list package installation dependency records are:

<service name="PACKAGE"> 
<scope name="SCH_RECS"> 
<message name="LIST">

These tags appear in both request and reply messages.

PACKAGE SCH_RECS LIST — Requests

Serena XML supports two types of package installation dependency requests:

• List All Installation Dependencies — Name the desired package in the tag. Omit the and ; tags, or enter a "matchall" (asterisk) wild card in each. The function returns a list of all predecessor and successor jobs that must execute before or after package installation to complete a successful install.

• Selective Installation Dependency Check — Name the desired package in the tag. Enter the job name to check for an installation dependency in the tag, the tag, or both as appropriate. Optionally, enter a wildcard pattern to check for several similar job names. The function returns installation scheduling dependency information for the named job(s) if such dependencies exist. Otherwise, no <result> is returned in the reply message.

The following example shows how you might code a request to list all package installation dependencies in Serena XML. Notice the use of match-all wildcard characters in the and tags. Data structure details for the <request> tag appear in Exhibit 4-41.

Example XML — PACKAGE SCH_RECS LIST Request

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="SCH_RECS">
        <message name="LIST">
            <header>
                <subsys>8</subsys>
                <product>CMN</product>
            </header>
            <request>
                <package>TES5000001</package>
            </request>
        </message>
    </scope>
</service>

Exhibit 4-41. PACKAGE SCH_RECS LIST <request>

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of package name. NOTE: OK to omit trailing blanks. NOTE: Not recommended to replace <package>. Use <package> instead of <applName> & <packageId>.
<package>	Required	1	String (10), fixed	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name. NOTE: Leading zeroes required. NOTE: Not recommended. Use <package> instead of <applName> & <packageId>.
<predecessorJob>	Optional	0 - 1	String (8), variable	Name of job(s) that must run before package is installed. NOTE: Accepts standard wildcards & patterns using question mark (?) & asterisk (). NOTE: Omit tag or use asterisk () wildcard to list all predecessor jobs.
<successorJob>	Optional	0 - 1	String (8), variable	Name of job(s) that must run after package is installed. NOTE: Accepts standard wildcards & patterns using question mark (?) & asterisk (). NOTE: Omit tag or use asterisk () wildcard to list all successor jobs.

PACKAGE SCH_RECS LIST — Replies

Serena XML returns zero to many <result> tags in package installation dependency list reply. Each <result> tag contains the name of a predecessor job, a successor job, or both that the package requires for successful installation. The <result> tag recurs as needed to accommodate all scheduled predecessor and successor jobs.

A standard <response> tag follows the last <result> tag to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher. As the last tag returned in the reply message, the <response> tag may serve as an end-of-list marker.

An example XML reply that lists package installation scheduling records appears on the next page. Data structure details for the <result> tag follow in Exhibit 4-42.

Example XML — PACKAGE SCH_RECS LIST Reply

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="SCH_RECS">
        <message name="LIST">
            <result>
                <package>TES5000001</package>
                <applName>TES5</applName>
                <packageId>000001</packageId>
                <successorJob>SCHJOB01</successorJob>
                <predecessorJob>SCHJOB02</predecessorJob>
            </result>
            <response>
                <statusMessage>CMN8700I - LIST service completed</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8700</statusReasonCode>
            </response>
        </message>
    </scope>
</service>

...

Exhibit 4-42. PACKAGE SCH_RECS LIST <result>

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of package name.
<package>	Optional	1	String (10), fixed	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name.
<predecessorJob>	Optional	0 - 1	String (8), variable	Name of a job that must run before package is installed.
<successorJob>	Optional	0 - 1	String (8), variable	Name of a job that must run after package is installed.

...

List Package Implementation Instructions - PACKAGE IMP_INST LIST

You can retrieve package implementation instructions independently of other package parameters using Serena XML. Results are returned for one package.

The Serena XML service/scope/message names for message to list implementation instructions for a package are:

<service name="PACKAGE"> 
<scope name="IMP_INST"> 
<message name="LIST">

These tags appear in both request and reply messages.

PACKAGE IMP_INST LIST — Requests

The tag syntax for request to list package implementation instructions is identical to that for many package information management functions, including the package description list and package general description list. Only the name parameter in the highlevel <scope> tag differs, as shown above.

PACKAGE IMP_INST LIST — Replies

The reply message for a package implementation instruction list includes one <result> tag with package name and implementation instructions, if the package is found. This tag is followed by a standard <response> tag that indicates the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher.

An example XML reply to a package description list request appears below. Data structure details for the <result> tag follow the example in Exhibit 4-43.

Example XML — PACKAGE IMP_INST LIST Reply

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="IMP_INST">
        <message name="LIST">
            <result>
                <package>TES5000001</package>
                <applName>TES5</applName>
                <packageId>000001</packageId>
                <packageImplInst>CR153620</packageImplInst>
            </result>
            <response>
                <statusMessage>CMN8700I - LIST service completed</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8700</statusReasonCode>
            </response>
        </message>
    </scope>
</service>

...

Exhibit 4-43. PACKAGE IMP_INST LIST <result>

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), fixed	ZMF application name. Same as first 4 bytes of package name.
<package>	Optional	1	String (10), fixed	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name.
<packageImplInst>	Optional	0 - 46	String (72), variable	Implementation instructions in free format text. Repeatable to accommodate multiple lines of text.

...

List Package Approvers - APPROVER PKG LIST

The Serena XML function to list package approvers retrieves an instantiated list of actual approvers for a named package. Actual approvers are those relevant to the named package after applying the approver business rules established by your administrator. They comprise a subset of relevant application approvers, emergency approvers for unplanned or temporary changes, and approvers assigned to review this package by a customized ChangeMan ZMF exit.

Note

The list of authorized approvers for a package, before the application of business rules, is associated with the parent application of the package rather than the package itself. Application approvers are retrieved with a different Serena XML function.

The Serena XML service/scope/message tags for a message to list package approvers are:

<service name="APPROVER">
<scope name="PKG">
<message name="LIST">

These tags appear in both request and reply messages.

The service name is "approver", not "package", because XML Services calls the lowlevel approver maintenance service in ChangeMan ZMF to perform most tasks associated with this function. The scope name, "pkg", identifies this function as a package-level service.

APPROVER PKG LIST — Requests

Serena XML supports two types of package approver lists:

• All Approvers for Named Package — Name the desired package in the tag. Enter a "match-all" (asterisk) wildcard character in the <approverEntity> tag or omit it altogether. Returns all package approvers and reports their approval actions (approved, rejected, reviewing, no response).

• Approval Activity for Named Approver(s) — Name the desired package in the tag. Enter the desired approver entity ID, as defined to RACF or other security system, in the <approverEntity> tag. Returns approver description for all TSO user IDs associated with the named approver entity and reports their approval actions (approved, rejected, reviewing, no response).

The following example shows how you might code a request to list all approvers for a package. Data structure details for the tag appear in Exhibit 4-44.

Example XML — APPROVER PKG LIST Request

<?xml version="1.0"?>
<service name="APPROVER">
    <scope name="PKG">
        <message name="LIST">
            <header>
                <subsys>8</subsys>
                <product>CMN</product>
            </header>
            <request>
                <package>ACTP000007</package>
            </request>
        </message>
    </scope>
</service>

...

Exhibit 4-44. APPROVER PKG LIST <request> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of package name. NOTE: OK to omit trailing blanks. NOTE: Not recommended to replace . Use <package> instead of <applName> & <packageId>.
<approverEntity>	Optional	0 - 1	String (8), variable	TSO user ID or security system entity ID of desired package approver. NOTE: Accepts standard wildcards & patterns using question mark (?) & asterisk (). NOTE: Omit tag or use asterisk () wildcard to list all approver entities.
<package>	Required	1	String (10), fixed	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name. NOTE: Leading zeroes required. NOTE: Not recommended. Use <package> instead of <applName> & <packageId>.

...

APPROVER PACKAGE LIST — Replies

The Serena XML reply to a package approver list request returns zero to many <result> tags. Each <result> tag contains information about one package approver, including TSO user ID, the associated approver entity defined in RACF (or other security system), an approver entity description, and approver status in the approval process. If multiple TSO user IDs are associated with the RACF approval entity, each generates a separate <result> tag.

A standard <response> data element follows the last <result> tag, if any, to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher. As the last tag returned in the reply message, the <response> tag serves as an end-of-list marker.

An example XML reply that lists package approvers appears below. Data structure details for the <result> tag follow in Exhibit 4-45.

Example XML — APPROVER PKG LIST Reply

<?xml version="1.0"?>
<service name="APPROVER">
    <scope name="PKG">
        <message name="LIST">
            <result>
                <package>ACTP000007</package>
                <applName>ACTP</applName>
                <packageId>000007</packageId>
                <approverEntity>ACTPLEAD</approverEntity>
                <approverDesc>Lead Programmer - ACTP Application</approverDesc>
                <approverAction>1</approverAction>
                <approvedDate>20090127</approvedDate>  
                <approvedTime>083100</approvedTime>
                <approver>USER24</approver>
                <approvalOrder>10</approvalOrder>
                <userListCount>02</userListCount>
                <isApproverNotified>Y</isApproverNotified>
                <postApprovalNoticeEnabled>N</postApprovalNoticeEnabled>
                <notification>
                    <notifierType>4</notifierType>
                    <userList>USER24@SERENA.COM;USER24</userList>
                </notification>
                <notification>
                    <notifierType>1</notifierType>
                    <userList>USER24</userList>
                </notification>
            </result>

...

            <result>
                <package>ACTP000007</package>
                <applName>ACTP</applName>
                <packageId>000007</packageId>
                <approverEntity>ACCTPAY</approverEntity>
                <approverDesc>Accounts Payable Manager</approverDesc>
                <approverAction>1</approverAction>
                <approvedDate>20090127</approvedDate>
                <approvedTime>083100</approvedTime>
                <approver>USER24</approver>
                <approvalOrder>20</approvalOrder>
                <userListCount>01</userListCount>
                <isApproverNotified>Y</isApproverNotified>
                <postApprovalNoticeEnabled>N</postApprovalNoticeEnabled>
                <notification>
                    <notifierType>4</notifierType>
                    <userList>USER24@SERENA.COM;USER24</userList>
                </notification>
            </result>
            <response>
                <statusMessage>CMN8700I - LIST service completed</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8700</statusReasonCode>
            </response>
        </message>
    </scope>
</service>

...

Exhibit 4-45. APPROVER PKG LIST <result> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), fixed	ZMF application name. Same as first 4 bytes of package name.
<approvalOrder>	Optional	0 - 1	Integer (2), variable	Approval level or sequence assigned to this approver entity for hierarchical approvals.
<approvedDate>	Optional	0 - 1	Date, yyyymmdd	Date package approval action taken by this approver. No punctuation.
<approvedTime>	Optional	0 - 1	Time, hhmmss	Time package approval action taken by this approver. No punctuation.
<approver>	Optional	0 - 1	String (8), variable	TSO user ID of individual approver. Mapped to <approverEntity> by RACF or other security system.
<approverAction>	Optional	0 - 1	Integer (1)	Code for most recent approval action of approver entity. Values: 1 = Approved 2 = Checkoff 3 = Rejected 4 = Review pending 5 = No response to notification
<approverDesc>	Optional	0 - 1	String (44), variable	Text description of approver level or function (e.g., project leader, QA manager) for <approverEntity>.
<approverEntity>	Optional	1	String (8), variable	Security system entity ID of package approver. Mapped to TSO user ID in <approver> by RACF or other security system.
<checkoffList>	Optional	0 - 14	String (72), variable	Checkoff list.
<checkoffList01> . . . <checkoffList14>	Optional	0 - 1 each	String (72), variable	Text descriptions for up to 14 possible approval actions taken by approver from custom-defined checkoff list. NOTE: At least one tag required if value in <approverAction> = 2.
<isApproverNotified>	Optional	0 - 1	String (1), variable	Has approver entity been notified that approval action is requested? Y = Yes N = No
<isLinkedApprover>	Optional	0 - 1	String (1), variable	Is this a linked package approver? Y = Yes N = No
<notification>	Optional	0 - 35	Complex	Describes notifications sent when this approver takes an approval action. See Exhibit 4-46.
<package>	Optional	1	String (10), fixed	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name.
<postApprovalNoticeEnabled>	Optional	0 - 1	String (1), variable	Is this approver to be notified of emergency/temporary changes for post-installation approval review? Y = Yes N = No
<rejectReasons>	Optional	0 - 10	String (72), variable	Reject reasons.
<rejectReasons01> . . . <rejectReasons10>	Optional	0 - 1 each	String (72), variable	Up to ten sequentially numbered, free-format text entries containing reason(s) for package rejection by approver. NOTE: At least one tag required if value in <approverAction> = 3.
<userListCount>	Optional	0 - 1	Integer(2)	The number of users to notify, the number of returned <notification> complex tags.

...

<notification> Subtag

The <notification> tag describes the notifications to be issued when this approver entity takes an approval action. The tag represents a complex data structure with subtags of its own. It is repeatable to accommodate multiple approvers and multiple notification methods. Data structure details for this tag appear in Exhibit 4-46.

Exhibit 4-46. <notification> Subtag Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<notifierType>	Optional	0 - 1	Integer (1)	ZMF code for notification method to use with notifications sent to users in <userList>. Values: 1 = MVS Send message 2 = E-mail 3 = SERNET email msg 4 = Batch messaging job
<userList>	Optional	0 - 1	String (44), variable	List of individual approvers to notify when the named approver entity takes an approval action. List consists of user TSO IDs or E-mail addresses separated by commas. NOTE: TSO IDs required if <notifierType> = 1. NOTE: E-mail addresses required if <notifierType> = 4 or 5.

List Affected Applications - PACKAGE AFF_APLS LIST

List the applications affected by a complex/super package using the Serena XML function to list affected applications for a package. This function includes only complex and super packages in its scope.

The Serena XML service/scope/message tags for a message to list applications affected by a complex/super package are:

<service name="PACKAGE"> 
<scope name="AFF_APLS"> 
<message name="LIST">

These tags appear in both request and reply messages.

PACKAGE AFF_APLS LIST — Requests

The <request> tag syntax for a request to list affected applications is identical to that for a request to list general package parameters. Only the name parameter in the high-level <scope> tag differs, as shown above. However, additional data constraints apply. (See Exhibit 4-47).

Exhibit 4-47. PACKAGE AFF_APLS LIST <request> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of package name. NOTE: OK to omit trailing blanks. NOTE: Not recommended as substitute. Use <package> instead of <applName> & <packageId>.
<package>	Required	0 - 1	String (10), fixed	Fixed-format ZMF package name for the complex/super package.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name. NOTE: Leading zeroes required. NOTE: Not recommended. Use <package> instead of <applName> & <packageId>.

...

PACKAGE AFF_APLS LIST — Replies

The Serena XML reply message for this function returns zero to many <result> tags. Each <result> contains names one application affected by the named complex/super package. If no participating packages are attached to the complex/super package, no <result> tags are returned.

A standard <response> tag follows the last <result> tag, if any, to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher. As the last tag returned in the reply message, the <response> tag may serve as an end-of-list marker.

An example XML reply that lists all affected applications for a package appears below. Data structure details for the <result> tag follow in Exhibit 4-48.

Example XML — PACKAGE AFF_APLS LIST Reply

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="AFF_APLS">
        <message name="LIST">
            <result>
                <package>TES5000003</package>
                <applName>TES5</applName>
                <packageId>000003</packageId>
                <affectedAppl>ACTP</affectedAppl>
            </result>
            <response>
                <statusMessage>CMN8700I - LIST service completed</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8700</statusReasonCode>
            </response>
        </message>
    </scope>
</service>

...

Exhibit 4-48. PACKAGE AFF_APLS LIST <result> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<affectedAppl>	Optional	0 - 1	String (8), variable	ZMF application name for a participating package.
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of package name.
<package>	Optional	0 - 1	String (10), fixed	Fixed-format ZMF package name for the complex/super package.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name.

...

List Participating Packages - PACKAGE PRT_PKGS LIST

List the participating applications in a complex/super package using the Serena XML function to list participating packages. This function includes only complex/super packages in its scope.

The Serena XML service/scope/message tags for a message to list participating packages for a complex/super package are:

<service name="PACKAGE"> 
<scope name="PRT_PKGS"> 
<message name="LIST">

These tags appear in both request and reply messages.

PACKAGE PRT_PKGS LIST — Requests

The <request> tag syntax for a request to list participating packages is identical to that for a request to list affected applications. (See Exhibit 4-47.) Only the name parameter in the highlevel <scope> tag differs, as shown above.

PACKAGE PRT_PKGS LIST — Replies

The Serena XML reply message for this function returns zero to many <result> tags. Each <result> names one participating package in the named complex/super package. If no participating packages are attached to the complex/super package, no <result> tags are returned.

A standard <response> tag follows the last <result> tag, if any, to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher. As the last tag returned in the reply message, the <response> tag may serve as an end-of-list marker.

An example XML reply that lists participating packages follows. Data structure details for the <result> tag appear in Exhibit 4-49.

Example XML — PACKAGE PRT_PKGS LIST Reply

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="PRT_PKGS">
        <message name="LIST">
            <result>
                <package>TES5000002</package>
                <applName>TES5</applName>
                <packageId>000002</packageId>
                <partPackage>TES5000003</partPackage>
            </result>
            <response>
                <statusMessage>CMN8700I - LIST service completed</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8700</statusReasonCode>
            </response>
        </message>
    </scope> 
</service>

...

Exhibit 4-49. PACKAGE PRT_PKGS LIST <result> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of package name.
<package>	Optional	0 - 1	String (10), fixed	Fixed-format ZMF package name of complex/super package.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name.
<partPackage>	Optional	0 - 1	String (10), variable	Fixed-format ZMF name of participating package in the complex/super package named in <package>.

...

List Linked Packages - PACKAGE PKG_LINK LIST

Serena XML provides a means for ChangeMan ZMF customers to list any packages on remote LPARs or non-mainframe servers that are linked (via external software) to an explicitly named ChangeMan ZMF package on the local mainframe LPAR. Only simple packages on the local LPAR are included in the scope of this function.

The XML service/scope/message names for a message to list linked packages are:

<service name="PACKAGE"> 
<scope name="PKG_LINK">
<message name="LIST">

These tags appear in both request and reply messages.

PACKAGE PKG_LINK LIST — Request

Serena XML supports the following linked package list options:

• All Remote Packages Linked to a Local Package — Name the desired local package in the <package> tag. Omit all other subtags of the <request> element. The function returns a list of all remote packages linked to the local package.

• All Local Packages Linked to a Remote Package — Name the desired remote package in the <linkPackage> tag. The package naming conventions of the remote system are accepted in <linkPackage>. Omit all other subtags of the <request> data element. The function returns a list of all local packages linked to the named remote package.

• All Local Packages Linked to Packages on a Remote Server — In tag <sourceLinkIpAddress>, enter the name or IP address of the desired remote server. Use the same naming or addressing conventions used by the remote link management software when it passes these values to ChangeMan ZMF. Omit all other subtags of the <request> data element. The function returns a list of all local packages linked to remote packages that reside on the named remote server.

• All Local Packages Linked Elsewhere by a User — Enter the name or TSO user ID of the desired link requestor in the <linkRequestor> tag. Omit all other subtags of the <request> data element. The function returns a list of all local packages linked to remote packages when those links were requested by the named user.

The following example shows how you might code a request to list all remote, linked packages for a named local package using Serena XML. Data structure details for the linked package list tag appear in Exhibit 4-50.

Example XML — PACKAGE PKG_LINK LIST Request

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="PKG_LINK">
        <message name="LIST">
            <header>
                <subsys>8</subsys>
                <product>CMN</product>
            </header>
            <request>
                <package>TES5000003</package>
            </request>
        </message>
    </scope>
</service>

...

Exhibit 4-50. PACKAGE PKG_LINK LIST <request> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of package name.
<linkPackage>	Optional	0 - 1	String (255), variable	Name(s) of one or more linked package(s) on remote server, delimited by semicolons. Package naming conventions are those of remote system.
<linkRequestor>	Optional	0 - 1	String (20), variable	Name or TSO user ID of package link requestor.
<package>	Required	0 - 1	String (10), fixed	Fixed-format ZMF package name for target package on local LPAR.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of package name.
<sourceLinkIpAddress>	Optional	0 - 1	String (255), variable	Network IP address for remote server where linked package resides. NOTE: ZMF stores address as provided by external link management software. May contain server name known to that software instead of an IP address.
<sourceLinkPortid>	Optional	0 - 1	String (8), variable	Network port ID for remote server where linked package resides.

...

PACKAGE PKG_LINK LIST — Replies

The linked package list reply contains zero to many <result> tags. Each <result> contains information about a package on the local LPAR that is linked to at least one remote package with the requested characteristics. Remote package name(s), application, server, and link requestor are included as they are stored in the package master records for the local package. Information such as package level, type, and status pertain to the local package, not the linked remote package(s).

A standard <response> data structure follows the <result> tags, if any, to indicate the success or failure of the list request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher. As the last data element returned in a Serena XML reply message, the <response> tag serves as an end-of-list marker.

An example reply to a linked package list request follows. Data structure details for the linked package list <result> tag appear in Exhibit 4-51.

Example XML — PACKAGE PKG_LINK LIST Reply

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="PKG_LINK">
        <message name="LIST">
            <result>
                <package>TES5000003</package>
                <applName>TES5</applName>
                <packageId>000003</packageId>
                <packageLevel>4</packageLevel>
                <packageType>1</packageType>
                <packageStatus>6</packageStatus>
                <installDate>20091231</installDate>
                <linkPackage></linkPackage>
                <sourceLinkIpAddress></sourceLinkIpAddress>
            </result>
            <response>
                <statusMessage>CMN8764I - Package is not Linked.</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8764</statusReasonCode>
            </response>
        </message>
    </scope>
</service>

...

Exhibit 4-51. PACKAGE PKG_LINK LIST <result> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of <package>.
<installDate>	Optional	0 - 1	Date, yyyymmdd	Planned install date for local package.
<linkDate>	Optional	0 - 1	Date, yyyymmdd	Link date.
<linkPackage>	Optional	0 - 1	String (255), variable	Name(s) of one or more linked package(s) on remote server, delimited by semicolons. Naming conventions are those of remote system.
<linkRequestor>	Optional	0 - 1	String (20), variable	Name or TSO user ID of package link requestor.
<linkTime>	Optional	0 - 1	Time, hhmmss	Link time
<package>	Optional	0 - 1	String (10), fixed	ZMF fixed-format package name for local package.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of <package>.
<packageLevel>	Optional	0 - 1	String (1)	Code for package complexity or level in hierarchy of local package. Values: 1 = Simple package 2 = Complex package 3 = Super package 4 = Participating package
<packageStatus>	Optional	0 - 1	String (1)	Code for status of local package in lifecycle. Values: 1 = Approved 2 = Backed out 3 = Baselined 4 = Complex/super pkg closed 5 = Deleted (memo delete) 6 = Development 7 = Distributed 8 = Frozen 9 = Installed A = Complex/super pkg open B = Rejected C = Temporary change cycle completed
<packageType>	Optional	0 - 1	String (1)	Code for package install type of local package. Values: 1 = Planned permanent 2 = Planned temporary 3 = Unplanned permanent 4 = Unplanned temporary
<sourceLinkIpAddress>	Optional	0 - 1	String (255), variable	Network IP address for remote server where linked package resides. NOTE: ZMF stores address as provided by external link management software. May contain server name known to that software instead of an IP address.
<sourceLinkPortid>	Optional	0 - 1	String (8), variable	Network port ID for remote server where linked package resides.

...

List Package Library Types - LIBTYPE PKG LIST

You can retrieve library type specifications for a package using the Serena XML package

library type list function. These specifications are defined separately by your ChangeMan ZMF administrator.

The Serena XML service/scope/message tags and attributes for messages to list package library type records are:

<service name="LIBTYPE">
<scope name="PKG">
<message name="LIST">

These tags appear in both requests and replies.

The service name is "libtype", not "package", because XML Services calls the low-level library type management service in ChangeMan ZMF to perform most tasks associated with this function. The scope name, "pkg", identifies this message as a package-level service.

LIBTYPE PKG LIST — Requests

You can request specifications for one or more library types defined for a named package. To retrieve all library type specifications for the package, no library type name is required. Specifications for an explicitly named library can also be requested. Filtering by DB2 library type is an additional option.

The following example shows how you might code a request to list all library types for a package that are not DB2 libraries. Data structure details for the data element appear in Exhibit 4-52.

Example XML —LIBTYPE PKG LIST Request

<?xml version="1.0"?>
<service name="LIBTYPE">
    <scope name="PKG">
        <message name="LIST">
            <header>
                <subsys>8</subsys>
                <product>CMN</product>
            </header>
            <request>
                <package>IMSQ000012</package>
            </request>
        </message>
    </scope>
</service>

...

Exhibit 4-52. LIBTYPE PKG LIST <request> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of <package>. NOTE: OK to omit trailing blanks. NOTE: Not recommended as <package> substitute. Use <package> instead of <applName> & <packageId>.
<isDb2LibType>	Optional	0 - 1	String (1)	Y = Include only DB2 libraries. N = Omit all DB2 libraries. NOTE: Omit tag or use asterisk (*) wildcard to request both DB2 and nonDB2 library types.
<libType>	Optional	0 - 1	String (3), variable	Name of specific library type to list. NOTE: Omit tag or use asterisk (*) wildcard to request all library types.
<package>	Optional	0 - 1	String (10), fixed	Fixed-format ZMF name of package for which library type info is requested.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of <package>. NOTE: Leading zeroes required. NOTE: Not recommended. Use <package> instead of <applName> & <packageId>.

...

LIBTYPE PKG LIST — Replies

The reply message listing package library types returns zero to many <result> data elements. Each <result> tag contains specifications for one library type defined for the named package.

The standard <response> data element follows any <result> tags in the reply and indicates the success or failure of the list request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher. Because it is the final data element in the XML reply message, the <response> tag serves as an end-of-list marker.

The following example shows what a Serena XML package library list reply message might look like. Data structure details for the <result> tag appear in Exhibit 4-53.

Example XML — LIBTYPE PKG LIST Reply

<?xml version="1.0"?>
<service name="LIBTYPE">
    <scope name="PKG">
        <message name="LIST">
            <result>
                <package>IMSQ000012</package>
                <applName>IMSQ</applName>
                <packageId>000012</packageId>
                <libType>CPC</libType>
                <likeType>1</likeType>
                <isPdseLibType>N</isPdseLibType>
                <chkOutComponentGenDesc>N</chkOutComponentGenDesc>
                <chkOutActivityFile>N</chkOutActivityFile>
                <deferStageLibCreation>Y</deferStageLibCreation>
                <includeUtilityInfo>N</includeUtilityInfo>
                <libTypeDesc>Copybooks common</libTypeDesc>
                <isImsLibType>N</isImsLibType>
                <isDb2LibType>N</isDb2LibType>
                <ddlSqlSubType>N</ddlSqlSubType>
                <storedProcSubType>N</storedProcSubType>
                <triggerSubType>N</triggerSubType>
                <bindControlSubType>N</bindControlSubType>
                <packageBindControlSubType>N</packageBindControlSubType>
                <sqlStoredProcDefinition>N</sqlStoredProcDefinition>
            </result>  
            .
            . 
            .
            <response> 
                <statusMessage>CMN8600I - The package library type list is complete.</ statusMessage>
                <statusReturnCode>00</statusReturnCode>  
                <statusReasonCode>8600</statusReasonCode>
            </response> 
        </message>  
    </scope> 
</service>

...

Exhibit 4-53. LIBTYPE PKG LIST <result> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of .
<apsDevLib>	Optional, APS only	0 - 1	String (44), variable	Name of APS development library associated with this ZMF library type. NOTE: If <isApsLibType> is Y, this tag is required.
<apsEntity>	Optional, APS only	0 - 1	String (8), variable	Name of APS entity type associated with this ZMF library type. NOTE: If <isApsLibType> is Y, this tag is required.
<bindControlSubType>	Optional, DB2 only	0 - 1	String (1)	Y = Yes, bind control library subtype N = No, not bind control library subtype
<chkOutActivityFile>	Optional	0 - 1	String (1)	Y = Yes, copy component to activity file at checkout N = Don’t make activity file copy NOTE: Tag also required if value is Y.
<chkOutComponentGenDesc>	Optional	0 - 1	String (1)	Y = Yes, copy component general description to staging change description at checkout N = No, leave component change description blank in staging at checkout
<db2SqlTerminationChar>	Optional, DB2 only	0 - 1	String (1)	DB2 SQL sentence termination character.
<dbrmSubType>	Optional	0 - 1	String (1)	Y = Yes, DBRM subtype N = Not DBRM subtype
<ddlSqlSubType>	Optional, DB2 only	0 - 1	String (1)	Y = Yes, SQL DDL library subtype N = No, not SQL DDL library subtype
<deferStageLibCreation>	Optional	0 - 1	String (1)	Y = Yes, defer allocation of library type in staging library to first component checkout N = No, don’t defer library allocation
<imsEntity>	Optional, IMS only	0 - 1	String (1)	Code for IMS entity type associated with this ZMF library type. Values: 1 = PSB source 2 = DBD source
				3 = MFS source 4 = PSB target 5 = DBD target 6 = FMT target 7 = REF target NOTE: If is Y, this tag is required.
<includeUtilityInfo>	Optional	0 - 1	String (1)	Y = Yes, include scratch/rename utility info with library type. N = No, omit scratch/rename info.
<isApsLibType>	Optional	0 - 1	String (1)	Y = Yes, this is APS library type N = No, not APS library type
<isDb2LibType>	Optional	0 - 1	String (1)	Y = Yes, this is DB2 library type N = No, not DB2 library type
<isHfsLibType>	Optional	0 - 1	String (1)	Y = Yes, this is HFS library type N = No, not HFS library type
<isImsLibType>	Optional	0 - 1	String (1)	Y = Yes, this is IMS library type N = No, not IMS library type NOTE: Tag also required if value is Y.
<isPdseLibType>	Optional	0 - 1	String (1)	Y = Yes, this is PDSE library type N = No, not PDSE library type
<libType>	Required	1	String (3), variable	Name of library type for which specifications are reported.
<libTypeDesc>	Optional	0 - 1	String (44), variable	Text description of library type.
<librarySequenceNo>	Optional	0 - 1	Integer	Library sequence number
<likeType>	Optional	0 - 1	String (1)	Code for "like-library" type assigned to library type name. Values: 1 = Like Copy Library 2 = Like Load Library 3 = Like Other Library 4 = Like PDS Library 5 = Like Source Library 6 = Like Ncal Library 7 = Like Object Library NOTE: Tag <targetLoadLibType> also required if value is 5.
<package>	Required	1	String (10), fixed	ZMF fixed-format package name.
<packageBindControlSubType>	Optional, DB2 only	0 - 1	String (1)	Y = Yes, package bind control subtype N = No, not package bind ctrl subtype
	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of .
<sqlStoredProcDefinition>	Optional, DB2 only	0 - 1	String (1)	Y = Yes, SQL stored proc definition N = No, not SQL stored proc definition
<storedProcSubType>	Optional, DB2 only	0 - 1	String (1)	Y = Yes, DB2 stored procedure subtype N = No, not stored procedure subtype
<targetActivityFile>	Optional	0 - 1	String (3), variable	Name of target activity file library type associated with this library. NOTE: This tag is required if value in <chkOutActivityFile> is Y.
<targetLoadLibType>	Optional	0 - 1	String (3), variable	Name of "like-Load" target library type associated with this source library. NOTE: This tag is required if value in <likeLibType> is 5.
<triggerSubType>	Optional, DB2 only	0 - 1	String (1)	Y = Yes, DB2 trigger library subtype N = No, not DB2 trigger library subtype

...

List Package Promotion History - PACKAGE PRM_HIST LIST

Promotion history records for a package as a whole can be listed using the package promotion history list function. Promotion history listings for components in a package require a different Serena XML function. (See Package Promoted Component List - PACKAGE PRM_CMP LIST.)

The Serena XML service/scope/message names for a package promotion history list message are:

<service name="PACKAGE"> 
<scope name="PRM_HIST"> 
<message name="LIST">

...

These tags appear in both requests and replies.

PACKAGE PRM_HIST LIST — Request

This function supports two promotion history request types:

• All Promotion Actions at All Sites — Name the desired package in the tag and enter a "1" in the <requestType> tag. Returns a complete history of all promotion and demotion actions taken against the named package on all sites.

• Current Promotion Status at Selected Site(s) — Name the desired package in the tag and enter a "2" in the <requestType> tag. Specify a site of interest in the <promotionSiteName> tag; for all sites, omit this tag or enter a "match-all" (asterisk) wildcard character. Returns the current promotion status of the named package at the specified sites. If the site has prior promotion history, then that information is returned. If the only history associated with the site is the ‘submitted’ request, then no information is returned for the site.

To further narrow either type of request, specify a promotion level or site of interest. You can also filter promotion status and promotion action using appropriate yes/no flag tags.

Note

Yes/no flags for status and action filtering each take default values as a group. The default changes based on whether or not you enter explicit values in these tags, as follows:

• If no status flag in a group has an explicitly typed value, the default for all tags in that group is "Y".

• If any status flag in a group has an explicitly typed value, the default for the remaining tags in the group is "N".

The following example shows how you might code a request to list the full package promotion history for all promotion sites where a "selective promote" or "selective demote" is the most recent promotion action taken for a package. Data structure details follow in Exhibit 4-54.

Example XML — PACKAGE PRM_HIST LIST Request

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="PRM_HIST">
        <message name="LIST">
            <header>
                <subsys>8</subsys>
                <product>CMN</product>
            </header>
            <request>
                <package>IMSQ000012</package>
            </request>
        </message>
    </scope>
</service>

...

Exhibit 4-54. PACKAGE PRM_HIST LIST <request> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of <package>.
<firstPromotion>	Optional	0 - 1	String (1)	Y = Yes, include first promotes N = No, omit first promotes NOTE: Member of promotion action flag tag group. If no tag in group has explicit value, default value is Y. If any tag in group has explicit value, default is N.
<fullDemotion>	Optional	0 - 1	String (1)	Y = Yes, include full demotes N = No, omit full demotes NOTE: Member of promotion action flag tag group. If no tag in group has explicit value, default value is Y. If any tag in group has explicit value, default is N.
<fullPromotion>	Optional	0 - 1	String (1)	Y = Yes, include full promotes N = No, omit full promotes NOTE: Member of promotion action flag tag group. If no tag in group has explicit value, default value is Y. If any tag in group has explicit value, default is N.
<jobBuilt>	Optional	0 - 1	String (1)	Y = Yes, include built jobs N = No, omit built jobs NOTE: Member of promotion status flag tag group. If no tag in group has explicit value, default value is Y. If any tag in group has explicit value, default is N.
<jobCompleted>	Optional	0 - 1	String (1)	Y = Yes, include completed jobs N = No, omit completed jobs NOTE: Member of promotion status flag tag group. If no tag in group has explicit value, default value is Y. If any tag in group has explicit value, default is N.
<jobFailed>	Optional	0 - 1	String (1)	Y = Yes, include failed jobs N = No, omit failed jobs NOTE: Member of promotion status flag tag group. If no tag in group has explicit value, default value is Y. If any tag in group has explicit value, default is N.
<jobSubmitted>	Optional	0 - 1	String (1)	Y = Yes, include submitted jobs N = No, omit submitted jobs NOTE: Member of promotion status flag tag group. If no tag in group has explicit value, default value is Y. If any tag in group has explicit value, default is N.
<package>	Required	1	String (10), variable	Fixed-format ZMF package name.
	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of .
<promotionName>	Optional	0 - 1	String (8), variable	ZMF promotion level nickname for which promotion history is requested. NOTE: Accepts standard wildcards & patterns using question mark (?) & asterisk (*).
<promotionSiteName>	Optional	0 - 1	String (8), variable	ZMF name of promotion site for which promotion history or status requested. NOTE: Accepts standard wildcards & patterns using question mark (?) & asterisk (*). NOTE: Omit tag or use asterisk (*) wildcard to list all promotion sites, regardless of request type.
<requestType>	Optional	0 - 1	String (255, variable	Code for type of promotion history list requested. Values: 1 = Full promotion history (default) 2 = Site promotion status 3 = Full promotion history, including site locks.
<selectiveDemotion>	Optional	0 -	String (1)	Y = Yes, include selective demotes N = No, omit selective demotes NOTE: Member of promotion action flag tag group. If no tag in group has explicit value, default value is Y. If any tag in group has explicit value, default is N.
<selectivePromotion>	Optional	0 - 1	String (1)	Y = Yes include selective promotes N = No, omit selective promotes NOTE: Member of promotion action flag tag group. If no tag in group has explicit value, default value is Y. If any tag in group has explicit value, default is N.
	Optional	0 - 1	String (1)	Y = site is locked N = site is not locked

...

PACKAGE PRM_HIST LIST — Reply

The XML reply to a promotion history list request includes zero to many <result> tags. For full promotion history lists (i.e., the value in <requestType> is "1"), each <result> contains a package promotion or demotion record for a particular site and level. For promotion site status lists (i.e., the value in <requestType> is "2"), each <result> contains current package promotion status for a site.

A standard <response> tag follows the last <result> tag, if any, to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher. As the last tag returned in the reply message, the <response> tag may serve as an end-of-list marker.

An example XML reply to a package promotion history list request appears below. Data structure details for the <result> tag follow in Exhibit 4-55.

Example XML — PACKAGE PRM_HIST LIST Reply

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="PRM_HIST">
        <message name="LIST">
            <result>
                <package>IMSQ000012</package>
                <applName>IMSQ</applName>
                <packageId>000012</packageId>
                <promotionSiteName>SERT8</promotionSiteName>
                <promotionLevel>10</promotionLevel>
                <promotionName>C001AUT</promotionName>
                <promoter>USER24</promoter>
                <promotionDate>20081019</promotionDate>
                <promotionTime>201225</promotionTime>
                <fullPromotion>Y</fullPromotion>
                <fullDemotion>N</fullDemotion>
                <selectivePromotion>N</selectivePromotion>
                <selectiveDemotion>N</selectiveDemotion>
                <firstPromotion>N</firstPromotion>
                <jobSubmitted>N</jobSubmitted>
                <jobCompleted>Y</jobCompleted>
                <jobFailed>N</jobFailed>
                <jobBuilt>N</jobBuilt>
                <componentCount>0000020</componentCount>
            </result>
            <result>
                <package>IMSQ000012</package>
                <applName>IMSQ</applName>
                <packageId>000012</packageId>
                <promotionSiteName>SERT8</promotionSiteName>
                <promotionLevel>10</promotionLevel>
                <promotionName>C001AUT</promotionName>
                <promoter>USER24</promoter>
                <promotionDate>20081019</promotionDate>
                <promotionTime>201633</promotionTime>
                <fullPromotion>N</fullPromotion>
                <fullDemotion>Y</fullDemotion>
                <selectivePromotion>N</selectivePromotion>
                <selectiveDemotion>N</selectiveDemotion>
                <firstPromotion>N</firstPromotion>
                <jobSubmitted>N</jobSubmitted>
                <jobCompleted>Y</jobCompleted>
                <jobFailed>N</jobFailed>
                <jobBuilt>N</jobBuilt>
                <componentCount>0000019</componentCount>
            </result>  
            .
            .
            <response>
                <statusMessage>CMN8700I - LIST service completed</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8700</statusReasonCode>
            </response>
        </message>
    </scope>
</service>

...

Exhibit 4-55. PACKAGE PRM_HIST LIST <result> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of .
<componentCount>	Optional	0 - 1	Integer (7), variable	Number of components included in promotion action.
<firstPromotion>	Optional	0 - 1	String (1)	Y = Yes, action is first promote N = No, not first promote
<fullDemotion>	Optional	0 - 1	String (1)	Y = Yes, action is full demote N = No, not full demote
<fullPromotion>	Optional	0 - 1	String (1)	Y = Yes, action is full promote N = No, not full promote
<jobBuilt>	Optional	0 - 1	String (1)	Y = Yes, promotion job built N = No, job not built
<jobCompleted>	Optional	0 - 1	String (1)	Y = Yes, promotion job completed N = No, job not completed
<jobFailed>	Optional	0 - 1	String (1)	Y = Yes, promotion job failed N = No, job did not fail
<jobSubmitted>	Optional	0 - 1	String (1)	Y = Yes, promotion job submitted N = No, job not submitted
<package>	Optional	0 - 1	String (10), variable	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of .
<promoter>	Optional	0 - 1	String (8), variable	TSO user ID of package promoter for reported promotion action.
<promotionDate>	Optional	0 - 1	Date, yyyymmdd	Date of reported promotion action.
<promotionLevel>	Optional	0 - 1	String (2), variable	Numeric promotion level for which promotion action & status are reported.
<promotionName>	Optional	0 - 1	String (8), variable	ZMF nickname of promotion level for which action & status are reported
<promotionSiteName>	Optional	0 - 1	String (8), variable	ZMF name of promotion site for which promotion action & status are reported.
<promotionSuccessDate>	Optional	0 - 1	Date, yyyymmdd	Date of successful promotion.
<promotionSuccessTime>	Optional	0 - 1	Time, hhmms	Time of successful promotion.
<promotionTime>	Optional	0 - 1	Time, hhmmss	Time of reported promotion action.
<selectiveDemotion>	Optional	0 - 1	String (1)	Y = Yes, action is selective demote N = No, not selective demote
<selectivePromotion>	Optional	0 - 1	String (1)	Y = Yes, action is selective promote N = No, not selective promote
<siteLock>	Optional	0 - 1	String (1)	Y = Site is locked. N = Site is not locked.

...

Package Promoted Component List - PACKAGE PRM_CMP LIST

List the promotion history of all components in a named package using the Serena XML component promotion history list. A promotion history list for the package as a whole requires a different Serena XML function. (See List Package Promotion History - PACKAGE PRM_HIST LIST.)

The Serena XML service/scope/message names for a component promotion history list are:

<service name="PACKAGE">
<scope name="PRM_CMP">
<message name="LIST">

These tags appear in both requests and replies.

PACKAGE PRM_CMP LIST — Request

This component promotion history function requests all component promotion history records for a specific package at a specific promotion site and level. No further filtering options exist.

The following example shows how you might code a component promotion history request in Serena XML. Data structure details follow the example in Exhibit 4-56.

Example XML — PACKAGE PRM_CMP LIST Request

<?xml version="1.0"?>  
<service name="PACKAGE">
    <scope name="PRM_CMP">
        <message name="LIST">
            <header>
                <subsys>8</subsys>
                <product>CMN</product>
            </header>
            <request>
                <package>IMSQ000012</package>
                <promotionSiteName>SERT8</promotionSiteName>
                <promotionLevel>10</promotionLevel>
                <promotionName>*</promotionName>
                <shortSelectList>Y</shortSelectList>
            </request>
        </message>
    </scope>
</service>

...

Exhibit 4-56. PACKAGE PRM_CMP LIST <request> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of <package>.
<package>	Required	1	String (10), variable	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6), fixed	ZMF package ID number. Same as last 6 bytes of .
<promotionLevel>	Required	1	Integer (2), variable	Numeric promotion level for which promotion action & status are requested.
<promotionName>	Required	1	String (8), variable	ZMF nickname of promotion level for which action & status are requested
<promotionSiteName>	Required	1	String (8), variable	ZMF name of promotion site for which promotion action & status are requested.
<shortSelectList>	Required	1	String (1)	Y = Limit the selection list for selective promotion to package components that are not currently promoted to the target level, including components that may have been re-staged, newly activated into the package, or overlaid by promotion of another package. N = Display all package components on the selective promotion selection list.

...

PACKAGE PRM_CMP LIST — Reply

The reply message for the Serena XML component promotion history list function returns zero to many <result> tags. Each <result> contains promotion action and status information for one component in the named package at the named promotion site and level. If no components have been promoted to that site and level, no <result> tags are returned.

A standard <response> tag follows the last <result> tag to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher. As the last tag returned in the reply message, the <response> tag also serves as an end-of-list marker.

An example Serena XML reply to a component promotion history list request follows. Data structure details for the <result> tag appear in Exhibit 4-57.

Example XML — Package Prm_Cmp List Reply

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="PRM_CMP">
        <message name="LIST">
            <result>
                <package>IMSQ000012</package>
                <applName>IMSQ</applName>
                <packageId>000012</packageId>
                <component>IM2Q101</component>
                <componentType>DBB</componentType>
                <stagedDate>20081019</stagedDate>
                <stagedTime>200843</stagedTime>
                <stager>USER24</stager>
                <componentStatus>0</componentStatus>
                <promotionSiteName>SERT8</promotionSiteName>
                <promotionName>C001AUT</promotionName>
                <promotionLevel>10</promotionLevel>
                <promoter>USER24</promoter>
                <promotionDate>20081212</promotionDate>
                <promotionTime>100135</promotionTime>
                <isComponentRestaged>N</isComponentRestaged>
                <cleanupComponent>N</cleanupComponent>
                <isComponentOverlayed>N</isComponentOverlayed>
                <isComponentDeleted>N</isComponentDeleted>
            </result> 
            .
            .
            .
            <response>
                <statusMessage>CMN8600I - The Promotion list is complete.</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8600</statusReasonCode>
            </response>
        </message> 
    </scope>  
</service>

...

Exhibit 4-57. PACKAGE PRM_CMP LIST <result>

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF package ID number. Same as last 6 bytes of <package>.
<cleanupComponent>	Optional	0 - 1	String (1)	Y = Yes, clean up component N = No, don’t clean up
<component>	Optional	0 - 1	String (256), variable	Name of component for which promotion action and status are reported. If component is PDS member, this is member name (max 8 bytes, no qualifiers). If component is HFS file, this is Unix-style long file name, optionally prefixed by path from installation root.
<componentStatus>	Optional	0 - 1	String (1)	Status code for listed component. Values: 0 = Active 1 = Approved 2 = Checked out 3 = Demoted 4 = Frozen 5 = Inactive 6 = Incomplete 7 = Promoted 8 = Refrozen 9 = Rejected A = Remote promoted B = Submitted C = Unfrozen
<componentType>	Optional	0 - 1	String (3), variable	Library type for listed component.
<isComponentDeleted>	Optional	0 - 1	String (1)	Y = Yes, component deleted N = No, not deleted
<isComponentOverlayed>	Optional	0 - 1	String (1)	Y = Yes, component is overlaid N = No, not overlaid
<isComponentRestaged>	Optional	0 - 1	String (1)	Y = Yes, component is restaged N = No, not restaged
<package>	Optional	0 - 1	String (10), variable	Fixed-format ZMF package name.
	Optional	0 - 1	Integer (6), fixed	ZMF application name. Same as first 4 bytes of <package>.
<promoter>	Optional	0 - 1	String (8), variable	TSO user ID of component promoter.
<promotionDate>	Optional	0 - 1	Date, yyyymmdd	Date component promoted to this site and level.
<promotionLevel>	Optional	0 - 1	Integer (2), variable	Numeric promotion level for which promotion action & status are reported.
<promotionName>	Optional	0 - 1	String (8), variable	ZMF nickname of promotion level for which action & status are reported
<promotionSiteName>	Optional	0 - 1	String (8), variable	ZMF name of promotion site for which promotion action & status are reported.
<promotionTime>	Optional	0 - 1	Time, hhmmss	Time component promoted to this site and level, 24-hour format.
<stagedDate>	Optional	0 - 1	Date, yyyymmdd	Date component staged.
<stagedTime>	Optional	0 - 1	Time, hhmmss	Time component staged, 24-hour format.
<stager>	Optional	0 - 1	String (8), variable	TSO user ID of developer who staged component.

...

List Reasons for Backout or Revert - PACKAGE REASONS LIST

The package reasons list function lists backout or revert reasons for a specific package.

The Serena XML service/scope/message tags for a package reasons list message are:

<service name="PACKAGE">
<scope name="REASONS">
<message name="LIST">

...

These tags appear in both requests and replies.

PACKAGE REASONS LIST Requests

An example of how you might code a Serena XML request to list backout or revert reasons appears below. Data structure details for the tag appear in Exhibit 4-58.

Example XML — PACKAGE REASONS LIST Request

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="REASONS">
        <message name="LIST">
            <header>
                <subsys>8</subsys>
                <product>CMN</product>
            </header> 
            <request>
                <package>ACTP000012</package>
            </request>
        </message>  
    </scope> 
</service>

...

Exhibit 4-58. PACKAGE REASONS LIST <request> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of package name. NOTE: OK to omit trailing blanks. NOTE: Not recommended as replacement for <package> tag. Use <package> instead of <applName> & <packageId>.
<fromDate>	Optional	0 - 1	Date, yyyymmdd	Start date in desired range of backout/revert dates.
<package>	Required	1	String (10), fixed	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6)	ZMF package ID number. Same as last 6 bytes of package name. NOTE: Leading zeroes required. NOTE: Not recommended. Use <package> instead of <applName> & <packageId>.
<reasonType>	Optional	0 - 1	String (1)	Reason type: B = Backout R = Revert
<siteName>	Optional	0 - 1	String (8), variable	Site name.
<toDate>	Optional	0 - 1	Date, yyyymmdd	End date in desired range of backout/revert dates.
<updater>	Optional	0 - 1	String (8)	TSO user ID of last user to back out or revert the package.

...

PACKAGE REASONS LIST — Reply

The reply message for the Serena XML package reasons list function returns zero to one <result> tags. If there are no backout or revert reasons for the requested package, no <result> tags are returned.

A standard <response> tag follows the last <result> tag to indicate the success or failure of the request. Successful requests have a return code of 00. Unsuccessful requests have a return code of 04 or higher.

An example Serena XML reply to a package reasons list request follows. Data structure details for the <result> tag appear in Exhibit 4-59.

Example XML — Package Reasons List Reply

<?xml version="1.0"?>
<service name="PACKAGE">
    <scope name="REASONS">
        <message name="LIST">
            <result>
                <package>ACTP000012</package>
                <applName>ACTP</applName>
                <packageId>000012</packageId>
                <reasonType>R</reasonType>
                <siteName>SERT8</siteName>
                <updater>USER109</updater>
                <updateDate>20120718</updateDate>
                <updateTime>073744</updateTime>
                <reasons>reverted</reasons>
                <reason01>reverted</reason01>
            </result>
            <response>
                <statusMessage>CMN8600I - LIST Reasons service completed.</statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8600</statusReasonCode>
            </response>
        </message>
    </scope> 
</service>

...

Exhibit 4-59. PACKAGE REASONS LIST <result> Data Structure

Subtag	Use	Occurs	Data Type & Length	Values & Dependencies
<applName>	Optional	0 - 1	String (4), variable	ZMF application name. Same as first 4 bytes of package name.
<package>	Optional	0 - 1	String (10), fixed	Fixed-format ZMF package name.
<packageId>	Optional	0 - 1	Integer (6)	ZMF package ID number. Same as last 6 bytes of package name.
<reason01>	Optional	0 - 1	String (72), variable	Reason line - 1.
<reason02>	Optional	0 - 1	String (72), variable	Reason line - 2.
<reason03>	Optional	0 - 1	String (72), variable	Reason line - 3.
<reason04>	Optional	0 - 1	String (72), variable	Reason line - 4.
<reason05>	Optional	0 - 1	String (72), variable	Reason line - 5.
<reason06>	Optional	0 - 1	String (72), variable	Reason line - 6.
<reason07>	Optional	0 - 1	String (72), variable	Reason line - 7.
<reason08>	Optional	0 - 1	String (72), variable	Reason line - 8.
<reason09>	Optional	0 - 1	String (72), variable	Reason line - 9.
<reasonType>	Optional	0 - 1	String (1)	Reason type: B = Backout R = Revert
<reasons>	Optional	0 - 9	String (72), variable	Reasons lines 1 - 9. NOTE: The <reasons> tag is deprecated and contains the same information as <reason01> -- <reason09>.
<siteName>	Optional	0 - 1	String (8), variable	Site name.
<updateDate>	Optional	0 - 1	Date, yyyymmdd	Date that the package was backed out or reverted.
<updateTime>	Optional	0 - 1	Time, hhmmss	Time that the package was backed out or reverted.
<updater>	Optional	0 - 1	String (8)	TSO user ID of user who backed out or reverted the package.

...