subject:"CSVFETCH exit"

Re: CSVFETCH exit

2016-03-24 Thread Vernooij, CP (ITOPT1) - KLM

In fact, I use LLA exit1, not exit2, because exit1 has the details of each 
fetch.

Kees.

-Original Message-
From: Vernooij, CP (ITOPT1) - KLM 
Sent: 24 March, 2016 8:23
To: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
Subject: RE: CSVFETCH exit

Leo,

We move the modules to a LNKLST library, so we are sure they are seen by LLA 
when they are fetched.
Yes, CSVFETCH has more capabilities, but just for the task of catching certain, 
old, modules, the LLA trick is more simple.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: 23 March, 2016 18:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Kees,
The exit is called with the local lock held, so BPX4SMF wouldn't work, I 
couldn't find the requirements for SMFWTM but if that also doesn't like the 
exit's environment I guess you would have to do something like writing 
information to a dataspace and then get the data using another address space. 
Definitely more complex than what you have now.

But you are comparing two different things; for example, CSVFETCH would get 
control if a user is fetching a module by steplib/joblib, which LLA EXIT2 
wouldn't do. So your current solution doesn’t "determine if certain loadmodules 
are still being used", but rather if they are being fetched using LLA.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Wednesday, March 23, 2016 11:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

To determine if certain loadmodules are still being used, we use LLA EXIT2 
since decades.
We move the modules to a special LNKLST library, monitor with LLA EXIT2 fetches 
from this library and write an SMF record for the event.
CSVFETCH apparently is able to catch more loads, provide more info, but also 
seems more complicated to use. 
As to the question, what can you do with the information CSVFETCH makes 
available: can I write an SMF record from CSVFETCH?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: 21 March, 2016 14:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I have a different question relative to this exit.

I've been looking for doc on line and have found two manuals that have CSVFETCH 
as an exit point defined, and one has the parm area info.

Peter did a presentation last week, and unfortunately for me, I had a hard 
conflict and couldn't attend, but I did get the "slide deck" and listened to 
the recording this morning.

There is a question that I have, and hopefully someone here will have the 
answer (We have not yet set up 2.2 on a test LPAR, but we have it on a sandbox 
LPAR where I can play with it):

Will a "fetch" of a CLIST or REXX be caught by this exit?

At this point, I have not seen how one could tell a executable module from a 
"script" (script because one might need this on the POSIX side of the system).

I could see using this exit in place of the SMF type 32 (with its overhead and 
tables in common...).

Meanwhile, I see where this exit could help a shop determine what obsolete 
subroutines are being used in production...

Regards,
Steve Thompson

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

Re: CSVFETCH exit

2016-03-24 Thread Leonardo Vaz

Ok! Thanks for the clarification!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Thursday, March 24, 2016 10:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

We use it for modules under our control, so we know the only version is in this 
specific library.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: 24 March, 2016 15:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Still, you wouldn't know if the old module is still being used from a (non-LLA) 
steplib, right? Am I missing something?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Thursday, March 24, 2016 3:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Leo,

We move the modules to a LNKLST library, so we are sure they are seen by LLA 
when they are fetched.
Yes, CSVFETCH has more capabilities, but just for the task of catching certain, 
old, modules, the LLA trick is more simple.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: 23 March, 2016 18:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Kees,
The exit is called with the local lock held, so BPX4SMF wouldn't work, I 
couldn't find the requirements for SMFWTM but if that also doesn't like the 
exit's environment I guess you would have to do something like writing 
information to a dataspace and then get the data using another address space. 
Definitely more complex than what you have now.

But you are comparing two different things; for example, CSVFETCH would get 
control if a user is fetching a module by steplib/joblib, which LLA EXIT2 
wouldn't do. So your current solution doesn’t "determine if certain loadmodules 
are still being used", but rather if they are being fetched using LLA.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Wednesday, March 23, 2016 11:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

To determine if certain loadmodules are still being used, we use LLA EXIT2 
since decades.
We move the modules to a special LNKLST library, monitor with LLA EXIT2 fetches 
from this library and write an SMF record for the event.
CSVFETCH apparently is able to catch more loads, provide more info, but also 
seems more complicated to use. 
As to the question, what can you do with the information CSVFETCH makes 
available: can I write an SMF record from CSVFETCH?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: 21 March, 2016 14:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I have a different question relative to this exit.

I've been looking for doc on line and have found two manuals that have CSVFETCH 
as an exit point defined, and one has the parm area info.

Peter did a presentation last week, and unfortunately for me, I had a hard 
conflict and couldn't attend, but I did get the "slide deck" and listened to 
the recording this morning.

There is a question that I have, and hopefully someone here will have the 
answer (We have not yet set up 2.2 on a test LPAR, but we have it on a sandbox 
LPAR where I can play with it):

Will a "fetch" of a CLIST or REXX be caught by this exit?

At this point, I have not seen how one could tell a executable module from a 
"script" (script because one might need this on the POSIX side of the system).

I could see using this exit in place of the SMF type 32 (with its overhead and 
tables in common...).

Meanwhile, I see where this exit could help a shop determine what obsolete 
subroutines are being used in production...

Regards,
Steve Thompson

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

Re: CSVFETCH exit

2016-03-24 Thread Vernooij, CP (ITOPT1) - KLM

We use it for modules under our control, so we know the only version is in this 
specific library.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: 24 March, 2016 15:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Still, you wouldn't know if the old module is still being used from a (non-LLA) 
steplib, right? Am I missing something?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Thursday, March 24, 2016 3:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Leo,

We move the modules to a LNKLST library, so we are sure they are seen by LLA 
when they are fetched.
Yes, CSVFETCH has more capabilities, but just for the task of catching certain, 
old, modules, the LLA trick is more simple.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: 23 March, 2016 18:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Kees,
The exit is called with the local lock held, so BPX4SMF wouldn't work, I 
couldn't find the requirements for SMFWTM but if that also doesn't like the 
exit's environment I guess you would have to do something like writing 
information to a dataspace and then get the data using another address space. 
Definitely more complex than what you have now.

But you are comparing two different things; for example, CSVFETCH would get 
control if a user is fetching a module by steplib/joblib, which LLA EXIT2 
wouldn't do. So your current solution doesn’t "determine if certain loadmodules 
are still being used", but rather if they are being fetched using LLA.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Wednesday, March 23, 2016 11:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

To determine if certain loadmodules are still being used, we use LLA EXIT2 
since decades.
We move the modules to a special LNKLST library, monitor with LLA EXIT2 fetches 
from this library and write an SMF record for the event.
CSVFETCH apparently is able to catch more loads, provide more info, but also 
seems more complicated to use. 
As to the question, what can you do with the information CSVFETCH makes 
available: can I write an SMF record from CSVFETCH?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: 21 March, 2016 14:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I have a different question relative to this exit.

I've been looking for doc on line and have found two manuals that have CSVFETCH 
as an exit point defined, and one has the parm area info.

Peter did a presentation last week, and unfortunately for me, I had a hard 
conflict and couldn't attend, but I did get the "slide deck" and listened to 
the recording this morning.

There is a question that I have, and hopefully someone here will have the 
answer (We have not yet set up 2.2 on a test LPAR, but we have it on a sandbox 
LPAR where I can play with it):

Will a "fetch" of a CLIST or REXX be caught by this exit?

At this point, I have not seen how one could tell a executable module from a 
"script" (script because one might need this on the POSIX side of the system).

I could see using this exit in place of the SMF type 32 (with its overhead and 
tables in common...).

Meanwhile, I see where this exit could help a shop determine what obsolete 
subroutines are being used in production...

Regards,
Steve Thompson

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

Re: CSVFETCH exit

2016-03-24 Thread Leonardo Vaz

Still, you wouldn't know if the old module is still being used from a (non-LLA) 
steplib, right? Am I missing something?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Thursday, March 24, 2016 3:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Leo,

We move the modules to a LNKLST library, so we are sure they are seen by LLA 
when they are fetched.
Yes, CSVFETCH has more capabilities, but just for the task of catching certain, 
old, modules, the LLA trick is more simple.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: 23 March, 2016 18:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Kees,
The exit is called with the local lock held, so BPX4SMF wouldn't work, I 
couldn't find the requirements for SMFWTM but if that also doesn't like the 
exit's environment I guess you would have to do something like writing 
information to a dataspace and then get the data using another address space. 
Definitely more complex than what you have now.

But you are comparing two different things; for example, CSVFETCH would get 
control if a user is fetching a module by steplib/joblib, which LLA EXIT2 
wouldn't do. So your current solution doesn’t "determine if certain loadmodules 
are still being used", but rather if they are being fetched using LLA.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Wednesday, March 23, 2016 11:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

To determine if certain loadmodules are still being used, we use LLA EXIT2 
since decades.
We move the modules to a special LNKLST library, monitor with LLA EXIT2 fetches 
from this library and write an SMF record for the event.
CSVFETCH apparently is able to catch more loads, provide more info, but also 
seems more complicated to use. 
As to the question, what can you do with the information CSVFETCH makes 
available: can I write an SMF record from CSVFETCH?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: 21 March, 2016 14:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I have a different question relative to this exit.

I've been looking for doc on line and have found two manuals that have CSVFETCH 
as an exit point defined, and one has the parm area info.

Peter did a presentation last week, and unfortunately for me, I had a hard 
conflict and couldn't attend, but I did get the "slide deck" and listened to 
the recording this morning.

There is a question that I have, and hopefully someone here will have the 
answer (We have not yet set up 2.2 on a test LPAR, but we have it on a sandbox 
LPAR where I can play with it):

Will a "fetch" of a CLIST or REXX be caught by this exit?

At this point, I have not seen how one could tell a executable module from a 
"script" (script because one might need this on the POSIX side of the system).

I could see using this exit in place of the SMF type 32 (with its overhead and 
tables in common...).

Meanwhile, I see where this exit could help a shop determine what obsolete 
subroutines are being used in production...

Regards,
Steve Thompson

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

Re: CSVFETCH exit

2016-03-24 Thread Vernooij, CP (ITOPT1) - KLM

Leo,

We move the modules to a LNKLST library, so we are sure they are seen by LLA 
when they are fetched.
Yes, CSVFETCH has more capabilities, but just for the task of catching certain, 
old, modules, the LLA trick is more simple.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: 23 March, 2016 18:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Kees,
The exit is called with the local lock held, so BPX4SMF wouldn't work, I 
couldn't find the requirements for SMFWTM but if that also doesn't like the 
exit's environment I guess you would have to do something like writing 
information to a dataspace and then get the data using another address space. 
Definitely more complex than what you have now.

But you are comparing two different things; for example, CSVFETCH would get 
control if a user is fetching a module by steplib/joblib, which LLA EXIT2 
wouldn't do. So your current solution doesn’t "determine if certain loadmodules 
are still being used", but rather if they are being fetched using LLA.

Regards,
Leo



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Wednesday, March 23, 2016 11:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

To determine if certain loadmodules are still being used, we use LLA EXIT2 
since decades.
We move the modules to a special LNKLST library, monitor with LLA EXIT2 fetches 
from this library and write an SMF record for the event.
CSVFETCH apparently is able to catch more loads, provide more info, but also 
seems more complicated to use. 
As to the question, what can you do with the information CSVFETCH makes 
available: can I write an SMF record from CSVFETCH?

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: 21 March, 2016 14:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I have a different question relative to this exit.

I've been looking for doc on line and have found two manuals that have CSVFETCH 
as an exit point defined, and one has the parm area info.

Peter did a presentation last week, and unfortunately for me, I had a hard 
conflict and couldn't attend, but I did get the "slide deck" and listened to 
the recording this morning.

There is a question that I have, and hopefully someone here will have the 
answer (We have not yet set up 2.2 on a test LPAR, but we have it on a sandbox 
LPAR where I can play with it):

Will a "fetch" of a CLIST or REXX be caught by this exit?

At this point, I have not seen how one could tell a executable module from a 
"script" (script because one might need this on the POSIX side of the system).

I could see using this exit in place of the SMF type 32 (with its overhead and 
tables in common...).

Meanwhile, I see where this exit could help a shop determine what obsolete 
subroutines are being used in production...

Regards,
Steve Thompson

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

Re: CSVFETCH exit

2016-03-23 Thread Charles Mills

Exactly. That is what I was referring to. I have done it a lot. I have/had a
client for whom I developed a series of executables using this method.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Wednesday, March 23, 2016 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

> Peter, the Rexx compiler produces object code that may be linked into 
> a
z/OS
> executable -- just like the COBOL compiler. I am sure to CSV it looks
just
> like any other load module.

  You can browse a compiled Rexx exec in SYS1.SBLSCLI0(IEAVCPUI).
It is appear to be executable code.  But it is not in the format of an OBJ
or load module or program object.  So it cannot be processed directly by any
Binder or CSV services. It is something that the Rexx interpreter reads into
storage and invokes.
This is an example of what the Rexx compiler documentation calls CEXEC
format.  The CSVFETCH exit would no nothing about this.

 The Rexx compiler also has an option to generate OBJs, which you
subsequently bind into load modules or program objects that would be invoked
via CSV services.

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

Re: CSVFETCH exit

2016-03-23 Thread Greg Dyck


As to the question, what can you do with the information CSVFETCH makes 
available: can I write an SMF record from CSVFETCH?


You should be able to use SMFEWTM BRANCH=YES can write a SMF record from 
the exit.

Greg

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

Re: CSVFETCH exit

2016-03-23 Thread Leonardo Vaz

Kees,
The exit is called with the local lock held, so BPX4SMF wouldn't work, I 
couldn't find the requirements for SMFWTM but if that also doesn't like the 
exit's environment I guess you would have to do something like writing 
information to a dataspace and then get the data using another address space. 
Definitely more complex than what you have now.

But you are comparing two different things; for example, CSVFETCH would get 
control if a user is fetching a module by steplib/joblib, which LLA EXIT2 
wouldn't do. So your current solution doesn’t "determine if certain loadmodules 
are still being used", but rather if they are being fetched using LLA.

Regards,
Leo



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Wednesday, March 23, 2016 11:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

To determine if certain loadmodules are still being used, we use LLA EXIT2 
since decades.
We move the modules to a special LNKLST library, monitor with LLA EXIT2 fetches 
from this library and write an SMF record for the event.
CSVFETCH apparently is able to catch more loads, provide more info, but also 
seems more complicated to use. 
As to the question, what can you do with the information CSVFETCH makes 
available: can I write an SMF record from CSVFETCH?

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: 21 March, 2016 14:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I have a different question relative to this exit.

I've been looking for doc on line and have found two manuals that have CSVFETCH 
as an exit point defined, and one has the parm area info.

Peter did a presentation last week, and unfortunately for me, I had a hard 
conflict and couldn't attend, but I did get the "slide deck" and listened to 
the recording this morning.

There is a question that I have, and hopefully someone here will have the 
answer (We have not yet set up 2.2 on a test LPAR, but we have it on a sandbox 
LPAR where I can play with it):

Will a "fetch" of a CLIST or REXX be caught by this exit?

At this point, I have not seen how one could tell a executable module from a 
"script" (script because one might need this on the POSIX side of the system).

I could see using this exit in place of the SMF type 32 (with its overhead and 
tables in common...).

Meanwhile, I see where this exit could help a shop determine what obsolete 
subroutines are being used in production...

Regards,
Steve Thompson

--
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: CSVFETCH exit

2016-03-23 Thread Jim Mulder

> Peter, the Rexx compiler produces object code that may be linked into a 
z/OS
> executable -- just like the COBOL compiler. I am sure to CSV it looks 
just
> like any other load module.

  You can browse a compiled Rexx exec in SYS1.SBLSCLI0(IEAVCPUI).
It is appear to be executable code.  But it is not in the format of
an OBJ or load module or program object.  So it cannot
be processed directly by any Binder or CSV services. It 
is something that the Rexx interpreter reads into storage and invokes.
This is an example of what the Rexx compiler documentation calls
CEXEC format.  The CSVFETCH exit would no nothing about this.

 The Rexx compiler also has an option to generate OBJs, which 
you subsequently bind into load modules or program objects that would
be invoked via CSV services.

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY



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

Re: CSVFETCH exit

2016-03-23 Thread Charles Mills

Peter, the Rexx compiler produces object code that may be linked into a z/OS
executable -- just like the COBOL compiler. I am sure to CSV it looks just
like any other load module.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Wednesday, March 23, 2016 4:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

If compiling a REXX exec results in a load module (or program object) and if
someone then does a LOAD to access it (or something similar), then the
resulting fetch will drive the exit.

I think that those two IF's are not true. Mostly because I don't recall
having something that is compiled REXX be RECFM U when in a PDS -- it can be
in the same data set as non-compiled REXX execs.

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

Re: CSVFETCH exit

2016-03-23 Thread Vernooij, CP (ITOPT1) - KLM

To determine if certain loadmodules are still being used, we use LLA EXIT2 
since decades.
We move the modules to a special LNKLST library, monitor with LLA EXIT2 fetches 
from this library and write an SMF record for the event.
CSVFETCH apparently is able to catch more loads, provide more info, but also 
seems more complicated to use. 
As to the question, what can you do with the information CSVFETCH makes 
available: can I write an SMF record from CSVFETCH?

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: 21 March, 2016 14:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I have a different question relative to this exit.

I've been looking for doc on line and have found two manuals that 
have CSVFETCH as an exit point defined, and one has the parm area 
info.

Peter did a presentation last week, and unfortunately for me, I 
had a hard conflict and couldn't attend, but I did get the "slide 
deck" and listened to the recording this morning.

There is a question that I have, and hopefully someone here will 
have the answer (We have not yet set up 2.2 on a test LPAR, but 
we have it on a sandbox LPAR where I can play with it):

Will a "fetch" of a CLIST or REXX be caught by this exit?

At this point, I have not seen how one could tell a executable 
module from a "script" (script because one might need this on the 
POSIX side of the system).

I could see using this exit in place of the SMF type 32 (with its 
overhead and tables in common...).

Meanwhile, I see where this exit could help a shop determine what 
obsolete subroutines are being used in production...

Regards,
Steve Thompson

--
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: CSVFETCH exit

2016-03-23 Thread Walt Farrell

On Wed, 23 Mar 2016 06:39:40 -0500, Peter Relson  wrote:

>If compiling a REXX exec results in a load module (or program object) and 
>if someone then does a LOAD to access it (or something similar), then the 
>resulting fetch will drive the exit.
>
>I think that those two IF's are not true. Mostly because I don't recall 
>having something that is compiled REXX be RECFM U when in a PDS -- it can 
>be in the same data set as non-compiled REXX execs.

I believe they are true, Peter. RACF's Program Control functions can work for 
compiled REXX execs, for example, when they are turned into load modules. It is 
a two-step process, though: compile, and link-edit, just as for other 
programming languages.

-- 
Walt

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

Re: CSVFETCH exit

2016-03-23 Thread Pinnacle


On 3/23/2016 5:36 AM, David Crayford wrote:

On 23/03/2016 5:41 AM, Charles Mills wrote:

There is a compiler for Rexx but its performance improvement is moderate.



It depends on what the REXX is doing. We compiled the ISPF DTL compiler
and saw a significant performance improvement.
IIRC, automation products like NetView get a free REXX compiler (they
need it) and for that domain it makes a lot of sense. Lots of string
parsing.

The REXX compiler unfortunately can produce suboptimal code that is much
slower than interpreted REXX if you do a lot of memory
allocations, think queues and stem variables. I profiled a compiled REXX
program in APA and it appears to be doing a GETMAIN for each
allocation. Nearly 95% of the CPU time was spent in GETMAIN! Ouch :^/





David,

Thank you very much for verifying this.  I reported this issue to the 
Rexx compiler team about 10 years ago when the product was still 
supported.  I use stems like crazy, and compiling the Rexx exec made it 
run a lot longer.  I also had this weird thing where the job took two 
hours to exit the system after it was done running.  FREEMAINs?


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: CSVFETCH exit

2016-03-23 Thread Peter Relson

If compiling a REXX exec results in a load module (or program object) and 
if someone then does a LOAD to access it (or something similar), then the 
resulting fetch will drive the exit.

I think that those two IF's are not true. Mostly because I don't recall 
having something that is compiled REXX be RECFM U when in a PDS -- it can 
be in the same data set as non-compiled REXX execs.

Peter Relson
z/OS Core Technology Design


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

Re: CSVFETCH exit

2016-03-23 Thread David Crayford


On 23/03/2016 5:41 AM, Charles Mills wrote:

There is a compiler for Rexx but its performance improvement is moderate.



It depends on what the REXX is doing. We compiled the ISPF DTL compiler 
and saw a significant performance improvement.
IIRC, automation products like NetView get a free REXX compiler (they 
need it) and for that domain it makes a lot of sense. Lots of string 
parsing.


The REXX compiler unfortunately can produce suboptimal code that is much 
slower than interpreted REXX if you do a lot of memory
allocations, think queues and stem variables. I profiled a compiled REXX 
program in APA and it appears to be doing a GETMAIN for each

allocation. Nearly 95% of the CPU time was spent in GETMAIN! Ouch :^/





TMON Tone? The TMON family of performance monitors was Landmark and is now
ASG.

Tone used to have that lower-overhead TSO replacement. They now have a mix
of mainframe products including a dynamic STEPLIB product.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Edward Finnell
Sent: Tuesday, March 22, 2016 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

There were three CLIST compilers that I'm aware of. XLR8(Fischer),
TMON(Tone), and CLICK(IBM Internal).
In mid eighties we had good results with XLR8 and ADF II. As jobs  changed
fewer folks were willing to pay for it and development was less TSO
sensitive.

--
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: CSVFETCH exit

2016-03-22 Thread Charles Mills

There is a compiler for Rexx but its performance improvement is moderate.

TMON Tone? The TMON family of performance monitors was Landmark and is now
ASG.

Tone used to have that lower-overhead TSO replacement. They now have a mix
of mainframe products including a dynamic STEPLIB product.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Edward Finnell
Sent: Tuesday, March 22, 2016 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

There were three CLIST compilers that I'm aware of. XLR8(Fischer),
TMON(Tone), and CLICK(IBM Internal).
In mid eighties we had good results with XLR8 and ADF II. As jobs  changed
fewer folks were willing to pay for it and development was less TSO
sensitive. 

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

Re: CSVFETCH exit

2016-03-22 Thread Edward Finnell

There were three CLIST compilers that I'm aware of. XLR8(Fischer),  
TMON(Tone), and CLICK(IBM Internal).
In mid eighties we had good results with XLR8 and ADF II. As jobs  changed 
fewer folks were willing to pay for it and development was less TSO  
sensitive. 
 
 
In a message dated 3/22/2016 7:05:41 A.M. Central Daylight Time,  
elardus.engelbre...@sita.co.za writes:

- Can  you compile a CLIST (making it a loadmod to speedup running and 
bypassing  interpreting)?



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

Re: CSVFETCH exit

2016-03-22 Thread Steve Thompson


On 03/22/2016 07:39 AM, Peter Relson wrote:

Will a "fetch" of a CLIST or REXX be caught by this exit?


No. Contents Supervisor (and hence this exit) deals with load modules and
program objects.

Peter Relson
z/OS Core Technology Design



Thanks for the quick reply to this. And I kinda had a sinking 
feeling when I asked that this wasn't going to fly. But I was 
hoping REXX and CLIST were seen a bit differently


Regards,
Steve Thompson

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

Re: CSVFETCH exit

2016-03-22 Thread Elardus Engelbrecht

Peter Relson wrote:

>>Will a "fetch" of a CLIST or REXX be caught by this exit?

>No. Contents Supervisor (and hence this exit) deals with load modules and 
>program objects.

Thanks for your clarification. 

Interpreted REXX and CLIST will not be caught, but I believe *compiled* REXX 
programs can be caught by Contents Supervisor.

Hmmm, now I'm wondering (and activating my last few rusty brain cells ;-D ) ... 

   - Can you compile a CLIST (making it a loadmod to speedup running and 
bypassing interpreting)?

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: CSVFETCH exit

2016-03-22 Thread Peter Relson

>Will a "fetch" of a CLIST or REXX be caught by this exit?

No. Contents Supervisor (and hence this exit) deals with load modules and 
program objects.

Peter Relson
z/OS Core Technology Design


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

Re: CSVFETCH exit

2016-03-21 Thread Steve Thompson


I have a different question relative to this exit.

I've been looking for doc on line and have found two manuals that 
have CSVFETCH as an exit point defined, and one has the parm area 
info.


Peter did a presentation last week, and unfortunately for me, I 
had a hard conflict and couldn't attend, but I did get the "slide 
deck" and listened to the recording this morning.


There is a question that I have, and hopefully someone here will 
have the answer (We have not yet set up 2.2 on a test LPAR, but 
we have it on a sandbox LPAR where I can play with it):


Will a "fetch" of a CLIST or REXX be caught by this exit?

At this point, I have not seen how one could tell a executable 
module from a "script" (script because one might need this on the 
POSIX side of the system).


I could see using this exit in place of the SMF type 32 (with its 
overhead and tables in common...).


Meanwhile, I see where this exit could help a shop determine what 
obsolete subroutines are being used in production...


Regards,
Steve Thompson

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

Re: CSVFETCH exit

2016-02-16 Thread Tom Marchant

On Tue, 16 Feb 2016 19:17:10 +, Gibney, David Allen,Jr wrote:

>I am finding this interesting. One thing I think you are missing was the 
>advisability 
>to use STMG/LMG to save and restore all 64 bits of the registers. Not a lot of 
>stuff 
>running above the bar as yet, but it will be there sooner than we expect. :)

It isn't because of things running above the bar. Nor is it about referencing 
storage 
above the bar

Your program can't know whether your caller or anyone who called him is using 
the 
high halves of the registers for anything, so the linkage conventions require 
that if 
you alter the high halves in any way, you must restore them. For example, if 
your 
program issues a LG, XGR, or AG instruction, among many others, you should save 
and restore the high halves. It isn't hard to do it correctly when you are 
passed a 
144-byte save area, as this exit is.

By the way, for a long time (z/OS 1.3 maybe, but I'm not sure), the system 
provides 
any program that it calls with a 144-byte save area.

-- 
Tom Marchant

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

Re: CSVFETCH exit

2016-02-16 Thread Leonardo Vaz

I should not be playing with storage above the bar but I guess I'll use STMG to 
be sure.

Thanks everyone for their input! Much appreciated!

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 16, 2016 2:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

On Tue, 16 Feb 2016 19:11:38 +, Leonardo Vaz wrote:

>I see. In the case of CSVFETCH there is a 1024-byte work-area passed, 
>so no getmain should be needed, in this case, STM should be the best option?

You are passed a 144-byte save area, so I would use STMG to save the registers 
in F4SA format as documented in Chapter 2 of the Assembler Services Guide.

If you are sure that you won't be altering the high halves of registers 2 
through 12, STM is adequate.

--
Tom Marchant

--
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: CSVFETCH exit

2016-02-16 Thread Tom Marchant

On Tue, 16 Feb 2016 19:11:38 +, Leonardo Vaz wrote:

>I see. In the case of CSVFETCH there is a 1024-byte work-area passed, so no 
>getmain should be needed, in this case, STM should be the best option?

You are passed a 144-byte save area, so I would use STMG to save the registers 
in F4SA format as documented in Chapter 2 of the Assembler Services Guide.

If you are sure that you won't be altering the high halves of registers 2 
through 12, 
STM is adequate.

-- 
Tom Marchant

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

Re: CSVFETCH exit

2016-02-16 Thread Gibney, David Allen,Jr

I am finding this interesting. One thing I think you are missing was the 
advisability to use STMG/LMG to save and restore all 64 bits of the registers. 
Not a lot of stuff running above the bar as yet, but it will be there sooner 
than we expect. :)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Leonardo Vaz
> Sent: Tuesday, February 16, 2016 11:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CSVFETCH exit
> 
> I see. In the case of CSVFETCH there is a 1024-byte work-area passed, so no
> getmain should be needed, in this case, STM should be the best option?
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Blaicher, Christopher Y.
> Sent: Tuesday, February 16, 2016 1:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CSVFETCH exit
> 
> BAKR/PR does take a lot more time then STM/LM, but most times you can't
> just use STM/LM, you also have a GETMAIN/FREEMAIN for a register save
> area and other setup/restore things to do.
> 
> So, once you factor in those other overheads, which is faster?  I don't know 
> as
> I haven't set up the tests to validly compare the different methods possible. 
>  I
> have seen several different ways to avoid the GETMAIN/FREEMAIN
> overheads.
> 
> Chris Blaicher
> Technical Architect
> Software Development
> Syncsort Incorporated
> 50 Tice Boulevard, Woodcliff Lake, NJ 07677
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Leonardo Vaz
> Sent: Tuesday, February 16, 2016 1:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CSVFETCH exit
> 
> Well, I guess using the linkage stack is cleaner because the state of the 
> caller
> is preserved.
> 
> Thanks for your reply, that is what I wanted to know, I was going to use STM
> but I remember reading somewhere before (maybe linkedin?) that they would
> never approve any assembler code written in the past 20 years starting with
> STM  R14,R12,12(R13). I just would like to hear someone that would prefer
> BAKR and why.
> 
> Thanks,
> Leo
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tom Marchant
> Sent: Tuesday, February 16, 2016 12:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CSVFETCH exit
> 
> On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:
> 
> >I apologize if the question is silly, but I am wondering if for a
> >performance sensitive exit like this one I should use STM/LM instead of
> >BAKR/PR. I believe it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR,
> right?
> 
> Why do you think BAKR is "cleaner"?
> 
> BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the
> high halves of any of registers 2-12).
> 
> --
> Tom Marchant
> 
> --
> 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
> 
> 
> 
> 
> 
> ATTENTION: -
> 
> The information contained in this message (including any files transmitted
> with this message) may contain proprietary, trade secret or other confidential
> and/or legally privileged information. Any pricing information contained in
> this message or in any files transmitted with this message is always
> confidential and cannot be shared with any third parties without prior written
> approval from Syncsort. This message is intended to be read only by the
> individual or entity to whom it is addressed or by their designee. If the 
> reader
> of this message is not the intended recipient, you are on notice that any use,
> disclosure, copying or distribution of this message, in any form, is strictly
> prohibited. If you have received this message in error, please immediately
> notify the sender and/or Syncsort and destroy all copies of this message in
> your possession, custody or control.
> 
> --
> 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: CSVFETCH exit

2016-02-16 Thread Blaicher, Christopher Y.

I had not followed the discussion very closely, but it sounds like they have 
given the exit enough working storage so that no GETMAIN/FREEMAIN is needed.
In that case it is clearly a performance advantage to use STM/LM over BAKR/PR.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803    
E: cblaic...@syncsort.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Tuesday, February 16, 2016 2:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I see. In the case of CSVFETCH there is a 1024-byte work-area passed, so no 
getmain should be needed, in this case, STM should be the best option?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Tuesday, February 16, 2016 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

BAKR/PR does take a lot more time then STM/LM, but most times you can't just 
use STM/LM, you also have a GETMAIN/FREEMAIN for a register save area and other 
setup/restore things to do.

So, once you factor in those other overheads, which is faster?  I don't know as 
I haven't set up the tests to validly compare the different methods possible.  
I have seen several different ways to avoid the GETMAIN/FREEMAIN overheads.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Tuesday, February 16, 2016 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Well, I guess using the linkage stack is cleaner because the state of the 
caller is preserved.

Thanks for your reply, that is what I wanted to know, I was going to use STM 
but I remember reading somewhere before (maybe linkedin?) that they would never 
approve any assembler code written in the past 20 years starting with STM  
R14,R12,12(R13). I just would like to hear someone that would prefer BAKR and 
why.

Thanks,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 16, 2016 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:

>I apologize if the question is silly, but I am wondering if for a 
>performance sensitive exit like this one I should use STM/LM instead of 
>BAKR/PR. I believe it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR, 
>right?

Why do you think BAKR is "cleaner"?

BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the high 
halves of any of registers 2-12).

--
Tom Marchant

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

ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
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: CSVFETCH exit

2016-02-16 Thread Tom Marchant

On Tue, 16 Feb 2016 18:49:36 +, Blaicher, Christopher Y. wrote:

>BAKR/PR does take a lot more time then STM/LM, but most times you can't just 
>use STM/LM, you also have a GETMAIN/FREEMAIN for a register save area and 
>other setup/restore things to do.
>
>So, once you factor in those other overheads, which is faster?  I don't know 
>as 
>I haven't set up the tests to validly compare the different methods possible.  
>I 
>have seen several different ways to avoid the GETMAIN/FREEMAIN overheads.

The CSVFETCH exit is passed a 1K work area, likely eliminating the need to 
GETMAIN 
in many cases.

-- 
Tom Marchant

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

Re: CSVFETCH exit

2016-02-16 Thread Leonardo Vaz

I see. In the case of CSVFETCH there is a 1024-byte work-area passed, so no 
getmain should be needed, in this case, STM should be the best option?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Tuesday, February 16, 2016 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

BAKR/PR does take a lot more time then STM/LM, but most times you can't just 
use STM/LM, you also have a GETMAIN/FREEMAIN for a register save area and other 
setup/restore things to do.

So, once you factor in those other overheads, which is faster?  I don't know as 
I haven't set up the tests to validly compare the different methods possible.  
I have seen several different ways to avoid the GETMAIN/FREEMAIN overheads.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Tuesday, February 16, 2016 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Well, I guess using the linkage stack is cleaner because the state of the 
caller is preserved.

Thanks for your reply, that is what I wanted to know, I was going to use STM 
but I remember reading somewhere before (maybe linkedin?) that they would never 
approve any assembler code written in the past 20 years starting with STM  
R14,R12,12(R13). I just would like to hear someone that would prefer BAKR and 
why.

Thanks,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 16, 2016 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:

>I apologize if the question is silly, but I am wondering if for a 
>performance sensitive exit like this one I should use STM/LM instead of 
>BAKR/PR. I believe it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR, 
>right?

Why do you think BAKR is "cleaner"?

BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the high 
halves of any of registers 2-12).

--
Tom Marchant

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

ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
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: CSVFETCH exit

2016-02-16 Thread Blaicher, Christopher Y.

BAKR/PR does take a lot more time then STM/LM, but most times you can't just 
use STM/LM, you also have a GETMAIN/FREEMAIN for a register save area and other 
setup/restore things to do.

So, once you factor in those other overheads, which is faster?  I don't know as 
I haven't set up the tests to validly compare the different methods possible.  
I have seen several different ways to avoid the GETMAIN/FREEMAIN overheads.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Tuesday, February 16, 2016 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Well, I guess using the linkage stack is cleaner because the state of the 
caller is preserved.

Thanks for your reply, that is what I wanted to know, I was going to use STM 
but I remember reading somewhere before (maybe linkedin?) that they would never 
approve any assembler code written in the past 20 years starting with STM  
R14,R12,12(R13). I just would like to hear someone that would prefer BAKR and 
why.

Thanks,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 16, 2016 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:

>I apologize if the question is silly, but I am wondering if for a
>performance sensitive exit like this one I should use STM/LM instead of
>BAKR/PR. I believe it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR, 
>right?

Why do you think BAKR is "cleaner"?

BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the high 
halves of any of registers 2-12).

--
Tom Marchant

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

ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

Re: CSVFETCH exit

2016-02-16 Thread Leonardo Vaz

Well, I guess using the linkage stack is cleaner because the state of the 
caller is preserved.

Thanks for your reply, that is what I wanted to know, I was going to use STM 
but I remember reading somewhere before (maybe linkedin?) that they would never 
approve any assembler code written in the past 20 years starting with STM  
R14,R12,12(R13). I just would like to hear someone that would prefer BAKR and 
why.

Thanks,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 16, 2016 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:

>I apologize if the question is silly, but I am wondering if for a 
>performance sensitive exit like this one I should use STM/LM instead of 
>BAKR/PR. I believe it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR, 
>right?

Why do you think BAKR is "cleaner"?

BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the high 
halves of any of registers 2-12).

--
Tom Marchant

--
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: CSVFETCH exit

2016-02-16 Thread Tom Marchant

On Tue, 16 Feb 2016 16:52:03 +, Leonardo Vaz wrote:

>I apologize if the question is silly, but I am wondering if for a performance 
>sensitive 
>exit like this one I should use STM/LM instead of BAKR/PR. I believe it's 
>"cheaper" to 
>do STM/LM, bur "cleaner" to do BAKR, right? 

Why do you think BAKR is "cleaner"?

BAKR/PR is MUCH slower than STM/LM (or STMG/LMG if you are using the high 
halves 
of any of registers 2-12).

-- 
Tom Marchant

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

Re: CSVFETCH exit

2016-02-16 Thread Leonardo Vaz

Hello again list!

I apologize if the question is silly, but I am wondering if for a performance 
sensitive exit like this one I should use STM/LM instead of BAKR/PR. I believe 
it's "cheaper" to do STM/LM, bur "cleaner" to do BAKR, right? 

Thanks,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Friday, February 12, 2016 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I agree, unsafe.  But I could probably argue that just letting a system 
programmer logon is unsafe :)  I had various checks to try to prevent the hooks 
from causing issues, including (if I remember correctly) using the LRA 
instruction to check for a valid address in ECSA prior to access.  I didn't 
want to cause an 0C4 in someone's SVC 8 just because I messed up.

Over the 4 years or so the hooks were in place I was kind of proud they had 
never caused problems or crashed a system.  And they had to co-exist with 
various vendor product hooks on the same SVC's.  That work gave me a good look 
at what the poor vendors have to go through when no better interface exists.

Leonardo Vaz wrote:
> More difficult indeed, but at least it is now a documented programming 
> interface, which is a huge jump from having to play around with 
> arguably unsafe hooks :)

--
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: CSVFETCH exit

2016-02-13 Thread Peter Relson

Just FYI, there's a pretty blatant doc error of my causing in the z/OS 2.2 
data. A doc APAR has been, or soon will be, provided.

The doc says that the exit routine gets control with reg 1 pointing to a a 
2 word area, the first word being the address of a work area that the exit 
routine can use, the second being the address of the parameter area.

In reality it is the reverse. The first address is the address of the 
parameter area, the second the address of the work area.

Peter Relson
z/OS Core Technology Design


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

Re: CSVFETCH exit

2016-02-13 Thread Leonardo Vaz

I noticed that, was going to open a PMR on Monday, thanks for reporting here.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Saturday, February 13, 2016 11:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Just FYI, there's a pretty blatant doc error of my causing in the z/OS 2.2 
data. A doc APAR has been, or soon will be, provided.

The doc says that the exit routine gets control with reg 1 pointing to a a
2 word area, the first word being the address of a work area that the exit 
routine can use, the second being the address of the parameter area.

In reality it is the reverse. The first address is the address of the parameter 
area, the second the address of the work area.

Peter Relson
z/OS Core Technology Design

--
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: CSVFETCH exit

2016-02-12 Thread Leonardo Vaz

More difficult indeed, but at least it is now a documented programming 
interface, which is a huge jump from having to play around with arguably unsafe 
hooks :)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Thursday, February 11, 2016 7:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I guess I missed the first post.  It interests me, maybe because at one time 
(when I had not much to do) I wrote some SVC hooks that did similar monitoring, 
and crazy enough, my code actually made it to production where it was of some 
use over time.  I think this was late-1990's, maybe before TADz became popular.

I haven't seen this new method yet, but I like it.  Now, what do you do with 
all the data?  From your note it sounds like IBM is only providing an exit, and 
a user program needs to do the recording and reporting. 
That part in my old code was probably more difficult than the hooks themselves.

Leonardo Vaz wrote:
> I will take the lack of response as a "no".
> 
> Am I the only one excited about this new exit on the discussion list or is my 
> email not reaching the list at all?
> 
> Leo
> 
> From: Leonardo Vaz
> Sent: Wednesday, February 10, 2016 5:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CSVFETCH exit
> 
> CSVFETCH seems to be a new exit in z/OS 2.2 which would allow monitoring of 
> module fetching.
> 
> http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos
> .v2r2.ieaa800/csvfetch01.htm?lang=en
> 
> This seems pretty interesting, and something that can't be easily done 
> another way. Has anyone played with it already and is willing to share their 
> view?
> 
> Thanks,
> Leonardo Vaz
> 
> 
> --
> 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: CSVFETCH exit

2016-02-12 Thread Tom Brennan

I agree, unsafe.  But I could probably argue that just letting a system 
programmer logon is unsafe :)  I had various checks to try to prevent 
the hooks from causing issues, including (if I remember correctly) using 
the LRA instruction to check for a valid address in ECSA prior to 
access.  I didn't want to cause an 0C4 in someone's SVC 8 just because I 
messed up.


Over the 4 years or so the hooks were in place I was kind of proud they 
had never caused problems or crashed a system.  And they had to co-exist 
with various vendor product hooks on the same SVC's.  That work gave me 
a good look at what the poor vendors have to go through when no better 
interface exists.


Leonardo Vaz wrote:

More difficult indeed, but at least it is now a documented programming 
interface, which is a huge jump from having to play around with arguably unsafe 
hooks :)


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

Re: CSVFETCH exit

2016-02-11 Thread Ed Jaffe


On 2/11/2016 1:46 PM, Leonardo Vaz wrote:

Am I the only one excited about this new exit on the discussion list or is my 
email not reaching the list at all?


You are not the only one. This exit is the result of SHARE requirement 
SSMVSE11018 that I authored and submitted in July 2011:



Title: Contents Supervisor Exit

Description: An exit is needed that will pass information about the 
module just fetched into or about to be removed from virtual storage by 
the contents supervisor. The information should include information 
available today to CSVINFO/CSVQUERY invokers such as 1) module name, 2) 
virtual storage extent list, and 3) information that can help determine 
the MVS data set name or z/OS UNIX directory from which the module was 
fetched. The CSV exit should also be called for directed LOADs, even 
though the information passed by the system might be only a subset of 
what is available for other module fetches and there will be no module 
DELETE for this case.


Benefit: CSV monitoring is needed by asset management products, 
application profilers, debuggers and other similar software programs. 
Today, such programs monitor module fetch by intercepting important 
system service entry points such as SVC routines. These are completely 
unintended interfaces, thus no documentation exists describing how to 
insert the intercept, how the intercept code must behave, or how to 
handle the situation that arises when more than one product must 
intercept the same system service. These system interfaces are very 
sensitive and serious system instability can arise from such programming.


Solution:The exit should be able to be dynamically activated by more 
than one product running in a z/OS image.


Impact if no solution provided: Software providers will continue to use 
unintended (and 'dangerous'!) interfaces to monitor CSV activity.


Product Name: z/OS MVS Contents Supervisor

Author Name: Edward Jaffe

Company: Phoenix Software International

SHARE Installation Code: PHX

etc...


--
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: CSVFETCH exit

2016-02-11 Thread Tom Brennan

I guess I missed the first post.  It interests me, maybe because at one 
time (when I had not much to do) I wrote some SVC hooks that did similar 
monitoring, and crazy enough, my code actually made it to production 
where it was of some use over time.  I think this was late-1990's, maybe 
before TADz became popular.


I haven't seen this new method yet, but I like it.  Now, what do you do 
with all the data?  From your note it sounds like IBM is only providing 
an exit, and a user program needs to do the recording and reporting. 
That part in my old code was probably more difficult than the hooks 
themselves.


Leonardo Vaz wrote:

I will take the lack of response as a "no".

Am I the only one excited about this new exit on the discussion list or is my 
email not reaching the list at all?

Leo

From: Leonardo Vaz
Sent: Wednesday, February 10, 2016 5:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CSVFETCH exit

CSVFETCH seems to be a new exit in z/OS 2.2 which would allow monitoring of 
module fetching.

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa800/csvfetch01.htm?lang=en

This seems pretty interesting, and something that can't be easily done another 
way. Has anyone played with it already and is willing to share their view?

Thanks,
Leonardo Vaz


--
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: CSVFETCH exit

2016-02-11 Thread wjanulin

Sounds like there are not that many users on zOS 2.2 just yet.

Bill J

Sent from my Verizon 4G LTE Smartphone

-- Original message--
From: Pommier, Rex
Date: Thu, Feb 11, 2016 7:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU;
Subject:Re: CSVFETCH exit

Leo,

The list has been reached.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Thursday, February 11, 2016 3:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I will take the lack of response as a "no".

Am I the only one excited about this new exit on the discussion list or is my 
email not reaching the list at all?

Leo

From: Leonardo Vaz
Sent: Wednesday, February 10, 2016 5:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CSVFETCH exit

CSVFETCH seems to be a new exit in z/OS 2.2 which would allow monitoring of 
module fetching.

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa800/csvfetch01.htm?lang=en

This seems pretty interesting, and something that can't be easily done another 
way. Has anyone played with it already and is willing to share their view?

Thanks,
Leonardo Vaz

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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

--
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: CSVFETCH exit

2016-02-11 Thread Leonardo Vaz

I will take the lack of response as a "no".

Am I the only one excited about this new exit on the discussion list or is my 
email not reaching the list at all?

Leo

From: Leonardo Vaz
Sent: Wednesday, February 10, 2016 5:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CSVFETCH exit

CSVFETCH seems to be a new exit in z/OS 2.2 which would allow monitoring of 
module fetching.

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa800/csvfetch01.htm?lang=en

This seems pretty interesting, and something that can't be easily done another 
way. Has anyone played with it already and is willing to share their view?

Thanks,
Leonardo Vaz

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

Re: CSVFETCH exit

2016-02-11 Thread Pommier, Rex

Leo,

The list has been reached.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Thursday, February 11, 2016 3:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I will take the lack of response as a "no".

Am I the only one excited about this new exit on the discussion list or is my 
email not reaching the list at all?

Leo

From: Leonardo Vaz
Sent: Wednesday, February 10, 2016 5:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CSVFETCH exit

CSVFETCH seems to be a new exit in z/OS 2.2 which would allow monitoring of 
module fetching.

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa800/csvfetch01.htm?lang=en

This seems pretty interesting, and something that can't be easily done another 
way. Has anyone played with it already and is willing to share their view?

Thanks,
Leonardo Vaz


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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: CSVFETCH exit

2016-02-11 Thread Leonardo Vaz

Wow, ‎thanks for the info and thanks for submitting the requirement.

Very useful indeed. ‎
Leo
  Original Message
From: Ed Jaffe
Sent: Thursday, February 11, 2016 5:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: CSVFETCH exit

On 2/11/2016 1:46 PM, Leonardo Vaz wrote:
> Am I the only one excited about this new exit on the discussion list or is my 
> email not reaching the list at all?

You are not the only one. This exit is the result of SHARE requirement
SSMVSE11018 that I authored and submitted in July 2011:

Title: Contents Supervisor Exit

Description: An exit is needed that will pass information about the
module just fetched into or about to be removed from virtual storage by
the contents supervisor. The information should include information
available today to CSVINFO/CSVQUERY invokers such as 1) module name, 2)
virtual storage extent list, and 3) information that can help determine
the MVS data set name or z/OS UNIX directory from which the module was
fetched. The CSV exit should also be called for directed LOADs, even
though the information passed by the system might be only a subset of
what is available for other module fetches and there will be no module
DELETE for this case.

Benefit: CSV monitoring is needed by asset management products,
application profilers, debuggers and other similar software programs.
Today, such programs monitor module fetch by intercepting important
system service entry points such as SVC routines. These are completely
unintended interfaces, thus no documentation exists describing how to
insert the intercept, how the intercept code must behave, or how to
handle the situation that arises when more than one product must
intercept the same system service. These system interfaces are very
sensitive and serious system instability can arise from such programming.

Solution:The exit should be able to be dynamically activated by more
than one product running in a z/OS image.

Impact if no solution provided: Software providers will continue to use
unintended (and 'dangerous'!) interfaces to monitor CSV activity.

Product Name: z/OS MVS Contents Supervisor

Author Name: Edward Jaffe

Company: Phoenix Software International

SHARE Installation Code: PHX

etc...

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

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

Re: CSVFETCH exit

2016-02-11 Thread Leonardo Vaz

Thanks for letting me know Rex :)

zLeo
  Original Message
From: Pommier, Rex
Sent: Thursday, February 11, 2016 5:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: CSVFETCH exit

Leo,

The list has been reached.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Thursday, February 11, 2016 3:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

I will take the lack of response as a "no".

Am I the only one excited about this new exit on the discussion list or is my 
email not reaching the list at all?

Leo

From: Leonardo Vaz
Sent: Wednesday, February 10, 2016 5:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CSVFETCH exit

CSVFETCH seems to be a new exit in z/OS 2.2 which would allow monitoring of 
module fetching.

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa800/csvfetch01.htm?lang=en

This seems pretty interesting, and something that can't be easily done another 
way. Has anyone played with it already and is willing to share their view?

Thanks,
Leonardo Vaz

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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

--
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: CSVFETCH exit

2016-02-11 Thread Leonardo Vaz

I  believe TADz might not be an option for many shops due to pricing vs gains 
since it's hard to measure the gains. This exit could prove pretty useful when 
TADz is not available. Having a documented programming interface for this is 
just golden.

Thanks IBM :)

Leo
  Original Message
From: Tom Brennan
Sent: Thursday, February 11, 2016 7:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: CSVFETCH exit

I guess I missed the first post.  It interests me, maybe because at one
time (when I had not much to do) I wrote some SVC hooks that did similar
monitoring, and crazy enough, my code actually made it to production
where it was of some use over time.  I think this was late-1990's, maybe
before TADz became popular.

I haven't seen this new method yet, but I like it.  Now, what do you do
with all the data?  From your note it sounds like IBM is only providing
an exit, and a user program needs to do the recording and reporting.
That part in my old code was probably more difficult than the hooks
themselves.

Leonardo Vaz wrote:
> I will take the lack of response as a "no".
>
> Am I the only one excited about this new exit on the discussion list or is my 
> email not reaching the list at all?
>
> Leo
>
> From: Leonardo Vaz
> Sent: Wednesday, February 10, 2016 5:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CSVFETCH exit
>
> CSVFETCH seems to be a new exit in z/OS 2.2 which would allow monitoring of 
> module fetching.
>
> http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa800/csvfetch01.htm?lang=en
>
> This seems pretty interesting, and something that can't be easily done 
> another way. Has anyone played with it already and is willing to share their 
> view?
>
> Thanks,
> Leonardo Vaz
>
>
> --
> 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

CSVFETCH exit

2016-02-10 Thread Leonardo Vaz

CSVFETCH seems to be a new exit in z/OS 2.2 which would allow monitoring of 
module fetching.

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa800/csvfetch01.htm?lang=en

This seems pretty interesting, and something that can't be easily done another 
way. Has anyone played with it already and is willing to share their view?

Thanks,
Leonardo Vaz


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

45 matches

Mail list logo