Re: Efficiency of Bound vs. Dynamic Calls

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
+---