Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!amdahl!kim From: kim@amdahl.uts.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga.tech Subject: Re: REZ questions. Message-ID: <28373@amdahl.uts.amdahl.com> Date: 16 Apr 88 01:52:56 GMT References: Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 54 In article , mp1u+@andrew.cmu.edu (Michael Portuesi) writes: > > I tried out REZ, and installed the big blob of commands I normally make > resident. They installed fine, but I was shocked to find that I still had to > have my Workbench disk in the drive so that the CLI could search for the > resident commands! Hmmmmm ... I've been using REZ for awhile, but haven't noticed this since the commands that I tell REZ to rez are sitting in vd0: (REZ is still "on trial" with me, so I haven't changed my environment around to take full advantage of it yet). Anyway, let me make a SWAG at your problem ... When you issue the command "rez foo" (or "rez -a foo"), REZ only adds the command to it's list of things you want to be made resident (in this case, "foo"). It doesn't actually load them at this point, but waits until the first time you actually issue the command (foo) to work it's magic. Hence, the *first* time you *use* one of the commands in your "blob", REZ checks it's list and sees that although the command is on the rez-list, it hasn't been loaded yet, and allows the path search to proceed. Assuming the command was found, it gets loaded (and executed), but is only *now* actually resident. Subsequent invocations for that particular command won't result in such a search, and will use the resident copy (dunno, if this is true if the code isn't sharable, and another copy of the code is already running). There is another command-line option for REZ ... -l, as I recall ... that causes the command(s) to also be loaded *now*. (I haven't used -l yet, but I think that's correct.) So try something like "rez -l glop1 glop2 ...", and see if that doesn't takes care of things. If not, then I must not understand your problem. BTW, you really ought to blow-off all that BCPL junk, and start using the ARP equivalents. Backwardly compatible, smaller, faster, and also provide additional functionality! Strangely enough, the hueristics Jim is using to guess at what "type" of code a command is (for informational purposes only), still think the ARP commands are from BCPL; other assembly language programs get flagged as Lattice 4.0 (as do several programs compiled with Manx ... :-) ). /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25