You know......right after I wrote this, it occurred to me that Tony G. could put a call to NEWPCODE inside of the processes that are running, so that at THE APPROPRIATE POINT the code could actually check to see if there was a new version of the subroutine (via a flag in a file) and if so, force a NEWPCODE of a subroutine.
This would need to be done from the MAIN program that called the subroutine, not the subroutine itself. Each process could post to the flag, it's port number so that each process would only do this once. This way, when the calling program called the subroutine, it would be the new version, instead of the old version. Gosh, that's a bit of an inspiration, eh? I would not try this in a production env until I had tested the heck out of it!!!!!!!!! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Allen E. Elwood (CA) Sent: Friday, September 03, 2004 12:08 To: [EMAIL PROTECTED] Subject: RE: [U2] Unidata shared memory and catalogs Yep, I got NEWPCODE on my TCL manager as well. Works great for current process, without shoving new code into everyone else's memory space. So, if you ask me, this is a FEATURE not a bug! I would never even think about trying to force new code into a currently running process. Just the thought of what could go wrong boggles the mind! At what point would this occur? What if the program was currently in the middle of a loop and got overwritten with new code that didn't even have that loop? What if it was in the middle of a FILE I/O statement and had priority control of the system and never released it? The permutations are too many to even try to ponder. Us old farts have the battle scars to prove that taking a chance is not a wise choice, and the fact that U2 won't do this no matter what you try says something as well ! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ian McGowan Sent: Friday, September 03, 2004 10:13 To: '[EMAIL PROTECTED]' Subject: RE: [U2] Unidata shared memory and catalogs > From: Richard Sammartino [mailto:[EMAIL PROTECTED] > Tony, I have experienced the same issues and I don't think there is a > solution. Our menu is a cataloged program which chains or > executes other cataloged programs. I don't know about the performance impact, but a TCL stacker program has the same problem. I do an EXECUTE 'NEWPCODE' after compiling a program to get the 'refreshed' version available immedidately. As others have noted, this works only for the process executing the command. As for the wisdom of the Unidata developers, I have to say it's better than working on old PICK systems where compiling a new version of a program or subroutine would cause anyone running that routine to bomb out to the debugger. I have vivid memories of an error routine that used TIME() as part of the key, and therefore had to loop doing READU's to make sure the key was not in use. I.e it could only write one error log per second. One inventory weekend, at 10pm on Saturday, calculating how long it was going to take to finish returned 5 days! Changing the routine to use a sequential key was quick, but recompiling it live, knowing that if the timing was wrong we'd have to restore to Friday's backup and start over was nerve wracking to say the least :-) This was Ultimate on an IBM 3090. Is today old fart's memorial day or something? ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
