The primary reason SLCs fail to work as planned (assuming they are enabled) is that the data in the events that are supposed to trigger them does not exactly match the criteria specified.
For example, you might specify a process name in the SLC of Xyzzy, but if the process name is actually XYZZY, it does not trigger the SLC. Why? The yzzy in the criteria is in lowercase while the actual name shows YZZY in uppercase, which does not match.
Or, you might specify a destination file name of c:\myfile.dat. But if the destination file name is actually C:\myfile.dat, it does not trigger the SLC. Why? The c: in the criteria is in lowercase, while the actual name shows C: in uppercase, which does not match.
There are times when you must either use a wildcard SLC or a workflow SLC, as opposed to a standard SLC, to accomplish your monitoring goals. One of those times is you when you are monitoring transfers to generation data groups (GDGs). When transferring files to GDGs, the destination file name is not known until the file is created.
For example, if your process is transferring a file to the data set XYZZY.GDG(+1), the SLC destination file name must be specified as XYZZY.GDG.* (assuming the Regular Expression check box is cleared).
To find out whether specifying faulty match criteria is the reason your SLC is not working properly, run a Database Events report. View the details of the events you expect to trigger your SLC. Specify event parameters that match the Process you feel were supposed to trigger your SLC but did not. Include the XML_STRING value at a minimum in the report output; then closely compare the match criteria specified in your SLC with the output generated.
The Test button on many SLC wizard panels is also helpful. Use it to try out your wildcard or regular expressions to see whether they match the values you expect the events that trigger your SLC to contain.