Having installed
Tool: make
Version: 4.1
Build Number: 0002
now running make I get rubbish characters
./make
/,�������+?��/����ˀ����������/>��>?�/,���%���?�>�����?��#
Actually the output is ascii and when translated is:
make: *** No targets specified and no makefile found. Stop.
So it looks to me that make 4.1 is unusable. Or did I miss anything?
–
Manfred
How are you accessing USS?
I was unable to reproduce this when logging in via either telnet or SSH. I could reproduce it when logging into TSO and then using omvs to access the shell.
The problem can be corrected by setting _BPXK_AUTOCVT=ON
Having installed
Tool: make
Version: 4.1
Build Number: 0002
now running make I get rubbish characters
./make
/,�������+?��/����ˀ����������/>��>?�/,���%���?�>�����?��#
Actually the output is ascii and when translated is:
make: *** No targets specified and no makefile found. Stop.
So it looks to me that make 4.1 is unusable. Or did I miss anything?
–
Manfred
I log in via ssh and it happens. Doesn’t matter if _BPXK_AUTOCVT=ON is set or not.
I log in via ssh and it happens. Doesn’t matter if _BPXK_AUTOCVT=ON is set or not.
I should add that in the same session invoking make 4.0 works ok.
I should add that in the same session invoking make 4.0 works ok.
Are you using PuTTY to log in via ssh or some other tool? I am using PuTTY (from Windows) to log in via both SSH and telnet, and don’t see the problem. What shell are you using?
Also, what does your environment look like? Can you run:
env | sort
and provide the output?
4.1 was ported using enhanced ASCII support, so it’s not too surprising that 4.0 and 4.1 would exhibit different behavior, but both 4.0 and 4.1 are working OK for me.
Are you using PuTTY to log in via ssh or some other tool? I am using PuTTY (from Windows) to log in via both SSH and telnet, and don’t see the problem. What shell are you using?
Also, what does your environment look like? Can you run:
env | sort
and provide the output?
4.1 was ported using enhanced ASCII support, so it’s not too surprising that 4.0 and 4.1 would exhibit different behavior, but both 4.0 and 4.1 are working OK for me.
I 'm using OpenSSH in Fedora Linux to log into z/OS UNIX.
Are you using PuTTY to log in via ssh or some other tool? I am using PuTTY (from Windows) to log in via both SSH and telnet, and don’t see the problem. What shell are you using?
Also, what does your environment look like? Can you run:
env | sort
and provide the output?
4.1 was ported using enhanced ASCII support, so it’s not too surprising that 4.0 and 4.1 would exhibit different behavior, but both 4.0 and 4.1 are working OK for me.
I tried to minimize the environment by deleting the ~/.profile. So, only /etc/profile will be sourced.
AOPCONF=/etc/Printsrv/aopd.conf
AOPMSG_CONF=/etc/Printsrv/aopmsg.conf
HOME=/u/demnt15
JAVA_HOME=/usr/lpp/java2600/J6.0
LANG=C
LIBPATH=/usr/lpp/Printsrv/lib:/lib:/usr/lib:.
LOGNAME=DEMNT15
MAIL=/usr/mail/DEMNT15
MANPATH=/usr/lpp/Printsrv/man/%L:
NLSPATH=/usr/lpp/Printsrv/%L/%N:/usr/lib/nls/msg/%L/%N
PATH=/_PRDS/MVSTOOLS/bin:/usr/lpp/Printsrv/bin:/usr/lpp/java2600/J6.0/bin:/bin:/usr/bin:/usr/sbin:.:/usr/lpp/java2600/J6.0/bin
SHELL=/bin/sh
SSH_CLIENT=9.145.15.37 41690 22
SSH_CONNECTION=9.145.15.37 41690 9.149.157.65 22
SSH_TTY=/dev/ttyp0000
STEPLIB=none
TERM=xterm-256color
TZ=UTC0
USER=DEMNT15
_=/bin/env
_BPX_SHAREAS=YES
_BPX_SPAWN_SCRIPT=YES
I tried to minimize the environment by deleting the ~/.profile. So, only /etc/profile will be sourced.
AOPCONF=/etc/Printsrv/aopd.conf
AOPMSG_CONF=/etc/Printsrv/aopmsg.conf
HOME=/u/demnt15
JAVA_HOME=/usr/lpp/java2600/J6.0
LANG=C
LIBPATH=/usr/lpp/Printsrv/lib:/lib:/usr/lib:.
LOGNAME=DEMNT15
MAIL=/usr/mail/DEMNT15
MANPATH=/usr/lpp/Printsrv/man/%L:
NLSPATH=/usr/lpp/Printsrv/%L/%N:/usr/lib/nls/msg/%L/%N
PATH=/_PRDS/MVSTOOLS/bin:/usr/lpp/Printsrv/bin:/usr/lpp/java2600/J6.0/bin:/bin:/usr/bin:/usr/sbin:.:/usr/lpp/java2600/J6.0/bin
SHELL=/bin/sh
SSH_CLIENT=9.145.15.37 41690 22
SSH_CONNECTION=9.145.15.37 41690 9.149.157.65 22
SSH_TTY=/dev/ttyp0000
STEPLIB=none
TERM=xterm-256color
TZ=UTC0
USER=DEMNT15
_=/bin/env
_BPX_SHAREAS=YES
_BPX_SPAWN_SCRIPT=YES
I tried using openssh from Linux as well; still works.
The one potentially significant difference in our environments is that I have this set:
_CEE_RUNOPTS=POS(ON) FILET(AUTOCVT,AUTOTAG)
Further, I cannot unset it. See: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcpx01/cbc1p2351.htm
To quote that, in part:
The _CEE_RUNOPTS environment variable has a unique behavior. It can be unset, or modified, but will be re-created or added to across an exec to effect the propagation of invocation Language Environment runtime options. This behavior is designed specifically to allow runtime options such as TRACE to take effect for parts of an application which are not invoked directly by the user. Without this behavior, the external TRACE option could not be propagated to parts of an application that are executed using one of the exec family of functions.
I think this is because I have my login shell set to bash 2.03, rather than /bin/sh.
So, can you try:
- exporting that variable:
export _CEE_RUNOPTS="POS(ON) FILET(AUTOCVT,AUTOTAG)", and then trying make 4.1
- invoking bash after you log in, and then trying make 4.1
– Jerry
I tried using openssh from Linux as well; still works.
The one potentially significant difference in our environments is that I have this set:
_CEE_RUNOPTS=POS(ON) FILET(AUTOCVT,AUTOTAG)
Further, I cannot unset it. See: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcpx01/cbc1p2351.htm
To quote that, in part:
The _CEE_RUNOPTS environment variable has a unique behavior. It can be unset, or modified, but will be re-created or added to across an exec to effect the propagation of invocation Language Environment runtime options. This behavior is designed specifically to allow runtime options such as TRACE to take effect for parts of an application which are not invoked directly by the user. Without this behavior, the external TRACE option could not be propagated to parts of an application that are executed using one of the exec family of functions.
I think this is because I have my login shell set to bash 2.03, rather than /bin/sh.
So, can you try:
- exporting that variable:
export _CEE_RUNOPTS="POS(ON) FILET(AUTOCVT,AUTOTAG)", and then trying make 4.1
- invoking bash after you log in, and then trying make 4.1
– Jerry
Ok.
- Exporting _CEE_RUNOPTS=“POS(ON) FILET(AUTOCVT,AUTOTAG)” didn’t help. Still ascii garbage when calling make 4.1
- invoking bash 4.2.53, then exporting _CEE_RUNOPTS=“POS(ON) FILET(AUTOCVT,AUTOTAG)” and make 4.1 works ok.
Please note, that also bash 4.3.46 isn’t usable as it requires to tag each ebcdic file it sources as such.
–
Manfred
Things are really weird
- I log into z/OS Unix having /bin/sh as shell. No CEERUNOPTS setting.
make 4.1 yields garbage
- Now invoking bash 4.2.53, and exporting CEERUNOPTS. No garbage with make 4.1
- Then leaving bash (Ctri-d) and being back into /bin/sh. make 4.1 still works ok.
Confused.
– Manfred
When you log in via SSH, one of the environment variables that gets set is SSH_TTY. Just for grins, can you:
- log in
- run
ls -lT $SSH_TTY
- invoke bash (4.2.53, or 2.03, I don’t think it matters)
- run
ls -lT $SSH_TTY
- try make 4.1. Do you get garbage?
- run
ls -lT $SSH_TTY
- export
_CEE_RUNOPTS
- try make 4.1
- run
ls -lT $SSH_TTY
- exit bash (returning to your original login shell)
- run
ls -lT $SSH_TTY
I am speculating (handwave, handwave…) that make 4.1 is setting a file tag on the pseudo-tty that persists after it exits.
This is a very weird problem. It may make more sense for us to work on this together with a screen share session. I can’t do that today, but we could try it tomorrow. PM me if you want to try that.
– Jerry
When you log in via SSH, one of the environment variables that gets set is SSH_TTY. Just for grins, can you:
- log in
- run
ls -lT $SSH_TTY
- invoke bash (4.2.53, or 2.03, I don’t think it matters)
- run
ls -lT $SSH_TTY
- try make 4.1. Do you get garbage?
- run
ls -lT $SSH_TTY
- export
_CEE_RUNOPTS
- try make 4.1
- run
ls -lT $SSH_TTY
- exit bash (returning to your original login shell)
- run
ls -lT $SSH_TTY
I am speculating (handwave, handwave…) that make 4.1 is setting a file tag on the pseudo-tty that persists after it exits.
This is a very weird problem. It may make more sense for us to work on this together with a screen share session. I can’t do that today, but we could try it tomorrow. PM me if you want to try that.
– Jerry
Updating with a portion of a note from Manfred:
Hi Jerry,
Your assumption was correct: make 4.1 tags the$SSH_TTY file as ascii:
t ISO8859-1 T=on crw–w---- 1 DEMNT15 TTY 2, 0 Mar 31 12:27 /dev/ttyp0000
Updating with a portion of a note from Manfred:
Hi Jerry,
Your assumption was correct: make 4.1 tags the$SSH_TTY file as ascii:
t ISO8859-1 T=on crw–w---- 1 DEMNT15 TTY 2, 0 Mar 31 12:27 /dev/ttyp0000
Just to let you know: When doing relogon the $SSH_TTY file is no longer tagged.
Just to let you know: When doing relogon the $SSH_TTY file is no longer tagged.
Did you get the same ptty or a different one?
– Jerry

Did you get the same ptty or a different one?
– Jerry

The same one, and then untagged when logged in again.
– Manfred