Kisco Systems
iEventMonitor
iEventMonitor : Support : Problem Reports

The following is a list of problems reported for iEventMonitor along with the solutions that we have developed for them. If you have a problem that is not covered here, ask us via E-mail and we'll address your problem.


Register your E-mail address to receive automatic notification when this product is updated.


iEventMonitor Problem Reports

Index:

iEventMonitor Release Independent Problem Reports:


iEventMonitor Release 8 Problem Reports:


iEventMonitor Release 7 Problem Reports:


iEventMonitor Release 6 Problem Reports:


iEventMonitor Release 5 Problem Reports:


iEventMonitor Release Independent Problems:


I have entered a "Support Email Address" in IEMSET (option 9 on the INSTALL menu), but that email address is not showing up as the sending address in iEventMonitor alerts.

The "Support Email Address" in IEMSET is only used when the "Use SNDSMTPEMM?" parameter is set to *NO. When using the IBM i OS SNDSMTPEMM, the sender's email address can be controlled using the user profile's SMTP user setting. To access this, use the IBM i OS command WRKSMTPUSR.

Most functions in iEventMonitor use the IEMONITOR user profile that was created during installation processing. Locate that profile in the list that is displayed when you run the WRKSMTPUSR command and place a 2 next to it to update it. Roll up to see the "Originating from" setting. It will probably be set to *NONE. Change this to the email address that you want to be shown on the alert emails that are issued by iEventMonitor.

Kisco recommends that you test this after making the change. You can force a test alert to be issued from the IEMONITOR user profile by using the following command:

SBMJOB CMD(IEMLIB/SNDALERT MESSAGE('This is a test alert') ETITLE('iEventMonitor Test Alert')) JOB(TESTALERT) USER(IEMONITOR)

Check to make sure that the email gets delivered correctly and that the sender's address is what you are looking for. If this change results in email delivery issues, change the setting in the WRKSMTPUSR command back to *NONE until you can figure out the issue. For some users, this change may result in your alert email getting delivered to a junk or spam folder.


iEventMonitor seems to have stopped working.

We recommend a full reset of iEventMonitor to see if that resolves this issue.

You can do the reset using the following process:

  • Shut down all current tasks using the ENDIEM command in library IEMLIB
  • Check your system to make sure that the IEMONITOR subsystem has ended. If not, force it to end.
  • Run the following IBM command: WRKWCH *ALL
  • If there are any iEventMonitor tasks showing as active, use option 4 to end them
  • Restart iEventMonitor using the STRIEM command in library IEMLIB

If this does not resolve your issue, contact support@kisco.com


Some email alerts going to Gmail users are being rejected by Google with the message "550 - Messages missing a valid messageId".

If you are using the SNDSMTPEMM option (on the IEMSET settings), this can happen and is an issue in the IBM i OS, not in iEventMonitor. IBM now recommends PTFs for OS releases 7.3, 7.4 and 7.5 to address this problem. If you are having this issue, please install the following IBM PTFs on your system:

  • IBM i OS 7.3 - PTF SI82395
  • IBM i OS 7.4 - PTF SI82394
  • IBM i OS 7.5 - PTF SI82396

My test email is not going through - when I look at the joblog, I see "Command failed. reason -108 failed to retrieve path information (PATH-/TMP,3525:Object is too large to process.)

The 108 code indicates that either the /TMP folder in the IFS does not exist on your system or that when you ran your test SNDALERT, it was locked and unavailable.

If it does not exist, all you need to do is create it. You can do so with the following command:

MD DIR(tmp)

If it was locked because of a save operation running on the folder, then it should work once that save has completed.


The message queue watch process has stopped working following a system error associated with the watch process.

There are several reasons possible for the message queue watch to stop working. To do a full reset of all iEventMonitor processes, issue the ENDIEM command from the IEMLIB library and then wait for the IEMONITOR subsystem to end. Once you have confirmed that the subsystem has ended, issue the STRIEM command, also from the IEMLIB library, to restart all iEventMonitor tasks. Issuing the STRIEM command when the subsystem is not running will force all internal settings in iEventMonitor to reset during the startup.

In some cases, however, this will not resolve an issue with the message queue monitor not responding to messages in the message queue. When that happens, the IBM i OS watch API process may need to be reset. The easiest way to do this is to IPL your system, but doing an IPL is not always convenient.

IBM appears to be aware of this issue and they have published the following support article with a manual recovery process that you can use:

https://www.ibm.com/support/pages/watch-programs-stopped-working

We have had mixed results when using this process. You should be aware that some system functions use the watch API process and this manual reset calls for you to manually end them all. You may need to contact IBM support to get those processes restarted correctly.


I'm implementing the IEM Respond feature. The test page comes up after I've completed setting up the HTTP Server Instance, but when I test the feature using the test option, I get an "Internal Server Error" in the browser session. Looking in the server error logs, I can see a ZSRV_MSG0947 error code.

We have seen this for a few customers. First, check to make sure that the HTTP Service Instance was installed according to our instructions and that no short-cuts or alternative methods were used. If that checks out and you still have this problem, then it is most probably a security issue for accessing the application library named IEMLIB.

You can resolve this by running the following two commands:

GRTOBJAUT OBJ(QSYS/IEMLIB) OBJTYPE(*LIB) USER(QTMHHTP1) AUT(*USE)
GRTOBJAUT OBJ(QSYS/IEMLIB) OBJTYPE(*LIB) USER(QTMHHTTP) AUT(*USE)

Once this has been done, end and restart the IEVENTMON server instance and try the failing link again.


My test email is not going through - when I look in the joblog, I see "Command failed. reason -203 failed to connect remote server (connect(), 3425:A remote host refused an attempted connect operation.

This message normally indicates that a validation process back to your IBM i system is failing. The first place to look for this is the email help available at this location. If the PING command works and the address is reachable, then the problem may be caused by using a non-standard port number for SMTP on your IBM i system. The default port value of 25 is normally used and is the default value used by iEventMonitor.

You can check the port number being used on your system with the following command:

WRKSRVTBLE SERVICE('smtp')

If you need to change the default port number for iEventMonitor on your system, it is stored as a hexadecimal value in positions 796-800 of the data area named IEMCONTROL in library IEMLIB. The default value for port 25 is shipped with iEventMonitor stored as X'0000000019'. If you need to change this value, determine the correct hexadecimal value to use and change the value using a CHGDTAARA command such as this:

CHGDTAARA DTAARA(IEMLIB/IEMCONTROL (796 5)) VALUE(X'0000000019')

If you change the default port value, you should end and restart the SMTP server.


My test email is not going through - when I look in the joblog, I see "Command failed. reason -301 negative response from SMTP server .... Relaying blocked at this site.

This message indicates that the SMTP server on your system is set to disallow email relays. For iEventMonitor's email to work, this will have to be changed. The setting is conrolled by the ALWRLY parameter (Allow relayed mail) on the Change SMTP Attributes (CHGSMTPA) command. Prompt this command using the F4 key and roll up until you see this parameter.

(Note: Your user profile must have special authority *IOSYSCFG to use the CHGSMTPA command. We recommend that you make changes to this command from a profile that is a security officer.)

When you first check this setting, you will probably find the ALWRLY set to *NONE. This will stop all iEventMonitor email from being sent. Changing this value to *ALL will allow email to be sent, but it is not the best solution to enabling email. The preferred solution is to change this value to *LIST. This will restrict email relays to only those IP addresses that you specifically authorize.

Once you have relaying configured and have specified the *LIST setting, you will then have to update the SMTP list to indicate who can relay mail. This is done using the ADDSMTPLE (Add SMTP List Entry) command. There are a lot of options for this, but as a simple example let’s set up an entry that will permit mail to be relayed from your IBM i (iSeries, AS/400). If your system has an IP address of 10.100.2.1, then you would add a relay accept transaction that looks like the following:

ADDSMTPLE TYPE(*ACCEPT) INTNETADR('10.100.2.1')
SUBNETMASK('255.255.255.255')

This entry will accept all SMTP mail that is sourced from the specific IP address indicated in the INTNETADR parameter. The subnet mask used here is coded so that only the specific IP address will be processed. You can also use this command to post a *REJECT entry to the SMTP list to indicate specific IP addresses to be rejected. Varying the subnet mask can let you define ranges of IP addresses and if you need help on how to code these entries, feel free to contact us (support@kisco.com). Once entries have been added to the SMTP list, if you decide you don't want to use the software, you can delete them using the RMVSMTPLE (Remove SMTP List Entry) command. It would be nice if IBM provided a WRKSMTPLE command, but the test system I work on has no sign of this feature.

After you get these changes made, you should end and then restart your SMTP server before testing for the results. Ending the SMTP server is done with the following command:

ENDTCPSVR SERVER(*SMTP)

and restarting it is done with the following:

STRTCPSVR SERVER(*SMTP)

iEventMonitor Release 8 Problem Reports:

8.04: various maintenance updates

1. A problem with an obscure setting when done from the Bluescape browser interface has been corrected.
2. Edits from the green screen setting update have been improved.
3. The new version swapper has been tightened up.
4. For certain audit alerts, characters that could not be rendered for the green screen interface could cause the log display to fail. This has been corrected.
5. The system name has been added to the log display.
6. The ENDIEM process has been extended to make sure that all tasks running have been ended.
7. A typo on one of the green screen menus has been fixed.
8. The WRKIEM process has been updated for consistent field naming for the Notification Address.

The fix for these issues is available as a PTF. This PTF can only be installed on iEventMonitor Release 8.03. The correction is available in PTF package IEPTF804. E-mail support@kisco.com to request the PTF package.


iEventMonitor Release 7 Problem Reports:

7.06: three updates

1 - When IEM was left running for a long period of time on a system with a lot of alerts being issued, it could fail because a limit on profile swaps was reached. This has been corrected.

2 - The size of the joblog on some tasks has been reduced to improve performance.

3 - A new parameter was added to the command that sends diagnostic information to Kisco for support purposes.

The fix for these issues is available as a PTF. This PTF can only be installed on iEventMonitor Release 7.05. The correction is available in PTF package IEPTF706. E-mail support@kisco.com to request the PTF package.


Issue with duplicate message queue alert suppression

In some cases, the duplicate message queue alert feature would not work when it has clearly been activated. This could happen when the customer was specifying SNDSMTPEMM email delivery protocol.

The fix for these issues is available as a PTF. This PTF can only be installed on iEventMonitor Release 7.00. The correction is available in PTF package IEPTF701. E-mail support@kisco.com to request the PTF package.


iEventMonitor Release 6 Problem Reports:

Release 6.04

The Output Queue Watch feature could fail with the MCH1210 message if there were an unusually high number of spool files in the monitored output queue. This has been fixed.

The fix for these issues is available as a PTF. This PTF can only be installed on iEventMonitor Release 6.03. The correction is available in PTF package IEPTF604. E-mail support@kisco.com to request the PTF package.


Release 6.03

The message queue monitor reminder option was issuing reminder alerts for messages that were already answered under certain unusual situations. This has been addressed.

The WRKIEM process (option #1 on the MASTER menu) has been updated to perform a software license validation each time it is used. This will advise customers with the software on trial when the trial period has expired.

The fix for these issues is available as a PTF. This PTF can only be installed on iEventMonitor Release 6.02. The correction is available in PTF package IEPTF603. E-mail support@kisco.com to request the PTF package.


Release 6.02

On some systems, the Audit Monitor could experience a problem with a data queue read. That read has been changed to check for an error and deal with it without interrupting the process.

The Network Watch has been corrected to prevent looping when a total loss of network connection is experienced.

The fix for these issues is available as a PTF. This PTF can only be installed on iEventMonitor Release 6.01. The correction is available in PTF package IEPTF602. E-mail support@kisco.com to request the PTF package.


Release 6.01

corrects a problem with a CPF1015 that could happen on a message queue monitor when the reminder option was specified

The fix for these issues is available as a PTF. This PTF can only be installed on iEventMonitor Release 6.00. The correction is available in PTF package IEPTF601. E-mail us and request the PTF package.


iEventMonitor Release 5 Problem Reports:

Two fixes - see details.

Customers reported the following two issues with iEventMonitor:

  • A customer reported that when viewing system status using the WRKIEM command (option 1 on the MASTER menu), a Job Watch shows as "Inactive" but when they try to start the watch, they get an error reporting that the watch is already active and cannot be started. We have now fixed the WRKIEM process to correctly show the active/inactive status.
  • A customer reported that under a rare condition, a mutex-wait watch was halting with a lock-wait condition. This was happening when simultaneous mutex-wait conditions occurred at the same time for jobs running under the same job name. We traced the problem to an issue in iEventMonitor and it has now been corrected.

The fix for these issues is available as a PTF. This PTF can only be installed on a Release 5.24 version of iEventMonitor. The correction is available in PTF package IEPTF523. E-mail us and request the PTF package.


I am having problems stopping and starting some Job Watches.

A customer reported this problem when they were running multiple Job Watches for the same Job Name but different user profiles. We were able to identify the problem and correct it.

The fix for these issues is available as a PTF. This PTF can only be installed on a Release 5.23 version of iEventMonitor. The correction is available in PTF package IEPTF522. E-mail us and request the PTF package.


See details for several fixes.

Several customer have reported different issues which have now been fixed. These include:

  1. A description for the CN task was missing on the Work With Tasks display (MASTER menu option #1).
  2. A problem was found that could, under very unusual conditions, cause an alert to be bypassed.

These issues have all be corrected.

The fix for these issues is available as a PTF. This PTF can only be installed on a Release 5.18 version of iEventMonitor. The correction is available in PTF package IEPTF519. E-mail us and request the PTF package.


See details for several fixes.

Several customer have reported different issues which have now been fixed. These include:

  1. A divide by zero error could happen when running an APS % Watch on an iASP when it is disconnected from the system. This has been corrected.
  2. The WRKIEM process (option #1 on the MASTER menu) was allowing for the user profile to be changed on a Job Watch. This has been fixed and the user profile can no longer be changed. If you need to change the user profile, delete the Job Watch and re-add it with the correct user profile.
  3. The Lock-Wait watch was not working correctly when run with a reminder interval set to zero. A constant stream of alerts could get issued. This has been fixed.

These issues have all be corrected.

The fix for these issues is available as a PTF. This PTF can only be installed on a Release 5.16 version of iEventMonitor. The correction is available in PTF package IEPTF517. E-mail us and request the PTF package.


See details for several fixes.

Several customer have reported different issues which have now been fixed. These include:

  1. Option 1 on the MASTER menu allowed you to delete a task while it was active. You now need to end a task before it can be deleted.
  2. One customer reported seeing a CPA0702 error for the message queue monitor. The cause of this has now been identified and corrected.
  3. If a message queue monitor was left active during a system save that included the IEMLIB library, the message queue monitor could fail with a CPF0001/CPA0702 error. This has now been fixed.

These issues have all be corrected.

The fix for these issues is available as a PTF. This PTF can only be installed on a Release 5.14 version of iEventMonitor. The correction is available in PTF package IEPTF515. E-mail us and request the PTF package.


When I start a message queue monitor, it does not appear to be working.

iEventMonitor now uses the IBM i OS Watch exit program feature to monitor message queues. For this to work, the QUSRWRK subsystem needs to be up and running. On some systems, this is normally not started. We have changed the monitor startup process to make sure that the QUSRWRK subsystem has been started with the watch exit program prestart jobs also started.

The fix for this issue is available as a PTF. This PTF can only be installed on a Release 5.13 version of iEventMonitor. The correction is available in PTF package IEPTF514. E-mail us and request the PTF package.


See details for several fixes.

Several customer have reported different issues which have now been fixed. These include:

  1. When starting iEventMonitor, an error was issued because of a missing data queue named IEMONMQ.
  2. The AUDIT monitors can leave a large work file active in the QTEMP library using up disk space.
  3. The new message queue monitor introduced in release 5.12 is generating a lot of T-JS security audit journal records.

These issues have all be corrected or had work arounds added to the product.

The fix for these issues is available as a PTF. This PTF can only be installed on a Release 5.12 version of iEventMonitor. The correction is available in PTF package IEPTF513. E-mail us and request the PTF package.


We are missing an occasional message queue monitor alert.

Under certain conditions, especially when message queue entries have been manually removed from the message queue, we found that the IBM i OS API's for direct reading of the message queue had poor recovery abilities. To correct for this issue, we have re-engineered the Message Queue Monitor feature to avoid this from happening. The feature now uses a completely different method for monitoring message queues.

The fix for this problem is available as a PTF. This PTF can only be installed on a Release 5.11 version of iEventMonitor. The correction is available in PTF package IEPTF512. E-mail us and request the PTF package.


Our monitor stopped working with an error message about a file named IEMLOGF.

We found that a size restriction setting for the activity log file named could result in an error on systems with a lot of activity and where the file had not been purged to remove older records. We have now removed the size restriction on this file to avoid problems.

The fix for this problem is available as a PTF. This PTF can only be installed on a Release 5.09 version of iEventMonitor. The correction is available in PTF package IEPTF510. E-mail us and request the PTF package.


Several fixes - see details.

Several customer have reported different issues which have now been fixed. These include:

  1. A User Watch could end during a system backup operation. This has been fixed.
  2. A customer reported that some alerts could still get bypassed on the Message Queue Monitor function.
  3. The File Monitor function has been re-engineered to improve system performance for the trigger program that does the tracking.

The fix for these problems is available as a PTF. This PTF can only be installed on a Release 5.02 version of iEventMonitor. The correction is available in PTF package IEPTF508. E-mail us and request the PTF package.


Option #6 on the AUDIT menu fails.

If the iEventMonitor library named IEMLIB is not in the session library list, this option will not work correctly. This has now been corrected and a PTF update is available.

The fix for these problems is available as a PTF. This PTF can only be installed on a Release 5.06 version of iEventMonitor. The correction is available in PTF package IEPTF507. E-mail us and request the PTF package.


The ASP Watch only lets me specify up to ASP number 99.

A customer reported that they needed to watch an ASP with a three digit number. The IBM i OS supports using up to a maximum value of 255, so iEventMonitor has now been updated to support this full range of ASP numbers.

The fix for these problems is available as a PTF. This PTF can only be installed on a Release 5.05 version of iEventMonitor. The correction is available in PTF package IEPTF506. E-mail us and request the PTF package.


Several more fixes - see details.

Several customer have reported different issues which have now been fixed. These include:

  1. Some messages arriving at a message queue were generating alerts in iEventMonitor. This has now been corrected.
  2. The user profile watch was not always honoring the shift times and days as posted in the IEMSET command. This has been corrected.
  3. Under unusual conditions, the IEM Respond process that generates a joblog of the job with the error message could fail when the message is manually responded to before the joblog processing completes. This has now been fixed.
  4. The message date and time has now been added to the detail display for the history log.

The fix for these problems is available as a PTF. This PTF can only be installed on a Release 5.02 version of iEventMonitor. The correction is available in PTF package IEPTF504. E-mail us and request the PTF package.


Several fixes - see details.

Several customer have reported different issues which have now been fixed. These include:

  1. A problem with the new Test Error Message function was fixed. It was failing when the IEMLIB library was not in the session library list.
  2. A fix was made to the message queue monitor function. It was calling the IEM Respond setup process when a message did not call for a response.
  3. One customer reported an MCH3601 error from program UTIL21. This has been identified and corrected.
  4. Some customers reported that option #1 on the MASTER menu was showing that the ASP Watch was inactive when it was actually running.
  5. One customer reported that a file named WEBPRINT was not allocated with enough records for a specific situation they encountered. The file has now been enlarged.
  6. The Reminder Option was causing errors when a value larger than 99 was entered.

The fix for these problems is available as a PTF. This PTF can only be installed on a Release 5.02 version of iEventMonitor. The correction is available in PTF package IEPTF503. E-mail us and request the PTF package.


We are seeing multiple SV Audit Alerts for time adjustments.

Some systems are configured for automatic time adjustment. These changes are reported as System Value changes and can happen regularly. We have now updated the SV Audit Watch to ignore all time adjustment changes and stop issuing these as alerts.

The fix for this problem is available as a PTF. This PTF can only be installed on a Release 5.01 version of iEventMonitor. The correction is available in PTF package IEPTF502. E-mail us and request the PTF package.