DX Unified Infrastructure Management

I would like to know if it's possible to answer a inquiry message on qsysopr (iSeries/IBM i), using the assign function on the message in Nimbus and UMP? Or any other way accept using assign? We would like to have this function without having to open a 5250-console, or open the fetchmsg-probe to find the message and give an answer from there.

The problem I see using the assign, is that a inquiry message could have several different letters to use in a reply (e.g C I R G D), and numbers (1-99999). Which means that you can't have an assign profile for each reply...

here are the fetchmsg-probe parameters for the send_reply:

If I use the assign option (with only the letter-options, of course.). And for this example I need to answer C (cancel). Should I create a profile named, let's say "C", and then use the Trigger in NAS, with the option "Message assigned to" = C? Then create a script which captures the alarm that was trigged, with a callback to the fetchmsg probe to give the answer?

Does the alarm.get() work here?

if trigger.state ("CANCEL") then alarm.get()  local addr = '/'..a.domain..'/'..a.hub..'/'..a.robot..'/'  probe ="fetchmsg" cmd = "answer"  local args = pds.create() pds.putString(args, "answer", "C")  output,rc = nimbus.request(addr..probe, cmd, args)
end

 I'm a real beginner so please correct this script if it's wrong

I am really unclear on the mechanics of what you really need to do here, but I think your cmd variable should be set to "send_reply". Then your args variable might need to have the "key" and "queue" parameters set in addition to "answer".

It seems like you might intend to use the trigger to determine something about what is in the alarm. If that is the case, it might be better to parse the alarm message rather than relying on the trigger. But the trigger might make sense if you using it to determine something external to the alarm.

True, I need to have the "send_reply" for the cmd.

I've created an alarm now from the machine which I can answer with a G (= go), the nimid is: "BA78886570-42036"

I'm not sure what the "key" should be? But I think it is the $key I use in the suppression for the inquiry message. So for this nimid/message the $key is: "0000c7e0"

The queue is: "QSYSOPR" 

If I only try to give an answer from a script, but it doesnt work.
What should it look like?

alarm.get("BA78886570-42036")

local addr = '/'..a.domain..'/'..a.hub..'/'..a.robot..'/'
probe ="fetchmsg"
cmd = "send_reply"

local args = pds.create()
pds.putString(args, ******...)

output,rc = nimbus.request(addr..probe, cmd, args)

Got it... this script works to answer with "G"..... if I put in the nimid in alarm.get(). 

a=alarm.get()

j={}
j=split (a.supp_key,"/")

local addr = '/'..a.domain..'/'..a.hub..'/'..a.robot..'/'

probe = "fetchmsg"
cmd = "send_reply"

local args = pds.create()
-- KEY
pds.putString(args, "key", j[2])
-- ANSWER
pds.putString(args, "answer", "G")
-- QUEUE
pds.putString(args, "queue", "QSYSOPR")

output,rc = nimbus.request(addr..probe, cmd, args)

But....

I created a profile named "GO".

Created a AO script-profile, with action mode: "On trigger". And added the trigger which will run if I assign anything to "GO".

Now,... when I try to assign the message, it doesn't answer! The problem seems to be that the script won't work when I use alarm.get() The script doesn't know what message the trigger is coming from??

What do I need here? Is there something I can use in the "Script parameter"? Can't find anything useful in the docs about this :/

If you want the script to run for every matching alarm, I think you should not be suing the "on trigger" action mode. With that mode, you might not get the profile to run as often as you need it to. In addition, the alarm.get() function (without an argument) probably cannot work with an "on trigger" AO profile. The alarm.get() function should return a table containing the alarm that caused the AO profile to run, but in the case an "on trigger" AO profile, it is the trigger that causes the profile to run, not an individual alarm.

I believe that you are likely to get the behavior you need by switching the AO profile to a different action mode.