MDCMS Enhancements
Smart Sorting for SQL Entities in RFP
When an SQL entity, such as a view or function, is checked out, MDCMS recursively checks the dependencies in both directions for that entity and automatically sorts it in the RFP so that items that it depends on are compiled first and items that depend on it are compiled after. For a new SQL entity, or for exceptions due to source changes, the developer can continue to override the sort sequence for any given item in the RFP. After upgrading, the cross references would need to be refreshed to bring in the new SQL dependencies.
Object Stamping
The administrator can define, by application, which IBMi object fields, if any, should contain MDCMS information for auditing/reporting purposes.
Then, when MDCMS installs an object, some or all of the following information can variably be stored in the service attributes of the object:
- MDCMS Attribute
- Installed RFP
- Original RFP
- Prior RFP
- Application and Level
- Project, Task and Subtask
Timesheet Entry
Hours can now be entered per day and user for Projects, Tasks and Subtasks and the overview can be seen/summarized with various filters. Customizable reports can be defined for automated generation and export.
Temporary Source for Compiles
*TEMP can now be used as the target source library/folder for an application level. When MDCMS is finished with the installation into the level, the source isn’t retained externally on the system. However, to allow for rollbacks or promotions to higher levels or other systems, the source is compressed and retained internally within MDCMS.
2 common reasons for doing this:
- to be able to compile on production systems to avoid level check issues and handle SQL components, but still conform to audit requirements not allowing observable source in production.
- source is managed entirely in an external source versioning tool such as Git or SVN and is intended to be used on the IBMi only to compile the object before being discarded.
Send Source for Recompiles
If the target system doesn’t contain persistent or complete source, the rules for a distribution level can be set to send the source to the target system when the local system performed a recompile. This coincides with the *TEMP usage in section 1.2. Perhaps the local system is the development partition where the source is retained, but the target system is the production partition.
Define Description to apply to Object during Deployment
Any description applied to the object during compile is kept by default. If blank, MDCMS will now automatically apply the description from the object it replaces. This value can be overridden with a different value by editing the Object Request prior to submitting the RFP. This is especially helpful for new objects created from IFS source, but can be used for any system object.
Define Default Member Source Type per MDCMS Attribute
Each MDCMS attribute that has a target source file defined for it can now have a default source type. This value is applied by default when a new member is generated or if MDCMS converts source from Git, SVN or other locations into a member.
Separate Archive Generation count for *DATA and *DTAGRP Attributes
Since the size of data migrations may be very large, the number of archive generations to keep for *DATA and *DTAGRP attributes can be defined per attribute. Any value between 0 and 99 is allowed.
Pre-Submit Validation Exit Point
Command Type V has been added as a new exit point that can be added at the RFP level. The defined command runs interactively when a user selects to submit an RFP. The custom program can perform its own validation routines and then indicate to MDCMS if the RFP can be submitted, or why it can’t. The exit point program can also provide warnings but allow the RFP to continue.
Project Types
Projects can now be categorized by type. Additionally, project types provide the following rules for the projects that are assigned to them:
- whether or not Tasks are permitted for the Project
- whether or not Object Requests are required to be assigned to Tasks instead of directly to the Project
- whether or not Object Requests are limited to Assigned Users
Project Costs
The cost per hour can now be defined and then multiplied against hours entered at the subtask, task or project level and summarized for reports. The cost to be used for any situation can be customized and prioritized based on any or all of the following criteria: Project Type, Task Type, Project Phase, or User.
Command Wildcards for all Project and Task Fields
The command wildcards have been expanded to include any Project fields that weren’t previously included as well as all Task Fields.
Command Wildcards for Custom Fields
A 6-character Wildcard ID can be defined for any custom field. The wildcard ID is then replaced by the value of the custom field at runtime. In the case of MDMAILF email bodies for custom DDL fields, the selected element code and description are included in the email body.
Specify a Different User for Command Execution
Parameter “Run as User Profile” has been added to command definitions. This allows a different user’s credentials to be used during the execution of a command instead of the user assigned to the job description for the Level.
Logging for Object Authority during Installation
The RFP Log has been expanded to track the application of object authorities during the installation process and to trigger a warning condition if authority couldn’t be applied.
MDFTP and MDMAIL Logging moved to Rolling IFS files
Until now, logging of the java services MDFTP and MDMAIL was outputted to a spooled file for the batch job. This made it complicated to find and clean up the logs and system buffering meant that the most recent transactions couldn’t be seen until the job ended. Now, logging goes directly to IFS files, which can be viewed directly from the Services screen, can be set to automatically purge after n days, and the most recent log entries can be seen immediately even while the job is running.
Optionally Set Default Flags for New RFP
The default Delete parameter values for an RFP can now be set using F8 from the RFP detail screen. Any new RFP will use those values rather than the last used values, so that the user can override the values for an RFP without worrying about future RFPs.
View Authorized Users from RFP Manager
When in Submit, Approve or Install mode in the RFP Manager, option U can be used to see the list of users that are authorized to generally perform the action for the given Application and Level.
Install Date Range Filter in RFP History
The list of RFPs in the RFP History can be filtered to those with a given minimum and/or maximum install date.
Improved Target Attribute Management
The Target Attributes for Distribution Levels can now be managed across many levels at once, filtered by several additional fields, and the option for a specific type of object can be applied across all like attributes for the filtered rows.
Use MDFTP to Distribute Settings and RFPs via FTPS or SFTP
Transfer method MDF added for sending settings and RFPs to SSL FTP or SSH FTP servers on target IBMi partitions.
Distribution Object Override
If certain objects or IFS files, such as configuration files, differ based on the target system, the object that is sent to target system can be configured to be overridden to a different library.
For example, if config.xml is different for each target system, you can use option O=Object Override from Distribution Levels to specify which folder to send from for each system when the file in the default folder for the attribute wouldn’t be correct.
Filter Target Locations for RFP Send by any active Status
In the RFP Send screen, the targets can be filtered by special status value *ACT for any active send, which is any location where the installation hasn’t occurred yet and the location isn’t ignored.
MDUPDSTS Command to automatically update Project/Task Status for RFP
MDUPDSTS is intended to be used as an exit point command for an RFP to update the status for the projects, tasks and/or subtasks attached to the RFP. The status update can be conditional based on what the current status is or isn’t.
MDUPDCFLD Command to update Project/Task Custom Fields
MDUPDCFLD is a command that can be used to update the values of custom fields for Projects, Tasks or Subtasks from an automated process.
MDCLEAN Command/Service to Cleanup Temp Libraries/Objects
Until now, the cleanup of no unneeded temporary RFP libraries and data objects occurred once per day during the first RFP of the day. If RFPs aren’t submitted very often, or if the first RFP of the day shouldn’t be slowed down by this cleanup process, then the command can be scheduled to run whenever desired.
Automatically Refresh X-Analysis Information when RFP is Installed
If instances of the X-Analysis tool from Fresche Legacy are used, they can be linked to MDCMS and updated automatically for objects installed on an RFP.
Project/Task Status Boundaries for RFP Events
An RFP (installation package) event can be blocked for a given level if Projects, Tasks or Subtasks impacted by that RFP Limit are not within the allowed status range.
For example: don’t allow the send of an RFP to production until the status for the impacted tasks is at least Testing Complete.
The Boundary settings can be managed in MDCMS, MDOpen or MDWorkflow.
Events that can be controlled by Status Boundaries:
Submit RFP
Approve RFP
Install RFP
Send RFP
Project/Task Status Transition Limits
Limit the list of status codes that a Project, Task or Subtask can currently have when trying to transition to a new status code.
For example: don’t allow a task to transition to status Testing Complete unless current status is Ready to Test or Testing in Progress.
Transition settings can be managed in MDCMS, MDOpen or MDWorkflow.
Block Project/Task Status Transition if Required Field values are Missing
If a custom field is marked as required for the current status of a Project, Task or Subtask, and a value hasn’t been entered for that field, then MDCMS will block transitioning forward to a new, higher status. Returning to a lower status is allowed.
Required custom fields are marked in a red font in MDOpen and MDWorkflow.
This replaces the requirement to immediately enter values for all required fields when a value in MDOpen or MDWorkflow should be saved, allowing the values to be entered over time during the same workflow step.
JIRA Interface
The interface between MDCMS and JIRA is now complete and has the following capabilities:
- Simple-to-use authorization Workflow for connecting MDCMS to JIRA on a server or in the cloud
- Select applicable JIRA Project Categories and map to MDCMS Project Types
- Select applicable JIRA Issue Types and map to Task Types
- Select applicable JIRA Issue Status Codes and map to Task Status Codes
- Specify which JIRA Issue Status Codes trigger the creation of a task in MDCMS and which are for update only, allowing ability to wait for a task to be created in MDCMS until it’s ready for development.
- Map JIRA Users to MDSEC users
- Manually import/refresh all applicable projects, tasks and subtasks from JIRA
- Automatically check for new/changed issues every n seconds with highly optimized MDJIRA background service for minimal bandwidth and performance impacts.
- Select and map MDCMS status codes that trigger an automatic status transition in JIRA
- Block updates to specific status codes for JIRA Projects within MDCMS that require the updates to occur within JIRA
- MDJIRACMT API to easily post a comment in JIRA for an issue from an RFP exit point or from your internal business processes.
- Direct URL navigation from MDOpen or MDWorkflow Project/Task/Subtask to JIRA Project or Issue with a single left-click on the URL icon.
Quickly Change Project/Task Status directly from List Views
Option 8=Chg Status added to the Project, Task and Subtask listings. When entered, a dialog shows the list of any status codes that are currently possible to transition to for a much quicker manual update. This replaces the options Cancel, Close and Reopen.
Specify Different User as Project/Task Requester
When adding or copying a Project, Task or Subtask, the Requester field is now editable in case the requester is different than the user signed on.
Automatic Purging of User Generated Reports
Reports that are generated by users remain in the F11 screen until either option 4 is used to individually delete a report, or, now, when MDCMS automatically purges the information once the report reaches a certain age.
SQL Procedure Management for Modified Programs
If a program is modified, MDCMS checks if any SQL procedures invoke the program and takes care that the procedures remain intact after the new version of the program is installed.