Originally posted by: SystemAdmin

We have a situation where some interfaces are hanging when creating db entries. They were last updated with only a modification to the 'where' clause of a query, so only the updated MDQ is pushed to production. When a map with tracing enabled is pushed (a new .sun file), to monitor these errors, the interface no longer hangs.

Is it necessary to push a new version of a map when a change is made to the mdq(even if this change has no effect on the data content)?
I've always know this to be unnecessary, and with the complications of SOX, we try to move only modified code to production.
#IBMSterlingTransformationExtender
#DataExchange
#IBM-Websphere-Transformation-Extender

Originally posted by: SystemAdmin

It depends. If you use the -MDQ and -QUERY qualifiers in the Get-->Source-->Command line, then I believe they are located dynamically at run time. I think that's the effect you're looking for.

If you don't use those qualifiers, then the contents of the query named in the Get--Source-->DatabaseQueryFile are compiled into the map and you'll need to rebuild the map for the revised query to take effect.

The same is true for DBQuery/DBLookup calls. If you use the three argument syntax (e.g. "Select <yada>,"something.mdq","somequery"), then that gets compiled into the map and you'll have to rebuild to get the revised query to take effect. Using the two argument syntax (e.g. "Select <yada>,"-mdq something.mdq -query queryname") then simply replacing the mdq file is enough.

The map shouldn't hang, though. I don't think it should even be looking into the MDQ file if you're not using -MDQ
#IBMSterlingTransformationExtender
#IBM-Websphere-Transformation-Extender
#DataExchange

Originally posted by: SystemAdmin

Might be a good idea to test any changed to any system component in a test environment, before going to production. Ideally the test/ Q/A / system is a mirror of production, and you can copy the changed files from test to prod without a redeploy.
#DataExchange
#IBMSterlingTransformationExtender
#IBM-Websphere-Transformation-Extender

Originally posted by: SystemAdmin

We certainly did use a system test prior to the production move.

No hangs were encountered until the move.

The work around is to push a recompiled map. I just was looking for an explaination of the need to do this.
#IBMSterlingTransformationExtender
#IBM-Websphere-Transformation-Extender
#DataExchange

Originally posted by: SystemAdmin

If you didn't need to redeploy the map in test, you shouldn't need to do this in production. If you are on a UNIX platform, run the UI script against both environments and check the files to see if there is something different.

If the MDQ is compilded into the map (in the Database section of the card) then you must recompile the map, if the MDQ is not used or is in a rule or command line (-mdq) then you do not have to recompile the map as long at there is no change to the format or data type entering or leaving the map.
#DataExchange
#IBM-Websphere-Transformation-Extender
#IBMSterlingTransformationExtender