No need to be a programmer to understand my comments

[Ph Vouters]

No need to be a programmer to understand my comments in the PROGRAM section of my document at http://vouters.dyndns.org/tima/Linux-HP-UX-OpenVMS-libreadline-GNU_readline_usage_example.html

[abrsvc]

You are correct in that DECC$ logicals should not be set at the system level.  Per the documentation (comments) the code indicates that setting the proces level logical name will PREVENT the use of DEBUG for that program image.

==================

"* Setting DECC$FILENAME_UNIX_ONLY logical to ENABLE or 1 with a DCL define
* simply prevents to run this code under the VMS debugger which becomes unable
* to open the .EXE to read the program symbols.

==================

Dan

[Ph Vouters]

The correct VMS solution is indeed to set program required DECC$ logicals using decc$feature_set. This is what does GNV bash. However the decc$feature_xxxx forces you to initially set all other unwanted logicals to their default values which is extremely seldomly if not never done even by HP provided codes. This is because the VMS C RTL does not own a decc$feature_set_all_defaults call. For your fun, just:

$ define DECC$UNIX_LEVEL 90

$ bash

bash$ ls $HOME

On my side, I get extremely strange and absolutely unexpected results.

However and for this GNU readline example, VMS forces the developer to complexify a lot the example just for this required DECC$FILENAME_UNIX_ONLY logical. Such an added complexity adds strictly nothing to the understanding of this Unix/Linux/VMS portable example.

In conclusion, OpenVMS ressembles to why doing things simple when you can make them extremely complex. For someone porting Opensource codes or looking after portability, OpenVMS has become totally unfriendly. The real conclusion one may draw with little experience is that needed DECC$ logical setting may negatively and extremely easily interact with any other VMS codes or even parts of the same code preventing these codes to be used in normal conditions.

For the curious, I lost lot of time and efforts manually setting all the numerous SYMBOL_VECTOR linker lines while porting libreadline. This was because I was inadvertendly setting DECC$FILE_SHARING or something alike which prevented me to execute nm from binutils. I even had to debug nm to finally realize that a very correctly coded fopen was returning NULL instead of fopen'ing the file.

Philippe

[H.Becker]

>>> The correct VMS solution is indeed to set program required DECC$ logicals using decc$feature_set.

I'm sure you know what you are talking about, but it may be better to differentiate between DECC$ logicals and CRTL features. The "solution" - as communicated in other threads of this forum and its predecssor - is to set CRTL features in image initialization code. If you can't do that, because you don't have the sources/objects to re-link, you have to use a user mode DECC$ logical to set a CRTL feature. It is not recommended to use process or job logicals, not to speak of any other logical name table.

>>> This is what does GNV bash.

Yes. Again, this was already mentioned here and it was mentioned that you don't need and should not define any of the DECC$ logicals to enable a CRTL feature for GNV.

>>> However the decc$feature_xxxx forces you to initially set all other unwanted logicals to their default values which is extremely seldomly if not never done even by HP provided codes. This is because the VMS C RTL does not own a decc$feature_set_all_defaults call.

Yes, there is no decc$feature_set_all_defaults. If you want to prepare your code to ensure that none of the "unwanted" features was enabled by a DECC$ logical you simply have to set ALL the features to values your program expects.

>>> However and for this GNU readline example, VMS forces the developer to complexify a lot the example just for this required DECC$FILENAME_UNIX_ONLY logical. Such an added complexity adds strictly nothing to the understanding of this Unix/Linux/VMS portable example.

Yes, a mixed Unix and VMS environment IS complex.

>>> In conclusion, OpenVMS ressembles to why doing things simple when you can make them extremely complex. For someone porting Opensource codes or looking after portability, OpenVMS has become totally unfriendly. The real conclusion one may draw with little experience is that needed DECC$ logical setting may negatively and extremely easily interact with any other VMS codes or even parts of the same code preventing these codes to be used in normal conditions.

Yes, if you have a shareable image, I mean a shared libray, ported from the Unix world and it requires a CRTL feature being enabled and you have a main program, which requires that feature to be disabled you are in trouble.

>>> For the curious, I lost lot of time and efforts manually setting all the numerous SYMBOL_VECTOR linker lines while porting libreadline. This was because I was inadvertendly setting DECC$FILE_SHARING or something alike which prevented me to execute nm from binutils. I even had to debug nm to finally realize that a very correctly coded fopen was returning NULL instead of fopen'ing the file.

If you really don't know the symbols (VMS developers know their interfaces and what to write into a SYMBOL_VECTOR clause) ANALYZE/OBJECT and/or ANALYZE/IMAGE are your friends. But there are some other VMS specific tools which can show exported symbols and PSECTs from shareable images as well. And for new DECC++ compilers (maybe only on I64, I didn't double check) __declspec(dllexport) may be of help.