I found a strange behavier from a COBOL server(fault tolerant) running on G=
uardian and NOT on Pathway. RECEIVE-CONTROL says the table occurs for 100 t=
imes but the program is able to allow 101 opens and I verified that using W=
HOHAS. Have anyone seen such a behaviour from COBOL programs? I expected er=
ror 12 once it crosses 100 but strange.

  RECEIVE-CONTROL.
      TABLE OCCURS 100 TIMES
      SYNCDEPTH IS 1
      REPLY CONTAINS 1 CHARACTERS
      ERROR CODE IS SOME-ERROR
      MESSAGE SOURCE IS RECEIVE-INFO.

And WHOHAS print(after eliminating confidential info):

Openers	of \NODE.$PROC=09
pid=A0=A0=A0		opens
0,10		1
0,58		1
0,62		1
0,78		1
0,94		1
0,124		1
0,132		1
0,135		1
0,159		1
0,175		1
0,177		1
0,180		1
0,188		1
0,197		1
0,198		1
0,199		1
0,203		1
0,205		1
0,207		1
0,213		1
0,223		1
0,230		1
0,235		1
0,240		1
0,251		1
1,39		1
1,52		1
1,89		1
1,113		1
1,122		1
1,124		1
1,136		1
1,142		1
1,157		1
1,189		1
1,191		1
1,198		1
1,227		1
1,230		1
1,236		1
1,243		1
2,12		1
2,29		1
2,33		1
2,46		1
2,70		1
2,84		1
2,101		1
2,102		1
2,116		1
2,155		1
2,157		1
2,186		1
2,206		1
2,232		1
3,64		1
3,76		1
3,83		1
3,101		1
3,107		1
3,133		1
3,163		1
3,183		1
3,186		1
3,210		1
3,215		1
3,241		1
3,251		1
4,34		1
4,47		1
4,56		1
4,68		1
4,80		1
4,90		1
4,113		1
4,132		1
4,135		1
4,144		1
4,146		1
4,159		1
4,216		1
4,239		1
4,242		1
4,246		1
4,252		1
5,26		1
5,31		1
5,52		1
5,60		1
5,74		1
5,87		1
5,115		1
5,136		1
5,184     =A0=A0=A0=A0  1
5,188		1
5,189		1
5,196		1
5,208		1
5,212		1
5,219		1
5,223		1

=E5=9C=A8 2012=E5=B9=B47=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8CUTC+=
8=E4=B8=8B=E5=8D=882=E6=97=B615=E5=88=8615=E7=A7=92=EF=BC=8CAnupam Das=E5=
=86=99=E9=81=93=EF=BC=9A
> I found a strange behavier from a COBOL server(fault tolerant) running on=
 Guardian and NOT on Pathway. RECEIVE-CONTROL says the table occurs for 100=
 times but the program is able to allow 101 opens and I verified that using=
 WHOHAS. Have anyone seen such a behaviour from COBOL programs? I expected =
error 12 once it crosses 100 but strange.
>=20
>   RECEIVE-CONTROL.
>       TABLE OCCURS 100 TIMES
>       SYNCDEPTH IS 1
>       REPLY CONTAINS 1 CHARACTERS
>       ERROR CODE IS SOME-ERROR
>       MESSAGE SOURCE IS RECEIVE-INFO.
>=20
> And WHOHAS print(after eliminating confidential info):
>=20
> Openers	of \NODE.$PROC=09
> pid=C2=A0=C2=A0=C2=A0		opens
> 0,10		1
> 0,58		1
> 0,62		1
> 0,78		1
> 0,94		1
> 0,124		1
> 0,132		1
> 0,135		1
> 0,159		1
> 0,175		1
> 0,177		1
> 0,180		1
> 0,188		1
> 0,197		1
> 0,198		1
> 0,199		1
> 0,203		1
> 0,205		1
> 0,207		1
> 0,213		1
> 0,223		1
> 0,230		1
> 0,235		1
> 0,240		1
> 0,251		1
> 1,39		1
> 1,52		1
> 1,89		1
> 1,113		1
> 1,122		1
> 1,124		1
> 1,136		1
> 1,142		1
> 1,157		1
> 1,189		1
> 1,191		1
> 1,198		1
> 1,227		1
> 1,230		1
> 1,236		1
> 1,243		1
> 2,12		1
> 2,29		1
> 2,33		1
> 2,46		1
> 2,70		1
> 2,84		1
> 2,101		1
> 2,102		1
> 2,116		1
> 2,155		1
> 2,157		1
> 2,186		1
> 2,206		1
> 2,232		1
> 3,64		1
> 3,76		1
> 3,83		1
> 3,101		1
> 3,107		1
> 3,133		1
> 3,163		1
> 3,183		1
> 3,186		1
> 3,210		1
> 3,215		1
> 3,241		1
> 3,251		1
> 4,34		1
> 4,47		1
> 4,56		1
> 4,68		1
> 4,80		1
> 4,90		1
> 4,113		1
> 4,132		1
> 4,135		1
> 4,144		1
> 4,146		1
> 4,159		1
> 4,216		1
> 4,239		1
> 4,242		1
> 4,246		1
> 4,252		1
> 5,26		1
> 5,31		1
> 5,52		1
> 5,60		1
> 5,74		1
> 5,87		1
> 5,115		1
> 5,136		1
> 5,184     =C2=A0=C2=A0=C2=A0=C2=A0  1
> 5,188		1
> 5,189		1
> 5,196		1
> 5,208		1
> 5,212		1
> 5,219		1
> 5,223		1

I don't have much experience for this, here is some manual for your referen=
ce, hope it helps

"When the number of active requesters fills the receive-control table, OPEN=
 messages from new requesters are refused with a run-time error message and=
 are not reported to your program. OPEN messages received from backup proce=
sses of active requesters are still accepted and reported."

Thanks

Will

"William, Lin" <cdyjldy@msn.com> wrote in
news:74d259ed-8374-4057-9fa2-13a861e07714@googlegroups.com: 

> "When the number of active requesters fills the receive-control
> table, OPEN messages from new requesters are refused with a
> run-time error message and are not reported to your program.
> OPEN messages received from backup processes of active
> requesters are still accepted and reported." 

That is indeed the explanation: the 101 openers that the OP sees include at least one process 
pair.

> That is indeed the explanation: the 101 openers that the OP sees include at least one process 
> pair.

Yes even I expected the same but unfortunately I really could not find a single process which is running as process pair. In fact, I know none of our Pathway components are fault tolerant :-).

But as I said, the Guardian server is fault tolerant. Is it's backup process interfering the calculation of the counts? I will have to check though using PSTATE. Thanks Doug and Wil for your time and inputs.

Anupam Das wrote:
>>That is indeed the explanation: the 101 openers that the OP sees include at least one process 
>>pair.
> 
> 
> Yes even I expected the same but unfortunately I really could not find a single process which is running as process pair. In fact, I know none of our Pathway components are fault tolerant :-).
> 
> But as I said, the Guardian server is fault tolerant. Is it's backup process interfering the calculation of the counts? I will have to check though using PSTATE. Thanks Doug and Wil for your time and inputs.
> 

Each entry in the table has space for recording the information about both the primary and backup of a process-pair, so, no, backup processes don't interfere with the calculation of the counts, but they might have confused you about how many table slots were needed for the set of openers you have.

A good test to do would be to make a test server with the TABLE OCCURS value of 2 or 3 and open the server from 3 or 4 different non-fault-tolerant processes.  If you get an error 12 on the 3rd or 4th open, then things are probably working correctly.

There is a small chance that COBOL makes the table one bigger than requested, but I kind of doubt that is the explanation.

I have a vage, mult-decades old memory that Cobol RTL does allow one
more open than requested in TABLE OCCURS clause.  I can't remember why
though.

On Tue, 24 Jul 2012 16:57:09 -0400, Keith Dick <kdick@acm.org> wrote:

>Anupam Das wrote:
>>>That is indeed the explanation: the 101 openers that the OP sees include at least one process 
>>>pair.
>> 
>> 
>> Yes even I expected the same but unfortunately I really could not find a single process which is running as process pair. In fact, I know none of our Pathway components are fault tolerant :-).
>> 
>> But as I said, the Guardian server is fault tolerant. Is it's backup process interfering the calculation of the counts? I will have to check though using PSTATE. Thanks Doug and Wil for your time and inputs.
>> 
>
>Each entry in the table has space for recording the information about both the primary and backup of a process-pair, so, no, backup processes don't interfere with the calculation of the counts, but they might have confused you about how many table slots were needed for the set of openers you have.
>
>A good test to do would be to make a test server with the TABLE OCCURS value of 2 or 3 and open the server from 3 or 4 different non-fault-tolerant processes.  If you get an error 12 on the 3rd or 4th open, then things are probably working correctly.
>
>There is a small chance that COBOL makes the table one bigger than requested, but I kind of doubt that is the explanation.

It might have been done so that Pathmon could 'open/close' the server
without error, even if all links were granted...Anyone else remember?

On Tue, 24 Jul 2012 18:17:57 -0500, Bill Honaker
<no_spam_bhonaker__@x_i_d.com> wrote:

>I have a vage, mult-decades old memory that Cobol RTL does allow one
>more open than requested in TABLE OCCURS clause.  I can't remember why
>though.

Bill Honaker wrote:
> It might have been done so that Pathmon could 'open/close' the server
> without error, even if all links were granted...Anyone else remember?
> 
> On Tue, 24 Jul 2012 18:17:57 -0500, Bill Honaker
> <no_spam_bhonaker__@x_i_d.com> wrote:
> 
> 
>>I have a vage, mult-decades old memory that Cobol RTL does allow one
>>more open than requested in TABLE OCCURS clause.  I can't remember why
>>though.

As far as I know, Pathmon does not open servers except to send them the startup message sequence, which would not involve use of the RECEIVE-CONTROL table, anyway.  So I don't believe that is the reason why COBOL would put one extra entry into the RECEIVE-CONTROL table.  There might be some other reason, but except just to allow for someone miscalculating the number of openers the program must support, I cannot think of a reason for allowing an additional opener in the table.

I have a vague memory that at one time, the way Pathway arranged that static server processes would keep running was to open the static server processes from Pathmon, so that the opener count would not fall to zero under any circumstances except when a command to stop the serverclass was entered.  However, I've been told that it never worked that way, and I do not remember there ever being instructions in the Pathway manuals to tell programmers writing servers in languages other than COBOL to allow for the extra open from Pathmon, so my vague memory probably is wrong.  Perhaps there was consideration of doing static server processes that way back when Pathway was being designed, but that method was not chosen.  Or maybe I just dreamed it all.

Unless Anupam determines that none of those 101 opens was from the backup process of one of the other openers (or someone does another experiment about this), we don't actually know that COBOL currently is allowing an extra opener.

Le mardi 24 juillet 2012 02:15:15 UTC-4, Anupam Das a =E9crit=A0:
> I found a strange behavier from a COBOL server(fault tolerant) running on=
 Guardian and NOT on Pathway. RECEIVE-CONTROL says the table occurs for 100=
 times but the program is able to allow 101 opens and I verified that using=
 WHOHAS. Have anyone seen such a behaviour from COBOL programs? I expected =
error 12 once it crosses 100 but strange.
>=20
>   RECEIVE-CONTROL.
>       TABLE OCCURS 100 TIMES
>       SYNCDEPTH IS 1
>       REPLY CONTAINS 1 CHARACTERS
>       ERROR CODE IS SOME-ERROR
>       MESSAGE SOURCE IS RECEIVE-INFO.
>=20
> And WHOHAS print(after eliminating confidential info):
>=20
> Openers	of \NODE.$PROC=09
> pid=A0=A0=A0		opens
> 0,10		1
> 0,58		1
> 0,62		1
> 0,78		1
> 0,94		1
> 0,124		1
> 0,132		1
> 0,135		1
> 0,159		1
> 0,175		1
> 0,177		1
> 0,180		1
> 0,188		1
> 0,197		1
> 0,198		1
> 0,199		1
> 0,203		1
> 0,205		1
> 0,207		1
> 0,213		1
> 0,223		1
> 0,230		1
> 0,235		1
> 0,240		1
> 0,251		1
> 1,39		1
> 1,52		1
> 1,89		1
> 1,113		1
> 1,122		1
> 1,124		1
> 1,136		1
> 1,142		1
> 1,157		1
> 1,189		1
> 1,191		1
> 1,198		1
> 1,227		1
> 1,230		1
> 1,236		1
> 1,243		1
> 2,12		1
> 2,29		1
> 2,33		1
> 2,46		1
> 2,70		1
> 2,84		1
> 2,101		1
> 2,102		1
> 2,116		1
> 2,155		1
> 2,157		1
> 2,186		1
> 2,206		1
> 2,232		1
> 3,64		1
> 3,76		1
> 3,83		1
> 3,101		1
> 3,107		1
> 3,133		1
> 3,163		1
> 3,183		1
> 3,186		1
> 3,210		1
> 3,215		1
> 3,241		1
> 3,251		1
> 4,34		1
> 4,47		1
> 4,56		1
> 4,68		1
> 4,80		1
> 4,90		1
> 4,113		1
> 4,132		1
> 4,135		1
> 4,144		1
> 4,146		1
> 4,159		1
> 4,216		1
> 4,239		1
> 4,242		1
> 4,246		1
> 4,252		1
> 5,26		1
> 5,31		1
> 5,52		1
> 5,60		1
> 5,74		1
> 5,87		1
> 5,115		1
> 5,136		1
> 5,184     =A0=A0=A0=A0  1
> 5,188		1
> 5,189		1
> 5,196		1
> 5,208		1
> 5,212		1
> 5,219		1
> 5,223		1


I believe this is an old anomaly that I remember seeing at least 20 years a=
go.

I think, back then, somebody explained that it had to do with either the Co=
bol runtime library or compiler: arrays are defined starting at 1 in Cobol,=
 TAL starts at zero.  Somehow, something got lost in translation and Cobol =
ended up acquiring an extra Receive table entry.

I would try specifying the table length as zero or 1, and wait eagerly to s=
ee what happens when you fire up multiple requests to it.

Actually, Pathmon will open a server process it has started so that a
Pathcom 'STOP' command will work even if no links have ever been
granted.  I think that open happens even if there are links granted.

On Wed, 25 Jul 2012 11:18:03 -0400, Keith Dick <kdick@acm.org> wrote:

>Bill Honaker wrote:
>> It might have been done so that Pathmon could 'open/close' the server
>> without error, even if all links were granted...Anyone else remember?
>> 
>> On Tue, 24 Jul 2012 18:17:57 -0500, Bill Honaker
>> <no_spam_bhonaker__@x_i_d.com> wrote:
>> 
>> 
>>>I have a vage, mult-decades old memory that Cobol RTL does allow one
>>>more open than requested in TABLE OCCURS clause.  I can't remember why
>>>though.
>
>As far as I know, Pathmon does not open servers except to send them the startup message sequence, which would not involve use of the RECEIVE-CONTROL table, anyway.  So I don't believe that is the reason why COBOL would put one extra entry into the RECEIVE-CONTROL table.  There might be some other reason, but except just to allow for someone miscalculating the number of openers the program must support, I cannot think of a reason for allowing an additional opener in the table.
>
>I have a vague memory that at one time, the way Pathway arranged that static server processes would keep running was to open the static server processes from Pathmon, so that the opener count would not fall to zero under any circumstances except when a command to stop the serverclass was entered.  However, I've been told that it never worked that way, and I do not remember there ever being instructions in the Pathway manuals to tell programmers writing servers in languages other than COBOL to allow for the extra open from Pathmon, so my vague memory probably is wrong.  Perhaps there was consideration of doing static server processes that way back when Pathway was being designed, but that method was not chosen.  Or maybe I just dreamed it all.
>
>Unless Anupam determines that none of those 101 opens was from the backup process of one of the other openers (or someone does another experiment about this), we don't actually know that COBOL currently is allowing an extra opener.

Bill Honaker wrote:
> Actually, Pathmon will open a server process it has started so that a
> Pathcom 'STOP' command will work even if no links have ever been
> granted.  I think that open happens even if there are links granted.

I think you are correct that that is a case in which Pathmon will open a server process.  I didn't think about that case when writing my reply.  I have no idea whether it always does the OPEN and CLOSE, or only if it notices that no links have been granted to that process.  It might do the OPEN and CLOSE all the time, and just ignore an error 12, assuming that if it gets an error 12, there have been links granted.  In either case (only done if no links or ignore error 12), no extra entry in the RECEIVE-CONTROL table would be needed.

I still don't recall ever seeing directions for writing servers in other languages that say the server must allow for one more opener than the configured MAXLINKS value, so if something depends on a server process being able to support more than MAXLINKS openers, servers written in other languages would not work in those circumstances, so I imagine there is no need for an extra entry in the RECEIVE-CONTROL table.  And I repeat once more that we do not yet know whether COBOL actually does allocate an extra entry.  Some more investigation than Anupam did is necessary to tell for sure.

> 
> On Wed, 25 Jul 2012 11:18:03 -0400, Keith Dick <kdick@acm.org> wrote:
> 
> 
>>Bill Honaker wrote:
>>
>>>It might have been done so that Pathmon could 'open/close' the server
>>>without error, even if all links were granted...Anyone else remember?
>>>
>>>On Tue, 24 Jul 2012 18:17:57 -0500, Bill Honaker
>>><no_spam_bhonaker__@x_i_d.com> wrote:
>>>
>>>
>>>
>>>>I have a vage, mult-decades old memory that Cobol RTL does allow one
>>>>more open than requested in TABLE OCCURS clause.  I can't remember why
>>>>though.
>>
>>As far as I know, Pathmon does not open servers except to send them the startup message sequence, which would not involve use of the RECEIVE-CONTROL table, anyway.  So I don't believe that is the reason why COBOL would put one extra entry into the RECEIVE-CONTROL table.  There might be some other reason, but except just to allow for someone miscalculating the number of openers the program must support, I cannot think of a reason for allowing an additional opener in the table.
>>
>>I have a vague memory that at one time, the way Pathway arranged that static server processes would keep running was to open the static server processes from Pathmon, so that the opener count would not fall to zero under any circumstances except when a command to stop the serverclass was entered.  However, I've been told that it never worked that way, and I do not remember there ever being instructions in the Pathway manuals to tell programmers writing servers in languages other than COBOL to allow for the extra open from Pathmon, so my vague memory probably is wrong.  Perhaps there was consideration of doing static server processes that way back when Pathway was being designed, but that method was not chosen.  Or maybe I just dreamed it all.
>>
>>Unless Anupam determines that none of those 101 opens was from the backup process of one of the other openers (or someone does another experiment about this), we don't actually know that COBOL currently is allowing an extra opener.

On Wednesday, July 25, 2012 6:30:56 PM UTC-5, Keith wrote:
> Bill Honaker wrote:
> > Actually, Pathmon will open a server process it has started so that =
a
> > Pathcom 'STOP' command will work even if no links have ever =
been
> > granted.  I think that open happens even if there are links granted.
>=20
> I think you are correct that that is a case in which Pathmon will open a =
server process.  I didn't think about that case when writing my reply. =
 I have no idea whether it always does the OPEN and CLOSE, or only if it no=
tices that no links have been granted to that process.  It might do the OPE=
N and CLOSE all the time, and just ignore an error 12, assuming that if it =
gets an error 12, there have been links granted.  In either case (only done=
 if no links or ignore error 12), no extra entry in the RECEIVE-CONTROL tab=
le would be needed.
>=20
> I still don't recall ever seeing directions for writing servers in ot=
her languages that say the server must allow for one more opener than the c=
onfigured MAXLINKS value, so if something depends on a server process being=
 able to support more than MAXLINKS openers, servers written in other langu=
ages would not work in those circumstances, so I imagine there is no need f=
or an extra entry in the RECEIVE-CONTROL table.  And I repeat once more tha=
t we do not yet know whether COBOL actually does allocate an extra entry.  =
Some more investigation than Anupam did is necessary to tell for sure.


I went back and checked a couple of textbooks from my days as a Tandem inst=
ructor to confirm my recollection of this server behavior:
Upon server startup the PATHMON process will open the server process, send =
the initial startup message, and then close its open on the server. After t=
hat all the openers on the server will be requester processes (such as TCP =
or LINKMON processes).=20

On 07/26/2012 09:30 AM, Keith Dick wrote:
> Bill Honaker wrote:
>> Actually, Pathmon will open a server process it has started so that a
>> Pathcom 'STOP' command will work even if no links have ever been
>> granted.  I think that open happens even if there are links granted.
> 
> I think you are correct that that is a case in which Pathmon will open a
> server process.  I didn't think about that case when writing my reply. 
> I have no idea whether it always does the OPEN and CLOSE, or only if it
> notices that no links have been granted to that process.  It might do
> the OPEN and CLOSE all the time, and just ignore an error 12, assuming
> that if it gets an error 12, there have been links granted.  In either
> case (only done if no links or ignore error 12), no extra entry in the
> RECEIVE-CONTROL table would be needed.
> 
> I still don't recall ever seeing directions for writing servers in other
> languages that say the server must allow for one more opener than the
> configured MAXLINKS value, so if something depends on a server process
> being able to support more than MAXLINKS openers, servers written in
> other languages would not work in those circumstances, so I imagine
> there is no need for an extra entry in the RECEIVE-CONTROL table.  And I
> repeat once more that we do not yet know whether COBOL actually does
> allocate an extra entry.  Some more investigation than Anupam did is
> necessary to tell for sure.
> 
>>
>> On Wed, 25 Jul 2012 11:18:03 -0400, Keith Dick <kdick@acm.org> wrote:
>>
>>
>>> Bill Honaker wrote:
>>>
>>>> It might have been done so that Pathmon could 'open/close' the server
>>>> without error, even if all links were granted...Anyone else remember?
>>>>
>>>> On Tue, 24 Jul 2012 18:17:57 -0500, Bill Honaker
>>>> <no_spam_bhonaker__@x_i_d.com> wrote:
>>>>
>>>>
>>>>
>>>>> I have a vage, mult-decades old memory that Cobol RTL does allow one
>>>>> more open than requested in TABLE OCCURS clause.  I can't remember why
>>>>> though.
>>>
>>> As far as I know, Pathmon does not open servers except to send them
>>> the startup message sequence, which would not involve use of the
>>> RECEIVE-CONTROL table, anyway.  So I don't believe that is the reason
>>> why COBOL would put one extra entry into the RECEIVE-CONTROL table. 
>>> There might be some other reason, but except just to allow for
>>> someone miscalculating the number of openers the program must
>>> support, I cannot think of a reason for allowing an additional opener
>>> in the table.
>>>
>>> I have a vague memory that at one time, the way Pathway arranged that
>>> static server processes would keep running was to open the static
>>> server processes from Pathmon, so that the opener count would not
>>> fall to zero under any circumstances except when a command to stop
>>> the serverclass was entered.  However, I've been told that it never
>>> worked that way, and I do not remember there ever being instructions
>>> in the Pathway manuals to tell programmers writing servers in
>>> languages other than COBOL to allow for the extra open from Pathmon,
>>> so my vague memory probably is wrong.  Perhaps there was
>>> consideration of doing static server processes that way back when
>>> Pathway was being designed, but that method was not chosen.  Or maybe
>>> I just dreamed it all.
>>>
>>> Unless Anupam determines that none of those 101 opens was from the
>>> backup process of one of the other openers (or someone does another
>>> experiment about this), we don't actually know that COBOL currently
>>> is allowing an extra opener.

I did a test with TABLE OCCURS 3 TIMES. The fourth opener of the process
received error 12.

I tested using COBOL85, NMCOBOL and ECOBOL compilers.

Perhaps some of Anupam's openers are transient in nature.

Tone wrote:
> On 07/26/2012 09:30 AM, Keith Dick wrote:
> 
>>Bill Honaker wrote:
>>
>>>Actually, Pathmon will open a server process it has started so that a
>>>Pathcom 'STOP' command will work even if no links have ever been
>>>granted.  I think that open happens even if there are links granted.
>>
>>I think you are correct that that is a case in which Pathmon will open a
>>server process.  I didn't think about that case when writing my reply. 
>>I have no idea whether it always does the OPEN and CLOSE, or only if it
>>notices that no links have been granted to that process.  It might do
>>the OPEN and CLOSE all the time, and just ignore an error 12, assuming
>>that if it gets an error 12, there have been links granted.  In either
>>case (only done if no links or ignore error 12), no extra entry in the
>>RECEIVE-CONTROL table would be needed.
>>
>>I still don't recall ever seeing directions for writing servers in other
>>languages that say the server must allow for one more opener than the
>>configured MAXLINKS value, so if something depends on a server process
>>being able to support more than MAXLINKS openers, servers written in
>>other languages would not work in those circumstances, so I imagine
>>there is no need for an extra entry in the RECEIVE-CONTROL table.  And I
>>repeat once more that we do not yet know whether COBOL actually does
>>allocate an extra entry.  Some more investigation than Anupam did is
>>necessary to tell for sure.
>>
>>
>>>On Wed, 25 Jul 2012 11:18:03 -0400, Keith Dick <kdick@acm.org> wrote:
>>>
>>>
>>>
>>>>Bill Honaker wrote:
>>>>
>>>>
>>>>>It might have been done so that Pathmon could 'open/close' the server
>>>>>without error, even if all links were granted...Anyone else remember?
>>>>>
>>>>>On Tue, 24 Jul 2012 18:17:57 -0500, Bill Honaker
>>>>><no_spam_bhonaker__@x_i_d.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I have a vage, mult-decades old memory that Cobol RTL does allow one
>>>>>>more open than requested in TABLE OCCURS clause.  I can't remember why
>>>>>>though.
>>>>
>>>>As far as I know, Pathmon does not open servers except to send them
>>>>the startup message sequence, which would not involve use of the
>>>>RECEIVE-CONTROL table, anyway.  So I don't believe that is the reason
>>>>why COBOL would put one extra entry into the RECEIVE-CONTROL table. 
>>>>There might be some other reason, but except just to allow for
>>>>someone miscalculating the number of openers the program must
>>>>support, I cannot think of a reason for allowing an additional opener
>>>>in the table.
>>>>
>>>>I have a vague memory that at one time, the way Pathway arranged that
>>>>static server processes would keep running was to open the static
>>>>server processes from Pathmon, so that the opener count would not
>>>>fall to zero under any circumstances except when a command to stop
>>>>the serverclass was entered.  However, I've been told that it never
>>>>worked that way, and I do not remember there ever being instructions
>>>>in the Pathway manuals to tell programmers writing servers in
>>>>languages other than COBOL to allow for the extra open from Pathmon,
>>>>so my vague memory probably is wrong.  Perhaps there was
>>>>consideration of doing static server processes that way back when
>>>>Pathway was being designed, but that method was not chosen.  Or maybe
>>>>I just dreamed it all.
>>>>
>>>>Unless Anupam determines that none of those 101 opens was from the
>>>>backup process of one of the other openers (or someone does another
>>>>experiment about this), we don't actually know that COBOL currently
>>>>is allowing an extra opener.
> 
> 
> I did a test with TABLE OCCURS 3 TIMES. The fourth opener of the process
> received error 12.
> 
> I tested using COBOL85, NMCOBOL and ECOBOL compilers.
> 
> Perhaps some of Anupam's openers are transient in nature.

Thanks for doing that test.  I think that makes it pretty clear that the RECEIVE-CONTROL table has only the number of entries specified by the OCCURS.

You might be right that during the time it took for WHOHAS to run, one or more of the openers closed the process and another one opened it.  Or it could be as Doug suggested that one or more of the openers was a backup process of another opener (both primary and backup openers are recorded in the same entry of RECEIVE-CONTROL).

joan.mathew@gmail.com wrote:
> On Wednesday, July 25, 2012 6:30:56 PM UTC-5, Keith wrote:
> 
>>Bill Honaker wrote:
>>> Actually, Pathmon will open a server process it has started so that a
>>> Pathcom 'STOP' command will work even if no links have ever been
>>> granted.  I think that open happens even if there are links granted.
>>
>>I think you are correct that that is a case in which Pathmon will open a server process.  I didn't think about that case when writing my reply.  I have no idea whether it always does the OPEN and CLOSE, or only if it notices that no links have been granted to that process.  It might do the OPEN and CLOSE all the time, and just ignore an error 12, assuming that if it gets an error 12, there have been links granted.  In either case (only done if no links or ignore error 12), no extra entry in the RECEIVE-CONTROL table would be needed.
>>
>>I still don't recall ever seeing directions for writing servers in other languages that say the server must allow for one more opener than the configured MAXLINKS value, so if something depends on a server process being able to support more than MAXLINKS openers, servers written in other languages would not work in those circumstances, so I imagine there is no need for an extra entry in the RECEIVE-CONTROL table.  And I repeat once more that we do not yet know whether COBOL actually does allocate an extra entry.  Some more investigation than Anupam did is necessary to tell for sure.
> 
> 
> 
> I went back and checked a couple of textbooks from my days as a Tandem instructor to confirm my recollection of this server behavior:
> Upon server startup the PATHMON process will open the server process, send the initial startup message, and then close its open on the server. After that all the openers on the server will be requester processes (such as TCP or LINKMON processes). 
> 

Thanks for checking your old documentation.  What you describe matches what I thought was the current behaviour, except I think Bill is correct that when Pathmon is stopping a serverclass, it must open and close at least those processes for which no links have been granted, so that those processes see their opener count go from 1 to 0, which is the condition that causes a server to stop itself.  Do you believe that does not actually occur?  I imagine that is just a situation the course was not covering, and so was not mentioned in the course material.

Folks,

We discussed this in detail in Yahoo group and I totally forgot to copy the=
 content here. Here is the mail chain from Tandem_Computers@Yahoogroups.com=
 in case you wanted to know the latest update on this.

--- In Tandem_Computers@yahoogroups.com, dimandja <demoungu@... wrote:

Actually, I don't see it that way. =C2 DELETEDELAY is 3 MINS.
=20
What I would do is run WHOHAS at least twice and compare the results.
=20
________________________________
From: das_anupam77 <das.anupam77@...
To: Tandem_Computers@yahoogroups.com=20
Sent: Wednesday, August 8, 2012 8:15 AM
Subject: [Tandem_Computers] Re: Strange behavier from RECEIVE-CONTROL
 =20
=20
Yah I know you will ask me now to check whether there is any abend or not(t=
oo fast enough for WHOHAS to detect this change) :-). Well, I guess I am co=
nvinced. I missed that point last time. The reason I am convinced because I=
 see that Pathway server INFO is like this -
=20
 DELETEDELAY 3 MINS
 LINKDEPTH 1
 MAXLINKS 2
 MAXSERVERS 50
 NUMSTATIC 0
=20
LOL :-). I am convinced that server kept going on and off continously which=
 is NOT an error.
=20
--- In Tandem_Computers@yahoogroups.com, Keith Dick <kdick@ wrote:
=20
When this was being discussed earlier, someone suggested that one of the re=
quester processes might have terminated and another might have started duri=
ng the time that WHOHAS was scanning all the processes looking to see which=
 ones have the given server open.  The WHOHAS scan is not an instantaneous =
process and has no mechanism for insuring that it gets a consistent view.
 =20
In this example, it could have happened that 2,145 terminated after WHOHAS =
examined it to see whether it had the server open, then the program was sta=
rted again with the same process name, and the new process got placed at 2,=
162, all before WHOHAS looked at process 2,162.
 =20
Is the requester program in question one that is being monitored for failur=
e and automatically restarted?
 =20
-----Original Message-----
From: das_anupam77 <das.anupam77@
Sent: Aug 8, 2012 5:39 AM
To: Tandem_Computers@yahoogroups.com
Subject: [Tandem_Computers] Re: Strange behavier from RECEIVE-CONTROL
 =20
Ok, now the things are even more worse for me to believe :-). Let me share =
here my findings.
 =20
I coded a server and a client program, both in COBOL, and then tried simula=
ting the condition as discussed below. My finding is that, if I mentioned 1=
00 as the size of the RECEIVE-CONTROL, the COBOL server allows EXACTLY 100 =
and NOT a single more open. And this testing involved NO Fault Tolerant pro=
cess. So, this proves that whatever we noticed earlier has something wrong.
 =20
I then went back to check how I got 101 entries from WHOHAS when the same C=
OBOL server allows only 100 opens in test mode. With my utter surprise I fo=
und that, the WHOHAS output has printed the same process name twice for one=
 of the servers where the PINs are different but running on the same CPU! T=
his was unbelieveable for me and I have no idea how this happened. Here is =
how it is showing me in the error display.
 =20
WHOHAS - T0706AAB (H01) (01MAY2006)
(C)1981 Tandem (C)2004 Hewlett Packard Development Company, L.P.
Running on a NonStop NSE-A (NS16000) Processor under version R06
 =20
Openers of \NODE.$PROC
  pid    name      opens process filename           paid
  2, 145 $XYZ        1   $VOL.SUBVOL.FILENAME     255,255=20
  2, 162 $XYZ        1   $VOL.SUBVOL.FILENAME     255,255
 =20
I am still wondering how this is possible. The server program $VOL.SUBVOL.F=
ILENAME is NOT a fault tolerant server and neither it can run with multiple=
 PIN like DP2.
 =20
Did you guys even see this kind of incident? Thanks.