Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
git on z/OS
589 views
Skip to first unread message
Jerry Callen
Aug 10, 2016, 9:17:03 AM8/10/16
to
[Prompted by mentions of git on another thread]
Rocket is in the process of porting git to z/OS (on USS, of course). As others have noted, it's challenging, given the ASCII/EBCDIC issues. Nonetheless, we hope to have a public beta available by the end of the year; it will be announced on Rocket's open source forum at:
http://forum.rocketsoftware.com/c/rocket-z-os-open-source-languages-tools
At least initially (and, I suspect, forever...), it will only support USS files, not MVS datasets (that's a whole nother kettle 'o fish...).
Meanwhile: I use git with z/OS using the "large sledgehammer" approach. I keep my actual git repositories on Windows and use WinSCP to periodically copy the source back and forth between Windows and z/OS. Crude, but functional. Once on Windows, I can push/pull github repos. Look here for a repos containing z/OS source:
https://github.com/zorts/pause_release
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Rocket is in the process of porting git to z/OS (on USS, of course). As others have noted, it's challenging, given the ASCII/EBCDIC issues. Nonetheless, we hope to have a public beta available by the end of the year; it will be announced on Rocket's open source forum at:
http://forum.rocketsoftware.com/c/rocket-z-os-open-source-languages-tools
At least initially (and, I suspect, forever...), it will only support USS files, not MVS datasets (that's a whole nother kettle 'o fish...).
Meanwhile: I use git with z/OS using the "large sledgehammer" approach. I keep my actual git repositories on Windows and use WinSCP to periodically copy the source back and forth between Windows and z/OS. Crude, but functional. Once on Windows, I can push/pull github repos. Look here for a repos containing z/OS source:
https://github.com/zorts/pause_release
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
Aug 10, 2016, 10:28:39 AM8/10/16
to
On 8/10/2016 6:16 AM, Jerry Callen wrote:
> Meanwhile: I use git with z/OS using the "large sledgehammer" approach. I keep my actual git repositories on Windows and use WinSCP to periodically copy the source back and forth between Windows and z/OS.
We maintain our git repositories on z/OS via the SMB server.
> Meanwhile: I use git with z/OS using the "large sledgehammer" approach. I keep my actual git repositories on Windows and use WinSCP to periodically copy the source back and forth between Windows and z/OS.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
Kirk Wolf
Aug 10, 2016, 11:09:55 AM8/10/16
to
Ed -
to clarify - your clients all have the git remote repo mounted with SMB and
then they use the "Local Protocol" ?
This is fine for some environments, but giving everyone r/w mounts to the
repo file system can be a little dangerous.
(for git connection protocols, see:
https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols )
Therefore I would think that it would be nice for many to have a git server
port for z/OS that would run with the ssh protocol.
Then again, for many I wouldn't see a huge benefit to having a git server
on z/OS at all. The server could be anywhere that is vigorously secure
and backed up.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Wed, Aug 10, 2016 at 9:28 AM, Ed Jaffe <edj...@phoenixsoftware.com>
wrote:
to clarify - your clients all have the git remote repo mounted with SMB and
then they use the "Local Protocol" ?
This is fine for some environments, but giving everyone r/w mounts to the
repo file system can be a little dangerous.
(for git connection protocols, see:
https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols )
Therefore I would think that it would be nice for many to have a git server
port for z/OS that would run with the ssh protocol.
Then again, for many I wouldn't see a huge benefit to having a git server
on z/OS at all. The server could be anywhere that is vigorously secure
and backed up.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Wed, Aug 10, 2016 at 9:28 AM, Ed Jaffe <edj...@phoenixsoftware.com>
wrote:
Paul Gilmartin
Aug 10, 2016, 11:27:04 AM8/10/16
to
On Wed, 10 Aug 2016 08:16:50 -0500, Jerry Callen <jca...@NARSIL.ORG> wrote:
>[Prompted by mentions of git on another thread]
>
>Rocket is in the process of porting git to z/OS (on USS, of course). As others have noted, it's challenging, given the ASCII/EBCDIC issues. ...
>[Prompted by mentions of git on another thread]
>
>
>http://forum.rocketsoftware.com/c/rocket-z-os-open-source-languages-tools
>https://github.com/zorts/pause_release
>
What would be the obstacles to building it in Enhanced ASCII mode? I know
there are many; I've never succeed with anything significantly larger than
"Hello, World" in Enhanced ASCII.
-- gil
Kirk Wolf
Aug 10, 2016, 11:32:16 AM8/10/16
to
Gil,
You think that Enhanced ASCII support in z/OS is crap? I've never heard
that before :-)
You think that Enhanced ASCII support in z/OS is crap? I've never heard
that before :-)
Paul Gilmartin
Aug 10, 2016, 11:41:37 AM8/10/16
to
On Wed, 10 Aug 2016 10:32:03 -0500, Kirk Wolf wrote:
>
>You think that Enhanced ASCII support in z/OS is crap? I've never heard
>that before :-)
>
You mean I forgot to tell you?
>
>You think that Enhanced ASCII support in z/OS is crap? I've never heard
>that before :-)
>
It would be somewhat better if the RTL had support for Curses and X11.
>> >Rocket is in the process of porting git to z/OS (on USS, of course). As
>> others have noted, it's challenging, given the ASCII/EBCDIC issues. ...
>> >
David Crayford
Aug 10, 2016, 7:44:32 PM8/10/16
to
Looks like Rockets R port is using Enhanced ASCII
http://forum.rocketsoftware.com/t/r-the-language-for-statistical-computing-is-now-on-z-os/297.
http://forum.rocketsoftware.com/t/r-the-language-for-statistical-computing-is-now-on-z-os/297.
John McKown
Aug 10, 2016, 8:03:06 PM8/10/16
to
On Wed, Aug 10, 2016 at 6:44 PM, David Crayford <dcra...@gmail.com> wrote:
> Looks like Rockets R port is using Enhanced ASCII
> http://forum.rocketsoftware.com/t/r-the-language-for-statist
> ical-computing-is-now-on-z-os/297.
>
I have a friend, ex co-worker, who now works for Rocket. Sounds like a
> Looks like Rockets R port is using Enhanced ASCII
> http://forum.rocketsoftware.com/t/r-the-language-for-statist
> ical-computing-is-now-on-z-os/297.
>
great place to work. Other than the "good will", I don't know why they are
doing these ports, but I'm very grateful for it. I really like R, the
little I know of it. If they're listening, a full port of GNU awk would be
fantastic (especially with the networking stuff). Also the Google "Go"
language (may be even more difficult since it specifically says that it
only supports UNICODE)
Klein bottle for rent -- inquire within.
Maranatha! <><
John McKown
David Crayford
Aug 10, 2016, 8:23:26 PM8/10/16
to
On 11/08/2016 8:02 AM, John McKown wrote:
> On Wed, Aug 10, 2016 at 6:44 PM, David Crayford <dcra...@gmail.com> wrote:
>
>> Looks like Rockets R port is using Enhanced ASCII
>> http://forum.rocketsoftware.com/t/r-the-language-for-statist
>> ical-computing-is-now-on-z-os/297.
>>
> I have a friend, ex co-worker, who now works for Rocket. Sounds like a
> great place to work. Other than the "good will", I don't know why they are
> doing these ports, but I'm very grateful for it.
>
Of course we're all pleased that Rocket are porting good stuff to z/OS
> On Wed, Aug 10, 2016 at 6:44 PM, David Crayford <dcra...@gmail.com> wrote:
>
>> Looks like Rockets R port is using Enhanced ASCII
>> http://forum.rocketsoftware.com/t/r-the-language-for-statist
>> ical-computing-is-now-on-z-os/297.
>>
> I have a friend, ex co-worker, who now works for Rocket. Sounds like a
> great place to work. Other than the "good will", I don't know why they are
> doing these ports, but I'm very grateful for it.
>
but it's not all about altruism. IBM have partnered with Rocket for the
z/OS port of Apache Spark. For Spark on z/OS to be credible you need at
least Python and almost certainly R for SparkR. For Spark to fly (groan)
on z/OS you really do need Rockets data virtualization product to access
legacy data. That's good
news for Rocket. Rocket aren't charging OTC for the Spark DVS, only S&S.
That sure is a change in business model for a mainframe software vendor.
Jerry Callen
Aug 11, 2016, 8:23:05 AM8/11/16
to
On Wed, 10 Aug 2016 10:26:55 -0500, Paul Gilmartin <PaulGB...@AIM.COM> wrote (regarding porting git to z/OS):
>What would be the obstacles to building it in Enhanced ASCII mode?
For a tool like git that has to straddle character encoding worlds, enhanced ASCII support (EAS) brings only limited value. We're likely to explicitly convert data, and control tagging, for text moving into and out of the repository, rather than relying on EAS to Do The Right Thing. Current plans (subject to change, of course...) are to support checkout as ISO-8859-1, UTF-8 or IBM-1047 (or conceivably ANY encoding supported by iconv) and respect tags on add/commit of new files. As I said - it's a challenging problem. Git currently ignores encoding altogether, with the exception of line endings (the perennial CRLF/LF/CR/whatever problem...).
>What would be the obstacles to building it in Enhanced ASCII mode?
Given the complexity of the problem, I think IBM has done a fairly decent job with EAS. Most of the existing C/C++ tool chain (most notably, of course, xlc) do a pretty decent job of handling a mix of character encodings in its input files, and the bulk of the POSIX system and library interfaces support ASCII. See http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxbd00/libfuncsupport.htm
-- Jerry
Kirk Wolf
Aug 11, 2016, 11:14:11 AM8/11/16
to
Agreed - Rocket's work to port updated tools to z/OS is great. I believe
that they have a paid support model, which hopefully will be embraced by
the community so that they can justify even more good work.
Regarding System R, you can also run this from z/OS batch using the Co:Z
Launcher utility. See an example below.
(The Co:Z Co-Processing Toolkit is available under our free Community
License and can be downloaded without registering.)
Some features of this approach:
- Run R under the control of a regular z/OS batch job step.
- processing is offloaded to a Linux server; perhaps an IFL
- z/OS datasets can be accessed by the distribute process via the job step
- output goes to z/OS spool files
- the exit code of the remote process is adopted as the step condition code
//R EXEC PROC=COZPROC,
// ARGS='ki...@linux1.dovetail.com'
//LIFEEXP DD DISP=SHR,DSN=KIRK.LIFEEXP.DATA
//STDIN DD *
# Run the R statistical system with an inline program
# This example is a 2-dimensional multiple regression
# The dataset is read from a DD using "fromdsn" in a R pipe file.
# The source of the data is:
# www.sci.usq.edu.au/staff/dunn/Datasets/applications/health/lifeexp.html
R --no-save <<EOB
mypipe = pipe("fromdsn DD:LIFEEXP", open="r")
life = read.table(mypipe, header=TRUE)
close(mypipe)
multilinearFit = lm(LifeExp~PeoplePerTV+PeoplePerDoctor,data=life)
summary(multilinearFit)
EOB
//
PS> Co:Z is agnostic about what you run with it. You can offload SAS in a
similar way:
http://dovetail.com/products/casestudysas.html
that they have a paid support model, which hopefully will be embraced by
the community so that they can justify even more good work.
Regarding System R, you can also run this from z/OS batch using the Co:Z
Launcher utility. See an example below.
(The Co:Z Co-Processing Toolkit is available under our free Community
License and can be downloaded without registering.)
Some features of this approach:
- Run R under the control of a regular z/OS batch job step.
- processing is offloaded to a Linux server; perhaps an IFL
- z/OS datasets can be accessed by the distribute process via the job step
- output goes to z/OS spool files
- the exit code of the remote process is adopted as the step condition code
//R EXEC PROC=COZPROC,
// ARGS='ki...@linux1.dovetail.com'
//LIFEEXP DD DISP=SHR,DSN=KIRK.LIFEEXP.DATA
//STDIN DD *
# Run the R statistical system with an inline program
# This example is a 2-dimensional multiple regression
# The dataset is read from a DD using "fromdsn" in a R pipe file.
# The source of the data is:
# www.sci.usq.edu.au/staff/dunn/Datasets/applications/health/lifeexp.html
R --no-save <<EOB
mypipe = pipe("fromdsn DD:LIFEEXP", open="r")
life = read.table(mypipe, header=TRUE)
close(mypipe)
multilinearFit = lm(LifeExp~PeoplePerTV+PeoplePerDoctor,data=life)
summary(multilinearFit)
EOB
//
PS> Co:Z is agnostic about what you run with it. You can offload SAS in a
similar way:
http://dovetail.com/products/casestudysas.html
Scott Ford
Aug 12, 2016, 1:28:28 PM8/12/16
to
We (IDMWORKS) are using Git via 'bitbucket.org' , we are in the process of
developing CI PC to Mainframe integrated processes.
The toughest thing for e is the Git organization.
Scott
On Thursday, August 11, 2016, Kirk Wolf <ki...@dovetail.com> wrote:
> Agreed - Rocket's work to port updated tools to z/OS is great. I believe
> that they have a paid support model, which hopefully will be embraced by
> the community so that they can justify even more good work.
>
> Regarding System R, you can also run this from z/OS batch using the Co:Z
> Launcher utility. See an example below.
> (The Co:Z Co-Processing Toolkit is available under our free Community
> License and can be downloaded without registering.)
>
> Some features of this approach:
>
> - Run R under the control of a regular z/OS batch job step.
> - processing is offloaded to a Linux server; perhaps an IFL
> - z/OS datasets can be accessed by the distribute process via the job step
> - output goes to z/OS spool files
> - the exit code of the remote process is adopted as the step condition code
>
>
> //R EXEC PROC=COZPROC,
> // ARGS='ki...@linux1.dovetail.com <javascript:;>'
developing CI PC to Mainframe integrated processes.
The toughest thing for e is the Git organization.
Scott
On Thursday, August 11, 2016, Kirk Wolf <ki...@dovetail.com> wrote:
> Agreed - Rocket's work to port updated tools to z/OS is great. I believe
> that they have a paid support model, which hopefully will be embraced by
> the community so that they can justify even more good work.
>
> Regarding System R, you can also run this from z/OS batch using the Co:Z
> Launcher utility. See an example below.
> (The Co:Z Co-Processing Toolkit is available under our free Community
> License and can be downloaded without registering.)
>
> Some features of this approach:
>
> - Run R under the control of a regular z/OS batch job step.
> - processing is offloaded to a Linux server; perhaps an IFL
> - z/OS datasets can be accessed by the distribute process via the job step
> - output goes to z/OS spool files
> - the exit code of the remote process is adopted as the step condition code
>
>
> //R EXEC PROC=COZPROC,
> //LIFEEXP DD DISP=SHR,DSN=KIRK.LIFEEXP.DATA
> //STDIN DD *
> # Run the R statistical system with an inline program
> # This example is a 2-dimensional multiple regression
> # The dataset is read from a DD using "fromdsn" in a R pipe file.
> # The source of the data is:
> # www.sci.usq.edu.au/staff/dunn/Datasets/applications/health/lifeexp.html
>
> R --no-save <<EOB
> mypipe = pipe("fromdsn DD:LIFEEXP", open="r")
> life = read.table(mypipe, header=TRUE)
> close(mypipe)
> multilinearFit = lm(LifeExp~PeoplePerTV+PeoplePerDoctor,data=life)
> summary(multilinearFit)
> EOB
> //
>
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> PS> Co:Z is agnostic about what you run with it. You can offload SAS in a
> similar way:
> http://dovetail.com/products/casestudysas.html
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to list...@listserv.ua.edu <javascript:;> with the message:
> //STDIN DD *
> # Run the R statistical system with an inline program
> # This example is a 2-dimensional multiple regression
> # The dataset is read from a DD using "fromdsn" in a R pipe file.
> # The source of the data is:
> # www.sci.usq.edu.au/staff/dunn/Datasets/applications/health/lifeexp.html
>
> R --no-save <<EOB
> mypipe = pipe("fromdsn DD:LIFEEXP", open="r")
> life = read.table(mypipe, header=TRUE)
> close(mypipe)
> multilinearFit = lm(LifeExp~PeoplePerTV+PeoplePerDoctor,data=life)
> summary(multilinearFit)
> EOB
> //
>
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> PS> Co:Z is agnostic about what you run with it. You can offload SAS in a
> similar way:
> http://dovetail.com/products/casestudysas.html
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
marcel....@gmail.com
Oct 15, 2016, 9:54:51 AM10/15/16
to
We run jgit in USS with is connected to a central github.
Each compile triggers a copy job (incl. iconv) for the codepage conversion EBCDIC to UTF-8 and commit. In case the compile job was successful we push the artefact to github.
We run this now for more then a year without any issues on the System z side
have fun
Each compile triggers a copy job (incl. iconv) for the codepage conversion EBCDIC to UTF-8 and commit. In case the compile job was successful we push the artefact to github.
We run this now for more then a year without any issues on the System z side
have fun
0 new messages