Skip to content

Installing a Promotion

Once any compile, approval and MDRapid steps are complete, the installation process checks the Promotion Level parameters and if the Auto-Install flag is set to 'N', the RFP status is set to '03' - Waiting to Install. An authorized user must then select the promotion for installation before the objects are actually installed into an application. To do this, toggle to the Install list using F9 in the RFP Manager.

The list of all RFPs in status CP or 03 is displayed.

Enter a '1' for a RFP number with status 03 to install it. A confirmation screen will be displayed for the submission of the installation of the promotion. If the RFP installation job is not placed in the Job Queue, then the status is changed to IP for Installation Pending and will wait until the RFP Installer API (MDINSRFP) submits the RFP.

The user must have authority to MDSEC code 44 for the application if the RFP was approved by someone else.

The user must have authority to MDSEC code 53 for the application if the RFP was approved by that same user.

Enter a '7' to remove the temporary promotion library and to reset the RFP back to status '01'.

The Installation Steps

  • Pre-Steps:
  • Process Pre-Installation commands for *RFP attributes
  • Process Pre-Installation commands and scripts for this RFP
  • Process Pre-Installation commands and scripts for objects and object attributes
  • Lock all target files to be replaced with new versions of those files
  • If MDRapid is running, finish any outstanding journal syncing and then end MDRapid processing
  • Object Steps processed in full for each object before continuing to next object:
  • Move current version of source and object to a backup library/folder
  • Move new version of source and object to target locations
  • Set object authorities for each target library, if replicated to multiple libraries and MDRapid not used to prepare the object.
  • Stamp object with MDCMS metadata information, if the object was re-compiled during the install phase.
  • Post-Steps
  • All prior members for modified physical files are copied to the new file using Data Transformation, if enabled. If disabled, CPYF with option *map/*drop will be used unless an overriding data copy command is specified.
    If MDRapid was used for a file, then this step already occurred prior to installation, so only a simple move is required.
  • All constraints, journals and system (non-SQL) triggers are reapplied (if the file flags indicate to do so). If a logical file is being replaced, all prior members of the file are created for the new file (if the file flag indicates to do so).
    If MDRapid was used for a file, then the constraints will have already been applied prior to installation.
  • Unlock all files
  • Process Post-Installation commands and scripts for objects and object attributes
  • Process Post-Installation commands and scripts for this RFP
  • Process Post-Installation commands for *RFP attributes
  • Set status of RFP and objects to IC=Installation Complete, indicating the application can be used again.

If an exception occurs during the Installation Steps, any completed portion of the installation is automatically rolled back and the RFP will return to status 03=Ready for Installation, unless the exception is for a command or replication location that has the Ignore Errors flag set to Y. In the case of ignoring a specific error, the warning will be logged and the RFP warning exit point will be triggered at the conclusion of the RFP process.

The Archiving/Cleanup Steps

  • Update MDXREF information for the installed source and objects
  • If the Application Level is tied to X-Analysis libraries in MDXREF, the deployed objects will be passed to the MDXANI service for the asynchronous update of object information in X-Analysis for those libraries.
  • Process Installation Archive/Cleanup commands for this RFP
  • Process Installation Archive/Cleanup commands for *RFP attributes
  • All replaced source is archived. Replaced objects will be zip compressed and archived to the MDCMS IFS path, if they are not compiled from source.
    During the archiving process for each object, any Installation Archive/Cleanup command for the specific object or for the MDCMS attribute used by the object will be invoked to be able to perform additional processing on the archived source and objects.
  • If the installation occurred at a checkout level and the RFP is defined to remove the source or objects from the developer's library and/or from an import library, the removal is performed at this time.
  • Delta Source and Objects are removed from other levels based on the templates assigned to the object attributes in this RFP. They are left in place if the version in the delta level is different than the version in the target level, unless the delta level is also flagged as an emergency level.
  • Installation History records are created for each object.
  • The finished Request detail records are removed.
  • If any of the object requests require Code Review, they will be added to the pending batch for each impacted Code Review Template. If the number of pending items meets the criteria to run the review, the batch will be executed.
  • The temporary libraries and spool files are deleted unless the parameters specify to keep them.

The Next Level Preparation Steps

  • If a Distribution Level is defined for the RFP's promotion level, the RFP is placed in the send list. If Auto-Send is set to Y for this Level, the RFP will immediately be sent to all Target Levels where the Default flag is set to Y.
    If other RFPs containing one or more of the same objects are open in the send list, and this RFP was flagged to auto-merge, then the other RFPs will be merged into this new RFP.
  • New Request records are created for the next level on the same system, if direct migration is defined and the object attribute exists further up the chain.
  • A new RFP number is generated and automatically assigned to the new Request records.
  • If an object is already requested for the next level, and auto-merge was set to No during the RFP submission, a Request record will not be created and a warning condition will be generated. If auto-merge was set to Yes, the other RFPs will be merged into this new RFP and a warning isn't flagged.
  • If Auto-Submit is set to Y for the next level, and no errors exist at the next level, and Workflow acceptance of this RFP is not required, the new RFP is submitted to batch.