Mark,
Thanks, but I think we're getting to a point where the solution is more
trouble than the original problem. I'll just set a standard MAXSESSIONS
value that's big enough for our largest system. That will be bigger
than what our test systems need, but at least we will be testing the
same value that we use in production. The alternative would be to
maintain the list of exempt cipher suites in the node-specific file.
While changing it on every system would be a pain, I don't expect it to
change often.
Dennis O'Brien
39,516
-----Original Message-----
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Mark Cibula
Sent: Friday, March 20, 2009 06:53
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] New CMS based SSLSERV problem... DTCSSL300E
Hi Dennis,
What you want to do (augment an existing tag value) can't be done using
j
ust
DTCPARMS-defined tags and values, because (for a given :type.server and
:type.class pairing) any tag present in the 'server' entry overrides any
same-named tag that exists in the corresponding 'class' entry -- the
valu
es
for the two tags are not combined.
When I first saw your question, I had also intended to suggest use of
the
TCPRUNXT exit, but with it, you can't really do exactly what you've
descr
ibed...
You can supply additional (or, replacement) tag/value overrides via the
e
xit
(with some limitations, based on the exit call type -- SETUP or BEGIN),
b
ut
there is no information provided with the current interface that allows
inspection of the set of tags and values 'known' by TCPRUN at the point
o
f
either call type. So, you can't modify or augment a tag value based on
i
ts
current value. This is a design point that limits some usefulness of
the
exit, at least with respect to what you want to do. If you see the need
for
this capability, a formal request would be the avenue to pursue it.
Though, having now given this some thought, there is likely a way to use
the
TCPRUNXT server exit (with a few updates) that would allow what you're
interested in doing. I'll contact you off-line, after I've had a chance
to
see if my ideas for doing this pan out...
Regards, Mark Cibula (z/VM TCP/IP Support)
