MLWTO getting RC=84

[Kyle_S]

I have MLWTOs & SLWTOs that I need to interrogate and then depending upon the msg content, highlight & hold or just let them pass through (MLWTOs will be re-issued).  I do some other things, too, but that is working.

SLWTOs can just have the MSG.* variables updated and 'return' to effect the desired changes, if any.

The MLWTOs, of course need to be re-issued with updated characteristics--mostly descriptor code(s).

So I started with CCLXRULS(DSNL027I).  The only thing I added to the MLWTO is the 'DESC(descriptor code)'  I never tried the unaltered DSNL027I.  When I try to execute the new rule in the test facility (captured messages from OPSLOG), the MLWTO always gets RC=84.  From the manual: '84
A command buffer parse error occurred.'

Not very helpful.  I have looked and looked again for syntax and other similar errors to no avail.  We are on 13.5 so no help is available from support as it is EOS.  Currently we are unable to upgrade OPS/MVS and there would not be enough time for the requirements.

I would really appreciate any ideas or help on this.

from a trace in the test facility:

OPS0997T >O>     Msgid(MQ@RCON) Textvar(getvar.)  Token(XAOF) Desc(11) Route(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,
OPS0997T +++      RC(84)                                                                                                  

source from the rule:

depending upon msg content either:

desccode = '6' 

or

desscode='11'

routecde= OPSBN(msg.route)

address WTO                                         
  "Msgid("msg.id") Textvar(getvar.) ",              
  "Token(XAOF) Desc("desccode") Route("routecde") " 

The stem variable getvar. actually has the lines from the MLWTO in it--I just before this.

Thanks,

Kyle

[Dave Gorisek]

My guess is that the lengthy msg.route variable substitution is causing the length of the command passed to WTO to be 'too long' or longer than allowed. As a test, simply set your routecde variable to just one routecode ( routecde=2)  and see if that gets you around your error. If it does, 'and' you really need to reissue the MLWTO with the exact route codes (not sure you really need 'all' routecodes), then you'll have to reach out to OPS/MVS support team. If it fails with short route code, you should still reach out to the OPS/MVS support team, but include the complete raw rule text as well as the triggerring message from the OPSLOG fwhen you open up an issue.

[Dave Gorisek]

...you can also do a pull/say from the EDQ after the RC=84 to see exactly what the command parser is complaining about.....

[Kyle_S]

Dave,

Please add my reply to you in this thread. I mistakenly sent it only to you.  Thanks.

With your diagnostic tips, I was able to find the problem with MLWTO line 1 too long.  The message text has the msgid in it and I also specified msgid on the WTO (just like the sample.)  So I removed the msgid  from the getvar.1 variable and left the msgid parameter on the WTO.  This worked great!  Thank you so much Dave.  You saved me much frustration and helped me finish the work successfully.

Kyle

[Dave Gorisek]

Glad that the pull/say of the non RC=0 host env error revealed more information, specifically with the length of the 'new' primary line (including msg.id) being too long. One additional item I wanted to point out is that the sample rule you used as a 'template' (DSNL027I) was written before the MLWTO keyword on the )MSG specifier was available. Meaning, if you are interrogating a true MLWTO, and want to create a 'new' message using certain data on specific data lines, then a )MSG msgid MLWTO event specifier will greatly improve and simplify the logic of your rule. Not that DSNL027I logic can still be used (store off all data lines, then interrogate upon the end line), but if you stick to using the most efficient tools available, you'll end up with a piece of code that is more effective and als appealing to the eyes! Ideally, OPS/MVS support should rewrite this sample to use this best technique. There are various samples that demonstrate using the MLWTO option/keyword on the specifier such as DSNP002I.

[Kyle_S]

Thank you.  I use the rule to do both MLWTOs and single-line WTOs since they can send me both.  So I combined the processing into one rule.  It is not really complicated.  Also, the portion I interrogate and process differently against is in the first line of the MLWTO.

I am sure I will have more opportunities to use the MLWTO parameter on )MSG spec line for other projects too.  Your advice seems sound.

Thanks again,

Kyle

[Kyle_S]

When I run the rule in the test facility against messages from OPSLOG that should have been set to desc(11) the process sets desc(11) and holds/highlights  (red) in the test facility.  However, the very message I extracted from OPSLOG & tested, that should have been highlighted / held (red) in OPSLOG had desc(0).  I used MSG.DESC=OPSBITS(11) to set this on for the actual instance of a single-line WTO that the rule is processing, then I do return 'NORMAL' to let the change take affect.  Any thoughts here?

Thanks,

Kyle

[Kyle_S]

I looked in SDSF SYSLOG and the messages that show not highlighted/held in OPSLOG are showing highlighted/held in SDSF's SYSLOG.  Seems like a bug in OPSLOG or?  I will have to wait until I can schedule to upgrade OPS/MVS from 13.5 to 14 to see how a supported version fairs in this situation.  I am still curious if anyone knows if there is a bug or something, but non-essential.

Dave, thanks so much for your support and insights.

Kyle

[Dave Gorisek]

By default the OPSLOG will always show the original message attributes (routes,desc), so you will not see the 'new' desc/route codes. If you 'need' to physically see the final rule 'result', you can set the OPS parm RULETRACE to ON. This will now cause OPSLOG to log the original and a duplicate message but showing the changed routes,desc. After you 'see' the result (again if needed), be sure to set the parm back to off as depening on the logic of all your other rules, your OPSLOG could have a lot of redundant message traffic. 

[Marcel van Ek]

One 'trick' we use is to whenever we change the route/desc code, we also save the new value(s)  into the msg.user field. That way you'll see it in opslog. (though it is limited to  8 char)

You'll need to come up with some naming/usage convention in your shop to allow for consistency, but you'll have 'proof' in your live opslog (as where ruletrace is only useful for debugging)

------------------------------
Automated Operations
Atos
Netherlands
------------------------------

[Kyle_S]

Thank you, Marcel.  That is a clever idea.

[Kyle_S]

Thanks Dave.  That is good to know.

[Kyle_S]

Thanks Dave.  That is good to know.