![Wink :wink:](./images/smilies/icon_wink.gif)
Again, and I cannot emphasize this enough, the DataStage monitors and logs show actions sent to the database in question and the errors that it report back, something that isn't always one-to-one. For inserts, sure, you should be able to find a number of records in the target that match the monitor count however there's no such guarantee with updates or deletes, both of which can affect multiple records based on the keys chosen.
Your assertion that every update at various frequencies should be present in the table is impossible to know without intimate knowledge of the table structure and the update strategies employed. There really is no "given" there. Which brings us back to the issue of the end users not being able to "find" the records your job is inserting. Since they are typically constrained to BI tools with canned metadata and reports with who knows what in the way of constraints, I'd be more concerned if you cannot find them with SQL tools. And then correlate what you find with your knowledge of what the job is doing, the indexes / keys on the target table (etc) to determine whether or not a legitimate issue exists. I continue to be concerned by the fact that you keep mentioning "load" and "insert" and "not updated" for this, it makes me seriously wonder if there really is an issue here or not.
![Confused :?](./images/smilies/icon_confused.gif)