Skip to content

RLSMAREA VER_REGR LIST

The RLSMAREA VER_REGR LIST message performs a version regression check on components. If a version regression situation exists between the current release and a prior release, information for the current and prior versions is listed.

The XML service/scope/message tags and attributes for this message are:

<service name="RLSMAREA">
<scope name="VER_REGR">
<message name="LIST">

These tags appear in both requests and replies.

RLSMAREA VER_REGR LIST — Request

The following example shows how you might code a request to perform a version regression check for a single component. Data structure details for the <request> tag follow the example.

Example XML — RLSMAREA VER_REGR LIST Request

<?xml version="1.0"?>
<service name="RLSMAREA">
    <scope name="VER_REGR">
        <message name="LIST">
            <header>
                <subsys>4</subsys>
                <test> </test>
                <product>CMN</product>
            </header>
            <request>
                <package>ACTP000478</package>
                <libType>SRC</libType>
                <component>AA002 </component>
            </request>
        </message>
    </scope>
</service>

RLSMAREA VER_REGR LIST <request> Data Structure

Subtag Use Occurs Data Type & Length Values & Dependencies
<component> Required 1 String (256), variable Component name. May be masked using asterisk (*) wildcard. However, processing a single component uses a lot of resources, so it is recommended that you request only a single component or a small number of components.
<libType> Required 1 String (3), variable Library type.
<package> Required 1 String (10), variable The package from which the area component was checked in.

...

RLSMAREA VER_REGR LIST — Reply

The XML reply to a RLSMAREA VER_REGR LIST request returns zero to many <result> data elements.

If a version regression situation does not exist, an informational message is displayed in the <response> data element, but no <result> data element is returned.

If a version regression situation does exist, a <result> data element is returned for each component, listing information for the current and prior releases.

The standard <response> data element follows any <result> tags in the reply and 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. Because it is the final data element in the XML reply message, the <response> tag serves as an end-of-list marker.

The following examples show what the reply message might look like. Data structure details for the <result> tag follow the examples.

Example XML — RLSMAREA VER_REGR LIST Reply

Example of No Version Regression

The following example shows a reply where a version regression situation does not exist:

<?xml version="1.0"?>
<service name="RLSMAREA">
    <scope name="VER_REGR">
        <message name="LIST">
            <response>
                <statusMessage>CMR6504I - No information found for Prior rls regress request.</statusMessage>
                <statusReturnCode>08</statusReturnCode>
                <statusReasonCode>6504</statusReasonCode>
            </response>
        </message>
    </scope>
</service>

...

Example of a Version Regression

The following example shows a reply where a version regression situation does exist:

<?xml version="1.0"?>
<service name="RLSMAREA">
    <scope name="VER_REGR">
        <message name="LIST">
            <result>
                <package>ACTP000478</package>
                <applName>ACTP</applName>
                <packageId>000478</packageId>
                <libType>SRC</libType>
                <component>AA002</component>
                <currentRelease>SDJUL112</currentRelease>
                <currentArea>UNIT</currentArea>
                <priorRelease>SDJUL111</priorRelease>
                <priorArea>UNIT</priorArea>
                <currentUser>WSER58</currentUser>
                <priorUser>WSER58</priorUser>
                <currentChangeDate>20110812</currentChangeDate>
                <currentChangeTime>033517</currentChangeTime>
                <priorChangeDate>20110822</priorChangeDate>
                <priorChangeTime>072426</priorChangeTime>
                <currentCheckInDate>20110812</currentCheckInDate>
                <currentCheckInTime>033610</currentCheckInTime>
                <priorCheckInDate>20110822</priorCheckInDate>
                <priorCheckInTime>072540</priorCheckInTime>
                <currentVersion>01</currentVersion>
                <currentModLevel>00</currentModLevel>
                <priorVersion>01</priorVersion>
                <priorModLevel>00</priorModLevel>
                <currentHashToken>D4C03B4A0000023E</currentHashToken>
                <priorHashToken>A10E947500000290</priorHashToken>
                <currentAssocPkg>ACTP000472</currentAssocPkg>
                <priorAssocPkg>ACTP000472</priorAssocPkg>
            </result>
            <response>
                <statusMessage>CMR8700I - Prior rls regress service completed </statusMessage>
                <statusReturnCode>00</statusReturnCode>
                <statusReasonCode>8700</statusReasonCode>
            </response>
        </message>
    </scope>
</service>

...

Most of the fields returned in the above example are informational, but the following fields are important to note:

<currentHashToken>D4C03B4A0000023E</currentHashToken>

This was the hash token of the current area component at the time it was originally checked out. If nothing has changed in the meantime then this field should be the same as the next one (priorHashToken).

<priorHashToken>A10E947500000290</priorHashToken>

This is the hash token of the component which is now in the "first found" prior release. The fact that it is different means that the prior release has been changed since the current release component was checked out.

<currentAssocPkg>ACTP000472</currentAssocPkg>

This is the name of the package which supplied the prior release component at the time the current release component was checked out. Again, for there to be no prior release version regression, this must also match the next field (priorAssocPkg).

<priorAssocPkg>ACTP000472</priorAssocPkg>

This is the name of the package which supplied the prior release component as it exists now. The fact that these are the same in this case but the hash tokens are different means that the prior release version has been updated in package ACTP000472 and then checked back in.

If you are satisfied that the current area component is up to date with all recently applied changes to earlier releases, you can reset the meta data, which will resolve an ERR0417 in the ERO release area audit. For information on how to reset the meta data using the ChangeMan ZMF ISPF interface, refer to "Repair ERR0417 Prior Release Version Regression" in the ERO Getting Started Guide.

RLSMAREA VER_REGR LIST <result> Data Structure

Subtag Use Occurs Data Type & Length Values & Dependencies
<applName> Optional 0 - 1 String (4), variable Release application name.
<component> Optional 0 - 1 String (256), variable Release area component name.
<currentArea> Optiona 0 - 1 String (8), variable Current release area name.
<currentAssocPkg> Optional 0 - 1 String (10) Current associated package name.
<currentChangeDate> Optional 0 - 1 Date, yyyymmdd Current change date.
<currentChangeTime> Optional 0 - 1 Time, hhmmss Current change time.
<currentCheckinDate> Optional 0 - 1 Date, yyyymmdd Current checkin date.
<currentCheckinTime> Optional 0 - 1 Time, hhmmss Current checkin time.
<currentHashToken> Optional 0 - 1 String (16) Current hash token.
<currentModLevel> Optional 0 - 1 String (2) Current modification level.
<currentRelease> Optiona 0 - 1 String (8), variable Current release name.
<currentUser> Optiona 0 - 1 String (8), variable Current user ID.
<currentVersion> Optiona 0 - 1 String (2) Current version.
<libType> Optiona 0 - 1 String (3) Library type.
<package> Optional 0 - 1 String (10) The package from which the area component was checked in.
<packageId> Optional 0 - 1 Integer (6) Package number.
<priorArea> Optional 0 - 1 String (8), variable Prior release area name.
<priorAssocPkg> Optional 0 - 1 String (10) Prior associated package name.
<priorChangeDate> Optional 0 - 1 Date, yyyymmdd Prior change date.
<priorChangeTime> Optional 0 - 1 Time, hhmmss Prior change time.
<priorCheckinDate> Optional 0 - 1 Date, yyyymmdd Prior checkin date.
<priorCheckinTime> Optional 0 - 1 Time, hhmmss Prior checkin time.
<priorHashToken> Optional 0 - 1 String (16) Prior hash token.
<priorModLevel> Optional 0 - 1 String (2) Prior modification level.
<priorRelease> Optional 0 - 1 String (8), variable Prior release name.
<priorUser> Optional 0 - 1 String (8), variable Prior user ID.
<priorVersion> Optional 0 - 1 String (2) Prior version.

...