Re: BFS SSLSERV question
On Friday, 03/20/2009 at 09:29 EDT, Jim Bohnsack jab...@cornell.edu wrote: Thank you all for your responses. It sounds as if it is as I suspected, a total lack of knowledge about BSF and almost as much of a lack of knowledge about SFS. It might be a good idea to include some of these SFS/BFS peculiar hints or ideas in the TCPIP doc, especially for the VM newbie (as well as for the old timer who still carries a pocket full of 5081 cards--for you kids, a 5081 card is an IBM punched card). It's worth pointing out, too, that with certificates and private keys being held in BFS, it becomes a more valuable chunk of data than in prior decades. (For those who didn't use it for anything else.) You might find it worth the effort to create your own SFS filepool so that release-to-release migrations don't create a disruption since you have to actually migrate VMSYS content. With your own global filepool, your 2nd level system can down to the 1st level system (via TSAF) to pick up the BFS filesystem. If there is a need to migrate a prior release's database content to a new database for any reason, we will be very clear on that point in the Migration Guide. Alan Altmark z/VM Development IBM Endicott
Re: BFS SSLSERV question
You might find it worth the effort to create your own SFS filepool so that release-to-release migrations don't create a disruption since you have to actually migrate VMSYS content. With your own global filepool, your 2nd level system can down to the 1st level system (via TSAF) to pick up the BFS filesystem. Alan Altmark z/VM Development IBM Endicott Sounds like a good practice for the next release. Call it CONFIG or something like that, and fix the apps like DFSMS to put their config files there by default.
Re: BFS SSLSERV question
On Sunday, 03/22/2009 at 03:17 EDT, David Boyes dbo...@sinenomine.net wrote: Sounds like a good practice for the next release. Call it CONFIG or something like that, and fix the apps like DFSMS to put their config files there by default. Sorry, David, that would just make things worse since we'd keep shipping a new CONFIG filepool in each release as we do with VMSYS and VMSYSU, and then there would be two *global* CONFIG filepools in the collection. Two objects would attempt to occupy the same space and one would be annihilated. There can be only one. If you don't want IBM to touch it, you need to create it. Alan Altmark z/VM Development IBM Endicott
Re: BFS SSLSERV question
In this new redbook we do indeed recommend to create a special filepool as storage space for the certificates and the LDAP databases, this to avoid problems with release migrations. The principle: customer data in your filepool; software in IBM's VMSYS. This is definitely not the way things are explained in the TCP/IP manual, then everything goes in VMSYS. We detail the required steps, to create the new filepool; what to change in the LDAP setup, what to mount to run gskkyman, ... 2009/3/22 Alan Altmark alan_altm...@us.ibm.com On Sunday, 03/22/2009 at 03:17 EDT, David Boyes dbo...@sinenomine.net wrote: Sounds like a good practice for the next release. Call it CONFIG or something like that, and fix the apps like DFSMS to put their config files there by default. Sorry, David, that would just make things worse since we'd keep shipping a new CONFIG filepool in each release as we do with VMSYS and VMSYSU, and then there would be two *global* CONFIG filepools in the collection. Two objects would attempt to occupy the same space and one would be annihilated. There can be only one. If you don't want IBM to touch it, you need to create it. Alan Altmark z/VM Development IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Quick Start Guides (1-pagers) Reloaded
When I talk about our plans for the future, there is always a caveat: things change. Everyone's understanding on that point is why I feel free to have the discussions here that I do. In a post last week I indicated that we would replace the Quick Start guides with some vaguely-described widget in the books. I cannot tell a lie: Chuckie made me do it. Though I use a cream daily to prevent its spread, I have been infected with Mr. Sunshine's optimism. While we have had several discussions in the Lab over the past year on this subject, none of the alternatives so far have met IBM's printing standards, contained all of the information needed, and met a subjective measure of brevity. Pick two We'll continue to revisit the issue from time to time. As with all futures discussions, the opera ain't over 'til the fat lady sings. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: New CMS based SSLSERV problem... DTCSSL300E
On Friday, 03/20/2009 at 05:48 EDT, Alan Ackerman alan.acker...@earthlink.net wrote: We have a problem with QWS3270. In 5.2.0/5.3.0 everything works fine with static SSL. In 5.4.0, QWS3270 prompts me for a certificate password. I provide one and everything works, but it sure slows me down. If I hit cancel instead I get disconnected with an unable to connect error. There is no way to turn off this behavior in QWS3270 -- is there any way to turn it off in the server? We are putting our heads together with our z/OS brethren to work out exactly what is going on. The more we study the problem, the more confused the team becomes. I think we're seeing different error behavor on static and dynamic sessions, making the problem more elusive. (It's complicated by folks trying to use dynamic SSL with a static-only client.) With any luck the problem will be in VM and we can fix all the client problems at once. I would truly hate to have an endemic problem. Alan Altmark z/VM Development IBM Endicott
Re: SCSIDISC SAMPEXEC on z/VM 5.4.0
On Thu, 19 Mar 2009 21:43:00 +0100, Rob van der Heij rvdh...@gmail.com wrote: On Thu, Mar 19, 2009 at 1:29 PM, Alan Altmark alan_altm...@us.ibm.com wrote: We use filetype SAMP to indicate that the item is not a supported/documented part of the product, but is something we provide for you to use. Sometimes the point is the source, demonstrating how to do something, and other times it is the functionality. SCSIDISC falls into the latter category. I'm in a positive mood today: that's also good news ;-) That probably means there is no concern at all to ship the Runtime Library of CMS Pipelines as SAMP with the product to complement the indoor plumbing that is 10 years old now. So we don't have to send customers to download something from the Bad Internet to install on their precious z/VM system. Do we need a SHARE requirement raised for this to happen? Sir Rob the Plumber = == = I believe we raised one and it was rejected. The reason given was (I think) that they cannot suport the runtime, but, as you point out, they don't support the SAMP code, either. Endicott has a bad case of NIH. (Not Invented Here.) Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: SCSIDISC SAMPEXEC on z/VM 5.4.0
On Sunday, 03/22/2009 at 10:26 EDT, Alan Ackerman alan.acker...@earthlink.net wrote: Endicott has a bad case of NIH. (Not Invented Here.) That is uncharitable of you, Alan, as you know well that z/VM is full of stuff that Wasn't Invented Here. I'm not sure what the point would be since you have to go the Pipeline RTL to get the latest version anyway, as you don't now whether some tool you have uses a stage in a newer version. Just go download it and be done with it. (To that end I've thought it would be nice to have wget included with the system as a standard TCP/IP client.) As I already said, we don't ship software that isn't part of the product. Whether it's an example or Type 1 code, it's part of the z/VM, The Product. Shipping other software has all sorts of legal implications. For example, we must not inadvertantly give the IBM imprimatur to non-product software as it could enable someone to get around employer restrictions on using downloaded software by claiming that it came with z/VM. That creates risk with no compensating benefit. Alan Altmark z/VM Development IBM Endicott
