IBM Mainframe Forum

Condescending? You mean you've done lots of stuff, which you haven't bothered to tell us about, so we can waste time looking at your problem and you just sit back and say, "nope, dunnit, nope, dunnit"?

I'm no sysprog. I poked the thing in google, came up with four or five interesting things to look through on first two pages, but thinking that you, as the sysprog, would make more initial sense of them than I, I suggested it.

Next time, and every time thereafter, tell us what you've done, tell us what you've tried, tell us what the results were, answer all questions before they are asked, and any that you miss, which you've already tried, have the grace to apologise for for the wasted time.

Now, fully explain what is happening, whether it is happening in more than one "place", all that you have tried, all the results and outputs you received, whether it was working at some point and what has changed since that point. Answer everyone's questions.

I haven't done lots of stuff. I've mentioned in the first post that I've looked at MPFLSTxx. Googling and searching within the forum would be the first thing anyone does before posting. My intention isn't to waste anyone's time, which I know you're spending out of interest rather than a need to. So, I apologize. I only said what I said because every time I make a post here, it ends up starting out the way it has now. And I don't even know what I'm missing (in my posts here) that upsets you (collectively).

I'm looking to implement CMEM functionality (dataset-based event trigger) using Control-O. So the "rule" starts this way -
ON DSNEVENT = (dsn)
DO xxx

Few of the prerequisites for this to work are -
Installation of a JES2 exit (related to Control-O)
Presence of IEF403I and an other SMS-related msgid that Control-O relies on

Both of these are present. There weren't any changes to the system recently. I have only recently noticed that the msgid doesn't show up every time a job is submitted. It's not happening in more than one "place" (I'm considering an LPAR). I'm not bothered about the console output. I'm just looking at the syslog. I'll post again tomorrow with the output jaggz asked for.

Hello,

Do you have anyother means of viewing LOG like OPSLOG ? Did you raise an issue with BMC ?

Yes, I can have a look at the "automation log". But I'm pretty sure this is not a CTO problem. It needs the msgid in the syslog to work. So before I see the msgid in the syslog, there's no way I can blame this on CTO.

Suppression isn't in place.

pretty strong statement, isn' t it ?

how would define the disappearance of something that is usually there ?

Can you help prove me wrong? I might be.
I'm saying it isn't because it's not completely blocked out. Few jobs do produce the msgid.

I do not care, there is no need to prove anything, if a message that usually is there disappears there is a reason, meditate, please, meditate

did it occur to You that the message might be trapped by <somebody>, processed and discarded
speak to a system programmer who knows more about Your environment to find out ALL the customization made

By proving me wrong, I mean to ask for places where I may have gone wrong so that I can check again.

It did occur. This test environment is no different from any of the other 12 LPARs that we have in regard to processing this msgid.

since we do not belong to Your organization we do not know what products are installed and what customization have been done.
discussing why a message as You say disappears, is just pure speculation, You know Your system ( or at least You should )
ask Your support for the checklist used when installing products and You will find what <modification> have been done to the base system

also it would be worth for You to read and meditate on the basics of system installation...
with particular regard to the MPF ( in wide sense ) exits , see for example
http://publib.boulder.ibm.com/infocente ... /vmxit.htm

but You are too busy bragging about 12 lpars , to have time to read the manuals ???

This test environment is no different from any of the other 12 LPARs that we have in regard to processing this msgid.

hard to believe and contrary to any good sense and logic, if it behaves different, then something is different! RIP whether You like it or not ...

19 posts and I didn't get one additional clue. You are not the only ones who can Google or read a book. I get it that you're annoyed at newbies. There's no need to be insulting. You think I haven't talked to my team about this?

It's not my mainframe and I don't have anything to brag about. You chose to see, what I mentioned as a fact, as bragging. I can only blame myself for coming here expecting an answer.
I'd rather search the manuals than get my message across to you, which you seem to be completely ignoring. Jesus..