Endevor/Binds using IKJEFT01 SYSTSPRT

Ruth Sutlic

Endevor/Binds using IKJEFT01 SYSTSPRT
Hello fellow Listers,
My CA-Endevor person has a problem when doing binds in foreground. (Batch
works just great). Endevor has a program that calls IKJEFT01. The missing
bind statements we want to see come from DDNAME SYSTSPRT. They don't show
up when the bind process runs in foreground.
CA said that we must have some customization in place that is preventing
this from working. I was wondering if anyone else has run into this
problem. Would you be willing to share what the resolution was?

Regards,
Ruth Sutlic



Marcel Harleman

Re: Endevor/Binds using IKJEFT01 SYSTSPRT
(in response to Ruth Sutlic)
Hi,

I have not run into this problem but ... have you checked the SYSTSPRT
allocation via f.i. {TSO} ISRDDN? Maybe SYSTSPRT is allocated to a
dataset where all the output is written to. Or it is allocated to
dummy (?).
If so then hopefully the SYSTSPRT is not open. In that case you should
be able to issue the command "{TSO} ALLOC F(SYSTSPRT) DA(*) REUSE" and
all the output for SYSTSPRT will be written to the terminal.

Hope this helps.

Marcel.

>Hello fellow Listers,
>My CA-Endevor person has a problem when doing binds in foreground. (Batch
>works just great). Endevor has a program that calls IKJEFT01. The missing
>bind statements we want to see come from DDNAME SYSTSPRT. They don't show
>up when the bind process runs in foreground.
>CA said that we must have some customization in place that is preventing
>this from working. I was wondering if anyone else has run into this
>problem. Would you be willing to share what the resolution was?
>
>Regards,
>Ruth Sutlic
>
>
>



Ruth Sutlic

Re: Endevor/Binds using IKJEFT01 SYSTSPRT
(in response to Marcel Harleman)
Morning Marcel,
Yes, one of the first things we did was ISRDDN to verify the ddname for
SYSTSPRT. It doesn't show up when we are logged on performing the bind
function. I can check my TSO session in SDSF with a ?. I can see SYSTSPRT
allocated to a work pack, but no data set name. I also see ACF2
violoations, but am uncertain if they are related to the allocation of the
temporary dataset.

CA thinks there is customization in our shop that is putting the bind
messages to the screen and not to the output dataset they allocate in the
Endevor process.

If you think of anything else, let me know.
Regards,

Ruth Sutlic



James Campbell

Re: Endevor/Binds using IKJEFT01 SYSTSPRT
(in response to Ruth Sutlic)
Is it possible to have SYSTSPRT allocated to anything other than the
terminal in foreground mode? I would think not - because otherwise
how would you ever see anything on the terminal?

It's more likely that there is a check for the running mode (fore or
back ground) and if foreground an OUTTRAP to intercept the bind
output. This is then not correctly processing the bind failure.

James Campbell

On 16 Dec 2002 at 22:20, Marcel Harleman wrote:

> Hi,
>
> I have not run into this problem but ... have you checked the SYSTSPRT
> allocation via f.i. {TSO} ISRDDN? Maybe SYSTSPRT is allocated to a
> dataset where all the output is written to. Or it is allocated to
> dummy (?).
> If so then hopefully the SYSTSPRT is not open. In that case you should
> be able to issue the command "{TSO} ALLOC F(SYSTSPRT) DA(*) REUSE" and
> all the output for SYSTSPRT will be written to the terminal.
>
> Hope this helps.
>
> Marcel.
>
> >Hello fellow Listers,
> >My CA-Endevor person has a problem when doing binds in foreground. (Batch
> >works just great). Endevor has a program that calls IKJEFT01. The missing
> >bind statements we want to see come from DDNAME SYSTSPRT. They don't show
> >up when the bind process runs in foreground.
> >CA said that we must have some customization in place that is preventing
> >this from working. I was wondering if anyone else has run into this
> >problem. Would you be willing to share what the resolution was?
> >
> >Regards,
> >Ruth Sutlic
> >
> >
> >
>
>
>



Marcel Harleman

Re: Endevor/Binds using IKJEFT01 SYSTSPRT
(in response to James Campbell)
Hi Ruth,

I tried something at work and found out the output of the BIND in
foreground mode is not sent to SYSTSPRT, but (probably) straight to
TCAS (ask your VTAM people or your OS390 people about that one).

If this is the case then the only way will be to use an outtrap
function to intercept the datastream being sent to TCAS. If Endevor
uses this then maybe CA can tell you what they do with the output that
has been trapped. If Endevor doesn't then maybe it's time they do -:)

And did you check whether the BIND actually was executed? Maybe it's
an idea to trace the activities that Endevor does regarding this BIND.
If it has been a successfull BIND you should be able to see so in the
DB2 catalog.

Something else: in the past I have had some troubles with Platinum
(also CA): I needed to write a pre-startup clist and made a typo. As a
result the clist supplied by Platinum did not run properly, but
because it ran with certain CONTROL options the messages informing me
something was wrong was never displayed, not on the terminal and not
in the ISPF log. It simply started and stopped without doing anything
it seemed.
I found out after I manually changed the CONTROL options. Perhaps
something similar is the case here and you need to manually change the
CONTROL options (or maybe there's a trace-option in Endevor you can
use) so you get all the messages and maybe even the CONLIST output.

Well, out of thought for the moment. Let's see if this helps. Good
luck!

Marcel.

>Morning Marcel,
>Yes, one of the first things we did was ISRDDN to verify the ddname for
>SYSTSPRT. It doesn't show up when we are logged on performing the bind
>function. I can check my TSO session in SDSF with a ?. I can see SYSTSPRT
>allocated to a work pack, but no data set name. I also see ACF2
>violoations, but am uncertain if they are related to the allocation of the
>temporary dataset.
>
>CA thinks there is customization in our shop that is putting the bind
>messages to the screen and not to the output dataset they allocate in the
>Endevor process.
>
>If you think of anything else, let me know.
>Regards,
>
>Ruth Sutlic
>
>
>



Marcel Harleman

Re: Endevor/Binds using IKJEFT01 SYSTSPRT
(in response to Marcel Harleman)
>Is it possible to have SYSTSPRT allocated to anything other than the
>terminal in foreground mode? I would think not - because otherwise
>how would you ever see anything on the terminal?

In foreground there is no SYSTSPRT allocation. In foreground
datastreams from and to terminals are handled by TCAS. TCAS sends and
gets the data from the TSO address space.
Allocating a ddname with DA(*) will send or receive all datastreams
via that ddname to or from TCAS.

I found out something else though: the output of the bind is not sent
to SYSTSPRT but (probably) straight to TCAS. IKJEFT01 is able to
recognize whether it's running in foreground or background mode and
most likely uses this to decide whether it should send the output to
TCAS or to a SYSTSPRT-allocation.

Marcel.



Ruth Sutlic

Re: Endevor/Binds using IKJEFT01 SYSTSPRT
(in response to Marcel Harleman)
James/Marcel,
Thanks for your reponses. I've done some reading on OUTTRAP. But, the
manual indicates it's a function with REXX? The Endevor product is coded in
our CLIST library.

I went and verfied that the bind is really working. I did a query against
the catalog and all my stuff shows up. So, I know that part is working.

Marcel, I'm hoping your testing is something that can be verified. If the
problem is that IKJEFT01 doesn't put the SYSTSPRT, then I can send this
back to CA for them to try and trap the messages.

I incorrectly stated that we are not getting the messages. The problem is
that they come back to the terminal. In the Endevor process, they allocate
a dataset to SYSTSPRT and are supposed to write to it. At the end of the
bind process, these statements should be able to be viewed by the
programmer with all the other output. They don't show up at all in
foreground. But, they do show up with all the other output when run in
batch.

I've gone back through the Endevor install manual to verify we didn't miss
anything in IKJTSO00 in SYS1.PARMLIB. All those steps have been completed.
I read through IKJTSO00 to see if some other option needed set, but didn't
turn up anything.

I've gone through SMP and verified we don't have any usermod's on this
module.

I have opened a PMR with IBM to request assistance with IKJEFT01 and how to
trap the output from the screen to send to a dataset.

Thank you, again for your responses. You gave me more things to check and
verify.

Regards,
Ruth Sutlic



James Campbell

Re: Endevor/Binds using IKJEFT01 SYSTSPRT
(in response to Ruth Sutlic)
CLISTs also have an OUTTRAP like mechanism - implemented using
&SYSOUTTRAP and &SYSOUTLINE.

James Campbell

On 17 Dec 2002 at 15:01, Ruth Sutlic wrote:

> James/Marcel,
> Thanks for your reponses. I've done some reading on OUTTRAP. But, the
> manual indicates it's a function with REXX? The Endevor product is coded in
> our CLIST library.
>
<rest snipped>



Marcel Harleman

Re: Endevor/Binds using IKJEFT01 SYSTSPRT
(in response to James Campbell)
On Tue, 17 Dec 2002 15:01:10 -0600, you wrote:

>Marcel, I'm hoping your testing is something that can be verified. If the
>problem is that IKJEFT01 doesn't put the SYSTSPRT, then I can send this
>back to CA for them to try and trap the messages.

My testing was as follows.

I made a SYSTSPRT dataset.

I used it in batch and the dataset was filled via a BIND so I knew the
DCB was OK.

I verified there was no SYSTSPRT allocation in my TSO session. So I
knew the data was not sent to SYSTSPRT in the first place: there was
no allocation of the ddname.

Then I allocated the dataset to ddname SYSTSPRT in my TSO session and
verified that went OK. I started the DB2I panels, went to the BIND
panel and did a BIND. The output went to the screen. After
deallocation of SYSTSPRT I tried a browse of the dataset and it was
empty. I repeated this with several setting of the TSO profile
(INTERCOM, WPTMSG and so on), everytime finding out the SYSTSPRT had
not been filled.

I used a Rexx procedure then to do a BIND after I allocated SYSTSPRT
via that Rexx. In batch this worked fine: the output went to the
dataset. In foreground the output went to the screen. Then I issued an
outtrap and did not get output on the screen. I sent the trapped
output to another dataset allocated to SYSOUT.

So if you want to repeat it, this is has been my scenario.

This behaviour made me realise I had forgotten an important aspect:
TCAS. I did not have the time to read all of it in the manuals for TSO
and Communications Server.

Marcel.



Ruth Sutlic

Re: Endevor/Binds using IKJEFT01 SYSTSPRT
(in response to Marcel Harleman)
Marcel,
I'm so grateful for all the time you have spent on this and the detail for
your testing. Thank you.

IBM doesn't believe this is their problem.They are going to give me some
traces to invoke that they require when debugging ISPF type problems. (I
don't have them, yet.) I'm supposed to send this to CA to help them debug
since I don't have the source to the program making the call.

Thanks you, again.
Regards,
Ruth Sutlic



Marcel Harleman

Re: Endevor/Binds using IKJEFT01 SYSTSPRT
(in response to Ruth Sutlic)
>Marcel,
>I'm so grateful for all the time you have spent on this and the detail for
>your testing. Thank you.

You're welcome. And all in all it was not much time. I went curious as
well since I too expected the output to appear in SYSTSPRT.

>
>IBM doesn't believe this is their problem.

Me neither. I think it's the famous "works as designed" and "sorry if
you misunderstood" -:)

>They are going to give me some
>traces to invoke that they require when debugging ISPF type problems. (I
>don't have them, yet.) I'm supposed to send this to CA to help them debug
>since I don't have the source to the program making the call.
>
>Thanks you, again.
>Regards,
>Ruth Sutlic
>
>
>