runnotfound

Most of the time we only deploy r-code to our customer-sites, but the programmers have always programmed:
run asobj/a5xxx.p

runnotfound will give a warning on this, although the r-code can be found most of the time.

I see in the code that function IsDlcComponent does replace the .p (or .w) with .r to do a new search, but then only returns true if the found r-code is in DLC.
Why can't it just return (rprogpath <> ?) ?
That's what matters doesn't it?

(then maybe the function-name should be modified)


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jurjen's picture

A customer-site with only

A customer-site with only r-code? What do you expect from Prolint in an environment without source code?


Prolint doesn't run on customer site

Obviously Prolint does not, can not, run on the customer site.
That would also be too late, the code would already be build, tested and deployed.
We build a standard application which we deploy to several customer sites.
So Prolint is run "in-house" by our development department, where the source resides.
But since source- and object-code are separated the run's aren't programmed to the source folders, but to the object-folders which may have a different name. So runnotfound will not find a .p in the object-folder.


tamhas's picture

But, why in the world would

But, why in the world would you not have a propath that went first to the .r and then to the .p? You are editing source, are you not?


Yes and No

Yes, for the development department the propath first searches the .r and then the .p.
No, at the customers-site there is only the .r, so not propath to the .p and No we don't edit source at the customers-site.

The program contains a run asobj/a5xx.p (with .p)
And the rule only does search(asobj/a5xx.p) which will never resolve because, the source-.p resides in the assrc-folder and the obj-.r resides in the asobj-folder.


jurjen's picture

no fix

"the source-.p resides in the assrc-folder and the obj-.r resides in the asobj-folder."

if the statement

  RUN asobj/a5xx.p.

should be validated by looking if file "assrc/a5xx.p" exists, knowing that "asobj" is the compile-into directory of "assrc", then I am afraid you are going to need a custom override of the rule. Because I don't see a reusable pattern here.

A feature you might propose is: consider "asobj" to be a third-party component. The current implementation of "runnotfound" treats DLC as such a third-party component, which means the rule thinks it is ok when it can find r-code even if the source-code is missing. The new feature would be that you can somewhere configure an additional list of third-party components which are actually directories where you can expect r-code and no source code.

If you acually do such a feature proposal, then please create an issue tracker to register it. Because issues are reminders, forum topics are not.


rule is named runnotfound

The run asobj/a5xxx.p should not be validated by looking for assrc/a5xx.p, it should validate it by looking for either asobj/a5xxx.p and/or asobj/a5xxx.r like Progress does at runtime.

The rule is named runnotfound, not "sourcenotfound".

Progress at run-time can resolve the run asobj/a5xxx.p to actually run asobj/a5xxx.r (preferred if it's there)
I think the rule is build to help identify runs that will never resolved.


tamhas's picture

If Progress forced you to

If Progress forced you to use .r or .p in the run and wouldn't find it otherwise, I might think this was OK. But, instead the rule is to search first for a .r and *then* to search for a .p if the .r is not found. To me, this is a strong indication that .r and .p should be on the same relative path in reference to one of the base directories in a propath. By including a directory in your run statement which only ever applies to .r code, you are violating what has been a basic design principle of Progress applications since the beginning.

Cobble this rule for your own purposes if you must, but no one is going to agree that is good practice, so don't expect to argue that the rule name means it should be looking for a .r ... no one works that way. Much better would be to realize now that this is a design flaw and change it. If you are on a Unix box I will even send you a general purpose search and replace script that will do it for you. It should be quite easy because all you will need to do is to remove "asobj/" from the run statement and fix the PROPATH.


tamhas's picture

Perhaps I'm not

Perhaps I'm not understanding your layout, so let me tell you about mine. I have a series of directories, e.g., rel and tst. In each there is a src and a run subdirectory for source and compiled programs respectively. So, for plain released code only, the propath is rel/run:rel/src. If I want to include test code then the propath becomes tst/run:tst/src:rel/run:rel/src . This way, .r is always found before .p for execution and anything in tst is found before an equivalent name in rel. But, if one does a search(xxx/xxx/xxxxxx.p) then it will find that in one of the src directories.

I thought most people did this.


No you won't :-), :-) many smileys

I still think that even in you situation (which is similar to ours) you won't find it.

If you do a search(rel/run/xxx.p) it won't find it.
Because you can either search(rel/run/xxx.r) or search(rel/src/xxx.p)

In our case the run is programmed as:
run rel/run/xxx.p.

Which will work and actually runs rel/run/xxx.r


tamhas's picture

You don't search for

You don't search for anything with rel or run or source. E.g., my main customer maintenance function is ar/cust/custmn.p . The current released source is in rel/src, the current released compiled version is rel/run/ar/cust/custmn.r and similarly for test versions in test. With the propath of "tst/run:tst/src:rel/run:rel/src", I will find a test version, if there is one and a released version if not. I search on "ar/cust/custmn.p" not on something that has rel, run, src or anything else in front of it. All references in the code are to "ar/cust/custmn.p" . No reason at all to have rel or run in there ... that's what the propath is for.


And that's where it's different

And that's where it's different from our situation.
Your source and object paths are the same after the propath entries, ours are not.


tamhas's picture

I would consider that a

I would consider that a significant design flaw ... at least as bad as that place in AutoEdge where the PROPATH has to include both a directory and a subdirectory of that directory because someone couldn't figure out that the reference in the code should be directory/subdirectory.

Frankly, you just shouldn't put things into your run statement like that. In fact, I would take a breather on ProLint and take a quick run over to ProRefactor to get rid of those elements in your run statements before you create any more of them.