PATHSEND/SERVERCLASS SEND procedure from C

Post by uros kusar
Hi,
I'm writing C program that would get the status of the xpnet objects (stations,processes,node...). I'm using procedures described in the HP manuals(Pathsend and Server programming Manual, C/C++ programmer's Guide...) but I can't get anyting from Pathway except errors. Can you tell me what am I doing wrong?
----------------------------------------------------------------------------------------------------------------
include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <cextdecs (SERVERCLASS_SEND_, SERVERCLASS_SEND_INFO_)> nolist
#include <tal.h>
main()
{
short error, error2,pserror, fserror,countread;
char *pmon;
char *buffer;
char *sname;
pmon ="$D1MN";
sname = "SERVER-NCPI-1A";
buffer ="STATUS PROCESS P1A^BICUNI1";
error = SERVERCLASS_SEND_ (pmon,
(short) strlen(pmon), /* pathmon */
sname,
(short) strlen(sname), /* server class */
buffer,
(short) strlen(buffer),
200,
&countread,
-1); /* timeout = forever */
if (error != 0)
{
error2 = SERVERCLASS_SEND_INFO_ (&pserror, &fserror);
printf ("\nSERVERCLASS_SEND_ error = %d, pathsend error = %d, fs error = %d\n", error, pserror, fserror);
exit (1);
}
else
{
buffer [countread] = 0;
printf ("\nReply = %s\n", buffer);
}
}
----------------------------------------------------------------------------------------------------------------
SERVERCLASS_SEND_ error = 233, pathsend error = 904, fs error = 12
Best Regards,
Uros

I see two coding errors in the program you included, but I cannot say whether either of them explains why the program is not working.

One coding error is that you do not check the error return from SERVERCLASS_SEND_INFO_. If something was wrong with that call to SERVERCLASS_SEND_INFO_, the values you are displaying for pathsend error and fs error might not be true, thereby misleading you about what went wrong with the SERVERCLASS_SEND_ call.

Assuming that nothing went wrong in the SERVERCLASS_SEND_INFO_ call, the errors were 904 and 12. The 904 says that there was an error when making the link to the server. Filesystem error 12 is the generic 'file in use' error when returned from an open of a disk file, but I'm not sure how to interpret it for a failure of a link request. If we dug into the description of link management, maybe there would be a description of what error 12 means in that context, but I did not take the time to do that right now.

The other coding error is in the SERVERCLASS_SEND_ call. I am not sure it is the cause of the SERVERCLASS_SEND_ failure, but the first thing I would do is fix it and see whether that changes how the program works.

The problem is that the SERVERCLASS_SEND_ call says that the buffer argument can accept a reply of 200 characters, but that is not how you declared buffer. You declared buffer to be a char*, then initialized it to point to the string constant

"STATUS PROCESS P1A^BICUNI1"

SERVERCLASS_SEND_ puts the reply into the same buffer from which it took the outgoing message. So in your program, if it actually got a reply, it would try to store it into the memory where "STATUS PROCESS P1A^BICUNI1" is. At the very least, that will destroy the supposedly constant value of that string. It might not be able to write into that storage if the compiler sets up string constants in a read-only memory segment. If the compiler sets up the string constant in a writable memory segment, storing the reply there could overwrite whatever data is stored following that string constant, since it is nowhere near 200 bytes long.

So change your program to declare buffer to be a 200-byte array, and put the string constant into it using strcpy(). Then see whether you get a more sensible result. If you still get an error, post again and we can dig into how filesystem error 12 on a link request is supposed to be interpreted.

Randall

2021-05-28 18:51:20 UTC

Post by Keith Dick

I see two coding errors in the program you included, but I cannot say whether either of them explains why the program is not working.
One coding error is that you do not check the error return from SERVERCLASS_SEND_INFO_. If something was wrong with that call to SERVERCLASS_SEND_INFO_, the values you are displaying for pathsend error and fs error might not be true, thereby misleading you about what went wrong with the SERVERCLASS_SEND_ call.
Assuming that nothing went wrong in the SERVERCLASS_SEND_INFO_ call, the errors were 904 and 12. The 904 says that there was an error when making the link to the server. Filesystem error 12 is the generic 'file in use' error when returned from an open of a disk file, but I'm not sure how to interpret it for a failure of a link request. If we dug into the description of link management, maybe there would be a description of what error 12 means in that context, but I did not take the time to do that right now.
The other coding error is in the SERVERCLASS_SEND_ call. I am not sure it is the cause of the SERVERCLASS_SEND_ failure, but the first thing I would do is fix it and see whether that changes how the program works.
The problem is that the SERVERCLASS_SEND_ call says that the buffer argument can accept a reply of 200 characters, but that is not how you declared buffer. You declared buffer to be a char*, then initialized it to point to the string constant
"STATUS PROCESS P1A^BICUNI1"
SERVERCLASS_SEND_ puts the reply into the same buffer from which it took the outgoing message. So in your program, if it actually got a reply, it would try to store it into the memory where "STATUS PROCESS P1A^BICUNI1" is. At the very least, that will destroy the supposedly constant value of that string. It might not be able to write into that storage if the compiler sets up string constants in a read-only memory segment. If the compiler sets up the string constant in a writable memory segment, storing the reply there could overwrite whatever data is stored following that string constant, since it is nowhere near 200 bytes long.
So change your program to declare buffer to be a 200-byte array, and put the string constant into it using strcpy(). Then see whether you get a more sensible result. If you still get an error, post again and we can dig into how filesystem error 12 on a link request is supposed to be interpreted.

That's a really good catch. This is a very common coding error. The buffer used for SERVERCLASS_SEND_ also cannot be used for any other purpose while the message is being processed (same applies to WRITEREAD[XL]. It is, essentially locked, although that is not enforced by the CRE. There was a SETMODE for IPC communication but that significantly slows down your application and can eat up PFS space. Protecting buffer space during IPC operations is really important as a design consideration, particularly with IPC being implemented using DMA. A little known thing is that this can also apply to some esoteric threaded PUT socket operations. Buffer protection is critical for very high performance applications (as people who have seen the jelly bean challenge will remember - can't give more details).

An error 12 is usually returned by the server based on the number of opens/LINKDEPTH. If your server is coded to accept only one open, then you can encounter this. Check your XPNet configuration - it may be limiting opens in this situation.

Bill Honaker

2021-05-28 19:48:59 UTC

Uros,

Keith and Randall gave very valuable responses.

Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.

Bill

Keith Dick

2021-05-28 20:22:58 UTC

Uros,
Keith and Randall gave very valuable responses.
Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.
Bill

Bill,

Very good remembering that filesystem error 12 is used for attempting to start a process with a name that already exists. I should have remembered that myself. Unless Pathway's link management also uses filesystem error 12 for other problems, I'd say a duplicate process name is likely to be the explanation for this problem. Perhaps Uros has set up a test environment by duplicating the configuration of an existing environment and did not know to change the configured fixed server process names.

uros kusar

2021-05-31 11:07:05 UTC

Uros,
Keith and Randall gave very valuable responses.
Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.
Bill

Bill,
Very good remembering that filesystem error 12 is used for attempting to start a process with a name that already exists. I should have remembered that myself. Unless Pathway's link management also uses filesystem error 12 for other problems, I'd say a duplicate process name is likely to be the explanation for this problem. Perhaps Uros has set up a test environment by duplicating the configuration of an existing environment and did not know to change the configured fixed server process names.

Hi,

Thank you all for your help.

I changed the code:
1) I added SERVERCLASS_SEND_INFO output error number to see if command was succsesfully processed.
2) I changed the buffer to a 200-byte array.
3) I find some tal example of a similar program and I noticed that this tal program, sends the command to a different pathway server. I send it to the SERVER-NCPI-1A server, which is a server for P1A^NODE. But the tal program sends the command to the server SERVER-NCP, which sees all "node" servers.

It is interesting because if I send a command to SERVER-NCP I get a different error code.
SERVER-NCP:
SERVERCLASS_SEND_ error = 233, pathsend error = 904, fs error = 21

SERVER-NCP-1A:
SERVERCLASS_SEND_ error = 233, pathsend error = 904, fs error = 12

I think that the correct server is a SERVER-NCP.

---------------------------------------------------------------------------------------------------------------------------------------------
Pahway server configuration:
MAXLINKMONS 20 [CURRENTLY 2]

SERVER SERVER-NCPI-1A
LINKDEPTH 1
MAXLINKS 32
MAXSERVERS 3
PROCESS $D1AU (ASSOCIATIVE ON)

SERVER SERVER-NCP
LINKDEPTH 32
MAXLINKS 32
MAXSERVERS 3
PROCESS $D1C1
PROCESS $D1C2
PROCESS $D1C3
---------------------------------------------------------------------------------------------------------------------------------------------
code:
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <tal.h>
#include <cextdecs (SERVERCLASS_SEND_, SERVERCLASS_SEND_INFO_)> nolist
main()
{
short error, error2, pserror, fserror,countread;
char *pmon;
char buffer [200]={0};
char *sname;

pmon ="$D1MN";
sname = "SERVER-NCP";
strcpy(buffer,"STATUS PROCESS P1A^BICUNI1");

error = SERVERCLASS_SEND_ (pmon,
(short)strlen(pmon), /* pathmon */
sname,
(short)strlen(sname), /* server class */
buffer,
(short)strlen(buffer),
200,
&countread,
-1); /* timeout = forever */
if (error != 0)
{
error2 = SERVERCLASS_SEND_INFO_ (&pserror, &fserror);
printf("\nSERVERCLASS_SEND_INFO error = %d \nSERVERCLASS_SEND_ error = %d, pathsend error = %d, fs error = %d\n",error2, error, pserror, fserror);
printf("\nBuffer size = %d\n", strlen(buffer));

int i;
for(i=0; i<strlen(buffer); i++)
{
printf("%c",buffer[i]);
}
printf("\n\n\n");
exit (1);
}
else
{
buffer [countread] = 0;
printf ("\nReply = %s\n", buffer);
}
}

Keith Dick

2021-05-31 13:57:14 UTC

Uros,
Keith and Randall gave very valuable responses.
Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.
Bill

Bill,
Very good remembering that filesystem error 12 is used for attempting to start a process with a name that already exists. I should have remembered that myself. Unless Pathway's link management also uses filesystem error 12 for other problems, I'd say a duplicate process name is likely to be the explanation for this problem. Perhaps Uros has set up a test environment by duplicating the configuration of an existing environment and did not know to change the configured fixed server process names.

Hi,
Thank you all for your help.
1) I added SERVERCLASS_SEND_INFO output error number to see if command was succsesfully processed.
2) I changed the buffer to a 200-byte array.
3) I find some tal example of a similar program and I noticed that this tal program, sends the command to a different pathway server. I send it to the SERVER-NCPI-1A server, which is a server for P1A^NODE. But the tal program sends the command to the server SERVER-NCP, which sees all "node" servers.
It is interesting because if I send a command to SERVER-NCP I get a different error code.
SERVERCLASS_SEND_ error = 233, pathsend error = 904, fs error = 21
SERVERCLASS_SEND_ error = 233, pathsend error = 904, fs error = 12
I think that the correct server is a SERVER-NCP.
---------------------------------------------------------------------------------------------------------------------------------------------
MAXLINKMONS 20 [CURRENTLY 2]
SERVER SERVER-NCPI-1A
LINKDEPTH 1
MAXLINKS 32
MAXSERVERS 3
PROCESS $D1AU (ASSOCIATIVE ON)
SERVER SERVER-NCP
LINKDEPTH 32
MAXLINKS 32
MAXSERVERS 3
PROCESS $D1C1
PROCESS $D1C2
PROCESS $D1C3
---------------------------------------------------------------------------------------------------------------------------------------------
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <tal.h>
#include <cextdecs (SERVERCLASS_SEND_, SERVERCLASS_SEND_INFO_)> nolist
main()
{
short error, error2, pserror, fserror,countread;
char *pmon;
char buffer [200]={0};
char *sname;
pmon ="$D1MN";
sname = "SERVER-NCP";
strcpy(buffer,"STATUS PROCESS P1A^BICUNI1");
error = SERVERCLASS_SEND_ (pmon,
(short)strlen(pmon), /* pathmon */
sname,
(short)strlen(sname), /* server class */
buffer,
(short)strlen(buffer),
200,
&countread,
-1); /* timeout = forever */
if (error != 0)
{
error2 = SERVERCLASS_SEND_INFO_ (&pserror, &fserror);
printf("\nSERVERCLASS_SEND_INFO error = %d \nSERVERCLASS_SEND_ error = %d, pathsend error = %d, fs error = %d\n",error2, error, pserror, fserror);
printf("\nBuffer size = %d\n", strlen(buffer));
int i;
for(i=0; i<strlen(buffer); i++)
{
printf("%c",buffer[i]);
}
printf("\n\n\n");
exit (1);
}
else
{
buffer [countread] = 0;
printf ("\nReply = %s\n", buffer);
}
}

Filesystem error 21 usually means an illegal count was specified. That might mean that either the length of the buffer you are sending is wrong or the maximum reply size (200 in this case) is wrong. It might mean something else, since I don't know anything about XPNET.

Pathway servers usually take input as data structures with fixed-length fields, not a text string like you would type to a command interpreter. Are you sure that the server you are sending to is expected a text string as its input? Do you have any documentation of what this server's interface is?

I notice that, although you show a new program that displays the value of error2, the output that you show does not include the line that would show the value of error2. Did you omit showing it because its value was 0, or are you showing output from a different version of your program?

Randall

2021-05-31 17:37:21 UTC

Uros,
Keith and Randall gave very valuable responses.
Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.
Bill

Bill,
Very good remembering that filesystem error 12 is used for attempting to start a process with a name that already exists. I should have remembered that myself. Unless Pathway's link management also uses filesystem error 12 for other problems, I'd say a duplicate process name is likely to be the explanation for this problem. Perhaps Uros has set up a test environment by duplicating the configuration of an existing environment and did not know to change the configured fixed server process names.

Filesystem error 21 usually means an illegal count was specified. That might mean that either the length of the buffer you are sending is wrong or the maximum reply size (200 in this case) is wrong. It might mean something else, since I don't know anything about XPNET.
Pathway servers usually take input as data structures with fixed-length fields, not a text string like you would type to a command interpreter. Are you sure that the server you are sending to is expected a text string as its input? Do you have any documentation of what this server's interface is?
I notice that, although you show a new program that displays the value of error2, the output that you show does not include the line that would show the value of error2. Did you omit showing it because its value was 0, or are you showing output from a different version of your program?

I too do not remember much about XPNet, but I thought it was not SERVERCLASS_SEND_ compatible - in particular, does not require a qualified name on the Open, like $XPN.#XPNET?

Keith Dick

2021-05-31 18:27:45 UTC

Post by Randall

Uros,
Keith and Randall gave very valuable responses.
Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.
Bill

Bill,
Very good remembering that filesystem error 12 is used for attempting to start a process with a name that already exists. I should have remembered that myself. Unless Pathway's link management also uses filesystem error 12 for other problems, I'd say a duplicate process name is likely to be the explanation for this problem. Perhaps Uros has set up a test environment by duplicating the configuration of an existing environment and did not know to change the configured fixed server process names.

Filesystem error 21 usually means an illegal count was specified. That might mean that either the length of the buffer you are sending is wrong or the maximum reply size (200 in this case) is wrong. It might mean something else, since I don't know anything about XPNET.
Pathway servers usually take input as data structures with fixed-length fields, not a text string like you would type to a command interpreter. Are you sure that the server you are sending to is expected a text string as its input? Do you have any documentation of what this server's interface is?
I notice that, although you show a new program that displays the value of error2, the output that you show does not include the line that would show the value of error2. Did you omit showing it because its value was 0, or are you showing output from a different version of your program?

I too do not remember much about XPNet, but I thought it was not SERVERCLASS_SEND_ compatible - in particular, does not require a qualified name on the Open, like $XPN.#XPNET?

Given that Uros' most recent post shows a Pathway configuration, whatever he is trying to communicate with appears to be a Pathway serverclass and so should be able to accept a request sent by SEVERCLASS_SEND_. Pathway servers usually don't accept free format text strings as request messages, but I don't immediately recall anything that would prevent one from being written to accept that. I believe the reply messages must have a 16-bit reply code as the first two bytes, at least if it is to be usable from Screen COBOL, but i don't believe there is any similar constraint on the request messages.

Bill Honaker

2021-05-31 19:59:27 UTC

Uros,
Keith and Randall gave very valuable responses.
Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.
Bill

Bill,
Very good remembering that filesystem error 12 is used for attempting to start a process with a name that already exists. I should have remembered that myself. Unless Pathway's link management also uses filesystem error 12 for other problems, I'd say a duplicate process name is likely to be the explanation for this problem. Perhaps Uros has set up a test environment by duplicating the configuration of an existing environment and did not know to change the configured fixed server process names.

I see the original server was setup with 'Asoociative On' It's possible the open table in the server can't accept another open.

Can't explain the error 21.

Dave Bossi

2021-06-01 12:09:59 UTC

Uros,
Keith and Randall gave very valuable responses.
Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.
Bill

Bill,
Very good remembering that filesystem error 12 is used for attempting to start a process with a name that already exists. I should have remembered that myself. Unless Pathway's link management also uses filesystem error 12 for other problems, I'd say a duplicate process name is likely to be the explanation for this problem. Perhaps Uros has set up a test environment by duplicating the configuration of an existing environment and did not know to change the configured fixed server process names.

I see the original server was setup with 'Asoociative On' It's possible the open table in the server can't accept another open.
Can't explain the error 21.

I would try changing PMON and SNAME from pointers to arrays and see if it doesn't help with the error 21.

char pmon[] = "$D1NM";
char sname[] = "SERVER-NCP";

Dave

uros kusar

2021-06-02 08:54:13 UTC

Post by Dave Bossi

Uros,
Keith and Randall gave very valuable responses.
Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.
Bill

Bill,
Very good remembering that filesystem error 12 is used for attempting to start a process with a name that already exists. I should have remembered that myself. Unless Pathway's link management also uses filesystem error 12 for other problems, I'd say a duplicate process name is likely to be the explanation for this problem. Perhaps Uros has set up a test environment by duplicating the configuration of an existing environment and did not know to change the configured fixed server process names.

I see the original server was setup with 'Asoociative On' It's possible the open table in the server can't accept another open.
Can't explain the error 21.

I would try changing PMON and SNAME from pointers to arrays and see if it doesn't help with the error 21.
char pmon[] = "$D1MN";
char sname[] = "SERVER-NCP";
Dave

Hi,

Keith, I don't find anything in the manuals, that would show me what to send to the server.

I did not post the complete output to make this thread readable as possible. The SERVERCLASS_SEND_INFO returns 0(OK) and I tried different data types, also arrays instead of pointers. The result is the same. I'm almost sure that I need to send command to the SERVER-NCP server instead the SERVER-NCPI-1A.

Currently I'm using arrays:

char pmon[5]={0};
char buffer [200]={0};
char sname[20]={0};

strcpy(pmon,"$D1MN");
strcpy(sname,"SERVER-NCP");
strcpy(buffer,"STATUS PROCESS P1A^BICUNI1");

error = SERVERCLASS_SEND_ (pmon,
(short)strlen(pmon), /* pathmon */
sname,
(short)strlen(sname), /* server class */
buffer,
(short)strlen(buffer),
200,
&countread,
-1); /* timeout = forever */

OUTPUT:
SERVERCLASS_SEND_INFO error = 0
SERVERCLASS_SEND_ error = 233, pathsend error = 904, fs error = 21

Buffer size = 26
STATUS PROCESS P1A^BICUNI1

EMS messages:

21-06-02;10:03:23.101 \PERUN.$D1MN TANDEM.PATHWAY.L01 3116
\PERUN.$D1MN: ERROR - *3116* LINKMON L\PERUN.$ZP01,
ERROR DURING SERVER I/O (21) - SERVER SERVER-NCP

21-06-02;10:03:23.102 \PERUN.$D1SUD TANDEM.VHS.L01 6
DEV1VHS:
02JUN21,10:03 $D1MN: ERROR - *3116* LINKMON L\PERUN.$ZP01, ERROR
DURING SERVER I/O (21) - SERVER SERVER-NCP. Display text received
from process $D1MN. Program file \PERUN.$SYSTEM.SYSTEM.PATHMON.
Primary log file \PERUN.$DATA01.DEV1VHS.LOG0000.

I'm losing ideas what else to try.

Uros

uros kusar

2021-06-02 09:42:12 UTC

Uros,
Keith and Randall gave very valuable responses.
Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.
Bill

Bill,
Very good remembering that filesystem error 12 is used for attempting to start a process with a name that already exists. I should have remembered that myself. Unless Pathway's link management also uses filesystem error 12 for other problems, I'd say a duplicate process name is likely to be the explanation for this problem. Perhaps Uros has set up a test environment by duplicating the configuration of an existing environment and did not know to change the configured fixed server process names.

I see the original server was setup with 'Asoociative On' It's possible the open table in the server can't accept another open.
Can't explain the error 21.

I would try changing PMON and SNAME from pointers to arrays and see if it doesn't help with the error 21.
char pmon[] = "$D1MN";
char sname[] = "SERVER-NCP";
Dave

Hi,
Keith, I don't find anything in the manuals, that would show me what to send to the server.
I did not post the complete output to make this thread readable as possible. The SERVERCLASS_SEND_INFO returns 0(OK) and I tried different data types, also arrays instead of pointers. The result is the same. I'm almost sure that I need to send command to the SERVER-NCP server instead the SERVER-NCPI-1A.
char pmon[5]={0};
char buffer [200]={0};
char sname[20]={0};
strcpy(pmon,"$D1MN");
strcpy(sname,"SERVER-NCP");
strcpy(buffer,"STATUS PROCESS P1A^BICUNI1");
error = SERVERCLASS_SEND_ (pmon,
(short)strlen(pmon), /* pathmon */
sname,
(short)strlen(sname), /* server class */
buffer,
(short)strlen(buffer),
200,
&countread,
-1); /* timeout = forever */
SERVERCLASS_SEND_INFO error = 0
SERVERCLASS_SEND_ error = 233, pathsend error = 904, fs error = 21
Buffer size = 26
STATUS PROCESS P1A^BICUNI1
21-06-02;10:03:23.101 \PERUN.$D1MN TANDEM.PATHWAY.L01 3116
\PERUN.$D1MN: ERROR - *3116* LINKMON L\PERUN.$ZP01,
ERROR DURING SERVER I/O (21) - SERVER SERVER-NCP
21-06-02;10:03:23.102 \PERUN.$D1SUD TANDEM.VHS.L01 6
02JUN21,10:03 $D1MN: ERROR - *3116* LINKMON L\PERUN.$ZP01, ERROR
DURING SERVER I/O (21) - SERVER SERVER-NCP. Display text received
from process $D1MN. Program file \PERUN.$SYSTEM.SYSTEM.PATHMON.
Primary log file \PERUN.$DATA01.DEV1VHS.LOG0000.
I'm losing ideas what else to try.
Uros

I just notice another EMS error in collector $0

21-06-02;11:39:59.662 \PERUN.$ZL01 TANDEM.APPCLSTR.L01 1038
WARNING 1038 - Server \PERUN.$D1MN.SERVER-NCP file
operation ACS_FS_PSWRITEREAD_() failed, process
\PERUN.$D1C1:115841149, file \PERUN.$D1C1, error 21

Uros

Keith Dick

2021-06-02 12:55:12 UTC

Uros,
Keith and Randall gave very valuable responses.
Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.
Bill

Bill,
Very good remembering that filesystem error 12 is used for attempting to start a process with a name that already exists. I should have remembered that myself. Unless Pathway's link management also uses filesystem error 12 for other problems, I'd say a duplicate process name is likely to be the explanation for this problem. Perhaps Uros has set up a test environment by duplicating the configuration of an existing environment and did not know to change the configured fixed server process names.

I see the original server was setup with 'Asoociative On' It's possible the open table in the server can't accept another open.
Can't explain the error 21.

I would try changing PMON and SNAME from pointers to arrays and see if it doesn't help with the error 21.
char pmon[] = "$D1MN";
char sname[] = "SERVER-NCP";
Dave

Hi,
Keith, I don't find anything in the manuals, that would show me what to send to the server.
I did not post the complete output to make this thread readable as possible. The SERVERCLASS_SEND_INFO returns 0(OK) and I tried different data types, also arrays instead of pointers. The result is the same. I'm almost sure that I need to send command to the SERVER-NCP server instead the SERVER-NCPI-1A.
char pmon[5]={0};
char buffer [200]={0};
char sname[20]={0};
strcpy(pmon,"$D1MN");
strcpy(sname,"SERVER-NCP");
strcpy(buffer,"STATUS PROCESS P1A^BICUNI1");
error = SERVERCLASS_SEND_ (pmon,
(short)strlen(pmon), /* pathmon */
sname,
(short)strlen(sname), /* server class */
buffer,
(short)strlen(buffer),
200,
&countread,
-1); /* timeout = forever */
SERVERCLASS_SEND_INFO error = 0
SERVERCLASS_SEND_ error = 233, pathsend error = 904, fs error = 21
Buffer size = 26
STATUS PROCESS P1A^BICUNI1
21-06-02;10:03:23.101 \PERUN.$D1MN TANDEM.PATHWAY.L01 3116
\PERUN.$D1MN: ERROR - *3116* LINKMON L\PERUN.$ZP01,
ERROR DURING SERVER I/O (21) - SERVER SERVER-NCP
21-06-02;10:03:23.102 \PERUN.$D1SUD TANDEM.VHS.L01 6
02JUN21,10:03 $D1MN: ERROR - *3116* LINKMON L\PERUN.$ZP01, ERROR
DURING SERVER I/O (21) - SERVER SERVER-NCP. Display text received
from process $D1MN. Program file \PERUN.$SYSTEM.SYSTEM.PATHMON.
Primary log file \PERUN.$DATA01.DEV1VHS.LOG0000.
I'm losing ideas what else to try.
Uros

I just notice another EMS error in collector $0
21-06-02;11:39:59.662 \PERUN.$ZL01 TANDEM.APPCLSTR.L01 1038
WARNING 1038 - Server \PERUN.$D1MN.SERVER-NCP file
operation ACS_FS_PSWRITEREAD_() failed, process
\PERUN.$D1C1:115841149, file \PERUN.$D1C1, error 21
Uros

Hi Uros,

Do you have any indication that the Pathway server you are trying to use is intended for a user such as yourself to access directly using SERVERCLASS_SEND_ ? You mentioned that you found a TAL program that sends commands to SERVER-NCP. Where did you find that example program? Perhaps if I looked at that TAL program, it would help me understand what you could be doing wrong.

I have a feeling that you are trying to do something that a user such as you is not intended to do, and that whatever task you are trying to do needs to be approached in some other way. That is only my feeling, based on very little evidence, so don't give up on this program based only on my feeling, because my feeling could be wrong. As I said earlier, I know nothing about xpnet.

Randall

2021-06-02 18:42:13 UTC

Uros,
Keith and Randall gave very valuable responses.
Also one other possibility is that, in creating the link, the PATHMON tried to start a server process.
If that server process has a fixed PROCESS NAME for each isntance, and if there is already a running process with that name,
the attempt to start the process would get an error 12. Look at the info ("PATHCOM $D1MN;INFO SERVER-NCPI-1A") and
check what is in the "PROCESS". If it's present, there will either be one process name, or a list in paraentheses.
From a TACL prompt, issue a status command for each process in the list.
Bill

Bill,
Very good remembering that filesystem error 12 is used for attempting to start a process with a name that already exists. I should have remembered that myself. Unless Pathway's link management also uses filesystem error 12 for other problems, I'd say a duplicate process name is likely to be the explanation for this problem. Perhaps Uros has set up a test environment by duplicating the configuration of an existing environment and did not know to change the configured fixed server process names.

I see the original server was setup with 'Asoociative On' It's possible the open table in the server can't accept another open.
Can't explain the error 21.

I would try changing PMON and SNAME from pointers to arrays and see if it doesn't help with the error 21.
char pmon[] = "$D1MN";
char sname[] = "SERVER-NCP";
Dave

Hi,
Keith, I don't find anything in the manuals, that would show me what to send to the server.
I did not post the complete output to make this thread readable as possible. The SERVERCLASS_SEND_INFO returns 0(OK) and I tried different data types, also arrays instead of pointers. The result is the same. I'm almost sure that I need to send command to the SERVER-NCP server instead the SERVER-NCPI-1A.
char pmon[5]={0};
char buffer [200]={0};
char sname[20]={0};
strcpy(pmon,"$D1MN");
strcpy(sname,"SERVER-NCP");
strcpy(buffer,"STATUS PROCESS P1A^BICUNI1");
error = SERVERCLASS_SEND_ (pmon,
(short)strlen(pmon), /* pathmon */
sname,
(short)strlen(sname), /* server class */
buffer,
(short)strlen(buffer),
200,
&countread,
-1); /* timeout = forever */
SERVERCLASS_SEND_INFO error = 0
SERVERCLASS_SEND_ error = 233, pathsend error = 904, fs error = 21
Buffer size = 26
STATUS PROCESS P1A^BICUNI1
21-06-02;10:03:23.101 \PERUN.$D1MN TANDEM.PATHWAY.L01 3116
\PERUN.$D1MN: ERROR - *3116* LINKMON L\PERUN.$ZP01,
ERROR DURING SERVER I/O (21) - SERVER SERVER-NCP
21-06-02;10:03:23.102 \PERUN.$D1SUD TANDEM.VHS.L01 6
02JUN21,10:03 $D1MN: ERROR - *3116* LINKMON L\PERUN.$ZP01, ERROR
DURING SERVER I/O (21) - SERVER SERVER-NCP. Display text received
from process $D1MN. Program file \PERUN.$SYSTEM.SYSTEM.PATHMON.
Primary log file \PERUN.$DATA01.DEV1VHS.LOG0000.
I'm losing ideas what else to try.
Uros

I just notice another EMS error in collector $0
21-06-02;11:39:59.662 \PERUN.$ZL01 TANDEM.APPCLSTR.L01 1038
WARNING 1038 - Server \PERUN.$D1MN.SERVER-NCP file
operation ACS_FS_PSWRITEREAD_() failed, process
\PERUN.$D1C1:115841149, file \PERUN.$D1C1, error 21
Uros

Hi Uros,
Do you have any indication that the Pathway server you are trying to use is intended for a user such as yourself to access directly using SERVERCLASS_SEND_ ? You mentioned that you found a TAL program that sends commands to SERVER-NCP. Where did you find that example program? Perhaps if I looked at that TAL program, it would help me understand what you could be doing wrong.
I have a feeling that you are trying to do something that a user such as you is not intended to do, and that whatever task you are trying to do needs to be approached in some other way. That is only my feeling, based on very little evidence, so don't give up on this program based only on my feeling, because my feeling could be wrong. As I said earlier, I know nothing about xpnet.

At this point, I would try putting together a trivial program in C/TAL that does a FILE_OPEN_, WRITEREADX, FILE_CLOSE_ to the process and see what error you actually get instead of trying to work through LINKMON. At least you have exact control with that and can see whether the FILE_OPEN_ fails, or whether the WRITEREADX is having a problem with your buffer.

Something you need to be aware of in your program, however. Your statement:

strcpy(pmon,"$D1MN");

is going to overrun your buffer and hit the next variable in memory. You only declared the buffer as char[5] and the copy is moving 6 bytes.

Cheers,
Randall

JShepherd

2021-06-02 19:03:39 UTC