|
Yikes! You mean there's no such thing as a segfault in i5/OS?!
There are errors that are similar to a segfault, yes. But the way i5/OS deals with memory is very different than just about any other operating system because of the single-level store paradigm.
In Windows and Unix systems, for example, a pointer is just a number. In OS/400, there are different types of pointers for pointing to different types of things, and they're not just numbers -- they're more like data structures, in fact. They contain security information and other things in addition to the actual numeric offset.
The idea behind a single-level store is that all memory and disk on the whole system can be addressed with a pointer. It's all one big address space. Within each object you point to, there's an offset. If you try to refer to an offset that's past the end of the object, you'd get an error. (Just by setting the pointer to it! You don't even have to try to use the pointer...) Likewise, there's authority considerations, if you try to set the pointer to something you don't have permissions to, you'll get an error. There are protected spots in memory that if you try to set a pointer to them, you'll get an error. So there are lots of things that are like a segfault, but nothing exactly the same.
One of the biggest differences between i5/OS and Unix is that in Unix each program typically runs in a different process. On the other hand, in i5/OS, the same "job" is reused over and over again for the next prgoram that's run. Since there's no process boundary, you can potentially resolve a pointer to the data of another program and corrupt it. On the other hand, you can't muck with the actual code of the other program, since that requires a completely different type of pointer! :)
Anyway, an e-mail message isn't a good place to explain the whole inner workings of OS/400 :) If you're really interested in that, I suggest going to http://iSeries400.org and buying the eBook that Leif is/was writing. You'll learn a lot about how i5/OS works.
For the sake of this discussion, the important bit is that you pass the same size variable as the API requires. Do it right, and your programs will be forward-compatible.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
