Thank you to both Dennis and Mark. I had the mount commands in my DTCPARMS, 
they just weren't syntactically correct. Everything appears to be fine now...

Mark Wiggins

-----Original Message-----
From: Mark Cibula [mailto:cibul...@us.ibm.com]
Sent: Monday, March 16, 2009 6:11 PM
Subject: Re: New CMS based SSLSERV problem... DTCSSL300E

Dennis (and Mark W) --

Apologies for the somewhat duplicate posting - ran into a browser timeout
whilst putting my posting together..   I would like to suggest how one can
implement DTCPARMS server customizations (building on Dennis' post) to
better isolate them, and to lessen the impact of changes to the IBM DTCPARMS
file itself.

* Use this 'override' entry in the SYSTEM DTCPARMS file:
* (Because the 'parms' value is overridden, the :parm. tag/value from IBM
* DTCPARMS needs to first be duplicated and then modified within this
* (SYSTEM DTCPARMS) file so as not to lose the Keyfile information.

:nick.SSLSERV    :type.server   :class.ssl
    :Admin_ID_list.TCPMAINT GSKADMIN SYSPROG1 SYSPROG2
    :parms.KEYFile /etc/gskadm/Database.kdb
                     MAXSESSIONS 30
                     EXEMPT LOW

With the above ':type.server' entry in place, a ':nick.ssl :type.class'
entry should no longer be necessary within SYSTEM DTCPARMS.  The 'class'
entry in the IBM DTCPARMS will provide the remainder of the needed tags/values.

Granted, with the significant change to the ssl 'class' with 540, having
done something similar to the above for a 530 SSL 'server' entry, one might
still have encountered some problems, since the old/new tags had little in
common...

The type of change I suggest above is meant simply to illustrate how to keep
customizations separate from the (IBM) supplied defaults. (And, we do
encourage this same type of thing on our own test systems so fewer servers
go 'bump' as things are changed).

-- Regards, Mark Cibula

Reply via email to