[paul sorya]

Hi Gary,

When a shell environment variable is used in “exec” of alert configuration. Each time the monitor deamon is cycled, you will always see this frictional error message: “XXXX: no such variable”.  

As you mentionned, despite this faultly message in monitord.log, you receive anyway an email when the alert fires.

(after the alert is fired, look either in hcimonitord.log or monitord.err. I prefer hcimonitord.err)

Unless you place your alert_mail script in the search paths, you cannot remove $HCISITEDIR/cscripts from “exec”.

You cannot neither replace it with $HciSiteDir because environment variables are case sensitive.

To find out your installation search path, run “env” from command line and look for “PATH”.

What I did, is using /home/hci/bin to keep my scripts, since it is in my search path. (you may need to create subdirectory bin under /home/hci).

I keep only one copy of my shell script for all sites.

I use also ksh script in exec option of my alert set-up and I have no problem with any environment variables.

To prove this simply place “env > enviro.txt” in your script and, when the alert fires, look at the output enviro.txt in $HCISITEDIR/exec/hcimonitord/.

(where $HCISITEDIR is the site path in which the alert is just fired). Later, do not forget to remove “env > enviro.txt” from your script.

Hope this helps.

Thanks!

Paul Sorya

Systems Analyst

MD Center of Univerty of Montreal

Canada

[paul sorya]

Hi All,

Finally I found the solution to my problem. Here is the summary of my solution:

1) The column that exceeds 4000 bytes must be converted to CLOB data type.

2) First, I insert  the raw to the table with the CLOB fields umpty using orapase/orabind/oraexec commands.

2) Then, I update the CLOB columns with oralob-alloc and oralob-write  commands.

Thanks,

Paul Sorya.

[paul sorya]

Hi,

From the Web, I leaned that “oraconfig” command allows me to increase the size of the buffer for binding variable values up to the maximum of 4000 bytes.

With the maximum of 4000 bytes, my problem is not completly resolved.

Does somebody have the solution to overcome the maximum of 4000 bytes for biding variable values?

Thanks!

Paul Sorya

Systems Analyst

MD Center of Universite of Montreal

Montreal, Quebec

Canada

[paul sorya]

Hi Rob,

It works superbly with SEND. In my case, SEND does exactly what I would like it to do, i.e. after the “set err [catch {..orabind…} errMsg]” returns an error, “SEND $mh” puts the message in the Recovery database and QDX keeps trying to process the same message over and over again until my orabind problem is fixed.

Thank You very much!

Paul Sorya

Systems Analyst

Medical Center of University of Montreal

Montreal, Quebec

Canada

[paul sorya]

Hi Thomas,

Actually my outbound thread is a dummy thread (protocol File /dev/null), in wich I place a tcl proc in “TPS outbound  data”. This tcl proc uses oratcl to file the message contents to the Oracle data base. When the filing to Oracle table is OK, I “CONTINUE” the message (to /dev/null).

Since my outbound Thread uses protocol File  and output the messages  to /dev/null. Therefore, when the filing (by oratcl) went wrong, I cannot “CONTINUE” the message because if I do so the message will be lost forever.

Any other suggestions will be deeply appreciated.

Thanks,

Paul Sorya

[Author]

Replies