|
Now if the AS/400 runs out of RAM for processing the current workload then various pages will be swapped out to disk... All in all very much similar to VAX/UNIX/Windoz. What I am trying to figure out is the difference between the other OS's and the AS/400. BTW NEP = Never Ending Program MRT = Multiple Request Terminal, VTAM = Virtual Terminal Access Method. :-) ______________________________________________ Eric N. Wilson President Doulos Software & Computer Services 2913 N Alder St Tacoma WA 98407 ----- Original Message ----- From: John P Carr <jpcarr@tredegar.com> To: RPG400-L <RPG400-L@midrange.com> Sent: Thursday, September 09, 1999 4:50 AM Subject: Re: Efficiency of Bound vs. Dynamic Calls > > > >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 > +--- +--- | 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-2025 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.