Data Transformation

When the existing data in a file is to be mapped to a new version of the file during the installation of an RFP, Data Transformation is now used by default to perform the mapping.
Data Transformation performs a dynamic SQL insert to populate the new version, which is as fast as CPYF for DDS files and faster than CPYF for SQL tables.
The results for each column, by default, are the contents of the same column name in the prior version, if the prior column type can be cast to the new column type. For new or invalid columns, MDCMS automatically fills with blank, 0 or null, depending on column properties.
In MDCMS, option F=File Data Transformation can be used to view/customize the results for the columns when the transformation occurs. This provides a very easy-to-use and powerful way to populate new columns or modify existing columns using any valid SQL syntax, including functions.
This option is also available from the send screen from within the object detail and from object history from within the object detail. This option is also available in MDOpen.
The Data Transformation results are validated during the RFP compile phase to avoid any bad surprises during the installation phase.
Data Transformation can be disabled for a specific file if a Data command should be used instead.

Source Comment Templates

MDCMS can now automatically insert highly customizable comments into source code when the source is deployed to an initial level for an application. The content format of the comments is defined within Source Comment Templates and a template can then be assigned to one or more attributes, typically based on the language of the attribute. All wildcards are available within the comment definition to be replaced with the object, RFP or Project values during deployment.

Separate Flags on RFP for Deleting Imported Source/Objects

Until 8.1, if an RFP was flagged to delete source/objects from the developer library upon completion, those items would be deleted whether they were checked out or imported. Now, imported source/objects can be separately decided if they should be deleted or not, since items in import libraries/folders often need to be retained.

Project/Task Status Triggers

Status Triggers can be defined to automatically trigger an RFP action for any RFP in the necessary state that contains a Project, Task or Subtask that just got transitioned to a specific status.
The trigger can additionally be limited to transitions from certain prior status codes.
The available actions:

• Submit RFP (with optional merge of all RFPs for the Project, Task or Subtask)
• Approve RFP
• Install RFP
• Send RFP (with optional merge of all RFPs for the Project, Task or Subtask)

MDSEC Authority to Merge Requests for Different User, Project or Task

In order to reduce project conflicts, MDSEC codes have been added to control if a user is allowed to add or merge a request into an RFP that is already for a different user, Project or Task within a Project. If unauthorized for the target Application Level, they won’t be able to assign the request to the RFP or merge requests into the RFP.
55 – Merge Other Users into RFP
56 – Merge Other Projects into RFP
57 – Merge Other Project Tasks into RFP

Choice to Automatically Merge RFPs at Next Level or in Send List

During the pre-submit validation for an RFP, when a user is warned that an Object is already requested for the next level or requested to be sent from the target level, MDCMS now requires the user to decide if MDCMS should automatically merge the impacted RFP(s) with the newest RFP. This provides 4 big advantages:

1. The user is certain to notice the warning
2. When automatically merging, you have certainty that all impacted objects are included in the same RFP for the next step.
3. If using MDWorkflow Acceptance, only the newest RFP will have to be accepted for a release when auto-merge is used.
4. If the user isn’t authorized to merge, due to impacts to other users, projects or tasks, then they won’t be able to continue with the submission of the RFP

Status Transitions by Project Type

The transition workflow of Project Status codes is now separately definable per Project Type, allowing for various workflows based on the type of Project.

Status Transitions by Task Type

The transition workflow of Task/Subtask Status codes is now separately definable per Task Type, allowing for various workflows based on the type of Task.

MDSNDRFP – Command API for sending RFPs

The send of RFPs can now be integrated into internal processes with the MDSNDRFP command. This command allows for the selection of RFPs to send based on:

• Application
• Range of Levels
• Range of RFP numbers
• Location ID
• Location Group
• Range of Target Levels
• Project/Task/Subtask

Additionally, the RFPs to send can be auto-merged into a single RFP before the send occurs and parameters are provided for scheduling the installation of the RFP on the target systems.

New Parameters in MDDELRFP

Additional parameters have been added to the MDDELRFP (Delete RFPs) command:

• From Level
• To Level
• From RFP
• To RFP
• Project
• Task
• Subtask
• Environment
• Exception Message

Also, the RFP type has been expanded to allow filtering by the original RFP number and the MD libraries no longer need to be in the library list prior to invoking the command.

New Parameters in MDSBMRFP

Additional parameters have been added to the MDSBMRFP (Submit RFPs) command:

• Environment
• Exception Message

Also, the MD libraries no longer need to be in the library list prior to invoking the command.

New Parameters in MDINSRFP

Additional parameters have been added to the MDINSRFP (Install RFPs) command:

• Environment
• Exception Message

Also, the MD libraries no longer need to be in the library list prior to invoking the command.

New Parameters in MDRBRFP

Additional parameters have been added to the MDRBRFP (Rollback RFPs) command:

• Environment
• Exception Message

Also, the MD libraries no longer need to be in the library list prior to invoking the command.

Send Status for RFP from RFP History

A Send Status code is now stored directly on the Installed RFP to be able to view and filter RFPs in RFP History by the Send Status. The codes are:
O – Open
P – Partial
C – Closed
Filtering can be done by those values, plus special values:
N – Not Applicable (no distribution levels defined or RFP defined to not exist in send list)
U – Not Closed (open or partial)

Status Boundary Checking prior to RFP Submission

If a Status Boundary is defined for submitting an RFP to the target Level, MDCMS will check this as part of the pre-validation and display a screen showing each impacted Project, Task or Subtask that is currently outside the boundary. If authorized, the Status can be changed directly from the validation screen.

Automatically Submit RFP when Prior Level RFP Closed in Send List

A new option, S, has been added to the Auto Submit flag for a Promotion Level.
When set to S, MDCMS will automatically submit the RFP for deployment into the next level, once the prior level’s RFP has been closed in the Send List.
A good example of why this can be useful:
The dev partition has a copy of the production environment. This copy shouldn’t be updated until all target production environments have finished being deployed to. If the Send RFP is set to close once all targets have been either ignored or installed, then the dev copy won’t be deployed to prematurely.
If the prior level’s RFP is closed without having been sent anywhere, the auto-submit will not occur.
If multiple RFPs were merged together in the prior level’s send list, MDCMS will auto-submit the next-level RFP for each of them.

XLSX Format for MD Reports

Reports generated by the MD products can now be exported XLSX format. The XLSX format allows for over a million rows in the report and the size per row is smaller than the legacy XLS format.

RFP Description in Installation History Report

The MDCMS Installation Report configurator now contains the column RFP Description.

New Wildcard variables

Command/Comment/Mail Wildcards have been added for:

• Request Date/Time
• Submit Date/Time
• Approve Date/Time
• Install Date/Time
• Project Due Date/Time
• Task Due Date/Time
• The final target object library/folder for a level. This wildcard (OBLLIB) is always the target library, whereas the standard OBJLIB wildcard is the developer or temp install library during compile time. OBLLIB is useful, for example, when the final target library needs to be pointed at for referencing during the compile, such as for pointing to the SQLPKG object for the compile of an SQL program.

F15=Print for List of Object Requests Generates Standard MD Report

1. The spooled output when printing the list of active Object Requests in the Object Manager has been replaced by the standardized MD Output report format, which additionally allows export to XLSX or a Database. Additional columns were added to the report as well.
2. The spooled output when printing the list of active Object Requests for a Project, Task or Subtask has been replaced by the standardized MD Output report format, which additionally allows export to XLSX or a Database. Additional columns were added to the report as well.
3. The spooled output when printing the list of installed Objects in Object History has been replaced by the standardized MD Output report format, which additionally allows export to XLSX or a Database. Additional columns were added to the report as well.
4. The ability to generate a standardized report has been added to the Objects for a Send RFP screen.
5. The ability to generate a standardized report has been added to the Objects for a Send RFP screen.
6. The ability to generate a standardized report has been added to the Send History Object Listing.

Override Automatic Submit for an RFP

The Assign new RFP to Next Level Requests flag can now be set to M=Manual Submit Only. When M, the RFP will not be auto-submitted for the next level when the installation is complete in this level, but the RFP will still be prepared so that it can be submitted manually.

Override Automatic Send for an RFP

The Place RFP in Send Promotion List flag can now be set to M=Manual Send Only. When M, the RFP will not be auto-sent to other locations when the installation is complete, but the RFP will still be prepared so that it can be sent manually.

Set RFP flags from MDADDREQ API

If the MDADDREQ command is used to add object requests to MDCMS, and this command also creates a new RFP, new parameters are available to set the create, assign and send flags for that new RFP.

Allow a Different Description for a Specific Distribution Level

If sending to multiple target levels for a single Location, it can be helpful to have a different description for each target level. Now, the location description can be overridden for each target level.

Object Request Deletion Log

When a user deletes an Object Request, it is now logged to table MDCMS/MDDDLOG for auditing purposes. The age of the log entries before they are purged can be set in the Logging screen.

Automatic Import and Mapping of JIRA Users

If using the JIRA interface, the list of active users in JIRA can be imported and mapped to users defined in MDSEC.
If the name or email address of the user matches, the mapping is automatic.
If an email address isn’t defined for the MDSEC user, it will be automatically imported from JIRA.
The manual insert of the JIRA user name has been removed from MDSEC.

Option to Prioritize JIRA URL over MDWorkflow URL

If the JIRA interface and the MDWorkflow Web App are use, the URL flag in the mail settings can be set to use the JIRA URL for projects and tasks that are managed in JIRA, but use the MDWorkflow URL for other projects and tasks.

MDRCVIFS and MDRCVSNA Jobs Renamed

2 Jobs have been renamed for better recognition when running multiple instances of MDCMS.
MDRCVIFS renamed to MDRIFS(instance)
MDRCVSNA renamed to MDRSNA(instance)
The service and command names remain the same.
Command MDENDRIFS has been added to end MDRCVIFS.
Command MDENDRSNA has been added to end MDRCVSNA.

MDCMS Patch Logging and Rollback

When MDUPDATE is used to apply a patch to the MDCMS product, the action and the list of impacted objects are logged. The log can be viewed by pressing F8 from the system settings. If an issue arises after applying a patch, it can be rolled back from the log screen.

Attempt Creation of all Objects in Object Manager with F22

F22 can now be used in the Object Manager to try to create all filtered, eligible objects into the developer library in the order listed. Upon completion, the statistics are shown for number of successful attempts and number of failed attempts.

*SQLSCR – SQL Script Object Type

The *SQLSCR MDCMS type for SQL Scripts has been added, which allows for specifying the target database libraries for the scripts to run against. Also, the script syntax is validated during the compile phase of an RFP to help avoid problems during the deployment phase.

*SQLVAR – SQL Variable Object Type

The *SQLVAR MDCMS type for SQL Variables has been added, which allows for the management and deployment of SQL variables as easily as any other type of object. MDCMS also manages the authority, stamping and cross-referencing of the auto-generated service program for the variable.