Conference azur::mcc

4870.0. "TSAM doesn't work " by ZUR01::SCHNEIDERR () Tue Apr 13 1993 07:05

Hello,

This problem is discussed in an earlier notes entry, too. But no solution is 
given.

We have the following problem on different MCC versions: 1.2.3, 1.3 and on 
different VMS versions 5.5.x.
The TSAM doesn't work at all. No TS can be reached, or registered. We tried to
find out something. The MCC_TS_AM_SRV process is LEF. One of the both mailboxes
the TSAM process has a channel open, is busy and one I/O is outstanding. 
That seems to be normal. The TSAM process has this state right after it is
started. 
If I look to a system, on that the TSAM works proper. You can see the following
if you do an operation on a server.

The mailbox is not busy anymore.
No outstanding IO anymore
A Network device is created (seems to be from callable TSM)
An oter device NET.. is created
An channel is opened to the new Network device.

MCC makes the operation successful

The channel to the Netork device disapears
The Network device disapears
The NET... device stays.
The mailbox becomes busy again
An further IO is outstanding


If you have a look to a system that doesn't work, You can see the following

The mailbox is not busy anymore.
No outstanding IO anymore

nothing further...the process is still LEF, no processtime is added. no 
network device.

You have to do CTRL C on the MCC, because the command would hang forever. But if
you do that. The MCC_TS_AM_SRV process doesn't go back to his rootstate (mailbox
busy and one IO outstanding). And the process won't react on futher calls.

Question:
- Are we realy the onlyones in the whole world with that problem?
- Is there any work on that problem?
- Why is the networkdevice not created?
- could you send me the source of TSAM, then we are able to do some further 
  investigations by ourselves? We should know where the process is exactly 
�  hanging, therefor we need the source. We need to know what TSAM does at this
  time.
- Why doesn't the TSAM process go back to his rootstate?

In earlier notes is written that the problem disapeared when they installed the
TSAM upgrade. In our case it doesn't work. We saw thas on three different MCC
systems. On one the problem disapeared after restart of the TSAM process. On the
two others it doesn't work. MCC_Audit says that all systemparameters are o.k.


Thanks and regards

Roland

    
    I have a similar problem once with TSAM. I solved it by chance by
    defining the TS_AM_STACK logical (refer note 4639). I didn't really 
    understand why it made such a difference. Try it , if it works  post a reply
    here . May be someone can explain the reasons behind it. 
    
Andrew

Hello Andrew,

Thanks for your answer. But it doesn't help. This problem is discussed in many
notes entries, but all the different solutions are some kind of tries. Nowhere is
a professional solution. I tied out all the different "I tried and it runed, but
I don't know why" things. 
We have here some realy important customers who wait for a real professional
solution. I tried it with notes, because I won't open lots of CLDs, but now
I must. I will open one.

Thanks again for your answer.

Regards Roland