On 03/25/2014 01:47 PM, John E. Malmberg wrote:
> On 3/24/2014 3:07 PM, h.becker wrote:
>> There are several problems with the checked-in old exit handling, which
>> aren't resolved by the recently suggested new code.
>>
>> Old problems are:
>> - the %NONAME-?-NOMSG messages, which are generated by
On 3/24/2014 3:07 PM, h.becker wrote:
There are several problems with the checked-in old exit handling, which
aren't resolved by the recently suggested new code.
Old problems are:
- the %NONAME-?-NOMSG messages, which are generated by VMS when a
program returns a Unix style exit code; an exit co
There are several problems with the checked-in old exit handling, which
aren't resolved by the recently suggested new code.
Old problems are:
- the %NONAME-?-NOMSG messages, which are generated by VMS when a
program returns a Unix style exit code; an exit code 2 shows as
%NONAME-E-NOMSG, Message n
On 03/11/2014 04:09 AM, John E. Malmberg wrote:
> Gnu make is already checking to see if a shell is present for other
> platforms, and is already tracking the information needed for VMS to do
> the same.
And at that point you can make sure that VMS file versions can be used
as specified on the VMS
On 3/10/2014 2:35 PM, h.becker wrote:
On 03/08/2014 02:47 PM, John E. Malmberg wrote:
Since there will only be one build procedure and one resulting binary,
there would not be two templates.
One of the main reasons for merging this fork back in is to get to one
make binary.
It's not yet deter
On 03/08/2014 02:47 PM, John E. Malmberg wrote:
> Since there will only be one build procedure and one resulting binary,
> there would not be two templates.
>
> One of the main reasons for merging this fork back in is to get to one
> make binary.
>
> The one binary where needed will check if it i
On 3/8/2014 6:15 AM, h.becker wrote:
On 03/07/2014 02:24 PM, John E. Malmberg wrote:
On 3/6/2014 6:14 PM, h.becker wrote:
...
For DCL it will be only one format.
Not true. The decc$ features can be set by logical names, and a user
may have set them for the various formats.
It as a user/adm
On 03/07/2014 02:24 PM, John E. Malmberg wrote:
> On 3/6/2014 6:14 PM, h.becker wrote:
>> ...
>> For DCL it will be only one format.
>
> Not true. The decc$ features can be set by logical names, and a user
> may have set them for the various formats.
It as a user/administrator error to enable a
On 3/6/2014 6:14 PM, h.becker wrote:
I'm still looking at this. I moved the code to places where I think they
should go, but I'm not yet done. But I have some comments:
On 03/06/2014 06:18 AM, John E. Malmberg wrote:
...
There is no way that I know of to know what foreign symbol was used to
in
I'm still looking at this. I moved the code to places where I think they
should go, but I'm not yet done. But I have some comments:
On 03/06/2014 06:18 AM, John E. Malmberg wrote:
> ...
>
> There is no way that I know of to know what foreign symbol was used to
> invoke an image. All we get is th
New patch attached as described below.
On 3/5/2014 3:30 PM, h.becker wrote:
I'm still looking at this, so I may change my mind or suggest to change
the code :-)
The main wrapper:
There were/are problems with the program name, however I'm not sure
whether the wrapper solves them. For DCL the wr
I'm still looking at this, so I may change my mind or suggest to change
the code :-)
The main wrapper:
There were/are problems with the program name, however I'm not sure
whether the wrapper solves them. For DCL the wrapper, as before,
requires a foreign command pointing to the executable (or the
* main.c, vms_main_wrapper.c (main): This fixes the VMS arvg[0] to be
the normalized program name expected by users and test scripts. This
handles the three possible syntax's that the argv[0] can be set to from
DCL, and handled removing a facility prefix.
When make is exec() from a C program,
13 matches
Mail list logo
