1. Home
  2. Knowledge Base
  3. MDCMS Enhancements in 8.2

MDCMS Enhancements in 8.2

From Build Date

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:

  • WebHook for JIRA so that JIRA can now start automatically when necessary and doesn’t need to poll JIRA anymore on a frequent basis
  • WebHook for Bitbucket and Github to automatically know when new files in a Git repository need to be cross-referenced or checked out for continuous integration
  • WebHook for SVN servers to automatically know when new files in a SVN repository need to be cross-referenced or checked out for continuous integration
  • APIs for creating object requests, projects, tasks and subtasks
  • APIs for retrieving various information about the environment, RFPs, projects tasks and subtasks
  • APIs for submitting, approving, installing, accepting and sending RFPs
  • API for MDSEC user management
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:

  • For Database – the target database the alias should point to. This value is then used wherever the wildcard ‘##RMTRDB##’ OR ‘++RMTRDB++’ is found in the create script
  • For Library – the target library the alias should point to. This value is then used wherever the wildcard ‘##RMTLIB##’ OR ‘++RMTLIB++’ is found in the create script
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:

  • Allow Manual Task Creation
  • Import Tasks from Jira
  • Export Tasks into Jira
  • Import Tasks from ServiceNow
  • Export Tasks into ServiceNow
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
##OBJDSC## – Object Description
##SRCATR## – Source Attribute
##SRCDSC## – Source Description

Jira Interface Enhancements:

  • The interface between MDCMS and Jira now provides the ability to export tasks from MDCMS into Jira.
  • The contents of any Jira field can now be mapped to custom fields in an MDCMS task and the values can be imported or exported, regardless of where the task originated.
  • The projects themselves are now mapped between Jira and MDCMS, rather than the mapping by Project Categories, for better granularity.
  • Issue imports can be omitted, if the assignee for an issue isn’t mapped to an MDCMS user.
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:

  • RFP Submit
  • RFP Approval
  • RFP Install
  • RFP Test Acceptance
  • RFP Send
  • MDSEC User Management
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:

  • Map specific Projects between MDCMS and Jira for better granularity rather than any projects for a Project Category
  • Option to omit the import of an issue, if the issue isn’t assigned to a user that is mapped to a MDCMS user
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:

  • passwords can now be up to 40 characters in length and are centrally encrypted and stored in table MDSEC/MDDCRED
  • UTF-8 storage of the passwords to ensure identical symbols regardless of job code page
  • password only needs to be entered once instead of twice and has the option (F14 in green screen, eye icon in MDOpen) to view the entered text for better certainty. For security purposes, only newly entered passwords can be made visible – any registered passwords can only be reset, but not viewed.
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:

  • check and auto-select attributes based on objects in the system catalog, in case the target library isn’t yet in MDXREF
  • option to update existing attributes
  • option to filter the attribute listing
  • attributes added to manage Synon/2E objects
  • ability to specify IFS subfolders within the IFS source parent folder, depending on the attribute.
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:

  • Separate Add and Update rules per library
  • Include/Omit Pre-Install/Post-Install commands or scripts per library
  • Use of generic naming patterns for dynamic selection of libraries for add or update
  • Use of *ALL to dynamically check all user libraries for object to update
  • Ability to override the Replication Template add and update rules for a specific Object Request using option O in the Object Manager
  • The SQL Replication type has been replaced with the OS400 Replication type, so that both SQL and non-SQL library definitions can be managed in a single template.
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:

  • Display Files
  • Printer Files
  • UIM Menus
  • *MNUDDS Menus
  • Message Files
  • Message Descriptions
  • Panel Groups

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:

  • Install Date Range
  • RFP Number Range
  • Project (*generic*)
  • Task
  • Subtask
  • Object Requester (*generic*)
  • Object Library (*generic*)
  • MDCMS Attribute (*generic*)

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.