On 2020-03-02 10:08 AM, Paul Gilmartin wrote:
On Sun, 1 Mar 2020 08:11:19 -0600, Support, DUNNIT SYSTEMS LTD. wrote:
OK, let me rephrase my question:
I see that the files are most likely in EBCDIC and just need a binary transfer
to z/OS. Is that correct?
It's EBCDIC, but beware: the line breaks are x'25' rather than
the perplexing x'15' that z/OS expects.
It's not EBCDIC by the time it's pushed to Github! The working tree may
have been EBCDIC but but Rockets git port will perform code page
conversion using the settings in .gitattributes. IIRC, git-encoding is
fixed at ISO8859-1
https://github.com/rscott-rocket/mxe/blob/master/.gitattributes
Line endings are handled automatically or explicitly using configuration.
https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings
If so, I notice all the files have extension names on them, after the member
name. Is there an easy way to transfer these to a PDS or do the extension names
get in the way, due to 8-character member name conventions? Thanks again.
Transfer the .zip in binary; unzip with "jar". The files will be extracted
to z/OS UNIX directory which is friendly to extension names.
HLASM ought to learn to deal with extensions. Most cross-assemblers
can do so.
The first 4 commands in README.md merely say "Copy". This is pretty
vague.
The x'25' linebreaks lead me to suspect the developers built and tested
from an ASCII tree with a cross-assembler then converted to EBCDIC
using a non-z tool that was unaware of the idiosyncratic z/OS line separator
convention.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
