Good day -

Was it Jorge that cristened 2020 "The year of the ashlog?"? Or the revenge of the ashlog?

Either way repelling down the ashlog well can result in never returning, but for now i have a simple question - parusing ours i see lots of asMessageBox(...verbiage here) messages. I have no traces turned on right now other than BASERR.

Any idea what and why these are tracked? I will most likely uncover more of these sorts of entries as i try to make my large servers more efficient... just figured i'd start here. No rush whatsoever. (either way, we can still blame Jorge, right?!)

TIA

I think they are xcall mesag / asMessageBox() and sneaked into non-debug Ashlog.log in version x and sneaked out after version y, as I highlighted them while back.

Any idea what version Y is??

All I remember is it’s after X ...

You're right Frank, this is the year for me to trace all those traces in ashlog but I'm not getting those asMessageBox.
Maybe another GPS related issue, but this time only affecting sites located in high mountains?

For a guy who admits to having the occasional loose screw, he sure has his logic down pat!

Indeed: X (6.1.1335) > Y (6.5.1673)

The idea behind it originally was to log messages that we had reason to be believe (from the MBICON choice) were errors. But due to the odd encoding of the MBICON values (in MSGBOX.SBR) it was also picking up the MBICON_QUESTION option, i.e. message boxes that were merely asking a question.

As it stands now, it still logs MSGBOX calls that specify the MBICON_EXCLAMATION or MBICON_STOP options, again, on the theory that those probably suggest conditions that might be useful when reviewing the ashlog later. (Admittedly, here we get into a gray area as to whether application-level warnings belong in the ashlog, since you may already have your own log file for that. But when I find myself scanning through someone's ashlog looking for an explanation for a problem, I usually appreciate all the clues can get.)

Or maybe infected with Covid?!!

Were running 6.5.1663.0 So im sure more current version has it sorted.. if yours and Steves are good to go.

Crossed posts - thanks Cap!

The great 2020 ashlog review continues...

I see the following at one customer, old-code and no PSTDIS.CSV exists in the ppn in question, there is a LOOKUP before and OPENs etc so curious whats "unlink" mean?

Yeah! it's unbelievable the unknow staff that runs underlines in the ashlog world
Besides less intense than I wish, I've fixed several things and improved performance in my incursions on that world.

Steve, regarding the unlink, maybe you can find some relation with this topic

Have fun

Sort of like cleaning out the garage...

It sure is Frank, more so when I stumbled on a program that needs tweaking and still going strong for....34 years!

Never know what you might find under all that clutter!!

The unlink trace should only appear (under A-Shell/UNIX) when the FOPENS trace is enabled. OR if there is an error in the unlink operation (which in this case there is.) The errno value is the one in parentheses, i.e. (2), aka ENOENT, which means "no such file". So the application is apparently trying to unlink a non-existent file.

Why "unlink"? The somewhat exotic sounding term is actually the standard UNIX system call underlying any command that erases or removes files. In other words, when you use ERASE.LIT (or any equivalent) to erase a file under A-Shell/Linux, the underlying operation will involve a call to the unlink() system library function.

The reason why it is called "unlink" is because in the UNIX world, it's quite possible for there to be multiple directory entries (often in different directories) which point to the same file. (There are actually two types of these, symbolic and direct links,but let's not get too deep into the weeds.)

When you "unlink" one those directory entries, if the directory entry is just a link to a file stored under a different name, then the operation just removes the link, i.e. removes the alias, i.e. unlinks file data from that alias name. Only if the specified directory entry links to the real file does the file itself get removed.

An example occurs with library modules, which typically include the version of the library in the name of the real file, and then we create one or more symbolic links with abbreviated names pointing to the same file, e.g.



The above illustrates the scenario where we have a file /vm/bin/libashmysql.so.1.4.143, and also a symbolic link to it ( /usr/lib/libashmysql.so.1 ) in a standard location (/usr/lib) and with an abbreviated name which insulates the application from having to know the latest version number of the library. (The .so.1 extension identifies the compatibility version, i.e. 1). If you erase /usr/lib/libashmysql.so.1, you're really just unlinking that alias from the actual file. If you erase /vm/bin/libashmysql.so.1.4.143, then you're removing the real file. (Removing a real file does not remove the symbolic links to it, but those would effectively become broken links, acting like non-existent files if you tried to access them. (That might even be related to the cause of your unlink errors?)

(In the case of direct links, they all have equal status and the system will not remove the actual file until there are no more links to it.)

ah! Thank-you for the explanation... I'll tweak the program to try to stop the unlink error showing in the ashlog.

So in Steve's case above, wouldn't that have generated an error message? Actually i just tried it and there is no ashell generated error when executing a KILL on a non-existent file. Shouldn't there be a "File Not Found" message?

No, please no!

It's debatable whether it should trigger an error, but at some point long long long ago (possibly last century) it was deliberately changed to stop triggering the error in the case of a mere attempt to delete a file that doesn't exist. (Probably because ... what would be the point in complaining that the thing you're trying to accomplish has already been accomplished?)

It is, however, still possible to trigger a Basic error on certain KILL errors, such as invalid filespecs. Or in strict mode, an attempt to kill a file outside your project.

Note that ERASE.LIT will report a "%No Files Deleted" message on a failed kill.

Seems inconsistent to me to allow the code to execute something that is improper... no matter the intended result. However, if Herman is happy with it, who am i to argue...

However - if i try to allocate a file that already exists, it does create an error. Using your logic, if all i was trying to do was already done, then why not just allow bygones be bygones?

Maybe an option, Frank?

Jack loves those!

Right Herman! But not important enough for me to burn a future request on

That's probably a wise choice!

But to respond to your observation about the lack of symmetry between complaining about an attempt to allocate an already-allocated file, vs deleting an already-deleted file, I think there is a potentially significant difference. In the deletion case, all deleted files are the same, so it doesn't really matter how we got to that state. But in the allocation case, a newly allocated file will be empty, and of a certain size, whereas if the file was previously allocated, it might contain data and be of a different size. So the end result of not-allocating an already-existing file is likely to be different (i.e. worthy of an error) than the end result of actually allocating the file.

Symantics... Agreed.