Below are several initialization problems that one might encounter during
initial configuration of the z/VM 540 SSL server, with actions that can
be taken which should help with their resolution.
- DMSLIO201W warning and DTCSSL300E error reported during server initialization
DTCRUN1011I Server started at hh:mm:dd on dd mon yyyy (day)
DTCRUN1011I Running server command: VMSSL
DTCRUN1011I Parameters in use:
DTCRUN1011I MAXSESSIONS 20 KEYFILE /etc/gskadm/Database.kdb
DTCSSL2423I Using server module: SSLSERV MODULE E2 - 2/26/09 16:28:52
DTCSSL002I SSLSERV main() - PROGMAP:
Name Entry Origin Bytes Attributes
SSLSERV 0FD63288 0FD63288 00041D73 Amode 31 Reloc:
DTCSSL002I DEBUG settings: Debug: 0
DTCSSL002I main() started...
DTCSSL015I Server initialization in progress (z/VM level 540 - PK65850)
DTCSSL100I This software incorporates the RSA algorithm
DTCSSL132I Server ID: SSLSERV
DMSLIO201W The following names are undefined:
EDCUCSNM
DMSLIO201W The following names are undefined:
EDCUCSNM
DTCSSL300E gsk_open_database_using_stash_file() failed; rc: 0x3353009
reason: File or keyring not found
DTCSSL127E Server shutdown has commenced
DTCSSL128E Server shutdown is complete
DTCRUN1015I Server ended with RC=1 at hh:mm:dd on dd mon yyyy (day)
DTCRUN1019I Server will not be logged off because you are connected
Ready;
For this case, DMSLIO201W warning and the the 0x3353009 return
code might result from referencing a non-540 level SSL server
:type.class definition within one of the DTCPARMS configuration
files available to the SSL server, or from erroneous mount parameters that have
been specified for the :mount. tag.
Check the various DTCPARMS files for an outdated :nick.ssl
:type.class entry, such as this sample:
:nick.ssl :type.class
:name.SSL daemon
:command.VMSSL
:diskwarn.YES
A :nick.ssl :type.class entry (appropriate for the level 540
SSL server should be similar to that shown here, from the PK65850-level
IBM DTCPARMS file:
:nick.ssl :type.class
:name.SSL daemon
:command.VMSSL
:runtime.C
:diskwarn.YES
:Admin_ID_list.TCPMAINT GSKADMIN
:memory.256M
:mixedcaseparms.YES
:mount. /../VMBFS:VMSYS:ROOT/ / ,
/../VMBFS:VMSYS:SSLSERV/ /tmp ,
/../VMBFS:VMSYS:GSKSSLDB/ /etc/gskadm
:parms.KEYFile /etc/gskadm/Database.kdb
- DTCSSL300E error (only) reported during server initialization
DTCRUN1011I Server started at hh:mm:dd on dd mon yyyy (day)
DTCRUN1011I Running server command: VMSSL
DTCRUN1011I Parameters in use:
DTCRUN1011I KEYFile /etc/gskadm/Database.kdb
DTCSSL2423I Using server module: SSLSERV MODULE E2 - 12/30/08 12:26:53
DTCSSL002I SSLSERV main() - PROGMAP:
Name Entry Origin Bytes Attributes
SSLSERV 0F8E8288 0F8E8288 00041D73 Amode 31 Reloc
DTCSSL002I DEBUG settings: Debug: 0
DTCSSL002I main() started...
DTCSSL015I Server initialization in progress (z/VM level 540 - PK65850)
DTCSSL100I This software incorporates the RSA algorithm
DTCSSL132I Server ID: SSLSERV
DTCSSL300E gsk_open_database_using_stash_file() failed; rc: 0x3353009
reason: File or keyring not found
DTCSSL127E Server shutdown has commenced
DTCSSL128E Server shutdown is complete
DTCRUN1015I Server ended with RC=1 at hh:mm:dd on dd mon yyyy (day)
DTCRUN1019I Server will not be logged off because you are connected
Ready;
This error (more specifically, the 0x3353009 return code) likely
has resulted due to incorrect file permissions assigned to the
Database.sth (or Database.kdb) file.
To check the file permissions, issue the following OPENVM LISTFILE
command after logon of the GSKADMIN user ID:
openvm listfile /etc/gskadm (own'
Confirm that the file permissions reflect read permission for the
security group for the Database.sth and Database.kdb files:
Directory = '/etc/gskadm/'
User ID Group Name Permissions Type Path name component
gskadmin security rwx r-- --- F 'Database.kdb'
gskadmin security rw- --- --- F 'Database.rdb'
gskadmin security rwx r-- --- F 'Database.sth'
If this is not the case, issue the following OPVENVM PERMIT commands
to establish such permission:
openvm permit /etc/gskadm/Database.kdb rw- r-- ---
openvm permit /etc/gskadm/Database.sth rw- r-- ---
- DMSOVZ2120E Unable to resolve current working directory for path name
(From attempted mount of the /../VMBFS:VMSYS:GSKSSLDB/ filespace)
One possible cause for this error is due to the VMSERVU file pool
server not being in operation. By default, the /etc, /tmp and /var
directories are maintained in the VMSYSU: file pool, and not in
VMSYS file pool that manages the root directory. Ensuring that the
VMSERVU server is fully operational (not just logged on) likely will
resolve this problem.
The following command can be used to confirm the VMSERVU server is
active:
query filepool overview vmsysu:
Another possible (but uncommon) cause for this error is due to lack of
availability of one (or all) of the /etc, /tmp or
/var directories. Such a condition could result if the VMSYSU:
filepool is regenerated, perhaps to recover filepool operation after a
significant file pool problem.
To confirm the filespaces for these directories are present, issue this
filepool QUERY command:
query enroll filespace for all vmsysu:
The query results should be similar to this (with BFS entries being important):
Number Of file spaces = 5
<PUBLIC> SFS
ETC BFS
MAINT SFS
TMP BFS
VAR BFS
If one or more BFS filespaces are not present, it likely is necessary to
recreate these (by running the BFSROOT command) , as well as those
required for the TCP/IP SSL (and, LDAP) servers (by running respective
LOADBFS commands). The commands cited below will accomplish this
task.
Notes
-
Use the MAINT user ID (or its equivalent) to issue these commands, after
having ensured that the VMSERVS and VMSERVU file pool servers are up and
running.
-
For the commands listed here, it is assumed that no PPF overrides to the
SERVP2P $PPF file are in use by your installation. If this is not the
case, adjust the VMFSETUP commands accordingly.
-
One can expect messages to be produced indicating that certain resources
are already defined. Such messages likely can be dismissed.
set filepool vmsys:
access 493 z
bfsroot
vmfsetup detach
vmfsetup servp2p tcpipp2p (link
loadbfs sslserv loadbfs
loadbfs gskssldb loadbfs
vmfsetup detach
After having completed these commands, you can again issue the QUERY
ENROLL FILESPACE FOR ALL VMSYSU: command cited previously, to confirm
the necessary filespaces are present.
