Re: Missing lin_taped module
Thanks to all who replied to the question. The support center and others confirmed that I needed to rebuild the lin_tape module after each application of a kernel patch. It seems that there are headers included in the module that align with the kernel and will break the module if the kernel is updated. I don't know how I am going to address the issue using SMT to update the images when new patches are available. I guess when TSM breaks I will look at the lin_tape module before looking at anything else. I also had a problem with the permissions on the /dev files. I am using a userid other than root to run TSM and the /dev files are owned by root. The support center found a technote that describes a udev.permissions file that can address this issue. I am trying that now. Ruddy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post Sent: Monday, June 18, 2012 3:05 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Missing lin_taped module >>> On 6/18/2012 at 03:38 PM, "Melancon, Ruddy" >>> wrote: > Do I or Will I have to reinstall lin_taped every time I install patches?? If IBM didn't package it correctly, yes. If they did package it correctly, then you shouldn't have to do that. A PMR with IBM should help clarify if something is wrong, or something is wrong with their packaging. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
DB2 Connect client, any sense in running server?
We're running the DB2 Connect client at the various distributed machines that require it. Is there any sense in running the DB2 Connect server product in a Linux on System Z guest to serve the other guests or the distributed machines removing the client from those distributed devices? I am of the impression that the only purpose for the server, at this point, is to perform two-factor commit under certain circumstances that we do not encounter here. Do the advantages of running the client wash out when Linux on System Z for a set of guests becomes the configuration? Thank you for sharing your experience and advice. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: DB2 Connect client, any sense in running server?
I'm not the dba, but I think the primary reason we run it in a Linux on z guest and not as clients on each is for maintenance and support reasons. It's tough to keep the clients up to date. Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Tom Ambros Sent: Thursday, June 21, 2012 7:43 AM To: LINUX-390@VM.MARIST.EDU Subject: [LINUX-390] DB2 Connect client, any sense in running server? We're running the DB2 Connect client at the various distributed machines that require it. Is there any sense in running the DB2 Connect server product in a Linux on System Z guest to serve the other guests or the distributed machines removing the client from those distributed devices? I am of the impression that the only purpose for the server, at this point, is to perform two-factor commit under certain circumstances that we do not encounter here. Do the advantages of running the client wash out when Linux on System Z for a set of guests becomes the configuration? Thank you for sharing your experience and advice. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: DB2 Connect client, any sense in running server?
Thomas, We are an SAP shop. Years ago, we ran the full DB2 connect client on each SAP application server. This would be a real pail at times when DB2 maintenance came along. It was also a consumed quite a bit of disk space on the server. Also there was the matter of the configuration that had to be co-ordinated with the SAP folks. SAP has since migrated to what was called a 'thin client.' (I can find the real name if you want.) One of the advantages of the thin client was that to install, you basically just untarred a directory structure and then pointed your PATH to it. It is so simple that the the SAP admin folks took over the maintenance of DB2 connect. As far as configuration goes, sometimes we have to make an entry in a INI file, but most of the time we do not. Ron Foster Baldor Electric Company 5711 R S Boreham Jr Street Fort Smith, AR 72901 Phone:479-648-5865 Fax:479-646-5440 Email: ron.fos...@baldor.abb.com www.baldor.com From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Tom Ambros [thomas_amb...@keybank.com] Sent: Thursday, June 21, 2012 9:43 AM To: LINUX-390@VM.MARIST.EDU Subject: DB2 Connect client, any sense in running server? We're running the DB2 Connect client at the various distributed machines that require it. Is there any sense in running the DB2 Connect server product in a Linux on System Z guest to serve the other guests or the distributed machines removing the client from those distributed devices? I am of the impression that the only purpose for the server, at this point, is to perform two-factor commit under certain circumstances that we do not encounter here. Do the advantages of running the client wash out when Linux on System Z for a set of guests becomes the configuration? Thank you for sharing your experience and advice. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Missing lin_taped module
> Thanks to all who replied to the question. The support center and others > confirmed that I needed to rebuild the lin_tape module after each > application of a kernel patch. It seems that there are headers included in > the > module that align with the kernel and will break the module if the kernel is > updated. That's a pretty lame response. DKMS (dynamic kernel module support) has been available for about 10 years now (since 2003), which provides a widely supported way to deal with issues like this. http://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support for details. DKMS provides a properly versioned RPM for code like this automatically on installation of the new kernel. We use it for OpenAFS modules on about a dozen platforms, which are even more kernel-invasive than lin_tape, so not much of an excuse for not doing it for something as simple as a device driver. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Linux on System z: publication updates available for Red Hat Enterprise Linux 6.3
The following Linux on System z publications are now available at: http://www.ibm.com/developerworks/linux/linux390/documentation_red_hat.html Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6.3 Abstract This document describes the device drivers, features, and commands available to Red Hat Enterprise Linux 6.3 for the control of IBM System z devices and attachments. Part 1. General concepts Chapter 1. How devices are accessed by Linux Chapter 2. Devices in sysfs Chapter 3. Kernel and module parameters Part 2. Storage Chapter 4. DASD device driver Chapter 5. SCSI-over-Fibre Channel device driver Chapter 6. Channel-attached tape device driver Chapter 7. XPRAM device driver Part 3. Networking Chapter 8. qeth device driver for OSA-Express (QDIO) and HiperSockets Chapter 9. OSA-Express SNMP subagent support Chapter 10. LAN channel station device driver Chapter 11. CTCM device driver Part 4. z/VM virtual server integration Chapter 12. z/VM concepts Chapter 13. Writing kernel APPLDATA records Chapter 14. Writing application APPLDATA records Chapter 15. Reading z/VM monitor records Chapter 16. z/VM recording device driver Chapter 17. z/VM unit record device driver Chapter 18. z/VM DCSS device driver Chapter 19. Shared kernel support Chapter 20. Watchdog device driver Chapter 21. z/VM CP interface device driver Chapter 22. Deliver z/VM CP special messages as uevents Chapter 23. AF_IUCV address family support Chapter 24. Cooperative memory management Part 5. System resources Chapter 25. Managing CPUs Chapter 26. Managing hotplug memory Chapter 27. Large page support Chapter 28. S/390 hypervisor file system Chapter 29. ETR and STP based clock synchronization Part 6. Security Chapter 30. Generic cryptographic device driver Chapter 31. Pseudo-random number device driver Chapter 32. Data execution protection for user processes Part 7. Booting and shutdown Chapter 33. Console device drivers Chapter 34. Initial program loader for System z - zipl Chapter 35. Booting Linux Chapter 36. Suspending and resuming Linux Chapter 37. Shutdown actions Part 8. Diagnostics and troubleshooting Chapter 38. Logging I/0 subchannel status information Chapter 39. Channel measurement facility Chapter 40. Control program identification Chapter 41. Activating automatic problem reporting Chapter 42. Avoiding common pitfalls Part 9. Reference Chapter 43. Commands for Linux on System z Chapter 45. Selected kernel parameters Chapter 46. Linux diagnose code use Using the Dump Tools on Red Hat Enterprise Linux 6.3 Abstract: This document describes tools for obtaining dumps of Linux on System z instances. Table of Contents: Chapter 1. Introduction Chapter 2. Using kdump Chapter 3 Using a DASD dump device Chapter 4. Using DASD devices for multi-volume dump Chapter 5. Using a tape dump device Chapter 6. Using a SCSI dump device Chapter 7. Using VMDUMP Chapter 8. Handling large dumps Chapter 9. Sharing dump devices Appendix A. Examples for initiating dumps Appendix B. Obtaining a dump with limited size Appendix C. Command summary Appendix D. Preparing for analyzing a dump Dorothea Matthaeus Linux on System z Information Development IBM Deutschland Research and Development GmbH -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: DB2 Connect client, any sense in running server?
We converted from standalone client copies to DB2 Connect Server under zLinux. Reasons: 1. Cost. The standlone copy was about $450 per. The server copy for 25 Named user was around $2,250. A Named user is per user and cannot be shared. A 25 pack for concurrent users costs much more. Another varient is a cost per engine based on your application server or web server size. Then there is the enterprize wide license. 2. I have multiple DB2 Connect servers running. One is production which has been up for more then 2 years. A fall back server in case the production server crashes (just change what you connect to). And a test one and MY test one. 3. If I add another DB2 (VSE), I just need to add it to DB2 Connect Server. Many PC based product will then see the new server when you open the connection. 4. The "thin client" on the pc is much smaller in disk space and PC memory usage. 5. Putting it, or really "them" on zLinux, is what zLinux is all about. Server Consolidation. Takes about 1-2% CPU. However, you have already paid for your current copies. We went with the server method and redistribute the standalone copies to certain users that we couldn't talk into the server method. Tom Duerbusch THD Consulting Sent via BlackBerry by AT&T -Original Message- From: Tom Ambros Sender: Linux on 390 Port Date: Thu, 21 Jun 2012 10:43:16 To: Reply-To: Linux on 390 Port Subject: DB2 Connect client, any sense in running server? We're running the DB2 Connect client at the various distributed machines that require it. Is there any sense in running the DB2 Connect server product in a Linux on System Z guest to serve the other guests or the distributed machines removing the client from those distributed devices? I am of the impression that the only purpose for the server, at this point, is to perform two-factor commit under certain circumstances that we do not encounter here. Do the advantages of running the client wash out when Linux on System Z for a set of guests becomes the configuration? Thank you for sharing your experience and advice. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
