Re: compile+link Fujitsu Linux
- From: Robert <no@xxxxxx>
- Date: Thu, 07 Feb 2008 20:55:26 -0600
On Wed, 6 Feb 2008 20:45:53 -0800 (PST), Richard <riplin@xxxxxxxxxxxx> wrote:
On Feb 7, 4:06 pm, Robert <n...@xxxxxx> wrote:
On Wed, 6 Feb 2008 00:34:14 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:
On Feb 6, 7:39 pm, Robert <n...@xxxxxx> wrote:
I don't know how you manage to make stuff go missing, but it just
doesn't happen to me.
We frequently build new environments. Populating them is controlled by component lists,
we don't just cp *. New files can be missing from the list. Files thought to be obsolete
might still be in use.
Well actually I can see that if you fail to include a program in the
list to be put in the library (by screwing up the editing), then
overwriting the previous library will make that program fail to be
CALLed, but the startup found the library OK.
Startup doesn't just check for the library's existance, it resolves all externs.
That requires all CALLs to be CALL literal.
That's the simplest way. Alternatively, you can list the symbols following -u. After the
first link, you can use the previous generation's symbol table as an --auxiliary.
But you don't test the libraries so you wouldn't notice that until the
batch run failed halfway through when it tried to CALL what is now
missing.
We check batch jobs hours BEFORE they are run, by executing ldd. If there is going to be a
problem, we fix it BEFORE the job starts, or change the schedule. The Unix loader checks
again at startup time.
Dynamic loading is the only way a program can fail halfway through. That's why it is not
THE NORM.
But my applications don't 'fail'.
If I ran batch programs then I might care about that problem.
Obviously you have set up your runs of ldd because reliability has
been a problem in the past (as you discussed previously), yet you
claim 'more reliable'.
That's like saying locking your door is proof you've been burglarized in the past; I don't
have to lock my door because I've never burglarized. Therefore, my home is more secure
than yours.
Changes in one program can't cause errors in other programs unless they share global data.
Or data in parameters to the CALL of that program or in CALLs that
program makes.
That's global data, which is bad practice.
Excuse me, but parameters to a CALL are now 'global data' ?
If you pass a structure to program A (by reference) and then pass the same structure to
program B, that structure is global data. The scope of the globe may be smaller than other
globes.
I'll also mention to OO users that 'object data' should not be used
because it is 'global' to the methods.
Object data is local to the object instance or class. OO was created to get away from
sharing data between 'programs'. The word is encapsulation.
And in an application there is usually an 'Application class', the
object of which holds the application object data, or interfaces to
objects holding it, which may need to be accessed by some of the other
objects within the application.
Only the top program should have update permission on the application class. Others should
read individual fields, not the whole structure, through their individual methods.
If you pass the whole structure to every program, that structure is global data, which is
anethma to OO principles.
Each object in the application has its own object data which may
correspond to W-S in sub-programs (ie it is encapsulated). Methods in
the objects may use getters and setters to the application data or may
access the application attributes directly via the object pointer
(depending on language).
In fact the way that OO works in Cobol is that the methods are nested
programs and the object data is GLOBAL in the object's W-S (without
the need for the GLOBAL keyword).
I'm not worried about methods of the class, I'm saying methods in other classes shouldn't
be able to see the whole structure, and all setting should be done in one place.
.
- Follow-Ups:
- Re: compile+link Fujitsu Linux
- From: Richard
- Re: compile+link Fujitsu Linux
- References:
- Re: compile+link Fujitsu Linux
- From: Robert
- Re: compile+link Fujitsu Linux
- From: Richard
- Re: compile+link Fujitsu Linux
- From: Robert
- Re: compile+link Fujitsu Linux
- From: Richard
- Re: compile+link Fujitsu Linux
- From: Robert
- Re: compile+link Fujitsu Linux
- From: Richard
- Re: compile+link Fujitsu Linux
- From: Robert
- Re: compile+link Fujitsu Linux
- From: Richard
- Re: compile+link Fujitsu Linux
- Prev by Date: Re: compile+link Fujitsu Linux
- Next by Date: Re: You know you're a Christina when .. (was: OT: Racial superiority / Intelligent design was Re: OT:Thanksgiving
- Previous by thread: Re: compile+link Fujitsu Linux
- Next by thread: Re: compile+link Fujitsu Linux
- Index(es):
Relevant Pages
|