jBASE RUN -- bizzarity

[s7bd]

So, we're playing with jBASE 4 and we've become accustomed to jBASE
just taking a RUN FILENAME PROGRAMNAME directive, tossing the FILENAME
and linking the PROGRAMNAME that was first in path. Fine, it's not
Pick but it makes sense. Many of our customers do this kind of stuff.

So, now someone at jBASE appears to have changed things in jBASE 4.
Now, if you try to RUN as above (even if you are just a user) and the
code hasn't yet been compiled, it tries to compile it for you by
placing executable code in your SOURCE directory or file. Now, I'm
not a security guru it seems to me that it's a really bad idea because
if a user RUNs a program that has not been compiled:

1) the source dir has to have execute permissions
2) users have to have read/write privileges to the source
3) users have to have access to source at all

Does somebody out there think this is a good idea?

We've gone another direction by writing our own BASIC, CATALOG and RUN
front-ends. Our BASIC creates binaries in a bin directory associated
with each source file. Only developers have permission to the source
and have access to this bin. These bins are not in path. If you want
the program to be cataloged and in path, you use our CATALOG front end
which writes a symlink into the jbcdev_bin. Now, the system works
like Pick and you don't have to give end-users access to source. You
only have to catalog a program once (just like Reality) and if you re-
BASIC the source, the private bin is overwritten and all symlinks
referencing it get the update (just like Pick). It's simple to setup
and requires zero admin. We also added a global catalog feature that
works like uniVerse and that too is simple and zero maint. Lastly, we
don't have issues with executing a bin in directory A then losing
source reference when we call a subroutine in a different source
file. It's nice for developers to not have to have the jBASE debugger
load source automatically as you enter an exit new objects.

Offered it to Temenos and they weren't interested.

-BD

[Daniel Klein]

Yes, RUN was changed on 4.1 but jBASE does not compile code automatically. The RUN command is ineffective unless it can find a .o (or .obj) file in the same directory that PROGRAMNAME is in, which means it had to be compiled in the first place in order to be RUN.

This RUN behavior can be circumvented by creating a 'FILENAME,OBJECT' data section, eg:

CREATE-FILE DATA FILENAME,OBJECT TYPE=UD

or

mkdir FILENAME]MOBJECT

Now when PROGRAMNAME is compiled, it will place all object code in the new 'data' section', thus maintaining your security on source code.

This of course means you can do:

RUN FILENAME,OBJECT PROGRAMNAME

without having previously CATALOG'd the program.

Using this scheme we behave very similar to legacy MV applications, ie a user can edit, BASIC and then RUN a program without having to CATALOG it.

Note that FILENAME should be a directory, not a hashed file.

Dan

[s7bd]

Thanks Dan:
If you don't create the MOBJECT dir:
1) What will the RUN verb automatically create?
2) Where will these objects be written?
3) What will happen if a user does not have write permissions to the
dir where the objects are wanted to be created?

If you do created the MOBJECT dir:
1) Is is a good idea iyo have user who have write permissions to
object directories?
2) For security sake, would you suggest a standard practice of
having a developer pre-RUN _every_ program to prevent user processes
from having to have permissions on object directories to create
objects 'on the fly'.

Thanks,

Bruce Decker
Strategy 7 Corporation

On Apr 21, 6:56 am, "Daniel Klein" <danielklei...@gmail.com> wrote:
> Yes, RUN was changed on 4.1 but jBASE does not compile code automatically.
> The RUN command is ineffective unless it can find a .o (or .obj) file in the
> same directory that PROGRAMNAME is in, which means it had to be compiled in
> the first place in order to be RUN.
>
> This RUN behavior can be circumvented by creating a 'FILENAME,OBJECT' data
> section, eg:
>
> CREATE-FILE DATA FILENAME,OBJECT TYPE=UD
>
> or
>
> mkdir FILENAME]MOBJECT
>
> Now when PROGRAMNAME is compiled, it will place all object code in the new
> 'data' section', thus maintaining your security on source code.
>
> This of course means you can do:
>
> RUN FILENAME,OBJECT PROGRAMNAME
>
> without having previously CATALOG'd the program.
>
> Using this scheme we behave very similar to legacy MV applications, ie a
> user can edit, BASIC and then RUN a program without having to CATALOG it.
>
> Note that FILENAME should be a directory, not a hashed file.
>
> Dan
>

> > -BD- Hide quoted text -
>
> - Show quoted text -

[Daniel Klein]

When you issue 'RUN BP PROGNAME' it will do the following:

a) Look in BP for a shared object called PROGNAME.so (or PROGNAME.dll or PROGNAME.sl etc)

b) If the shared object doesn't exist, try to create one from the .o file (or .obj or $PROGNAME)

c) Check the time-stamps and re-build the shared object if, for example, the .o file is newer than the .so/.dll file.

d) Finally, load BP/PROGNAME.so (or .dll) and execute it (Note that it is loading the shared object and not the executable due to the new 4.1 thread model)

If any of this fails, it tries to run the CATALOG'd version.

Any files created (.so / .dll / .exp / .lib / etc) will be placed first in BP,OBJECT, if it exists, and then in BP.

Again, much of this only works when BP is a directory rather than a hashed file. If your source code isn't in directories then it should be.

The '-x' option has been removed from RUN , it is no longer required.

The RUNPATH environment variable has also been removed, it is no longer needed as we now do a more genuine RUN.

If the user does not have 'write' permissions then the same thing will happen on any resource that does not have 'write' permissions...the use will not be able to, errr, write to it.

Wrt your second set of questions...

1) Please clarify

2) No. I don't advocate developers (or anyone for that matter) using the RUN command at all. They should have their own environment, separate from 'live' to do what they want to. I realize the 'real world' is different so I refrain from further comment.

Any questions? No, I thought not.

Dan

[s7bd]

Thanks Dan (replies and requested clarifications below):

> b) If the shared object doesn't exist, try to create one from the .o file
> (or .obj or $PROGNAME)

[bd] I guess I should have been more clear about my concern. My
concern is precisely that this scheme appears to open a situation
whereby if a program has not yet been RUN but a developer with write
permissions on the source file, the end user's process will try to
write to the source (MOBJECT) dir and then err. I guess you may be
saying that if you choose to use RUN then you have to accept that a
user writing objects is OK. We'll have to disagree on that point. I
only want my users creating data, not objects.

> Any files created (.so / .dll / .exp / .lib / etc) will be placed first in
> BP,OBJECT, if it exists, and then in BP.
>
> Again, much of this only works when BP is a directory rather than a hashed
> file. If your source code isn't in directories then it should be.

[bd] Actually, I'd say that regardless of whether it is a dir or
hashed file, I still don't think users writing to these directories is
a very good idea. But, again, we've agreed to disagree on that point.

> If the user does not have 'write' permissions then the same thing will
> happen on any resource that does not have 'write' permissions...the use will
> not be able to, errr, write to it.

[bd] We'll I appreciate you are trying to use a bit of humor here but
I think you're ignoring the real problem. Users should not be put in
situations where writing to object directories is part of the
deployment strategy. That is, I guess, where we are going to have to
agree to disagree.

>
> Wrt your second set of questions...
>
> 1) Please clarify

[bd] Oops, that should have read: "Is it a good idea for users to have
write permissions on object directories". You've already answer that
and I understand that we disagree on that point. I withdraw the
question.

> 2) No. I don't advocate developers (or anyone for that matter) using the RUN
> command at all. They should have their own environment, separate from 'live'
> to do what they want to. I realize the 'real world' is different so I
> refrain from further comment.

[bd] Yes, in the real world, legacy developers used RUN to selectively
run one version of a program_name vs. others based on some conditional
criteria. In a migration, you would have to make each of the
conflicting program_name(s) and change them so that they could all be
cataloged in path then change the programs that call them. This can
be messy. There is a very straight-forward way to deal with this
legacy construct that maintains compatibility with these legacy
constructs but does not require you to keep object directories open to
user write.

>
> Any questions? No, I thought not.

Nope, just more amazement :-)

[Charlie Noah]

Does anyone know how to interpret the machine-readable results of LIST-TRIGGER
(release Major 3.4, Minor 8, Patch 0351)?

LIST-TRIGGER -m /inland/corp/KEYWORDS

returns:

prewrite 938336546 1119020404 1 0 0 KEYWORDS.TRIGGER 1
postwrite 938336584 1119020404 1 0 0 KEYWORDS.TRIGGER 2
predelete 938336597 1119020404 1 0 0 KEYWORDS.TRIGGER 3

The 1 0 0 I can figure as probably amend yes, term no and debug no. The trailing numbers appear to
be sequential. The large numbers elude me.

LIST-TRIGGER /inland/corp/KEYWORDS

returns:

TRIGGER definitions for file /inland/corp/KEYWORDS at 10:10:57 23 APR 2007 PAGE 1

TYPE...... AMEND. TERM.. DEBUG. SUBROUTINE NAME...............

prewrite YES NO NO KEYWORDS.TRIGGER
postwrite YES NO NO KEYWORDS.TRIGGER
predelete YES NO NO KEYWORDS.TRIGGER

LIST-TRIGGER -a /inland/corp/KEYWORDS

returns nothing, even though the docs say -a means that all fields will be displayed.

The KB page says:

LIST-TRIGGER -Options FileName {jQL statements}
Option Description
-a or (A) all fields will be displayed
-ffilename use file "filename" instead of creating a dummy
-m or (M) output is in machine readable format
(N) NO-PAGE the output
(P) output is to printer

Thanks,
Charlie Noah
Inland Truck Parts Company

[Jim Idle]

First, download ANTLR3 and using the excellent C runtime target written
by someone very clever, write a parser that can understand the output,
then, write an interpreter that uses this parser to execute the
numbers... oh, that's not what you meant? ;-)

You might try -A, or (A and see if that makes a difference, otherwise it
is a bug.

However, the large numbers look like UNIX format times to me and as the
create and modify times are recorded for the triggers, I suggest that
that is what you are looking at. The trailing numbers are probably just
the type of the trigger and happen to look sequential, or perhaps they
really are just the number of the trigger. Try adding some to another
test file and see if you get sequential numbers regardless of the type
of the same number for each type.

Jim

[Greg Cooper]

Field 1 is the trigger type as a text string

Field 2 is the create time, in Unix time format, of the trigger

Field 3 is the last modification time, in Unix time format, of the trigger

Field 4 is a flag to show if modifications are allowed

Field 5 is a flag to show if the trigger can terminate the update

Field 6 is a flag to show if the trigger can be debugged

Field 7 is the subroutine name

Field 8 is the trigger type as a number, where 1 == pre-write, 2 == postwrite , 3 == pre-delete , 4 ==post-delete

              5 == pre-clear , 6 == post-clear , 7 == pre-read , 8 == post-read , 9 == post-open

[Charlie Noah]

Greg,

Marvelous explanation. It all seems so clear with a roadmap. Now (OK, so I'm
lazy), does anyone have a Unix Time to Pick^h^h^h^h Jbase date and time converter
that they would share? I suppose I could design one myself, but I'm not above
begging. ;^)

Charlie

[Jim Idle]

How about U0FF1 for the date and U0FF0 for the time (same input)?

That's $1M please.

Jim

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf
Of Charlie Noah

[Greg Cooper]

Charlie,

 

In the code sample below, the 'tim' value is the current Unix UTC value for today. Normally the value returned is set to GMT regardless of the computer's physical location and then time zones are set to give the local time. The conversion below will convert from the Unix value in GMT to the local value with time zone applied. In my case, as I live in GMT land, it's the same thing although we might be on BST now and so .... oh no, my brain's exploded.

 

    tim = 1177348242
    PRINT "DATE = ":OCONV(OCONV(tim,"Uff1"),"D")
    PRINT "TIME = ":OCONV(OCONV(tim,"Uff0"),"MTS")

 

Hope this helps.

 

Greg

[Charlie Noah]

Greg,

Works like a charm! Thanks.

Charlie

[Charlie Noah]

Thanks, Jim. The check's in the mail.

Charlie

[Charlie Noah]

One final piece would make my life bliss - I don't suppose there's a function
like INDICES() that returns trigger info? If not, I will probably write one,
to make it a little easier to use. What!?!? functions are depracated in 4.1???
Just kidding (I think)!

Charlie