Asynchronous Data Replication

Previously, any Project, Task or Object information passed to other systems using DDM was done synchronously, potentially causing long wait times when many systems were involved. Now, nearly all data sharing and RFP and MDWorkflow information is done via separate MDPUSH and MDPULL service jobs.
MDPUSH is recommended and possible when a target location allows this system to connect to it via DDM. If this system can’t connect to that system, then data can be staged on this system and the other system can be defined to use MDPULL to get the staged data.
Now that the data replication doesn’t impact the interactive jobs, much more information is shared between the systems for much better understanding of deployment status across systems and for very fast MDWorkflow usage.

Simplified Connection Definitions

OS/400 locations are now used to define DDM connections and RFP distribution connections, so that if something changes, like a password or host name, it only needs to be changed a single time.
An unlimited number of Distribution Levels can use the same OS/400 location while still having certain parameter overrides available per level. F6 from the Distribution Level screen allows for multi-selecting many locations and many Promotion Levels in order to create a super-set of all combinations in seconds.

Test Connections

Option T=Test has been added to easily test if a connection is possible for an OS/400 location or Distribution Level.

Java Connect Password Removed from System Settings

It is no longer necessary to store the password for the java connect user in the system settings. When the MDFTP, MDMAIL, or MDSIGN service job is submitted, it is now submitted to run under the java connect user profile so that the password doesn’t need to be known to MDCMS. A valid password must still exist for the user profile itself, however.

Promotion Level Settings

New Flag – Auto Close Sent RFP – the migration to 7.4 sets it to S=Sent to mimic the behavior of prior versions of MDCMS. This means an RFP will no longer show in the Send screen once all default queues have successfully been sent to. Alternately, the following values are possible:
N – don’t automatically close RFP
R – close after successful receipt on every sent queue
I – close after successful install on every sent queue
Even when closed, the targets can still be tracked or reopened from send history.
New Flag – Level Check Warnings – This indicates if modules and programs being migrated without compile should be checked for file format levels and warned when mismatches are found. The migration sets it to Y to mimic the behaviour of prior versions of MDCMS but can now be set to N per level. Any warnings are now placed directly in the RFP Log rather than in a spool file.

Services

All services can now be listed and managed from a single screen.
For each service, where applicable, the following can be defined:

• Auto-Start
• Default Job Queue
• Runtime Window
• # of Parallel Jobs to start
• Delay in seconds between processes
• SNA user

The user also sees which services are already running and can start/end them from the list. The services are:

• MDFTP
• MDMAIL
• MDPULL
• MDPUSH
• MDRCVIFS
• MDRCVSNA
• MDSIGN

Log Maintenance

All MDCMS logging can now be listed and managed from a single screen. From the Logging Settings Menu option, the age of a log entry before it is purged can be set for each log.

Quickly Push Settings to multiple Locations via DDM

Settings (Applications, Levels, Attributes, Commands, Scripts and Templates) can be defined to be pushed via DDM to many locations simultaneously. The contents of settings can be heavily customized and the settings can be sent to other instances of MDCMS on the same system or other systems.

Track Status and Problems for Distributed RFPs from Send Screen

The RFP Send screen has been substantially enhanced to not only send an RFP, but also to see what the status is of the RFP on the target systems and to review any problems that occurred on the remote systems during the receipt or installation of the RFP.
If the user has the authority (new MDSEC code 54 added), they can ignore individual targets or prematurely close the RFP in the send list.
The Send History also displays the status and problems found for the RFP on the target systems.

RFP Receipt Logging

When an RFP is received from a Remote System, it, and any warnings or errors that occur, are logged. The log can be viewed by pressing F10 in the Receive Promotion main menu option.

RFP Installation Logging

All steps that occur between the moment that an RFP is submitted until it is installed are logged for a very easy and complete understanding of what occurred during the RFP run.
Each step has includes a severity number, date, time, message, and object involved.
The severities:
10 – informational message
20 – a warning occurred during the processing of the step, but the RFP continued
30 – a fatal error occurred for the step, causing the RFP to roll back.
When a warning occurs, a W is attached to the RFP status. When an error occurs, an E is attached to the RFP status.
Option L can be used for an RFP to see the steps processed during the most recent installation attempt of the RFP. For each step, option J can be used to see the job log entries for that specific step, making it very quick and easy to be aware of, and troubleshoot, problems.
The log, with or without the job log entries, can be exported for viewing in excel etc.

RFP Manager and RFP History available directly from Main Menu

Menu option 3 (Approve Promotions) has been replaced by RFP Manager. The RFP Manager remembers the filters and controls from the prior session so that the user view best fits the role for that user. Command keys can be used to quickly toggle between controls (submit, approve, install, manage, or history).
Menu option 4 (Install Promotions) has been replaced by RFP History. This displays installed RFPs by installation date/time for quick access to logging, object and rollback information. This option also remembers the filters and controls from the prior session.

Send RFP and view Send Status directly from RFP History

Option T, Target Locations, has been added to the RFP history display to view the send/install status of each target location for the RFP in location sequence. If the RFP is open in the Send View, the RFP can also be sent directly from this view.

Filter RFPs by Prior RFP or Original RFP Number

Since MDCMS generates a new RFP number for each level in order to provide full flexibility from level to level, it can be helpful to be able to filter for RFPs based on the prior RFP number or the original RFP number from the development level. This is now possible from the RFP listing.

Automatically Delete Logical Files when Creating PF in Dev Lib

When attempting to create a checked out physical file in the developer library, MDCMS now automatically deletes any logical files that are over that file, as long as the logical files exist in the same library as the physical file.

Object Pre-Compiles and Post-Compiles aligned with Compiles by Object

Previously, MDCMS executed all Object Pre-Compiles together before stepping through the Compiles and then finally all Post-Compiles were again executed together.
Now, for each object, any Pre-Compiles are run, followed by Compiles, and then the Post-Compiles relevant for that Object or Object Attribute. Then, the process starts over for the next object in the list, providing better granularity for the commands.
The exact same handling is now also used when creating an object in the Dev Library so that the commands can be unit tested identically to how they will run during an RFP (including OVRDBF commands).

Warning at RFP Submit when Original Checkout older than most recent Install

In order to increase awareness of potential conflicts, MDCMS now compares the date/time when an object was originally checked out to the date/time of the most recent installation of the object into the target level. If the checkout occurred before the installation, a warning is displayed, indicating that work was still in process in the migration path when checkout occurred.

Search for Source/Object in Conflicting Libraries

The templates for Source Search and Object Search have been enhanced with the parameter Display Warning, which can be set to Y for any library that is considered to potentially conflict with the target library of the attributes using the template.
When a checkout or library migration occurs, the existence of the source and object is checked in the defined warning libraries for the search templates. If found, a warning is displayed before the checkout is completed, allowing the developer to decide if they should continue or not.

Track where Source was copied from for Checkouts

When a developer requests to modify source and copies the source from a location to the developer library, the From Location is saved with the request. This information can then be viewed in the object manager display or in installation history for the checkout level.

Object Type Selection List when Requesting Non-Unique Name

When a developer requests an object, and the object name occurs for multiple object types, the developer is automatically prompted to select the appropriate object type from a list.

Script Execution for IFS Objects

Script execution has now been expanded to be applicable for *IFS objects with the same wildcard and other abilities as for *REMOTE objects. When an *IFS script is to run, the QSH command is executed. Additional parameters have been added to indicate if the QSH command should run as part of the RFP job or if and how it should be run as a separate job.

Script Definitions for Specific Objects or RFPs

Scripts can now be defined for specific objects and/or specific RFPs with the same handling and reusability as for commands.

Script Execution Log for Windows or Linux included in RFP Log

The server log for the execution of a script on a Windows or Linux server is saved to the RFP log for simple, centralized troubleshooting of script issues.

Filter Object Listing by Objects with Commands or Scripts defined

The object listings in MDCMS or MDOpen can now be filtered to those objects containing commands or scripts at the object level.

Option to Clear a File when Recompiling

For physical files (or tables) that are requested for Recompile, the Data Migration parameter can be set to *NONE. When this is the case, any existing data will not be mapped to the new format of the file.

Location Filter for Execution of Object or RFP Commands

Commands that are defined to run for a specific Object or specific RFP can now be configured to only run for certain locations. The possible values are:
*ALL – run command for every location where RFP will run (default)
*LOCAL – run command only for any level on local system
*LOCLVL – run command only for this level on local system
*REMOTE – run command everywhere except on local system
Location ID – run command only on specific system

Queries sorted before Modules/Programs

Queries and QM Queries are now processed in an RFP prior to compiling modules or programs. This provides the timing to run the query to generate an output file that the module or program may depend on.

View Usage and File Name when including Related Objects

When requesting to include related objects for a file, the file usage and file name (physical file itself or logical, display, or printer file referencing the physical file) are displayed for each related object. This assists in deciding if the object should be requested.

Retain File Locks until Installation is Complete

During the Installation of an RFP, MDCMS now retains an exclusive lock on the impacted files until the installation is complete in order to avoid potential premature usage of a new version of the file.

Option to Include RFP Commands when Copying Completed RFP

When a previously run RFP is copied in order to generate new object requests based on the contents of the prior RFP, an option is now provided to also copy any Commands defined for the specific RFP.

Navigate to RFP Listing from Installation History

Option R=RFP has been added to the installation history screen to navigate directly to the RFP listing filtered by the RFP for the selected object. This provides quick access to the RFP information, such as logs, commands and other objects.

Optional Deployment of *REMOTE Objects for Promotion Levels

If the migration path for an Application containing *REMOTE objects (objects distributed to non-IBMi systems such as Windows or Linux) should not distribute the objects for certain levels due to a lack of a system at that level, server special name *NONE can be used.
MDCMS will still carry the object bundle forward to the next level for potential distribution later in the migration path.

Handle Programs with Adopted Authority when Restore not permitted

If a program object is to be sent to a target system, but *ALWPGMADP or *ALL not defined for QALWOBJRST on the source system, then MDCMS automatically removes the adopted authority from the program prior to saving it and then reapplies it again. If adopted authority is required on the target system, then a post-compile command should be attached to the object or attribute to reapply it at deployment time.

MDUPDEMLA Command to Update Email Address for User

Command MDUPDEMLA has been created to provide a systematic means to add or change the email address for a user in MDCMS without using the Interactive Settings Menu option.

Data Copy Templates may now Include/Omit Data Areas

When using the Data Copy template to copy data from one set of libraries to another, data area contents can now also be included. Specific data areas that shouldn’t be included can be omitted in the list.

MDWorkflow Settings and Acceptance available from Green Screen

In order to be able to proceed with RFP Workflow acceptance in case the web server isn’t available, the features to manage User Groups, Group Types and Acceptance Group Types, as well as to perform RFP Acceptance are now available from green screen.

Optionally Archive *DATA and *DTAGRP Records

Archive Prior Contents parameter added to *DATA and *DTAGRP attributes. When set to Y, the prior collection of impacted records is archived when the new records are installed, allowing for viewing and rollback of data. If set to N, the records won’t be archived to save disk space.

Command Type O for Sending Data per Location

Command Type O – Data Copy during Send has been added to provide the ability to filter the records in a table based on target location.