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
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 VMS when
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
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 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 is
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 decc$
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
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
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 the
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
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
11 matches
Mail list logo
