AW: Re: AW: Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Peter Hunkeler]

>
>The exit 6 that I modified from the version done by Glenn Harper at
>[snip]


Exit 6 is JES2 Exit 6, I assume, and this is run in a JES2 context, so it has 
access to JES2 "data", such as the JESYSMSG ACB. I doubt SMS has access to that 
information when writing IGD* message upon data set allocation and unallocation.




--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AW: Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Clark Morris]

[Default] On 27 Oct 2016 03:32:19 -0700, in bit.listserv.ibm-main
p...@gmx.ch (Peter Hunkeler) wrote:

>>It is route code 11. specify that on your WTO macro . 
>
>
>No, it s not. As I wrote, WTO with route code 11 goes to JESMSGLG and JESYSMSG 
>(and also to consoles which receive route code 11).
>
The exit 6 that I modified from the version done by Glenn Harper at
A.N.R production company about thirty years ago wrote to the message
set using the ACB for the message data set and an RPL.  See mod
NAPJ005 in the Philips Lighting mods File 175 on the CBTTAPE -
www.cbttape.org.  The code was either in the original code or the
modifications by Glenn Harper.  It was extremely helpful to stand on
the shoulders of those who knew more than I did.  If I recall
correctly this was the exit I picked up that was coded MVS/SP 1.3.4
and all of the labels for one or more of the JES macros had been
changed with new tags at the  1.3.5 or 1.3.6 level so the first time I
assembled it, I abended the assembler with too many error messages.  I
found the problem and changed it and also found the MNOTE limit in one
of the Macros and reported the problem to Level 1.  The details are
hazy but the availability of the exit plus some others enabled a
relatively smooth conversion from JES3 to JES2.  The major advantage
of my modifications was to allow the programmers to not have to worry
about jobclass because the exit set it for them based on resources
requested.

Clark Morris
>
>I'm wondering how to write to JESYSMGS *only*. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Peter Hunkeler]

> Isn't your finding what I wrote to you few emails ago...?




 I was asking how to write a message to JESYSMSG, only. You answered, a WTO 
with route code 11 will do that. At least this is how I understood. If this is 
what you are referring to, then no. WTO with route code 11 writes to JESYSMSG 
*and* JESMSGLG.



But I may have misunderstood your post. If so, give me another try, please.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AW: Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Elardus Engelbrecht]

Peter Hunkeler wrote:

>After reading about IEFACTRT in "Installation Exits" I conclude that IEFYScan 
>only be used by this exit. You need what is passed in R12 to IEFACTRT to be 
>able to address the parameter list for IEFYS. And again this text talks about 
>"...writing to the JOBLOG..." which for me is synonymous to JESMSGLG, not 
>JESYSMSG.

>Still the question is unanswered: How to write to JESYSMSG, only.


>@Elardus: I'd like to keep this a single thread. It helps if people later 
>search the archives. This is why I did not reply to your IEFYS spawn.

Ok. Agreed, thanks for your comments. If I see any replies on my question, I 
will comply to your request and answer in this thread while monitoring all 
threads.

The reason why I initially spawned a new thread was because my question was 
about the documentation statement about using IEFYS which is not looking 
'right' for me. 

This thread is getting interesting and I have reread everything to refresh my 
tired braincells... ;-)

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Itschak Mugzach]

Isn't your finding what I wrote to you few emails ago...?

ITschak

ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Thu, Oct 27, 2016 at 2:49 PM, Peter Hunkeler  wrote:

>
>
>
>
> >>It is route code 11. specify that on your WTO macro .
>
> >No, it s not. As I wrote, WTO with route code 11 goes to JESMSGLG and
> JESYSMSG (and also to consoles which receive route code 11).
>
>
> At last I found the following in the *authorized* assembler service
> reference:
> WTO
> ...
>
> A WTO message with ROUTCDE=11 is sent to the JES2 or JES3 system message
> data set (SYSMSG) unless LINKAGE=BRANCH is specified. In this case, the
> message is not sent. If you want the WTO to go to SYSMSG, use LINKAGE=SVC
> with ROUTCDE=11. Whether you issue LINKAGE=BRANCH or LINKAGE=SVC with
> ROUTCDE=11, the message appears in the JES2 or JES3 joblog.
>
>
>
>
> The information from the last sentence is not present in the *non-auth*
> reference. Note that this is not someting restricted to authorized users at
> all.
>
>
> --
> ßph
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Peter Hunkeler]

>From IEFACTRT we write to JESYSMSG with the IEFYS routine.



After reading about IEFACTRT in "Installation Exits" I conclude that IEFYScan 
only be used by this exit. You need what is passed in R12 to IEFACTRT to be 
able to address the parameter list for IEFYS. And again this text talks about 
"...writing to the JOBLOG..." which for me is synonymous to JESMSGLG, not 
JESYSMSG.


Still the question is unanswered: How to write to JESYSMSG, only.


@Elardus: I'd like to keep this a single thread. It helps if people later 
search the archives. This is why I did not reply to your IEFYS spawn.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Peter Hunkeler]

>From IEFACTRT we write to JESYSMSG with the IEFYS routine.




Are you sure the messages go to JESYSMSG (file 3) and not JESMSGLG (file 1)? I 
only seem to have ever seen messages from IEFACTRT, such as step statistics, 
appear in JESMSGLG. But me not having seen any in JESYSMSG does not mean there 
aren't.

--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Peter Hunkeler]

>>It is route code 11. specify that on your WTO macro .

>No, it s not. As I wrote, WTO with route code 11 goes to JESMSGLG and JESYSMSG 
>(and also to consoles which receive route code 11).


At last I found the following in the *authorized* assembler service reference:
WTO
...

A WTO message with ROUTCDE=11 is sent to the JES2 or JES3 system message data 
set (SYSMSG) unless LINKAGE=BRANCH is specified. In this case, the message is 
not sent. If you want the WTO to go to SYSMSG, use LINKAGE=SVC with ROUTCDE=11. 
Whether you issue LINKAGE=BRANCH or LINKAGE=SVC with ROUTCDE=11, the message 
appears in the JES2 or JES3 joblog.




The information from the last sentence is not present in the *non-auth* 
reference. Note that this is not someting restricted to authorized users at all.


--
ßph

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Peter Hunkeler]

>It is route code 11. specify that on your WTO macro .


No, it s not. As I wrote, WTO with route code 11 goes to JESMSGLG and JESYSMSG 
(and also to consoles which receive route code 11).


I'm wondering how to write to JESYSMGS *only*.


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Itschak Mugzach]

It is route code 11. specify that on your WTO macro .

ITschak


On Thu, Oct 27, 2016 at 10:28 AM, Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> From IEFACTRT we write to JESYSMSG with the IEFYS routine.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: 26 October, 2016 23:47
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How to write messages to JESYSMSG only? (was: Randomly
> disappearing IGD101I messages)
>
> I can help a bit with the first question but not the other two. We have an
> ancient and venerable JES2 EXIT 6 that writes messages to JESYSMSG only. It
> uses the IFGRPL macro (AMODGEN). I did not write this part of the code, but
> I could send you a sample if you'd like. It's based on PUT with the parm
> RPL.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: Friday, October 21, 2016 1:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):How to write messages to JESYSMSG only? (was: Randomly
> disappearing IGD101I messages)
>
> Triggered by the discussion about randomly disappearing IGD101I message, I
> did some RTFM and some testing to find out how to write a message only to
> JESYSMSG. I got contradicting information instead of an answer. So here it
> goes...
>
>
>
> It was may understanding from my experience that allocation messages, be
> it the SMS ones IDG10xI, or  the non-SMS IEF ones, are only ever
> written to JESYSMSG. Only for STC running under MSTR (and in BPXAS?) will
> the messages be prefixed with IEF196I and written to syslog/operlog.
>
>
>
> I knew there is the "WTP" service which is actually a WTO with route code
> 11, only. It is described as to be writing the message to the *JESYSMSG*
> data set. However from experience, and I verified today, a WTO with route
> code 11 writes the message to JESYSMSG *and* to the JESMSGLG data set. The
> doc is not complete here, it seems.
>
>
> So, while I thought the IDG10xI messages are written as WTO ROUTCDE=11, I
> now doubt, since they are not seen anywhere else than JESYSMSG (exception
> see IEF196I above).
>
>
>
> But, the MVS messages manual documents for all of the IGD10xI messages:
> Route Code 2, Descriptor Code 4. Route code 2 is for the consoles (and the
> syslog/operlog). Again, the doc seems to be incomplete and possibly in
> error, because the IGD10xI messages are not seen in syslog/operlog and not
> on consoles. Contradiction #1.
>
>
>
> Next surprise: By chance, I saw a few IGD103I and IGD104I messages in
> operlog, *not* prefixed by IEF196I! How comes?? I was looking at the STC
> that was the source of the WTO. To my astonishment, I found not only in the
> JESYSMGS but also in the JESMSGLG of the STC. So far, I had only seen
> IDG103I and IGD104 in the same places and format as the IDG101I.
> A WTO seen in all of those three places would have routing codes 11 plus
> (at least) one of the "console" routing codes. Again the MVS msg manuals
> say route code 2, only.
> Contradiction #2.
>
>
>
>
> Anyone to shed some light on this?
>
>
> Questions to answer:
>
> a) How does one write a message to JESYSMSG *only".
> b) What determines whether IDG10xI messages are written to JESYSMSG only,
> or to JESYSMSG, JESMSGLG *and* operlog?
> c) Are the IGD10xI messages really WTOs with route code 2 and descriptor
> code 4, only?
>
>
> --
> Peter Hunkeler
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart

Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Vernooij, Kees (ITOPT1) - KLM]

>From IEFACTRT we write to JESYSMSG with the IEFYS routine.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: 26 October, 2016 23:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to write messages to JESYSMSG only? (was: Randomly 
disappearing IGD101I messages)

I can help a bit with the first question but not the other two. We have an 
ancient and venerable JES2 EXIT 6 that writes messages to JESYSMSG only. It 
uses the IFGRPL macro (AMODGEN). I did not write this part of the code, but I 
could send you a sample if you'd like. It's based on PUT with the parm RPL. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Friday, October 21, 2016 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):How to write messages to JESYSMSG only? (was: Randomly 
disappearing IGD101I messages)

Triggered by the discussion about randomly disappearing IGD101I message, I did 
some RTFM and some testing to find out how to write a message only to JESYSMSG. 
I got contradicting information instead of an answer. So here it goes...



It was may understanding from my experience that allocation messages, be it the 
SMS ones IDG10xI, or  the non-SMS IEF ones, are only ever written to 
JESYSMSG. Only for STC running under MSTR (and in BPXAS?) will the messages be 
prefixed with IEF196I and written to syslog/operlog.



I knew there is the "WTP" service which is actually a WTO with route code 11, 
only. It is described as to be writing the message to the *JESYSMSG* data set. 
However from experience, and I verified today, a WTO with route code 11 writes 
the message to JESYSMSG *and* to the JESMSGLG data set. The doc is not complete 
here, it seems.


So, while I thought the IDG10xI messages are written as WTO ROUTCDE=11, I now 
doubt, since they are not seen anywhere else than JESYSMSG (exception see 
IEF196I above).



But, the MVS messages manual documents for all of the IGD10xI messages: Route 
Code 2, Descriptor Code 4. Route code 2 is for the consoles (and the 
syslog/operlog). Again, the doc seems to be incomplete and possibly in error, 
because the IGD10xI messages are not seen in syslog/operlog and not on 
consoles. Contradiction #1.



Next surprise: By chance, I saw a few IGD103I and IGD104I messages in operlog, 
*not* prefixed by IEF196I! How comes?? I was looking at the STC that was the 
source of the WTO. To my astonishment, I found not only in the JESYSMGS but 
also in the JESMSGLG of the STC. So far, I had only seen IDG103I and IGD104 in 
the same places and format as the IDG101I. 
A WTO seen in all of those three places would have routing codes 11 plus (at 
least) one of the "console" routing codes. Again the MVS msg manuals say route 
code 2, only.
Contradiction #2. 




Anyone to shed some light on this?


Questions to answer:

a) How does one write a message to JESYSMSG *only".
b) What determines whether IDG10xI messages are written to JESYSMSG only, or to 
JESYSMSG, JESMSGLG *and* operlog?
c) Are the IGD10xI messages really WTOs with route code 2 and descriptor code 
4, only?


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Jesse 1 Robinson]

I can help a bit with the first question but not the other two. We have an 
ancient and venerable JES2 EXIT 6 that writes messages to JESYSMSG only. It 
uses the IFGRPL macro (AMODGEN). I did not write this part of the code, but I 
could send you a sample if you'd like. It's based on PUT with the parm RPL. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Friday, October 21, 2016 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):How to write messages to JESYSMSG only? (was: Randomly 
disappearing IGD101I messages)

Triggered by the discussion about randomly disappearing IGD101I message, I did 
some RTFM and some testing to find out how to write a message only to JESYSMSG. 
I got contradicting information instead of an answer. So here it goes...



It was may understanding from my experience that allocation messages, be it the 
SMS ones IDG10xI, or  the non-SMS IEF ones, are only ever written to 
JESYSMSG. Only for STC running under MSTR (and in BPXAS?) will the messages be 
prefixed with IEF196I and written to syslog/operlog.



I knew there is the "WTP" service which is actually a WTO with route code 11, 
only. It is described as to be writing the message to the *JESYSMSG* data set. 
However from experience, and I verified today, a WTO with route code 11 writes 
the message to JESYSMSG *and* to the JESMSGLG data set. The doc is not complete 
here, it seems.


So, while I thought the IDG10xI messages are written as WTO ROUTCDE=11, I now 
doubt, since they are not seen anywhere else than JESYSMSG (exception see 
IEF196I above).



But, the MVS messages manual documents for all of the IGD10xI messages: Route 
Code 2, Descriptor Code 4. Route code 2 is for the consoles (and the 
syslog/operlog). Again, the doc seems to be incomplete and possibly in error, 
because the IGD10xI messages are not seen in syslog/operlog and not on 
consoles. Contradiction #1.



Next surprise: By chance, I saw a few IGD103I and IGD104I messages in operlog, 
*not* prefixed by IEF196I! How comes?? I was looking at the STC that was the 
source of the WTO. To my astonishment, I found not only in the JESYSMGS but 
also in the JESMSGLG of the STC. So far, I had only seen IDG103I and IGD104 in 
the same places and format as the IDG101I. 
A WTO seen in all of those three places would have routing codes 11 plus (at 
least) one of the "console" routing codes. Again the MVS msg manuals say route 
code 2, only.
Contradiction #2. 




Anyone to shed some light on this?


Questions to answer:

a) How does one write a message to JESYSMSG *only".
b) What determines whether IDG10xI messages are written to JESYSMSG only, or to 
JESYSMSG, JESMSGLG *and* operlog?
c) Are the IGD10xI messages really WTOs with route code 2 and descriptor code 
4, only?


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Randomly disappearing IGD101I messages.

[Peter Hunkeler]

>Lizette,
>You said you suppressed IGD1010I. Are you sure you got it in syslog without 
>suppressing it?
 >
>Kees.




I just posted the initial message for the new thread. Therein, I say that I 
have found a case of IGD103I and IGD104I in syslog (without the IEF196I 
prefix). So I'm pretty sure if that STC was to allocate a new data set, the 
associated IGD101I would also appear in syslog.


My conclusion: You can see IGD10xI messages in syslog for some (rare) cases, 
but not for the greater part. And this is *not* an effect of any message 
suppression mechanism.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

How to write messages to JESYSMSG only? (was: Randomly disappearing IGD101I messages)

[Peter Hunkeler]

Triggered by the discussion about randomly disappearing IGD101I message, I did 
some RTFM and some testing to find out how to write a message only to JESYSMSG. 
I got contradicting information instead of an answer. So here it goes...



It was may understanding from my experience that allocation messages, be it the 
SMS ones IDG10xI, or  the non-SMS IEF ones, are only ever written to 
JESYSMSG. Only for STC running under MSTR (and in BPXAS?) will the messages be 
prefixed with IEF196I and written to syslog/operlog.



I knew there is the "WTP" service which is actually a WTO with route code 11, 
only. It is described as to be writing the message to the *JESYSMSG* data set. 
However from experience, and I verified today, a WTO with route code 11 writes 
the message to JESYSMSG *and* to the JESMSGLG data set. The doc is not complete 
here, it seems.


So, while I thought the IDG10xI messages are written as WTO ROUTCDE=11, I now 
doubt, since they are not seen anywhere else than JESYSMSG (exception see 
IEF196I above).



But, the MVS messages manual documents for all of the IGD10xI messages: Route 
Code 2, Descriptor Code 4. Route code 2 is for the consoles (and the 
syslog/operlog). Again, the doc seems to be incomplete and possibly in error, 
because the IGD10xI messages are not seen in syslog/operlog and not on 
consoles. Contradiction #1.



Next surprise: By chance, I saw a few IGD103I and IGD104I messages in operlog, 
*not* prefixed by IEF196I! How comes?? I was looking at the STC that was the 
source of the WTO. To my astonishment, I found not only in the JESYSMGS but 
also in the JESMSGLG of the STC. So far, I had only seen IDG103I and IGD104 in 
the same places and format as the IDG101I.
A WTO seen in all of those three places would have routing codes 11 plus (at 
least) one of the "console" routing codes. Again the MVS msg manuals say route 
code 2, only.
Contradiction #2.




Anyone to shed some light on this?


Questions to answer:

a) How does one write a message to JESYSMSG *only".
b) What determines whether IDG10xI messages are written to JESYSMSG only, or to 
JESYSMSG, JESMSGLG *and* operlog?
c) Are the IGD10xI messages really WTOs with route code 2 and descriptor code 
4, only?


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Peter Hunkeler]

>A message is produced or not based on MPF list, Automation Tools, or a user 
>exit.  The Vendors (IBM and BMC) should be able to help you determine why this 
>is going on.



I do not know about automation's posibilities, but MPF does *not* suppress 
messages from the syslog/operlog. The SUP=YES flag in MPF tells MVS not to 
display the message on *consoles*, only.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Good idea. I started a thread about this a few years ago, but it did not result 
in an answer.
We suspect there are bits in the WTO parmlist that keep it way from syslog. We 
thought about taking a dump in IEAVMXIT, if this is able to trap IGD101I, and 
see what is in the control blocks.

Lizette,
You said you suppressed IGD1010I. Are you sure you got it in syslog without 
suppressing it?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Friday, October 21, 2016 9:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

>They are among the messages that (seem to) never appear in SYSLOG/OPERLOG, 
>only in the job's Allocation messages file. IGD101I is not trappable via SLIP 
>or MPFLST. They seem to be (like the IGD messages produces by the ACS routines 
>WRITE statements) directly written to the job sysout.  


>How is this achieved? 


I though I have an idea, but then I detected some contradicting facts. I'll 
start a new thread to try to get some more information about this.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Peter Hunkeler]

>They are among the messages that (seem to) never appear in SYSLOG/OPERLOG, 
>only in the job's Allocation messages file. IGD101I is not trappable via SLIP 
>or MPFLST. They seem to be (like the IGD messages produces by the ACS routines 
>WRITE statements) directly written to the job sysout.


>How is this achieved?


I though I have an idea, but then I detected some contradicting facts. I'll 
start a new thread to try to get some more information about this.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[J R]

Sorry, I didn't properly articulate what I meant to convey.

I was trying to point out that the term "allocation" is used in more than one 
context, ie. in the case of datasets, (1) assigning datasets to DD names, and, 
specifically in the case of datasets on DASD, (2) their creation and placement 
on disk.

JCL's MSGLEVEL and DYNALLOC's S99MSGL0 both affect what messages are issued at 
that level.

The latter, (2), is performed at the base level by DADSM.  I don't know what 
the relationship is between DADSM, SMS, etc., but messages may well be issued 
at this level.

===




From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Peter Hunkeler <p...@gmx.ch>
Sent: Thursday, October 20, 2016 4:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: Randomly disappearing IGD101I messages.


>Dynalloc's S99MSGL0 is the equivalent of JCL's MSGLEVEL=0, ie. the allocation 
>of datasets to ddnames.



Not equivalent, I would say. MSGLEVEL is for the whole job, S99MSGL0 is for a 
single allocation.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Edward Gould]

Peter:
I haven’t worked with DMS lately. Having said that I vaguely remember DMS doing 
its own thing with DASD (i.e. creating a F4 DSCB and deb etc etc etc).

Ed

> On Oct 20, 2016, at 3:12 PM, Peter Hunkeler  wrote:
> 
> 
> 
> 
>> That might be a good point: different flows through the program that set 
>> different S99MSGLO flags.
> 
> 
> 
>  and it has nothing to do with "bypassing SMS".
> 
> 
> All new allocations are seen by SMS's ACS routines. If they decide to assign 
> a Storage Class to the data set, then the data set is "SMS managed"; if not 
> then not.
> 
> 
> Does anyonw know it it is possible to "bypass the ACS routines" for new 
> alloctions?
> 
> 
> --
> Peter Hunkeler
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Greg Shirey]

Peter,  

All new allocations are not necessarily seen by ACS routines.  It depends on 
your authority.  

>From DFSMSdss Storage Administration Reference: 

http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/dgt3u2150.htm

BYPASSACS specifies that Automatic Class Selection (ACS) routines are not to be 
invoked to determine the target data set's storage class or management class 
names. To specify BYPASSACS, RACF(r) authorization might be required.

I posted an example earlier in this thread. 

Regards,
Greg Shirey
Ben E. Keith Company

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Thursday, October 20, 2016 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: Randomly disappearing IGD101I messages.


All new allocations are seen by SMS's ACS routines. If they decide to assign a 
Storage Class to the data set, then the data set is "SMS managed"; if not then 
not.

Does anyonw know it it is possible to "bypass the ACS routines" for new 
alloctions? 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Greg Shirey]

Kees,

Yes, running the same job, but removing the BYPASSACS parm results in the 
SMS-managed data set being created, but there is still no IGD101I message.
That's interesting.  

Greg 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Thursday, October 20, 2016 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Greg,

If you request to bypass SMS, no IGD101I can be expected. Can you create an 
example where things are left to SMS when possible?

Kees.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Randomly disappearing IGD101I messages.

[Peter Hunkeler]

>Dynalloc's S99MSGL0 is the equivalent of JCL's MSGLEVEL=0, ie. the allocation 
>of datasets to ddnames.



Not equivalent, I would say. MSGLEVEL is for the whole job, S99MSGL0 is for a 
single allocation.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Randomly disappearing IGD101I messages.

[Peter Hunkeler]

>That might be a good point: different flows through the program that set 
>different S99MSGLO flags.



 and it has nothing to do with "bypassing SMS".


All new allocations are seen by SMS's ACS routines. If they decide to assign a 
Storage Class to the data set, then the data set is "SMS managed"; if not then 
not.


Does anyonw know it it is possible to "bypass the ACS routines" for new 
alloctions?


--
Peter Hunkeler


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[J R]

Dynalloc's S99MSGL0 is the equivalent of JCL's MSGLEVEL=0, ie. the allocation 
of datasets to ddnames.  

Messages describing the details of actually creating new datasets on DASD are 
related to DADSM. 

Sent from my iPhone

> On Oct 20, 2016, at 15:18, Peter Hunkeler  wrote:
> 
> 
>> "So, it is DMS or FDR which decide whether to place those IGD* messages or 
>> not." 
>> 
> 
> 
> --
> Peter Hunkeler
>> To be precise: 
>> It is DMS or FDR which decide to allocate the dataset via SMS or not, 
>> thereby causing the IGD message to appear or not. 
> 
> 
> PMFJI, I do not know but I seriously wonder if it is possible for a program 
> to "allocate a data set *not* via SMS". It would bring the whole storage 
> management upside down.
> 
> 
> 
> Anyway, I just thought I'd mention that a program using dynamic allocation 
> can suppress allocation messages by setting a flag in the SVC99 RB 
> (S99MSGL0). 
> 
> 
> This does not explain why the message would appear for on run of this single 
> job but not in another one. But you mentioned that there slight differences 
> for the data set in question, and that the tool is reacting slightly 
> different. Maybe the S99MSGLO flag is set in some cases but not in others. 
> 
> 
> --
> Peter Hunkeler
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Peter,

That might be a good point: different flows through the program that set 
different S99MSGLO flags.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Thursday, October 20, 2016 9:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

 
>"So, it is DMS or FDR which decide whether to place those IGD* messages or 
>not." 
 >


--
Peter Hunkeler
>To be precise: 
>It is DMS or FDR which decide to allocate the dataset via SMS or not, thereby 
>causing the IGD message to appear or not. 
 

PMFJI, I do not know but I seriously wonder if it is possible for a program to 
"allocate a data set *not* via SMS". It would bring the whole storage 
management upside down.



Anyway, I just thought I'd mention that a program using dynamic allocation can 
suppress allocation messages by setting a flag in the SVC99 RB (S99MSGL0). 


This does not explain why the message would appear for on run of this single 
job but not in another one. But you mentioned that there slight differences for 
the data set in question, and that the tool is reacting slightly different. 
Maybe the S99MSGLO flag is set in some cases but not in others. 


--
Peter Hunkeler

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Greg,

If you request to bypass SMS, no IGD101I can be expected. Can you create an 
example where things are left to SMS when possible?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Shirey
Sent: Thursday, October 20, 2016 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Here is a job which produced a new SMS-managed data set without generating an 
IGD101I message: 

//DPC088X   JOB 111,NOTIFY=DPC088,CLASS=A,MSGLEVEL=(1,1) 
//STEP01   EXEC PGM=ADRDSSU,REGION=0M 
//SYSPRINT DD SYSOUT=*   
//DD2  DD  UNIT=3390,VOL=SER=TSO003,DISP=SHR 
//SYSIN DD * 
 COPY  ODD(DD2) -
 DS(INCLUDE('DPC088.DISK.PTF')) -  
  BYPASSACS('DPC088.DISK.PTF') -   
  RENAMEU((DPC088.DISK.PTF,SYT.DPC088.DISK.PTF)) -   
  STORCLAS(TSOSC)  - 
 DELETE PURGE CATALOG PROCESS(SYS1) ALLDATA(*)   


Regards,
Greg Shirey
Ben E. Keith Company 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Thursday, October 20, 2016 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

"So, it is DMS or FDR which decide whether to place those IGD* messages or not."

To be precise:
It is DMS or FDR which decide to allocate the dataset via SMS or not, thereby 
causing the IGD message to appear or not.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Peter Hunkeler]

>"So, it is DMS or FDR which decide whether to place those IGD* messages or 
>not."
 >


--
Peter Hunkeler
>To be precise:
>It is DMS or FDR which decide to allocate the dataset via SMS or not, thereby 
>causing the IGD message to appear or not.


PMFJI, I do not know but I seriously wonder if it is possible for a program to 
"allocate a data set *not* via SMS". It would bring the whole storage 
management upside down.



Anyway, I just thought I'd mention that a program using dynamic allocation can 
suppress allocation messages by setting a flag in the SVC99 RB (S99MSGL0).


This does not explain why the message would appear for on run of this single 
job but not in another one. But you mentioned that there slight differences for 
the data set in question, and that the tool is reacting slightly different. 
Maybe the S99MSGLO flag is set in some cases but not in others.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Greg Shirey]

Here is a job which produced a new SMS-managed data set without generating an 
IGD101I message: 

//DPC088X   JOB 111,NOTIFY=DPC088,CLASS=A,MSGLEVEL=(1,1) 
//STEP01   EXEC PGM=ADRDSSU,REGION=0M 
//SYSPRINT DD SYSOUT=*   
//DD2  DD  UNIT=3390,VOL=SER=TSO003,DISP=SHR 
//SYSIN DD * 
 COPY  ODD(DD2) -
 DS(INCLUDE('DPC088.DISK.PTF')) -  
  BYPASSACS('DPC088.DISK.PTF') -   
  RENAMEU((DPC088.DISK.PTF,SYT.DPC088.DISK.PTF)) -   
  STORCLAS(TSOSC)  - 
 DELETE PURGE CATALOG PROCESS(SYS1) ALLDATA(*)   


Regards,
Greg Shirey
Ben E. Keith Company 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Thursday, October 20, 2016 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

"So, it is DMS or FDR which decide whether to place those IGD* messages or not."

To be precise:
It is DMS or FDR which decide to allocate the dataset via SMS or not, thereby 
causing the IGD message to appear or not.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

"So, it is DMS or FDR which decide whether to place those IGD* messages or not."

To be precise:
It is DMS or FDR which decide to allocate the dataset via SMS or not, thereby 
causing the IGD message to appear or not.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 20 October, 2016 15:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Vernooij, Kees (ITOPT1) - KLM  wrote:

>We found the answer.

Excellent! 


>IGD101I is used by Control-M for the 'disp=catalog' rule of dataset triggering.
>IGD104I is used by Control-M for the 'disp=keep' rule of dataset triggering.
>In the case of the DMS step IGD104I is always produced, so we changed the 
>Control-M rule to trigger on IGD104I, which solved our problem.

Good workaround.


>- We did not check what DFdss does

We use other methods (CSI, SYSDSN in CList, homegrown programs, etc.) to check 
whether a dataset is there or not.

I did not check it, but, AFAIK, if DFDSS does not find a dataset, it will set a 
RC accordingly. Easy to check RC with Control-M.


>The conclusion is, that IGD101I (and even IGD104I in some situations) is not a 
>reliable indicator for dataset creation and we will report this to BMC.

So, it is DMS or FDR which decide whether to place those IGD* messages or not. 
It is annoying, to say at least.

Thanks for telling IBM-MAIN members. I would like to hear what is BMC saying 
about this.

And no, we're not using DMS and FDR.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Elardus Engelbrecht]

Vernooij, Kees (ITOPT1) - KLM  wrote:

>We found the answer.

Excellent! 


>IGD101I is used by Control-M for the 'disp=catalog' rule of dataset triggering.
>IGD104I is used by Control-M for the 'disp=keep' rule of dataset triggering.
>In the case of the DMS step IGD104I is always produced, so we changed the 
>Control-M rule to trigger on IGD104I, which solved our problem.

Good workaround.


>- We did not check what DFdss does

We use other methods (CSI, SYSDSN in CList, homegrown programs, etc.) to check 
whether a dataset is there or not.

I did not check it, but, AFAIK, if DFDSS does not find a dataset, it will set a 
RC accordingly. Easy to check RC with Control-M.


>The conclusion is, that IGD101I (and even IGD104I in some situations) is not a 
>reliable indicator for dataset creation and we will report this to BMC.

So, it is DMS or FDR which decide whether to place those IGD* messages or not. 
It is annoying, to say at least.

Thanks for telling IBM-MAIN members. I would like to hear what is BMC saying 
about this.

And no, we're not using DMS and FDR.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Hi all,

We found the answer.

Apparently IGD101I is produced when SMS creates and catalogues a dataset and 
Control-M relies on this message to detect dataset creation/cataloguing.

But there appear to be other methods to create and catalog SMS managed datasets.

As we already discovered, a dataset copied with FDR never produces IGD101I.

A dataset copied by DMS sometimes does not produce IGD101I. Depending on the 
characteristics of the input dataset, DMS apparently takes different actions to 
create the output dataset:
- When the input dataset is not multi-volume, DMS seems to create the output 
dataset simply via SMS, thereby having IGD101I produced.
- When the input dataset is multi-volume DMS takes different actions to create 
and catalogue the output dataset, apparently not via SMS, so IGD101I is not 
produced. We noticed that the catalog entry of the output dataset contained the 
same number of volser-entries as the input dataset, but if the output datasets 
fits on less volsers than the input dataset, the other volser-entries in the 
catalogue are candidate volsers with "*" in the volser field.
- FDR apparently always creates and catalogues the dataset itself, without SMS, 
so IGD101I is never produced.
- We did not check what DFdss does.

IGD101I is used by Control-M for the 'disp=catalog' rule of dataset triggering.
IGD104I is used by Control-M for the 'disp=keep' rule of dataset triggering.
In the case of the DMS step IGD104I is always produced, so we changed the 
Control-M rule to trigger on IGD104I, which solved our problem.
However in the FDR case, neither IGD101I nor IGD104I are produced, so Control-M 
will probably never be triggered on datasets created by FDR.

The conclusion is, that IGD101I (and even IGD104I in some situations) is not a 
reliable indicator for dataset creation and we will report this to BMC.

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: 18 October, 2016 11:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Randomly disappearing IGD101I messages.

Hello,

Control-M uses message IGD101I for dataset triggering: when a data set has been 
created, as indicated by IGD101I, a job must be triggered.

We see every now and then that the triggering is not working, because IGD101I 
is not produced, although the dataset has been created.
We don't have any clue on what makes IGD101I not appear in some situations: it 
happens in different runs of the same job, on same system, in the same step, 
with the same results, for nearly the same dataset, in the same SMS Storage 
Group.

Anybody recognized this or has an idea where to look?

Thanks,
Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with 

Re: Randomly disappearing IGD101I messages.

[Longabaugh, Robert E]

The IGD101I is in IBM code.  As long as the output volume is SMS controlled, 
the IGD101I should appear consistenly.

There are some ways that an SMS data set can become non-SMS after the move.  
This would depend on the ACS rules in place, or whether you are using an 
Allocation Management product like CA Allocate to redirect allocations, the 
TOVOL parameter which may have non-SMS target volumes, or if the SMS MC, DC, 
and SC of the original data was used by setting SMSALLOCY.   If that kind of a 
quick check does not produce the reason, then it would be best to open a case 
with Level 1 Support and they can look over the documentation.
 
IEF196I appears when a message is for a job running under the MSTR subsystem.  
This does not appear to be the case here.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, October 19, 2016 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

In my case we have automation suppressing the messages.

However, I will see them occasionally when it is preceded by an IEF196I message

IEF196I  IGD101I 


Our scheduling software reads the SMF Records as they are created.  It does not 
require the IGD101I messages to trigger the next job when a dataset/file is 
created/updated.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Vernooij, Kees (ITOPT1) - KLM
> Sent: Wednesday, October 19, 2016 4:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
> 
> I am not looking for a workaround, we already have one.
> I am looking for the mysterious algorithm that decided to produce or 
> not produce IGD101I. This is what makes Control-M trigger a job.
> 
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Elardus Engelbrecht
> Sent: 19 October, 2016 12:44
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
> 
> Vernooij, Kees (ITOPT1) - KLM wrote:
> 
> >Well, the situation is becoming more and more curious:
> - I checked 400 runs of the job in the last year and IGD101I appears 
> in 2/3 of the jobs and does not appear in 1/3 of the jobs, without an 
> indication of why
> 
> Ok, try this temporary workaround:
> 
> In Control-M, insert JOBEND for the job which creates that dataset.
> Now trigger a job which checks whether the dataset is in fact there 
> (allocated / SMS / etc. ) [1] If true, trigger then your second job.
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> [1] - Something like this little Clist:
> 
>   IF ('') = OK THEN   +
>DO
> WRITE DATASET FOUND
> SET  = 0
>END
>   ELSE  +
>DO
> WRITE DATA SET NOT FOUND
> SET  = 4
>END
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Lizette Koehler]

In my case we have automation suppressing the messages.

However, I will see them occasionally when it is preceded by an IEF196I message

IEF196I  IGD101I 


Our scheduling software reads the SMF Records as they are created.  It does not 
require the IGD101I messages to trigger the next job when a dataset/file is 
created/updated.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Vernooij, Kees (ITOPT1) - KLM
> Sent: Wednesday, October 19, 2016 4:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
> 
> I am not looking for a workaround, we already have one.
> I am looking for the mysterious algorithm that decided to produce or not
> produce IGD101I. This is what makes Control-M trigger a job.
> 
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: 19 October, 2016 12:44
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
> 
> Vernooij, Kees (ITOPT1) - KLM wrote:
> 
> >Well, the situation is becoming more and more curious:
> - I checked 400 runs of the job in the last year and IGD101I appears in 2/3 of
> the jobs and does not appear in 1/3 of the jobs, without an indication of why
> 
> Ok, try this temporary workaround:
> 
> In Control-M, insert JOBEND for the job which creates that dataset.
> Now trigger a job which checks whether the dataset is in fact there (allocated
> / SMS / etc. ) [1] If true, trigger then your second job.
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> [1] - Something like this little Clist:
> 
>   IF ('') = OK THEN   +
>DO
> WRITE DATASET FOUND
> SET  = 0
>END
>   ELSE  +
>DO
> WRITE DATA SET NOT FOUND
> SET  = 4
>END
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

I am not looking for a workaround, we already have one.
I am looking for the mysterious algorithm that decided to produce or not 
produce IGD101I. This is what makes Control-M trigger a job.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 19 October, 2016 12:44
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Vernooij, Kees (ITOPT1) - KLM wrote:

>Well, the situation is becoming more and more curious: 
- I checked 400 runs of the job in the last year and IGD101I appears in 2/3 of 
the jobs and does not appear in 1/3 of the jobs, without an indication of why

Ok, try this temporary workaround:

In Control-M, insert JOBEND for the job which creates that dataset.
Now trigger a job which checks whether the dataset is in fact there (allocated 
/ SMS / etc. ) [1]
If true, trigger then your second job.

Groete / Greetings
Elardus Engelbrecht 

[1] - Something like this little Clist:

  IF ('') = OK THEN   + 
   DO 
WRITE DATASET FOUND   
SET  = 0   
   END
  ELSE  + 
   DO 
WRITE DATA SET NOT FOUND  
SET  = 4   
   END

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Elardus Engelbrecht]

Vernooij, Kees (ITOPT1) - KLM wrote:

>Well, the situation is becoming more and more curious: 
- I checked 400 runs of the job in the last year and IGD101I appears in 2/3 of 
the jobs and does not appear in 1/3 of the jobs, without an indication of why

Ok, try this temporary workaround:

In Control-M, insert JOBEND for the job which creates that dataset.
Now trigger a job which checks whether the dataset is in fact there (allocated 
/ SMS / etc. ) [1]
If true, trigger then your second job.

Groete / Greetings
Elardus Engelbrecht 

[1] - Something like this little Clist:

  IF ('') = OK THEN   + 
   DO 
WRITE DATASET FOUND   
SET  = 0   
   END
  ELSE  + 
   DO 
WRITE DATA SET NOT FOUND  
SET  = 4   
   END

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Bob,

Well, the situation is becoming more and more curious:
- I checked 400 runs of the job in the last year and IGD101I appears in 2/3 of 
the jobs and does not appear in 1/3 of the jobs, without an indication of why.
- We changed the copy step to FDR (PGM=FDRCOPY, statement: COPY TYPE=DSF) and 
this does not produce any IGD101I messages, nor does it produce IGD104I 
(retained) messages, which the DMS step did produce reliably. This, by the way, 
this makes FDR unfit for Control-M dataset triggering.

What causes IGD101I to appear and/or what causes SMS to produce IGD101I or not 
produce it. 
Is it depending on the actions DMS and FDR do? E.g. using BYPASSSMS options? 
Why does DMS sometimes have IGD101I generated and sometimes not?

Can you clarify this from the DMS side?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: 19 October, 2016 8:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Bob,

I could not find any difference between the steps with and without IGD101I. The 
JCL is the same, the output dataset cannot exist because this would generate 
RC=8 and all steps have RC=0, all output datasets are SMS managed.
I'll do some further investigations to try to discover when the problem has 
started and what maintenance actions have taken place around that time.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Longabaugh, Robert E
Sent: 18 October, 2016 19:48
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

When CA Disk moves SMS data sets, it renames the original to a temporary name 
and creates the new one with the existing name.  If the new data set is 
correctly created, cataloged, written, and closed, then CA Disk deletes the 
original (now renamed) data set.  If the move operation fails the original data 
set is renamed back to the original name.  The Auto Restore intercepts would 
not become involved, but the CA Disk SVC will intervene so that the last use 
date remains the same.

IGD101I is produced for a new SMS data set allocation.  IGD103I is for existing 
SMS data sets.  

Is it possible that the moved data set would sometimes be created non-SMS?  
This might be due to redirection by the ACS routine or an allocation management 
product such as CA Allocate.

Also check the CA Disk SYSPARM SMSALLOC, which determines if CA Disk passes the 
existing STORCLAS, DATACLAS, and MGMTCLAS to the allocation request for the 
move.  

Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Shirey
Sent: Tuesday, October 18, 2016 9:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

I would suggest asking CA about the DMS step not generating the IGD101I 
message.  (DMS has a "hook" in SMS, doesn't it?) 

Regards,
Greg Shirey
Ben E. Keith Company

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, October 18, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

One I see BMC has asked for doc. I would definitely do that.
Two, I concur with Tom Conley, Most scheduling software will provide an SMF 
Exit in order to see when datasets are created/updated.  

I would follow up with BMC and see what they say.  If they are dependent on 
IGD101I then you need to open a case to IBM on how or when the IGD101I is 
produced to SYSLOG.

A message is produced or not based on MPF list, Automation Tools, or a user 
exit.  The Vendors (IBM and BMC) should be able to help you determine why this 
is going on.

What z/OS Maintenance has been implemented when you first noticed this issue 
What BMC maintenance has been implemented when you first noticed this issue

What user exits are in your system (IEF*) or MPF List exit, or Automation tool 
changes.



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or 

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Bob,

I could not find any difference between the steps with and without IGD101I. The 
JCL is the same, the output dataset cannot exist because this would generate 
RC=8 and all steps have RC=0, all output datasets are SMS managed.
I'll do some further investigations to try to discover when the problem has 
started and what maintenance actions have taken place around that time.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Longabaugh, Robert E
Sent: 18 October, 2016 19:48
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

When CA Disk moves SMS data sets, it renames the original to a temporary name 
and creates the new one with the existing name.  If the new data set is 
correctly created, cataloged, written, and closed, then CA Disk deletes the 
original (now renamed) data set.  If the move operation fails the original data 
set is renamed back to the original name.  The Auto Restore intercepts would 
not become involved, but the CA Disk SVC will intervene so that the last use 
date remains the same.

IGD101I is produced for a new SMS data set allocation.  IGD103I is for existing 
SMS data sets.  

Is it possible that the moved data set would sometimes be created non-SMS?  
This might be due to redirection by the ACS routine or an allocation management 
product such as CA Allocate.

Also check the CA Disk SYSPARM SMSALLOC, which determines if CA Disk passes the 
existing STORCLAS, DATACLAS, and MGMTCLAS to the allocation request for the 
move.  

Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Shirey
Sent: Tuesday, October 18, 2016 9:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

I would suggest asking CA about the DMS step not generating the IGD101I 
message.  (DMS has a "hook" in SMS, doesn't it?) 

Regards,
Greg Shirey
Ben E. Keith Company

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, October 18, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

One I see BMC has asked for doc. I would definitely do that.
Two, I concur with Tom Conley, Most scheduling software will provide an SMF 
Exit in order to see when datasets are created/updated.  

I would follow up with BMC and see what they say.  If they are dependent on 
IGD101I then you need to open a case to IBM on how or when the IGD101I is 
produced to SYSLOG.

A message is produced or not based on MPF list, Automation Tools, or a user 
exit.  The Vendors (IBM and BMC) should be able to help you determine why this 
is going on.

What z/OS Maintenance has been implemented when you first noticed this issue 
What BMC maintenance has been implemented when you first noticed this issue

What user exits are in your system (IEF*) or MPF List exit, or Automation tool 
changes.



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Longabaugh, Robert E]

When CA Disk moves SMS data sets, it renames the original to a temporary name 
and creates the new one with the existing name.  If the new data set is 
correctly created, cataloged, written, and closed, then CA Disk deletes the 
original (now renamed) data set.  If the move operation fails the original data 
set is renamed back to the original name.  The Auto Restore intercepts would 
not become involved, but the CA Disk SVC will intervene so that the last use 
date remains the same.

IGD101I is produced for a new SMS data set allocation.  IGD103I is for existing 
SMS data sets.  

Is it possible that the moved data set would sometimes be created non-SMS?  
This might be due to redirection by the ACS routine or an allocation management 
product such as CA Allocate.

Also check the CA Disk SYSPARM SMSALLOC, which determines if CA Disk passes the 
existing STORCLAS, DATACLAS, and MGMTCLAS to the allocation request for the 
move.  

Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Shirey
Sent: Tuesday, October 18, 2016 9:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

I would suggest asking CA about the DMS step not generating the IGD101I 
message.  (DMS has a "hook" in SMS, doesn't it?) 

Regards,
Greg Shirey
Ben E. Keith Company

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, October 18, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

One I see BMC has asked for doc. I would definitely do that.
Two, I concur with Tom Conley, Most scheduling software will provide an SMF 
Exit in order to see when datasets are created/updated.  

I would follow up with BMC and see what they say.  If they are dependent on 
IGD101I then you need to open a case to IBM on how or when the IGD101I is 
produced to SYSLOG.

A message is produced or not based on MPF list, Automation Tools, or a user 
exit.  The Vendors (IBM and BMC) should be able to help you determine why this 
is going on.

What z/OS Maintenance has been implemented when you first noticed this issue 
What BMC maintenance has been implemented when you first noticed this issue

What user exits are in your system (IEF*) or MPF List exit, or Automation tool 
changes.



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Greg Shirey]

I would suggest asking CA about the DMS step not generating the IGD101I 
message.  (DMS has a "hook" in SMS, doesn't it?) 

Regards,
Greg Shirey
Ben E. Keith Company

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, October 18, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

One I see BMC has asked for doc. I would definitely do that.
Two, I concur with Tom Conley, Most scheduling software will provide an SMF 
Exit in order to see when datasets are created/updated.  

I would follow up with BMC and see what they say.  If they are dependent on 
IGD101I then you need to open a case to IBM on how or when the IGD101I is 
produced to SYSLOG.

A message is produced or not based on MPF list, Automation Tools, or a user 
exit.  The Vendors (IBM and BMC) should be able to help you determine why this 
is going on.

What z/OS Maintenance has been implemented when you first noticed this issue 
What BMC maintenance has been implemented when you first noticed this issue

What user exits are in your system (IEF*) or MPF List exit, or Automation tool 
changes.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Elardus Engelbrecht]

Vernooij, Kees (ITOPT1) - KLM wrote:

>Two: IGD101I seems to be among those messages that are only/directly sent to 
>the job's allocation message file and never make it to the Syslog/Operlog and 
>are never seen by SLIP, MPFLST and other automation tools that scan the 
>subsystem interface for messages. 
 
>Three: Saying this, I wonder how Control-M traps the message (and possibly 
>does unwanted things with it). Maybe I should consult them anyway. 

Check your IEFSSNxx before you run away to BMC, sequence is *important*:

Mine looks like this one:

SUBSYS SUBNAME(SMS)
  INITRTN(IGDSSIIN)   
  INITPARM('ID=00,PROMPT=DISPLAY')
SUBSYS SUBNAME(JES2)  
  PRIMARY(YES)  START(YES)
SUBSYS SUBNAME(O50J)  /* Control-M */
SUBSYS SUBNAME(RACF) /* RACF */
  INITRTN(IRRSSI00)  
... etc ...


Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Lizette,

One: Getting BMC to redesign Control-M is heavy and long lasting and not 
necessary if IGD101I is reliably produced.
Two: IGD101I seems to be among those messages that are only/directly sent to 
the job's allocation message file and never make it to the Syslog/Operlog and 
are never seen by SLIP, MPFLST and other automation tools that scan the 
subsystem interface for messages.

Three: Saying this, I wonder how Control-M traps the message (and possibly does 
unwanted things with it). Maybe I should consult them anyway.

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: 18 October, 2016 15:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

One I see BMC has asked for doc. I would definitely do that.
Two, I concur with Tom Conley, Most scheduling software will provide an SMF 
Exit in order to see when datasets are created/updated.  

I would follow up with BMC and see what they say.  If they are dependent on 
IGD101I then you need to open a case to IBM on how or when the IGD101I is 
produced to SYSLOG.

A message is produced or not based on MPF list, Automation Tools, or a user 
exit.  The Vendors (IBM and BMC) should be able to help you determine why this 
is going on.

What z/OS Maintenance has been implemented when you first noticed this issue
What BMC maintenance has been implemented when you first noticed this issue

What user exits are in your system (IEF*) or MPF List exit, or Automation tool 
changes.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Vernooij, Kees (ITOPT1) - KLM
> Sent: Tuesday, October 18, 2016 6:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
> 
> We verified that the problem exists for at least a couple of months.
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: 18 October, 2016 15:32
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
> 
> Vernooij, Kees (ITOPT1) - KLM wrote:
> 
> >Via a DMS COPY step. Always. Can't find any suppression, nor do I specify
> route of desc codes for IBM's IGD messages.
> 
> >They are among the messages that (seem to) never appear in SYSLOG/OPERLOG,
> only in the job's Allocation messages file. IGD101I is not trappable via SLIP
> or MPFLST. They seem to be (like the IGD messages produces by the ACS routines
> WRITE statements) directly written to the job sysout.
> How is this achieved?
> 
> OK. Thanks for earlier clarifying that BMC's products are victims.
> 
> Ok, I think it is time for a PMR because I looked up who is the issuer of
> IGD101I and it is DFSMSdfp. Not even a module name is mentioned in the
> bookies.
> 
> Last question: did you upgraded and now only see this problem?
> 
> Sorry for not being able to help you.
> 
> Groete / Greetings
> Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Lizette Koehler]

One I see BMC has asked for doc. I would definitely do that.
Two, I concur with Tom Conley, Most scheduling software will provide an SMF 
Exit in order to see when datasets are created/updated.  

I would follow up with BMC and see what they say.  If they are dependent on 
IGD101I then you need to open a case to IBM on how or when the IGD101I is 
produced to SYSLOG.

A message is produced or not based on MPF list, Automation Tools, or a user 
exit.  The Vendors (IBM and BMC) should be able to help you determine why this 
is going on.

What z/OS Maintenance has been implemented when you first noticed this issue
What BMC maintenance has been implemented when you first noticed this issue

What user exits are in your system (IEF*) or MPF List exit, or Automation tool 
changes.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Vernooij, Kees (ITOPT1) - KLM
> Sent: Tuesday, October 18, 2016 6:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
> 
> We verified that the problem exists for at least a couple of months.
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: 18 October, 2016 15:32
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
> 
> Vernooij, Kees (ITOPT1) - KLM wrote:
> 
> >Via a DMS COPY step. Always. Can't find any suppression, nor do I specify
> route of desc codes for IBM's IGD messages.
> 
> >They are among the messages that (seem to) never appear in SYSLOG/OPERLOG,
> only in the job's Allocation messages file. IGD101I is not trappable via SLIP
> or MPFLST. They seem to be (like the IGD messages produces by the ACS routines
> WRITE statements) directly written to the job sysout.
> How is this achieved?
> 
> OK. Thanks for earlier clarifying that BMC's products are victims.
> 
> Ok, I think it is time for a PMR because I looked up who is the issuer of
> IGD101I and it is DFSMSdfp. Not even a module name is mentioned in the
> bookies.
> 
> Last question: did you upgraded and now only see this problem?
> 
> Sorry for not being able to help you.
> 
> Groete / Greetings
> Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

It is 1 job with the same JCL each time that sometimes loses IGD101I.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lucas Rosalen
Sent: 18 October, 2016 15:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Hello Kees,

You might had already looked at that, but if both jobs don't have MSGLEVEL
coded in the jobcards, they might rely on each job class' MSGLEVEL, which
might differ from each other.
Sorry, to much stuff going on today to properly test this...

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
<lrosa...@br.ibm.com>*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2016-10-18 15:35 GMT+02:00 Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com>:

> We verified that the problem exists for at least a couple of months.
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: 18 October, 2016 15:32
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
>
> Vernooij, Kees (ITOPT1) - KLM wrote:
>
> >Via a DMS COPY step. Always. Can't find any suppression, nor do I specify
> route of desc codes for IBM's IGD messages.
>
> >They are among the messages that (seem to) never appear in
> SYSLOG/OPERLOG, only in the job's Allocation messages file. IGD101I is not
> trappable via SLIP or MPFLST. They seem to be (like the IGD messages
> produces by the ACS routines WRITE statements) directly written to the job
> sysout.
> How is this achieved?
>
> OK. Thanks for earlier clarifying that BMC's products are victims.
>
> Ok, I think it is time for a PMR because I looked up who is the issuer of
> IGD101I and it is DFSMSdfp. Not even a module name is mentioned in the
> bookies.
>
> Last question: did you upgraded and now only see this problem?
>
> Sorry for not being able to help you.
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, 

Re: Randomly disappearing IGD101I messages.

[Lucas Rosalen]

Hello Kees,

You might had already looked at that, but if both jobs don't have MSGLEVEL
coded in the jobcards, they might rely on each job class' MSGLEVEL, which
might differ from each other.
Sorry, to much stuff going on today to properly test this...

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
<lrosa...@br.ibm.com>*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2016-10-18 15:35 GMT+02:00 Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com>:

> We verified that the problem exists for at least a couple of months.
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: 18 October, 2016 15:32
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
>
> Vernooij, Kees (ITOPT1) - KLM wrote:
>
> >Via a DMS COPY step. Always. Can't find any suppression, nor do I specify
> route of desc codes for IBM's IGD messages.
>
> >They are among the messages that (seem to) never appear in
> SYSLOG/OPERLOG, only in the job's Allocation messages file. IGD101I is not
> trappable via SLIP or MPFLST. They seem to be (like the IGD messages
> produces by the ACS routines WRITE statements) directly written to the job
> sysout.
> How is this achieved?
>
> OK. Thanks for earlier clarifying that BMC's products are victims.
>
> Ok, I think it is time for a PMR because I looked up who is the issuer of
> IGD101I and it is DFSMSdfp. Not even a module name is mentioned in the
> bookies.
>
> Last question: did you upgraded and now only see this problem?
>
> Sorry for not being able to help you.
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

We verified that the problem exists for at least a couple of months.
Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 18 October, 2016 15:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Vernooij, Kees (ITOPT1) - KLM wrote:

>Via a DMS COPY step. Always. Can't find any suppression, nor do I specify 
>route of desc codes for IBM's IGD messages. 
 
>They are among the messages that (seem to) never appear in SYSLOG/OPERLOG, 
>only in the job's Allocation messages file. IGD101I is not trappable via SLIP 
>or MPFLST. They seem to be (like the IGD messages produces by the ACS routines 
>WRITE statements) directly written to the job sysout.  
How is this achieved? 

OK. Thanks for earlier clarifying that BMC's products are victims.

Ok, I think it is time for a PMR because I looked up who is the issuer of 
IGD101I and it is DFSMSdfp. Not even a module name is mentioned in the bookies.

Last question: did you upgraded and now only see this problem?

Sorry for not being able to help you.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Elardus Engelbrecht]

Vernooij, Kees (ITOPT1) - KLM wrote:

>Via a DMS COPY step. Always. Can't find any suppression, nor do I specify 
>route of desc codes for IBM's IGD messages. 
 
>They are among the messages that (seem to) never appear in SYSLOG/OPERLOG, 
>only in the job's Allocation messages file. IGD101I is not trappable via SLIP 
>or MPFLST. They seem to be (like the IGD messages produces by the ACS routines 
>WRITE statements) directly written to the job sysout.  
How is this achieved? 

OK. Thanks for earlier clarifying that BMC's products are victims.

Ok, I think it is time for a PMR because I looked up who is the issuer of 
IGD101I and it is DFSMSdfp. Not even a module name is mentioned in the bookies.

Last question: did you upgraded and now only see this problem?

Sorry for not being able to help you.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Via a DMS COPY step.
Always.
Can't find any suppression, nor do I specify route of desc codes for IBM's IGD 
messages.

They are among the messages that (seem to) never appear in SYSLOG/OPERLOG, only 
in the job's Allocation messages file. IGD101I is not trappable via SLIP or 
MPFLST. They seem to be (like the IGD messages produces by the ACS routines 
WRITE statements) directly written to the job sysout. 
How is this achieved?

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 18 October, 2016 15:09
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Vernooij, Kees (ITOPT1) - KLM wrote:

>I would circumvent the problems (if I can get BMC to redesign their way of 
>working), but still the question remains, why the message sometimes disappear.

Question - how are they allocated? Via JCL DD statements or via dynalloc? 

Is SMS *always* used in those allocations?

I'm still wondering if messages are suppressed or if you're using wrong or 
non-standard route code or description code?

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Yifat,
There is no difference between jobs with and without IGD101I.
BMC is just victim of the not-appearing message.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Oren, Yifat
Sent: 18 October, 2016 15:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Hi Kees,

Are there any allocation messages issued?

The MSGLEVEL parameter controls whether allocation messages are issued to the 
JESYSMSG sysout. Make sure it is (1,1) in all executions.

Otherwise, please open a ticket with BMC and attach the sysout of 2 different 
job runs (one with the message and one without it).

HTH,
Yifat

These postings are my own and do not necessarily represent BMC's position, 
strategies, or opinion.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: 18 October 2016 15:56
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

I would circumvent the problems (if I can get BMC to redesign their way of 
working), but still the question remains, why the message sometimes disappear.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: 18 October, 2016 14:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

On 10/18/2016 5:04 AM, Vernooij, Kees - KLM , ITOPT1 wrote:
> Hello,
>
> Control-M uses message IGD101I for dataset triggering: when a data set has 
> been created, as indicated by IGD101I, a job must be triggered.
>
> We see every now and then that the triggering is not working, because IGD101I 
> is not produced, although the dataset has been created.
> We don't have any clue on what makes IGD101I not appear in some situations: 
> it happens in different runs of the same job, on same system, in the same 
> step, with the same results, for nearly the same dataset, in the same SMS 
> Storage Group.
>
> Anybody recognized this or has an idea where to look?
>
> Thanks,
> Kees.
>
> 
> For information, services and offers, please visit our web site: 
> http://www.klm.com. This e-mail and any attachment may contain confidential 
> and privileged material intended for the addressee only. If you are not the 
> addressee, you are notified that no part of the e-mail or any attachment may 
> be disclosed, copied or distributed, and that any other action related to 
> this e-mail or attachment is strictly prohibited, and may be unlawful. If you 
> have received this e-mail by error, please notify the sender immediately by 
> return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
> employees shall not be liable for the incorrect or incomplete transmission of 
> this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
> Airlines) is registered in Amstelveen, The Netherlands, with registered 
> number 33014286
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

Kees,

I haven't worked on Control-M, but the other job schedulers I've worked 
on use the IEFU8x SMF exits to trap dataset creation records.  You say 
in another post that you're seeing the SMF data, so you should ask BMC 
for an IEFU8x exit for dataset triggering.

Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (al

Re: Randomly disappearing IGD101I messages.

[Oren, Yifat]

Hi Kees,

Are there any allocation messages issued?

The MSGLEVEL parameter controls whether allocation messages are issued to the 
JESYSMSG sysout. Make sure it is (1,1) in all executions.

Otherwise, please open a ticket with BMC and attach the sysout of 2 different 
job runs (one with the message and one without it).

HTH,
Yifat

These postings are my own and do not necessarily represent BMC's position, 
strategies, or opinion.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: 18 October 2016 15:56
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

I would circumvent the problems (if I can get BMC to redesign their way of 
working), but still the question remains, why the message sometimes disappear.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: 18 October, 2016 14:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

On 10/18/2016 5:04 AM, Vernooij, Kees - KLM , ITOPT1 wrote:
> Hello,
>
> Control-M uses message IGD101I for dataset triggering: when a data set has 
> been created, as indicated by IGD101I, a job must be triggered.
>
> We see every now and then that the triggering is not working, because IGD101I 
> is not produced, although the dataset has been created.
> We don't have any clue on what makes IGD101I not appear in some situations: 
> it happens in different runs of the same job, on same system, in the same 
> step, with the same results, for nearly the same dataset, in the same SMS 
> Storage Group.
>
> Anybody recognized this or has an idea where to look?
>
> Thanks,
> Kees.
>
> 
> For information, services and offers, please visit our web site: 
> http://www.klm.com. This e-mail and any attachment may contain confidential 
> and privileged material intended for the addressee only. If you are not the 
> addressee, you are notified that no part of the e-mail or any attachment may 
> be disclosed, copied or distributed, and that any other action related to 
> this e-mail or attachment is strictly prohibited, and may be unlawful. If you 
> have received this e-mail by error, please notify the sender immediately by 
> return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
> employees shall not be liable for the incorrect or incomplete transmission of 
> this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
> Airlines) is registered in Amstelveen, The Netherlands, with registered 
> number 33014286
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

Kees,

I haven't worked on Control-M, but the other job schedulers I've worked 
on use the IEFU8x SMF exits to trap dataset creation records.  You say 
in another post that you're seeing the SMF data, so you should ask BMC 
for an IEFU8x exit for dataset triggering.

Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the 

Re: Randomly disappearing IGD101I messages.

[Elardus Engelbrecht]

Vernooij, Kees (ITOPT1) - KLM wrote:

>I would circumvent the problems (if I can get BMC to redesign their way of 
>working), but still the question remains, why the message sometimes disappear.

Question - how are they allocated? Via JCL DD statements or via dynalloc? 

Is SMS *always* used in those allocations?

I'm still wondering if messages are suppressed or if you're using wrong or 
non-standard route code or description code?

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

I would circumvent the problems (if I can get BMC to redesign their way of 
working), but still the question remains, why the message sometimes disappear.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: 18 October, 2016 14:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

On 10/18/2016 5:04 AM, Vernooij, Kees - KLM , ITOPT1 wrote:
> Hello,
>
> Control-M uses message IGD101I for dataset triggering: when a data set has 
> been created, as indicated by IGD101I, a job must be triggered.
>
> We see every now and then that the triggering is not working, because IGD101I 
> is not produced, although the dataset has been created.
> We don't have any clue on what makes IGD101I not appear in some situations: 
> it happens in different runs of the same job, on same system, in the same 
> step, with the same results, for nearly the same dataset, in the same SMS 
> Storage Group.
>
> Anybody recognized this or has an idea where to look?
>
> Thanks,
> Kees.
>
> 
> For information, services and offers, please visit our web site: 
> http://www.klm.com. This e-mail and any attachment may contain confidential 
> and privileged material intended for the addressee only. If you are not the 
> addressee, you are notified that no part of the e-mail or any attachment may 
> be disclosed, copied or distributed, and that any other action related to 
> this e-mail or attachment is strictly prohibited, and may be unlawful. If you 
> have received this e-mail by error, please notify the sender immediately by 
> return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
> employees shall not be liable for the incorrect or incomplete transmission of 
> this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
> Airlines) is registered in Amstelveen, The Netherlands, with registered 
> number 33014286
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

Kees,

I haven't worked on Control-M, but the other job schedulers I've worked 
on use the IEFU8x SMF exits to trap dataset creation records.  You say 
in another post that you're seeing the SMF data, so you should ask BMC 
for an IEFU8x exit for dataset triggering.

Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Tom Conley]

On 10/18/2016 5:04 AM, Vernooij, Kees - KLM , ITOPT1 wrote:

Hello,

Control-M uses message IGD101I for dataset triggering: when a data set has been 
created, as indicated by IGD101I, a job must be triggered.

We see every now and then that the triggering is not working, because IGD101I 
is not produced, although the dataset has been created.
We don't have any clue on what makes IGD101I not appear in some situations: it 
happens in different runs of the same job, on same system, in the same step, 
with the same results, for nearly the same dataset, in the same SMS Storage 
Group.

Anybody recognized this or has an idea where to look?

Thanks,
Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



Kees,

I haven't worked on Control-M, but the other job schedulers I've worked 
on use the IEFU8x SMF exits to trap dataset creation records.  You say 
in another post that you're seeing the SMF data, so you should ask BMC 
for an IEFU8x exit for dataset triggering.


Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Yes, the jobstep does the same task each time. Besides, if the dataset already 
existed, the step would fail.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: 18 October, 2016 14:30
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

kees, are you sure that the expected dataset that shoud be reported by
IGD101I is allocated new?


ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Tue, Oct 18, 2016 at 2:39 PM, Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> No, everything is equal in all jobs (from what I could check), except the
> appearance of the message.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Itschak Mugzach
> Sent: 18 October, 2016 13:31
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
>
> Are all allocations are SMS managed? May be SMS is not involved in some of
> the allocations, or the dataset was not allocated as new in some cases.
>
> ITschak
>
> ITschak Mugzach
> Z/OS, ISV Products and Application Security & Risk Assessments Professional
>
> On Tue, Oct 18, 2016 at 1:39 PM, Vernooij, Kees (ITOPT1) - KLM <
> kees.verno...@klm.com> wrote:
>
> > There is something special with IGD101I, it only appears in the job's
> > allocation message file. Not in SYSLOG and it is not trappable by SLIP or
> > MPF.
> >
> > What is the special route through the system of this type of messages?
> >
> > Kees.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Elardus Engelbrecht
> > Sent: 18 October, 2016 12:32
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Randomly disappearing IGD101I messages.
> >
> > Vernooij, Kees (ITOPT1) - KLM wrote:
> >
> > >Everything is equal, no errors, only IGD101I is sometimes missing and we
> > have no idea why.
> >
> > Ok, where is that message displayed? Joblog or Syslog or where?
> > What is the Route and Descriptor code where you expect the message to be
> > shown?
> >
> > Perhaps you should change Route and/or Descriptor of your batch job which
> > shows that message?
> >
> > Do you have any MPF exit?
> >
> > I think something is being run on your system (Control-O or MPF or SMS
> > exit) which suppress those message?
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > 
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only. If
> > you are not the addressee, you are notified that no part of the e-mail or
> > any attachment may be disclosed, copied or distributed, and that any
> other
> > action related to this e-mail or attachment is strictly prohibited, and
> may
> > be unlawful. If you have received this e-mail by error, please notify the
> > sender immediately by return e-mail, and delete this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> > employees shall not be liable for the incorrect or incomplete
> transmission
> > of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with registered
> > number 33014286
> > 
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and an

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

From the output of the DMS step, that did a copy from one dataset to another, 
from the corresponding SMF records and because manually triggering the job to 
process the datasets caused it to do its work.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Shirey
Sent: 18 October, 2016 14:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Kees,

How are you verifying the data set was created? 

Regards,
Greg Shirey
Ben E. Keith Company 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Tuesday, October 18, 2016 6:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

No, everything is equal in all jobs (from what I could check), except the 
appearance of the message.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Itschak Mugzach]

kees, are you sure that the expected dataset that shoud be reported by
IGD101I is allocated new?


ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Tue, Oct 18, 2016 at 2:39 PM, Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> No, everything is equal in all jobs (from what I could check), except the
> appearance of the message.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Itschak Mugzach
> Sent: 18 October, 2016 13:31
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
>
> Are all allocations are SMS managed? May be SMS is not involved in some of
> the allocations, or the dataset was not allocated as new in some cases.
>
> ITschak
>
> ITschak Mugzach
> Z/OS, ISV Products and Application Security & Risk Assessments Professional
>
> On Tue, Oct 18, 2016 at 1:39 PM, Vernooij, Kees (ITOPT1) - KLM <
> kees.verno...@klm.com> wrote:
>
> > There is something special with IGD101I, it only appears in the job's
> > allocation message file. Not in SYSLOG and it is not trappable by SLIP or
> > MPF.
> >
> > What is the special route through the system of this type of messages?
> >
> > Kees.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Elardus Engelbrecht
> > Sent: 18 October, 2016 12:32
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Randomly disappearing IGD101I messages.
> >
> > Vernooij, Kees (ITOPT1) - KLM wrote:
> >
> > >Everything is equal, no errors, only IGD101I is sometimes missing and we
> > have no idea why.
> >
> > Ok, where is that message displayed? Joblog or Syslog or where?
> > What is the Route and Descriptor code where you expect the message to be
> > shown?
> >
> > Perhaps you should change Route and/or Descriptor of your batch job which
> > shows that message?
> >
> > Do you have any MPF exit?
> >
> > I think something is being run on your system (Control-O or MPF or SMS
> > exit) which suppress those message?
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > 
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only. If
> > you are not the addressee, you are notified that no part of the e-mail or
> > any attachment may be disclosed, copied or distributed, and that any
> other
> > action related to this e-mail or attachment is strictly prohibited, and
> may
> > be unlawful. If you have received this e-mail by error, please notify the
> > sender immediately by return e-mail, and delete this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> > employees shall not be liable for the incorrect or incomplete
> transmission
> > of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with registered
> > number 33014286
> > 
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If 

Re: Randomly disappearing IGD101I messages.

[Greg Shirey]

Kees,

How are you verifying the data set was created? 

Regards,
Greg Shirey
Ben E. Keith Company 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Tuesday, October 18, 2016 6:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

No, everything is equal in all jobs (from what I could check), except the 
appearance of the message.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

No, everything is equal in all jobs (from what I could check), except the 
appearance of the message.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: 18 October, 2016 13:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Are all allocations are SMS managed? May be SMS is not involved in some of
the allocations, or the dataset was not allocated as new in some cases.

ITschak

ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Tue, Oct 18, 2016 at 1:39 PM, Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> There is something special with IGD101I, it only appears in the job's
> allocation message file. Not in SYSLOG and it is not trappable by SLIP or
> MPF.
>
> What is the special route through the system of this type of messages?
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: 18 October, 2016 12:32
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
>
> Vernooij, Kees (ITOPT1) - KLM wrote:
>
> >Everything is equal, no errors, only IGD101I is sometimes missing and we
> have no idea why.
>
> Ok, where is that message displayed? Joblog or Syslog or where?
> What is the Route and Descriptor code where you expect the message to be
> shown?
>
> Perhaps you should change Route and/or Descriptor of your batch job which
> shows that message?
>
> Do you have any MPF exit?
>
> I think something is being run on your system (Control-O or MPF or SMS
> exit) which suppress those message?
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Itschak Mugzach]

Are all allocations are SMS managed? May be SMS is not involved in some of
the allocations, or the dataset was not allocated as new in some cases.

ITschak

ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Tue, Oct 18, 2016 at 1:39 PM, Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> There is something special with IGD101I, it only appears in the job's
> allocation message file. Not in SYSLOG and it is not trappable by SLIP or
> MPF.
>
> What is the special route through the system of this type of messages?
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: 18 October, 2016 12:32
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
>
> Vernooij, Kees (ITOPT1) - KLM wrote:
>
> >Everything is equal, no errors, only IGD101I is sometimes missing and we
> have no idea why.
>
> Ok, where is that message displayed? Joblog or Syslog or where?
> What is the Route and Descriptor code where you expect the message to be
> shown?
>
> Perhaps you should change Route and/or Descriptor of your batch job which
> shows that message?
>
> Do you have any MPF exit?
>
> I think something is being run on your system (Control-O or MPF or SMS
> exit) which suppress those message?
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

There is something special with IGD101I, it only appears in the job's 
allocation message file. Not in SYSLOG and it is not trappable by SLIP or MPF.

What is the special route through the system of this type of messages?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 18 October, 2016 12:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Vernooij, Kees (ITOPT1) - KLM wrote:

>Everything is equal, no errors, only IGD101I is sometimes missing and we have 
>no idea why. 

Ok, where is that message displayed? Joblog or Syslog or where? 
What is the Route and Descriptor code where you expect the message to be shown?

Perhaps you should change Route and/or Descriptor of your batch job which shows 
that message?

Do you have any MPF exit?

I think something is being run on your system (Control-O or MPF or SMS exit) 
which suppress those message?

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Elardus Engelbrecht]

Vernooij, Kees (ITOPT1) - KLM wrote:

>Everything is equal, no errors, only IGD101I is sometimes missing and we have 
>no idea why. 

Ok, where is that message displayed? Joblog or Syslog or where? 
What is the Route and Descriptor code where you expect the message to be shown?

Perhaps you should change Route and/or Descriptor of your batch job which shows 
that message?

Do you have any MPF exit?

I think something is being run on your system (Control-O or MPF or SMS exit) 
which suppress those message?

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Everything is equal, no errors, only IGD101I is sometimes missing and we have 
no idea why.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 18 October, 2016 11:45
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

Vernooij, Kees (ITOPT1) - KLM wrote:

>Control-M uses message IGD101I for dataset triggering: when a data set has 
>been created, as indicated by IGD101I, a job must be triggered.

Isn't that Control-O which scans the SYSLOG? Or am I missing something in your 
setup?

>We see every now and then that the triggering is not working, because IGD101I 
>is not produced, although the dataset has been created.
>We don't have any clue on what makes IGD101I not appear in some situations: it 
>happens in different runs of the same job, on same system, in the same step, 
>with the same results, for nearly the same dataset, in the same SMS Storage 
>Group.

Hmmm. Weird. Is this for the same HLQ ? RACF blocking? out of volser space? Or 
something in the job overriding the ACS routines? Your ACS may suppress it by 
some logic AFAIK.

Alternative - Are your Control-O not suppressing the message conditionally?

>Anybody recognized this or has an idea where to look?

Show us your Control-M (or O) rules + conditions and your job + the messages 
for successfull triggering and unsuccesfull triggering.

I need to see the time, conditions and status of that rule when triggering is 
supposed to go.

What is your Control-M log showing?

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Randomly disappearing IGD101I messages.

[Elardus Engelbrecht]

Vernooij, Kees (ITOPT1) - KLM wrote:

>Control-M uses message IGD101I for dataset triggering: when a data set has 
>been created, as indicated by IGD101I, a job must be triggered.

Isn't that Control-O which scans the SYSLOG? Or am I missing something in your 
setup?

>We see every now and then that the triggering is not working, because IGD101I 
>is not produced, although the dataset has been created.
>We don't have any clue on what makes IGD101I not appear in some situations: it 
>happens in different runs of the same job, on same system, in the same step, 
>with the same results, for nearly the same dataset, in the same SMS Storage 
>Group.

Hmmm. Weird. Is this for the same HLQ ? RACF blocking? out of volser space? Or 
something in the job overriding the ACS routines? Your ACS may suppress it by 
some logic AFAIK.

Alternative - Are your Control-O not suppressing the message conditionally?

>Anybody recognized this or has an idea where to look?

Show us your Control-M (or O) rules + conditions and your job + the messages 
for successfull triggering and unsuccesfull triggering.

I need to see the time, conditions and status of that rule when triggering is 
supposed to go.

What is your Control-M log showing?

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Randomly disappearing IGD101I messages.

[Vernooij, Kees (ITOPT1) - KLM]

Hello,

Control-M uses message IGD101I for dataset triggering: when a data set has been 
created, as indicated by IGD101I, a job must be triggered.

We see every now and then that the triggering is not working, because IGD101I 
is not produced, although the dataset has been created.
We don't have any clue on what makes IGD101I not appear in some situations: it 
happens in different runs of the same job, on same system, in the same step, 
with the same results, for nearly the same dataset, in the same SMS Storage 
Group.

Anybody recognized this or has an idea where to look?

Thanks,
Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN