|
From Build Date |
Description
|
|---|---|
| February 15, 2021 | Execute Jenkins Pipeline jobs during the RFP batch process to build, test, deploy, perform workflow acceptance or rollback artifacts on target systems. The *PIPE attribute type has been added to MDCMS and for such attributes, any number of Jenkins Pipeline jobs can be invoked during the appropriate RFP phase, with the ability to pass any number of MDCMS or customer parameters and to cache parameter values between jobs for a very flexible and powerful DevOps master process from within MDCMS.
All console logs generated by Jenkins can be automatically injected into the RFP Deployment log for a single point of auditing and troubleshooting across platforms. |
| A new parameter is available per Application and partition to allow the RFP compile phase to resume where it left off if an error occurs. When activated, when the compile/validation for an object occurs, and the object isn’t the first one in the list, the RFP will go into new status SE=Submission Error. The developer can then make corrections to that source or object and any subsequent entries and then resubmit the RFP. The RFP will then continue at that request. If changes need to occur to an already processed object request, the RFP can be reset back to status 01 to free those requests for editing.
This can be a significant time saver for large RFPs. |
|
| A new parameter is available per Application and partition named Auto-Merge RFP in Send List.
O=Optional – the developer can decide if a merge in the Send List should automatically happen or not when one or more of the same objects are on the RFP to submit. Y=Yes – any open RFPs in the Send List with matching objects will automatically merge in the Send List into the RFP to be installed. N = No – no automatic merging in the Send List will occur. The installed RFP will contain only its own objects in the Send List and any common objects will still be in the separate RFPs. This parameter replaces the prior command MDLCKAMGS to set the behavior. |
|
Conflict-Management of Received Objects has now been significantly enhanced for better visibility and more intuitive control when a received RFP contains objects already locked for the target level using the following decision process:
|
|
| Rename option added for level numbers to be able to rename a level to a new number and MDCMS will then automatically rename all active occurrences in all tables to the new number. | |
| Required Workflow Acceptance Group Types can now be defined for specific attributes. This means that if objects of a specific attribute are installed into a level, MDCMS can require acceptance by the assigned group of the group type before that RFP can continue to the next step in the migration path. | |
| For each User Group type, a user group can be set as the default group for the group type to reduce setup when new projects are created. | |
| The MDCMS version, build date and install date of remote locations can be viewed for each location in the OS/400 Location settings if a DDM connection exists for the location. It tries to auto-refresh at install time and can be manually refreshed by pressing the F10=Test Connection key. | |
| When replacing wildcards with runtime strings for command execution, MDCMS now applies the same naming rules that QCMDEXC applies and if there are exceptions, MDCMS will automatically wrap the string in quotes, when not already present and any embedded quotes in the string will be escaped.
If more than just the wildcard is in a set of parenthesis, then quotes won’t automatically be added to allow for qualified names, etc. In this case, the administrator would still need to define the quotes on the command definition around the combination of values, when necessary. |
|
| New Pre-Submit validation error if a recompile request exists for an object without source, such as an ILE program or service program, and the object doesn’t exist in the search locations. | |
| Check Conflict Resolution requirements for automated object requests or when receiving object requests from another level | |
New History tables to capture configuration updates for:
|
|
| Assign an Object Authority template to *SQLTRG attributes and apply Object Authority template to *SQLTRG CLE programs that are generated when the SQL trigger is created | |
| Improvements to the handling of SQL variables and User Defined Types to avoid/delay dropping them when dependencies exist over them. | |
| During the RFP compile phase, if a program is to be compiled from a modified source member, the source will temporarily get copied into the target source file so that a debug view of *SOURCE will function. | |
| If pulling source or objects from a Git or Subversion repository, the repository type, server ID (defined in MDOpen) and revision code/number can be stored with the object request. If the requests were created automatically using Continuous Integration, the information will automatically be there. For manual object request creation, this can be added to the object request detail in MDOpen.
This information can then be used on commands or pipeline parameters with the following new wildcards:
|
|
| For *DATA and *DTAGRP attributes, a Allow *NONE parameter has been added. When set to false, then the developer can’t specify *NONE for the library where the data can be migrated from. Instead, the default developer object library will be suggested. | |
| March 19, 2021 | Ability to automatically omit the send of specific objects to specific target locations with the usage of value *NONE for the Override Library in the Distribution Override settings for target levels. |
