On Wed, 20 Aug 2025 17:41:18 -0400, Phil Smith III <[email protected]> wrote:
>Ah HAH: indeed, if I reset _BPXK_AUTOCVT to OFF >and then issue sh and do the same thing, the file is NOT tagged. >If I exit back to the original shell >--where _BPXK_AUTOCVT is allegedly OFF--and repeat, it IS tagged. This is exactly what we expect regardless of the program (in this case shell). It's very common for programs to read the env variable never update it again. Thus the need for starting a second shell. I suspect you can update your RACF profile to specify the variable along with the shell name. >...and that "fixes" it, but it breaks command completion etc. WTF You might need to tell the shell the language it should be using. Maybe there's an env variable that tells the shell how to handle this situation. Without hands on, It's difficult to say how to proceed. Talk to IBM support and maybe they know how to handle this. . >This normally shows me a nice prompt like: >(PHS) Ready; 16:35:53 /u/vendor/phs > > >But with AUTOCVT turned off, I get: >(▒▒▒▒▒▒▒▒) Ready; ▒▒z▒▒z▒▒ /u/vendor/phs > I suspect this is being passed using pipes (most likely using STDOUT & STDIN) which is files. It will take some playing around to get STDOUT & STDIN working together correctly. I also suspect that the terminal inferface is playiing a role (TSO OMVS versus TELNET). ***important*** your next 2 questions should be: How are pipes affected by autocvt and will there be an impact over time. Consider the command: tar cf - . | (cd /work/bkup/jane && tar xvf -) We know autocvt monitors the data and may change tag actions because it's found something not supported by the current ccsid. I suspect TAR will work because because unexpected characters occur almost from the start. But consider what happens if you write 2 programs that fit a specific ccsid but later start sending binary data. How willl autocvt handle the transition. Remember this is automatic and you need to understand the consequences. > it means that I screwed up yesterday and am owning up to it! Screwing up is part of life. No need to admit as long as you deal with it appropriately. The problem is with people can't accept that they are infallible. >In any case, the user that the automated build is running under is NOT me, and >that user's .profile is just: > >PATH=$PATH:/u/vendor/gzip/bin; export PATH >PATH=$PATH:/u/vendor/local/python/bin:/usr/lpp/java/J6.0.1_64/bin >MANPATH=$MANPATH:/u/vendor/local/python/man; export MANPATH >PYTHONPATH=$PYTHONPATH:/u/vendor/local/zlib/lib; export PYTHONPATH >PS1="$ " This looks standard and I would expect that IBM has tested this. >I have asked the guy running the builds to add the chtag and TYPE E > to the FTP process and we'll see if that fixes it. >Still wish I understood this... I think you now have a good grasp on this. Just don't overthink this nor let it overwhelm you. Here's some things might (or might not) help: 1. Get comfortable with RUNTIME(AUTOTAG and AUTOCVT). Some programs are compiled with these parms and others don't. Apparently, shell is AUTOCVT. Others won't be. AUTOCVT won't be cheap to use and this option affects all programs compiled with this option. 2. CHTAG is for existing files to turn it on or off as needed. 3. Your guy, may or may not want to integrate touch and chtag into his build to avoid manual chtag. 4. Maybe you can find some who is familiar with how autocvt analyzes the data to determine tags. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
