Re: z/OS and zLinux
Thanks for the plug John. I'll also point out that if you are using Co:Z Launcher to pipe data between Linux files/applications and z/OS that you also have the option to send the data over a raw socket rather than within the ssh connection. If you have a secure network, like hipersockets between z/OS and zLinux, then avoiding the overhead of encryption can save significant CPU... and the throughput rates of Co:Z over a raw TCP/IP socket via hipersocket scream when compared to NFS. FYI, there are some case studies and examples for z/OS Hybrid Batch here: http://dovetail.com/solutions.html I'm not exactly clear on the details of Mike's requirement can you elaborate on where the data is, where you need it, etc? It sounds like you have a db2 database on zLinux and want to export data for processing on z/OS? If so, you could do something like this: // EXEC COZPROC,ARGS=myuser@zlinux //EXPORT DD DSN=EXPORT,DISP=(NEW,PASS), // DCB=(RECFM=VB,LRECL=2052,BLKSIZE=0), // SPACE=(CYL,(20,20)) //COZCFG DD * # option to send data on clear sockets ssh-tunnel=false //STDIN DD * # This shell script runs on the target zLinux guest. # shell redirection is used to export to a pipe file # connected to a todsn process which sends the data to a DD # db2 export to (todsn DD:EXPORT) of del \ select * from mytable /* //PROC EXEC PGM=MYPROG to process data //DATA DD DSN=EXPORT,... ... But it seems more common that your DB2 database is already on z/OS, in which case you would probably want a completely different approach. Kirk Wolf Dovetailed Technologies http://dovetail.com -- 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: SAS
You may not need to port R to z/OS. You can run R or SAS (or WPS) programs in a z/OS hybrid batch job step, using the Co:Z Launcher. The R or SAS processing is offloaded to a Unix/Linux appliance (like a zBX blade or zLinux guest), but your data and output can be on z/OS. Jobs are still scheduled and controlled by z/OS, but significant hardware and software savings can be realized using a hybrid model. Here's example JCL for running R from z/OS batch: // EXEC PROC=COZPROC,ARGS='u...@linux.myco.com' //LIFEEXP DD DISP=SHR,DSN=KIRK.LIFEEXP.DATA //STDIN DD * # This shell script runs on the target Linux server, # and executes the R statistical system with an inline program. # # This example is a 2-dimensional multiple regression R --no-save EOB mypipe = pipe(fromdsn DD:LIFEEXP, open=r) life = read.table(mypipe, header=TRUE) close(mypipe) multilinearFit = lm(LifeExp~PeoplePerTV+PeoplePerDoctor,data=life) summary(multilinearFit) EOB // For more details on this, see our webinar archives for the session Using the Co:Z Launcher to Enable zEnterprise Distributed Workloads, which can be found at http://dovetail.com/webinars Co:Z is free to use, enterprise license and support agreements are also available. Kirk Wolf Dovetailed Technologies http://dovetail.com PS We're working on a white paper (maybe a webinar) on running SAS / WPS in a similar way. Send me a note offline if you would like to review a preliminary draft. On Sat, Mar 31, 2012 at 3:14 AM, David Crayford dcrayf...@gmail.com wrote: No worries. Bear in mind that WPS have a aggressive business strategy to undercut SAS on the price point, which is always welcome for customers. AFAIK, WPC are ex-IBMers from Hursley who saw a opportunity to deliver a competitive product at a much lower price. From what I can tell it's a C/C++ application which should port well to zLinux. FWIW, I tried to port R to z/OS but bailed when it required a Fortran compiler. Has Fortran been ported to zLinux or is that a moot point due to the the loosely coupled front-end - backend (optimizer) architecture of the GCC compiler tool chain? On 30/03/2012 11:16 PM, Aria Bamdad wrote: Thanks for this link. I was not aware of WPS. We will seriously take a look at this product. Although R is an excellent alternative as David Boyes suggested, it is so only from a statistical analysis point of view. When it comes to data management and manipulation, it is not really a good alternative to SAS. Perhaps the availability of WPS for Linux on System z will be a motivation for SAS to provide the same offering. Aria -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.**EDULINUX-390@VM.MARIST.EDU] On Behalf Of David Crayford Sent: Thursday, March 29, 2012 10:19 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: SAS On 30/03/2012 4:44 AM, Neale Ferguson wrote: Just curious - is there such thing SAS under Linux on z? My reading shows only x86, x86_64 and Itanium as options. WPC have a SAS clone (WPS) that runs on zLinuz. WPS is very well regarded - in fact, MXG creator Barry Merrill endorses it. http://www.teamwpc.co.uk/**products/wps/platforms/zlinuxhttp://www.teamwpc.co.uk/products/wps/platforms/zlinux Neale --**--** -- 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-390http://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-390http://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-390http://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-390http://www.marist.edu/htbin/wlvindex
Re: REXEC / RSH
You might also want to look at our (free) Co:Z Launcher tool. It uses
SSH under the covers, and allows you to not only launch shell commands
from z/OS, but the Linux process can reach back into the MVS jobstep
and access z/OS datasets via pipes.
For examples, see: http://dovetail.com/docs/coz/cookbook.html
Kirk Wolf
Dovetailed Technologies
On Fri, Oct 9, 2009 at 11:09 AM, Stewart Thomas J
stewartthom...@johndeere.com wrote:
This is how I do it - highly recommend using SSH instead of R-anything. Makes
your security auditors happy.
//SFTPPRF1 EXEC PGM=BPXBATCH,PARM=('SH ssh -o $O1 -l $L $S $CMD')
//STDOUT DD SYSOUT=(,)
//STDERR DD SYSOUT=(,)
//STDENV DD *
L=userid
S=linux.whatever.com
CMD=ls -al
O1=StrictHostKeyChecking=no
/*
For this to work, you must have OpenSSH on the mainframe side. And establish
SSH keys between Unix System Services and the Linux machine. If you Google
ssh keys you'll find lots of sites on how to do that.
Also, check out the offering from Dovetail:
http://dovetail.com/index.html
Fancier version of doing some of the same thing.
Tom Stewart
z/OS Support Services
John Deere
-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Jones,
Russell
Sent: Friday, October 09, 2009 10:34 AM
To: LINUX-390@VM.MARIST.EDU
Subject: REXEC / RSH
Does anyone have any experience running remote linux commands from MVS batch?
I have found that MVS TSO has REXEC and RSH, but I am been unsuccessful
executing a remote command on linux. I can use rexec/rsh from one linux
system to another, but not from MVS.
Any help on using these commands, or other suggestions on how to execute
remote commands will be much appreciated.
Russell Jones
ANPAC
--
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 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 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
Re: Universal Binaries on Linux?
LSB is much more than standard file system layouts. It allows you to build a common binary package (for a given processory architecture) that can be installed on any LSB-compliant distro (with that processor architecture). This is accomplished by building and linking your binary with import libraries from the LSB SDK, and commonly building an LSB RPM that only depends on the LSB package in an LSB-compliant distro. So, for example, we distribute a product and make available four different binary LSB 3.0 RPM packages: s390x for 64-bit SUSE and RH i486 for Intel 32 bit LSB compatible distos, including Debian based ones which can install via alien PPC32 and PPC64 for Power Linux distros (RH or SUSE) See: http://dovetail.com/downloads/coz/index.html (Under Target System Toolkits) More info on porting an app to LSB can be found here: http://ldn.linuxfoundation.org/lsb/porting-lsb-demo So, LSB is really orthogonal to the OP reference to common binaries (aka FAT binaries), but in the context of Linux a FAT binary is not much use without what LSB brings due to the library and filesystem differences between different distros. IIMO, FAT binaries are easier to implement than what LSB does, even though I'm not sure that FAT binaries are a good solution. Makes more sense to me that a package manager / repository could just direct installation of the right binary for the right processor architecture. Kirk Wolf Dovetailed Technologies http://dovetail.com On Sun, Oct 25, 2009 at 6:10 PM, John Campbell soup...@gmail.com wrote: LSB has, to my limited understanding, NOTHING to do with Universal Binaries. LSB, as I understand it, lays down a standard filesystem tree for system configuration files and other basic services. Note that LSB means that the subdirectories under /etc will be reasonably standard and any deviations will only be seen when the hardware requires additional files. I suspect that LSB also influences the structure of the /dev tree, as it does the /bin, /lib, /usr and /var file trees. It has been a long time since the days of the a.out header (as I first saw in the original SLS distribution), COFF and the final decision to adopt the ELF format (making the code and static data segments of a binary program block loadable by the paging subsystem). I suspect that the Universal Binary of MacOS X duplicates static data to handling the differing byte genders, but, really, the UB capability for Apple isn't so bad since there are only two CPU architectures to deal with. For a Linux distribution each binary would need to hold a BUNCH of targets. H... x86/32bit x86/64bit Itanium ppc/32bit ppc/64bit sparc/32bit sparc/64bit s390/31bit z/64bit . . . Somehow I do not see a Universal Binary file as having a lot of value in a system that has so many targets though having a Universal Install HD-DVD *may* be the way to go. - soup On Sun, Oct 25, 2009 at 6:47 PM, Kirk Wolf k...@dovetail.com wrote: Does such an effort distract from LSB? To that point, what do listers think about LSB? Kirk Wolf Dovetailed Technologies http://dovetail.com PS We have more than a casual interest in the future of LSB, since we currently offer products that ship in LSB form. Its not clear the the industry has or ever will fully embrace it. If not LSB, what chance does something like this have? On Fri, Oct 23, 2009 at 9:21 AM, McKown, John john.mck...@healthmarkets.com wrote: Interesting article, to me. Might be nice to have a single executable that runs on Intel/32 Intel/64, z/31, z/64, and p. Apparently the data only portion would not be duplicated, only the executable code portion. Not likely to happen, but interesting (again, at least to me). http://www.phoronix.com/scan.php?page=news_itempx=NzYyNQ http://icculus.org/fatelf/ John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: Universal Binaries on Linux?
Does such an effort distract from LSB? To that point, what do listers think about LSB? Kirk Wolf Dovetailed Technologies http://dovetail.com PS We have more than a casual interest in the future of LSB, since we currently offer products that ship in LSB form. Its not clear the the industry has or ever will fully embrace it. If not LSB, what chance does something like this have? On Fri, Oct 23, 2009 at 9:21 AM, McKown, John john.mck...@healthmarkets.com wrote: Interesting article, to me. Might be nice to have a single executable that runs on Intel/32 Intel/64, z/31, z/64, and p. Apparently the data only portion would not be duplicated, only the executable code portion. Not likely to happen, but interesting (again, at least to me). http://www.phoronix.com/scan.php?page=news_itempx=NzYyNQ http://icculus.org/fatelf/ John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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 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
Re: JBOSS Performance Issue
JInsight is a good tool, but you may find that is not ideal for your situation. There are basically three kinds of Java profiling techniques: - Code instrumentation: the profiler hooks class loading and adds intrumentation byte code to all or selected methods. A nice free pure-java tool that does this is http://jiprof.sourceforge.net/ This works well on z/OS, so it probably works fine on z Linux as well. - Tracing: the profiler gets an event when *every* method is entered and exited. This is the way that JInsight works (unless something has changed recently) - Sampling: The profiler periodically examines the thread stack(s) and builds a statistical profile A great profiler that does this with very low overhead is YourKit, but I don't think that it is available on z Linux. All three techniques are useful depending on the kind of problem, but I find a sampling profiler to be the best for most situations. Code instrumentation can work well if you designate selected Java packages to instrument, which is a much lower overhead way to find out what is slow in a large application. For example: just instrument the application classes and not framework or SDK classes and you can find out what parts of your code are performing slowly, without nearly as much profiling overhead. Tracing is best when you want very detailed data for a small amount of code or period of time. Kirk Wolf Dovetailed Technologies http://dovetail.com -- 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
Re: Sun JDK on Linux on Z
I will defer to your judgment that having any kind of Sun JRE is better than an IBM JRE, from a selling point of view. From a technical perspective, we agree that eventually you will need a high-performance JRE. I see a couple of paths: - Port/write a JIT for the Sun JRE for z architecture. A good JIT, especially for z, is really a very sophisticated real-time optimizing compiler; a rather large effort. BTW: will you be using OpenJDK? If so, are you sure that the customer applications will work? Most of the portability issues have to do with using non-API classes, which might not be in OpenJDK either. But if this were done, it would be easy to port it to Linux, which would be great. If you could pull this off so that the performance were comparable to the IBM JVM, there is a team of IBM JIT developers that would certainly get excited. This kind of competition would be great. - (Assuming that IBM ported their JVM from Linux z to Solaris z) Why not explore the possibility of running the Sun OpenJDK Java libraries with the IBM JVM? I'm not sure how difficult this would be, but it seems possible in theory. Alternatively, IBM somehow could add non-public Sun classes to their JDK so that compatibility issues are relieved. Again, customers whose applications only support the Sun JRE are saying that they don't conform to the public API. They will probably get whacked when they try to migrate to a new version of Java. These are likely the same goof-balls that complain how non-portable Java is, and how slow it is since it is interpreted. Do these people really think that porting their Solaris workloads from Sparc or Intel to z will be easy, so long as they don't have to support a different JRE? Kirk Wolf Dovetailed Technologies On Thu, Apr 16, 2009 at 7:25 PM, David Boyes dbo...@sinenomine.net wrote: On 4/16/09 5:38 PM, Kirk Wolf k...@dovetail.com wrote: That's fine; but without a JIT, migrating common Java workloads to Solaris z is a non-starter. For the z-architecture, it needs to be a rather sophisticated JIT. Give us a little time, OK? Neale's only had a week or so to get this far. 8-) It's a known requirement. Baby steps...it's easier to sell eating the performance hit for now than arguing about converting some application to a different JDK. The next two steps are a LOT harder, and Kate is rationing pixie dust this month..8-) I agree with your points on JDK compatibility being a common issue, on all platforms. Most all of the problems end up being that the application code incorrectly uses Sun internal classes. Sun should have fixed this long ago by somehow preventing using of classes that aren't part of the Java API. Not my battle. I'm just tired of hearing IBM Java isn't what our applications people need. -- db -- 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 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
Re: Sun JDK on Linux on Z
On Thu, Apr 16, 2009 at 10:21 AM, David Boyes dbo...@sinenomine.net wrote: Also, this is more about non-vendor code; most of the ISVs do support the IBM code, but customer code is seldom (if ever) tested against it. They support the Sun JDK, and insist on it. That's fine; but without a JIT, migrating common Java workloads to Solaris z is a non-starter. For the z-architecture, it needs to be a rather sophisticated JIT. I agree with your points on JDK compatibility being a common issue, on all platforms. Most all of the problems end up being that the application code incorrectly uses Sun internal classes. Sun should have fixed this long ago by somehow preventing using of classes that aren't part of the Java API. -- 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
Re: Sun JDK on Linux on Z
David, Is Java without a JIT compiler really of much practical use? IBM has made a huge investment in JIT technology for z architecture (z/OS and Linux) in their SDK. It would be much better IMO if IBM offered a Solaris z port of their SDK. After all, if IBM isn't interested in Solaris z ports of their products, who will be? Kirk Wolf Dovetailed Technologies On Wed, Apr 15, 2009 at 2:02 PM, David Boyes dbo...@sinenomine.net wrote: java -version java version 1.6.0_0 OpenJDK Runtime Environment (IcedTea6 1.4.1) (build 1.6.0_0-b14) OpenJDK 64-Bit Core VM (build 14.0-b08, interpreted mode) -- System Properties--- java.runtime.name : OpenJDK Runtime Environment java.vm.version : 14.0-b08 ant.library.dir : /usr/share/ant/lib java.vm.vendor : Sun Microsystems Inc. java.vendor.url : http://java.sun.com/ path.separator : :java.vm.name : OpenJDK 64-Bit Core VMfile.encoding.pkg : sun.iouser.country : USsun.java.launcher : SUN_STANDARD sun.os.patch.level : unknown java.vm.specification.name : Java Virtual Machine Specification java.runtime.version : 1.6.0_0-b14 java.awt.graphicsenv : sun.awt.X11GraphicsEnvironment os.arch : s390x line.separator :java.vm.specification.vendor : Sun Microsystems Inc.os.name : Linux Contact me offlist if you have some interest in obtaining a copy. -- 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 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
Re: Keyboard
The PA-1 key on TN3270 usually has that semantic. Check the doc for your TN3270 emulator to see how that key is mapped. On Mon, Apr 6, 2009 at 4:34 PM, Ron Wells rwe...@agfinance.com wrote: 3270 keyboard--trying to setup a break seq---ctl+c I think for break?? -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- 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 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
Re: Solaris v. Linux
This may be a well-worn topic here, and if so I apologize... What about GPL-licensed code using proprietary (closed) instructions and hipervisor features (DIAG, etc)? Aren't micro/millicode and zVM hipervisor vectors the new OCO with respect to Linux and Solaris on z? I can guess what RMS would say, but IMO kernel modules that use closed instructions should be considered non-free. This would have nasty implications. Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, Mar 31, 2009 at 9:24 PM, John Summerfield deb...@herakles.homelinux.org wrote: However, sometimes licence conflicts determine what can be done. GPL-licence code cannot be mixed with code released under other licences - any that keep source code secret for starters. It is not open to Oracle to incorporate code from bash into Oracle. It's not permissible to alter the Linux kernel and release the result without source code, and companies have been sued sucessfully for this violation. Ask Dlink. Its also possible for a licence to prohibit release of source code. MS owns large parts of OS/2. -- Cheers John -- spambait 1...@coco.merseine.nu z1...@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.htmlhttp://www.catb.org/%7Eesr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- 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 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
Re: Stopping java based applications
Re: how to cause a Java app to shutdown IF you have the authority to send it a signal: Java JVMs on *nix generally will respond to SIGINT (2) or SIGTERM(15) by exiting normally. An application an register a shutdownhook and run some code to clean up if necessary. Here's a link: http://www.ibm.com/developerworks/java/jdk/linux/50/sdkandruntimeguide.lnx.html#signals Kirk Wolf Dovetailed Technologies On Tue, Mar 31, 2009 at 8:50 AM, Scott Rohling scott.rohl...@gmail.comwrote: IMO - the java app should provide a way to tell it to exit gracefully - and the stop script would exercise that. Scott On Tue, Mar 31, 2009 at 7:43 AM, CHAPLIN, JAMES (CTR) james.chap...@associates.dhs.gov wrote: Our programmers have been creating java based applications that they start and stop using simple scripts. The start script call java to start the program; however the stop script issues a simple kill command against the PID. Our problem if User A start the program, only User A can kill it (except for root). We want anyone in the group level to be able to also issue the kill command (in the script). Is there a way to allow users in a group to kill each other's started processes. Being new to the zLinux and Java worlds, is it standard to issue a 'kill -9 pid to terminate a java program? Is there a better way and how does issuing a kill de-allocate memory and other issues? James Chaplin Systems Programmer, MVS, zVM zLinux Base Technologies, Inc Supporting the zSeries Platform Team -- 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 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 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
Re: Fw: SFTP Authentication Question
FWIW, here's a little flash video that demonstrates how to setup SSH keys so that a z/OS SSH (or SFTP) client can log into a remote system without a password: http://dovetail.com/demos/coz/demo_keys.html -- 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
Re: different take on Java 6 question
AFAIK, the IBM Java SDK is the only one that has a JIT that targets the z instruction set. Its the same dynamic compilation technology that is used by the z/OS Java SDK. (it compiles byte codes into native / optimized machine instructions at run time) If you poke around the OpenJDK docs, you'll see that only a byte-code interpreter is available for s390. Running Java without a JIT compiler is *not* a good idea :-) Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Nov 21, 2008 at 2:03 PM, David Goodenough [EMAIL PROTECTED] wrote: Have you tried OpenJDK. I understand the Debian build it for the Z series although I am not sure wether they build for 32 or 64 bit. However it is open source so if there are problems you can always fix them. David -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: ZFS or LVM2 on Debian?
A clarification on the open source status of Co:Z - The Co:Z binaries for z/OS are free under a binary-only Apache 2 license (no souce). - The toolkit for distributed systems, such as Linux, *is* open source (GPL V2). There are LSB packages available for Linux - IA32 and z/31, z/64 bit, or you can build from source with a standard make/make install. We would welcome any opportunities to get the package included in any Linux distribution. I would recommend using the following DCB for redirecting tar output to optimize the I/O, since todsn uses QSAM to write records, and the following would perform better: //TAROUT DD DSN=TAR.OUT, // RECFM=U,BLKSIZE=27998,DSORG=PS, // UNIT=(SYSDA,10), // SPACE=(CYL,(200,10)) Also, I would suggest that if you are looking at doing high-volume data transfers over a secure network between z/OS and Linux on z that you might want to exploit a feature in Co:Z that allows you to use SSH for the login connection but to pipe the data over separate clear-channel sockets rather than tunneling back through the SSH connection, which is the default. This avoids the CPU overhead of SSH encryption and allows you to fully exploit something like hypersockets with minimal overhead and maximum speed. Of course, backups are only one thing that you could schedule from z/OS... you might also do things like run a job to extract data from DB2 and pipe it into a program that loads it into an Oracle database on Linux (or vice versa). The advantage of using Co:Z and pipes is that processing can be concurrent with the data transfer, rather than one-at-a-time if you were to use a traditional file-transfer approach. There are some other examples of using Co:Z in the most recent issue of the ZJournal magazine: Extending z/OS with Linux: A Multi-protocol File Exchange Gateway. Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Oct 8, 2008 at 11:17 AM, John McKown [EMAIL PROTECTED] wrote: I didn't see the original message. Apparently the OP wants to backup RHEL/Intel files on z/OS. I will mention a very nice product which is free, but not open source. It is Co:Z from Dovetailed Technologies. http://www.dovetail.com What this can do is establish an SSH session from z/OS to any Linux box which is running sshd. On the Linux box, there are some programs installed. Then, on the z/OS side of the world, you can run a jobstep similar to: //BACKUP EXEC PROC=COZPROC, // ARGS='[EMAIL PROTECTED]' //STDIN DD * cd /sub/directory/to/back/up tar cjv * |\ todsn -b '//DD:TAROUT' /* //TAROUT DD DSN=output.file, // RECFM=FB,LRECL=1,BLKSIZE=0,DSORG=PS, // UNIT=(SYSDA,10), // SPACE=(CYL,(200,10)) // The above puts the output of the tar command on the file output.file on the z/OS system. Unfortunately, as shown, it requires that the RACF id on the z/OS system have a UNIX UID and home directory which contains ~/.ssh/id_rsa file and that file have a null passphrase which is appropriate to ssh onto the given Linux box with the given Linux ID. Another possibility is that the todsn command on the Linux box could be used to output to a z/OS dataset without the use of a batch job. This is more complicated, but I think would look something like: tar cj * | todsn -b -ssh [EMAIL PROTECTED] //'EXISTING.DSN' This would overwrite 'EXISTING.DSN'. This program can also create a new z/OS dataset, but the command would be long and involved to specify the DCB and SPACE characteristics. Just thought that I'd mention this. I don't know if anybody is interested or not. -- Q: What do theoretical physicists drink beer from? A: Ein Stein. Maranatha! John McKown -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Sharing data between z/OS and Linux on z/Series
Scott, NFS is of course one option for sharing file systems, but its security model and performance may not meet your requirements. MVSDASD has no security model - and doesn't even support the necessary serialization to be considered safe IMO. It would be nice if z/OS zFS filesystems could be shared with Linux on z, but don't hold your breath. Even so, that wouldn't address sharing of MVS datasets. While not a file sharing technology per se, our free Co:Z toolkit allows processes on z/OS to exchange data with processes on Linux on z It uses SSH to setup processes and connections between z/OS and Linux, but you can also configure it to use clear-channel socket connections for data transfer (taking advantage of hipersockets). For more information, see: http://dovetail.com/coz Kirk Wolf Dovetailed Technologies On Fri, Sep 26, 2008 at 2:36 PM, Scott Rohling [EMAIL PROTECTED]wrote: Thanks David and Dave! I've passed this on .. appreciate the response .. Scott Rohling On Fri, Sep 26, 2008 at 12:20 PM, Dave Jones [EMAIL PROTECTED] wrote: Scott, there's an open source project called MVSDASD that provides a read only Linux device driver to flat files stored on MVS DASD; e.g., sequential z/OS datasets. It even has a page comparing it to NFS. It's web site is located here: http://www.mvsdasd.org/ Good luck. Scott Rohling wrote: I know this topic has been done before - but you never know if something new has come to pass... The subject says it all -- We know NFS works -- but we're looking for solutions outside of NFS. A customer recently asked me about 'zFS' (which appears to come from an older reference at the IBM Haifa website).. Outside of network mounts -- is anyone aware of something that allows either z/OS to read Linux filesystems directly, or vice-a-versa? (ECKD or FCP/SAN) Thanks for any suggestions! Scott Rohling -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: z/Linux access to z/OS DASD
Along with security (which is a huge problem) a production quality native file-system driver would have to deal with: - serialization (GRS/XCF enqueues with z/OS) - support for z/OS catalogs - support for dealing with variable length binary records. - support for datasets with extents that span volumes - VSAM, ISAM, etc. To satisfy everyone, you would probably need a big chunk of MVS implemented in Linux (or VM?) On the topic of security - does anyone use NFS to share sensitive datasets with Linux and have issues with delegating user-level security control to Linux? Once the filesystem is mounted, you are trusting Linux to control access to it. Kirk Wolf On Mon, May 19, 2008 at 12:38 PM, Thomas Kern [EMAIL PROTECTED] wrote: I am pretty sure it would take at least a new driver and probably a new filesystem, akin to CMSFS for a start. But then you get into the area of security. Without z/OS doing the file access, your z/OS security package cannot validate any of the linux i/o to each file. Any process on linux might be able to read all of your z/OS data. If you want to do this in a controlled linux just for the purpose of coping z/OS data to linux data and setting the linux uid/gid and permissions properly for each data file, then you might get by with something as simple as the CMSFS. I would look at two alternatives. One, push the data from z/OS to linux with something like Co:Z and then leave all processing of that data in linux, DON'T bring it back to z/OS all the time. Two, consider building/buying a custom client/server application, with linux as the client, requesting some data from z/OS and the server in z/OS validating each request against your security pacakge before delivering the data. But again, those alternatives are meant to stay within the scope of a z/OS security package. If you don't need to bother with the security package in order to quickly move to linux, then move quickly to linux bypassing as much security as you can and then stop using the z/OS copy of the data. /Tom Kern -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Interesing, to me, Web-based book on AUTOTOOLS et al.
Correct me if I'm wrong - but there aren't modern versions of these ported to z/OS. A pity since you really need them to bootstrap the porting of newer versions of many of the other open source tools. Kirk Wolf Dovetailed Technologies On Thu, May 8, 2008 at 3:05 PM, McKown, John [EMAIL PROTECTED] wrote: http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_ automake_libtool I haven't read all of the chapters yet. There are 11 of them. But I am finding it interesting about how to use GNU autotools to create a semi-platform independant makefile. Used quite a lot in Linux, but I think it should work on z/OS UNIX as well. I'd play around with it on z/OS except for the fact that a penny-pinching ex-manager killed my C compiler. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: USS-Linux
As mentioned earlier, you can't use shared mem or semaphores between z/OS and Linux on z. Our free Co:Z toolkit allows you to simplify the use of pipes between z/OS and Linux - including access to z/OS datasets. See: http://dovetail.com/coz for more details Kirk Wolf Dovetailed Technologies -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Workload move from z/OS to z/Linux
Frank, Co:Z depends on ssh (included in Ported Tools for z/OS) and is written in C++ with dependence on the LE and POSIX apis, so it is probably a big job port to VSE. Kirk Wolf Dovetailed Technologies On Feb 4, 2008 1:48 PM, Frank Swarbrick [EMAIL PROTECTED] wrote: Where's the VSE version? :-) Frank -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Workload move from z/OS to z/Linux
Dave, Thanks for mentioning Co:Z, which is now a free offering. We built it with exactly this kind of thing in mind - we have 31 and 64 bit LSB rpm packages for Linux on z ready to go. With Co:Z, you can also access MVS datasets as pipes on Linux. So, for the case that you mentioned - PGP encryption, here's example JCL: //COZCB3 JOB (),'COZ' //STEP1 EXEC PROC=COZPROC, //ARGS='[EMAIL PROTECTED]' //STDIN DD * fromdsn -l rdw -k //DD:INPUT \ | gpg -r key-1 --batch --output=- --encrypt=- \ | todsn -b //DD:OUTPUT /* //INPUT DD DISP=SHR,DSN=KIRK.CLEARTEXT.DATA //OUTPUT DD DSN=KIRK.ENCRYPT,DISP=(NEW,PASS), // SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=U,BLKSIZE=4096) For more explanation of this example, see: http://dovetail.com/docs/coz/cookbook.html#4_3 Co:Z can be configured to either tunnel data through SSH, or to use direct sockets. In a z environment, this means that you can use ssh for authentication and unencrypted hipersockets to for data - which SCREAMS. There is *not* an easier or faster way to integrate Linux and z/OS processes and data: - Why not use z/OS as a batch scheduler for running Linux jobs? - Running Oracle on Linux and need to export/import data from z/OS datasets? - Its easy, and all managed and visible from your z/OS batch envionment. Kirk Wolf Dovetailed Technologies On Jan 30, 2008 9:13 AM, Dave Jones [EMAIL PROTECTED] wrote: And things like data encryption (PGP, etc.) and data compression (GZIP, BZIP, etc.) make good candidates as well, (and you can avoid the license charges for PKZIUP on z/OS. :-) You might also want to check out the new Co:Z Co-processing Toolkit as well. It allows a z/OS batch job to remotely launch a process on a distributed system, redirecting input and output from the remote process to traditional z/OS datasets or spool files. More info here: http://dovetail.com/products/coz.html -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Co:Z Co-Processing Toolkit is now FREE
Dovetailed Technologies announces today that the Co:Z Co-Processing Toolkit for z/OS is now free for use under the terms of the Apache V2 license. Client/target system RPMs for Linux on System z (31 and 64 bit) are also available. The Co:Z Co-Processing Toolkit allows a z/OS batch job to remotely launch a process on a distributed system, redirecting input and output from the remote process to traditional z/OS datasets or spool files. Remote processes are securely launched using proven SSH (secure shell) technology to the target platform, which may be Linux, Windows, or other Unix/Posix platforms. The remote/target process can use Dataset Pipes commands or APIs to reach back into the Co:Z Launcher jobstep and access MVS datasets - by name or DD reference. These APIs allow for very flexible control over the conversion of record-oriented z/OS datasets to or from byte-stream pipes usable by the target application. The Co:Z toolkit for z/OS also includes the popular DtlSpawn and Dataset Pipes tools, packaged in a single installer. Pre-built binary and source packages are available for a variety of distributed platforms, including Windows, Linux/x86, Linux for System z, and Unix. Free support is available on our support forum. Commercial support contracts are also available. See: http://dovetail.com/products/coz.html - for more information. http://dovetail.com/docs/coz/cookbook.html - for sample jobs http://dovetail.com/downloads/coz/index.html - for downloads -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: EBCDIC to ASCII conversion;
Here's a link to the z/OS OpenSSH manual: http://www.ibm.com/servers/eserver/zseries/zos/unix/pdf/docs/fotza104.pdf z/OS's port has the following changes: 1) scp client assumes text and converts from ASCII to EBCDIC in both directions. - I don't believe that it handles line-end conversions (Windows). - scp server mode does the same 2) sftp defaults to binary, but z/OS adds an ascii subcommand to the client (only) which does conversion as with scp. Therefore, you can't use sftp-server and do conversion. Note that some implementions' scp client actually use sftp's underlying protocol, but often have an option to fallback. Kirk Wolf Dovetailed Technologies P.S. In reference to another Q on this post, its quite easy to use our Co:Z toolkit to schedule jobs and transfer files, and even kick off processing on the target Linux system. You can even pipe the MVS data directly into the processing program, allowing for overlap of file transfer and processing. Here's an example: http://dovetail.com/docs/coz/cookbook.html#4_5 Richard Troth wrote: SCP to/from MVS systems performs translation. I do not believe it munges with line-end characters. (That is, if there is a CR, it stays.) This turns out to be a good thing for those of us who kick around a lot of source and scripts and HTML between z/OS and Unix and Linux systems. Dunno about SFTP. -- R; -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Coping a MVS file to Linux
For more flexibility, security, and ease of use than what z/OS NFS offers, you might consider the Co:Z Toolkit, which uses SSH as its underlying network protocol. Example: //COZCB2 JOB (),'COZ' //STEP1 EXEC PROC=COZPROC, //ARGS='[EMAIL PROTECTED]' //STDIN DD * # Any commands here run in a shell on the linux box fromdsn '//mvs1.my.data' /u/id/my.file // In this simple example, the fromdsn command reaches back into z/OS over the secure SSH connection established by the Co:Z batch program and converts the MVS dataset to a stream that is written to stdout. For more information, see: http://dovetail.com/products/coz.html Also, if the process is initiated from the Linux side, you can use our free Dataset Pipes product, which can read and write MVS datasets over an SSH connection: http://dovetail.com/products/dspipes.html http://dovetail.com/docs/dspipes/cookbook.html#3_14 (an example) Kirk Wolf Dovetailed Technologies Britz, Anton - CO 7th wrote: Hi, My Developers are asking me the following : I am having a problem figuring out the JCL to do the copy from z/os to the 'linux' file on the shared partition. Do you recall any details? The MVS job should like much like the z/os I think? The information contained in this email may be privileged, confidential or otherwise protected from disclosure. All persons are advised that they may face penalties under state and federal law for sharing this information with unauthorized individuals. If you received this email in error, please reply to the sender that you have received this information in error. Also, please delete this email after replying to the sender. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: OpenSSH and 'HostBased' Authentication
We have put together a web-cam how-to on setting up ssh keys between z/OS and Linux. The webcam is in the z/OS -- linux direction, but the same applies in the other direction. http://dovetail.com/docs/coz/demo_keys.html Additionally, the Co:Z and Dataset Pipes product installation documentation on our site has additional information on setting up z/OS - Linux ssh keys. Kirk Wolf Dovetailed Technologies Peter Rothman wrote: Our shop has this situation: User A has a userid on Linux and a userid on MVS - they are not named the same. EG. On linux it is prothman and on MVS it is pm1pkr. We have a process/application that requires an OpenSSH setup on BOTH systems to allow ssh traffic between the 2 systems/users without having to specify a password. On linux prothman must be able to ssh -l pm1pr mvs-sys and on MVS pm1pkr must be able to ssh -l prothman linux-sys We are also are looking into having a 'super user' on MVS that is allowed to ssh into any linux userid without having to present a password. I have this scenario working in a linux-linux combination but cannot get it to work in the MVS-Linux environment. I have googled the subject and have some documentation but cannot get this to work. Can anyone point me to some 'good' documentation. Thanks -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
I would like to thank everyone for your thoughtful responses to this post. Although the application will target any linux (or Windoze) system, we hope for strong z linux usage. The information you shared will definitely help us package for z distros. Kirk Wolf Dovetailed Technologies -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
John, Ubuntu is what we run on our desktops, so I can appreciate your position. We had assumed that enlightened z Debian users would accept source tarballs for a commercial application, but we could be mistaken. I can assure you that we will make .deb binaries available for Debian on z if a customer wants it. Regards, Kirk Wolf Dovetailed Technologies John Summerfield wrote: Kirk Wolf wrote: that install and run correctly on several LSB3.0 distros (including Debian/Ubuntu via alien). Speaking for myself, I will if I must run an rpm through alien for my use, but I'd be peeved if my software vendor did that. I would, if source is provided, expect 'apt-get source' to get it. Risks I might imagine with running a debianised rpm are similar to those with running a foreign rpm on any rpm-based distro, and if there are associated install/uninstall scripts I would fully imagine them untested on my platform, if they run at all. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Best Practices for zSeries linux ISVs?
Kris Van Hees wrote:
Actually, more than small and subtle... Dependencies for the binary RPMs are
in part derived from the build environment, so creating a SuSE RPM on a RedHat
system, or the other way around, is never a good idea. It can be made to work
with the right amount of dark magic, but it isn't for the faint of heart, and
it is bound to get you into a lot of misery down the road.
Cheers,
Kris
Kris,
The application itself is quite portable and after some work complies
100% with LSB 3.0.
(http://www.freestandards.org/en/LSB)
Of course we would be testing on as many architectures and distros as
possible,
but we've had success in building LSB3.0 compatible RPMs (for arch=i486,
arch=x86_64, arch=ppc, and arch=ppc64)
that install and run correctly on several LSB3.0 distros (including
Debian/Ubuntu via alien).
We are hoping that LSB 3.0 compatible RPMs for arch=s390 and arch=s390x
will work as well.
If this is never a good idea, can you elaborate on issues that you see?
Following is a snippet from the RPM spec that is used for LSB packaging
that I believe is
designed to address the issues that you mention.The point of LSB is
to have - by architecture -
binary application compatibility across LSB compatible distros. As you
can see below,
a lsb compatible distro is required to have lsb support packages
that wash away distro-specific
dependencies.
Buildroot:/var/tmp/%{name}
Prefix:/opt/dovetail/xxx
AutoReqProv:no
# LSB dependency section
%ifarch i386 i486 i586 i686 athlon
PreReq:lsb-core-ia32 = 3.0
%endif
%ifarch ia64
PreReq:lsb-core-ia64 = 3.0
%endif
%ifarch ppc
PreReq:lsb-core-ppc32 = 3.0
%endif
%ifarch ppc64
PreReq:lsb-core-ppc64 = 3.0
%endif
%ifarch s390
PreReq:lsb-core-s390 = 3.0
%endif
%ifarch s390x
PreReq:lsb-core-s390x = 3.0
%endif
%ifarch x86_64
PreReq:lsb-core-amd64 = 3.0
%endif
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
Best Practices for zSeries linux ISVs?
We are preparing to release a new commercial application which will support zSeries linux distros, and are hoping to get some advice and/or suggestions for packaging the product for zSeries. Our current thinking is to make the following distribution formats available: 1) s390 (31 bit) architecture LSB 3.0 compatible RPM 2) s390x (64 bit) architecture LSB 3.0 compatible RPM 3) source rpm 4) source tarball These are our questions / issues: 1) RHEL 3.x is not LSB 3.0 compatible, whereas RHEL 4.2+ and SLE 9.3+ are. Would this affect a significant portion of the current zLinux installed population? Are there problems with LSB3.0 support on zSeries linux distros that we aren't aware of? 2) For non-LSB3.0 environments, we would have instructions on how to do a source RPM install or a source tarball make/make install. Even though the build is simple, will this be a issue with some z Linux customers? Based on feedback, we can really decide to ship the package formats that users seem to want/need, but we would *really* like to keep the binary packages to a small number. We would like to be able to use a single zLinux image to build binary packages. It would be *ideal* for us to just ship source packages, but our intuition is that no matter how simple the build process, some customers will only want binaries (the opposite of my preference :-) Your comments and suggestions would really be appreciated. Regards, Kirk Wolf Dovetailed Technologies, LLC -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: zLinux experience
Walter, Its hard to say with so little information. Can you provide ANY numbers on the benchmark comparisons? Kirk Walter Marguccio wrote: this has been cross-posted to the ibmmain-list we are a shop with a z890-230 with three zOS.e LPARs in Basic Sysplex. We'd be really happy to consolidate some of our applications running right now on Blades and/or pSeries on the mainframe due to reliability and scalability of the latter. Within the TryBuy agreement with IBM we got one IFL and 16 GB memory on the fly (just a microcode update), added two zLinux LPARs to be run in native and installed DB2 8.2.2 onto SuSE Enterprise 9. Well, the first results we have been having are pretty discouraging. We have been running some benchmarks in form of scripts on 4 different machines pSeries Power 3, two PPC3 @ 450 MHz; Intel-based board with two Pentium 3 @ 933 MHz; z890, 1IFL @ 1,3GHz (?) OpenPower 720, 2 PPC5 @ 1,6 GHz and all benchmarks show that our IFL is *FAR* behind the Power5 architecture (round 20.000 Eur). Somehow, too slow to be true Without not going too much in detail about what the benchmarks did, they performed operations like loading and selects over joined tables - basic database I/O tasks. Either we are doing something conceptually wrong, or we are expecting too much from the IFL and/or zLinux. Comments, remarks, recommendations, pointer to further documentation are really welcome. Regards. Walter Marguccio z/OS Systems Programmer Munich - Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
