I was actually thinking of my personal memory about UniData problems reported 
these past 21 years.

Bill said his programs were CATALOG ... DIRECT - so unless he places his source 
files under UDTHOME\sys\CTLG - his object code is not managed by sbcs or stored 
in shared memory. Each udt process will have to malloc private memory to load 
all of the objects it runs.

Each time he starts a new udt process and runs the problem program, that object 
code is read from disk and loaded into private process memory. There isn't any 
cache or such for this application setup.

Wally Terhune
U2 Support Architect
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
Tel: +1.720.475.8055
Email: wterh...@rs.com
Web: www.rocketsoftware.com/u2




-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wols Lists
Sent: Wednesday, December 21, 2011 1:54 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UD] Corrupted compiled code

On 21/12/11 17:38, Wally Terhune wrote:
> Though I have to agree with Bob Wyatt: "memory seems to get cheaper 
> and less reliable as it ages" :-(
>
I was thinking memory ... possibly bad?

Does Unidata store its programs in shared memory? Could the memory have got 
corrupted and it takes a recompile to move it and reset it? Long shot I know, 
but stranger things have happened (and as memory gets faster and the lines get 
narrower, random corruption gets more likely).

Cheers,
Wol
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to