Re: Bulk YOU updates?
I "think" autoyast2 (alice replacement) can also do things like this. I've just recently started reading up on it and haven't gotten too deep, but I did install it and it looks pretty interesting. http://www.suse.de/~nashif/autoinstall/8.0/html/ Leland -Original Message- From: Vic Cross To: [EMAIL PROTECTED] Sent: 6/10/2003 7:02 PM Subject: Re: Bulk YOU updates? On Tue, 10 Jun 2003, Tom Duerbusch wrote: > Is there an existing HOWTO on this? What about the shops with hundeds > of Penguins? What do you do? Not that they're likely to get to hundreds here (but you never know, I guess), but we're using APT-RPM. I'm sketchy on the details of the implementation, but what basically happens is that the APT repository will hold several 'builds' of a distribution, with each build representing packages at different levels (errata updates at a particular date, for example). When you've completed testing of your new build, you do an 'apt-get dist-upgrade' (I think) from the server and it upgrades to the next build (at the moment I think this is a manual process, but the guys are working on a semi-automatic method driven by something like cfengine). Different servers can be held at different levels of the build, and individual servers can be upgraded as change windows and requirements allow. Once you have no servers using a particular build (and you're sure you won't have to regress a server to it), you can remove that build from the repository. How well would APT-RPM work with SLES? I'm afraid I don't know. It might be worth a look-at, though. Cheers, Vic
Re: Oracle client on VSE?
OK, since you started the cross post, I'll answer that way. A previous poster hit the nail on the head. The VSE Redirector can do this. With a database on Linux for S/390 (DB2 or Oracle), VSE can access it as if it were a VSAM file. So any of your COBOL Batch or COBOL/CICS programs can access database tables. There is a mapping tool available that will map table columns into VSAM accessible fields. We are currently conducting a proof-of-concept with a customer. The big question (apologies to the Oracle bigots), why Oracle? This process works for Oracle as well as DB2 on Linux for S/390. Don't you currently have a license for DB2 UDB already? On Tuesday 10 June 2003 09:53 am, you wrote: > Sorry for the major crosspost, but between the three groups, I will get > all the likely suspects... > > Our DB2 for VSE conversion isn't looking so good. And now we are > looking at other options. > > One option that wasn't considered when we went to DB2 was Oracle. Now > that is seems to be available for Linux/390, it is back to being a > player again. > > The problem is that I just can't see how VSE batch, VSE CICS/TS and VM > batch can use Oracle on Linux/390. We have to compile Cobol programs. > That would seem to need, at a minimum, a translator plus object decks > brough in during the LNKEDT. > > Part of my brain lock, is my experience with Oracle in the '80s. I did > have it running on VSE/SP 2.1 (it really did run there). It was a full > version. Problem was, was that it took 2 ICCF pseudo partitions per > Oracle Forms user. Not going to happen! Then we ran Oracle under VM. > Both cases we had full blown versions that allowed us to compile. Just > like the full blown version of DB2 is needed to compile in VM and VSE. > > So, I don't see how the VM/VSE world can be a part of it. > > Any body running this way? > > Tom Duerbusch > THD Consulting -- Rich Smrcina Sr. Systems Engineer Sytek Services, A Division of DSG Milwaukee, WI rsmrcina at wi.rr.com rsmrcina at dsgroup.com Catch the WAVV! Stay for Requirements and the Free for All! Update your S/390 skills in 4 days for a very reasonable price. WAVV 2004 in Chattanooga, TN April 30-May 4, 2004 For details see http://www.wavv.org
Re: Bulk YOU updates?
On Tue, 10 Jun 2003, Tom Duerbusch wrote: > Is there an existing HOWTO on this? What about the shops with hundeds > of Penguins? What do you do? Not that they're likely to get to hundreds here (but you never know, I guess), but we're using APT-RPM. I'm sketchy on the details of the implementation, but what basically happens is that the APT repository will hold several 'builds' of a distribution, with each build representing packages at different levels (errata updates at a particular date, for example). When you've completed testing of your new build, you do an 'apt-get dist-upgrade' (I think) from the server and it upgrades to the next build (at the moment I think this is a manual process, but the guys are working on a semi-automatic method driven by something like cfengine). Different servers can be held at different levels of the build, and individual servers can be upgraded as change windows and requirements allow. Once you have no servers using a particular build (and you're sure you won't have to regress a server to it), you can remove that build from the repository. How well would APT-RPM work with SLES? I'm afraid I don't know. It might be worth a look-at, though. Cheers, Vic
Re: SLES8 dasdfmt problem
This is during install of sles8. I do the load and the dasd shows up in the window. I go to another ssh to format and get these results... I still think this has something to do with the RAMAC 3990-13 controllers and older RAMAC B23 dasd. I do not see any disk addrs in the /proc/subchannels... We're going to wait a week or two until this client cuts over their z800 to production, at which time it will have access to a newer RVA Then we'll give it another go Thanks, Dave Myers Denver Solutions Group Senior Systems Engineer Office Phone: (303) 996-7112 Cellular Phone: (303) 619-0782 Home Office: (303) 948-0027 Fax: (303) 706.1713 e-mail: [EMAIL PROTECTED] Jim Sibley <[EMAIL PROTECTED] To: [EMAIL PROTECTED] m.com>cc: Sent by: LinuxSubject: Re: SLES8 dasdfmt problem on 390 Port <[EMAIL PROTECTED] ARIST.EDU> 06/10/2003 01:14 PM Please respond to Linux on 390 Port Dave, is this an install or adding dasd after the install? I have done both with SLES8 on RAMAC (STK) with no problems as well as Shark. The usual suspects are: - during the install, did you "load" the dasd before going to next? after install: - have you added the devices to your zipl.conf and done the zipl? - do you use cio_ignore and the volumes you want are in the ignore list? - if not in the zipl.conf list, did you try varying them on with echo "set device rang=xxx-yyy on" >> /proc/dasd/devices" - if they're not in /proc/subchannels then they could be in th cio_ignore list or not genned. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: hz_timer
On Tue, 10 Jun 2003, Jim Sibley wrote: > So where is /etc/sysctl.conf documented? I did a grep on the string in the > /usr/src/linux directory and and I found some informaiton on sysctl, bit I > did not find the file (though I did a developer's opinion that one should > read the code to find out how sysctl works!. > > So where does one look to find out about sysctl.conf? Did you try the man command? > -- Cheers John. Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: hz_timer
So where is /etc/sysctl.conf documented? I did a grep on the string in the /usr/src/linux directory and and I found some informaiton on sysctl, bit I did not find the file (though I did a developer's opinion that one should read the code to find out how sysctl works!. So where does one look to find out about sysctl.conf? Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: hz_timer
On Tue, 10 Jun 2003, Tom Duerbusch wrote: > When I do a > cat /proc/sys/kernel/hz_timer > it shows a '1'. > > I set it to '0' as suggested for VM types. But after a boot, it is back > to '1'. The documentation on this doesn't say anything about needing to Of course > put it in a boot script. Seems to imply that this is a one time only > thing. Of course;-) > > So.. > > 1. Am I doing something wrong? > 2. Is it broke (Suse 8.1 Jan 15 2003 fixes I guess this makes it > 2.4.19-46) > 3. Is the docs wrong and I do have to put it in a boot script? You do, or put it where it will be done wherever sysctl gets run. This is likely to be /etc/sysctl.conf -- Cheers John. Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Question about multiple Linux/390 instances under z/VM
On Tue, 10 Jun 2003, McKown, John wrote: > No money. "Linux is FREE!" I don't know how our marketting rep talked our > management to getting an IFL and z/VM when we upgraded to our z/800. We have > NO consolidation plans or any other "plan" for how to use Linux/390. Lots of > talk, but no real action at present. The only reason that we are testing > Oracle under Linux/390 is so that the Oracle people can "prove" that the > mainframe is inferior to a "full blown, 8-way" Sun box with ? Gigs of memory > (they are comparing it to a single IFL and 2 Gb of CSTOR + 1Gb of ESTOR > under z/VM). The unfortunate thing about "free software" as defined by the FSF is that it's open to misinterpretation. Read http://www.fsf.org/philosophy/free-sw.html Understand it, refer to it whenever appropriate, incoporate the entire text as an appendix to any relevant report etc. There's no licence fee, but that's where "free of cost" ends. You still have implementation costs, maintenance costs, support costs. Learn to use what you have, develop a plan to get the best out of what you have. And, if you don't do something speccy, the Sun platform will win this round, not because Oracle on Sun is better, but because the people doing the testing on that platform are better. It's like when a grandmaster visits your local chess club and takes on all comers in a simultaneous exhibition. Unless your club is pretty special, I'd back the GM to win every game. -- Cheers John. Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: The meddling continues:
That's assuming the GeCad stuff ever shows up in an MS OS. (You aren't the only suspicious mind on this list. :) Mark Post -Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 5:48 PM To: [EMAIL PROTECTED] Subject: Re: The meddling continues: On Maw, 2003-06-10 at 18:48, Beinert, William wrote: > I read in another post that MS does not plan to continue GeCad's current offerings. Look on the bright side. With antivirus built into the MS OS from the ground up the other vendors are going to be very keen to find an alternative market because they've just been netscaped... Alan
Re: The meddling continues:
On Maw, 2003-06-10 at 18:48, Beinert, William wrote: > I read in another post that MS does not plan to continue GeCad's current offerings. Look on the bright side. With antivirus built into the MS OS from the ground up the other vendors are going to be very keen to find an alternative market because they've just been netscaped... Alan
Re: hz_timer
For those of us that have to build for both LPAR and VM, you might consider adding this code to /etc/init.d/boot.local if [ $(grep -c "version = FF" /proc/cpuinfo) != 0 ] then /sbin/sysctl -w kernel.hz_timer=0 fi Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
more mail problems
Hello, again. Although Alan's suggestion for disabling ECN cleared up the majority of our listerv mail problems, there are still a few servers that we can't send mail to. We can ping and traceroute them, but no email makes it through. I've sniffed the traffic on our end, and it looks like we are throwing two syn packets into a brick wall, with no response from them at all. As in the other case, we can send mail to these servers from other, non-mainframe linux boxes. Why the disparity? One other question...I was running ethereal on some of our other images, and the only output information was Etherent II...no ip, hostnames or anything. Our listserv box shows the expected traffic, but not these machines that I just installed the same version of ethereal on. Anyone have any idea for the cause of the difference? -- Michael Lambert <[EMAIL PROTECTED]>
Re: Question about multiple Linux/390 instances under z/VM
We're no experts but we basically use the same minidisk addresses for the various linux guests. We also tend to put application products in their own filesystem on a separate VM minidisk. So our linux guests have basically the same minidisks for the SuSE linux filesystems. We didn't have a problem with limited dasd yet so each guest has 2 sets of system minidisks (2 levels of maintenance). We have a base linux guest where we install all system software. We have exec's which DDR maintenace to the other guests and perl scripts that copy appropriate files for a given guest depending on what application it runs (for example so that the correct daemons are started up). "McKown, John" wrote: > I have a general administration / setup question for people who are running > multiple Linux/390 systems under z/VM. Do all your Linux instances use the > same virtual addresses for things like DASD, regardless of the actual device > address? Or do you find it "better" to make the virtual DASD address match > the actual device address? I'm tending towards making all Linux/390 > instances use the same set of virtual DASD addresses, which are not even > related to the "real" DASD addresses. I think this would be easier to > maintain and "clone" new instances. Do you even try to make the Linux DASD > addresses "look like" the actual device numbers, or do you simply have a > range of virtual DASD addresses that you assign to physical devices. I'm > using MDISK statements for Linux DASD. Basically, so far, I give each > instance (OK, I only have one so far), the entire device OTHER THAN the > first cylinder. Sorry, but I don't trust the Linux administrator to not > destroy the DASD label, so this protects it from any mistakes. Oh, I'm the > OS/390 and z/VM (new) sysprog. I am familar with Linux on Intel and did help > the Linux administrator set up the initial Linux/390 system because she is > not s390 literate. And I had actually done a SuSE s390 install at home under > Hercules/390. So I was the "expert". > > -- > John McKown > Senior Systems Programmer > UICI Insurance Center > Applications & Solutions Team > +1.817.255.3225 > > This message (including any attachments) contains confidential information > intended for a specific individual and purpose, and its' content is > protected by law. If you are not the intended recipient, you should delete > this message and are hereby notified that any disclosure, copying, or > distribution of this transmission, or taking any action based on it, is > strictly prohibited.
Re: RH 2.4.9-38 k_timer
I just ran a little experiment. I took the Red Hat 2.4.20 kernel SRPM and looked to see just how many of the IBM patches from developerWorks for 2.4.19 were included. The answer was "not enough." Sigh. There was a whole bunch of stuff from 2.5 included, but apparently the IBM patches haven't been fully integrated into the official tree. Mark Post -Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 12:36 PM To: [EMAIL PROTECTED] Subject: Re: RH 2.4.9-38 k_timer On Maw, 2003-06-10 at 12:35, Chet Norris wrote: > Per company demand, I must stay with RedHat. I am running the 2.4.9-38 > kernel with the qdio/qeth OCO under z/VM 4.3 and need to get the > k_timer patch. The only download I've found is for a 2.4.19 kernel on > Developerworks. > Is there a rpm available for 2.4.9-38 somewhere? > What's the latest RH s/390 release that's clean? I've built 2.4.21rc7-ac for S/390 (took a little while on Hercules 8)) so the core stuff is now synced with -ac and I hope for 2.4.22pre with Marcelo's base tree. Building a new kernel rpm from a source tree isn't too hard, although you need to know what is in the kernel to know which patches to add, which makes it less trivial to deal with. Alan
Re: The meddling continues:
Maybe Sophos could be enticed, or inveigled, or just plain wheedled into offering a zLinux build? I've used their AV product on other unixes with happy results... (Is anybody from Sophos out there? Hello??) Thinking out loud, -dan. On Tue, 10 Jun 2003, Joe Poole wrote: > GeCad software made a name for itself by developing the first anti-virus > software to run on zLinux, and guess who just bought the technology? > > http://www.ravantivirus.com/pages/shownews.php?i=153 > > I wonder how long it will take before the Linux offerings are withdrawn? >
Re: SLES8 dasdfmt problem
Dave, is this an install or adding dasd after the install? I have done both with SLES8 on RAMAC (STK) with no problems as well as Shark. The usual suspects are: - during the install, did you "load" the dasd before going to next? after install: - have you added the devices to your zipl.conf and done the zipl? - do you use cio_ignore and the volumes you want are in the ignore list? - if not in the zipl.conf list, did you try varying them on with echo "set device rang=xxx-yyy on" >> /proc/dasd/devices" - if they're not in /proc/subchannels then they could be in th cio_ignore list or not genned. Regards, Jim Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] *** Grace Happens ***
Re: hz_timer
On Tue, 10 Jun 2003, Tom Duerbusch wrote: > I set it to '0' as suggested for VM types. But after a boot, it is back > to '1'. The documentation on this doesn't say anything about needing to > put it in a boot script. Seems to imply that this is a one time only > thing. ... > 3. Is the docs wrong and I do have to put it in a boot script? There is already a script, it configure it, take these steps: 1) Create/Update the sysctl config file, e.g. by: # echo kernel.hz_timer=0 >>/etc/sysctl.conf Verify and activate the current config in /etc/sysctl.conf: # sysctl -p If successful, it prints: kernel.hz_timer = 0 2) Activate the boot service to call sysctl -p at boot: chkconfig -a boot.sysctl (ignore the output in this case) Which creates a symlink to boot.sysctl in /etc/init.d/boot.d/ 3/Test) After the next reboot, # sysctl kernel.hz_timer should print: kernel.hz_timer = 0 Bernhard Kaindl
Re: hz_timer
Does SuSE have an /etc/sysctl.conf? If so, try putting a kernel.hz_timer = 0 in it... sysctl.conf's purpose is to hold desired values for runtime-adjustable kernel parameters (like at boot time), and you'd probably be better served placing your values here than needing to hunt around for it at some future time in your init scripts. ~ Daniel > I set it to '0' as suggested for VM types. But after a boot, > it is back to '1'. --- This message is the property of Time Inc. or its affiliates. It may be legally privileged and/or confidential and is intended only for the use of the addressee(s). No addressee should forward, print, copy, or otherwise reproduce this message in any manner that would allow it to be viewed by any individual not originally listed as a recipient. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is strictly prohibited. If you have received this communication in error, please immediately notify the sender and delete this message. Thank you.
Re: The meddling continues:
I read in another post that MS does not plan to continue GeCad's current offerings. Bill -Original Message- From: Joe Poole [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 1:26 PM To: [EMAIL PROTECTED] Subject: The meddling continues: GeCad software made a name for itself by developing the first anti-virus software to run on zLinux, and guess who just bought the technology? http://www.ravantivirus.com/pages/shownews.php?i=153 I wonder how long it will take before the Linux offerings are withdrawn?
Re: hz_timer
This is a kernel compile-time option. make menuconfig ---> General setup ---> [*] No HZ timer ticks in idle [*] Idle HZ timer on by default Mark Post -Original Message- From: Tom Duerbusch [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 1:32 PM To: [EMAIL PROTECTED] Subject: hz_timer When I do a cat /proc/sys/kernel/hz_timer it shows a '1'. I set it to '0' as suggested for VM types. But after a boot, it is back to '1'. The documentation on this doesn't say anything about needing to put it in a boot script. Seems to imply that this is a one time only thing. So.. 1. Am I doing something wrong? 2. Is it broke (Suse 8.1 Jan 15 2003 fixes I guess this makes it 2.4.19-46) 3. Is the docs wrong and I do have to put it in a boot script? Tom Duerbusch THD Consulting
Re: hz_timer
On Tue, 2003-06-10 at 12:31, Tom Duerbusch wrote: > When I do a > cat /proc/sys/kernel/hz_timer > it shows a '1'. > > I set it to '0' as suggested for VM types. But after a boot, it is back > to '1'. The documentation on this doesn't say anything about needing to > put it in a boot script. Seems to imply that this is a one time only > thing. > > So.. > > 1. Am I doing something wrong? > 2. Is it broke (Suse 8.1 Jan 15 2003 fixes I guess this makes it > 2.4.19-46) > 3. Is the docs wrong and I do have to put it in a boot script? Stuff in /proc is not persistent across reboots. So if you want this every time, put it in a boot script. Adam
hz_timer
When I do a cat /proc/sys/kernel/hz_timer it shows a '1'. I set it to '0' as suggested for VM types. But after a boot, it is back to '1'. The documentation on this doesn't say anything about needing to put it in a boot script. Seems to imply that this is a one time only thing. So.. 1. Am I doing something wrong? 2. Is it broke (Suse 8.1 Jan 15 2003 fixes I guess this makes it 2.4.19-46) 3. Is the docs wrong and I do have to put it in a boot script? Tom Duerbusch THD Consulting
The meddling continues:
GeCad software made a name for itself by developing the first anti-virus software to run on zLinux, and guess who just bought the technology? http://www.ravantivirus.com/pages/shownews.php?i=153 I wonder how long it will take before the Linux offerings are withdrawn?
CTG for LINUX v5.0
Hello Listers, I installed the CICS Transaction Gateway v5 for LINUX in an IFL. But I still need to configure the CTG.INI file. Can anyone send me a copy of a customized CTG.INI file so I can use it as sample to build my own. Thank you for your assistance, Emilio
Re: RH 2.4.9-38 k_timer
On Maw, 2003-06-10 at 12:35, Chet Norris wrote: > Per company demand, I must stay with RedHat. I am running the 2.4.9-38 > kernel with the qdio/qeth OCO under z/VM 4.3 and need to get the > k_timer patch. The only download I've found is for a 2.4.19 kernel on > Developerworks. > Is there a rpm available for 2.4.9-38 somewhere? > What's the latest RH s/390 release that's clean? I've built 2.4.21rc7-ac for S/390 (took a little while on Hercules 8)) so the core stuff is now synced with -ac and I hope for 2.4.22pre with Marcelo's base tree. Building a new kernel rpm from a source tree isn't too hard, although you need to know what is in the kernel to know which patches to add, which makes it less trivial to deal with. Alan
DB2 - Problems with JDBC driver
The error: Can't find library db2jdbc (libdb2jdbc.so) in java.library.path java.library.path=/opt/IBMJava2-s390-131/jre/bin:/opt/IBMJava2-s390-131/jre/bin/classic::/usr/lib Our environment vars: LD_LIBRARY_PATH=LD_LIBRARY_PATH=/home/db2inst1/sqllib/lib:/opt/IBM/db2/V8.1/lib CLASSPATH=/opt/jakarta/tomcat/webapps/rcaster-5-2/WEB-INF/lib/db2jdbc.zip:/opt/IBM/db2/V8.1/lib DB2_JDBC_DRIVER_PATH=/opt/IBM/db2/V8.1/java/db2java.zip Any experience with this issue? Thanks, Matt Lashley Idaho State Contrroller's Office
Re: Bulk YOU updates?
On Tue, 2003-06-10 at 10:32, Tom Duerbusch wrote: > What I'm considering is a method to put the recommended updates on a > mindisk, a standalone minidisk, that as each of the Penguins come in, I > can give everyone the same updates. Is this doable? I know I can do it > manually (no, actually I wouldn't), but can YOU still be in control of > this? Ugh. Maybe. I assume YOU just does http transactions, so if you set up a web server with the correct directory structures you might be able to make it work. Still, it'd be tricky and massively annoying. > Is there an existing HOWTO on this? What about the shops with hundeds > of Penguins? What do you do? Manually determine which patches are appropriate and put those on a shared disk. Write a script that basically does (with more error-checking, and reading in the list of packages to install from a file), and put that on the shared disk too: for i in package-foo.rpm blah.rpm bar.rpm ... ; do rpm -Uvh $i; done If you wanted you could put together a cron job to run that from each guest each night, or whatever. This all gets trickier with shared-R/O DASD, too, but that's the basic idea. Adam
Bulk YOU updates?
I'm just in the process of letting YOU go to update a Linux 8.1 test system. And I have some concerns. Monday, I couldn't get access to YOU updates. I kept timing out. I don't know if there were problems at Suse, or if some Penguin farm updated all their images at the same time and overloaded Suse. Today, while it is progressing nicely, it started to make me wonder How can I keep all the maintenance at the same level when the updating process might be spread over weeks or months (as testing goes into production)? New "recommended" updates goes on the site every few days, sometimes making other updates obsolete. What I'm considering is a method to put the recommended updates on a mindisk, a standalone minidisk, that as each of the Penguins come in, I can give everyone the same updates. Is this doable? I know I can do it manually (no, actually I wouldn't), but can YOU still be in control of this? Is there an existing HOWTO on this? What about the shops with hundeds of Penguins? What do you do? Thanks Tom Duerbusch THD Consulting
Re: Question about multiple Linux/390 instances under z/VM
When we bought our MP3000, not only Linux was free, but by committing to have the business partner install Linux, we got a heafty discount on the hardware. I think IBM knows, that once Linux gets into the mainframe, and system programmers start looking at it, it will be used. And will be used to drive additional hardware sales. Tom Duerbusch THD Consulting >>> [EMAIL PROTECTED] 06/10 10:12 AM >>> No money. "Linux is FREE!" I don't know how our marketting rep talked our management to getting an IFL and z/VM when we upgraded to our z/800. We have NO consolidation plans or any other "plan" for how to use Linux/390. Lots of talk, but no real action at present. The only reason that we are testing Oracle under Linux/390 is so that the Oracle people can "prove" that the mainframe is inferior to a "full blown, 8-way" Sun box with ? Gigs of memory (they are comparing it to a single IFL and 2 Gb of CSTOR + 1Gb of ESTOR under z/VM). -
Re: Question about multiple Linux/390 instances under z/VM
No money. "Linux is FREE!" I don't know how our marketting rep talked our management to getting an IFL and z/VM when we upgraded to our z/800. We have NO consolidation plans or any other "plan" for how to use Linux/390. Lots of talk, but no real action at present. The only reason that we are testing Oracle under Linux/390 is so that the Oracle people can "prove" that the mainframe is inferior to a "full blown, 8-way" Sun box with ? Gigs of memory (they are comparing it to a single IFL and 2 Gb of CSTOR + 1Gb of ESTOR under z/VM). -- John McKown Senior Systems Programmer UICI Insurance Center Applications & Solutions Team +1.817.255.3225 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. > -Original Message- > From: Chet Norris [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 10, 2003 10:04 AM > To: [EMAIL PROTECTED] > Subject: Re: Question about multiple Linux/390 instances under z/VM > > > And if you're going to create multiple images, do yourself a favor up > front, go ahead and install DIRMAINT. Create a CMS DASD group and a > Linux DASD group for seamless minidisk allocations. Then talk to your > IBM rep about a class overviewing z/VM basic's, Linux and cloning. > > --- Adam Thornton <[EMAIL PROTECTED]> wrote: > > On Tue, 2003-06-10 at 09:13, McKown, John wrote: > > > I have a general administration / setup question for > people who are > > running > > > multiple Linux/390 systems under z/VM. Do all your Linux instances > > use the > > > same virtual addresses for things like DASD, regardless of the > > actual device > > > address? > > > > Yes. It may vary by site, but I like to set up a scheme where, for > > example, 150 is /, 151 is swap, 152 is /usr, 153 is /opt, and 154 is > > /usr/local, where any guest may or may not have a 153 or 154 > > depending > > on what it needs to do and whether it needs its own DASD for it (I'm > > also a big fan of sharing /usr read-only). > > > > > Or do you find it "better" to make the virtual DASD address match > > > the actual device address? I'm tending towards making all > Linux/390 > > > instances use the same set of virtual DASD addresses, > which are not > > even > > > related to the "real" DASD addresses. I think this would be easier > > to > > > maintain and "clone" new instances. > > > > It is. > > > > > Do you even try to make the Linux DASD > > > addresses "look like" the actual device numbers, or do you simply > > have a > > > range of virtual DASD addresses that you assign to physical > > devices. I'm > > > using MDISK statements for Linux DASD. Basically, so far, I give > > each > > > instance (OK, I only have one so far), the entire device > OTHER THAN > > the > > > first cylinder. Sorry, but I don't trust the Linux > administrator to > > not > > > destroy the DASD label, so this protects it from any mistakes. Oh, > > I'm the > > > OS/390 and z/VM (new) sysprog. I am familar with Linux on > Intel and > > did help > > > the Linux administrator set up the initial Linux/390 > system because > > she is > > > not s390 literate. And I had actually done a SuSE s390 install at > > home under > > > Hercules/390. So I was the "expert". > > > > This is what I do. I don't generally like dedicated DASD; let VM > > manage > > it, is my usual advice. The nice thing about VM is that you *don't* > > have to care about the physical devices; pick a range you > like, and I > > tend to think you should pick a range that isn't even close to the > > real > > DASD range, so you know, just from the device address/site > > convention, > > that you're talking Linux filesystems on minidisks. > > > > Adam > > > = > Chet Norris > Marriott International,Inc. > > __ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.yahoo.com >
Re: Oracle client on VSE?
I can't help you with Oracle. We have it on our Sun systems. "They" are testing it on Linux/390. From what I understand, the preliminary report was written before the test started. What might be of interest, and I may even do some day, is to run PostgreSQL under Linux/390, then port the client code to run under OS/390 UNIX. The problem, for me, is how to write a "preprocessor" which can handle imbedded SQL and write out the appropriate "host language" statements. I'm not a compiler writer by any stretch of the imagination! -- John McKown Senior Systems Programmer UICI Insurance Center Applications & Solutions Team +1.817.255.3225 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. > -Original Message- > From: Tom Duerbusch [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 10, 2003 9:53 AM > To: [EMAIL PROTECTED] > Subject: Oracle client on VSE? > > > Sorry for the major crosspost, but between the three groups, > I will get > all the likely suspects... > > Our DB2 for VSE conversion isn't looking so good. And now we are > looking at other options. > > One option that wasn't considered when we went to DB2 was Oracle. Now > that is seems to be available for Linux/390, it is back to being a > player again. > > The problem is that I just can't see how VSE batch, VSE CICS/TS and VM > batch can use Oracle on Linux/390. We have to compile Cobol programs. > That would seem to need, at a minimum, a translator plus object decks > brough in during the LNKEDT. > > Part of my brain lock, is my experience with Oracle in the > '80s. I did > have it running on VSE/SP 2.1 (it really did run there). It > was a full > version. Problem was, was that it took 2 ICCF pseudo partitions per > Oracle Forms user. Not going to happen! Then we ran Oracle under VM. > Both cases we had full blown versions that allowed us to > compile. Just > like the full blown version of DB2 is needed to compile in VM and VSE. > > So, I don't see how the VM/VSE world can be a part of it. > > Any body running this way? > > Tom Duerbusch > THD Consulting >
Re: Question about multiple Linux/390 instances under z/VM
And if you're going to create multiple images, do yourself a favor up front, go ahead and install DIRMAINT. Create a CMS DASD group and a Linux DASD group for seamless minidisk allocations. Then talk to your IBM rep about a class overviewing z/VM basic's, Linux and cloning. --- Adam Thornton <[EMAIL PROTECTED]> wrote: > On Tue, 2003-06-10 at 09:13, McKown, John wrote: > > I have a general administration / setup question for people who are > running > > multiple Linux/390 systems under z/VM. Do all your Linux instances > use the > > same virtual addresses for things like DASD, regardless of the > actual device > > address? > > Yes. It may vary by site, but I like to set up a scheme where, for > example, 150 is /, 151 is swap, 152 is /usr, 153 is /opt, and 154 is > /usr/local, where any guest may or may not have a 153 or 154 > depending > on what it needs to do and whether it needs its own DASD for it (I'm > also a big fan of sharing /usr read-only). > > > Or do you find it "better" to make the virtual DASD address match > > the actual device address? I'm tending towards making all Linux/390 > > instances use the same set of virtual DASD addresses, which are not > even > > related to the "real" DASD addresses. I think this would be easier > to > > maintain and "clone" new instances. > > It is. > > > Do you even try to make the Linux DASD > > addresses "look like" the actual device numbers, or do you simply > have a > > range of virtual DASD addresses that you assign to physical > devices. I'm > > using MDISK statements for Linux DASD. Basically, so far, I give > each > > instance (OK, I only have one so far), the entire device OTHER THAN > the > > first cylinder. Sorry, but I don't trust the Linux administrator to > not > > destroy the DASD label, so this protects it from any mistakes. Oh, > I'm the > > OS/390 and z/VM (new) sysprog. I am familar with Linux on Intel and > did help > > the Linux administrator set up the initial Linux/390 system because > she is > > not s390 literate. And I had actually done a SuSE s390 install at > home under > > Hercules/390. So I was the "expert". > > This is what I do. I don't generally like dedicated DASD; let VM > manage > it, is my usual advice. The nice thing about VM is that you *don't* > have to care about the physical devices; pick a range you like, and I > tend to think you should pick a range that isn't even close to the > real > DASD range, so you know, just from the device address/site > convention, > that you're talking Linux filesystems on minidisks. > > Adam = Chet Norris Marriott International,Inc. __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Oracle client on VSE?
Sorry for the major crosspost, but between the three groups, I will get all the likely suspects... Our DB2 for VSE conversion isn't looking so good. And now we are looking at other options. One option that wasn't considered when we went to DB2 was Oracle. Now that is seems to be available for Linux/390, it is back to being a player again. The problem is that I just can't see how VSE batch, VSE CICS/TS and VM batch can use Oracle on Linux/390. We have to compile Cobol programs. That would seem to need, at a minimum, a translator plus object decks brough in during the LNKEDT. Part of my brain lock, is my experience with Oracle in the '80s. I did have it running on VSE/SP 2.1 (it really did run there). It was a full version. Problem was, was that it took 2 ICCF pseudo partitions per Oracle Forms user. Not going to happen! Then we ran Oracle under VM. Both cases we had full blown versions that allowed us to compile. Just like the full blown version of DB2 is needed to compile in VM and VSE. So, I don't see how the VM/VSE world can be a part of it. Any body running this way? Tom Duerbusch THD Consulting
Re: Question about multiple Linux/390 instances under z/VM
Many years ago I stared using addresses in the range 700-7FF for virtual DASD on all may guests. I have never had real DASD in this range. That way when someone says something about a DASD at some address I know if they are talking about a real address or a virtual address. I also use the same addresses for any function on all guests. Thus every VSE spool is at 703 no matter witch VSE guest it is. Every Linux swap is at 751. It makes it easy to build new guests. You don't need to be concerned about DASD address when you copy a guest because they do not change. [EMAIL PROTECTED] wrote: I have a general administration / setup question for people who are running multiple Linux/390 systems under z/VM. Do all your Linux instances use the same virtual addresses for things like DASD, regardless of the actual device address? Or do you find it "better" to make the virtual DASD address match the actual device address? I'm tending towards making all Linux/390 instances use the same set of virtual DASD addresses, which are not even related to the "real" DASD addresses. I think this would be easier to maintain and "clone" new instances. Do you even try to make the Linux DASD addresses "look like" the actual device numbers, or do you simply have a range of virtual DASD addresses that you assign to physical devices. I'm using MDISK statements for Linux DASD. Basically, so far, I give each instance (OK, I only have one so far), the entire device OTHER THAN the first cylinder. Sorry, but I don't trust the Linux administrator to not destroy the DASD label, so this protects it from any mistakes. Oh, I'm the OS/390 and z/VM (new) sysprog. I am familar with Linux on Intel and did help the Linux administrator set up the initial Linux/390 system because she is not s390 literate. And I had actually done a SuSE s390 install at home under Hercules/390. So I was the "expert". -- John McKown Senior Systems Programmer UICI Insurance Center Applications & Solutions Team +1.817.255.3225 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 email: [EMAIL PROTECTED]
Re: Question about multiple Linux/390 instances under z/VM
I always keep the virtual address different from the real address. (unless I'm running in a perferred guest system) RE: That allows me to easily move minidisks to other units without making any other changes then the "user direct" file. Also, if you have multiple minidisks defined on a real volume, which minidisk gets the real address. Note, I do use real addresses for the $alloc$ and $endpak$ ($endpak$ locates the last cylinder on a pack so diskmap can show end of pack, gapsmy modification). Yes, I do use basically the same virtual addresses for disk in each of my Linux machines. Not that Linux cares that much about addresses since Linux uses "devices" instead. But cloning is easier. Documentation is easier (150 is the root, 151 is /usr, 293 is swap, etc), and, so far, the only problems this has caused in the last 20 years (VSE and Linux guests), saved me from more problems as people that "though" they knew what they were doing, tried to make changes. When virtual = real addresses, they would have had sufficient info to really screw things up. When the virtual address didn't match anything, it stopped them and they gave me a call and stopped them from really messing things up. Tom Duerbusch THD Consulting >>> [EMAIL PROTECTED] 06/10 9:13 AM >>> I have a general administration / setup question for people who are running multiple Linux/390 systems under z/VM. Do all your Linux instances use the same virtual addresses for things like DASD, regardless of the actual device address? Or do you find it "better" to make the virtual DASD address match the actual device address? I'm tending towards making all Linux/390 instances use the same set of virtual DASD addresses, which are not even related to the "real" DASD addresses. I think this would be easier to maintain and "clone" new instances. Do you even try to make the Linux DASD addresses "look like" the actual device numbers, or do you simply have a range of virtual DASD addresses that you assign to physical devices. I'm using MDISK statements for Linux DASD. Basically, so far, I give each instance (OK, I only have one so far), the entire device OTHER THAN the first cylinder. Sorry, but I don't trust the Linux administrator to not destroy the DASD label, so this protects it from any mistakes. Oh, I'm the OS/390 and z/VM (new) sysprog. I am familar with Linux on Intel and did help the Linux administrator set up the initial Linux/390 system because she is not s390 literate. And I had actually done a SuSE s390 install at home under Hercules/390. So I was the "expert". -- John McKown Senior Systems Programmer UICI Insurance Center Applications & Solutions Team +1.817.255.3225 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited.
Re: Question about multiple Linux/390 instances under z/VM
On Tue, 2003-06-10 at 09:13, McKown, John wrote: > I have a general administration / setup question for people who are running > multiple Linux/390 systems under z/VM. Do all your Linux instances use the > same virtual addresses for things like DASD, regardless of the actual device > address? Yes. It may vary by site, but I like to set up a scheme where, for example, 150 is /, 151 is swap, 152 is /usr, 153 is /opt, and 154 is /usr/local, where any guest may or may not have a 153 or 154 depending on what it needs to do and whether it needs its own DASD for it (I'm also a big fan of sharing /usr read-only). > Or do you find it "better" to make the virtual DASD address match > the actual device address? I'm tending towards making all Linux/390 > instances use the same set of virtual DASD addresses, which are not even > related to the "real" DASD addresses. I think this would be easier to > maintain and "clone" new instances. It is. > Do you even try to make the Linux DASD > addresses "look like" the actual device numbers, or do you simply have a > range of virtual DASD addresses that you assign to physical devices. I'm > using MDISK statements for Linux DASD. Basically, so far, I give each > instance (OK, I only have one so far), the entire device OTHER THAN the > first cylinder. Sorry, but I don't trust the Linux administrator to not > destroy the DASD label, so this protects it from any mistakes. Oh, I'm the > OS/390 and z/VM (new) sysprog. I am familar with Linux on Intel and did help > the Linux administrator set up the initial Linux/390 system because she is > not s390 literate. And I had actually done a SuSE s390 install at home under > Hercules/390. So I was the "expert". This is what I do. I don't generally like dedicated DASD; let VM manage it, is my usual advice. The nice thing about VM is that you *don't* have to care about the physical devices; pick a range you like, and I tend to think you should pick a range that isn't even close to the real DASD range, so you know, just from the device address/site convention, that you're talking Linux filesystems on minidisks. Adam
Question about multiple Linux/390 instances under z/VM
I have a general administration / setup question for people who are running multiple Linux/390 systems under z/VM. Do all your Linux instances use the same virtual addresses for things like DASD, regardless of the actual device address? Or do you find it "better" to make the virtual DASD address match the actual device address? I'm tending towards making all Linux/390 instances use the same set of virtual DASD addresses, which are not even related to the "real" DASD addresses. I think this would be easier to maintain and "clone" new instances. Do you even try to make the Linux DASD addresses "look like" the actual device numbers, or do you simply have a range of virtual DASD addresses that you assign to physical devices. I'm using MDISK statements for Linux DASD. Basically, so far, I give each instance (OK, I only have one so far), the entire device OTHER THAN the first cylinder. Sorry, but I don't trust the Linux administrator to not destroy the DASD label, so this protects it from any mistakes. Oh, I'm the OS/390 and z/VM (new) sysprog. I am familar with Linux on Intel and did help the Linux administrator set up the initial Linux/390 system because she is not s390 literate. And I had actually done a SuSE s390 install at home under Hercules/390. So I was the "expert". -- John McKown Senior Systems Programmer UICI Insurance Center Applications & Solutions Team +1.817.255.3225 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited.
Re: RH 2.4.9-38 k_timer
Chet, Red Hat do not appear to have made a timer-patch verion of their kernel available. My testing of Red Hat systems with the timer patch has been with vanilla (+ patches) 2.4.19 kernel source. In practical terms, this means that you cannot run a Red Hat system with the timer patch and get support from Red Hat for that system (our advice has been that if you rebuild a kernel from the Red Hat kernel-source RPM *without* applying any patches RH will support you, but if you patch the kernel you're unsupported). The latest errata kernel for RH 7.2 on S/390 is 2.4.9-43, released early-mid May I believe. OCO modules were available from DeveloperWorks for this level shortly afterward. Cheers, Vic On Tue, 10 Jun 2003, Chet Norris wrote: > Per company demand, I must stay with RedHat. I am running the 2.4.9-38 > kernel with the qdio/qeth OCO under z/VM 4.3 and need to get the > k_timer patch. The only download I've found is for a 2.4.19 kernel on > Developerworks. > Is there a rpm available for 2.4.9-38 somewhere? > What's the latest RH s/390 release that's clean? > > = > Chet Norris > Marriott International,Inc. > > __ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.yahoo.com >
RH 2.4.9-38 k_timer
Per company demand, I must stay with RedHat. I am running the 2.4.9-38 kernel with the qdio/qeth OCO under z/VM 4.3 and need to get the k_timer patch. The only download I've found is for a 2.4.19 kernel on Developerworks. Is there a rpm available for 2.4.9-38 somewhere? What's the latest RH s/390 release that's clean? = Chet Norris Marriott International,Inc. __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Re: Error from SYSLOGD
That was the same thing I suspected, but I didn't know if there was anything to check to verify it. There must've been an error in the JAVA parms being fed or the way the application was set up. The applications person replaced the file containing the program and the problem went away, almost majically. Thanks. --- Rob van der Heij <[EMAIL PROTECTED]> wrote: > > > Could it be you "just" ran out of memory? (no swap or full swap) > > > > When that happens to me, I see my logs populated with messages > about the > > kernel clobbering random processes (sometimes innocent ones) do to > 'out of > > memory' problems. > > Reason for asking was that the program check indicates the segment > table > entry is not valid, so it looks like the program did not get virtual > memory > where it expected to get some. > > Rob = Chet Norris Marriott International,Inc. __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
A couple small kernel fixes (if anyone wants 'em)
The first is a (very simple) fix to the parsing of the auto_msck and del_auto_msck chandev verbs. When writing them to /proc/chandev, all you'd get back is an argument error. (Personally, this is one of the reasons I like open source...find a problem...fix it...no waiting!) While I have my own installkernel script and don't use the kernel install scripts, I never could understand why they have remained broken. So, I "fixed" them. Get 'em at: http://www.homerow.net/projects/zlinux/kernelfixes.htm Leland
