Re: ABO Automatic Binary Optimizer

[Timothy Sipples]

David Crayford wrote:
>Good point well made.

Thanks, David.

For the record, Amazon.com (the commerce site and associated commerce
services) reportedly consists of a *mix* of programming languages: Java, C,
C++, Perl, Ruby (on Rails), and Javascript. All of these programming
languages are available for IBM z Systems, by the way. Is COBOL "different"
from a testing and deployment lifecycle point of view? No, absolutely not
-- I again strongly disagree. If anything, C (for example) is much more
difficult to test well. Javascript isn't even compiled.

I hope nobody is testing the Employee Cafeteria Menu application and the
Billion Dollar Payments application using the same testing effort and
procedures, even if both applications happen to be written in COBOL and run
on the same machine. That testing equivalence would be nuts.

Adapt or die, folks. Yes, I know some of you occasionally face irrationally
rigid people who celebrate process for process sake, with little or no
awareness of real world outcomes and actual business risks. Some of them
are auditors. That doesn't mean we should agree with such irrational
rigidity.

Back to ABO. ABO and Enterprise COBOL Version 6 have clear benefits. They
can help you reduce your peak monthly utilization, shorten CPU-bound batch
execution times, and improve the performance of latency sensitive
transactions. Those benefits translate directly into financial and other
valuable business benefits. Exactly how much benefit you can get is
situational, but you can figure that out pretty easily (and without your
purchasing department having to do anything). You and your employer have a
choice, and so do your competitors. You can postpone adopting these
technologies until 2038 because you've got a "one size all" testing
program, that's your process (gosh darn it), and any "new" (not new!)
thinking is intolerable. That's one option, an expensive one. Or you can
apply some rationality, discuss appropriate testing scope and methodologies
with IBM, verify that these technologies work and work well starting with
your low risk programs, and enjoy the benefits much sooner. I vote for this
second approach. It's reasonable, rational, logical, informed, and based on
sound risk mitigation and outcome-oriented principles.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)

[Binyamin Dissen]

Data chaining was the original solution to this problem.

On Wed, 19 Oct 2016 00:27:56 +0200 Peter Hunkeler  wrote:

:>
:>Below discussion triggered a question I could not answer by RTFM. I had never 
thought about this before in this detail, but now that I do, I wonder if the 
following is correct.
:>
:>Program allocates >4k of virtual storage. The real frames backing it may or 
may not be contiguous. The program wants to use this area with some interface 
(I/O, etc) that will use real addresses when accessing the storage, so it does 
a PGFIX. PGFIX would move the possibly non-contiguous frames guaranteeing the 
area is backed by contiguous frames. After all, the interface using real 
addresses would expect the the frames to be contiguous. 
:> 
:>
:>Am I wrong? I would have expected to find this documented with the PGFIX or 
PGSER FIX macros, but did not find it.  

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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: Shopz issues?

[Richards, Robert B.]

No, I do not see that message. All I see prior to the CCC is:

virtual user S111 logged in from /205.131.188.10:51349

The port number is the only thing that has changed between attempts by me with 
a new submit.

Bob


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of George Davis
Sent: Monday, October 17, 2016 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz issues?

On 10/17/2016 9:17 AM, Richards, Robert B. wrote:
> Is anyone else having issues doing a RFN from IBM's ShopzSeries?
>
> I get logged in and see the commands CCC followed by BINARY and then nothing. 
> Eventually it retries all 10 times and then fails.

I get something close - do you see:
FC1028 authServer: secure_socket_init failed with rc = 8 (Certificate 
validation error)

--
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]

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

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

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.

[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:

>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: Shopz issues?

[Richards, Robert B.]

Kurt,

We had been running with RFC4217 up to now and it was working. 

Regardless, per your recommendation (and the manual), I changed it to 
CCCNONOTIFY.

Voila! All is well with the RFN world once again, I owe Kurt another virtual 
drink of his choice. 

Thanks again, Kurt! And thanks to the other responders. Cheers! :-)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Tuesday, October 18, 2016 9:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz issues?

On 10/17/2016 9:16 AM, Richards, Robert B. wrote:
> Is anyone else having issues doing a RFN from IBM's ShopzSeries?
>
> I get logged in and see the commands CCC followed by BINARY and then 
> nothing. Eventually it retries all 10 times and then fails.

Someone else reported similar behavior last week, so perhaps its related.  
Verify the FTP.DATA file you're using has the following:

TLSRFCLEVEL   CCCNONOTIFY

For reference, see the SMP/E User's Guide:
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.gim3000/gim3115s.htm

Kurt Quackenbush -- IBM, SMP/E Development

--
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.

[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
*
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, 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

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 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: Shopz issues?

[Richards, Robert B.]

Let me ask my question differently:

Is anyone *successfully* processing RECEIVEFROMNETWORK orders since Sunday's 
Shopz outage?

My firewall guy says that the FTP request was allowed to go out just fine. 

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Tuesday, October 18, 2016 5:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz issues?

No, I do not see that message. All I see prior to the CCC is:

virtual user S111 logged in from /205.131.188.10:51349

The port number is the only thing that has changed between attempts by me with 
a new submit.

Bob


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of George Davis
Sent: Monday, October 17, 2016 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz issues?

On 10/17/2016 9:17 AM, Richards, Robert B. wrote:
> Is anyone else having issues doing a RFN from IBM's ShopzSeries?
>
> I get logged in and see the commands CCC followed by BINARY and then nothing. 
> Eventually it retries all 10 times and then fails.

I get something close - do you see:
FC1028 authServer: secure_socket_init failed with rc = 8 (Certificate 
validation error)

--
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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Shopz issues?

[Kurt Quackenbush]

On 10/17/2016 9:16 AM, Richards, Robert B. wrote:

Is anyone else having issues doing a RFN from IBM's ShopzSeries?

I get logged in and see the commands CCC followed by BINARY and then
nothing. Eventually it retries all 10 times and then fails.


Someone else reported similar behavior last week, so perhaps its 
related.  Verify the FTP.DATA file you're using has the following:


TLSRFCLEVEL   CCCNONOTIFY

For reference, see the SMP/E User's Guide:
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.gim3000/gim3115s.htm

Kurt Quackenbush -- IBM, SMP/E Development

--
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.

[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: Shopz issues?

[Jousma, David]

Yes. I ran one Monday morning.  I just now ran another, successfully.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Tuesday, October 18, 2016 8:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz issues?

Let me ask my question differently:

Is anyone *successfully* processing RECEIVEFROMNETWORK orders since Sunday's 
Shopz outage?

My firewall guy says that the FTP request was allowed to go out just fine. 

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Tuesday, October 18, 2016 5:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz issues?

No, I do not see that message. All I see prior to the CCC is:

virtual user S111 logged in from /205.131.188.10:51349

The port number is the only thing that has changed between attempts by me with 
a new submit.

Bob


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of George Davis
Sent: Monday, October 17, 2016 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz issues?

On 10/17/2016 9:17 AM, Richards, Robert B. wrote:
> Is anyone else having issues doing a RFN from IBM's ShopzSeries?
>
> I get logged in and see the commands CCC followed by BINARY and then nothing. 
> Eventually it retries all 10 times and then fails.

I get something close - do you see:
FC1028 authServer: secure_socket_init failed with rc = 8 (Certificate 
validation error)

--
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 IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
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. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

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.

[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
*
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]

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: Shopz issues?

[Blake, Daniel J [CTR]]

My weekly job ran successfully at 0600 today.


;-D an

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Tuesday, October 18, 2016 8:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz issues?

Let me ask my question differently:

Is anyone *successfully* processing RECEIVEFROMNETWORK orders since Sunday's 
Shopz outage?

My firewall guy says that the FTP request was allowed to go out just fine. 

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Tuesday, October 18, 2016 5:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz issues?

No, I do not see that message. All I see prior to the CCC is:

virtual user S111 logged in from /205.131.188.10:51349

The port number is the only thing that has changed between attempts by me with 
a new submit.

Bob


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of George Davis
Sent: Monday, October 17, 2016 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz issues?

On 10/17/2016 9:17 AM, Richards, Robert B. wrote:
> Is anyone else having issues doing a RFN from IBM's ShopzSeries?
>
> I get logged in and see the commands CCC followed by BINARY and then nothing. 
> Eventually it retries all 10 times and then fails.

I get something close - do you see:
FC1028 authServer: secure_socket_init failed with rc = 8 (Certificate 
validation error)

--
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 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]

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.

[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: ABO Automatic Binary Optimizer

[David Crayford]

On 18/10/2016 12:55 PM, Timothy Sipples wrote:

Bill Woodger wrote:

For me, changing any compile option at the moment of going to Production
invalidates all the testing up to that point.

Then along comes Java :-)


Good point well made.


I strongly disagree with the word "all." I don't think that word in this
sentence is grounded in a reasonable, rational, informed assessment of
comparative risks and testing costs.

Consider also this important point: many businesses are moving much, much
faster than this rigid point of view would ever allow. Take a look at this
2011 video, for example:

https://www.youtube.com/watch?v=dxk8b9rSKOo

The whole video is worth watching, but fast forward to about 10:00 for the
key statistics. According to the speaker, Amazon.com (the Web commerce
site, not all of AWS) deployed code changes into production on average once
every 11.6 seconds in May, 2011 (based on weekday deployments; they
evidently have a slower but still rapid deployment pace during weekends).
That was their pace half a decade ago. Are your current testing practices
and policies able to support that sort of business velocity or anything
vaguely similar? If not, why not? Are you helping your business compete? (I
believe at least a couple readers do work for businesses in competition
with Amazon.)

Amazon, the publicly traded company, has a market capitalization of $385.4
billion (as of October 17, 2016). Among companies traded on U.S. exchanges
it's currently #4 by that measure. True, its price-earnings ratio is over
200, i.e. the company isn't all that profitable. But that's yet another
problem if you're in competition with Amazon.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
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]

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.

[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 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 

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.

[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 message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / 

Re: ABO Automatic Binary Optimizer

[Bill Woodger]

We continue to add things to the bubbling pot that is a discussion started 
through the misunderstanding of some IBM sales staff. 

Tom Ross ventured close, dipped a spoon in the pot, and confirmed that there is 
no "source conversion" process for migration to V5/V6. Mmmm... he's either 
writing something very substantial, or he ain't coming back to this pot any 
time soon.

Sure, delivery needs to be addressed. 

But. COBOL isn't Java.

While a COBOL program is able to overwrite itself, or another program (there 
are limits, it can't trash storage it has no access to), you can't compare 
testing processes for COBOL to Java.

The generous levels of programmer-hand-holding in Java (and other "more modern" 
languages) don't exist beyond a bit of a shadow, or mist, or the intellectual 
satisfaction of "hah! Xyz! So that proves you wrong!".

I'm prepared to bet, and it is an entirely case to measure, or resolve, so even 
betting is useless, that around the world in, say, for every 10,000 Mainframe 
sites that there are at least 20,000 times a day, unique occasions, not the 
same storage, that storage is overwritten in Production COBOL systems. It 
happens "so often" because most often when it happens "it doesn't matter".

By "doesn't matter" I mean that the program completes normally, and all the 
test cases are passed, and all Production data is correctly processed. 
Actually, can't be definitive about that latter, wihch is the most important 
thing. If nothing else, the unintntional partial destruction of a program is at 
least a "symptom" of "something".

OK, arriving at the Door to Production (I've never known of it referred to as 
that, but what the heck?). You have one of these systems, and it has passed all 
the tests. You change a compile option which affects the generation of code, 
which means that what was being overwritten with impunity previuously is now 
safe, but something which actually matters after the overwiring has occured has 
now been... altered. Uunthinkingly, you toss it into Production.

The 10am presentation in the Board Room is arranged, you have people from the 
US and Asia who flying in, and out again, specially.

You know what is going to happen.

So what do you do in that situation? It's been through all the tests, and then 
it gets vommited out on its introduction to Production. Explain that away. As 
soon as you get to "and we did this...", whatever "this" is, anyone but the 
village idiot is going to ask "why did you do that" (referring to the "this", 
of course). Oh, and it much, much, worse if, instead of vomitting, there is 
mild nausea which goes undiscovered for a period of time.

So you don't just change compiler options, or the order of INCLUDEs in a 
linkedit deck (indeed, as Peter pointed out earlier, many sites push 
executables up the line, rather than recreating them at each stage).

20,000 only seems a lot in isolation (and it is an entirely invented figure, 
just to have a figure), it is tiny amongst the total, and the times that 
something turns from an innocuous to a vicious situation are tiny in comparison 
to 20,000. But it happens.

If you do just up and change a compile option, you have invalidated your 
testing. If you are going to go with it anyway (it wasn't my hypotherical 
scenario) then the risk in terms of possibility is very small, but in terms of 
potential impact may be immense. So, as well as going forward, you do what you 
can to be as sure as possible that the health of the system will be unimpeded. 
Do you feel happy yourself? No, you want to find out how you were strung up in 
that situation, and do what you can to make sure it can't, ever, happen again.

On the other side of the hill, an expression I use because I like it, not 
because of its confrontational connotations, there are "edge cases". An 
edge-case is something that's unlikely to happen, so you don't have to bother 
about it until it does happen. There are also "corner cases". A corner-case is 
a situation which is unlikely to happen, and even if it does you are not going 
to bother about it.

You don't bother so much about getting the technical details right, because 
usually (or at least in expectation) the language will do something to assist 
you. "Line 3491 array out of bounds". Which is nices, but which underlying code 
operates 24 hours a day, 365 days a year (plus leap seconds, days) whilst 
99.99% of the time it is unnecessary to have it checked automatically.

In passing, I hope no-one replies to this, else the topice gets even more 
convoluted, wide-ranging and unresolved.

--
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

Re: ABO Automatic Binary Optimizer

[Anne & Lynn Wheeler]

sipp...@sg.ibm.com (Timothy Sipples) writes:
> I strongly disagree with the word "all." I don't think that word in this
> sentence is grounded in a reasonable, rational, informed assessment of
> comparative risks and testing costs.

re:
http://manana.garlic.com/~lynn/2016f.html#91 ABO Automatic Binary Optimizer
http://manana.garlic.com/~lynn/2016f.html#92 ABO Automatic Binary Optimizer
http://manana.garlic.com/~lynn/2016f.html#97 ABO Automatic Binary Optimizer

I wrote a long tome on this 17Oct1980 for internal distribution
... about having single monolithic resource versus having huge number of
smaller resources capable of efficiently rolling in/roll back. They sent
somebody from Armonk corporate hdqtrs to slap my hands. I had already
had my hands slapped that summer ... being blamed for online computer
conferencing on the internal network (larger than arpanet/internet from
just about the beinning until sometime mid-80s). Folklore is that when
the corporate executive committee was told about online computer
communication (and the internal network), 5of6 wanted to fire me.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: ABO Automatic Binary Optimizer

[Jesse 1 Robinson]

"Happy families are all alike; every unhappy family is unhappy in its own way." 
While Wikipedia calls it the Anna Karenina Principle, it's not quite enough to 
substantiate the Russian claim that Tolstoy invented great literature.  It's 
still a vital lesson.

I would venture that there so many ways to screw up a COBOL program that no 
software mechanism could possible catch all of them, let alone correct them. 
Like a medieval cathedral that took generations to build, a 'classic' COBOL 
program has evolved through many cosmetic surgeries performed by many different 
hands with many different attitudes. Some scars are superficial. Some are 
systemic. The best news is that not all programs need to be converted at once. 
Go for the low hanging fruit; the biggest, sweetest ones that will feed the 
most mouths. Leave the rest for gleaners. There is no need to wait for a grand 
solution. 

.
.
.
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 Bill Woodger
Sent: Tuesday, October 18, 2016 2:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: ABO Automatic Binary Optimizer

We continue to add things to the bubbling pot that is a discussion started 
through the misunderstanding of some IBM sales staff. 

Tom Ross ventured close, dipped a spoon in the pot, and confirmed that there is 
no "source conversion" process for migration to V5/V6. Mmmm... he's either 
writing something very substantial, or he ain't coming back to this pot any 
time soon.

Sure, delivery needs to be addressed. 

But. COBOL isn't Java.

While a COBOL program is able to overwrite itself, or another program (there 
are limits, it can't trash storage it has no access to), you can't compare 
testing processes for COBOL to Java.

The generous levels of programmer-hand-holding in Java (and other "more modern" 
languages) don't exist beyond a bit of a shadow, or mist, or the intellectual 
satisfaction of "hah! Xyz! So that proves you wrong!".

I'm prepared to bet, and it is an entirely case to measure, or resolve, so even 
betting is useless, that around the world in, say, for every 10,000 Mainframe 
sites that there are at least 20,000 times a day, unique occasions, not the 
same storage, that storage is overwritten in Production COBOL systems. It 
happens "so often" because most often when it happens "it doesn't matter".

By "doesn't matter" I mean that the program completes normally, and all the 
test cases are passed, and all Production data is correctly processed. 
Actually, can't be definitive about that latter, wihch is the most important 
thing. If nothing else, the unintntional partial destruction of a program is at 
least a "symptom" of "something".

OK, arriving at the Door to Production (I've never known of it referred to as 
that, but what the heck?). You have one of these systems, and it has passed all 
the tests. You change a compile option which affects the generation of code, 
which means that what was being overwritten with impunity previuously is now 
safe, but something which actually matters after the overwiring has occured has 
now been... altered. Uunthinkingly, you toss it into Production.

The 10am presentation in the Board Room is arranged, you have people from the 
US and Asia who flying in, and out again, specially.

You know what is going to happen.

So what do you do in that situation? It's been through all the tests, and then 
it gets vommited out on its introduction to Production. Explain that away. As 
soon as you get to "and we did this...", whatever "this" is, anyone but the 
village idiot is going to ask "why did you do that" (referring to the "this", 
of course). Oh, and it much, much, worse if, instead of vomitting, there is 
mild nausea which goes undiscovered for a period of time.

So you don't just change compiler options, or the order of INCLUDEs in a 
linkedit deck (indeed, as Peter pointed out earlier, many sites push 
executables up the line, rather than recreating them at each stage).

20,000 only seems a lot in isolation (and it is an entirely invented figure, 
just to have a figure), it is tiny amongst the total, and the times that 
something turns from an innocuous to a vicious situation are tiny in comparison 
to 20,000. But it happens.

If you do just up and change a compile option, you have invalidated your 
testing. If you are going to go with it anyway (it wasn't my hypotherical 
scenario) then the risk in terms of possibility is very small, but in terms of 
potential impact may be immense. So, as well as going forward, you do what you 
can to be as sure as possible that the health of the system will be unimpeded. 
Do you feel happy yourself? No, you want to find out how you were strung up in 
that situation, and do what you can to make sure it can't, ever, 

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.

[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: diagnose 8 / interesting dilemma

[Paul Gilmartin]

On Mon, 17 Oct 2016 10:08:50 -0700, Ed Jaffe wrote:
>>
>> Hmmm... What happens if AMODE 31 code issues LRA and the real address
>> is above the bar?  Program check?  Or does LRA simply (always?) load a
>> 64-bit register?  Is there an LRAG instruction?
>
>Why not take at least a cursory glance at Principles of Operation before
>asking such questions publicly?
> 
You're right; thanks.  GIMF.  (Oops; the Urban Dictionary says that doesn't
mean what I expected.)  I find:
z/OS 2.2.0
z/OS MVS
z/OS MVS Programming: Assembler Services Guide
Understanding 31-bit addressing
Understanding the use of central storage
Central storage considerations for user programs
Load real address (LRA) instruction

Woe be unto anyone who did LRA; LA in AMODE 24  (But why?.  And it
doesn't discuss AR mode.  Perhaps elsewhere, but my curiosity is exhausted.

Which leaves a historical question.  Was AMODE 31 antedated by the
availability of real storage >16 MiB, or was AMODE 64 antedated by
the availability of real storage >2GiB?  How did LRA(G) operate in
those eras?

And in a virtual guest with shadow page tables, does LRA return the
real real address or a virtual real address?  I suppose it's all emulated
by CP anyway, so it depends.  Or maybe SIE.  My head hurts.

Thanks,
gil

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

Re: diagnose 8 / interesting dilemma

[Tony Harminc]

On 18 October 2016 at 13:15, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>   I find:
> z/OS 2.2.0
> z/OS MVS
> z/OS MVS Programming: Assembler Services Guide
> Understanding 31-bit addressing
> Understanding the use of central storage
> Central storage considerations for user programs
> Load real address (LRA) instruction

As suggested, you need to look at the Principles of Operation. LRA is
a matter of hardware, not MVS. Of course the MVS environment
potentially affects some things, but LRA is entirely defined by the
hardware.

> Woe be unto anyone who did LRA; LA in AMODE 24  (But why?.  And it
> doesn't discuss AR mode.  Perhaps elsewhere, but my curiosity is exhausted.

POO.

> Which leaves a historical question.  Was AMODE 31 antedated by the
> availability of real storage >16 MiB,

Assuming you mean the hardware addressing mode, rather than the MVS
Assembler and Binder's notion of AMODE for modules, Yes. But in a
quirky way. In the pre-XA era, there was a time when 64 MB of real
storage could be addressed by DAT tables, but not by channels or
instructions running with DAT off.

> or was AMODE 64 antedated by the availability of real storage >2GiB?

How is this an "or"? You sound like a lawyer at bar: "My client did
not kill Mr X, or in the alternative, if he did kill Mr X he did it
with justification." Maybe I just need to apply De Morgan to your
sentence...

> How did LRA(G) operate in those eras?

LRA provided a 26-bit real address (padded on the left to 32 bits) in
the 64 MiB era.

> And in a virtual guest with shadow page tables, does LRA return the
> real real address or a virtual real address?

Always a virtual real address.

> I suppose it's all emulated by CP anyway, so it depends.

No, it doesn't depend. What sense would it make to return a real real
address to LRA? If you want a real real address you need to use a
conceptually different level of query; a meta-query, one might say.
Normally this would be a Diagnose.

> Or maybe SIE.  My head hurts.

With (XA+) or without (370 pre-XA) SIE, the result is the same. With
SIE it's all handled by the "hardware". Pre SIE, since LRA is
privileged, and the guest always runs in real problem state, CP
provides the answer.

Tony H.

--
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

IBM and z/OS OpenSSH

[Jack J. Woehr]

If this question is inappropriate, please excuse me, but I would like to know 
who can give me an answer.

I've been involved with IBM big iron for 22 years. I've been involved with 
OpenBSD/OpenSSH for about 18 years.

OpenSSH is used mission-critically on z/OS. OpenSSH comes from the OpenBSD 
project.

It is my understanding that Microsoft has given meaningful financial support to the OpenBSD project in appreciation of 
OpenSSH.


It is my understanding that IBM has never made any contribution to the OpenBSD 
project, neither hardware nor financial. The
OpenSSH mailing lists nonetheless continue to support consultants and IBM ISV's 
tuning OpenSSH on z/OS on a regular basis.

I am wondering who one would lobby in IBM's z/OS operation to attempt to persuade IBM to 
remedy this "oversight" :)

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

HMC CPC Image

[Steely.Mark]

I have created a new CPC image. When I click on the icon and then double click 
on Customize/Delete Activation Profiles only the DEFAULTLOAD Profile is 
displayed. How do I create an Image profile for this LPAR. 

Any help would be appreciated.

Thanks

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

Re: HMC CPC Image

[Feller, Paul]

If your new CPC (CEC) is a replacement of a current CPC you could have IBM copy 
the LPAR profiles over for you.  

If this is a new CPC (not replacing anything) I would first load the IOCDS you 
plan on using.  If I remember correctly a default lpar profile will get built.  
You can then customize the profile to what you need.

I think there is also a new function/script to help build LPAR profiles.  Sorry 
I'm not sitting in front of an HMC to give you details.

Thanks..

Paul Feller
AGT Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steely.Mark
Sent: Tuesday, October 18, 2016 16:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: HMC CPC Image

I have created a new CPC image. When I click on the icon and then double click 
on Customize/Delete Activation Profiles only the DEFAULTLOAD Profile is 
displayed. How do I create an Image profile for this LPAR. 

Any help would be appreciated.

Thanks

--
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: Looking for New Function APARs across the entire z/OS platform?

[Ed Jaffe]

On 10/18/2016 2:10 PM, Bill Woodger wrote:

What is SPE? I'm sorry if I appear naive on that, but search-engineing comes up with 
"IBM Standards Processing Engine" which probably isn't what your SPE means.


SPE = Small Programming Enhancement.

In the old days SPEs were considered evil because "small" really means 
"large" (when compared with a typical PTF). Therefore, the chances of 
the SYSMOD going PE were orders of magnitude greater than a typical PTF.


PE implies HOLD(ERROR), which prevents later service from being applied.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: HMC CPC Image

[Steely.Mark]

I did load the IOCDS and that’s what I got was a default profile. I need to 
build an image profile for that LPAR.

Thanks

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Feller, Paul
Sent: Tuesday, October 18, 2016 4:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HMC CPC Image

If your new CPC (CEC) is a replacement of a current CPC you could have IBM copy 
the LPAR profiles over for you.  

If this is a new CPC (not replacing anything) I would first load the IOCDS you 
plan on using.  If I remember correctly a default lpar profile will get built.  
You can then customize the profile to what you need.

I think there is also a new function/script to help build LPAR profiles.  Sorry 
I'm not sitting in front of an HMC to give you details.

Thanks..

Paul Feller
AGT Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steely.Mark
Sent: Tuesday, October 18, 2016 16:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: HMC CPC Image

I have created a new CPC image. When I click on the icon and then double click 
on Customize/Delete Activation Profiles only the DEFAULTLOAD Profile is 
displayed. How do I create an Image profile for this LPAR. 

Any help would be appreciated.

Thanks

--
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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: HMC CPC Image

[Matthew Stitt]

Just start customizing the default profile(s) shown.  Change everything you 
can, including the name of the profile.  The default profile you are editing 
will not change, and a new profile with the new name will be created.

Matthew

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

Looking for New Function APARs across the entire z/OS platform?

[Marna WALLE]

Hello IBM-MAINers,
With IBM using continuous delivery across the entire z/OS platform and in many 
cases introducing new functions within the service stream, there are now two 
ways to quickly learn about those APARs (aka SPEs):

1) Subscribe to receive notification of those APARs right after the APAR 
closes, via email or subscription list.  See WSC Techdoc 
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS5188 for 
information on how to do this.  

2) Refer to the website for a "history" of closed APARs, available in HTML ad 
CSV formats.  See 
http://www.ibm.com/systems/z/os/zos/installation/zosnfapars.html .   There are 
details on this website on what is included in this "history".

Of course, you still will want to watch for product announcements, but these 
two ways are nice in that you can see New Function APARs in a consolidated 
manner.  We are hoping that these two methods will help you find new functions 
in a helpful way.  If you have any comments about this,  please respond here, 
or email me if you prefer.

-Marna WALLE
z/OS System Installation, IBM Poughkeepsie

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

Re: ABO Automatic Binary Optimizer

[Bill Woodger]

Yes, let's add Literature into the pot as well...

The thing is, once a COBOL program is compiled, it is no longer a COBOL 
program. It is no longer at the whim of a misplaced full-stop (period), 
oblivious to whether a SECTION has been coded or a THRU has been used, the GO 
TO superficially indistinguishable from a "leg" of a condition, the magic which 
operates when a 12-integer-3-decimal-place packed-decimal is MOVEd to a 
zoned-decimal integer, a floating-point item and an identically-described 
subscripted item.

Poof! In about the same time it takes to compile a program, it has been 
compiled, and is now sitting as a bunch of machine-code, with some data ranged 
in ordered manner. Now it is machine-code, it is coincidental that it was once 
COBOL, except that because it once was COBOL, and has been compiled, there is a 
shed-load of defined information about it, and another shed-load or two of 
information that can be intuited, and a further amount, which I can't relate to 
in terms of sheds (is it one, three hundred, 0.002?) because it is machine-code 
and because there's maybe something that can be done to it (turn it into an 
intermediate form, let's call it an Intermediate Result, for the heck of it) 
and then, the IR can be modified in a cyclic process which, at each change, 
contains a "proof" that the state is unchanged.

Once no more can be done with the IR, compile that. Now it's machine-code 
again. Some final touches, a bit of low-level (unverified?) optimisation 
(including perhaps killing that vital "return" from that "stupid PERFORM", my 
guess) and you have a new program which, to some extent, to be determined, 
"does the same thing" as the original.

Things projected for the future of ABO:

1) It is not going away. Since nowhere near all programs are changed even over 
a long period of years, ABO will be available to "soup up" (great, now I have 
soup and stock, bring in the cookery to the topic as well) things and not 
require the work to "recompile".
2) It is not going away. When V7 comes (so it is already in the works) ABO will 
be available for V5/V6 program stock, as well as all the others it supports. 
3) In some future it may also be able to "profile on the fly", providing 
further performance improvements revealed by the actual interaction between 
program and data consumed. A different run, with different data, may obtain 
different improvements if the profiling dictates.
4) Other stuff.

So, yes, Martin Packer's point of the ABO "team" providing a lot more 
information, so that things like "how do we test something which is ABO'd?" can 
be discussed *in the terms of what the thing does* not because "remember Java" 
or "xyz is unrealistic". Without knowledge, everything is speculation, 
effectively, which could be located in any local bar, and have the same quality 
of content and result.

So, literature, cookery, woodworking, horse racing, cricket (should have put 
that first), let's get them all in here - without information, we may as well 
:-)

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

Re: Looking for New Function APARs across the entire z/OS platform?

[Bill Woodger]

That sounds good, but "continuous delivery", beyond fashion-speak, means 
specifically what? DFSORT used to provide new functionality through PTFs. Does 
it mean that, and at a faster pace and in smaller units, or something, 
specifically, different?

And whatever it is, is it across all products (as in "OS" and "applications" 
IBM provides), within certain products/areas, something else? Is it an 
"emerging concept, we've just started running with it, and we'll see where it 
takes us, so can't exactly answer" or something more "planned"?

I'm not trying to be negative, but until your use of "continuous delivery" is 
known, it can mean anything, so means nothing. Currently it is one of those 
phrases I just "cross out" when encountering it, without it detracting from 
information content. "Service delivery" is another.

What is SPE? I'm sorry if I appear naive on that, but search-engineing comes up 
with "IBM Standards Processing Engine" which probably isn't what your SPE means.

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

Re: HMCS consoles

[Barbara Nitz]

>The real question is whether dynamic _deletion_ and subsequent
>_replacement_ of a wrongly-defined IPL-time HMCS specification will
>work. On the surface it seems like it ought to work, but I think there's
>a reasonable chance it won't...

Well, it does. :-) The only surprise was that I had to issue the SETCON DELETE 
command on the system the HMCS console was attached to. I had thought that 
since console definitions are sysplex in scope, I could issue the command 
anywhere in the plex and have it internally routed to the system the console is 
attached to. But that's not a problem.
So I deleted the console named HMCS, did a SET CON=xx on the system HMCS was 
formerly defined to, and voila, a subsequent d c,f,cn=(name) was showing me the 
newly named HMCS in standby mode.

Oh, and by the way - I erroneously did the t con=xx *before* deleting the 
console named HMCS. Apparently there can be only one HMCS console on any one 
system, because the second name, HMCS, did not show up until I had 
deleted the HMCS console named HMCS.

Problem solved.

Barbara

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

Re: Looking for New Function APARs across the entire z/OS platform?

[Bill Woodger]

Thanks Ed, that helps. So a typical "old style" PTF for DFSORT, which added 
several new functions to the product would have been an SPE, either by name or 
by fact. 

And, even with the OS on a two-year release cycle, new functions (for anything) 
can be provided (delivered) at any point (continuously) without having to wait 
for X months for the new release. That's good.

It'll keep many contributors here busy, even if IBM doesn't manage the "update 
every 11.6 seconds" of Amazon :-) 

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

Re: HMC CPC Image

[Steely.Mark]

When I did that it created another load profile - I need an image profile. 

Thanks

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Matthew Stitt
Sent: Tuesday, October 18, 2016 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HMC CPC Image

Just start customizing the default profile(s) shown.  Change everything you 
can, including the name of the profile.  The default profile you are editing 
will not change, and a new profile with the new name will be created.

Matthew

--
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: Shopz issues?

[Kurt Quackenbush]

We had been running with RFC4217 up to now and it was working.

Regardless, per your recommendation (and the manual), I changed it to 
CCCNONOTIFY.

Voila! All is well with the RFN world once again, I owe Kurt another virtual 
drink of his choice.


Glad its working for you now.

I should have also mentioned that instead of using FTPS you (and 
everyone else too) could have used HTTPS which has no FTP.DATA-like file 
full of confusing and conflicting options, and avoids typical FTPS 
firewall issues as a bonus.


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: HMC CPC Image

[Jesse 1 Robinson]

You should have an Image profile called DEFAULT. Click on that one to 
Customize. Give it the exact name of your LPAR. Set CPU, storage, and other 
values that you want. When you Save it, you will have created an Image profile 
for that LPAR. Repeat the process for as many LPARs as you want to define. 

As an alternative, if you are replicating an existing CEC with all the same 
LPARs, you can Export profiles from the old CEC and Import them to the new one. 
Kill all birds with one (or couple of) stones. See my SHARE Bit Bucket pitch:

https://share.confex.com/share/121/webprogram/Handout/Session13568/Bit_Bucket_x2D.pdf

.
.
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 Steely.Mark
Sent: Tuesday, October 18, 2016 2:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: HMC CPC Image

I did load the IOCDS and that’s what I got was a default profile. I need to 
build an image profile for that LPAR.

Thanks

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Feller, Paul
Sent: Tuesday, October 18, 2016 4:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HMC CPC Image

If your new CPC (CEC) is a replacement of a current CPC you could have IBM copy 
the LPAR profiles over for you.  

If this is a new CPC (not replacing anything) I would first load the IOCDS you 
plan on using.  If I remember correctly a default lpar profile will get built.  
You can then customize the profile to what you need.

I think there is also a new function/script to help build LPAR profiles.  Sorry 
I'm not sitting in front of an HMC to give you details.

Thanks..

Paul Feller
AGT Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steely.Mark
Sent: Tuesday, October 18, 2016 16:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: HMC CPC Image

I have created a new CPC image. When I click on the icon and then double click 
on Customize/Delete Activation Profiles only the DEFAULTLOAD Profile is 
displayed. How do I create an Image profile for this LPAR. 

Any help would be appreciated.

Thanks


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

Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)

[Tony Harminc]

On 18 October 2016 at 18:27, Peter Hunkeler  wrote:
> Below discussion triggered a question I could not answer by RTFM. I had never 
> thought about this before in this detail,
> but now that I do, I wonder if the following is correct.
>
> Program allocates >4k of virtual storage. The real frames backing it may or 
> may not be contiguous. The program wants to
> use this area with some interface (I/O, etc) that will use real addresses 
> when accessing the storage, so it does a PGFIX.
> PGFIX would move the possibly non-contiguous frames guaranteeing the area is 
> backed by contiguous frames. After all,
> the interface using real addresses would expect the the frames to be 
> contiguous.
>
> Am I wrong? I would have expected to find this documented with the PGFIX or 
> PGSER FIX macros, but did not find it.

I do not believe there is such a service documented. As Jim Mulder
pointed out, there are 1M pages available above the bar, but that's
relatively new stuff. And there are unexposed RSM services to manage
pairs of frames (and quads, I think he said).

If you want to do I/O to your real storage, that is what IDAWs are
for. Perhaps there are undocumented (or at least not publicly
documented) IBM facilities -- I'm guessing things like crypto,
compression, newer non traditional I/O -- that take real addresses and
need more than a page at a time, but I don't know of any. In this
sense, VM's Diagnose interface is an outlier.

Tony H.

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

Re: Looking for New Function APARs across the entire z/OS platform?

[Jesse 1 Robinson]

You generally have the option to delay installing an SPE for some time if you 
don't want the new function. As Ed said, because an SPE is actually 'big', 
there's more chance for PEs to crop up than for individual narrower-scope PTFs. 
But eventually you pretty much have to install an SPE because some other 
maintenance will PRE or COREQ it. Unless you install the SPE, you will 
accumulate an ever growing chain of PTFs, some maybe HIPER even though not 
directly related to the new SPE function. By that time, however, most of the 
egregious bugs in the SPE should have fixes available as well. 

While there is no 'free' lunch, there are seemingly free lunches that you have 
to pay for later. 

.
.
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 Bill Woodger
Sent: Tuesday, October 18, 2016 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Looking for New Function APARs across the entire z/OS 
platform?

Thanks Ed, that helps. So a typical "old style" PTF for DFSORT, which added 
several new functions to the product would have been an SPE, either by name or 
by fact. 

And, even with the OS on a two-year release cycle, new functions (for anything) 
can be provided (delivered) at any point (continuously) without having to wait 
for X months for the new release. That's good.

It'll keep many contributors here busy, even if IBM doesn't manage the "update 
every 11.6 seconds" of Amazon :-) 


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

Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)

[Peter Hunkeler]

Below discussion triggered a question I could not answer by RTFM. I had never 
thought about this before in this detail, but now that I do, I wonder if the 
following is correct.

Program allocates >4k of virtual storage. The real frames backing it may or may 
not be contiguous. The program wants to use this area with some interface (I/O, 
etc) that will use real addresses when accessing the storage, so it does a 
PGFIX. PGFIX would move the possibly non-contiguous frames guaranteeing the 
area is backed by contiguous frames. After all, the interface using real 
addresses would expect the the frames to be contiguous. 
 

Am I wrong? I would have expected to find this documented with the PGFIX or 
PGSER FIX macros, but did not find it.  


--
Peter Hunkeler





 
On 10/17/2016 08:23 AM, Paul Schuster wrote: 
> I am issuing DIAGNOSE 8 on my z/os image under VM (z/vm) to do a QUERY 
> VIRTUAL DASD.  It works—up to a certain point: 
>  
> The QUERY VIRTUAL DASD command returns (for me) 38617 (decimal) bytes, 
> according to the CC=0 after the DIAGNOSE 8 command.  My buffer is large 
> enough to accommodate this.  I have tried several different sub-pools of 
> storage.  I PGSER FIX the buffer pages.  I do a SYSEVENT DONTSWAP.  I do a 
> LRA of the virtual address of the start of the buffer.  The DIAGNOSE 
> completes CC=0. But, in my buffer, I am only seeing the first page (4095) 
> bytes of the output.   
>  
> My question: I don’t see any documented restriction in the VM manuals that 
> limits the DIAGNOSE 8 output buffer to 4K (rather the limitation is the 
> architecture limit depending on your amode.) The z/vm manuals say the buffer 
> can cross page boundaries.  So is there a way to force the real storage 
> addresses of the page-fixed pages to be consecutive?  According to the 
> diagnose 8 doc., the buffer needs to be in guest-real storage, hence the LRA. 
>  And it is working for the first 4k page. 
>  
> Thank you for any insight you can provide.  
 
As you already guessed, the memory you get is virtual, so the pages are not 
consecutive. The LRA will give you the address of the first page, but the 2nd, 
3rd and so on will be somewhere else. Please note that your code will even 
cause random memory overwrites in your z/OS as the diag8 will write to the real 
address of your LRA, the real address of your LRA+4096 and so on. 
 


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

Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)

[Paul Gilmartin]

On Tue, 18 Oct 2016 19:34:10 -0400, Tony Harminc wrote:
>
>If you want to do I/O to your real storage, that is what IDAWs are
>for. Perhaps there are undocumented (or at least not publicly
>documented) IBM facilities -- I'm guessing things like crypto,
>compression, newer non traditional I/O -- that take real addresses and
>need more than a page at a time, but I don't know of any. In this
>sense, VM's Diagnose interface is an outlier.
> 
I understand that for some time IEBCOPY could not deal with VIO because
IEBCOPY dealt only with real addresses and VIO dealt only with virtual
addresses.  I was slightly surprised when the conflict was resolved by
modifying VIO rather than IEBCOPY.  I suppose this required something
like an inverse LRA.

-- gil

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

Re: Looking for New Function APARs across the entire z/OS platform?

[Paul Gilmartin]

On Tue, 18 Oct 2016 14:18:57 -0700, Ed Jaffe wrote:
>
>SPE = Small Programming Enhancement.
>
>In the old days SPEs were considered evil because "small" really means
>"large" (when compared with a typical PTF). Therefore, the chances of
>the SYSMOD going PE were orders of magnitude greater than a typical PTF.
> 
They may be called "small" in order to allow bypassing some process
requirements, whether the supplier's or the customer's.

>PE implies HOLD(ERROR), which prevents later service from being applied.
>
That applies only to later service that depends on the PE/SPE.

A conscientious vendor will try when practical to craft later corrective service
so as not to depend on recent SPEs.

And the PTF that resolves a PE may depend on the PE PTF, particularly when
the PE PTF is large and a small corrective PTF is sufficient.

-- gil

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