|
From Build Date |
Description
|
|---|---|
| April 16, 2019 | The 2-level logging functionality for the installation of RFPs is now also enabled for the send of an RFP. The log includes any pre-send and post-send exit points and a description of exactly which source and objects are sent from which libraries for each target level.
Each high-level step can be expanded to view the job log entries for that step and all or part of the log can be exported to various file formats and emailed to recipients. |
| Similar to MDPUSH, there are new service jobs called MDSEND that allow for concurrent sending of an RFP to up to 9 different queues in parallel to greatly speed up the send process.
The build of a save file for an RFP to be sent continues to occur within a specific job for that RFP. Once built, the RFP is passed off to a MDSEND queue between 1 and 9 based on the number assigned to the remote location. The RFP job can then continue immediately with the build for the next location while the MDSEND job processes the transfer. |
|
| MDCMS now provides an ever-growing suite of REST APIs to allow connectivity to MDCMS using the REST standard. The APIs run on a native apache http server instance which can be defined very easily from the MDCMS Setup Menu.
The APIs include:
|
|
| Custom Wildcards per Level which can be defined for use in commands, IFS/Remote scripts and SQL scripts. The wildcard values can differ for each application level. This is in addition to the custom wildcards that can be defined per Project, Task or Subtask. |
|
| An optional description field is now available for attributes to allow for easier identification of the usage of an attribute. | |
Attributes of type *SQLALS can now be defined to manage the deployment of SQL aliases or DDM files. 2 additional fields are available in the attribute for this type, which can vary per level:
|
|
| Attributes of type *SQLUDT can now be defined to manage the deployment of SQL User Defined Types | |
| The Based-On flag on a level to enable conflict resolution has been extended to specify if for all objects in the level or only the existing objects.
Until now, if a level is based on another level, then every object checked out in the based-on level prompts for resolution of objects in the dependent level. Now, if the Existing Only flag on the level is set to Y, then only objects that already exist in the dependent level will be prompted for resolution, when a request is made in the based-on level. This is useful when new or custom versions of an application are deltas of the based-on version. |
|
| If a program or service program is requested on an RFP for modify or recompile, and that program is externally called by an SQL Function or Procedure that isn’t on the RFP, then MDCMS will warn the user at RFP submit time. The user can then request to recompile the routine from the warning screen. When routines aren’t included, there is a risk that the routine will be automatically dropped by the system when the new version of the program is deployed. | |
| Prior to the submission of an RFP, MDCMS now checks if each source member that is to be promoted from a developer’s library is currently locked. This is typically the case when the developer still has it open in a green-screen or LPEX editor.
This gives the developer the chance to cleanly close each impacted member before continuing. |
|
| When the warning screen appears for merging objects with existing RFPs for the next level or in the send list, option O=Original Description can be selected. This will perform an auto-merge after installation into the new RFP, but retain the description from the original RFP. | |
| Any attribute that deploys source to the IFS can now have an IFS Object Authority Template assigned to it, so that the Object and Data authority on the IFS file is set appropriately. | |
| A new command type of Z can be defined for an attribute and will be invoked whenever an object request of that attribute/level is deleted prior to installation. | |
| Until now, the rename function could be used if the source name or object name was incorrect for the request of a New Object.
Now, this function can also be used for the request of Modify, Recompile, Update and Delete requests too, as long as they are for a level allowing checkout. The function can also optionally rename the source member, source IFS file and object in the developer library. The rename only affects the request record and components in the developer’s library, but doesn’t affect the target environments. |
|
| The compile sequence for *MSGF and *MSGD object requests has be set lower so that they are deployed prior to a possible compilation of display files to pick up message dependencies. | |
| In order to allow for a larger number of tasks for a project, or number of subtasks for a task, particularly when mapped for other systems such as Jira, they can now be up to 7 digits in length. | |
| There is now a 240-character summary field for each task or subtask to allow for a brief description of the task. This is in addition to the extended description for a task/subtask. During the migration from an older version of MDCMS, the Summary field will be populated with the first 240 characters from the description. If the description wasn’t longer than 240 characters, then it is removed as the extended description is no longer mandatory. | |
| The reference IDs in Tasks to external products, such as JIRA and ServiceNow, are now stored in a separate table, freeing up the internal reference code for other uses. During the migration from an older version of MDCMS, the internal code value will be move to the reference table for JIRA tasks and subtasks. | |
| The label for the internal reference code on tasks and subtasks can now be set in the System Settings. This label is then used in all clients, including MDOpen and MDWorkflow. | |
| The task types that are allowed to be used in a Project can now be defined by mapping them to the Project Type. This allows for tighter controls of the workflow and origin of tasks for a given project. | |
| A project type can now be set as the default. Then, when the user requests to create a new project, the default type will be auto-filled into the project type field. This can then be overwritten when necessary. | |
| For each project type, one of the allowed task types can be set as the default task type. Then, when the user requests to create a new task or subtask for a project of the given project type, the default type will be auto-filled into the task type field. This can then be overwritten when necessary. | |
| The MDUPDATT command has been added to MDCMS to provide the ability to systematically add, replace or delete an attachment for an existing Project, Task or Subtask. | |
New flags have been added to each Task Type to control where it can be created and export to:
|
|
| Large text fields in most of the MDCMS/MDXREF tables that typically contain a lot of records have been converted to variable length fields to greatly reduce the amount of disk space that the MDCMS product requires. During the migration from an older version of MDCMS, the conversion will cause the upgrade to run a few minutes longer than usual. | |
| The /MDCMS/REPORT folder has been added to the Logging list in the Setup Menu to provide for cleanup of IFS files that are generated into that folder.
By default, files older than 60 days will be deleted. As with all other entries in the log list, the minimum age can be adjusted or purging turned off. If certain files are critical to be kept, they should be copied to another folder. |
|
| New fixed wildcards have been added:
##OBJATR## – Object Attribute |
|
Jira Interface Enhancements:
|
|
| May 14, 2019 | New flag on distribution levels to ignore the distribution to a target level when the RFP originated in a different branch than the migration branch that the level to send from is located in. This provides a way to avoid looping between branches and a trunk. |
| June 6, 2019 | MDWFARFP command to automate the update of the MDWorkflow Test Acceptance status for Project(s) in installed RFPs.
Alternatively, the REST API resource /rfp/acceptance can be invoked to perform the update via REST. |
| June 14, 2019 | REST APIs added for:
|
| June 28, 2019 | Selected Filter Conditions for the MDCMS Installation History Report and Objects modified outside of MDCMS Report are now included in the footer of the report for auditing purposes. |
| Standard Wildcards added: ##SYSLIB## – the system name of an SQL schema (library) ##SYSNAM## – the system name of an SQL object |
|
| if receiving an object from another branch, and the object is currently checked out at the bottom level of the target branch, the received object will still be requested, but in unlocked status, so that the entire contents of the branch RFP are available, but requiring developer decisions to proceed with the merge into the target branch. | |
| July 7, 2019 | The MDJIRA interface has been enhanced to:
|
| July 31, 2019 | New IC (Installation Complete) object request and RFP status to provide a clear indication of when the target application is free to be used again during the deployment process. RFP cleanup continues while in IC until status 05 (RFP Complete) is reached. If the RFP job abnormally ends while still in IC status, the Close option can be used for the RFP in MDCMS or MDOpen to continue the cleanup phase where it left off. |
| Auto-Rollback an RFP if the copy of data fails, unless a Data Copy command is defined that explicitly ignores exceptions. | |
| August 2, 2019 | Special value *MD can be used for the Project ID in Continuous Integration to extract the Project, Task and Subtask from the Commit message |
| August 10, 2019 | Allow the send of settings from any level to any defined location, rather than only to locations targeted by the level. |
| Ability to view the committed IFS source for a system/SQL object using option S | |
| August 17, 2019 | Ability to distribute RFPs and Attribute Settings via ObjectConnect (SAVRSTOBJ). If ObjectConnect is installed and configured for communication between the source and target system, MDCMS can distribute RFPs and settings using the new method OBJ. This method provides the ability to transfer the information without requiring some form of FTP or SNA to be configured and enabled. |
| September 7, 2019 | Db2 Mirror for i handling – MDCMS automatically handles the inclusion or exclusion of temporary libraries for optimal performance in a Db2 Mirror for i environment. |
| October 13, 2019 | Password handling for OS/400 Locations, Remote Server Locations, Email Settings, SVN User/Password authentication and Git User/Password authentication now have the following changes:
|
| Email names and addresses are stored in UTF-8 to ensure correct symbol usage regardless of job code page | |
| Allow compile commands defined for an attribute to be used only for modifications or only for recompiles to allow for differences in compile parameters based on if modification or recompile. | |
| when requesting to compare/merge currently checked out source, the target source to compare to is automatically defaulted to the source in the application based on the standard source search configuration. | |
| The MDCMS Configuration Report now includes the OS/400 Locations | |
| December 4, 2019 | The MDCMS REST APIs can now be used at no additional cost by any organization that has a valid MDWorkflow license |
| The version of Java to use in MDCMS can now easily be managed directly from the system settings | |
| December 18, 2019 | ServiceNow Interface – MDCMS now interfaces with the incident management tool ServiceNow to allow sharing of tasks between the 2 products, or as a bridge between Jira and ServiceNow. More information available in the tutorial. |
| Command MDADDSRQ added to be able to systematically create and populate RFPs in the Send Listing with objects to be sent to other locations. | |
| January 2, 2020 | Authority of temporary libraries created by MDCMS for the receipt, install, backup and rollback of objects now based on Object Authority templates. Each Promotion Level can be applied to a different template. |
| Pressing F15 in the Send History screen now creates an MD Report rather than spooled file for better viewing and export to other formats. | |
| January 10, 2020 | When using MDFTP to send RFPs to a target system, the target folder can be modified in case the target system is on a different ASP than the local system, or if needing to send to a DMZ server to forward to the target. |
| When using SFTP to send artifacts to a server, the Remote Server Location definition in MDOpen now provides for authentication using SSH keys. | |
| February 4, 2020 | MDOBJRPT command to be able to automatically generate a report of active or historical object requests based on Application, Level, RFP Number, Project, Task, Subtask, and Programmer filters and to automatically email the report or copy the report to IFS. |
| *CD as date parameter value for the Installation History Report to report on activity only for the current day | |
| Auto-set the margins parameter when using the RUNSQLSTM command to execute SQL scripts within MDCMS so that the margins match the actual width of the source file containing the script. The Wildcards in SQL flag must be true for the command for this to be enabled. | |
| February 17, 2020 | MDRCVRMT service to be able to pull RFPs or settings from another system. This is useful when a firewall only permits outbound communication and blocks inbound communication. For example – the test system isn’t allowed send RFPs to Production, so on test, method SFF can be used to place the RFP in the IFS and then the MDRCVRMT service on production can use FTP or MDF (MDFTP client for FTP, FTPS or SFTP) to listen for RFPs/settings on the SFF folder on the test system. |
| March 3, 2020 | The maximum size of a description for MDCMS projects, tasks and subtasks has now been increased from 9,999 characters to 180 million characters.
Also, if the description is edited in MDWorkflow so that it is in html format, then it will be shown as read-only in green screen or MDOpen to avoid losing the rich formatting. NOTE: If upgrading the core to 8.2.5, MDOpen and MDWorkflow also have to be upgraded to 8.2.5. |
| March 6, 2020 | MDMIGLMI tool to migrate LMI history, object-specific compile commands and archived source into MDCMS for those customers making the switch from Aldon (Rocket) LMI to MDCMS. |
| March 27, 2020 | MDMIGARC tool to migrate ARCAD history and archived source into MDCMS for those customers making the switch from ARCAD to MDCMS. |
| April 2, 2020 | When using a separate a library for source development than for object development, MDCMS now remembers the preference for each for each checkout level and developer. |
| When compiling an object into a developer library, the developer’s object library and source library are added to the top of library list, when flag to include developer library is set to true. | |
| April 13, 2020 | New template type to automatically create Field Procs in a new version of a changed file to match the Field Procs in the prior version, based on a number of naming patterns for the program, file and field. Particularly useful for reapplying encryption procs prior to copying the existing data to the new version of the file. When used in conjunction with MDRapid, no additional application downtime is necessary to apply the Field Procs. |
| Object stamping and Object Authority setting moved from the installation phase of an RFP to the build phase in order to reduce the application downtime window and to ensure the objects are properly secured while in the temporary installation libraries. If replicating objects to multiple libraries without using MDRapid, Object Authority still necessary during the installation phase. | |
| New flag on Object Replication and Source Replication Templates to ignore deletion from specific replication locations when a a Delete Template is executed for the attribute at a higher level. | |
| Description field for Object Replication and Source Replication Templates for easier understanding of use of the templates. | |
| April 15, 2020 | Handle the export of spooled files when they contain DBCS data |
| April 24, 2020 | New Job Control settings to easily create and maintain Subsystems, Job Descriptions and Job Queues for use in MDCMS or elsewhere.
This is accessible from the MDCMS Setup Menu option 12. Previously, option 12 was for Email settings – those settings continue to be accessible from Services (option 13)->MDMAIL→F10 to be consistent with the administration of all other Services. Email settings also continue to be available from MDSEC option 12. |
| automatically reset the next value for an Identity Column on a table when using CPYF to migrate records into the table using the *DATA or *DTAGRP attribute | |
| only get a *SHRRD lock instead of an exclusive lock on a source member to be copied from to limit possibility of delaying the bundling or sending of an RFP. | |
| May 5, 2020 | Quick access to the MDCMS Job Description listing/maintenance tools using F10 from the Job Settings or with command MDWRKJOBD. |
| MDCMS Rest API resource gitlab/webhook to use as a webhook in GitLab to automate updates of cross-references and CI/CD when a commit occurs to GitLab | |
| MDUPDTASK parameter NSTS (new Task/Subtask) enhanced with new value *REF to base the task or subtask to create or update on the Internal Reference code for the Project’s task/subtask. Useful when the calling process isn’t aware of the MD task/subtask number. | |
| June 2, 2020 | Pre-Object Request validation exit point. Command type B can be defined for attributes or specific objects and will run when a developer tries to request (checkout) an Object for custom validation to verify that the checkout can proceed and/or provide further information to the developer. |
| RFP Archive/Cleanup exit point. Command type Q can be defined for attributes, specific objects or RFPs and will run during the final archive/cleanup phase of an RFP installation. If for an RFP, it is intended to run commands such as notifications, etc. that can occur when the application is no longer considered locked for deployment, whereas the existing command type 3=Post Installation, runs within the downtime window, causing to take longer, and can trigger a rollback.
If command type Q is defined for an attribute or specific object, it is run when the source or object is about to be archived so that additional archiving processing or comparisons can be run. |
|
| MDCMPPFM command – this command compares 2 source members and generates a report in PDF or TXT which can then be placed automatically in an IFS folder. This command can be used for any source comparisons but is particularly intended for use with command type Q to automatically create a report of source code changes deployed by an RFP. | |
| Ignore Errors flag added to Replication Templates – if a replication library/folder has ignore errors set to Y and an RFP fails to replicate the source/object to that location, then a warning will be thrown, but the RFP will continue. | |
| June 7, 2020 | Object Attribute and Object Description added as optional columns to the MDCMS Installation History Audit Report and the Objects modified outside of MDCMS Audit Report |
| June 10, 2020 | The *REQONLY special value for the source file name on an attribute definition can now be used for any attribute that can contain source. This is to provide a way for any such request to travel to production when the source and object shouldn’t be deployed on production so that when the RFP returns to update the copy of production on a development partition, the indirect source can be retrieved and compiled to place the source and object in the production repository and clean up any delta environments. A good use case for this is *MODULE objects. These typically aren’t needed on production but are important on development. |
| When checking out an existing object without specifying the attribute, MDCMS will now not only check which object types exist for that name, but also if any *SOURCE installations have previously occurred for that name. If so, then *SOURCE will be added to the bottom of the object type list that the user is prompted for to select which type to use for attribute selection. | |
| The RFP command generator (F9 from the Commands settings) now suggests post-installation notification commands as type Q commands instead of type 3 commands and it’s recommended that any already defined notification commands of type 3 be changed to Q. This is because type 3 commands run within the application downtime window, but type Q commands run after the application is flagged as being available for use again. | |
| Since Midrange Dynamics always recommends compiling logical files, including SQL indexes and views, in order to ensure correct schema usage, the distribution rules default to B=Both for such entities when the distribution level rule is that source shouldn’t be sent. And, when configuration settings are pushed or send/received and Include Source is set to No, the source file will still be retained for logicals, but with the library set to *TEMP and the compile command will be retained. This should significantly reduce exception handling during the configuration of an application on production systems. | |
| June 19, 2020 | Ability to rename an existing project with option 7 from the green screen Project Manager. All locations of the project element, including user preferences, are renamed with the exception of API log files for historical purposes. |
| Ability to rename an existing application code with option 7 from the green screen Application settings. All locations of the application element, including user preferences, are renamed with the exception of API log files for historical purposes. | |
| June 23, 2020 | Ability to rename an exiting MDCMS attribute with option 7 from the green screen Attribute settings. All locations of the attribute element, including user preferences, are renamed with the exception of API log files for historical purposes. |
| Always sync rename of projects to other synced locations and optionally sync rename of application codes to other synced locations. | |
| July 12, 2020 | MDCMS now includes a complete interface for locking, requesting and deploying Synon/2E objects |
The default attribute generation wizard (F9 from the attribute settings) now has the following enhancements:
|
|
| The MDPUSH and MDPULL jobs to asynchronously share data with other MDCMS locations are now substantially faster | |
| August 2, 2020 | Significant Object Replication Template Enhancements:
|
Ability to package multiple objects or source members of the same name in the same RFP, when for different target libraries. This is typically used when an object has several versions based on the language. This is now available for the following typical language-dependent types:
Data Groups already allowed for this |
|
| MDADDSRQ command to systematically add object requests to a Send RFP now has special value *OBJLANG for the object name (OBJN parameter).
When used, MDCMS will loop through all existing requests in the RFP of the given object type and object attribute and see if that object has versions for other languages. When true, the objects of the other languages will also be added to the RFP. This can be done automatically prior to sending an RFP by using the command type 5 (pre-send). |
|
| Backup Library Retention in days. A new property in the System Settings can be set to retain temporary backup libraries a certain number of days after the installation of an RFP is complete. This can be helpful in case database changes occurred to avoid immediately losing the old format of the data records.
If the retention is set to 0, the backup libraries will be deleted immediately. Otherwise, the MDCLEAN service will delete them once they’ve reached the required minimum age. This replaces the User-Specific parameter Delay Delete Prior Objects that was available at submission time to ensure a consistent handling for all RFPs on the partition. |
|
| If using the Get Prior Source or Get Prior Object option in Installation History, automatically go into PDM for the source or object after the archived version is retrieved. | |
| Prior to the Send of an RFP to a local level, verify that the attributes are correctly defined for the target local level. | |
| August 9, 2020 | From within the Object Listing for an RFP in the 5250 RFP Manager/History, option X=XREF has been added to be able to navigate directly to MDXREF for the selected object to obtain further information about it. |
| August 17, 2020 | Object and Source Replication Template libraries can now be filtered by one or more Projects, Tasks or Subtasks so that a library is only populated with an object or source if it is assigned to one of the filtered project elements. |
| Improve MDCMS attribute suggestion for an object request by checking the source attribute for a member in any library when the member isn’t in the target library | |
| August 21, 2020 | When an Object Request is created, any Object Specific commands are applied to the request. Until now, the Object Command had to be defined for a checkout level for it to picked up and applied. Now, the command will also get applied if it’s defined for a higher level in the chain of levels on the development partition. |
| September 16, 2020 | Show the compile subsequence for an object request in the option 5=view screen from the object manager, when the subsequence > 0 |
| October 15, 2020 | MDLOG service to perform all RFP installation and send logging in a separate job rather than inline within the RFP process. This makes the RFP run about twice as fast for a mid-sized RFP (50-60 objects) and can be over 6 times faster for RFPs containing more than a thousand objects. |
| Within the RFP deployment log screen within MDCMS, F5 can be pressed to refresh the log list, F17 to go to the top of the list and F18 to go to the bottom of the list | |
| Create a send package from any amount of installation history for a level.
Pressing F6 from the MDCMS RFP Send List now provides a dialog to create a send RFP based on installation history filtered by:
Additionally, MDCMS can automatically create one RFP for DB objects and 1-n RFPs for non-DB objects. This new feature makes it very simple and secure to collect all necessary changes for a branch release or a release to be distributed to other systems. |
|
| Performance optimizations for compiling SQL entities and for handling logical files, including indexes and views | |
| October 30, 2020 | If an RFP fails and rolls back during the INSTALL phase and a user re-submits the RFP, the RFP Log including job log entries will be automatically exported to the Report list for the user defined for the job description for the target level in order to avoid losing log information about the prior, failed attempt to install. |
| November 9, 2020 | The target library and source file for a source member is now stamped into the object description during the compile phase of an RFP for better traceability of the source when looking at the object properties. This eliminates the possibility of a temporary library in the source location properties for the object and speeds up the RFP compile process by removing the steps of copying the source into the target library and then reverting it again. |
| Improve performance for the deployment of tables through more efficient checking of temporal table/history table attributes | |
| November 19, 2020 | Ability to provide a description for the Object Authority templates |
| November 27, 2020 | When performing an Include Related Objects or when the pre-submit validator checks for missing dependencies, MDCMS will now only include a dependent file over a reference file if the dependent file uses a field that has changed in the reference file to limit the amount needed to recompile to the truly impacted files.
Additionally, physical files using reference fields will be included in the missing dependencies list in addition to display files and printer files. |
| December 13, 2020 | In the Send RFP listing, a location filter has been added. When a value is entered in the location filter, only open RFPs in the Send list that have the location as a target will be listed and the status, receive and install values are shown specifically for that location in order to easily filter and view the state of all open RFPs for a location. |
| Show the RFP user in the Send RFP history listing instead of the send/ignore user, but include an RFP when filtering by user and the user is either the RFP user or the send/ignore user. | |
| F9 button added to Services listing to filter list of services to only those with active jobs | |
| While performing the MDINSSAVF command to install or update to a newer build of MDCMS, the green screen, MDOpen, RFP and services jobs will be locked from using MDCMS to avoid possibly corrupting an ongoing update to the product. |
