Discussion:
Looking for an appropriate system exit
Add Reply
Steff Gladstone
2017-12-06 07:12:34 UTC
Reply
Permalink
Greetings,

In our installation we would like to implement certain checks and document
certain run-time characteristics at the beginning and during program
initialization and duration (chiefly Cobol programs). We would like to
implement this in a manner transparent to the application, without
requiring the programmer to add lines of JCL or calls to subroutines (we
have thousands of legacy programs and jobs and don't want to have to go
through a massive conversion project).

We are looking at initialization routines like CEEBINT. Can anyone
recommend any other system exits that could be candidates for this sort of
thing. Any potential pitfalls we should be aware of?

Thank you,
Steff Gladstone

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-12-06 08:52:31 UTC
Reply
Permalink
Can you give an example or two?

On Wed, 6 Dec 2017 09:13:47 +0200 Steff Gladstone <***@GMAIL.COM>
wrote:

:>In our installation we would like to implement certain checks and document
:>certain run-time characteristics at the beginning and during program
:>initialization and duration (chiefly Cobol programs). We would like to
:>implement this in a manner transparent to the application, without
:>requiring the programmer to add lines of JCL or calls to subroutines (we
:>have thousands of legacy programs and jobs and don't want to have to go
:>through a massive conversion project).

:>We are looking at initialization routines like CEEBINT. Can anyone
:>recommend any other system exits that could be candidates for this sort of
:>thing. Any potential pitfalls we should be aware of?

--
Binyamin Dissen <***@dissensoftware.com>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steff Gladstone
2018-10-04 15:26:41 UTC
Reply
Permalink
After a respite of several months this topic has gotten hot again for us.
We believe that using the IEFUSI and IEFACTRT exits answer our need to gain
control at job-step initialization and again at job-step termination.

My question is: if we use the dynamic exits facility, that is, the console
command

SETPROG EXIT,ADD,EX=xxxxxxxx,MOD=xxxxxxxx,LAST

(or issue the equivalent CSVDYNEX macro in an assembler program) to add our
exit routines to the system exit points SYS.IEFUSI AND SYS.IEFACTRT, and
assuming we are careful to return R15=0 in our exit routines and not change
anything in the passed parameters, could that still affect or override in
any way the results of the default or system exit routines already in
effect for those exit points? We would like our exits to be as innocuous
as possible and not adversely affect what is already in the system.
Your best/easiest would be a SAF exit for checking PROGRAM class - that
gets
control for each load without hooking stuff. Otherwise you can hook the
standard LOAD/LINK/ATTACH SVCs. The IEFUSI would have the EXEC PGM= name.
On Wed, 6 Dec 2017 12:14:45 +0200 Steff Gladstone <
:>Hi Binyamin,
:>
:>The application load libraries are full of obsolete code. We are trying
to
:>identify which programs are still active in the installation in order to
:>weed out obsolete legacy programs and clean up our load libraries, and
:>eventually, source libraries.
:>
:>We were hoping to choose an optimal exit that would enable us to capture
:>pertinent info: called load module name, load library name, caller name,
:>etc. We would prefer an exit that allows the designation of a number of
:>individual exit routines per exit (JES2 and CICS and, to a limited
extent,
:>DFSMS, provide this capability; I am not aware of other possibilities),
so
:>that we could easily disable or remove our code when necessary without
:>affecting other customized user code in that exit.
:>
:>Thanks for any assistance you can extend to us.
:>
:>Steff Gladstone
:>
:>On Wed, Dec 6, 2017 at 10:53 AM, Binyamin Dissen <
:>
:>> Can you give an example or two?
:>>
:>> On Wed, 6 Dec 2017 09:13:47 +0200 Steff Gladstone <
:>>
:>> :>In our installation we would like to implement certain checks and
:>> document
:>> :>certain run-time characteristics at the beginning and during program
:>> :>initialization and duration (chiefly Cobol programs). We would like
to
:>> :>implement this in a manner transparent to the application, without
:>> :>requiring the programmer to add lines of JCL or calls to subroutines
(we
:>> :>have thousands of legacy programs and jobs and don't want to have to
go
:>> :>through a massive conversion project).
:>>
:>> :>We are looking at initialization routines like CEEBINT. Can anyone
:>> :>recommend any other system exits that could be candidates for this
sort
:>> of
:>> :>thing. Any potential pitfalls we should be aware of?
:>>
:>> --
:>> 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,
:>>
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-10-04 16:56:13 UTC
Reply
Permalink
The dynamic exits facility does a pretty much perfect job of isolating various exit routines one from another.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Steff Gladstone
Sent: Thursday, October 4, 2018 8:30 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Looking for an appropriate system exit

After a respite of several months this topic has gotten hot again for us.
We believe that using the IEFUSI and IEFACTRT exits answer our need to gain
control at job-step initialization and again at job-step termination.

My question is: if we use the dynamic exits facility, that is, the console
command

SETPROG EXIT,ADD,EX=xxxxxxxx,MOD=xxxxxxxx,LAST

(or issue the equivalent CSVDYNEX macro in an assembler program) to add our
exit routines to the system exit points SYS.IEFUSI AND SYS.IEFACTRT, and
assuming we are careful to return R15=0 in our exit routines and not change
anything in the passed parameters, could that still affect or override in
any way the results of the default or system exit routines already in
effect for those exit points? We would like our exits to be as innocuous
as possible and not adversely affect what is already in the system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Harminc
2018-10-04 19:15:12 UTC
Reply
Permalink
Post by Charles Mills
The dynamic exits facility does a pretty much perfect job of isolating various exit routines one from another.
I agree with Charles - it's a great facility with about all the power
and convenience one could ask for. (Now why certain IBM components
continue not to use it is another matter.)

Steff Gladstone wrote:
[...]
Post by Charles Mills
(or issue the equivalent CSVDYNEX macro in an assembler program) to add our
exit routines to the system exit points SYS.IEFUSI AND SYS.IEFACTRT,
[...]

I would just watch for two possible trouble areas:

Will either or both exits get control where you don't expect it, e.g.
for things other than batch jobs/steps? Your code may need to be aware
of its invocation environment that could be TSO, a
forked/spawned/exec'd UNIX job step, or an APPC transaction. Maybe you
don't have any of these, but your code should probably be aware and
ignore them gracefully if you don't want to process them.

On the flip side, dynamically adding exit routines to SYS.xxx may not
be enough to capture everything of interest. If it's your own system
and you know what your SMFPRMxx looks like, then fine. But depending
on the SYS and SUBSYS parameters, there could be exit points for
things like TSO.xxx or IMS.yyy or ASCH.zzz. Best generalized approach
if you're going to use CSVDYNEX is to issue CSVDYNEX REQUEST=LIST,
and then scan the result for exit point names *ending* in .IEFUSI and
.IEFACTRT (noting that the left parts can be of different lengths). Or
of course just hard code what you know you need.

And it goes without saying that these exits run in the most highly
privileged state possible, i.e. key zero and supervisor state. So code
and test very carefully...

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-12-06 12:35:58 UTC
Reply
Permalink
Post by Steff Gladstone
In our installation we would like to implement certain checks and document
certain run-time characteristics at the beginning and during program
initialization and duration ...
We are looking at initialization routines like CEEBINT. Can anyone
recommend any other system exits that could be candidates for this sort of
thing. Any potential pitfalls we should be aware of?
In order to provide any guidance, we will need more information about the
kinds of things you want to do. I would be surprised if CEEBINIT would be
appropriate.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-12-06 14:37:49 UTC
Reply
Permalink
In our installation we would like to implement certain checks and document certain run-time characteristics at the beginning and during program initialization and duration (chiefly Cobol programs).
What checks?
We would like to implement this in a manner transparent to the application, without requiring the programmer to add lines of JCL or calls to subroutines (we have thousands of legacy programs and jobs and don't want to have to go through a massive conversion project).
Forget about it. No, sorry, I not being funny with you, but really, those 'change / documentation / check management' and similar software are mostly failed to doom and gloom. Rather start with that project when you __start__ a mainframe system or a data centre, not when you have gazillion old and new programs, JCLs and systems.

I was tasked around 1989-199? to implement Librarian and to invent something for documentation of program changes and what they're doing at all. It was a PITA which we dropped as soon we can...
We are looking at initialization routines like CEEBINT. Can anyone recommend any other system exits that could be candidates for this sort of thing.
Ok, I said I am not funny with you. One solution is, what submitter are you using? If using automation software, then your project is nearly done. just modify your automation software for all these jobs and their programs. These software have audit logs, if enabled of course.

Those automation software have 'condition codes' which can be used to audit and log jobs/steps completion. So you could setup your job with RC=0/4/16 and the condition codes can be setup as 'Good/Bad/Ugly' after completion.

Or use RACF and SMF to monitor the loadlibs and program as well data used. Lots of hard work and overhead, but can be done.

I believe there are other methods... but CEEBINIT? Not all programs are compiled using LE. What will you do if some COBOL programs call an Assembler program which disregards LE?
Any potential pitfalls we should be aware of?
Hmmm, some pitfalls - you will only see the first program [in EXEC PGM=<???>], if you want monitor subsequent called programs, you're in trouble, unless you can put something in to monitor them too. No, I don't know if that solution is possible or useful.

Perhaps you should clarify what you need and give some examples as requested by others. I am pretty sure there is a solution for your task.

Good luck and all of the very best for you and your team.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2018-10-05 12:36:35 UTC
Reply
Permalink
<snip>
assuming we are careful to return R15=0 in our exit routines and not
change
anything in the passed parameters, could that still affect or override in
any way the results of the default or system exit routines already in
effect for those exit points?
</snip>

No, it could not.

<snip>
(Now why certain IBM components
continue not to use it is another matter.)
</snip>

Because, presumably, there has been not enough call to do so (and there
is, of course, a cost for implementation). If you have a reason for
wanting/needing a particular exit to exploit the dynamic exits facility,
then please submit an RFE. When the facility was developed, we took a stab
at which existing exits that we thought were most likely to be of help to
the most customers. And I'd hope that new exits use it.

<snip>
SYS.IEFUSI AND SYS.IEFACTRT
</snip>

I agree with Tony H's point that you need to consider whether you might
also need the other cases such as SYSSTC.


Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2018-10-05 12:44:10 UTC
Reply
Permalink
<snip>
Otherwise you can hook the standard LOAD/LINK/ATTACH SVCs.
</snip>

Please do not do that. There is a long history of applications getting
this wrong.
It is unfortunate that hooking of any SVC was ever viewed as acceptable
practice.
But in the absence of suitable exits, it can be understandable.

z/OS 2.2 implemented the CSVFETCH exit. Consider using that if you want to
track every module fetch.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-10-05 13:20:22 UTC
Reply
Permalink
When the facility was developed, we took a stab at which existing exits that we thought were most likely to be of help to the most customers. And I'd hope that new exits use it.
That was one of the best stabs I got from Big Blue. It saved me an unneeded IPL when one of my SMF exits went down the bit bucket.

That exit was called once, a dump took place and SMF just disable it. I had to remove it from SMFPRMxx and from LPA, analyze the problem and put it back first on LPA and then back on SMF.

Years ago, before those dynamic exit facility, it was a real PITA to add a new accounting code in IEFUJI exit. Then some one (not me) rewrote the IEFUJI to have LOAD EP=<module containing the batch account codes> avoiding an IPL.

Now these days we are using RACF to check up those accounting codes. IRREVX00 exit is also an excellent user of that great dynamic exit facility.

I could also go on for example those ISPF exits which you can reload it by just logoff/logon on to TSO.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-10-05 14:17:43 UTC
Reply
Permalink
I use the CSVDYNEX interface extensively and it has been nothing but bulletproof in all of my experience. Kudos!

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht
Sent: Friday, October 5, 2018 6:20 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Looking for an appropriate system exit
When the facility was developed, we took a stab at which existing exits that we thought were most likely to be of help to the most customers. And I'd hope that new exits use it.
That was one of the best stabs I got from Big Blue. It saved me an unneeded IPL when one of my SMF exits went down the bit bucket.

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