SearchFAQMemberlist Log in
Reply to topic Page 1 of 1
The mysterious port 1757
Author Message
Post The mysterious port 1757 
Greetings ADSM-L! I've a port problem today. When we're trying to run
a command schedule in prompted mode, we see this in the activity log:

2008-07-26 23:01 ANR8213W
Session open with vmhyper1-toc timed out. (SESSION: 984)
2008-07-26 23:01 ANR2716E
Schedule prompter was not able to contact client
VMHYPER1_TOC_VCB using type 1 (vmhyper1-toc 1757). (SESSION: 984)

As you can see, the port in use is 1757. And, indeed, when we open
that port through the client's firewall, the schedule runs just fine.
My question is: where the #%$! is that port coming from?

Here is the dsm.sys:

Servername vmhyper1-toc-vcb
COMMmethod tcpip
tcpserveraddr xxxxxxx
tcpport 1500
nodename vmhyper1_toc_vcb
passwordaccess generate
largecom yes
txnbytelimit 25600
tcpnodelay yes
tcpbuffsize 32
tcpwin 64
schedlogn /home/vmwaresched-vcb.log
schedmode prompted
errorlogn /home/vmwareerr-vcb.log
dirmc dirmc
schedlogretention 30 d
errorlogretention 30 d

and here is the client node definition on the server:

Node Name: VMHYPER1_TOC_VCB
Platform: Linux86
Client OS Level: 2.4.21-47
Client Version: Version 5, release 4, level 0.0
Policy Domain Name: CG_UNIX
Last Access Date/Time: 07/28/2008 10:17:58
Days Since Last Access: <1
Password Set Date/Time: 05/29/2008 15:14:05
Days Since Password Set: 60
Invalid Sign-on Count: 0
Locked?: No
Contact:
Compression: Client
Archive Delete Allowed?: Yes
Backup Delete Allowed?: No
Registration Date/Time: 05/29/2008 15:14:05
Registering Administrator: admin
Last Communication Method Used: Tcp/Ip
Bytes Received Last Session: 7,814.35 M
Bytes Sent Last Session: 3,891
Duration of Last Session: 138.81
Pct. Idle Wait Last Session: 0.10
Pct. Comm. Wait Last Session: 7.82
Pct. Media Wait Last Session: 0.00
Optionset:
URL: http://myclient.mycompany.com:1581
Node Type: Client
Password Expiration Period:
Keep Mount Point?: No
Maximum Mount Points Allowed: 1
Auto Filespace Rename : No
Validate Protocol: No
TCP/IP Name: vmhyper1-toc
TCP/IP Address: <valid redacted IP address>
Globally Unique ID: 11.58.f2.80.10.9d.11.dd.86.1e.00.50.56.4f.e5.e5
Transaction Group Max: 0
Data Write Path: ANY
Data Read Path: ANY
Session Initiation: ClientOrServer
High-level Address:
Low-level Address:
Collocation Group Name:
Proxynode Target:
Proxynode Agent:
Node Groups:

And the contents of the command executed by the schedule, tsmbckup.sc:

/jobs/vmbckup.sc </dev/null

and the contents of vmbckukp.sc:

vcbMounter -h vmhyper1-toc -a ipaddr:ctrxweb -r
/vmfs/volumes/vmhyper1-toc:Local/vcb/ctrxwebbckup
wait
vcbMounter -h vmhyper1-toc -a ipaddr:ctrxlicsvr -r
/vmfs/volumes/vmhyper1-toc:Local/vcb/ctrxlicsvrbckup
wait
dsmc sel /vmfs/volumes/vmhyper1-toc:Local/vcb/ -subdir=yes -ser=vmhyper1-toc-vcb
wait
rm -rf /vmfs/volumes/vmhyper1-toc:Local/vcb/*

The server is 5.5, running on AIX 5.3

What's up with port 1757? Am I missing something blazingly obvious?

--
Stephen Stackwick
Jacob & Sundstrom, Inc.
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick < at > jasi.com

Post The mysterious port 1757 
Quoting Steve Stackwick <sstackwick < at > JASI.COM>:

Greetings ADSM-L! I've a port problem today. When we're trying to run
a command schedule in prompted mode, we see this in the activity log:

2008-07-26 23:01 ANR8213W
Session open with vmhyper1-toc timed out. (SESSION: 984)
2008-07-26 23:01 ANR2716E
Schedule prompter was not able to contact client
VMHYPER1_TOC_VCB using type 1 (vmhyper1-toc 1757). (SESSION: 984)

As you can see, the port in use is 1757. And, indeed, when we open
that port through the client's firewall, the schedule runs just fine.
My question is: where the #%$! is that port coming from?


you run schedmode prompted, right?

So either:

1- switch to schedmode polling
2- set a tcp client port

'cause probably, the defaul tcp client port 1501 was in use (maybe a
hung client?) and the client selected some other port.

Here is the dsm.sys:

Servername vmhyper1-toc-vcb
COMMmethod tcpip
tcpserveraddr xxxxxxx
tcpport 1500
nodename vmhyper1_toc_vcb
passwordaccess generate
largecom yes
txnbytelimit 25600
tcpnodelay yes
tcpbuffsize 32
tcpwin 64
schedlogn /home/vmwaresched-vcb.log
schedmode prompted
errorlogn /home/vmwareerr-vcb.log
dirmc dirmc
schedlogretention 30 d
errorlogretention 30 d

and here is the client node definition on the server:

Node Name: VMHYPER1_TOC_VCB
Platform: Linux86
Client OS Level: 2.4.21-47
Client Version: Version 5, release 4, level 0.0
Policy Domain Name: CG_UNIX
Last Access Date/Time: 07/28/2008 10:17:58
Days Since Last Access: <1
Password Set Date/Time: 05/29/2008 15:14:05
Days Since Password Set: 60
Invalid Sign-on Count: 0
Locked?: No
Contact:
Compression: Client
Archive Delete Allowed?: Yes
Backup Delete Allowed?: No
Registration Date/Time: 05/29/2008 15:14:05
Registering Administrator: admin
Last Communication Method Used: Tcp/Ip
Bytes Received Last Session: 7,814.35 M
Bytes Sent Last Session: 3,891
Duration of Last Session: 138.81
Pct. Idle Wait Last Session: 0.10
Pct. Comm. Wait Last Session: 7.82
Pct. Media Wait Last Session: 0.00
Optionset:
URL: http://myclient.mycompany.com:1581
Node Type: Client
Password Expiration Period:
Keep Mount Point?: No
Maximum Mount Points Allowed: 1
Auto Filespace Rename : No
Validate Protocol: No
TCP/IP Name: vmhyper1-toc
TCP/IP Address: <valid redacted IP address>
Globally Unique ID:
11.58.f2.80.10.9d.11.dd.86.1e.00.50.56.4f.e5.e5
Transaction Group Max: 0
Data Write Path: ANY
Data Read Path: ANY
Session Initiation: ClientOrServer
High-level Address:
Low-level Address:
Collocation Group Name:
Proxynode Target:
Proxynode Agent:
Node Groups:

And the contents of the command executed by the schedule, tsmbckup.sc:

/jobs/vmbckup.sc </dev/null

and the contents of vmbckukp.sc:

vcbMounter -h vmhyper1-toc -a ipaddr:ctrxweb -r
/vmfs/volumes/vmhyper1-toc:Local/vcb/ctrxwebbckup
wait
vcbMounter -h vmhyper1-toc -a ipaddr:ctrxlicsvr -r
/vmfs/volumes/vmhyper1-toc:Local/vcb/ctrxlicsvrbckup
wait
dsmc sel /vmfs/volumes/vmhyper1-toc:Local/vcb/ -subdir=yes
-ser=vmhyper1-toc-vcb
wait
rm -rf /vmfs/volumes/vmhyper1-toc:Local/vcb/*

The server is 5.5, running on AIX 5.3

What's up with port 1757? Am I missing something blazingly obvious?

--
Stephen Stackwick
Jacob & Sundstrom, Inc.
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick < at > jasi.com




--

Met vriendelijke groeten,

Remco Post, PLCS

Post The mysterious port 1757 
Well, it's working now after we poked a hole in the firewall, my real
question is: where is 1757 coming from?

On Thu, Jul 31, 2008 at 10:58 AM, Remco Post <r.post < at > plcs.nl> wrote:
Quoting Steve Stackwick <sstackwick < at > JASI.COM>:

Greetings ADSM-L! I've a port problem today. When we're trying to run
a command schedule in prompted mode, we see this in the activity log:

2008-07-26 23:01 ANR8213W
Session open with vmhyper1-toc timed out. (SESSION: 984)
2008-07-26 23:01 ANR2716E
Schedule prompter was not able to contact client
VMHYPER1_TOC_VCB using type 1 (vmhyper1-toc 1757). (SESSION: 984)

As you can see, the port in use is 1757. And, indeed, when we open
that port through the client's firewall, the schedule runs just fine.
My question is: where the #%$! is that port coming from?


you run schedmode prompted, right?

So either:

1- switch to schedmode polling
2- set a tcp client port

'cause probably, the defaul tcp client port 1501 was in use (maybe a hung
client?) and the client selected some other port.

Here is the dsm.sys:

Servername vmhyper1-toc-vcb
COMMmethod tcpip
tcpserveraddr xxxxxxx
tcpport 1500
nodename vmhyper1_toc_vcb
passwordaccess generate
largecom yes
txnbytelimit 25600
tcpnodelay yes
tcpbuffsize 32
tcpwin 64
schedlogn /home/vmwaresched-vcb.log
schedmode prompted
errorlogn /home/vmwareerr-vcb.log
dirmc dirmc
schedlogretention 30 d
errorlogretention 30 d

and here is the client node definition on the server:

Node Name: VMHYPER1_TOC_VCB
Platform: Linux86
Client OS Level: 2.4.21-47
Client Version: Version 5, release 4, level 0.0
Policy Domain Name: CG_UNIX
Last Access Date/Time: 07/28/2008 10:17:58
Days Since Last Access: <1
Password Set Date/Time: 05/29/2008 15:14:05
Days Since Password Set: 60
Invalid Sign-on Count: 0
Locked?: No
Contact:
Compression: Client
Archive Delete Allowed?: Yes
Backup Delete Allowed?: No
Registration Date/Time: 05/29/2008 15:14:05
Registering Administrator: admin
Last Communication Method Used: Tcp/Ip
Bytes Received Last Session: 7,814.35 M
Bytes Sent Last Session: 3,891
Duration of Last Session: 138.81
Pct. Idle Wait Last Session: 0.10
Pct. Comm. Wait Last Session: 7.82
Pct. Media Wait Last Session: 0.00
Optionset:
URL: http://myclient.mycompany.com:1581
Node Type: Client
Password Expiration Period:
Keep Mount Point?: No
Maximum Mount Points Allowed: 1
Auto Filespace Rename : No
Validate Protocol: No
TCP/IP Name: vmhyper1-toc
TCP/IP Address: <valid redacted IP address>
Globally Unique ID:
11.58.f2.80.10.9d.11.dd.86.1e.00.50.56.4f.e5.e5
Transaction Group Max: 0
Data Write Path: ANY
Data Read Path: ANY
Session Initiation: ClientOrServer
High-level Address:
Low-level Address:
Collocation Group Name:
Proxynode Target:
Proxynode Agent:
Node Groups:

And the contents of the command executed by the schedule, tsmbckup.sc:

/jobs/vmbckup.sc </dev/null

and the contents of vmbckukp.sc:

vcbMounter -h vmhyper1-toc -a ipaddr:ctrxweb -r
/vmfs/volumes/vmhyper1-toc:Local/vcb/ctrxwebbckup
wait
vcbMounter -h vmhyper1-toc -a ipaddr:ctrxlicsvr -r
/vmfs/volumes/vmhyper1-toc:Local/vcb/ctrxlicsvrbckup
wait
dsmc sel /vmfs/volumes/vmhyper1-toc:Local/vcb/ -subdir=yes
-ser=vmhyper1-toc-vcb
wait
rm -rf /vmfs/volumes/vmhyper1-toc:Local/vcb/*

The server is 5.5, running on AIX 5.3

What's up with port 1757? Am I missing something blazingly obvious?

--
Stephen Stackwick
Jacob & Sundstrom, Inc.
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick < at > jasi.com




--

Met vriendelijke groeten,

Remco Post, PLCS




--
Stephen Stackwick
Jacob & Sundstrom, Inc.
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick < at > jasi.com

Post The mysterious port 1757 
Steve -

There's no TCPCLIENTPort spec in the client options, so the TSM
server uses the port number which the client chose to use in
establishing itself with the TSM server. See IBM Technote 1083673.

Richard Sims

Post The mysterious port 1757 
Thanks, Richard, but after reading the Technote I'm still a little
confused. It seems that the port is selected (presumably randomly) at
initial contact right after installation and stored by the server, at
least that's how I'm reading the technote. If so, where does that
configuration live on the server? I don't see anything in CLIENT_LLA.
And why wouldn't the port be default 1500 or 1501, rather than 1757?

Ah well, it seems to work, but I don't know why.

On Thu, Jul 31, 2008 at 11:28 AM, Richard Sims <rbs < at > bu.edu> wrote:
Steve -

There's no TCPCLIENTPort spec in the client options, so the TSM
server uses the port number which the client chose to use in
establishing itself with the TSM server. See IBM Technote 1083673.

Richard Sims




--
Stephen Stackwick
Jacob & Sundstrom, Inc.
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick < at > jasi.com

Post The mysterious port 1757 
On Jul 31, 2008, at 17:17 , Steve Stackwick wrote:

Well, it's working now after we poked a hole in the firewall, my real
question is: where is 1757 coming from?


random, the default was unavailable (must have been, otherwise that
would have been selected).

On Thu, Jul 31, 2008 at 10:58 AM, Remco Post <r.post < at > plcs.nl> wrote:
Quoting Steve Stackwick <sstackwick < at > JASI.COM>:

Greetings ADSM-L! I've a port problem today. When we're trying to
run
a command schedule in prompted mode, we see this in the activity
log:

2008-07-26 23:01 ANR8213W
Session open with vmhyper1-toc timed out. (SESSION: 984)
2008-07-26 23:01 ANR2716E
Schedule prompter was not able to contact client
VMHYPER1_TOC_VCB using type 1 (vmhyper1-toc 1757). (SESSION: 984)

As you can see, the port in use is 1757. And, indeed, when we open
that port through the client's firewall, the schedule runs just
fine.
My question is: where the #%$! is that port coming from?


you run schedmode prompted, right?

So either:

1- switch to schedmode polling
2- set a tcp client port

'cause probably, the defaul tcp client port 1501 was in use (maybe
a hung
client?) and the client selected some other port.

Here is the dsm.sys:

Servername vmhyper1-toc-vcb
COMMmethod tcpip
tcpserveraddr xxxxxxx
tcpport 1500
nodename vmhyper1_toc_vcb
passwordaccess generate
largecom yes
txnbytelimit 25600
tcpnodelay yes
tcpbuffsize 32
tcpwin 64
schedlogn /home/vmwaresched-vcb.log
schedmode prompted
errorlogn /home/vmwareerr-vcb.log
dirmc dirmc
schedlogretention 30 d
errorlogretention 30 d

and here is the client node definition on the server:

Node Name: VMHYPER1_TOC_VCB
Platform: Linux86
Client OS Level: 2.4.21-47
Client Version: Version 5, release 4, level 0.0
Policy Domain Name: CG_UNIX
Last Access Date/Time: 07/28/2008 10:17:58
Days Since Last Access: <1
Password Set Date/Time: 05/29/2008 15:14:05
Days Since Password Set: 60
Invalid Sign-on Count: 0
Locked?: No
Contact:
Compression: Client
Archive Delete Allowed?: Yes
Backup Delete Allowed?: No
Registration Date/Time: 05/29/2008 15:14:05
Registering Administrator: admin
Last Communication Method Used: Tcp/Ip
Bytes Received Last Session: 7,814.35 M
Bytes Sent Last Session: 3,891
Duration of Last Session: 138.81
Pct. Idle Wait Last Session: 0.10
Pct. Comm. Wait Last Session: 7.82
Pct. Media Wait Last Session: 0.00
Optionset:
URL: http://myclient.mycompany.com:1581
Node Type: Client
Password Expiration Period:
Keep Mount Point?: No
Maximum Mount Points Allowed: 1
Auto Filespace Rename : No
Validate Protocol: No
TCP/IP Name: vmhyper1-toc
TCP/IP Address: <valid redacted IP address>
Globally Unique ID:
11.58.f2.80.10.9d.11.dd.86.1e.00.50.56.4f.e5.e5
Transaction Group Max: 0
Data Write Path: ANY
Data Read Path: ANY
Session Initiation: ClientOrServer
High-level Address:
Low-level Address:
Collocation Group Name:
Proxynode Target:
Proxynode Agent:
Node Groups:

And the contents of the command executed by the schedule,
tsmbckup.sc:

/jobs/vmbckup.sc </dev/null

and the contents of vmbckukp.sc:

vcbMounter -h vmhyper1-toc -a ipaddr:ctrxweb -r
/vmfs/volumes/vmhyper1-toc:Local/vcb/ctrxwebbckup
wait
vcbMounter -h vmhyper1-toc -a ipaddr:ctrxlicsvr -r
/vmfs/volumes/vmhyper1-toc:Local/vcb/ctrxlicsvrbckup
wait
dsmc sel /vmfs/volumes/vmhyper1-toc:Local/vcb/ -subdir=yes
-ser=vmhyper1-toc-vcb
wait
rm -rf /vmfs/volumes/vmhyper1-toc:Local/vcb/*

The server is 5.5, running on AIX 5.3

What's up with port 1757? Am I missing something blazingly obvious?

--
Stephen Stackwick
Jacob & Sundstrom, Inc.
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick < at > jasi.com




--

Met vriendelijke groeten,

Remco Post, PLCS




--
Stephen Stackwick
Jacob & Sundstrom, Inc.
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick < at > jasi.com

--
Met vriendelijke groeten,

Remco Post
remco < at > pipsworld.nl

Post The mysterious port 1757 
On Thu, Jul 31, 2008 at 11:56 AM, Remco Post <remco < at > pipsworld.nl> wrote:
On Jul 31, 2008, at 17:17 , Steve Stackwick wrote:

Well, it's working now after we poked a hole in the firewall, my real
question is: where is 1757 coming from?


random, the default was unavailable (must have been, otherwise that
would have been selected).

Thanks, and that sounds right, because there is a another scheduler on
the box (redacted from the dsm.sys I posted, sorry!) using the default
port. But I wonder where TSM stores this information, because it seems
to be persistent. I see nothing in CLIENT_LLA (where I would expect
it) or anywhere else. Hmm, perhaps the client password file? Perhaps I
should check.

Steve

On Thu, Jul 31, 2008 at 10:58 AM, Remco Post <r.post < at > plcs.nl> wrote:

Quoting Steve Stackwick <sstackwick < at > JASI.COM>:

Greetings ADSM-L! I've a port problem today. When we're trying to
run
a command schedule in prompted mode, we see this in the activity
log:

2008-07-26 23:01 ANR8213W
Session open with vmhyper1-toc timed out. (SESSION: 984)
2008-07-26 23:01 ANR2716E
Schedule prompter was not able to contact client
VMHYPER1_TOC_VCB using type 1 (vmhyper1-toc 1757). (SESSION: 984)

As you can see, the port in use is 1757. And, indeed, when we open
that port through the client's firewall, the schedule runs just
fine.
My question is: where the #%$! is that port coming from?


you run schedmode prompted, right?

So either:

1- switch to schedmode polling
2- set a tcp client port

'cause probably, the defaul tcp client port 1501 was in use (maybe
a hung
client?) and the client selected some other port.

Here is the dsm.sys:

Servername vmhyper1-toc-vcb
COMMmethod tcpip
tcpserveraddr xxxxxxx
tcpport 1500
nodename vmhyper1_toc_vcb
passwordaccess generate
largecom yes
txnbytelimit 25600
tcpnodelay yes
tcpbuffsize 32
tcpwin 64
schedlogn /home/vmwaresched-vcb.log
schedmode prompted
errorlogn /home/vmwareerr-vcb.log
dirmc dirmc
schedlogretention 30 d
errorlogretention 30 d

and here is the client node definition on the server:

Node Name: VMHYPER1_TOC_VCB
Platform: Linux86
Client OS Level: 2.4.21-47
Client Version: Version 5, release 4, level 0.0
Policy Domain Name: CG_UNIX
Last Access Date/Time: 07/28/2008 10:17:58
Days Since Last Access: <1
Password Set Date/Time: 05/29/2008 15:14:05
Days Since Password Set: 60
Invalid Sign-on Count: 0
Locked?: No
Contact:
Compression: Client
Archive Delete Allowed?: Yes
Backup Delete Allowed?: No
Registration Date/Time: 05/29/2008 15:14:05
Registering Administrator: admin
Last Communication Method Used: Tcp/Ip
Bytes Received Last Session: 7,814.35 M
Bytes Sent Last Session: 3,891
Duration of Last Session: 138.81
Pct. Idle Wait Last Session: 0.10
Pct. Comm. Wait Last Session: 7.82
Pct. Media Wait Last Session: 0.00
Optionset:
URL: http://myclient.mycompany.com:1581
Node Type: Client
Password Expiration Period:
Keep Mount Point?: No
Maximum Mount Points Allowed: 1
Auto Filespace Rename : No
Validate Protocol: No
TCP/IP Name: vmhyper1-toc
TCP/IP Address: <valid redacted IP address>
Globally Unique ID:
11.58.f2.80.10.9d.11.dd.86.1e.00.50.56.4f.e5.e5
Transaction Group Max: 0
Data Write Path: ANY
Data Read Path: ANY
Session Initiation: ClientOrServer
High-level Address:
Low-level Address:
Collocation Group Name:
Proxynode Target:
Proxynode Agent:
Node Groups:

And the contents of the command executed by the schedule,
tsmbckup.sc:

/jobs/vmbckup.sc </dev/null

and the contents of vmbckukp.sc:

vcbMounter -h vmhyper1-toc -a ipaddr:ctrxweb -r
/vmfs/volumes/vmhyper1-toc:Local/vcb/ctrxwebbckup
wait
vcbMounter -h vmhyper1-toc -a ipaddr:ctrxlicsvr -r
/vmfs/volumes/vmhyper1-toc:Local/vcb/ctrxlicsvrbckup
wait
dsmc sel /vmfs/volumes/vmhyper1-toc:Local/vcb/ -subdir=yes
-ser=vmhyper1-toc-vcb
wait
rm -rf /vmfs/volumes/vmhyper1-toc:Local/vcb/*

The server is 5.5, running on AIX 5.3

What's up with port 1757? Am I missing something blazingly obvious?

--
Stephen Stackwick
Jacob & Sundstrom, Inc.
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick < at > jasi.com




--

Met vriendelijke groeten,

Remco Post, PLCS




--
Stephen Stackwick
Jacob & Sundstrom, Inc.
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick < at > jasi.com

--
Met vriendelijke groeten,

Remco Post
remco < at > pipsworld.nl




--
Stephen Stackwick
Jacob & Sundstrom, Inc.
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick < at > jasi.com

Post The mysterious port 1757 
On Jul 31, 2008, at 11:51 AM, Steve Stackwick wrote:

Thanks, Richard, but after reading the Technote I'm still a little
confused. It seems that the port is selected (presumably randomly) at
initial contact right after installation and stored by the server, at
least that's how I'm reading the technote. If so, where does that
configuration live on the server? I don't see anything in CLIENT_LLA.


The TSM server's database table for storing derived client values is
not exposed to us customers. The port number is not reflected in the
CLIENT_LLA field of the NODES table because, like the CLIENT_HLA
field, these are to reflect values explicitly set by the customer for
server-initiated communications.

what I know, Richard

Post The mysterious port 1757 
Ah, I'll buy that, esp. since the port is persistent and obviously
stored *somewhere*. Mere mortals are not to know where, though,
apparently. Thanks, Richard!

Steve

On Thu, Jul 31, 2008 at 12:27 PM, Richard Sims <rbs < at > bu.edu> wrote:
On Jul 31, 2008, at 11:51 AM, Steve Stackwick wrote:

Thanks, Richard, but after reading the Technote I'm still a little
confused. It seems that the port is selected (presumably randomly) at
initial contact right after installation and stored by the server, at
least that's how I'm reading the technote. If so, where does that
configuration live on the server? I don't see anything in CLIENT_LLA.


The TSM server's database table for storing derived client values is
not exposed to us customers. The port number is not reflected in the
CLIENT_LLA field of the NODES table because, like the CLIENT_HLA
field, these are to reflect values explicitly set by the customer for
server-initiated communications.

what I know, Richard




--
Stephen Stackwick
Jacob & Sundstrom, Inc.
401 East Pratt St., Suite 2214
Baltimore, MD 21202-3003
(410) 539-1135 * (866) 539-1135
sstackwick < at > jasi.com

Display posts from previous:
Reply to topic Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
  


Magic SEO URL for phpBB