Greetings all,
I am looking for advice as to how to manage a network of systems that use CKNSERVE.
There might be many nodes in use in the network, and often it is best to see query results from all nodes. Hence the list of nodes specified in SE.1 will include all nodes. 
However, on occasion a node may not be available. This may be due to errors, an unscheduled IPL, TCP/IP being down, or some other event, that the zSecure user is not aware of.

In such a situation a request to that node will cause the entire request to hang, sometimes for a long time. It seems in such a situation we need to identify the problem node(s) and then submit the request with the node(s) in question having been unselected in SE.1. Sometimes that process is simple, but not always.

Is there a way to determine which nodes are up?
What do you do in such a situation?
Is there a recommended approach to handle these situations?

Lennie

Hey Lennie

I do not know about the time-out issue, haven't seen those for ages, but there is a trick for running with unreliable network nodes.

When you specify the dsname in SE.1, the ALLOC statement uses DSN=dsname which fails when the dsname doesn't exist or isn't available.

When you use DSNPREF=dsname, the query will quietly continue without the dsname.  That may not be good for all reports, especially the quiet part, so use with caution.

Greetings all,
I am looking for advice as to how to manage a network of systems that use CKNSERVE.
There might be many nodes in use in the network, and often it is best to see query results from all nodes. Hence the list of nodes specified in SE.1 will include all nodes. 
However, on occasion a node may not be available. This may be due to errors, an unscheduled IPL, TCP/IP being down, or some other event, that the zSecure user is not aware of.

In such a situation a request to that node will cause the entire request to hang, sometimes for a long time. It seems in such a situation we need to identify the problem node(s) and then submit the request with the node(s) in question having been unselected in SE.1. Sometimes that process is simple, but not always.

Is there a way to determine which nodes are up?
What do you do in such a situation?
Is there a recommended approach to handle these situations?

Lennie

Rob,

Thanks for the reply. I agree that approach might need some caution. But If I have understood correctly I will simply get no results from a query to the "dead" system. I will at least get a response from the others.

However, I think I need same clarification on how to set this up.
For most nodes the data sets allocated simply use a "Type"  of ACT.BACK so there is neither DSN= nor DSNPREF= used. The active RACF backup is used.
If I have understood you correctly I would need to replace this with DSNPREF="Real name of RACF backup on remote node" and have "Type" set to COPY.RACF
I have tried this and cannot get this to work. It fails with a CKR2160 (I have changed values in CKR2353 and CKR1353 below to obscure names).

CKR2353 00 Adding ALLOC TYPE=CKFREEZE ZSECNODE=ZZZZ      ZSECSYS=SSSS     ACTIVE COMPLEX=ZZZZ
CKR1353 00 ALLOC DSNPREF=SYS1.RACF.BACKUP adds DSN=SYS1.RACF.BACKUP
CKR2160 12 No systems found matching zsecnode= zsecsys= in ALLOC command

Or is there some other point I have missed?

Hey Lennie

I do not know about the time-out issue, haven't seen those for ages, but there is a trick for running with unreliable network nodes.

When you specify the dsname in SE.1, the ALLOC statement uses DSN=dsname which fails when the dsname doesn't exist or isn't available.

When you use DSNPREF=dsname, the query will quietly continue without the dsname.  That may not be good for all reports, especially the quiet part, so use with caution.

Greetings all,
I am looking for advice as to how to manage a network of systems that use CKNSERVE.
There might be many nodes in use in the network, and often it is best to see query results from all nodes. Hence the list of nodes specified in SE.1 will include all nodes. 
However, on occasion a node may not be available. This may be due to errors, an unscheduled IPL, TCP/IP being down, or some other event, that the zSecure user is not aware of.

In such a situation a request to that node will cause the entire request to hang, sometimes for a long time. It seems in such a situation we need to identify the problem node(s) and then submit the request with the node(s) in question having been unselected in SE.1. Sometimes that process is simple, but not always.

Is there a way to determine which nodes are up?
What do you do in such a situation?
Is there a recommended approach to handle these situations?

Lennie

Rob,

Thanks for the reply. I agree that approach might need some caution. But If I have understood correctly I will simply get no results from a query to the "dead" system. I will at least get a response from the others.

However, I think I need same clarification on how to set this up.
For most nodes the data sets allocated simply use a "Type"  of ACT.BACK so there is neither DSN= nor DSNPREF= used. The active RACF backup is used.
If I have understood you correctly I would need to replace this with DSNPREF="Real name of RACF backup on remote node" and have "Type" set to COPY.RACF
I have tried this and cannot get this to work. It fails with a CKR2160 (I have changed values in CKR2353 and CKR1353 below to obscure names).

CKR2353 00 Adding ALLOC TYPE=CKFREEZE ZSECNODE=ZZZZ      ZSECSYS=SSSS     ACTIVE COMPLEX=ZZZZ
CKR1353 00 ALLOC DSNPREF=SYS1.RACF.BACKUP adds DSN=SYS1.RACF.BACKUP
CKR2160 12 No systems found matching zsecnode= zsecsys= in ALLOC command

Or is there some other point I have missed?

Hey Lennie

I do not know about the time-out issue, haven't seen those for ages, but there is a trick for running with unreliable network nodes.

When you specify the dsname in SE.1, the ALLOC statement uses DSN=dsname which fails when the dsname doesn't exist or isn't available.

When you use DSNPREF=dsname, the query will quietly continue without the dsname.  That may not be good for all reports, especially the quiet part, so use with caution.

Greetings all,
I am looking for advice as to how to manage a network of systems that use CKNSERVE.
There might be many nodes in use in the network, and often it is best to see query results from all nodes. Hence the list of nodes specified in SE.1 will include all nodes. 
However, on occasion a node may not be available. This may be due to errors, an unscheduled IPL, TCP/IP being down, or some other event, that the zSecure user is not aware of.

In such a situation a request to that node will cause the entire request to hang, sometimes for a long time. It seems in such a situation we need to identify the problem node(s) and then submit the request with the node(s) in question having been unselected in SE.1. Sometimes that process is simple, but not always.

Is there a way to determine which nodes are up?
What do you do in such a situation?
Is there a recommended approach to handle these situations?

Lennie