Re: compile+link Fujitsu Linux

On Feb 3, 3:31 pm, Robert <n...@xxxxxx> wrote:
On Fri, 1 Feb 2008 12:58:23 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:
On Feb 1, 7:49 pm, Robert <n...@xxxxxx> wrote:
On Thu, 31 Jan 2008 20:41:29 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:
Fujitsu's terminology is pretty
good:

static linking Old School, everything in one executable

Not 'Old School' at all. Old School would be trying to fit everything
in 640Kb, or even 64Kb of CP/M.

That's why CANCEL was created.

dynamic program structure Unix style libraries linked with -l

And the objects are loaded (statically) at start up time, though the
CALLs are not necessarily linked to the routines.

Loading at start up time is faster and safer.

That is your opinion. It doesn't agree with mine at all, and I have
been using dynamic load when required for some some decades.

You can specify -z lazyload to make it load
libraries when first called.

It may be that for a batch run checking that all required modules are
available at start-up would be useful. However, for an interactive
system with several applications and many modules it would be _slower_
on start up to load all modules simply because many will not be run on
any particular day.

As for 'safer', you have that completely wrong, too. If a particular
module is missing then it would prevent anyone doing anything if the
startup failed because of that, but it may be a module that is not
actually required that day.

As I never have had an issue where any system was 'unsafe' because I
had separate dynamic loaded programs then I can't see how you can
claim 'safer' than that.

dynamic link structure Cobol style Load On Demand

Exactly, they are _loaded_ dynamically. The requirement was stated as
being the last: "dynamic linkage" which does dynamic loading. You
should have noticed that the DLOAD directive was used and thus the -l
was inappropriate (see table in manual).

Fujitsu works with DLOAD and dynamic program structure, because dlopen() finds programs
already resident. If the program is NOT resident then it loads from disk. The only
downside is Fujitsu will not CANCEL programs bound at start up time.


No. The downside is that the user has to completely close the
application, update the libraries, and then restart the application if
a new program, or an updated one, or a one-off, is required.

If it is Windows then the library cannot be replaced until all users
have closed the application because you cannot overwrite an open file.

With dynamic loading, and a suitable framework in place (which I had
developed many years ago), it is only necessary to drop the new
program in and select it.


If any cannot
be found, the program will not start, which guarantees the program will not abort mid-run
because a called program is missing.

The CALL can check whether it has failed to find the program with an
ON EXCEPTION, or it can be checked for in other ways, there is no need
for the program to abort.

True. How many programs have a graceful fallback? Ok, if called from a menu, they say
'Function not available'.

It would seem to me that Charles' programs may well form an
interactive menu driven application. Gracefull fallback is what these
systems should do.

Makes you wonder why they didn't grey it out.

Perhaps because that would require searching the disk every time the
menu is displayed.

In Micro Focus, one can say SET procedure-pointer TO ENTRY 'MYPROG1'.
If the pointer is null, the program doesn't exist.
Cobol doesn't allow definition of weak externs, so you can either tell ld -z nodefs to
allow undefined symbols, or put MYPROG1 in a variable.

Actually in MF Cobol since Level II there is a special CALL x"91"
function 15 that will tell you if the program exists.

Fujitsu has no equivalent feature. You'd have to call all programs at initialization time
and remember which are invalid.

No, I don't have to do that, I have the menu program tell the user if
a program is unavailable when they actually try to run it.


The problem with dynamic binding in Cobol is that Cobol has no concept of library FILE
NAME, it only knows about entry point names, which are essentially the same as program
names. Thus, Charles' application with "hundreds of COBOL programs", if packaged for
dynamic call, will have HUNDREDS OF LIBRARY FILES, each named libPROGRAM.so.

I am not sure why you think that is a 'problem'.

It is not a problem to me at all, nor to any of my clients.

It complicates deployment, makes the system less reliable and slows execution.

What _evidence_, other than 'researching your keyboard', can you
provide for these unsupported assertions. Certainly a dynamic load
takes a few milliseconds when a menu item is selected, but in what way
would it be 'less reliable' ?

There are more files that can be deleted or overwritten.

As I have never had a program file "overwritten or deleted" then no
other mechanism can be 'more reliable'. If you do have a library file
deleted then with your mechanism _no_one_ can do anything with the
system because it fails to load up at all (according to what you have
said).

With my system if a file is deleted or overwritten then unless it is
one of a small number of essential core modules the applications will
run, but possibly one or more modules could become unavailable. Of
course it is possible that module is not required at that time anyway.

How do _you_ measure reliability ? Let us say one file has been
deleted:

a) NOTHING WORKS AT ALL until the programmer fixes the problem.

b) Applications function as normal except one module is unavailable
(which may not be required)

I would say the b) would rate as 'more reliable'.


Actually, to those that use this, it _simplifies_ deployment,
especially in bespoke systems where I operate. If a single program
requires changes then only that file is tested and redistributed. In
any rational development all deployments would be fully tested. If you
link several programs into one library the all those in the library
need to be retested. If they are all linked to one executable then
everything needs to be retested.

There is no reason to re-test an unchanged program just because it is in the same library
with other programs.

Yes, there is. Any program that is re-issued must pass testing. It may
be that other programs in that library have been modified (by someone
else) but are not completed and ready for distribution.

If you lump a dozen programs into a library then you need to re-test
and re-issue those dozen.

In fact that is a point against using a library if you are not
retesting because there is a risk that may affect the system's
reliability.

You could use the same argument to require re-testing every
application on the machine.

Why ? Are you re-issuing new versions of every application ?


Changes in one program can't cause errors in other programs unless they share global data.

You are changing one program and then collecting a dozen, or several
dozen into one library file and re-issuing it. How do you ensure that
the other dozens have not been changed but are not ready for issuing
yet ?

In a rational environment, data is shared between parent and child, not between siblings
and certainly not with stranger programs. You should never make a decision in program A,
store it in an indicator or database, and take action on that decision in program B.
That's bad design.

Why are you talking irrelevancies here ? You are just making up straw
men.

If you DO make that mistake, putting programs A and B in separate files is no more
protection than putting them in the same library. Even running them on separate machines,
as remote procedures, is no protection.

And the CALL dataname feature is invaluable as it means that the menu
program can use a data file to define what is available in a
particular application, or even to the particular user, and this can
be extended by changing the data file (and issuing the programs)
without changing the menu program at all.

Now you're advocating home-grown security. I've seen hundreds of home-grown security
systems and not one of them was secure. Most can be defeated by editing a cleartext
database or text file.

'Home-grown' or application security does not prevent other security
systems being used. In fact having each program separately in its own
file can be used to give greater granularity to the security.

In any case, in my systems, users don't have access to the application
security files except by running the application control system and
that is protected. And, no, they can't just edit a text file.

So you are inventing straw man arguments yet again.

If I want some programs, such as month end, to be entirely secure I
can make put them in a special group and only have specific users in
that group. Make them readable by that group only and no one else can
run them even if they break the application security.

With your mechanism:

1) You would have to make the whole library special group only (OK so
you could reorganize and re-issue).

2) the application would fail to start for everyone else because the
library was unavailable.

But thank you for pointing out yet another advantage of how I do the
systems.


In any case, this is irrelevant to program load mechanism. The same bad security will work
with dynamic program structure.

Where did the 'bad security' come from ? Oh, I know, you made that up.


'One off' or special programs can be deployed individually and
executed with the application framework by typing their name into the
menu program (given that the user has adequate permissions), there is
no need to redeploy the whole system.

Create a few dummy 'stub' programs for this purpose. Or use versioning, so ONEOFF 1.1 does
one repair and ONEOFF 1.2 does another. See documentation for dlvsym().

I am quite happy with the way the system works, why are you attempting
to impose your unrequired ideas on my systems when there is no problem
at all ?


As you should be able to tell from the results in charles' 2nd message
your BAD and WRONG advice has meant that his program does not work as
he expected. He statically linked the dynamic library which will cause
the CANCEL to fail to unload it and thus a reload does not find a new
copy but reuses the old.

Wrong. If Cobol issues a dlclose() on libMYSUB1.so, even though it was 'statically' linked
with -l, it will be unloaded .. and reloaded the next time he calls it.

Charles results and my testing show that you are WONG once again.

I said IF Cobol issues a dlclose(). Fujitsu does not. It could.

So, you would agree that your 'Wrong' was Wrong then. Charles and I
both described the results of testing. You said this was 'wrong' on
the basis that it _could_ have been different if Fujitsu did it
differently, but they don't.

I'll give you that win. A hardcore programmer would do it by calling dlclose() and
dlopen() directly from Cobol. :)

So the score remains at about 10 to nothing then ?

.

Relevant Pages

  • Re: compile+link Fujitsu Linux
    ... I wasn't trying to change your way of doing things, I was answering Charles' question. ... Charles was unfamiliar with Fujitsu on Unix. ... libraries was 'more secure'. ... YOU introduced application security, not I. ...
    (comp.lang.cobol)
  • [UNIX] XDR Integer Overflow (Additional Details)
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... were discovered in these libraries during the testing of new Retina ... locally audit applications for the existence of common vulnerabilities. ...
    (Securiteam)
  • Re: compile+link Fujitsu Linux
    ... been using dynamic load when required for some some decades. ... libraries when first called. ... file can be used to give greater granularity to the security. ... mechanism _couldn't_ use the unix file system security because it ...
    (comp.lang.cobol)
  • Re: managed string library
    ... respective libraries as well. ... more focussed on functionality and ease of use or "Software Crisis" ... Another security issue is the question of auditing. ... code of Bstrlib) and 2) verifying that the facilities claimed are ...
    (comp.lang.c.moderated)
  • SSRT2336 Rev.5 XDR library
    ... Source: HEWLETT-PACKARD COMPANY ... SECURITY BULLETIN: HPSBUX0209-215 ... --> Install PHCO_28128 or subsequent for B.10.26 ... certain implementations of XDR libraries. ...
    (comp.security.misc)