hmmm .. so I have 300 syntactical incorrect but running rexx'es . Is this use of !! instead of || customizable by a sysprog ? - I guess the || isn't available on the HOSTs codepage 273 or is mapped to annother char. (Z/OS 1.9 TSO)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
still open for me:
so I have 300 syntactical incorrect but running rexx. Is the
use of !! instead of || customizable by a sysprog ? - I guess the || isn't
available on the HOSTs codepage 273 or is mapped to annother char. (Z/OS 1.9 TSO)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The code points that Rexx on TSO recognizes as operator characters is a fixed EBCDIC code point that may display using different glyphs in various locales. The character does not change...it is still considered the | character even though it might display as a ! for you. In fact, the ! character is a valid symbol character, so attempting to add this as an operation would creates some significant incompatibilities.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
even though it might display as a ! for you ..
I understand this partly. When I type in a !! for concatenation it works ( I do not type in a || and get a !! on display) even printing, transfers via FTP and so on gives me the !. It seems to me that the ! ist a true ! and the REXX interpreter or s.th. else translates this.
(If I typein the | within TSO, it is mapped into a lttle "hook" symbol and this is rejected by the MF REXX interpreter)
Either way, you won't offer this with oorexx.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't feel alone. I have run into this problem myself. This is NOT a Rexx problem, it is an FTP problem. Depending on how the ftp server is configured on the mainframe the '|' character can be translated in several ways. This is due to the source and target code pages used for the translation. There is nothing you can do to correct this. If it is a real problem you will need to contact you mainframe admin and see what can be done about modifying the translation code pages.
BTW, the FTP server on the mainframe has two set of translation pages, one for uploads and one for downloads. The default install for the mainframe actually uses different code pages for each direction. Of course, this can lead to very inconsistent results for file transfers!
I hope you have better luck with your mainframe admin than I have had in the past with this issue. Most of them tend to ignore this issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
!! are not concatenation characters for mainframe Rexx. || has always been the only explicit concatentation operator.
hmmm .. so I have 300 syntactical incorrect but running rexx'es . Is this use of !! instead of || customizable by a sysprog ? - I guess the || isn't available on the HOSTs codepage 273 or is mapped to annother char. (Z/OS 1.9 TSO)
still open for me:
so I have 300 syntactical incorrect but running rexx. Is the
use of !! instead of || customizable by a sysprog ? - I guess the || isn't
available on the HOSTs codepage 273 or is mapped to annother char. (Z/OS 1.9 TSO)
The code points that Rexx on TSO recognizes as operator characters is a fixed EBCDIC code point that may display using different glyphs in various locales. The character does not change...it is still considered the | character even though it might display as a ! for you. In fact, the ! character is a valid symbol character, so attempting to add this as an operation would creates some significant incompatibilities.
Either way, you won't offer this with oorexx.
Don't feel alone. I have run into this problem myself. This is NOT a Rexx problem, it is an FTP problem. Depending on how the ftp server is configured on the mainframe the '|' character can be translated in several ways. This is due to the source and target code pages used for the translation. There is nothing you can do to correct this. If it is a real problem you will need to contact you mainframe admin and see what can be done about modifying the translation code pages.
BTW, the FTP server on the mainframe has two set of translation pages, one for uploads and one for downloads. The default install for the mainframe actually uses different code pages for each direction. Of course, this can lead to very inconsistent results for file transfers!
I hope you have better luck with your mainframe admin than I have had in the past with this issue. Most of them tend to ignore this issue.