|
>Yes and the single level store is something I have been trying to wrap my >mind around. Is there a white paper or patent document that states what it >really is. I would imagine that the service program's image would have to be >mapped into the process's memory space.. >Thanks for the correction! >Eric Wilson Eric Real quick, and I don't mean this to be a NET (the Thread version of a NEP if you know what that is) Single Level Store, Every object created on the AS/400 will only have One address space assigned to it(at creation) for its life. Actually longer. If you call a Program, (etc any object) and I call that same program a second later we will both "Branch to / be resolved to " the very same virtual address. We will have our own variables unique to our job, but the object code of the program itself - will be shared by all processes on the machine. So Service programs and regular old dynamic calls to programs (if they are used by lots of people) may indeed be resident in memory all day long after the first call. So after the first call, no one else will incur the bring from Dasd cost. Same is true for files, until the last person on the machine using that file closes it, its structure is in memory. Above I said "actually longer" because unlike most every other virtual machine(mainframes etc.) where the virtual address space is carved up at IPL, our machine has persistence in its truest form. Machine on, machine off, the object has the same address. Now, When you destroy an object(DLTPGM, etc) Those virtual addresses for that object will never be assigned again. They will be "tagged" as invalid. Some of the "Viruses" on other machines where one process gets the handle for an address space, hold it, and another process(or same) destroys that object, You have control over that address space and you can do harm. Ah, you can't do that here. So, Thoses dynamic calls (with *INLR left *OFF) might not be that bad if you "Design In" object code sharing when designing at a System level. End of lession, John Carr (Classes by Powertech visit www.400school.com) +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.