Re: DMSJLD653E Error
Hello Alan, The SFS preparatory steps for setting up the updated SSL server implementation need to be performed from an SFS administrative user ID, n ot TCPMAINT. Instructions for doing this can be found at this URL: http://www.vm.ibm.com/related/tcpip/tcspeins.html which describe use of the SSLPOOL utility and the TCP/IP Install/service id (5VMTCP40) for getting things done. Note that the SFS setup is required only to use an SSL SERVER pool. If a n existing, single SSL server will meet your SSL requirements, you can continue to use that (minidisk-based) server, although some configuration changes still are required. Run SSLPOOL with the PLAN and other appropria te parms, along with the NOPOOL option, to obtain a sampling of the needed changes.. Regards, Mark Cibula (z/VM TCP/IP Support)
Re: New z/VM Red Alert posting
Hello All, It's come to my attention that attendees at this week's SHARE have been informed that only a 610 level SSL Scalability and Enhancement PTF would be provided. For the record, PTFs for both the 540 and 610 levels will be m ade available. Regards, Mark Cibula (z/VM TCP/IP Support)
New z/VM Red Alert posting
Hello, A new z/VM Red Alert has been posted at: http://www.vm.ibm.com/service/redalert/ August 4, 2010 With this APAR and its associated requisites (listed in the document), TCP/IP for z/VM provides significant performance and scalability enhancements for the CMS-based SSL server, introduced with z/VM version 5 release 4. USERS AFFECTED: All z/VM customers who have configured the z/VM SSL server and are runnin g it in a production environment. Customers who acquire these updates, but have not employed an SSL server within their installation, do not need to complete the prescribed changes prior to placing service into production. Detailed information about these enhancements, their use, and system and configuration changes required to install these updates, can be found at this z/VM web site URL: http://www.vm.ibm.com/related/tcpip/vmsslinf.html Regards, Mark Cibula (z/VM TCP/IP Support)
Re: Question on SSLSERV and multiple stacks
Hi Marcy, Your supposition about needing distinct SSL server virtual machines for e ach stack is correct. But can they share /etc/gskadm/Database.kdb ? I can't see why not. Yes, the various SSL servers all can share the same key database. And.. If I've done that, can they use the same cert? Or am I just dreaming? Yes, they can each make use of the same certificate(s)... (No, you're not dreaming). The ability to share a common key database wa s our intent with having the 540 server key database maintained in the Byte File System. Of course, one can use separate databases if that's require d for some reason -- the database files and/or mount specifics just need t o be adjusted accordingly... Regards, Mark Cibula IBM z/VM TCP/IP Support Development
Re: 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)
Re: New CMS based SSLSERV problem... DTCSSL300E
Hi Mark, I suspect the errors you've encountered stem from somehow referencing a pre-540 SSL 'class' entry -- one that lacks the :runtime.C , :mount. and other tags that define values needed for the 540 SSL server. Please chec k your SYSTEM DTCPARMS file (or any others you've customized) for a stale/rogue pre-540 SSL class entry that looks like this one: :nick.ssl :type.class :name.SSL daemon :command.VMSSL :diskwarn.YES Also, ensure that a pre-540 level IBM DTCPARMS file is not present in the CMS search order of the (540) SSL server, and that thePK65850- level IBM DTCPARMS file *is* available. The class definition from this file is: :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 (Note: The 540 GA-level of this file lacks the 'SSLSERV' file space ID fo r the '/tmp' mount; commentary in the updated file explains why this needs to be included.) One other customer ran across the errors you cited for this same reason, but I've just not had a chance to update the page you had checked to add this 'gotcha'... Regards, Mark Cibula (z/VM TCP/IP Support)
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 ca n implement DTCPARMS server customizations (building on Dennis' post) to better isolate them, and to lessen the impact of changes to the IBM DTCPA RMS 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/v alues. 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 mig ht still have encountered some problems, since the old/new tags had little i n common... The type of change I suggest above is meant simply to illustrate how to k eep customizations separate from the (IBM) supplied defaults. (And, we do encourage this same type of thing on our own test systems so fewer server s go 'bump' as things are changed). -- Regards, Mark Cibula
Re: ZVM 5.4, TCPIP, and SCEXIT
The changes to dynamically reload a Telnet connection (or TN3270E printer management) exit without requiring a stack restart were introduced in Lev el 520. The dynamic reload is accomplished via OBEYFILE processing of an INTERNALCLIENTPARMS update. See the Usage Notes for the INTERNALCLIENTPA RMS statement for details. (And when so doing, read that 'TN3280EEXXIT' reference as a 'TN3270EEXIT'... I see that a correction is in order...;-)
Re: PTF providing CMS based SSL support
Hello Everyone, All PTFs that pertain to enablement of the z/VM 540 SSL server are now available and can be ordered. The complete list is available at this URL : http://www.vm.ibm.com/related/tcpip/tcsslsvc.html Regards, Mark Cibula (z/VM TCP/IP Support)
Re: Printing a TRSOURCE/IPFORMAT Trace
Hi Dick, The 'formatted' IPFORMAT data file (file type IPFDATA) is packed with the PIPE PACK stage. If you process this file with the PIPE UNPACK stage, you 'll have a flat file that contains all of the formatted packet data (after th e packet 'summary') in a more legible form, that you can edit, print as needed... The Pipe below will create suh a flat file: pipe tracex ipfdata a | unpack | tracex prtdata a The various formatted packets are prefixed using a Pn marker string. Regarding the (un?) ordered display of selected packets , this could be d ue to a bug in the code. If you'd like to pursue that further, just open a PMR with the support center... Regards, Mark Cibula, IBM z/VM Systems Management
Re: Coding the port statement in the TCPIP profile.
Hello Thomas and Suleiman, I believe the confusion over label length (and other characteristics) has arisen due to not considering the type of certificate. For a CA certificate, the label can be as Thomas cited -- up to 200 characters in length, can be mixed-case, and can contain blanks. A SERVER certificate label (that is/will be specified for securing a port) is restricted to 8 characters in length (this stems from the fact that the file name of the X509INFO file -- used for the *server* certificate request -- is used as the server certificate label). Since both server and CA certificates need to be 'received' to a CMS file prior to being stored in the SSL server certificate database, I understan d the opportunity for confusion... The key here (no pun intended) is to b e aware of the type of certificate - server or CA -- that one is dealing wi th. I hope this information helps clarify things... Regards, Mark Cibula; z/VM TCP/IP Support
Re: Deleting an LPRSET defined printer
Hello Bobby, The HELP file for LPRSET (help tcpi lprset) cites a RESET option. The command 'lprset (reset' should clear the (default SESSION-level print er and host values. Add the PERM option also if you want these values clear ed from LASTING GLOBALV. Regards, Mark Cibula; z/VM TCP/IP Support
Re: z/VM 5,3 installation
Hello Richard, Your VMSYSx file pool servers were not up and running, so the LDAP BFS fi le processing failed. See the info. at this URL for more information: http://www.vm.ibm.com/related/tcpip/tcprdbfs.html Regards, Mark Cibula; z/VM TCP/IP Support
Re: DMSPAR727E
Hi Jim, Looks like you're using a pre-530 level SSLADMIN EXEC. With 530, SSLADMIN was modified such that it no longer makes use of the C MS command parser, so the DTCUPA/DTCUSY TEXT files previously associated wit h its use of that function are not supplied with level 530. (Thus the error message you've received.) A check of your search order should help you resolve things... Regards, Mark Cibula - z/VM Systems Mangement, TCP/IP Support
Re: IPFORMAT
Hi Brian, Perhaps just processing the formatted file with the PIPE UNPACK stage wil l provide data in a format more suited to your needs: pipe tracex ipfdata a | unpack | tracex altdata a The various formatted packets are prefixed using a Pn marker string. Regards, Mark Cibula, IBM z/VM Systems Management
Re: SSLSERV
Hello, In case this problem has not yet been resolved: 13:32:22 * MSG FROM TCPIP2 : Restarting you because you have no passive open on TCP port check that the correct TCPIP DATA file is being referenced by the SSL server, and that the TCPIPUSERID statement in that file cites the correct TCP/IP stack ID (TCPIP2). I suspect you've configured the TCPIP2 stack f or using the SSL server, but that the TCPIPUSERID statement in effect is directing the SSL server to connect to a different stack (likely, 'TCPIP' ). Regards, Mark Cibula (IBM z/VM Systems Management)
Re: VMRPC placement in z/VM 5.2
Hello Mats, The Programmer's Reference citation is correct. The VMRPC TXTLIB part is built on the TCPMAINT 492 test-build disk, and should then also reside on the client-code disk (TCPMAINT 592) when TCP2PROD is used to place files into production. The various client 'run-time' files are copied from the 492 disk to the 592 disk when a 'wildcard' CATALOG file entry (similar to the one that follows) is processed by TCP2PROD: BLD3Z BLD2Z * * = = The CATALOG file entries you cited are in place to specifically propagate the VMRPC TXTLIB to the MAINT 493 /193 disks, to ensure it is available f or use whenever the (CMS) DMSVSMAS module is built (without requiring a separate access of the TCPMAINT 592 disk beforehand). Regards, Mark Cibula, z/VM TCP/IP Development and Support
