Re: SHC bash script compiler for Linux on z
> > I accept that. does SLES supports Assembler 390 ;-) If it should be C, C it > will be. > > Thanks. > ITschak > Yes - you can use our assembler to write HLASM-style programs on s390x SLES. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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: Migrating DB2 from z/OS to Linux on z that is written in Assembler
Hi Jeff, You can use the Dignus assembler to assemble things in HLASM format and directly create a z/Linux ELF object ... and even be able to debug it (at the ASM source level) with gdb, etc... The Dignus tools write out extra debugging information for that. You would, of couse, need to change the linkages, etc... and, z/Linux is ASCII (there is an option on the Dignus assembler for that.) We also have a DB2 preprocessor that can run in the z/Linux environment, but its target is the z/OS DB2.. I'm not sure how that might operate with the z/Linux DB2. - Dave Rivers - > > Has anyone migrated a DB2 database from z/OS to Linux on z where the > application code was written in assembler? I am wondering if it is > possible to use the z/OS precompiler output with the DB2 database set up > on Linux on z? If this is not possible, what other alternatives have you > looked at? > > First question to this forum. Its been a great resource to read Q/A over > the past year. > > > Jeff Van Minde - vanmi...@us.ibm.com > zTPF Support and Solutions > (tel) 801-328-6764 > -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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: Linux Applications
Well... We like to tell people they can move their z/OS C/C++ compiles and assembly jobs to z/Linux using our tools. Moving the compiles from z/OS to z/Linux can save a lot of z/OS cycles, which can save the company $$$. So, if you have some C/C++ in the shop - that's something to really consider. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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: Micro Focus
We didn't do this because of some assembler routines used that would not translate well to Linux, and some calls to an archaic product with no Linux equivalent. You can use the Dignus assembler to port existing z/OS ASM source to z/Linux with very few changes. The Dignus assembler generates ELF objects that can be linked into a shared library that should be loadable/callable by Microfocus. This would mean you are executing the ASM programs 'natively' on the z/Arch hardware. - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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: Micro Focus
Sorry to bother everyone... but, after my post; someone went to our website and tried to submit some code for a test assemble. Unfortunately, there was a hosting issue that prevented it from working, that's been corrected, if you want to try it again :-) Thanks! - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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: C++ Cross-Compiling on zLinux for z/OS
Hi Dennis, As far as I know - we are the only people who provide such an offering. We have several customers doing their z/OS (IBM compatible) builds on z/Linux. Not only do you save cycles, our customers have found their builds run *much* faster! We have C, C++ and assembler.. (although, to be clear of course, the IBM HLASM assembler is available on z/Linux.) Give us a call, we can help you with that! - Thanks! - - Dave Rivers - Hi, My shop is interested in using zLinux to cross-compile C++ programs which will be executed on z/OS. The purpose would be to make use of cheaper IFL cycles instead of the more expensive CP cycles. Are there options for gcc or are cross-compilers available which would run on zLinux and generate object code or modules which could be executed under z/OS? Does anyone have experience w/ these alternatives, if any? Thanks in advance for your responses. Dennis Schaffer -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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: assembler and LINUX
Hello ! I am an experienced assembler programmer, BUT I do not have any clue how to write , assemble etc. in LINUX , where do I start ?? Any help is appreciated . Thanks Gunter Email ghochrei...@tsys.com You can use Systems/ASM to generate Linux programs in HLASM-style syntax. Systems/ASM generates native ELF-format files with little-to-no-change in the HLASM syntax, allowing one to port z/OS programs to z/Linux. You can also debug those programs with the GNU debugger available on z/Linux. See http://www.dignus.com/dasm/ for more info. In particular, you may want grab the documentation and see the chapter on writing Linux programs. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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: weird(?) idea for an extended symlink functionality
John, You could use a program to do this, and a named pipe. To simplify this a little... if you had a program that wanted to open the file INFILE. And, it wanted a concatenation of FILE1, FILE2 and FILE3. (And, let's say the program is named 'prog') Then - a typical UNIXy approach would be: cat FILE1 FILE2 FILE3 INFILE prog INFILE (assuming 'prog' took the name of its input file as a parm). OK - that's well and good. But - you say - that's lousy, as it keeps the file INFILE lying around and lacks a certain sense of being easily configured. And the 'cat' program doesn't really feel like PDS concatenation. One nice approach to solving this dilema in UNIX-land is with a named pipe; that is created with the 'mkfifo' command. So - you might have: mkfifo INFILE prog INFILE The file INFILE is not a file at all, but a pipe. The program, 'prog' is sitting there, waiting to read it's input from INFILE pipe. (Of course, 'prog' isn't strictly aware of this, it simply reads from the named file.) Now, we have _another_ process that starts to write the concatenation to INFILE. cat FILE1 FILE2 FILE3 INFILE That program is `cat' in this example; but it could be something much more fancy that did any number of act like a PDS concatenation tricks. There are some advantages to this approach. 1) The producer ( `cat' in our example ) can become a more complicated program. It can become a program that, for example, reads DD definitions from some configuaration file, or environment variables, and processes those in any arbitrary fashion to create the desired data. 2) The program ( `prog' in our example ) does not have to be altered in any fashion. It simply reads as it always does. 3) The producer program can now work for any program that reads input (not just the one in our example.) This division-of-labor is a fundamental design tenant in UNIX. 4) The UNIX kernel does not need to be extended/altered. 5) The same facility is available on other OSs (see http://en.wikipedia.org/wiki/Named_pipe for other examples.) Some disadvantages: 1) You've gotta know the name of the pipe. (Of course, a program has to know the DD name on z/OS and/or a file name on UNIX.) 2) You have to 'manage' the pipe (create it and delete it). Just thought I would throw out another approach, that can be tackled on your existing system. - Dave Rivers - This goes back to the person who wanted some way to emulate DD concatenatio= n of multiple datasets so that they are read as if they were one. Everybody= agrees that there isn't an easy way. Now, I don't know filesystem internal= s. But what about a new type of symlink? Normally, a symlink contains the r= eal name of the file. Sometimes a symlink will point to another symlink, an= d so on (I don't know how deep). What about a multi-symlink. That's where a= symlink points to multiple files in a specific order. When the symlink is = opened and read, each file in the symlink is opened and read in order. I kn= ow this would require some changes to open() as well, in order to make sure= that each file in the symlink chain is readable by the process. What think? Or is this just alien to the UNIX mindset? ln -s symlink realfile1 realfile2 /etc/fstab /tmp/somefile 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 -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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: RACF and Linux for z/Series
Hi Mike, It's my understanding that for RACF on z/VM you need an assembler. We have several customers using the Dignus assembler on z/VM for this very purpose, to avoid the purchase price of HLASM on z/VM. HLASM used to be a no-cost item on z/VM but now it carries a cost. So, if you decide to go the RACF on z/VM road, we can help with that component. - Dave Rivers - (Cross posted on VMESA-L and LINUX-390) Hi Folks, I have a couple of questions on using IBM's RACF as an ESM for Linux (z/Series or otherwise)? 1.There is NO version of the RACF product that runs on Linux. The RACF server must be licensed for and run on a supported platform (e.g. z/OS or z/VM). Is that correct? If z/VM, it must be 5.4 or higher? 2.If the RACF server runs on z/VM, are there any other licensed program products that are co-requisite? Is the same true for z/OS-based RACF servers? 3.Are there any licensed program products that must be installed on Linux? I see reference to IBM Tivoli Directory Server, but it's unclear if this runs on the Linux instances or the z/Series RACF hosts. -TIA -Mike -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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: OT: C language question
Hi John, See below... Well, I am trying to compile a program on Linux, so maybe... Anyway, I got (didn't write) a program off of the Internet. It is actually the output from yacc. There is a statement which does not compile: FILE *msgout=stderr; error: initializer element is not constant I'm not really very good with C. Any help? Or tell me to just go away. [grin] Also, just for fun, if I try to use bison instead of yacc to preprocess to C, I get a ton of errors. Not asking for help, just thought I'd mention it. You should look at the definition/declaration of 'stderr' and see what it is.. In the past, 'stderr' was simply a declaration like: extern FILE *stderr; however, the C99 standard allows these to be macros that expand into whatever-is-needed. In some environments, the 'stderr' macro expands into a function call. And, from the error message, I'm guessing this is a file-scoped symbol, which can't be initialized with a non-static value. Take a look at /usr/include/stdio.h and see what 'stderr' expands to to get an idea of what is going on here. But - what it comes down to is that the programmer has assumed that 'stderr' is a compile-time constant, when the C99 standard indicates it doesn't have to be; so the program is in error. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: GCC GOFF output ?
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Thomas David Rivers Sent: Wednesday, May 28, 2008 7:58 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: GCC GOFF output ? Hi John, It's not an option of GCC, but you can use the Dignus compiler sweet on z/Linux to do that. - Dave Rivers - Is that a natural sweet like honey? Or overly refined sugar? GRIN Oh, suite! -- John McKown Ha! Clearly, I wasn't paying too much attention to my words! :-) - Dave - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: GCC GOFF output ?
Anyone know if its possible to produce GOFF instead of ELF output file format from the GCC compiler in z/Linux RHEL. Is there a compiler option ? John Randles American Express made the following annotations on Wed May 28 2008 17:42:03 Hi John, It's not an option of GCC, but you can use the Dignus compiler sweet on z/Linux to do that. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Linux assemblers: A comparison of GAS and NASM
John, You know - on mainframe linux, you can use HLASM and our own assembler to make Linux objects following HLASM syntax. So - if you want it; you got it. You can also use the Tachyon assembler - but I believe they have syntax differences when assembling for mainframe linux. To learn more about the Dignus assembler - see http://www.dignus.com/dasm/ - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Mini-survey: Linux usability
Mary Anne Matyaz [EMAIL PROTECTED] wrote: An ispf like editor on linux would be great. :) MA SlickEdit has an ISPF-like mode. And - the IBM LPEX editor is ISPF-like. It's provided as part of Wdz... Unless, you meant, a free one... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: DASM Hobbyist License Renewal
Hi Dave, Uh.. Hi Jim! I'm pretty sure you didn't intend that to go to the Linux/390 mailing list :-) But - if anyone is interested - toss a note to [EMAIL PROTECTED] for more info... - Dave Rivers - It's that time of year. How much and where do I send it? Hope all is going well for you guys. Regards, --Jim-- James S. Tison Senior Software Engineer Software Group/EPS Architecture IBM Corporation -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Design and implementation of the z/VM® SCSI I/O subsystem
Hi, gang Here's an interesting article on the design and implementation of the SCSI interface code the is now in CP to support the use of SCSI disks for both Linux and z/VM itself. http://www.research.ibm.com/journal/rd/511/webb.html DJ And, if you take a look at some of the CP macros, etc... you'll find out which C implementation they use... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: getting parameters from both the command line and file(s).
Hi John! Typically/Historically in UNIX - everything up to the first argv[] without a dash is considered an argument; everything after that point is considered a file name. All arguments start with a dash. So - you have prog -arg1 -arg2 -arg3 file1 file2 file3 The getopt() facility is a good way to handle this. The getopt() man page usually has a nice example. - Dave Rivers - I'm working on a small project where I want to be able to get data from either the command arguments or from a file or from stdin. What I am thinking of is allowing the use of - by itself to mean stdin as I have seen other commands do. But I was wondering how to distinguish between a filename to read and a parameter that just happens to look like a filename. Is there a standard for this? The only thing that I have seen is with the javac compiler and the use of the @filename to specify a file which contains the names of the files to compile. Is there a better indicator character than @? Of course this means that I cannot have a parameter which starts with a @ or I must include some way to escape the @ (probably via the \ character since that seems to be another UNIX de facto standard). Thanks for your thoughts. Time to go home for the day. -- 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
Re: OpenSolaris
I thought people we working to Make ZFS available for Linux. Also - I know the initial work to get ZFS into FreeBSD is well under-way - the initial patches have recently become available. Wouldn't it be easier to port the file system to Linux than to port the OS to z-arch? - Dave Rivers - McKown, John wrote: Curiousity question. Why bother? What does OpenSolaris have that is needed? Why not one of the BSDs as well / instead? ZFS Mark -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: PL/I and C cross compilers
Hi Jon, Dave Pitts also has GCC working on MVS (USS, I think) with the Dignus runtime. Or, of course; you could license our tools... http://www.dignus.com - Dave Rivers - That's certainly interesting. I hadn't heard of PDPCLIB or the whole SPFTOOLS stuff before. The problem I have had here is lack of a C compiler on z/OS (not to mention lack of time, talent, expertise, marbles, and sundry other things). Who knows? If I get a few things whipped into shape around here, maybe I'll take a crack at putting it on. Thanks for the link! Jon snip Would this do? http://www.spftools.com/downloads/gccmvs.htm /snip -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: PL/I and C cross compilers
Hi Ken, For the 'C' part, you can use Systems/C in IBM compatibility mode to use with your existing IBM runtime. Also - Amadeus is already a customer; give us a call - I think we can handle that part for you. PL/I is another story... - Dave Rivers - Hi, We have various 'C', and PL/I programs that run on our VM systems. Are there any cross compilers that would compile 'C' and PL/I programs,and allow the object to run on VM? Thanks, Ken Vance Amadeus -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Getting to 64-bit systems *legitimately*...
Adam Thornton [EMAIL PROTECTED] wrote snip... Yeah, Hercules would let us get around that for the pure-Linux stuff (although for *that* we could also just cross-compile from Intel if we wanted). It doesn't help for the z/VM-integrated-with-Linux or for the Linux-under-z/VM cases. ...snip There are other cross-compiling options available that can help address the VM stuff... see http://www.dignus.com That is, you spoke of spiky CPU usage, due to compiling... if that's the case, we can help. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Subversion on SLES9
McKown, John [EMAIL PROTECTED] Frank, Not only can you manage your z/OS or VSE code there, but using our tools on Linux/390, you can actually build your software there and simply make the load-modules available. In fact, you could do this on an x86 Linux box, or even Windows, HPUX, Solaris, etc... - Dave Rivers - Ah, assuming the z/OS software is C/C++ or HLASM only. Most z/OS shops are still like 99.9% (SWAG) COBOL. Is there a z/Linux COBOL cross compiler which is compatable with IBM's Enterprise COBOL? -- John McKown Senior Systems Programmer Yes - that is certainly true. I was actually thinking more along the lines of HLASM. It seems a vastly significant portion of z/OS software is HLASM. COBOL will always remain very interesting... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Subversion on SLES9
Frank Swarbrick [EMAIL PROTECTED] wrote: Anyone use this to manage their z/OS or VSE source code / JCL? Frank, Not only can you manage your z/OS or VSE code there, but using our tools on Linux/390, you can actually build your software there and simply make the load-modules available. In fact, you could do this on an x86 Linux box, or even Windows, HPUX, Solaris, etc... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com --- Frank Swarbrick Senior Developer/Analyst - Mainframe Applications Development FirstBank Data Corporation - (303) 235-1403 [EMAIL PROTECTED] 09/07/06 8:06 PM If your users are willing to work with it, it's a great idea and you've already done the hard part (getting them to use the CM system in the first place). The subversion code works great in this environment, and it's typically a low-impact application, so it's a good choice for consolidation. David Boyes Sine Nomine Associates -- 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: Kernel Compilation Failure with gcc 3.4.6
Mark, GCC is complaining that cast expressions of lvalues is now gone. This was a GCCism which was in clear violation of the C standard. Newer versions of GCC are tightening up the implementation. For example, older versions of GCC would allow something similar to this: int x, y; (char)x = y; which would, on a 390/z-Arch implementation, assign to the most significant byte of the 4 bytes allocated to 'x'. You can imagine, this might be a helpful idiom, but it really is no better than this: char *xp; int x,y; xp = (char *)x; /* this is type-punning, which is */ /* only allowed for the char type */ *xp = y; This is the standard C approach to the problem, and makes it easier for an optimizer. I believe you'll have to clean-up your source to be more in-line with ANSI C. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: HLASM for zLinux
Hi Mark, We could have provided Systems/ASM (which the TPF labs has tested) for your z/TPF developers - probably with some serious savings. See http://www.dignus.com/dasm/ - Dave Rivers - From what I can tell, yes. We just licensed it that way for our z/TPF developers. Mark Post -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: ftp ascii file (pc to linux) has trailing garbage
Tom, How it shows up is a function of the program displaying it to you (either your terminal window, your editor, or the 'more' command or.. whatever.) It does sound like you have carriage returns buried in there. You might want to use the 'od' or 'hexdump' command to look at the actual bytes and see what it is. You can avoid it by ensuring the transfer is ASCII (i.e. text), and not BINARY. One most FTP clients, you specify that you want an ASCII transfer using the: type ascii command. - Dave Rivers - I've downloaded the current mksles9root.sh from the linuxvm.org website. When I ftp it from XP to Linux (using vsFTPd 1.2.1 on the Linux side), the file arrives but with a trailing character. Makes me think that it is a trailing crlf. But it shows up in Linux as an upper case M with an underline under it. I've tried various forms of parms, such as ascii and binary, and the file still arrives in Linux with this garbage character. I think the last time I did this, I didn't have enough time to look at it, so I manually deleted that character from the end of each line. How do I avoid this in the first place? Thanks Tom Duerbusch THD Consulting -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: OPM zLinux Experience
hmm... I don't mean to rain on parades, but these figures seem kinda high to me. Tiger Direct (here in Raleigh) is running a deal where you can get a 3.03ghz celeron w/256K cache, 1GIG of memory in a case (with power-supply) for $79.99. So - $2K for a PC seems awfully pricy these days. Dell sells their bottom-of-the-line server for $399.99. 100g-bit switches are usually around $59 at CompUSA. And - is there a reason not to just use one of the Intel boxes as the firewall? That would be $80 + $40 for a brand new IDE drive. I suppose my point is that you can pay whatever you want for a PC these days... of course, you get what you pay for. Even so, I would think that someone doing a big purchase could drive an awfully hard bargain out of a white-box distributor, and get much better prices than these... I just returned from an IT Financial conference where I contrasted the costs between running the 45 servers on Intel versus the z/900. I took very conservative costs for the Intel machines ($2K per server), Switches ($10K), and Firewalls ($10K) and all with no support (this $0). - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: OPM zLinux Experience
Yeah - that's what I meant by a white box distributor I mean - presumably - that's an attempt to drive the purchase price down - not up? So - if those are the retail walk-in prices, I would hope that a corporate IT dept. could do better... - Dave Rivers - But buying for a corporate IT department can be very different. Every PC in this company that I have seen, server and desktop, is a Compaq. Most I believe were purchased through a volume purchase agreement with a distributor, who had to bid for the privilege. -- 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: HLASM on zLinux install
Betsie, IBM has also announced at the TPF User's Group (in Miami I believe, it was two or three TPFUG's ago) that they would support Systems/ASM as an alternative for TPF development. Systems/ASM runs on z/Linux, Linux/390 as well as intel Linux, Windows and other platforms. See http://www.dignus.com/dasm/ - Dave Rivers - Visa is a TPF shop. zTPF is built on zLinux and needed HLASM. Betsie -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Paul Giordano Sent: Friday, June 09, 2006 11:45 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: HLASM on zLinux install My interest is piqued - what will you be using HLASM for on zLinux? (If it's not confidential information...) Paul Giordano Technical Sales Specialist - Linux zSeries e-business Solutions Technical Sales, Americas (312) 529-1347 (630) 207-9435 (cell) -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Who's been reading our list...
OK - I'm going to play serious devil's advocate here, at the risk of the ire of several people, I'm sure. But, I think we need to do something more 'direct' in terms of refuting the arguments. I've seen a couple of posts that have a sentiment of well - this guy doesn't know what he's talking about. But - I'd like to see some data and arguments to back up that sentiment. If I break down his argument, these are the points I get from it: 1 - A mainframe CPU is about as fast as a PIII 2 - SCSI is SCSI - mainframe SCSI isn't going to be any better/faster than any other SCSI. 3 - Linux is Linux, running on PC Linux is just as good as mainframe Linux. 4 - Mainframes are awfully expensive for what you get, given #1-3 above. 5 - The mainframe is very good at running it's legacy apps, but not the new ones. Now - how do we break-down the arguments and address them? Simply jumping up-and-down and saying nyaa-nyaa - this guy is wrong plays directly into his these guys are a bunch of clueless zealots who need to be consigned to the back corner for there mutual back-patting session idea. I suggest we don't fall into that trap. If you have some real data/experience to offer, please make it known. If not, then we have a problem. I think we could come up with an argument that says well, yes - we did have a PC farm of Linux machines; we consolidated all of that quite successfully on a mainframe (because of #2 and #3 above) and had a tremendous cost savings. Or - something like yes - the mainframe I/O did, in fact, run faster than the PC for my DB2 database. Or - something like using the advanced backup facilities on my SHARK, I was able to completely eliminate scheduled downtime for backups. Or - something like using hipersockets allowed me to get to the z/OS database (where all of the PCs are trying to get to anyway) and change my average web response time from M to N, an X% improvement. Please understand, I'm not necessarily in agreement with this fellow, but I'd sure like to have a reasoned response. If he doesn't have a clue, then demonstrate it. Let's beat this sentiment back with rationality. - Thanks - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: DB2 Backup into Samba Filesystem
Jose Raul Baron [EMAIL PROTECTED] wrote: Hi group, I am currently trying to backup a db into a smbfs via the command: db2 backup db mydb to /mnt/smb_disk compress but I have the following error: SQL2025N An I/O error 4 occurred on media /mnt/smb_disk/LNXE89.0.db2inst1.NODE.CATN.20060516182813.0. Could that be errno #4 - which is EINTR? /* Interrupted system call */ EINTR can happen for a write() function according to the write() man page: EINTR The call was interrupted by a signal before any data was written. Perhaps the DB2 people could better explain the message and tell you what the 4 means? You may want to try and look up SQL2025N. From the IBM manual: == SQL2025N An I/O error code occurred on media dir/devices. Cause: An I/O error occurred while accessing a file on the specified media. The utility stops processing. Action: Record the error return code. Determine whether the I/O error can be corrected. == It doesn't seem to tell you what the code could be. Also, I believe you can type: SQL2025N at the DB2 CLP prompt to get a description. Hope that helps. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Wine on z/Linux
I thought Wine also provided something called Winelib that would emulate a lot of the Windows API on the non-windows system. But - of course, the API is part of the runtime, not a function of the compiler. - Dave Rivers - See http://www.dignus.com. That's a compiler that runs on Windows and produces Z object code (even Linux/390 and/or z/Linux code.) We also support many of the Microsoft extensions, especially in the Systems/C++ compiler. And the Windows API? Years ago, I wrote an OS/2 GUI front-end using Visual Age C++ and the OS/2 (including PM) APIs. Could I write such a thing for Windows, and then compile it for Z-Windows? -- Cheers John -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Wine on z/Linux
John Summerfield [EMAIL PROTECTED] wrote: provied first you acquire a compiler that converts Windows source code to Z object code. See http://www.dignus.com. That's a compiler that runs on Windows and produces Z object code (even Linux/390 and/or z/Linux code.) We also support many of the Microsoft extensions, especially in the Systems/C++ compiler. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Cross-compilation on z/Linux = target z/OS.
Hi Ranga, YES! See http://www.dignus.com. We offer cross-compilers for z/OS; hosted on many different platforms, including x86, 390 and z/Linux. It's very reasonably priced on Linux platforms. - Dave Rivers - Is it possible to compile C programs on z/linux to run under z/OS? Has anyone done such cross-compilation? My employer would not consider buying C compiler on z/OS :( -- __ Ranga Nathan Work: 714-442-7591 -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Cross-compilation on z/Linux = target z/OS.
Hello everyone! Yes, we do have a hobbyist license, for all of our products. To avoid too much time here, I'll just direct everyone to send inquiries to [EMAIL PROTECTED] you'll the entire scoop. - Thanks! - - Dave Rivers - Hobbyist license? Is there info or some discussion about this somewhere? McKown, John wrote: -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Ranga Nathan Sent: Friday, February 03, 2006 10:34 AM To: LINUX-390@VM.MARIST.EDU Subject: Cross-compilation on z/Linux = target z/OS. Is it possible to compile C programs on z/linux to run under z/OS? Has anyone done such cross-compilation? My employer would not consider buying C compiler on z/OS :( -- __ Ranga Nathan Work: 714-442-7591 Yes. Dignus has such a beastie. Works well. I actually had their C cross-compiler and HLASM cross-assembler on my Linux/Intel system at home, not on z/Linux. Unfortunately, the purpose for which I had acquired it disappeared and I did not feel that I could afford it just for fun. That may no longer be true since they now have a hobbist license (which I doubt you could use). http://www.dignus.com There is also a very old port of GCC which runs on z/OS. I never could get it to work properly. I don't know if there is a current port of GCC for z/OS or not. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology -- Rich Smrcina VM Assist, Inc. Main: (262)392-2026 Cell: (414)491-6001 Ans Service: (360)715-2467 rich.smrcina at vmassist.com -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Ordering HLASM for Linux on zSeries
Hi John! To throw some numbers out there, in our own defense... Just taking a quick glance around, I found a test case in our suite that has 483,086 lines. Not quite 500,000 - but pretty close, (for some definition of pretty and close :-) ) The listing has 9398 pages :-) The last time it was assembled on an 800mhz PC running FreeBSD 5.3, on Jan 31, 2006, it took 45 wall seconds and 25 CPU seconds. That includes a full listing and cross-reference. I would expect a more modern machine would turn in dramatically better numbers. So - I think the workstation is quite able to handle that size assembly. I don't know if Java could provide that kind of performance, but it does provide some portability. When I say Eclipse-based workstation, I didn't mean that the assembler was implemented in Java, just that it integrated with the Eclipse IDE... just to clarify that point a little. - Dave Rivers - To Dave Rivers: I thought Don Higging was working on that? 8-) And, if an Eclipse-based workstation assembler can handle source files up to 500,000 lines we might consider that possibility. -- 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: Ordering HLASM for Linux on zSeries
I would agree with what David wrote, and suggest that we take it further. Wouldn't it be nice to be able to do that on your workstation/PC, using Eclipse tools and assembling locally? I mean, we've said it many times here that CPU-intensive tasks are better in some alternative environments. That's our thought anyway... (http://www.dignus.com/dasm/) - Dave Rivers - David Boyes [EMAIL PROTECTED] Biggest advantage to HLASM on zLinux is the *ability* to license it on IFLs. Assembles/compiles eat CPU like crazy. IFLs are cheaper than std engines, so you burn the IFL cycles on the CPU-intensive bits, and test on GCPs. HLASM on zLinux also lets you employ Eclipse and other nice development tools to mainframe development. -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: IBM software for z/VM and/or Linux on zSeries
Hi Mark, RACF defines various tables in assembly language that need to be assembled and linked in. HLASM is listed as a prerequisite for RACF in the RACF specifications. However, HLASM has become a for-charge product in VM (it used to be free there too.) Several sites are now using our assembler for this, saving a lot of money. - Dave Rivers - I'm curious. Why does RACF require that you have HLASM (or your replacement)? Note that I've never worked on an MVS system that didn't have an assembler, so I've never paid much attention to what needed it or not. Mark Post -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: IBM software for z/VM and/or Linux on zSeries
Thanks Alan! I have to admit to being a little ignorant on the details. I was just reporting what folks at IBM and our customers had told us... (hence my somewhat vague answer to Mark's question :-) ) - Dave Rivers - On Thursday, 11/17/2005 at 12:08 EST, Thomas David Rivers [EMAIL PROTECTED] wrote: If you get RACF, you'll need HLASM (or, you can use the DIGNUS replacement there for a lot less money...) This is how rumors get started. :-) RACF requires HLASM only if you want to customize the way CP and RACF talk to each other. If you are satisfied with the defaults, then HLASM is not required. In particular, the macros SYSSEC (does RACF defer to CP or fail the request?) and GLBLDSK (bypass access control and audit for selected disks) are the usual targets of such customizations. HLASM is not required for the general IBM service of RACF. Alan Altmark z/VM Development IBM Endicott -- 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: IBM software for z/VM and/or Linux on zSeries
If you get RACF, you'll need HLASM (or, you can use the DIGNUS replacement there for a lot less money...) - Dave Rivers - For securing logons, links, guest lans, rdrs: RACF If you have multiple LPARs consider RSCS for file and data transfer Good luck - David -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
See the wait(2) man page for the reason why the return-code limited... Basically, more than the return code is returned when a process ends - and that consumes some flag bits. - Dave Rivers - On Monday, 10/10/2005 at 06:45 ZE2, Carsten Otte [EMAIL PROTECTED] wrote: Alan Altmark wrote: Eh? CP has *thousands* of return codes. I is just Plain Wrong to try to map them to the smaller name space of the Linux return code. Good point. me adds mapping CP return value to Linux rc to his list of bad ideas. If a program makes a rc = system(vmcp foo) call, will it get the full return code? Or can a program call vmcp in some other way? I am wondering if the problem with the 8-bittedness of the return code is a result of real truncation or if it's just an artifact of the shell's rendering of the return code. Maybe we should fix it? I think DJ is right: why have int main() if the program can't [usefully] return the full range of ints? -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: ELF Binaries and Linux on z/Series
I've got a customer here that's all excited about ELF binaries. They have a product they'd like to see run on z/Series linux but there is no declaration that z/Series is a supported platform. They do state that their binaries are 100% ELF compatible. What exactly does that mean for an intel based product when someone wants to have you try it on z/Series cuz it's ELF binary compatible. Shouldn't work regardless, should it? Hi James, ELF is an object file format... The ELF on x86 Linux follows the same ELF as z/Series does, but the bytes in there don't. Your product will need to be rebuilt for z/Series Linux. Mainframe linux won't run PC linux programs (at least directly.) - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: cross compiler for GCC 3.3.3
I am currently running SuSE9 with GCC 3.3.3 on Z/LINUX and like to compiler C program on the INTEL mchine. Do we have a cross compller on z-linux to compiler program for the INTEL box? We offer such a compiler - although it's not GCC... It's Systems/C. See http://www.dignus.com Also - several people here have pointed to instructions for how to get GCC built in a cross-environment... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: z/VM IFL special price for Systems/ASM
On Thu, Apr 01, 2004 at 04:10:23PM -0500, Thomas David Rivers wrote: [.. short, hype-free, informative message on new product offering ..] Now that's the way to make a commercial announcement on a mailing list. Well done. -- db Hi David! Thanks it's always sooo hard to balance things... By the way - if you find it might be helpful in any of your Linux installations, just let us know. We installed it a few weeks ago at the EPA and it's working beautifully. IBM is going to be pushing it as hard as they can, as it reduces the total cost for z/VM + Linux. - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
z/VM IFL special price for Systems/ASM
Just a quick note that our Systems/ASM assembler (DASM) is now available under z/VM with IFL engine prices. For z/VM RACF management, you need an assembler to do RACF updates... which is a special bid from IBM. We can help reduce your costs by substituting Systems/ASM. We have had some wonderful success with this, if anyone is interested in saving $$$ feel free to contact us. For more information about Systems/ASM - see http://www.dignus.com/dasm/ - Thanks - - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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
Re: Use of DIrmaint
As David mentioned, a reference C program (with source!) would go a long way towards adoption of SMAPI. In SMAPI's defence, there is a lot of sample code in the docs (which are extensive). Problem is that it's not helpful if you don't have a C compiler and a lot of shops that are using VM only to support Linux aren't going to license the C/C++ compiler just to write management apps. There are other alternatives to the IBM C/C++ compiler... Systems/C, Systems/C++ (and Systems/ASM) are available on VM, in a special distribution... - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: MS url
The Register gets it just about right http://www.theregister.co.uk/content/4/34734.html Ha! Pretty funny when I went to look at it; there were a couple of Microsoft advertisements on the page, with a link at the bottom to take a Microsoft-sponsored survey on providing feedback to Microsoft. Perhaps, instead of Biting the hand the feeds IT, The Register's slogan should be Biting the hand that feeds us :-) :-) :-) I'm sure the ad-placement was semi-random, and I just got the luck-of-the-draw; but it was certainly funny to look at :-) - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Os/390 (no MQ) to Linux LPAR (MQ) anyone?
Just to add to this discussion - we've had several customers do exactly this, avoid MQ-series and other middle-ware products simply using Systems/C (and Systems/C++) to write some quick TCP/IP client/server programs on z/OS - talking directly to the non-z/OS systems, using some of the freely available communication libraries (e.g. Boost.)One of these was a govt. agency in Australia so, it really works :-) Although Linux is free - the total cost of Systems/C++ still is *much* less than a typical Linux installation because of the additional cost for VM, Linux admin, etc... (I'm assuming someone familiar with C and/or C++ is already on-staff.) Even if you do your own programming. My point is that it's sometimes not necessary to go to the trouble of installing a Linux IFL or a new VM machine or some expensive middle-ware just to communicate data. Sometimes, the more straight-forward solution will work just fine. We can forward references if anyone is interested. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: IBM iSource -- U.S. Announcements
Wolfe, Gordon W [EMAIL PROTECTED] wrote: Or does per install mean each and every linux server? I wonder if this was prompted by the pricing changes RedHat announced for the up-coming (PC) versions. Apparently, they want to start charging for each installed version of the product... before, companies would buy one copy and then install it on many machines, which wasn't making too much money for RedHat. There was a write-up in the News and Observer (the local Raleigh, NC newspaper) about it some weeks ago. The article was comparing this new policy to the typical Microsoft pricing policy. So - if you're charging for each PC - wouldnt' charging for each Linux instance make sense? - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Linux on 390 Port
Arnd Bergmann [EMAIL PROTECTED] wrote: On Wednesday 24 September 2003 11:11, John Summerfield wrote: I'm not familiar with SuSE, but I woul;d guess that if binaries created on S7 run on S8 and RHL 7, then they should also run on RHL 8. Only if you avoid C++ or link statically against libstdc++ as mandated by the Linux Standard Base. AFAIR, SLES7 and Debian woody used gcc-2.95, RHL7 used gcc-2.96, SLES8 and Rawhide have gcc-3.2 and Debian Sarge will have gcc-3.3. All versions until 3.2 were incompatible with each other, so if you want your binary to work on all of them, you need to link all g++ libraries you are using into your binary. There are also many different versions of glibc, but they are all backwards compatible, so if you link against glibc 2.1.3, it should also work with 2.2.5 and 2.3.1. Note that you should not link statically against glibc and other (non-C++) system libraries. Arnd There is an alternative... Dignus Systems/C++ for Linux/390 (or z/Linux) will produce C++ programs that run on all of those. We have our own C++ runtime, which includes the STL, etc.. And, we're much more ANSI compliant than g++. See http://www.dignus.com for more information. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: zSeries performance heavily dependent on working set size
On Maw, 2003-08-12 at 11:57, Thomas David Rivers wrote: Some versions of gcc don't do well with locality-of-reference for functions that reference many literals. There is a global pool of literals which can be far away. This approach could easily artificially inflate the working set size. gprof will generate you call graphs on a binary and a function list thats then pretty close to best locality when you relink it On a per-function basis - but not within functions; because gcc points R13 at the literal pool; which can be quite large (and different from the code location in sufficiently large functions.) - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: zSeries performance heavily dependent on working set size
Dave Rivers wrote: On a per-function basis - but not within functions; because gcc points R13 at the literal pool; which can be quite large (and different from the code location in sufficiently large functions.) Separating code and literal pool would appear likely to cause a net win on machines with separate i-cache and d-cache (i.e. all zSeries machines). I don't have specific measurements to prove that point, though. Yes - I would agree. It was a rather surprising discovery to us as well (when reported by some users of zSeries machines.) I may, however, be mis-attributing the reason for the performance benefit. There was some thought that gcc's use of relative instructions (which should also be fine in zSeries) might be the culprit... Admittedly - this are all guesses, and could use the watchful eye of some serious performance tester. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: zSeries performance heavily dependent on working set size
Fargusson.Alan [EMAIL PROTECTED] wrote: What would you do to improve Jims program? Some versions of gcc don't do well with locality-of-reference for functions that reference many literals. There is a global pool of literals which can be far away. This approach could easily artificially inflate the working set size. This could be one reason why people have discovered Systems/C has better performance than gcc... (Systems/C keeps literals within 4K of the reference, so they are likely to already be paged in...) So - one simple alternative may be to recompile the program with a different compiler. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -Original Message- From: Peter Vander Woude [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2003 1:24 PM To: [EMAIL PROTECTED] Subject: Re: zSeries performance heavily dependent on working set size Rod, I agree with you that the best solution to the issue of an actual application that is doing this type of programming would be to correct the program. While throwing hardware may seem easier, I'm always amazed by programmers reactions when I do point out that by making minor changes to a program, they can achieve big performance improvements (both in cpu and elapsed time). Peter I. Vander Woude Sr. Mainframe Engineer Harris Teeter, Inc.
Re: IBM's Power5+ to hit 3GHz
Fargusson.Alan [mailto:[EMAIL PROTECTED] wrote: From what I have heard, z/OS is mainly written in PL/S, which is a PL/1 like language which emits assembler code which is then assembled to create the actual programs. Also, much like GCC, PL/S allows one to embed assembler code directly in the source. Well - as I understand it - PL/S is much more like Systems/C, where you can embed arbitrary assembly source code, can radically alter the entry/exit sequences, etc... GCC lets you embed instructions, but it's not that good at, say, embedding a macro invocation. Although, I imagine with some effort, it could be done. That is, I think GCC is, perhaps only slightly, more restrictive than either PL/S or Systems/C. However, this doesn't seem to be any type of deterrent in the effort to write operating systems :-) :-) More to the point of the subject though, I understand that the later 9370s were actually a 68K core. And, I believe the P390 is a 68K core as well. So, this isn't exactly something new in the IBM world... - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Stripping trailing blanks?
John,
There's a simpler way... (perl is, typically, overkill.)
To strip the blanks from a file, just use sed:
cat $file | sed s/ *$// /tmp/strip.$$
mv /tmp/strip.$$ $file
This cats the file named $file - strips the blanks and writes
the output in the file named /tmp/strip.$$. Then, it moves
the file named strip.$$ back over the original file.
The sed substitution can be read as:
substitute any string of blanks, anchored at the end of the
line with nothing.
You can also do a similar trick to get rid of MSDOS carriage
returns... very straightforward.
- Dave R. -
John McKown wrote:
Is there a simple way to strip blanks from all the lines in a file? What I
am doing is downloading members from my various PDSes. Some of these member
contain the standard sequence number in columns 73-80. I am using Perl to
strip these off. After stripping off the sequence numbers, I would like to
strip off any resulting trailing blanks. My current Perl script looks like:
#!/usr/bin/perl
while() {
chop;
s/(.{0,72}).*/\1/;
$new1 = reverse($_);
$_ = $new1;
s/ *(.*)/\1/;
$new = reverse($_);
print $new,\n;
}
I admit that I'm a tyro Perl person. I'm a legacy mainframer. I am more used
to assembler and REXX.
--
John McKown
Senior Systems Programmer
Re: Stripping trailing blanks?
If you're going to use a shell script, I think you will find this model
both faster and safer: faster because the cat command is superflous, and
safer because it keeps the original, just in case.
mv ${file{ ${file}~
sed ${file}~ ${file} \
-e s/ *$//
I've not tested mine either, but your sed's wrong;-)
Oops - I think you have a typo there in the first line.
But - none-the-less; my sed is right - you don't have to have
the -e. The traditional (pre-GNU) format didn't require
the -e... the syntax was simply
sed [-Ean] command [file ...]
It is nice that you script preserves the original file - a much
better idea!
- Dave R. -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
Re: What's stopping SCO from doctoring...
Lucius, Leland [EMAIL PROTECTED] wrote: ...their source to make ABSOLUTELY CERTAIN things match up with the kernel tree? And how do they prove it wasn't the other way around? SCO employees taking from the Linux kernel to look good to their bosses? actually - that's one of the purposes of escrows, etc... A company can assert that it wrote the code in year X; and can verify that with a 3rd party escrow agent that coughs up the escrow from year X with the source on it. Of course; you could manipulate the escrow agent, but that agent wouldn't be in business very long after that happened. So - presumably in a situation like this, SCO would be able to show, via a virtual paper trail at the escrow agent, that is had written that source. Until something like that shows up, though, my thought is that this is a look-and-feel argument. i.e. that looks like and feels like something we did, so it must be our source. It would hope/expect the argument from SCO's side to be a little more forceful/compelling than that. That is, in a trial, I would expect SCO to produce this escrow trail detailing the source's progeny; and then make an argument that the source is the same. But, I don't imagine there will be any disclosure until an actual trial. So - until something happens - we're all just guessing. - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Dignus announces Systems/ASM V1.70
John Summerfield [EMAIL PROTECTED] On Wed, 16 Jul 2003, Kanter, Mauri wrote: To slightly modify IEFBR14 processing some sites coded home written 'user exits' :-) In early MVS, IBM modified to code to something like this: IEFBR14 CSECT B THERE-*(0,15) DC AL1(THERE-*),CCOPYRIGHT IBM CORP INC' THERE SR 15,15 BR 14 END IEFBR14 No joke. So - perhaps a better Linux version would be: main CSECT main ALIAS C'main' balr 13,0 using *,13 bthere DC AL1(there-*),C'No Copyright' there DS 0H sr 2,2 br 14 end This starts to get into the specifics of Linux linkage and return values (using R13 as the base register, R2 as the return value register.) But, that seems to be appropriately analogous :-) And, of course, this would assemble and run correctly using Systems/ASM for Linux. - Dave Rivers - -Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 3:47 AM To: [EMAIL PROTECTED] Subject: Re: Dignus announces Systems/ASM V1.70 On Tue, 15 Jul 2003, Tom Duerbusch wrote: APAR that puppyit doesn't set the return code. IEFBR14 also had the same problem. And a few others;-) -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb Copyright John Summerfield. Reproduction prohibited. -- Cheers John. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb Copyright John Summerfield. Reproduction prohibited.
Bad URL
Well - Several people have pointed out that I mis-typed the URL for the Systems/ASM press release... so, here is the corrected one: http://www.dignus.com/press_releases/030715.html Thanks - sorry for the confusion! - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Dignus announces Systems/ASM V1.70
Just like to take a quick moment to announce something that might be interesting to this list. We've just released V1.70 of our HLASM compatible Systems/ASM assembler. As well as supporting the new z990 instructions/formats, and other niceties, this new version includes support for generating Linux/390 and z/Linux objects from HLASM source that is as unchanged as we could make it. For example, the following program assembles and runs on Linux/390: main CSECT main ALIAS C'main' BR 14 END (about the simplest mainframe program there is. There are other examples in the Systems/ASM documentation.) This support also includes complete debugging information, including line numbers and DSECT member offsets; so you can use the typical Linux debuggers to debug the assembly program and refer to DSECT members, set break points on lines in the original ASM source, etc... There are several other features in this new release, if you're interested, please see the press release available on our web page (http://www.dignus.com/press_release/030715.html) - Many Thanks! - - Dave Rivers - p.s. See us at SHARE - Booth number 305! -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Dignus announces Systems/ASM V1.70
Tom Duerbusch [EMAIL PROTECTED] wrote: APAR that puppyit doesn't set the return code. IEFBR14 also had the same problem. Tom Duerbusch THD Consulting So true! So true!!! Typing without thinking... what to do? - Dave R. - [EMAIL PROTECTED] 07/15/03 04:27PM Just like to take a quick moment to announce something that might be interesting to this list. We've just released V1.70 of our HLASM compatible Systems/ASM assembler. As well as supporting the new z990 instructions/formats, and other niceties, this new version includes support for generating Linux/390 and z/Linux objects from HLASM source that is as unchanged as we could make it. For example, the following program assembles and runs on Linux/390: main CSECT main ALIAS C'main' BR 14 END (about the simplest mainframe program there is. There are other examples in the Systems/ASM documentation.) This support also includes complete debugging information, including line numbers and DSECT member offsets; so you can use the typical Linux debuggers to debug the assembly program and refer to DSECT members, set break points on lines in the original ASM source, etc... There are several other features in this new release, if you're interested, please see the press release available on our web page (http://www.dignus.com/press_release/030715.html) - Many Thanks! - - Dave Rivers - p.s. See us at SHARE - Booth number 305! -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: newbie gcc s390 question
Thank you Dave, the ulimit -s command solved my problem /Mats Glad to help! - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com I have a C program that call a recursive function that causes the program to run out of stack space. What compiler options should be used to increase the stack size. Mats Westlund Mats, There is no compiler option... the amount of runtime stack space is not determined by the compiler, but by the operating system systems. The general setting allow for generous stack space, so, first make sure you're not infinitely recursing. If it's infinite - no amount of stack space will fix it! If it's not infinit - I typically direct people to the ulimit man page (man ulimit), which points you to the shell (bash), and the system configuration programs (sysconf.) The reason your shell gets involved is there is typically a built-in shell command that adjusts the various limits. - Dave Rivers -
Re: newbie gcc s390 question
Mats Westlund (GIS) [EMAIL PROTECTED] wrote: I have a C program that call a recursive function that causes the program to run out of stack space. What compiler options should be used to increase the stack size. Mats Westlund Mats, There is no compiler option... the amount of runtime stack space is not determined by the compiler, but by the operating system systems. The general setting allow for generous stack space, so, first make sure you're not infinitely recursing. If it's infinite - no amount of stack space will fix it! If it's not infinit - I typically direct people to the ulimit man page (man ulimit), which points you to the shell (bash), and the system configuration programs (sysconf.) The reason your shell gets involved is there is typically a built-in shell command that adjusts the various limits. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: API to get fullpath name
Ferguson, Neale [EMAIL PROTECTED] wrote: How do I, within a program, get the full pathname of the program I'm executing? argv[0] will have the command name but not necessarily the full pathname. Neale, In general, you have to know the name of the program (argv[0] may be incorrect) and then have to look at the users PATH environment to find it... That is - you have to look at argv[0] to see if it's a direct path specification (begins with '/' or '.'). If it's not, then you look along the PATH environment variable to find argv[0]. This approach does not work if the program is being exec'd and the exec() call sets argv[0] to something strange. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: API to get fullpath name
Ferguson, Neale [EMAIL PROTECTED] wrote: How does the command 'which' work? The symbolic link /proc/self/exe will point to the absolute path. 'which' looks at your PATH environment variable - looking for the file name you gave it as a parameter as in, If I were to execute this command, 'which' file would it run? Also - looking at /proc isn't portable - different UNIXes uses different /proc structures (some don't have it at all..) But, that may not matter in the modern era. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: API to get fullpath name
Richard Troth [EMAIL PROTECTED] wrote: This approach does not work if the program is being exec'd and the exec() call sets argv[0] to something strange. Leaving argv[0] set to the original command (then exec()) or setting it to something strange are very useful features of the UNIX API. Good stuff. (But doesn't help Neale.) -- RMT To be sure (look at argv[0] of the shell your running sometime :-) ) I wasn't saying it was bad - it just makes it difficult to do what Neale needs done... - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Development tools
David Boyes [EMAIL PROTECTED] I'll second that. While I really dislike IDEs because I think they mask sloppy programming habits, Eclipse has some pretty neat gadgetry in it, and it's nice that IBM had the sense to keep it open. The overall design is pretty nice, although COBOL support would tend to make me wonder... To forestall Dave J's question, so when does it get a PL/1 mode? 8-) New versions of Websphere include Eclipse-based software for development... some of the advantages of buyin Websphere include modules for supporting PL/I and COBOL. This is based on a web-cast I was in on a few weeks ago.. I think it's available from the SHARE web site. So - the answer is already - but - to get it from IBM, you have to pay for Websphere (you may already have it.) - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: so correct me if I am wrong
Matt Zimmerman [EMAIL PROTECTED] wrote: On Fri, Feb 21, 2003 at 11:55:16AM -0500, Thomas David Rivers wrote: My experience has been that cross-compiling is risky, at best. While working to port SAPDB, one of the other people helping was doing cross-compiles, and getting different results than I was. Setting up a cross-compile environment is apparently not easy to do correctly, so I try to avoid it as much as possible. Cross-compiling is risky... but, it can be done. Earlier versions of gcc had problems, but it's getting better (and, of course plugSystems/C/plug gets it right.) The problems are not generally with the compiler/assembler/linker toolchain, but with the packages being built. Most programs have never been cross-compiled, and make assumptions that do not hold true for cross-compilation. For example, that the same compiler used to build executables for the target system can be used to build programs meant to run on the build system (such as utilities used during the build). -- - mdz Matt, That is a *very* good point! It certainly diminishes the utility of a cross-compilation environment. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: so correct me if I am wrong
My experience has been that cross-compiling is risky, at best. While working to port SAPDB, one of the other people helping was doing cross-compiles, and getting different results than I was. Setting up a cross-compile environment is apparently not easy to do correctly, so I try to avoid it as much as possible. Cross-compiling is risky... but, it can be done. Earlier versions of gcc had problems, but it's getting better (and, of course plugSystems/C/plug gets it right.) We'd be happy to discuss this with anyone who's interested; feel free to contact me off-line. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com Mark Post -Original Message- From: Tzafrir Cohen [mailto:[EMAIL PROTECTED]] Sent: Friday, February 21, 2003 11:30 AM To: [EMAIL PROTECTED] Subject: Re: so correct me if I am wrong On Fri, 21 Feb 2003, Post, Mark K wrote: Since they do put out the SRPMs (source RPMs), you can download those and build the binary for installation, but that can be, ummm, a chore, and it certainly chews up CPU time for packages of any size. (I'm currently in the process of re-building glibc 2.2.5, and it's going on 24 hours of wall clock time. Open Office took me about a _month_, on a much bigger machine that this one.) Why not put some cheepo intel with a faster CPU to the task? rpms should generally allow cross-platform building. I admit I haven't tried that, But the time it would take you to set that up (in addition to the compilation time of OOo) will still probably be less than a month. (Disclaimer: I have never tried this: nither rpm cross-building, nor building the OOo beast ;-) ) -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir
Re: so correct me if I am wrong
McKown, John [EMAIL PROTECTED] wrote: Dave, Can Systems/C be used for kernel development? Or does Linux still have a number of gcc dependancies as I've read in the past? Or course, few of us actually cross compile the kernel itself. About the only syntax issue Systems/C doesn't support now is the gcc-style of inline assembly source. Most (all?) of the other gcc extensions are now supported by Systems/C. So - for kernel development; which likely does some significant gcc-style inline assembly... Systems/C may not yet be the thing to use. But - for applications development, we think it's just fine. - Dave R. - p.s. We'll be a SHARE next week, if anyone else is going - drop by our booth! -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Development tools
Not an option, at least at present. The thought is to consolidate Intel servers onto zLinux. If some of that consolidation could be development, great. Otherwise development will stay on Windows/Intel. Perhaps, in the future, Linux/Intel will become a possibility here. But not right off hand. This question actually came from our z/OS developers who are looking at some way of using zLinux to help off load some of the legacy workload. I think we convinced them that is not a good way to start. (I.e. Can we run a CICS region on zLinux?) But using Apache on zLinux as a Web front end to our legacy workload (along with MQ et al.) may be a possibility as a second stage usage of zLinux. There are _some_ things you can offload... for example, the Dignus tools all run on z/Linux... so, you can offload all your assembles using our assembler on z/Linux. (That is, use z/Linux to create z/OS programs...) And, since our C/C++ compilers have an IBM compatibility mode, you can offload your IBM C/C++ builds for z/OS to z/Linux. z/Linux might make a very attractive build environment for z/OS programming. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: vi vs. ISPF
Jay Maynard [EMAIL PROTECTED] wrote: On Thu, Feb 20, 2003 at 08:41:07AM -0800, Fargusson.Alan wrote: I am surprised that some of you can't figure out the difference between command mode, and insert mode. The problem is that typig text at vi in command mode is often catastrophic, and there's no good way to tell if you're in command mode in most setups. Sure, you can always do esc I (or A, or...) to make sure you're in insert mode, but why should you have to? Add set showmode to your .exrc file in your home directory (assuming your vi clone is a true clone. The BSD one seems to be the closest to real vi, I'm not a fan of vim myself...) Then, in the bottom right hand corner, vi will display the mode. It can be very helpful for learning... Now - as to the question of why should you have to? Well - that's a big one, either way :-) I think it comes down to what do your fingers remember... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Compilation Failure in gdb 5.2.1
Back in December of 2001, Nish Deodhar reported the same problem with gdb 5.1, and talked about the changes he made to get it to compile. Jim Blandy from Red Hat/Cygnus asked him a few questions about what he'd done, but the gdb 5.2.1, and 5.3 source doesn't reflect those changes. So, I have to assume that they weren't considered a good fix by the gdb maintainers. I manually re-compiled the module with --save-temps. If anyone could help me figure out what needs to be done to get this to compile, I would appreciate it. Thanks, Mark Post Mark, The problem is that one of the opaque types isn't quite as opaque as it should be. We've sent several gdb fixes into the gdb maintainers for the 390 and z/Series gdb... they actually have incorporated many of them (but, there is a significant legal hurdle to overcome, which makes gdb progress quite slow.) However, as I understand it, the gdb maintainers have not changed this one... they view it as a deficiency in the s390 and z/Series Linux implementation (some type defined by the kernel which is defined differently on mainframe linux than other linuxes.) So - for us, to get gdb to compile cleanly, we had to make many local modifications... if you just go grab the gdb sources, it won't compile on mainframe linux. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Linux compiles
Cross compiling would have been my first recommendation, until I ran into differences in compilations between Linux/390 and cross compiling. Running Hercules reduces the effective speed of the box, but I believe it allows you to be more certain that what you end up with better reflects what you would have gotten on a 'real' Linux/390 system. The differences in question were discovered trying to compile SAPDB. I ran into things that needed correction that someone else did not. I was compiling on Linux/390, and they were cross compiling on Intel Linux. Mark Post Gcc can be configured as a cross-compiler, but the gcc compiler makes several assumptions that may or may-not be valid about its host environment making it what I would call a mostly cross-compiler. Most notably - floating point arithmetic; which don't matter to many applications. We've gone to great lengths to ensure the Systems/C and Systems/C++ compilers generate exactly the same code on every platform. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Linux compiles
Most notably - floating point arithmetic; which don't matter to many applications. This in particular will be fixed with gcc 3.3. Compile-time floating point arithmetic will be done exactly identical in native and cross compiles. (But even before 3.3, this should not be an issue for targets using the standard IEEE format, only with non-IEEE targets.) That is, of course one of the issues. The i386 IEEE implementation is not the same as the mainframe, particularly when two variables are loaded into registers and arithmetic is applied. The result will be different.So, one set of IEEE arithmetic on a PC can get very different answers than the same arithmetic on a 390. I don't know how gcc handles this. That is, I believe, one of the reasons why #pragma STDC FENV_ACCESS was added to the C99 standard. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Linux compiles
Dave Rivers wrote: That is, of course one of the issues. The i386 IEEE implementation is not the same as the mainframe, particularly when two variables are loaded into registers and arithmetic is applied. The result will be different.So, one set of IEEE arithmetic on a PC can get very different answers than the same arithmetic on a 390. I don't know how gcc handles this. Basically, by not using the host's native floating point facilities at all. Instead, all floating point use at compile time is done by a floating point emulation library that can be tuned to exactly simulate the target's native floating point format and precision. This is necessary both for things like compile-time folding of floating point constants, to make sure we get the same result as we'd get had we executed the computation explicitly on the target machine, and for things like the use of floating point variables internally to the compiler (e.g. for branch probabilities) where different rounding could cause different optimization decisions and thus different emitted code in a cross vs. a native compilation. Yes - it sounds *very* familiar! :-) - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
[ANNOUNCE] Systems/C, Systems/C++ and Systems/ASM for z/Linux
Just a quite note to announce the new versions of Systems/C, Systems/C++ and Systems/ASM. What makes this pertinent to this mailing list is the new 64-bit support, including z/Linux. All of the Dignus tools now run on z/Linux, as well as generating code for z/Linux. We have also delivered the first 64-bit complete C/C++ development environment for z/OS, as well as new utility programs, ANSI C99 features, etc... That seems about as long a message as I should allow, I'll just add that those who are interested should visit our web page for more information - http://www.dignus.com. - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Fortran 95 Compiler
Gowans, Chuck [EMAIL PROTECTED] wrote: Hello All, I need to port a Fortran module from a non-390 Linux platform to our Linux-On-390 platform. This module has been coded in Fortran95 using a number of the new functions/features available in Fortran95. I am aware of the g77 Fortran rpm that is available, but I am guessing that it is at the Fortran77 level. Is this correct? If so, Is there a Fortran95 plug-in for this compiler that would allow it to compile the Fortran95 code - once again for the Linux-on-390 platform? Is a freeware plug-in available or do I have to look for a commercial source? If no plug-in is available, is there a Fortran95 compiler? Thanks in advance for the help. Chuck Gowans USDA - Nat'l IT Center - Kansas City (816) 926-2345 Just to try and gage potential interest in this area Would anyone be interested in a Fortran95 compiler for z/Linux + Linux/390? Would you consider paying for it, or would this interest only go as far as acquiring a free one? If you would be willing to pay for it, how much would you consider reasonable? Many thanks! Oh - please - replies to me ([EMAIL PROTECTED]), no need to gum up the list. - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: VSAM or Lightweight Database?
I'd like to explore moving some OS/390 VSAM files to Linux on the 390. Can anyone point me to some appropriate resources? I would like to stay with VSAM (ISAM, C-ISAM, etc.) files, since some of the code that uses those files is written in assembler. Record locking would be necessary however. A web Search did not turn up much of any useful information. Paul, You should look at C-TREE from Faircloth... it's used by a lot of people to implement VSAM-like functionality on many platforms. However, I think you might be hard-pressed to re-use your existing assemlber code on Linux/390. The calls will be totally different (there are no macros to invoke in Linux), everything will be in ASCII, entry/exit linkages are different, etc... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: SlickEdit ® Announces Availability of Visual SlickEdit for Linux on IBM eServer zSeries
Thought this may be of interest to some of you, probably the more developer orientated types will enjoy it most, but its still fun for all. It supports heaps of different languages etc see the blurb for yourself. In my opinion this is an excellent tool on any platform well worth a look at. Its now available on my favourite platforms z/OS Linux/390. See their press release at http://www.slickedit.com/news/press/2002/pr_vse_zseries.htm Paul Matthews jnr Principal Consultant Just f.y.i Dignus,LLC is an authorized reseller of SlickEdit. We can help anyone who would like to learn more about SlickEdit, or would like to order a copy. The new version (7.0) has many enhancements; and it (optionally) supports HLASM text (we find that *very* helpful.) Being able to locate a macro definition anywhere in a blob of files can be very handy. It also integrates seamlessly with the Dignus tool suite. - Dave Rivers - --
Re: Intel Architecture Emulated with Linux/390?
Most of this stuff's been addressed by those who have ported it to Sparc. We're lucky to becoming slightly later into the game so these things have been seen and fixed for us. Yes - very true - SPARC and PowerPC are both the same byte order as the mainframe. So, for Linux apps, most of these shouldn't have any problem. But - if a vendor only has an x86 version of the product (i.e. Windows), it's something to look out for :-) - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: General LINUX Question
Anyone, We're researching the opportunity of server consolidation through the investment of LINUX images on our mainframe. Is anyone aware of compiler limitations concerning programming languages, or anything at all between Microsoft or Unix environments to LINUX? Several members of our Network team are standing firmly in the ear of management exclaiming that LINUX is something of a toy or IBM cash cow that will not perform up to Microsoft or Unix standards. Bruce Fry As far as compilers are concerned, there is the freely-available gcc. But, Dignus also offers C and C++ compilers for mainframe linux. To keep things brief for the general readership, I'll just say to visit http://www.dignus.com for more info. - Dave Rivers - --
Re: Linux/390 STLport SIGSEGV errors
Post, Mark K [EMAIL PROTECTED] wrote: Hopefully someone out there will have some experience with building STLPort on Linux/390. I've just about driven myself crazy on this, but I can't get it to work. I've tried STLport 4.0, 4.5, 4.5.3. I've completely rebuilt gcc 2.95.2 with a patch Martin Blapp pointed me towards. I've completely rebuild glibc 2.2.3. I've turned off all optimization. I've played with the -pthread compile option, the various permutations of -D_REENTRANT and -D_PTHREADS. I get further than I used to, but I'm still dying. If anyone can offer any other suggestions, I'd love to hear them. Here's the latest gdb run. Mark, I ran this past the guys here and we have something of an answer for you. gcc has several bugs which we discovered when doing our own C++ implementation, particularly in the area of exception handling. Typically, these are problems where gcc doesn't implement the proper C++ semantics, particularly for partially instantiated objects. This is probably what you're seeing here - a partially instantiated object has a dangling pointer somewhere. There is some thought that gcc 3.3 will address some of these issues... but we haven't verified this ourselves. Hope this helps! - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Linux/390 STLport SIGSEGV errors
Hopefully someone out there will have some experience with building STLPort on Linux/390. I've just about driven myself crazy on this, but I can't get it to work. I've tried STLport 4.0, 4.5, 4.5.3. I've completely rebuilt gcc 2.95.2 with a patch Martin Blapp pointed me towards. I've completely rebuild glibc 2.2.3. I've turned off all optimization. I've played with the -pthread compile option, the various permutations of -D_REENTRANT and -D_PTHREADS. I get further than I used to, but I'm still dying. If anyone can offer any other suggestions, I'd love to hear them. Here's the latest gdb run. This may not be of much help... but, Systems/C++ for Linux/390 includes the STLport libraries. Of course, that's not using g++. I'll pass your e-mail to the developers here and see if we can be some assistance... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
C++ question...
I am a C++ dummy so can any one tell me what I should look for to fix the
following. The code says:
void CallStack::Output(ostream os)
{
total_time = data.total_time();
for (ProfileData::const_arc_iterator i = data.begin_roots();
i != data.end_roots(); ++i)
{
os root ' ' get_func_time(*i) '\n';
output_node(os, *i, 1);
}
}
The compiler bitches:
callstack.C: In member function `void CallStack::Output(std::ostream)':
callstack.C:83: no match for `ProfileData::const_arc_iterator !=
ProfileData::const_arc_iterator' operator
The compiler is complaining that the const_arg_iterator class
does not have a != operator where the left-hand-side is a
reference and the right-hand-side is not.
This is probably coming from the:
i != data.end_roots()
comparison in the for() loop.
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
Re: Oracle on 64bit SuSE
Ulrich Weigand [EMAIL PROTECTED] wrote: Dave Rivers wrote: You're right... you can't run 32-bit binaries on the 64-bit system. It's not so much C/C++ as it is the Linux kernel... it won't run 32-bit programs (at least, our ThinkBlue 64-bit one won't.) You most certainly can run 32-bit binaries on the 64-bit kernel. However, unless the 32-bit app is statically linked, you'll need the appropriate 32-bit shared libraries to go with the app. AFAIK, ThinkBlue (at least some versions) does not provide the 32-bit system libraries, so you can't run 32-bit apps. Both SuSE and RedHat 64-bit distros do provide those libraries. Ah! Very good to know! But - when I try this with TurboLinux-64, I don't get a message that indicates a shared library can't be found, I get a message that indicates the program can't be run at all... $ ./prog $ sh: ./prog: No such file or directory (maybe it should be saying some shared library is missing?) But - I did check a static link, and you're most definately right! Things do run if they are statically linked. We've been sitting here with TurboLinux so long, maybe it's time to try out some of the others. Many thanks! - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Oracle on 64bit SuSE
Post, Mark K [EMAIL PROTECTED]
Sergey,
I would think that you would need the 64-bit Oracle to run on the 64-bit
SuSE system. I could be wrong (what I don't understand about C/C++ would
fill a library), but the errors you're seeing make me believe that.
You're right... you can't run 32-bit binaries on the 64-bit
system.
It's not so much C/C++ as it is the Linux kernel... it won't
run 32-bit programs (at least, our ThinkBlue 64-bit one won't.)
Rather disappointing... but, I'm sure some enterprising
person will appropriately augment the various kernel exec()
routines to make it happen if it needs to.
As far as C/C++ experts - we are certainly in that category,
if anyone has a C/C++ questions, feel free to send them to us.
We'll be glad to help!
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
Mark Post
-Original Message-
From: Sergey Korzhevsky [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 6:20 AM
To: [EMAIL PROTECTED]
Subject: Re: Oracle on 64bit SuSE
Thank you, Mark. I checked md5sum. All right.
I started to download Oracle for 390x but is that mean, that i can't run
31bit Oracle on 64bit SuSE system?
WBR, Sergey
Post, Mark K
mark.post@eds.To: [EMAIL PROTECTED]
com cc:
Sent by: Linux Subject: Re: Oracle on 64bit
SuSE
on 390 Port
[EMAIL PROTECTED]
ARIST.EDU
16.08.2002
17:52
Please respond
to Linux on 390
Port
Sergey,
Those could not read symbols errors sound really bad, perhaps some form
of
corruption. What's the md5sum of your file? Mine is
66f0ba4544cffb0e4569d669e43200c6 ora90101_S390_0329.tar.gz
Oops, I just noticed that you are using 64 bit SuSE. You need the
Oracle9i
Enterprise Edition for z/Linux (Developer's Release)
ora901X_S390_1011.tar.gz file, from
http://download.oracle.com/otn/linux/oracle9i/390/ora901_S390X_1011.tar.gz
Mark Post
-Original Message-
From: Sergey Korzhevsky [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 16, 2002 4:34 AM
To: [EMAIL PROTECTED]
Subject: Re: AW: Oracle on 64bit SuSE
I can't create any libs, so i don't have libclntsh.so.9.0, be cause i got
this errors on first step - install.
WBR, Sergey
Coosmann, Carlo
Carlo.Coosmann@RTo: [EMAIL PROTECTED]
LA.AOK.de cc:
Sent by: Linux onSubject: AW: Oracle on
64bit SuSE
390 Port
[EMAIL PROTECTED]
IST.EDU
15.08.2002 21:08
Please respond to
Linux on 390 Port
In which lib directory /lib /usr/lib or someother pathlib? Does your
ld.so.conf include this path and have you run ldconfig? Can you invoke
lsnrconf.sh like this: LD_LIBRARY_PATH=path to libclntsh.so.9.0
lsnrconf.sh
-Urspr|ngliche Nachricht-
Von: Sergey Korzhevsky [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 15. August 2002 16:07
An: [EMAIL PROTECTED]
Betreff: Oracle on 64bit SuSE
I'm trying to install Oracle ( ora90101_S390_0329.tar.gz) . When i start
install.sh i get following errors:
Linking client shared library
/opt/oracle/s390/lib/libwtc9.so: could not read symbols: Invalid operation
and then
- Linking Oracle
--skip--
lm`cat /opt/oracle/s390/lib/sysliblist` -ldl -lm
/opt/oracle/s390/lib//libodm9.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [/opt/oracle/s390/rdbms/lib/oracle] Error 1
I tryed to remove ${LD_SELF_CONTAINED} flag from genclntsh script but it
isn't help me.
Any suggestions?
btw,
zlinux:/opt/oracle/s390/bin # ld --version
GNU ld 2.11.90.0.27
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
Supported emulations:
elf64_s390
elf_s390
WBR, Sergey
Re: Debugger question - gdb?
John Campbell [EMAIL PROTECTED] writes: Many years ago I had a similar problem. Not with Linux, but running DOS on a PC. The problem turned out to be that the compiler thought it was smarter than me and optimized the code out of existance. Once I turned of optimization, the problem went away. The program was small so it didn't matter to me. I would not expect a problem like this under GCC however; The act of using a -g is intended to disable any and all optimization. That's not the complete story - in GCC you can specify -O and -g at the same time. Thus, you can have an optimized program that contains some debugging information. This may be easier to understand if we could see a glimpse of the source... Also - we have discovered some issues with the 390 and 'z' versions of gdb, and made several fixes. These have been returned back to the official gdb tree, and should show up in future versions. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Clear Case
Gerard Graham [EMAIL PROTECTED] wrote: Trying to find out if anyone knows of or is using Clear Case, on Linux 390. I have a client that would like to port a major application to Linux but requires this software. Any help is appreciated. Gerard, ClearCase will export a file system via NFS - so it should work fine from their ClearCase server. That is, the Linux/390 machin would mount the correct exported version of a source tree. That should allow them to build their products on a Linux/390 platform. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Kernel 2.4.17 experimental and recommendation updates
Patterson, Ross [EMAIL PROTECTED] wrote: Gerhard Hiller [EMAIL PROTECTED] writes: On the new Experimental level 2.4.17 page at: http://www10.software.ibm.com/developerworks/opensource/linux390/exp-2_4_17.shtml you will find: This: gcc ... gcc-3.1.tar.gz (GNU) is not yet released. When it is released, no 390-patch is required. gdb ... gdb-5.1.1.tar.gz (GNU) - No 390-patch is required. modutils ... For modutils-2.4.7 (GPL) no patch needs to be applied for the S/390 backend. From one who's been patching the toolchain on a far-too-frequent basis, THANK YOU! This is excellent news - I think this may be the first time the compiler and debugger have had all the S/390 support fully integrated into the GNU source trees. Just F.Y.I. - We've got some fixes to gdb that are needed - not sure which version of gdb we're talking about. They address problems debugging programs with sufficiently large frames. We haven't gotten them integrated with the GNU source trees yet - but, we're working on it (just need to properly sign them over... even in free software, there are legal issues :-) ) Unforunately, I'm not privy to the details - but I can post here later if anyone is interested (including patches.) - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
[Announce] Systems/C++ for mainframe Linux.
Just a quick announcement... hopefully, a shortened version of this will not be too intrusive. Today, Dignus announces Systems/C++ for Linux - the first ANSI-98 standard C++ for mainframe linux. Systems/C++ also includes (pre-built) the de-facto STLport C++ standard libraries and Standard Template Library. For more information - please visit http://www.dignus.com, you'll find a pointer to the press release on the first page. And... now... we return you to your regular programming. - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: FW: Addressing problems using asm embedded in C
Condit, Christopher [EMAIL PROTECTED] wrote:
Thanks for the info Paul, but unfortunately I didn't specify my question
adequately. I'm writing *IBM* assembler, where a move is spelled MVC. My
third-hand doc says to write IBM opcodes but use Unix syntax. Whatever that
means. Here's a simplified example that would get 2 errors, for 2 label
references:
__asm__ __volatile__(
CHI %3,20\n
BHLABEL1\n
LA2,1\n
B LABEL2
LABEL1 LA2,0\n
LABEL2 BR14\n
: =a (retValue)
: d (pProc), d (pStack), d (cbStack)
);
I think you're missing a \n on that B LABEL2 - and a closing quote.
That would cause the definition of LABEL1 to `go missing', which
might explain things...
Also - you might want to look at Systems/C (http://www.dignus.com),
we think it allows direct in-line assembler in C in a much
nicer fashion than GCC does. But - that's a biased opinion.
Systems/C generates either HLASM or GAS output - supporting
both traditional mainframe operating systems and mainframe linux.
With Systems/C - you would have:
...
{
__register(2) int r; /* retval is in R2 */
__register(3) int t; /* testval is in R3 */
t = /* some expression - set's testval in R3 */
__asm {
CHI 3,20
BHLABEL1
LA2,1
B LABEL2
LABEL1 LA2,0
LABEL2 BR14
}
retval = r; /* Grab R2 and place it in `retval' */
}
I have already displayed that certain simple register manipulation works in
context, so I am confident that this language works, and that I am on the
right track.
On the other hand, it's news to me that ATT/Unix assembler can work on an
IBM S/390 box.
Oh yeah - it's just the GNU gas assembler... generating ELF
format... at some point, bits are bits...
I was only brought in on this project cuz I know IBM
assembler. If Unix assembler can be used just as well, maybe I will try to
dump this thing back on our Unix guy...
Well - it's UNIX assembler syntax - but IBM instructions. I'm sure
you're input will be very much appreciated...
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
CXC
-Original Message-
From: Paul L. Rogers [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 24, 2002 11:59 AM
To: Condit, Christopher
Subject: Re: Addressing problems using asm embedded in C
It's been many years since I did any assembly programing, but I seem
to recall that different assemblers would use a different syntax to
denote if the address or the contents of the address should be used.
Any chance that this explanation would apply?
From: http://www.cis.ohio-state.edu/~parent/classes/360/faq.html
Relocation Truncated to Fit
The problem is that if you have declared a label, say something like:
X: .word 20
Then in your code, suppose you say something like:
mov X, %r3
What you are trying to do is to copy the value in the word corresponding
to X into %r3; except the right way to do it is first get the address of X
into another register etc.
The reason why the assembler assembles this without complaint is thatthe
(unrelocated) address of X is typically small enough to fit in 13 bits
available in the mov instruction; so it assembles using that address. Then
the loader relocates the stuff and now the relocated address won't fit in
the 13 bits, so it `truncates the relocation to fit'.
Paul
On Wed, 24 Apr 2002, Condit, Christopher wrote:
Date: Wed, 24 Apr 2002 14:13:17 -0400
From: Condit, Christopher [EMAIL PROTECTED]
Reply-To: Linux on 390 Port [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Addressing problems using asm embedded in C
I'm trying to write some assembler embedded in C via __asm__
__volatile__().
A couple hundred lines or so. Compiler doesn't complain, but linker
gives
relocation truncated to fit errors on any instruction that refers to a
label (B's and EX's). I know that message usually (in C) means you are
calling an unknown function or else are branching too far. Neither of
these
conditions is the case, since I am only branching down a few bytes, and
I'm
not calling any functions by name. Total dll length is under 32K.
Fooling around, I note that by recoding to avoid using any labels (lots of
relative branching), I can eliminate the link time errors. So my linker
is
choking basically on all labels. Anybody know what's up, or what I can do
about it? Writing labelless code is not an appealing prospect.
TIA,
Christopher
Paul L. Rogers[EMAIL PROTECTED]
Are you prepared for NetDay? http://www.netday.org/
Linux: It works for me. http://www.linuxdoc.org/
Re: MTBF
David Boyes [EMAIL PROTECTED] wrote: On Mon, Apr 22, 2002 at 04:26:39PM -0500, Holly, Jason wrote: has anyone established mean-time-between-failure numbers for linux instances running under vm? anything general would be good information. i'm curious about disk, memory or other system failures that compromise the vm instances. The record for us is about 9 months for a single Linux image. Average is about 3-4 months between reboots, depending on what's running in them -- things that suck up lots of memory like Websphere tend to shorten the lifespan of the machine by fragmenting storage. Machines that get a lot of interactive use tend to collect a few zombies after a while, so reboots become a reasonably good idea after a while. I have to say that I'm a little surprised at that recommendation. Let me see if I understand... you're saying that you need to reboot your Linux images about every 9 months because the Linux virtual memory manager has issues? I hadn't heard that before... Seems like I've heard lots of tales of people with Linux up much longer than 9 months... doing web services, etc... do you think your 9 month figure is a function of the 390 version of Linux, or Linux in general? That is, would you recommend rebooting a PC version of Linux on the same interval (given the same workload?) We don't reboot our machines unless there is some configuration change... but, we don't do highly interactive things on them, just product builds every now-and-then. Also - just to ask - what about the BSD variants - would you also recommend 9 months for them? It's my understanding that the virtual memory manager in FreeBSD is better than Linux, for example, and perhaps might not suffer the fragmentation issues? [Of course, that may be a biased understanding... I have no evidence to back that up.] For the VM side, I know of sites with uptimes measured in years; Yes - this is much better! :-) And, I would expect it from Linux (even today's Linux) too... Could you relate more about this 9 month figure? Do you have specific instances where it was required, that you can share of course... - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: MTBF
The record for us is about 9 months for a single Linux image. Average is about 3-4 months between reboots, depending on what's running in them -- things that suck up lots of memory like Websphere tend to shorten the lifespan of the machine by fragmenting storage. Machines that get a lot of interactive use tend to collect a few zombies after a while, so reboots become a reasonably good idea after a while. I have to say that I'm a little surprised at that recommendation. No, THIS IS NOT A RECOMMENDATION. This is a descriptive observation. Ah - my fault - I didn't mean to mis-characterize your statements. My apologies. ... Sorry if the comment was confusing. I don't intend it to be a recommendation, just an observation of our experience. Your clarification helps a great deal! Many thanks! - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: LinuxWorld Article series
David Boyes [EMAIL PROTECTED] Although the article did have issues, I'm most disconcerted with some of the bang-per-buck comparisons (one of the charts showed a mid-range SUN performs at 300% that of the z/900 at only %18 of the cost... and that was a *mid-range* SUN!) He's comparing apples and Brazil nuts. It depends a lot on the application -- there are cases where the Sun is the right answer, many where it's not. You have to profile the application. Wonderful! I'd be very delighted to have someone set-me-straight on these points... If a mid-range SUN is only 18% of the cost of a (slower) mainframe, it will make selling mainframe Linux (vs. SUN Linux) a lot harder. Granted, the RAS facilities of the mainframe are nice, but for 18% of the cost... if you had to, you could buy 3 or 4 SUN boxes, keeping most of them in the closet as spares and still be cheaper. I would argue that the figures in the article do not include the whole picture. For a *single* application, he may be close. It's when you deploy application n+1 and n+2 that the difference/advantage becomes apparent. He's falling into the usual trap of doing TCOs based only on hardware price -- that isn't the whole story, and he's not including cost of operators, floor space, etc. Our studies indicate that the breakdown for TCO is nominally: 20-23% hw/sw cost 37% people remainder facilities (power, HVAC, floor space, network bandwidth, etc) It's kind of weird that people focus on the smallest portion of the problem while ignoring the other 70+% of the problem... Hmm... that could be very true... But - he's comparing one mid-range sun to one z/900. Seems like the 37% people and remainder facilities would be the same in both of those. One sun should be just about as much work/power as one z/900.. in fact, I'd expect one mid-range sun to be a little lower on the power/HVAC requirements. So - if we accept that, then really we're talking about %18 percent of that 20-23% hardware figure... right? I may be just a little slow on the up-take here, so bear with me while I walk through this... I _really_ want a nice compelling argument here. Let's say that the mainframe TCO costs $100. The hardware costs would be $20, the rest of the cost (the part that's the same between the alternatives) is then $80. So - the Sun box would be 18% of the z/900 hardware cost. Thus, if the z/900 TCO is $100, the Sun TCO would be $83.6 - a savings of 16.4%. Granted, a savings of 16.4% is much better than a savings of 82%, but 16.4% is still quite a significant savings. Am I understanding this correctly? Or, have I missed the boat somewhere? So - then the argument would be that for 16.4% more, you can get all of the RAS of z/900 hardware, vs. the mainframe box. Is that a fair statement? Please don't get me wrong - I'm a big proponent of Linux on the mainframe; our company has quite a substantial investment in seeing it succeed. I'm just trying to get together a fantastic response when asked the question myself, which does come up from time to time. What better place to get a reliable answer? Then, we need to understand (and address?) performance concerns. This was all under the assumption that the z/900 runs as fast, and hopefully faster, than the mid-range Sun. And, with this back-of-the-napkin calculation, there are several other issues to consider (virtualization technology for one.) And, as you mention, this ignores the very good point regarding testing your application in the environment. - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: LinuxWorld Article series
Bernd Oppolzer [EMAIL PROTECTED] wrote: By the way: most of the new development on IBM systems (for example LE) is done in C, as you can see by looking at the LE modules. C is not very widely used by IBM customers; there are only few large companies in germany using C/370 for mission-critical apps. But I have the impression that an increasing part of system-related development for mainframes is done in C, by IBM and others. The guy who wrote the article has never heard of this, I guess. C is simple, working, portable, great fun (personal opinion). Regards Bernd Well... not to be too advertisy, but we can certainly give you many examples of people using C and C++ for mainframe development, on various operating systems. See http://www.dignus.com for more info. But - to offer my take on the article - and this is only my opinion Although the article did have issues, I'm most disconcerted with some of the bang-per-buck comparisons (one of the charts showed a mid-range SUN performs at 300% that of the z/900 at only %18 of the cost... and that was a *mid-range* SUN!) You really have to get past the history stuff (just skip through it, most of the people here already know the history) to get at the point of the article. The point, to me, seems to be the Linux on the mainframe didn't make sense because a) it ran too slow, and b) the hardware/software was too expensive. These are quite significant allegations - which I hope someone (IBM?) will spend the time/effort to refute, or at least address in future hardware. If a mid-range SUN is only 18% of the cost of a (slower) mainframe, it will make selling mainframe Linux (vs. SUN Linux) a lot harder. Granted, the RAS facilities of the mainframe are nice, but for 18% of the cost... if you had to, you could buy 3 or 4 SUN boxes, keeping most of them in the closet as spares and still be cheaper. Now - that's what I got from the article - I have absolutely no idea if these numbers are correct... I certainly hope there was significant room for error... and that someone will correct the impression. I'm also interested in seeing the bonnie and bonnie++ results. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com There is a lot of stuff bubbling around in IBM also. They have some top guys working on NUMA machines that are regularly collaberating (sending code to) the Linux kernel development tree. john alvord
Re: Bogomips S390(IFL) / Intel
Philipp Knirsch [EMAIL PROTECTED] Moloko Monyepao wrote: I RedHat 7.2 (Server Installation). I am currentely testing sendmail (Comparing the load handling between Linux on Intel and Linux on S390. I am using an IBM z37 machine with one IFL and I gave my Linux LPar 80Pwt (processor weighting on the IFL) When the sever gets too busy start rejecting messages. Just for outbount mail and I also want to test for both Inbound/Outbound. What could be the problem here. I will send any further information if it is needed. The following is what I got from my mail administrator. This is the BogoMips rating for the various machines: Mainframe: 326.04 BogoMIPS (Mainframe) Maggie (mail-spool, 500Mhz): 996.14 (Intel) 500meg (processor) Higher is better, BogoMIPS should also be generic across platforms. BogoMIPS is a fairly useless speed rating for the system, especially if you even start to try to use it to compare different archs. Better use some 'real' benchmarks, e.g simple ones like dhrystone or similar... Also - your choice of compiler might make a difference (though, probably not in the case of a mail server... which I can imagine is I/O bound.) For example, Systems/C on Linux390 typically presents values that are up to 20% faster than gcc for these other tests. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Big Blue Smoke
[EMAIL PROTECTED] wrote Can anyone do the necessary dig/nslookup to see who really is behind this site: http://www.bigbluesmoke.com;. Here's the answers from here - first an nslookup, then a dig -x. - Dave Rivers - [dignus.com]$ nslookup www.bigbluesmoke.com Server: dignus.com Address: xx.x.x.x Non-authoritative answer: Name:www.bigbluesmoke.com Address: 64.124.140.188 [dignus.com]$ dig -x 64.124.140.188 ; DiG 8.3 -x ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; 188.140.124.64.in-addr.arpa, type = ANY, class = IN ;; ANSWER SECTION: 188.140.124.64.in-addr.arpa. 23h59m25s IN PTR 64.124.140.188.sun.com. ;; AUTHORITY SECTION: 140.124.64.in-addr.arpa. 23h59m25s IN NS ns.above.net. 140.124.64.in-addr.arpa. 23h59m25s IN NS ns3.above.net. ;; ADDITIONAL SECTION: ns.above.net.13h17m36s IN A 207.126.96.162 ns3.above.net. 13h17m36s IN A 207.126.105.146 ;; Total query time: 2 msec ;; FROM: .dignus.com to SERVER: default -- xx.x.x.x ;; WHEN: Fri Mar 15 14:59:34 2002 ;; MSG SIZE sent: 45 rcvd: 157 -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: Porting Large S/390 Assembler Applications
See below... David Boyes [EMAIL PROTECTED] wrote: My question is if it is easy, difficult or impossible to port large existing S/390 applications written in assembler to run under LINUX on a 390 or z/series platform? I am not talking about a batch application but about a server type application that currently uses S/390 facilities and operating system services such as TCP/IP Socket APIs, multi-tasking and Data Spaces. This will be quite difficult. Most of the APIs either don't exist or are quite different, multitasking will need to be restructured, and Linux doesn't know anything about data spaces. You'll effectively need to restructure most of the critical sections of the application (if not the whole application), and at that point, you're better off switching to a higher-level language such as C and starting over, taking advantage of the Linux APIs. If you're considering possibilities - let me suggest working through a rewrite of your application with Systems/C. Systems/C will allow a function-by-function rewrite (Systems/C can use your own assembler entry/exit macros, etc...) Then, you have a nice migration path to move an existing application to C. When that is done, and the application operates exactly the same (on OS/390) as it did before. You'll have a much better chance of moving it to Linux/390. Also - Systems/C (and Systems/C++) are the first commercial C/C++ compilers for Linux/390. In some tests, Systems/C generated code that ran 20% faster than the gnu compiler's code. Have other S/390 software vendors ported assembler products of this complexity or is the effort so large as to not be feasible?. See above. Unix applications are pretty easy; this stuff won't be. A very true statement! - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Using Linux/390 to build OS/390 programs.
Just thought this might be appealing to some people on this list. See the IBM Solution Vendor of the month article: http://www-1.ibm.com/servers/eserver/zseries/solutions/s390da/ - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
