WITH message^Paul.Robinson DO BEGIN
Mark Morgan LLoyd wrote: > I've got reservations because of the EBCDIC issue. That's not a problem. You write a program on the 370, the machine does the internal conversion. Most people never notice the difference. The standard characters are the same in all versions of EBCDIC, the conversions for A-Z, a-z, 0-9, space and most symbols @!#$&*()-+ etc. are pretty much cut and dried. I actually wrote an ASCII <- ->EBCDIC conversion to be able to view some text files from a mainframe PDS (their version of unix's tarball files) in order to understand what is going on. > I'm sure Paul has his reasons that we all need to respect, but I don't think > that using > a 370 emulator (i.e. at least two architectures out of date) plus an obsolete > operating > system is the place to start. Again, I have to target what I know. A program written for the 370 will run on a 390. Having gotten the simpler version up and running, I can put other things in place and potentially add hooks later. If I have to learn the extensions for the 390 and how Linux/370 works, well, I guess I can probably add another 2 years on top of the conversion. I'd like potentially to see something running by Summer 2012, just in case Michel Nostradamus and the Aztecs were interpreted correctly and there'll be no tomorrow on December 22! (I'm going to be real upset if that happens, I just bought a five-year extension on my Magic Jack phone service before the price goes up.) > I admit to having considered this as a long-term project, but > what I don't have is a good understanding of the architecture's > assembler-level programming. I've been updating the Wikibook (another one of Wikipedia's projects) on IBM 370-series assembler, just to remind myself of what was involved and to keep my skills sharp. Having gotten back into this I'm starting to remember things I'd forgotten. > However I think I need to make the general point here that > "IBM Assembler" is understood in the industry to encompass > that which is needed to write application-level programs in > CISC assembler plus macro support etc.), and that even > somebody skilled in that particular black art might need to > enter unfamiliar territory when it comes to the operations > required by a compiler's code generation (e.g. commercial > programming doesn't do large amounts of stack-relative addressing). They didn't tell us that at the time, but a lot of people did and didn't realize it. By convention, Register 13 is used by a called program as a save area to store the user's registers. If you're a subroutine (or if you prefer, you wrote a subroutine or wrote your program so that it would operate as one) the caller hands you R13 with an address of a 72-byte save area to store a spare word (used by Fortran and PL/I), plus all of the registers in the order 13-15 and 0-12 so you can return them as they were given to you and you don't have to worry about how you use them. So what some people did was use the register version of the OS/VS1 GETMAIN macro, which tells the operating system to return a block of storage space in register 1. Then they'd save the current value of register 13 at address 4 in this block, then put the block's address in R13. Just like doing a linked list. Now you have a place for any routines you might call to store your registers, plus, if you store your variables as offsets in register 13, you've created a stack to put your variables on and your program, since it uses no local writable memory, is fully reentrant and position independent. So you got it, you got a stack, reentrancy and PIC all for free and most of us who wrote code doing it that way never even knew it. Tomas Hajny wrote: > Still, starting with the Linux for S/390 (or are S/390 and S/370 completely > different animals?) Similar to the differences between Pentium and IAS-64, the 390 is a 64-bit version of the 370. > probably a very good idea to avoid having to tackle both a different HW > platform and > a different OS at the same time (the Linux port to S/390 apparently uses > ASCII > according to what I found on Internet). Obviously, the OS may follow once the > new HW platform is in working state. I may take a look at it, but I figured getting a Linux port was a substantial amount of work I didn't want to do right now; I have code I can use for the OS target I am using, I can know if it works or know why it doesn't. Not so for the 390 or for Linux. I can, conceivably include it as an option with it stubbed for the moment, then as I figure out how to implement the interface to it I can. Michael Schnell wrote: > As for using Linux: I have no idea how this works in practice, so I can't > comment on that. Which more-or-less makes two of us. > I know that people here use Hercules inside linux to > develop for zSeries, but then again running a linux > inside that seems a bit like overkill I would disagree, it's available, its standard, and thus it allows you to test programs which might otherwise run on a mainframe on your PC. I mean, IBM ran a commercial a few years ago where someone thought they had been robbed, when racks and racks of servers were replaced by a single IBM zSystem mainframe about the size of one server rack. If you spend, oh say US$200,000 on a single computer, as opposed to spending $300,000 or more to put up 1,000 servers, you might find that the architecture provides better results where it's optimized. Mainframes did very well on block I/O in that respect, and most data transfers on the internet are block I/O, e.g. web pages, data files and other resources. They suck on character I/O which is why terminals are always connected as block devices; you'd never have single character at a time or mouse controlled apps running on a 370. They shine with large volumes of data and transaction processing using blocks at a time. I've heard on a real zSystem you can run something like 22,000 virtual Linux sessions before the underlying VM partition ran out of resources. Which implies that one zSystem could conceivably handle the load of 22,000 servers. Plus you can't infect one the way you can to a microcomputer. You can do a tremendous amount of things running as a non-privileged user, moreso than on, say Linux, because you can decide to let it be able to do some things and implement supervisor calls where it needs to access privileged functions. So, first, your average random J hacker isn't going to know mainframe assembly language to even be able to inject code to pown someone's box, if a program has an error that allows someone to exploit a buffer overflow, most likely the process running that web server crashes and is restarted, they do not get the ability to do shell access (because there might not even be shell access if a web server is marked as being like a non-interactive task) and it's never running as a privileged task so it has no privileges an attacker can steal. The Lessons of history teach us - if they teach us anything - that no one learns the lessons that history teaches us. END . _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
