Jaap,

Thanks for that very useful info. But how about components in SCM?

This thread is split off from http://www.baanboard.com/baanboard/showthread.php?s=&threadid=7028 - ~Vamsi 2002-10-04 12:50 PDT

~Vamsi,

SCM is on a different level. If you want to find a software component, you first have to know in what VRC it is. That's what this search algorithm is about. The elegancy is that it finds it with one single query.

If you want the most recent version, this algorithm works. I shouldn't know why you want another revision (SCM) than the latest.
BTW: labels don't have revisions.


Regards,
Jaap Zwaan

Jaap,

I have a program in developement that searches for strings in Baan code. You may say that this is standard Baan functionality. My program runs many times faster than Baan code does (It uses Perl on the backend). This is inspired by grepx that is totally shell based and in use within Baan.

I am not sure if I should accept the VRC or the package combination from the user to do the search. I want an option to include the SCM script if required. That would be another option I guess. Below is the code that I want to optimise.

function read.main.table()
{
filename.in = creat.tmp.file$(bse.tmp.dir$())
filename.out = creat.tmp.file$(bse.tmp.dir$())
fp = seq.open(filename.in, "w")
scripts = true
select ttadv230.cpac, ttadv230.cmod, ttadv230.cprs
from ttadv230
where ttadv230._index1 inrange {:cpac.f, :cmod.f, :cprs.f}
and {:cpac.t, :cmod.t, :cprs.t}
and ttadv230.cpac <> "tt"
group by ttadv230.cpac, ttadv230.cmod, ttadv230.cprs
order by ttadv230.cpac, ttadv230.cmod, ttadv230.cprs
selectdo
ret = pathname( "p" & S(ttadv230.cpac) &
S(ttadv230.cmod) & S(ttadv230.cprs) & "0", "P", file_path )
write.filenames()
| rprt_send()
endselect
scripts = false

functions = true
select ttadv260.cpac, ttadv260.cmod, ttadv260.cfun
from ttadv260
where ttadv260._index1 inrange {:cpac.f, :cmod.f, :cfun.f}
and {:cpac.t, :cmod.t, :cfun.t}
and ttadv260.cpac <> "tt"
group by ttadv260.cpac, ttadv260.cmod, ttadv260.cfun
order by ttadv260.cpac, ttadv260.cmod, ttadv260.cfun
selectdo
ret = pathname( "i" & S(ttadv260.cpac) &
S(ttadv260.cmod) & S(ttadv260.cfun) & "0", "P", file_path )
write.filenames()
| rprt_send()
endselect
functions = false
seq.close(fp)
perlcommand = "search.pl " & """" & S(search) & """ "
& filename.in & " " & filename.out
ret = run.prog("perl", perlcommand, RP_WAIT)
if ret then
message("Errors encountered in executing\nperl %s", perlcommand)
else
display.file(filename.out, "Search Results",
132, 50, language$, prog.name$(1;13), 0)
endif
seq.unlink(filename.in)
}

function write.filenames()
{
if not ret then
seq.puts(file_path, fp)
endif
}

Vamsi,

It looks very nice.

I have a few suggestions -

1. pathname() doesnt seem to be returning right value when I tested and built my own pattern matching tool.

2. According to the BaaN SCM concepts, any checked-out components should be externally visible only to the developer or the shared SCM group.

3. Instead of the perl or grep of Unix, you can use some of the internal BaaN tools functions which improve the performance extensively.

4. if you dont have that log file operations and let BaaN handle your output controls, you will gain tiny performance. That's another clue for you.

5. I guess giving the package combination, Package VRC as input fields is based upon your idea of the tool. I didnt provide that, and our developers know that when they execute the tool, the last found script from the VRC tree is searched based on the current package combination.

6. Output handler should be portable to excel, word or display screen.

Here is a screenshot of my tool, and I used the keyword "main", as I figured that most scripts have the domain or main() used.

For a full range of Package VRC's in the current package combination it took 69 secs and 225 pages of output on my display screen.

Good Luck! I know you can make it...!!!

1. pathname() doesnt seem to be returning right value when I tested and built my own pattern matching tool.
http://www.baanboard.com/programmers_manual_baanerp_help_functions_directory_file_operations_pathname is not supposed to return a match. It returns the path to any given component. Works great on my machine - Sun Solaris/Baan 5.b

2. According to the BaaN SCM concepts, any checked-out components should be externally visible only to the developer or the shared SCM group.
pathname() returns the object/script that one is supposed to. If I have two scripts checked out. Those are the only two scripts that I get with SCM.

3. Instead of the perl or grep of Unix, you can use some of the internal BaaN tools functions which improve the performance extensively.
I am not aware of pattern matching features in Baan. http://www.baanboard.com/programmers_manual_baanerp_help_functions_expressions_runtime_expr_compile does pattern matching but only BRE (basic regular expressions). Also I am not aware of if there is any pattern matching out there that can match stuff in more than one line. Also I am not sure whatever you have done, is capable of ignoring case (remember Baan does not care about case).

4. if you dont have that log file operations and let BaaN handle your output controls, you will gain tiny performance. That's another clue for you.
You lost me on that one.

5. I guess giving the package combination, Package VRC as input fields is based upon your idea of the tool. I didnt provide that, and our developers know that when they execute the tool, the last found script from the VRC tree is searched based on the current package combination.
Because pathname() works on the current package combination, it is a disabled feature for me at the moment. But I would like to be able to search for stuff only in the standard without having to log in to the standard package combination. That was the intent of the question to Jaap.

6. Output handler should be portable to excel, word or display screen.
Trivial. I usually search for stuff and copy and paste useful code :). Fortunately I do not have to do management reports out of stuff I copy and paste. Now come to think of it, perhaps I should... and prove how good I am at reusing stuff :D.

Here is a screenshot of my tool, and I used the keyword "main", as I figured that most scripts have the domain or main() used.

For a full range of Package VRC's in the current package combination it took 69 secs and 225 pages of output on my display screen.
It takes about 11 seconds to come up with a list of all program scripts (the part for pathnname() to execute) and another 29 seconds to do a pattern match in all those files. This I guess would be an apple/orange comparison. I could be running a more powerful machine.

Good Luck! I know you can make it...!!!
I already have :). Am trying to improve its performance. I am sure you can make a tool which addresses the issue of matching beyond BREs. Ofcourse one could always claim that BRE is all that one needs ;). But then there is always the slightly more demanding programmer :).

I always like these interesting discussions with you Vamsi, for you dont think like the most do.

So I have presented my issues with the pathname() function in the document.


1. pathname() is not supposed to return a match. It returns the path to any given component.


I meant that path returned is wrong and quite aware its not used to match patterns.


2. According to the BaaN SCM concepts, any checked-out components should be externally visible only to the developer or the shared SCM group.

I think Jaap has the same Q or point of view as I have -

I shouldn't know why you want another revision (SCM) than the latest.



3. Also I am not sure whatever you have done, is capable of ignoring case (remember Baan does not care about case).

I think BaaN does consider cases. Correct me if I am wrong, and here is my test program.

$ cat abc
THIS IS A TEST PROGRAM



function main()
{
string pattern(12)
string logfile(256)
logfile = "/home/nprao/abc"
pattern ="test" |* try another run with TEST
if pos(logfile, pattern) then
message("found")
else
message("not found")
endif
}


4. -> my bad, shot in the dark.

5. You can get around with that issue, by giving VRC fields as input fields to your session, in that case you can no longer use the pathname() but you need to use the other tools functions to get the scripts path or code your own function.

6. Ouput Options - I guess you are lucky then, here people are very picky, and they found it to be useful, to do scripts porting between BaaN versions or where used searches.

I am pretty sure you are on a powerful Sun Machine, and I am on a HP server with 4 BaaN environments in it.

Nevertheless, its been very interesting discussion. So I take the runner-up cup :p

There seems to be a misunderstanding about case sensitivity. It is correct that in a Baan script, it doesn't matter if you write identifiers (variables, function names, macros) with upper or lower case.
But the strings are different: "TEST" and "test" are two different strings.

By the way: your example is wrong anyway, because the function pos simply operates on two strings, and not on files.

Your example:

logfile = "/home/nproa/abc"
pattern= "test"

pos(logfile, pattern) | this will return false, because the word "test" is not in the file name!

pattern = "nprao"
pos(logfile, pattern) | this will return true, although the name is not in the file


The rest of the conversation gets too complicated form me: all those separate topics are too confusing for a simple mind like me.

Regards,
Jaap Zwaan

Sorry Jaap,

I made the code too concise. I didnt write the seq.open(), seq.gets() functions for the logfile. Here is the complete sample code -


$ cat abc
THIS IS A TEST PROGRAM


function main()
{
long fp
string pattern(12)
string logfile(256)
string buffer(1024)
logfile = "/home/nprao/abc"
pattern ="test" |* try another run with TEST

if fp < 0 then
message("File Handling Errors")
exit(1)
endif
while not seq.gets(buffer, 1024, fp)
if pos(buffer, pattern) then
message("found")
else
message("not found")
endif
endwhile
e = seq.close(fp)
}


I hope this makes it clear for everyone.

Jaap, I guess you are simple living and great thinking...!!! :)

~Vamsi,

My last remark on this thread: What happens if your program script was set to expired? In your code (read.main.table function), this is not handled, so you might find a pattern in a script that is already expired. Reading the complete ttadv230 record in combination with ttadv112 will solve this (minor?) problem, but there is a penalty on performance, I agree.

Regards,
Jaap Zwaan

I tested my tool in a new environment with modifications and with no VRC search logic and using pathname() and I got a best timing of 12 seconds and worst as 35-39 seconds and 221 pages(page length=50) of output.

Interesting Findings-

1. When I use the pathname() the speed increased considerably than using my own vrc search algorithm and finding path of the script.

2. The pathname() did give me correct SCM or script paths, in this new environment.

3. The pathname() returns only the path of the SCM components which were checked out by me and not by the other developers.

Jaap, please correct me if I am wrong -

I think the pathname() logic is different from the search.script.path() logic as it builds the path from the environment paths and checking the file on the OS while the second one basically searches through the tools tables entries.

Based on my observations, I think if there is a messy environment as our old dev, there are instances, where you have a script in a particular VRC of a VRC tree, the object might be on the OS while the tools table entry might not be there or vice-versa, in either case one of the search functions fails.

NPRao,

You're right, pathname is a bshell function that starts searching for a file according to the $BSE/lib/fd6.x.<pacc> file, regardless of the data in ttadv230 and ttadv260.
The other function I don't know, but I assume it uses the database for looking up the source.

Pathname is indeed faster, but note that it ignores "expired" records: it will find an object/source even if it is expired according to a later VRC in your view.

Regards,
Jaap Zwaan

P.S. This will be my 30th post, so I will finally become an official member.

Jaap,

I have few more Q's in this issue, from Vamsi's code -


select ttadv230.cpac, ttadv230.cmod, ttadv230.cprs
from ttadv230
where ttadv230._index1 inrange {:cpac.f, :cmod.f, :cprs.f}
and {:cpac.t, :cmod.t, :cprs.t}
and ttadv230.cpac <> "tt"
and ttadv230.expi = ttyeno.no |* not expired
group by ttadv230.cpac, ttadv230.cmod, ttadv230.cprs
order by ttadv230.cpac, ttadv230.cmod, ttadv230.cprs
selectdo
ret = pathname( "p" & S(ttadv230.cpac) &
S(ttadv230.cmod) & S(ttadv230.cprs) & "0", "P",
file_path )
write.filenames()
| rprt_send()
endselect


1. Even if I add the check for unexpired scripts as ttadv230.expi = ttyeno.no, I think I would get the patterns matched for the expired script with a source as the path name doesnt test if the script is expired or not?

2. If statement-1 is true, I think my previous code, where I used the VRC search and then find the script path logic is the correct logic to get the right set of matches even if it takes more time.

3. I still didnt understand why do we have 2 different path finding algorithms - pathname() and search.path.program.script(). I think both the functions are used in the various tools sessions/dlls. Which is the safer/better one to use?

Congrats on being the Member, we are happy to have you on the BaaN-Board. :)

The big difference between pathname and search.script.path( I still haven't found this function, so don't blame me on this one) is Runtime or DataDictionary.
Pathname simply looks on OS level where the source is (like the explode6.2 or explode6.1 command). Whereas search.script.path creates the path from the VRC of the ttadv230 (program scripts) record and ttadv115 (Directories of Software components). This is were it should be (if you havent been messing around).
The answers to your questions are now:
1) Indeed if there are two records:
tt adv 2500 B50 a "not expired"
and
tt adv 2500 B50 b "expired"
This function will still find the ttadv2500 script and will start looking for it on os level. It will find the B50a version.

2) Right. You have to find the balance between "exacly right and long waiting time" and "almost right and very fast"

3) This depends on what you want, as explained above. Do you want to follow the database (DD) or find what's there. Note that pathname is most of the times used for finding objects. On customer systems, the program scripts and ttadv230 might not be available. You can still execute the objects then.

Regards,
Jaap Zwaan

Thanks for all the info, Jaap.


long search.path.object( domain ttadv.cpac cpac fixed,
domain ttadv.vers vers fixed,
domain ttadv.rele rele fixed,
domain ttadv.cust cust fixed,
domain ttadv.cmod cmod fixed,
domain ttadv.cprs cprs fixed,
ref string path.object() )

long search.path.program.script( domain ttadv.cpac cpac fixed,
domain ttadv.vers vers fixed,
domain ttadv.rele rele fixed,
domain ttadv.cust cust fixed,
domain ttadv.cmod cmod fixed,
domain ttadv.cprs cprs fixed,
ref string path.script() )


functions are present in the tools dll - ttdllsrch_path

I think the speed game is over and I will switch back to my original good logic which is quite accurate.

The reason for Q-3 was that in our messy environment,
the scripts were compiled down the VRC structure
and we got objects present in the VRCs where the
sources were not located.

Hence, I made a tool which can find the mismatch of the source and objects VRC's using the tools functions,
vrc_search_script() and vrc_search_object(),
which I later found that we had unreliable entries in the tools database entries.
And I found another functions search.path.object() and get.envpath().
And then I also found that I can use get.envpath() to get the script's path.

I am just confused myself which functions are the best one
to use for objects and scripts sources. :confused: