Re: New free / open source z/OS tools from Dovetailed Technologies

[Timothy Sipples]

Kirk Wolf wrote:
>Are you running Kerberos enabled NFS over IPSec?

I was going to mention IPSec, but you partially beat me to it. FTP over
IPSec is another possible file transfer option. Then it's possible to use
the Ant task for FTP (within its remaining limitations) but have an
encrypted network connection. Other connections can ride "shotgun" over the
same IPSec tunnel if desired -- TN3270E, Telnet, SNTP, NFS, MQ, HTTP,
database connections (e.g. JDBC), IP sockets, Enterprise Extender,
CIFS/SMB, etc. You can also configure separate IPSec tunnels to support
connections that shouldn't be combined on the same tunnel. There's a lot of
merit in an IPSec-based approach, including for developers who might need
half a dozen connection types to a development LPAR all at once. You can
encrypt them separately of course (and probably should in many use cases),
or you can ride them all over IPSec.

Please note that OpenSSH is now part of the base z/OS 2.2 operating system.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Paul Gilmartin]

On Wed, 18 Jan 2017 14:16:55 -0400, Clark Morris wrote:
>
>>We used to do a lot of that.  NFS has liberated us from a lot of file 
>>shuffling -- files
>>appear alike on our desktops and on z/OS.  We discarded our STC.  ISPF 3.17 is
>>your friend.
>
>How do you handle ASCII/ISO- - EBCDIC between platforms and the
>different ways of storing information?
>
For most purposes, NFS ISO8859-1<->IBM-1047 suffices.  In some cases, we
have dual mountpoints, with and without translation.  In other cases, we
pipe through iconv.  Likewise, for legacy data sets we can bootleg a translation
option in the pathname.

"Different ways"?  Isn't it all magnetic domains in ferrite?  (We don't use
paper tape.)  For BSAM/QSAM, the JCL/BPXWDYN FILEDATA option is
useful.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Kirk Wolf]

NFS seems like a good option if you can deal with connectivity and security
issues.  Are you running Kerberos enabled NFS over IPSec?

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, Jan 18, 2017 at 11:46 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 18 Jan 2017 11:13:04 -0600, Ray Pearce wrote:
>
> >We have also been looking at a similar issue here at Macro 4 but with a
> slightly different approach for our mainframe development.
> >We now use Subversion as our source repository, Eclipse as our IDE and we
> utilise Apache Ant and Jenkins for our development and production builds.
> >However we do not use USS, we use z/OS for our compiles and assemblies –
> and this works for all of our languages; Assembler, Cobol, PL/1, C, REXX,
> Java, etc.
> >We have the advantage that some of our products already have a z/OS STC
> as part of their installation and this STC has APIs allowing us to move the
> source from our workstations to z/OS, submit the JCL for the compiles,
> assemblies, etc. and capture and return any output and listings etc.
> >
> We used to do a lot of that.  NFS has liberated us from a lot of file
> shuffling -- files
> appear alike on our desktops and on z/OS.  We discarded our STC.  ISPF
> 3.17 is
> your friend.
>
> >By using z/OS it meant we could reuse all of the build JCL that we
> already had in place which was a big help with the transition.
> >
> I could imagine makefile recipes that (tailor and) submit JCL.
>
> -- 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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Clark Morris]

[Default] On 18 Jan 2017 09:46:08 -0800, in bit.listserv.ibm-main
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:

>On Wed, 18 Jan 2017 11:13:04 -0600, Ray Pearce wrote:
>
>>We have also been looking at a similar issue here at Macro 4 but with a 
>>slightly different approach for our mainframe development.
>>We now use Subversion as our source repository, Eclipse as our IDE and we 
>>utilise Apache Ant and Jenkins for our development and production builds.
>>However we do not use USS, we use z/OS for our compiles and assemblies – and 
>>this works for all of our languages; Assembler, Cobol, PL/1, C, REXX, Java, 
>>etc.
>>We have the advantage that some of our products already have a z/OS STC as 
>>part of their installation and this STC has APIs allowing us to move the 
>>source from our workstations to z/OS, submit the JCL for the compiles, 
>>assemblies, etc. and capture and return any output and listings etc.
>>
>We used to do a lot of that.  NFS has liberated us from a lot of file 
>shuffling -- files
>appear alike on our desktops and on z/OS.  We discarded our STC.  ISPF 3.17 is
>your friend.

How do you handle ASCII/ISO- - EBCDIC between platforms and the
different ways of storing information?

C;ark Morris 
>
>>By using z/OS it meant we could reuse all of the build JCL that we already 
>>had in place which was a big help with the transition. 
>>
>I could imagine makefile recipes that (tailor and) submit JCL.
>
>-- 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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Paul Gilmartin]

On Wed, 18 Jan 2017 11:13:04 -0600, Ray Pearce wrote:

>We have also been looking at a similar issue here at Macro 4 but with a 
>slightly different approach for our mainframe development.
>We now use Subversion as our source repository, Eclipse as our IDE and we 
>utilise Apache Ant and Jenkins for our development and production builds.
>However we do not use USS, we use z/OS for our compiles and assemblies – and 
>this works for all of our languages; Assembler, Cobol, PL/1, C, REXX, Java, 
>etc.
>We have the advantage that some of our products already have a z/OS STC as 
>part of their installation and this STC has APIs allowing us to move the 
>source from our workstations to z/OS, submit the JCL for the compiles, 
>assemblies, etc. and capture and return any output and listings etc.
>
We used to do a lot of that.  NFS has liberated us from a lot of file shuffling 
-- files
appear alike on our desktops and on z/OS.  We discarded our STC.  ISPF 3.17 is
your friend.

>By using z/OS it meant we could reuse all of the build JCL that we already had 
>in place which was a big help with the transition. 
>
I could imagine makefile recipes that (tailor and) submit JCL.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Kirk Wolf]

Ray,

Seems like a good approach.  I personally prefer Makefiles over JCL, but
given your legacy stuff it makes perfect sense.
You might want to look at ant-ssh tasks + z/OS OpenSSH + Co:Z SFTP, since
you could (in one ssh connection) you could:

- upoad dirty source
- submit JCL
- wait for job completion
- download selected job spool files
- then use other Ant tasks to parse spool file, check step CC, etc.

(See: https://dovetail.com/docs/sftp/using.html#server_jes   - any of these
commands can be included in  actions)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, Jan 18, 2017 at 11:13 AM, Ray Pearce  wrote:

> We have also been looking at a similar issue here at Macro 4 but with a
> slightly different approach for our mainframe development.
> We now use Subversion as our source repository, Eclipse as our IDE and we
> utilise Apache Ant and Jenkins for our development and production builds.
> However we do not use USS, we use z/OS for our compiles and assemblies –
> and this works for all of our languages; Assembler, Cobol, PL/1, C, REXX,
> Java, etc.
> We have the advantage that some of our products already have a z/OS STC as
> part of their installation and this STC has APIs allowing us to move the
> source from our workstations to z/OS, submit the JCL for the compiles,
> assemblies, etc. and capture and return any output and listings etc.
> By using z/OS it meant we could reuse all of the build JCL that we already
> had in place which was a big help with the transition.
> We have also created a task that scans all the source and produces a list
> of dependencies, such as Macro and Copybook usage. Then when a developer
> updates say a Macro he does not have to remember or scan for all the source
> that is affected by the update as the build system will automatically
> compile all the components affected. They can of course optionally rebuild
> the whole application if they want with a click of a button!
> The advantages are that we utilise Open Source, and admittedly some
> in-house code, rather than potentially costly mainframe based source
> management systems, and we utilise Eclipse as the IDE which helps with
> recruitment of new talent, cross training and up training to the mainframe.
> As I expect others have found our developers have to use multiple
> languages and get involved in cross platform solutions, especially with
> digital transformation and modernization projects, so using Subversion as
> the source repository and the Eclipse IDE for editing gives us a single way
> of working across the teams.
> There is also another benefit in using Eclipse in that like Macro 4 other
> vendors have produced Eclipse interfaces to their products meaning that
> your technical teams can stay in a single environment for all their tasks,
> again assisting with recruitment and training.
> Most of the University graduates CVs that we see have Eclipse experience
> and they expect a modern interface as their working environment, and
> although us die-hards like 3270 and ISPF we have to be realistic and accept
> that the younger generation do not want to be trained in ISPF, regardless
> of whether we think it is a much better interface or not.
> This approach works well for us and it didn’t take long for us to convert
> from our old mainframe based processes to this modern agile environment.
> Even turned an old timer who was a naysayer into “I wish we had done this
> 10 years ago”!
> We even trained up an Open Source developer with mainframe knowledge by
> just using the Eclipse interfaces and now he is a contributor to our
> mainframe development – and he does not have a TSO logon!
> Of course it will also work with other Open Source tools, such as GIT, so
> you are not tied in to one product, the choice is yours.
> Drop me an email if you want to know more – keith.ban...@macro4.com.
>
> --
> 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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Kirk Wolf]

There is an Ant task for FTP:  https://ant.apache.org/manual/Tasks/ftp.html
We used to use it, but it doesn't include support FTP/SSL/TLS, and it
doesn't support running z/OS commands like ssh.

If you have IBM OpenSSH + Co:Z SFTP (both free on z/OS), you can:

- support secure transfers (we keep our ssh private user keys in our
desktop password safe)
- run remote z/OS commands via ssh (like make)
- submit JCL, wait for jobs to run, retrieve output (via Co:Z SFTP)
  (you can also use other Ant tasks to parse downloaded JES* spool files
and check return codes)


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, Jan 18, 2017 at 7:11 AM, Allan Staller 
wrote:

> I do not believe this can be done. You can look at FTPS (as opposed to
> SFTP).
>
> I think you are describing a TLS type implementation. In this case, the
> encryption is at the link level. SFTP encrypts the data.
>
> TLS normally requires application modification for use. IBM offers AT-TLS
> which does not require application modification.
>
> HTH,
>
> 
>
> Can the standard z/OS FTP with SSL be used instead of either scp or sftp?
> I don't think we have any ssh server running at all.
>
> 
>
>
> ::DISCLAIMER::
> 
> 
> 
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability
> on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error
> please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
>
> 
> 
> 
>
> --
> 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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Ray Pearce]

We have also been looking at a similar issue here at Macro 4 but with a 
slightly different approach for our mainframe development.
We now use Subversion as our source repository, Eclipse as our IDE and we 
utilise Apache Ant and Jenkins for our development and production builds.
However we do not use USS, we use z/OS for our compiles and assemblies – and 
this works for all of our languages; Assembler, Cobol, PL/1, C, REXX, Java, etc.
We have the advantage that some of our products already have a z/OS STC as part 
of their installation and this STC has APIs allowing us to move the source from 
our workstations to z/OS, submit the JCL for the compiles, assemblies, etc. and 
capture and return any output and listings etc.
By using z/OS it meant we could reuse all of the build JCL that we already had 
in place which was a big help with the transition. 
We have also created a task that scans all the source and produces a list of 
dependencies, such as Macro and Copybook usage. Then when a developer updates 
say a Macro he does not have to remember or scan for all the source that is 
affected by the update as the build system will automatically compile all the 
components affected. They can of course optionally rebuild the whole 
application if they want with a click of a button! 
The advantages are that we utilise Open Source, and admittedly some in-house 
code, rather than potentially costly mainframe based source management systems, 
and we utilise Eclipse as the IDE which helps with recruitment of new talent, 
cross training and up training to the mainframe.
As I expect others have found our developers have to use multiple languages and 
get involved in cross platform solutions, especially with digital 
transformation and modernization projects, so using Subversion as the source 
repository and the Eclipse IDE for editing gives us a single way of working 
across the teams.
There is also another benefit in using Eclipse in that like Macro 4 other 
vendors have produced Eclipse interfaces to their products meaning that your 
technical teams can stay in a single environment for all their tasks, again 
assisting with recruitment and training.
Most of the University graduates CVs that we see have Eclipse experience and 
they expect a modern interface as their working environment, and although us 
die-hards like 3270 and ISPF we have to be realistic and accept that the 
younger generation do not want to be trained in ISPF, regardless of whether we 
think it is a much better interface or not.
This approach works well for us and it didn’t take long for us to convert from 
our old mainframe based processes to this modern agile environment. Even turned 
an old timer who was a naysayer into “I wish we had done this 10 years ago”!
We even trained up an Open Source developer with mainframe knowledge by just 
using the Eclipse interfaces and now he is a contributor to our mainframe 
development – and he does not have a TSO logon!  
Of course it will also work with other Open Source tools, such as GIT, so you 
are not tied in to one product, the choice is yours.
Drop me an email if you want to know more – keith.ban...@macro4.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Denis]

Hi,
 
you can run the z/OS FTP Server and the FTP client unchanged if you set up 
AT-TLS on the mainframe and use stunnel on the FTP client platform to do the 
reverse thing that AT-TLS does on z/OS (transparent SSL).
Stunnel uses OpenSSL libraries. There is no need for a ssh server or client.
 
Just as a remark:
The data (socket) between ftp client and stunnel as well as between AT-TLS 
(z/OS TCPIP) and z/OS FTP server is not encrypted.
This means only the transport channel is encrypted.
 
Denis.
 
-Original Message-
From: Allan Staller <allan.stal...@hcl.com>
To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
Sent: Wed, Jan 18, 2017 2:12 pm
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

I do not believe this can be done. You can look at FTPS (as opposed to SFTP).

I think you are describing a TLS type implementation. In this case, the 
encryption is at the link level. SFTP encrypts the data.

TLS normally requires application modification for use. IBM offers AT-TLS which 
does not require application modification.

HTH,



Can the standard z/OS FTP with SSL be used instead of either scp or sftp?  I 
don't think we have any ssh server running at all.




::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.



--
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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Allan Staller]

I do not believe this can be done. You can look at FTPS (as opposed to SFTP).

I think you are describing a TLS type implementation. In this case, the 
encryption is at the link level. SFTP encrypts the data.

TLS normally requires application modification for use. IBM offers AT-TLS which 
does not require application modification.

HTH,



Can the standard z/OS FTP with SSL be used instead of either scp or sftp?  I 
don't think we have any ssh server running at all.




::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Frank Swarbrick]

Can the standard z/OS FTP with SSL be used instead of either scp or sftp?  I 
don't think we have any ssh server running at all.


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Kirk Wolf <k...@dovetail.com>
Sent: Tuesday, January 17, 2017 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

Scott,

Right, this is how we use it, except with C/C++/Java/Assembler and no
Cobol.
If you are familiar with make, you might also try invoking make via ant-ssh
in the same connection, which is how we do it.
The z/OS "cob2" shell command can be used to run the Cobol compier.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Dovetailed Technologies, LLC<http://dovetail.com/>
dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...



PS> I should point out that if you don't have Co:Z SFTP on z/OS but you do
have plain IBM OpenSSH, you will have to use the "scp" task instead of
"sftp" since IBM z/OS scp always does translation and IBM z/OS sftp does
not.



On Sun, Jan 15, 2017 at 2:11 PM, scott Ford <idfli...@gmail.com> wrote:

> Sorry hit the reply to fast...
>
> 1.  Clone Git Resp.
> 2.  Make changes on Cobol/Assembler
> 3.  Upload to z/OS
>
> Sounds like this Ant/XML might do it ???
>
> Scott
>
> On Sun, Jan 15, 2017 at 3:10 PM, scott Ford <idfli...@gmail.com> wrote:
>
> > Frank, All:
> >
> > I am in the same boat, I am trying to do:
> >
> > 1.
> >
> > On Sat, Jan 14, 2017 at 11:32 AM, Paul Gilmartin <000433f07816-dmarc-
> > requ...@listserv.ua.edu> wrote:
> >
> >> On Sat, 14 Jan 2017 01:52:25 +, Frank Swarbrick wrote:
> >> >
> >> >Seems to me the only think that Make would be of use for in our
> >> environment would be figuring out which COBOL programs to recompile
> when a
> >> copybook is changed.
> >> >
> >> Not necessarily in COBOL, but, heck, for that alone it's precious.  No
> >> need to
> >> remember whch JCL member to submit or tailor.  Just edit one or more
> >> sources;
> >> type "make" (no parameters necessary) and it happens.
> >>
> >> A configuration management system can provide homomorphic source
> >> directories
> >> at various development levels so the same makefile can be used at each.
> >>
> >> You can do wonderful things when you escape the constraint of a
> one-level
> >> namespace.
> >>
> >> -- 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
>

--
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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Kirk Wolf]

Scott,

Right, this is how we use it, except with C/C++/Java/Assembler and no
Cobol.
If you are familiar with make, you might also try invoking make via ant-ssh
in the same connection, which is how we do it.
The z/OS "cob2" shell command can be used to run the Cobol compier.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> I should point out that if you don't have Co:Z SFTP on z/OS but you do
have plain IBM OpenSSH, you will have to use the "scp" task instead of
"sftp" since IBM z/OS scp always does translation and IBM z/OS sftp does
not.



On Sun, Jan 15, 2017 at 2:11 PM, scott Ford  wrote:

> Sorry hit the reply to fast...
>
> 1.  Clone Git Resp.
> 2.  Make changes on Cobol/Assembler
> 3.  Upload to z/OS
>
> Sounds like this Ant/XML might do it ???
>
> Scott
>
> On Sun, Jan 15, 2017 at 3:10 PM, scott Ford  wrote:
>
> > Frank, All:
> >
> > I am in the same boat, I am trying to do:
> >
> > 1.
> >
> > On Sat, Jan 14, 2017 at 11:32 AM, Paul Gilmartin <000433f07816-dmarc-
> > requ...@listserv.ua.edu> wrote:
> >
> >> On Sat, 14 Jan 2017 01:52:25 +, Frank Swarbrick wrote:
> >> >
> >> >Seems to me the only think that Make would be of use for in our
> >> environment would be figuring out which COBOL programs to recompile
> when a
> >> copybook is changed.
> >> >
> >> Not necessarily in COBOL, but, heck, for that alone it's precious.  No
> >> need to
> >> remember whch JCL member to submit or tailor.  Just edit one or more
> >> sources;
> >> type "make" (no parameters necessary) and it happens.
> >>
> >> A configuration management system can provide homomorphic source
> >> directories
> >> at various development levels so the same makefile can be used at each.
> >>
> >> You can do wonderful things when you escape the constraint of a
> one-level
> >> namespace.
> >>
> >> -- 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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[scott Ford]

Sorry hit the reply to fast...

1.  Clone Git Resp.
2.  Make changes on Cobol/Assembler
3.  Upload to z/OS

Sounds like this Ant/XML might do it ???

Scott

On Sun, Jan 15, 2017 at 3:10 PM, scott Ford  wrote:

> Frank, All:
>
> I am in the same boat, I am trying to do:
>
> 1.
>
> On Sat, Jan 14, 2017 at 11:32 AM, Paul Gilmartin <000433f07816-dmarc-
> requ...@listserv.ua.edu> wrote:
>
>> On Sat, 14 Jan 2017 01:52:25 +, Frank Swarbrick wrote:
>> >
>> >Seems to me the only think that Make would be of use for in our
>> environment would be figuring out which COBOL programs to recompile when a
>> copybook is changed.
>> >
>> Not necessarily in COBOL, but, heck, for that alone it's precious.  No
>> need to
>> remember whch JCL member to submit or tailor.  Just edit one or more
>> sources;
>> type "make" (no parameters necessary) and it happens.
>>
>> A configuration management system can provide homomorphic source
>> directories
>> at various development levels so the same makefile can be used at each.
>>
>> You can do wonderful things when you escape the constraint of a one-level
>> namespace.
>>
>> -- 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

Re: New free / open source z/OS tools from Dovetailed Technologies

[scott Ford]

Frank, All:

I am in the same boat, I am trying to do:

1.

On Sat, Jan 14, 2017 at 11:32 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 14 Jan 2017 01:52:25 +, Frank Swarbrick wrote:
> >
> >Seems to me the only think that Make would be of use for in our
> environment would be figuring out which COBOL programs to recompile when a
> copybook is changed.
> >
> Not necessarily in COBOL, but, heck, for that alone it's precious.  No
> need to
> remember whch JCL member to submit or tailor.  Just edit one or more
> sources;
> type "make" (no parameters necessary) and it happens.
>
> A configuration management system can provide homomorphic source
> directories
> at various development levels so the same makefile can be used at each.
>
> You can do wonderful things when you escape the constraint of a one-level
> namespace.
>
> -- 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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Paul Gilmartin]

On Sat, 14 Jan 2017 01:52:25 +, Frank Swarbrick wrote:
>
>Seems to me the only think that Make would be of use for in our environment 
>would be figuring out which COBOL programs to recompile when a copybook is 
>changed.
> 
Not necessarily in COBOL, but, heck, for that alone it's precious.  No need to
remember whch JCL member to submit or tailor.  Just edit one or more sources;
type "make" (no parameters necessary) and it happens.

A configuration management system can provide homomorphic source directories
at various development levels so the same makefile can be used at each.

You can do wonderful things when you escape the constraint of a one-level
namespace.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[David Crayford]

On 14/01/2017 1:09 AM, Frank Swarbrick wrote:

Our sysprog group has been hesitant to set up SMB on z/OS before a "prove out" 
the use of git.  So this (the Ant tool) seemed like it could be of use.  I'm still 
pondering all of the options.

Thanks!


I don't do COBOL but I do use RD/z sometimes and it's got tooling for 
COBOL projects. I use a Slickedit plugin so I have the same editor for 
all languages unlike native RD/z.




I used the Git z/OS beta as well and it is quite wonderful.  The only problem 
with using Git on z/OS directly is that you can't (as far as I know!) invoke a 
GUI merge tool!



I use "tig" on headless Linux systems which is an ncurses terminal app 
and it's brilliant. I might have a crack at porting that to z/OS when I 
get some spare cycles. The side by side diff GUIs are very nice though. 
If you want to use GUI tools just clone the repo on Windows and do all 
the manipulations there. Then push/pull the changes back to z/OS.



Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of David 
Crayford <dcrayf...@gmail.com>
Sent: Thursday, January 12, 2017 10:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Git: Re: New free / open source z/OS tools from Dovetailed Technologies

On 13/01/2017 5:56 AM, Frank Swarbrick wrote:

Can you give a bit more detail on how you are utilizing this Ant SSH process?  
I don't know anything about Ant.  I am thinking/wondering how it might be used 
in conjunction with Git for source code management of z/OS COBOL programs (and 
jobs).  I know that Rocket is releasing a z/OS version of Git, but it still 
seems to me that for the main part of development (that is, other than the move 
of code to production) it would be useful to use Eclipse to update the source 
code on the local workstation and just send it (perhaps using this Ant SSH 
interface?) to z/OS to be compiled.  Or something like that!

I'm using Rockets git port for active development now it's GA (in fact I
was when it was still in beta). We use SMB network shares which are
mounted on Windows where I use Slickedit for C++ and HLASM. We run
bitbucket locally so the git servers are running on Windows servers. To
share code between different systems using git is easy. Once you've
cloned the repos just keep them in sync but doing "git push" on one
system and "git pull" on the other to fetch the updates. We've had code
review meetings where bugs are being fixed on different systems and then
pushed and pulled right there and then! All our Java development is done
using Eclipse on Windows. When we want to deploy it on z/OS we just use
the push/pull method and then build using maven. Git has revolutionized
the way we work. We also run Jira which has bitbucket integration. We
manage our projects using weekly agile sprints from a backlog using Jira
tasks. Each task is attached to a git branch in bitbucket (press of a
button). When the code is complete we use pull requests which double up
as code reviews (pull requests and merges are done by different members
of the team). We can then track every line of code to a Jira task.

Git has become indispensable. I've suggest to management that we should
pay Rocket for support.





Thanks,

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Kirk Wolf 
<k...@dovetail.com>
Sent: Thursday, January 12, 2017 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: New free / open source z/OS tools from Dovetailed Technologies

Today we have released several new free / open source tools on our website:
See the new "Community" page at: http://dovetail.com

Dovetailed Technologies, LLC<http://dovetail.com/>
dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...



Dovetailed Technologies, LLC<http://dovetail.com/>

Dovetailed Technologies, LLC<http://dovetail.com/>
dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...



dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...



Some highlights:

*Ant SSH* is a set of enhanced SSH tasks for Apache Ant.  For many years we
have used a workstation IDE (Eclipse) as a code editor for  C/C++, Java,
and some Assembler.  We find this tool to be indispensable since it allows
us with one button click in a couple of seconds to upload any dirty source
files and run an incremental build (make) on z/OS.   These custom Ant tasks
can be used with any (or no) IDE.

*ncdu* is a curses based user interface for navigating Unix file systems,
which can be very use

Re: New free / open source z/OS tools from Dovetailed Technologies

[Frank Swarbrick]

More on this later, but the whole "dependencies" and "makefile" process is 
pretty strange to this COBOL programmer.  We pretty much only do dynamic calls, 
so there is no need to update in any way a calling program when a called 
program is changed.  We simply compile and link the called program and move it 
to production.  No need to recompile any other programs.


Even if we do have a static call to another program and that program is changed 
it's almost always only going to be utilized (at that point) by programs that 
are also being changed for the current project.  Therefore, again, no need to 
recompile any other (unchanged) programs.


Seems to me the only think that Make would be of use for in our environment 
would be figuring out which COBOL programs to recompile when a copybook is 
changed.


I don't have any real world experience in developing non-COBOL systems, so I 
don't know much about Make except at a very high level (if that!).


Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Kirk Wolf <k...@dovetail.com>
Sent: Friday, January 13, 2017 6:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

FWIW, we use z/OS make to build stuff with c/c++/assembler/java:

- as  command to invoke HLASM
- c++ or c89 commands for c / c++ compiles
- c89 for binding (according to the docs, cob2 internally invokes c89 for
binding)
- various Unix REXX scripts, like one to invoke EDCDSECT
- java is compiled as it is typed on the workstation; ant scripts
incrementally build and upload jars as required.

The z/OS shell commands run the same compilers, so they can be used to
build modules in PDS/Es, so they are not just for building z/OS Unix stuff.

I wouldn't expect cob2 to be much different.

Kirk Wolf
http://dovetail.com
Dovetailed Technologies, LLC<http://dovetail.com/>
dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...



PS> I don't expect that many on this list will be interested in using make
on z/OS.
For one thing, you would have to agree to using the Unix file system for
source files.
Next, the learning curve for Makefile recipes is pretty steep.
The payoff is that you have a way of incrementally building projects with
many source files and compile units, since make uses a dependency model to
figure out what files need to be recompiled.  C compilers (z/OS XLC/C++
included) can automatically generate Makefile #include dependencies, so
your incremental builds can be even smarter.  With some hacking, you could
probably invoke the COBOL compiler to scan and generate ADATA and then
generate the COPY dependencies for make from there.

--
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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Kirk Wolf]

FWIW, we use z/OS make to build stuff with c/c++/assembler/java:

- as  command to invoke HLASM
- c++ or c89 commands for c / c++ compiles
- c89 for binding (according to the docs, cob2 internally invokes c89 for
binding)
- various Unix REXX scripts, like one to invoke EDCDSECT
- java is compiled as it is typed on the workstation; ant scripts
incrementally build and upload jars as required.

The z/OS shell commands run the same compilers, so they can be used to
build modules in PDS/Es, so they are not just for building z/OS Unix stuff.

I wouldn't expect cob2 to be much different.

Kirk Wolf
http://dovetail.com

PS> I don't expect that many on this list will be interested in using make
on z/OS.
For one thing, you would have to agree to using the Unix file system for
source files.
Next, the learning curve for Makefile recipes is pretty steep.
The payoff is that you have a way of incrementally building projects with
many source files and compile units, since make uses a dependency model to
figure out what files need to be recompiled.  C compilers (z/OS XLC/C++
included) can automatically generate Makefile #include dependencies, so
your incremental builds can be even smarter.  With some hacking, you could
probably invoke the COBOL compiler to scan and generate ADATA and then
generate the COPY dependencies for make from there.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Frank Swarbrick]

I suspect you are correct!


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Charles Mills <charl...@mcn.org>
Sent: Friday, January 13, 2017 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

I strongly suspect the cob2 compiler is exactly the same executable as the
IGYCRCTL compiler, with a  little UNIX-y front-end.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Friday, January 13, 2017 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

Wow!  It's even more restrictive than I had thought.  I tested this out
(sorry, I found it hard to believe!) and of course you are correct.



And you're saying this restriction is true even when the compiler is
executed via cob2?

Seems like an RFE is order.

--
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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Jesse 1 Robinson]

The last modern vestige of screwball characters in names that I know of is in 
the set of SVCs like IGC0004{ and IGC0004A in LPALIB. The last character in the 
name corresponds to the SVC number. No problem for 1 - 9, but '0' is 
represented by x'C0', which is the left brace in EBCDIC. Certainly not the rich 
menagerie that SMP used to harbor, but it does look odd in a member name.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Friday, January 13, 2017 1:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: New free / open source z/OS tools from Dovetailed 
Technologies

On Fri, 13 Jan 2017 12:18:02 -0800, Charles Mills wrote:

>My recollection is that STOW at least and probably BLDL and FIND are 
>utterly character agnostic. You can create member names with 
>non-printable characters in them

Yes. SMP (not SMP/E) used at least one PDS that was full of them.

--
Tom Marchant


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Paul Gilmartin]

On Fri, 13 Jan 2017 14:51:22 -0600, John McKown wrote:
>
>> I believe BPAM/BLDL/FIND is case-indifferent and that any UPPER CASE
>> restriction lies in the compiler.
>
>Could be. But, if so, then which version do you get it there exists "AA"
>"Aa" "aA" and "aa" in the same directory?​
>
Well,
if you say "COPY AA" you get AA
if you say "COPY Aa" you get Aa
if you say "COPY aA" you get aA
if you say "COPY aa" you get aa

At least you should.

I know you better than that.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Charles Mills]

I strongly suspect the cob2 compiler is exactly the same executable as the
IGYCRCTL compiler, with a  little UNIX-y front-end.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Friday, January 13, 2017 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

Wow!  It's even more restrictive than I had thought.  I tested this out
(sorry, I found it hard to believe!) and of course you are correct.



And you're saying this restriction is true even when the compiler is
executed via cob2?

Seems like an RFE is order.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Frank Swarbrick]

Wow!  It's even more restrictive than I had thought.  I tested this out (sorry, 
I found it hard to believe!) and of course you are correct.

"copy library":
DVFJS:/u/dvfjs:>ls /u/dvfjs/copy
TEST1  TEST3.CPY  test2

Compile JCL:
//COBUXJOB ,NOTIFY=,REGION=2000M
// SET COBLIB=IGY.V5R2M0
// JCLLIB ORDER=()
//*--*
//CLMAIN   EXEC IGYWC,LNGPRFX=
//COBOL.SYSIN DD *
   identification division.
   program-id. cobux.
   copy test1.
   copy 'test1'.
   copy test2.
   copy 'test2'.
   copy 'test3.cpy'.
   copy 'TEST3.CPY'.
/*
//COBOL.SYSLIB DD PATH='/u/dvfjs/copy',FILEDATA=TEXT,RECFM=FB,LRECL=80
//

Selected output:

PP 5655-W32 IBM Enterprise COBOL for z/OS  5.2.0 Date 
01/13/2017  Time 14:11:04   Page 3
LineID  Message code  Library phase message text

 7  IGYLI0048-S   The member "TEST2" was not found in the "COPY" library.  
Skipped to the period terminating the "COPY"
  statement.

 8  IGYLI0048-S   The member "'test2'" was not found in the "COPY" library. 
 Skipped to the period terminating the "COPY"
  statement.

 9  IGYLI0025-E   Name "'test3.cpy'" was invalid.  It was processed as 
"TEST30CP".

 9  IGYLI0048-S   The member "'test3.cpy'" was not found in the "COPY" 
library.  Skipped to the period terminating the "COPY"
  statement.

10  IGYLI0025-E   Name "'TEST3.CPY'" was invalid.  It was processed as 
"TEST30CP".

10  IGYLI0048-S   The member "'TEST3.CPY'" was not found in the "COPY" 
library.  Skipped to the period terminating the "COPY"
  statement.
MessagesTotalInformationalWarningErrorSevereTerminating
Printed:   62 4
PP 5655-W32 IBM Enterprise COBOL for z/OS  5.2.0   COBUX Date 
01/13/2017  Time 14:11:04   Page 4
  LineID  PL SL  
+-*A-1-B--+2+3+4+5+6+7-|--+8
 Map and Cross Reference
  01identification division.
  02program-id. cobux.
  03copy test1.
  04C  * This is copied from /u/dvfjs/copy/TEST1
  05copy 'test1'.
  06C  * This is copied from /u/dvfjs/copy/TEST1
  07copy test2.
  08copy 'test2'.
  09copy 'test3.cpy'.
  10copy 'TEST3.CPY'.

[...]

PP 5655-W32 IBM Enterprise COBOL for z/OS  5.2.0   COBUX Date 
01/13/2017  Time 14:11:04   Page 7

 COPY/BASIS cross-reference of text-names, library names and dataset 
information

 Text-name Library   File nameConcat   ISPF 
statistics
 (Member)  (DDNAME)  (Dataset name)   Level
Created Changed

 TEST1 SYSLIB...PATH=.SPECIFIED...  0


The only copy statements that succeeded are when the copy file in the Unix 
directory was in uppercase and no more than 8 characters.

And you're saying this restriction is true even when the compiler is executed 
via cob2?

Seems like an RFE is order.




From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
John McKown <john.archie.mck...@gmail.com>
Sent: Friday, January 13, 2017 1:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

On Fri, Jan 13, 2017 at 2:18 PM, Charles Mills <charl...@mcn.org> wrote:

> My recollection is that STOW at least and probably BLDL and FIND are
> utterly character agnostic. You can create member names with non-printable
> characters in them, for example. As I recall you cannot reference them in
> JCL (of course) but ISPF displays them correctly and you can rename or
> delete them from 3.1. Been a long time -- I may be off on some of the
> details. Experiments would have been done around 1997.
>

Ah, yes. A PDS can have a members named "A" and "a" in the same library.
But, given that the COBOL compiler does not allow specifying a lower case
name (or it automatically upper cases it), then you cannot have a UNIX file
named "a" (lower case) be processed by the COBOL compiler via a "COPY a"
statement. So the restriction that the COBOL copy code which resides in a
UNIX file requires that the UNIX file be all in upper case and consist only
of "valid" (according to COBOL) characters. That's what I was trying to
say, but didn't say very well.



>
> Charles
>
> -Original Message-
> From: IBM Mainfram

Re: New free / open source z/OS tools from Dovetailed Technologies

[Tom Marchant]

On Fri, 13 Jan 2017 12:18:02 -0800, Charles Mills wrote:

>My recollection is that STOW at least and probably BLDL and FIND 
>are utterly character agnostic. You can create member names with 
>non-printable characters in them

Yes. SMP (not SMP/E) used at least one PDS that was full of them.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Charles Mills]

> Could be. But, if so, then which version do you get it there exists "AA"
> "Aa" "aA" and "aa" in the same directory?

I think what is being said is the COBOL uppercases the specification of a COPY 
member name (not BLDL or FIND).

For ordinary PDS(E) members, this qualifies as a favor. You can code copy foo 
and pick up member FOO in a PDS(E).

But for USS directories accessed as PDS's, this is no favor, and I think the 
answer to the question above is AA, even if you coded COPY aa or COPY Aa.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, January 13, 2017 12:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

On Fri, Jan 13, 2017 at 2:09 PM, Paul Gilmartin <000433f07816-dmarc- 
requ...@listserv.ua.edu> wrote:

> On Fri, 13 Jan 2017 13:43:37 -0600, John McKown wrote:
> >
> >​There is a UNIX command: cob2 which will do a COBOL compile and link.
> >Basically this is just a "driver" which, as Gil indicated, parses the 
> >UNIX command line parameters, does dynamic allocations for DDs needed 
> >and then does (I think) a normal MVS LINK command to invoke the 
> >standard COBOL compiler. Note that any UNIX directories in the 
> >command are allocated to the proper DD and the "normal" BSAM / BPAM 
> >UNIX interface code in the access method takes care of the I/O. That 
> >is, there is no UNIX I/O code in the COBOL compiler itself. At least, 
> >I don't think that there is. This is why the COBOL COPY verb cannot 
> >process a file name like "SOMEFILE.cpy" and why the file in the UNIX 
> >directory must in in UPPER CASE, not in "normal"
> >lower case.​ On my system (z/OS 1.12), the cob2 command's full path
> >is: /usr/lpp/cobol/bin/cob2
> >
> I believe BPAM/BLDL/FIND is case-indifferent and that any UPPER CASE 
> restriction lies in the compiler.
>

Could be. But, if so, then which version do you get it there exists "AA"
"Aa" "aA" and "aa" in the same directory?​

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Charles Mills]

I was just sayin'

My impression of the COBOL compiler is no different than yours.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, January 13, 2017 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

On Fri, Jan 13, 2017 at 2:18 PM, Charles Mills <charl...@mcn.org> wrote:

> My recollection is that STOW at least and probably BLDL and FIND are 
> utterly character agnostic. You can create member names with 
> non-printable characters in them, for example. As I recall you cannot 
> reference them in JCL (of course) but ISPF displays them correctly and 
> you can rename or delete them from 3.1. Been a long time -- I may be 
> off on some of the details. Experiments would have been done around 1997.
>

​Ah, yes. A PDS can have a members named "A" and "a" in the same library.
But, given that the COBOL compiler does not allow specifying a lower case name 
(or it automatically upper cases it), then you cannot have a UNIX file named 
"a" (lower case) be processed by the COBOL compiler via a "COPY a"
statement. So the restriction that the COBOL copy code which resides in a UNIX 
file requires that the UNIX file be all in upper case and consist only of 
"valid" (according to COBOL) characters. That's what I was trying to say, but 
didn't say very well.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[John McKown]

On Fri, Jan 13, 2017 at 2:09 PM, Paul Gilmartin <000433f07816-dmarc-
requ...@listserv.ua.edu> wrote:

> On Fri, 13 Jan 2017 13:43:37 -0600, John McKown wrote:
> >
> >​There is a UNIX command: cob2 which will do a COBOL compile and link.
> >Basically this is just a "driver" which, as Gil indicated, parses the UNIX
> >command line parameters, does dynamic allocations for DDs needed and then
> >does (I think) a normal MVS LINK command to invoke the standard COBOL
> >compiler. Note that any UNIX directories in the command are allocated to
> >the proper DD and the "normal" BSAM / BPAM UNIX interface code in the
> >access method takes care of the I/O. That is, there is no UNIX I/O code in
> >the COBOL compiler itself. At least, I don't think that there is. This is
> >why the COBOL COPY verb cannot process a file name like "SOMEFILE.cpy" and
> >why the file in the UNIX directory must in in UPPER CASE, not in "normal"
> >lower case.​ On my system (z/OS 1.12), the cob2 command's full path
> >is: /usr/lpp/cobol/bin/cob2
> >
> I believe BPAM/BLDL/FIND is case-indifferent and that any UPPER CASE
> restriction lies in the compiler.
>

Could be. But, if so, then which version do you get it there exists "AA"
"Aa" "aA" and "aa" in the same directory?​



>
> HLASM and Binder have at least enough UNIX I/O code to display pathnames
> correctly in a data set summary.  And in Binder you can select CASE(MIXED).
>

​Hum, well, not really; at least as I think of it. The RDJFCB macro's exit
list type x'07', in the DSN area, gives ​'...PATH=.SPECIFIED...'. But use
of exit list type x'13' will return the actual UNIX path name. See macros
IHAARL (which has a pointer to) & IHAARA.



>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
There’s no obfuscated Perl contest because it’s pointless.

—Jeff Polk

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[John McKown]

On Fri, Jan 13, 2017 at 2:18 PM, Charles Mills <charl...@mcn.org> wrote:

> My recollection is that STOW at least and probably BLDL and FIND are
> utterly character agnostic. You can create member names with non-printable
> characters in them, for example. As I recall you cannot reference them in
> JCL (of course) but ISPF displays them correctly and you can rename or
> delete them from 3.1. Been a long time -- I may be off on some of the
> details. Experiments would have been done around 1997.
>

​Ah, yes. A PDS can have a members named "A" and "a" in the same library.
But, given that the COBOL compiler does not allow specifying a lower case
name (or it automatically upper cases it), then you cannot have a UNIX file
named "a" (lower case) be processed by the COBOL compiler via a "COPY a"
statement. So the restriction that the COBOL copy code which resides in a
UNIX file requires that the UNIX file be all in upper case and consist only
of "valid" (according to COBOL) characters. That's what I was trying to
say, but didn't say very well.



>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, January 13, 2017 12:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: New free / open source z/OS tools from Dovetailed Technologies
>
> On Fri, 13 Jan 2017 13:43:37 -0600, John McKown wrote:
> >
> >​There is a UNIX command: cob2 which will do a COBOL compile and link.
> >Basically this is just a "driver" which, as Gil indicated, parses the
> >UNIX command line parameters, does dynamic allocations for DDs needed
> >and then does (I think) a normal MVS LINK command to invoke the
> >standard COBOL compiler. Note that any UNIX directories in the command
> >are allocated to the proper DD and the "normal" BSAM / BPAM UNIX
> >interface code in the access method takes care of the I/O. That is,
> >there is no UNIX I/O code in the COBOL compiler itself. At least, I
> >don't think that there is. This is why the COBOL COPY verb cannot
> >process a file name like "SOMEFILE.cpy" and why the file in the UNIX
> directory must in in UPPER CASE, not in "normal"
> >lower case.​ On my system (z/OS 1.12), the cob2 command's full path
> >is: /usr/lpp/cobol/bin/cob2
> >
> I believe BPAM/BLDL/FIND is case-indifferent and that any UPPER CASE
> restriction lies in the compiler.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
There’s no obfuscated Perl contest because it’s pointless.

—Jeff Polk

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[David W Noon]

On Fri, 13 Jan 2017 13:36:16 -0600, Paul Gilmartin
(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: New
free / open source z/OS tools from Dovetailed Technologies" (in
<9549369497181383.wa.paulgboulderaim@listserv.ua.edu>):

> In UNIX I believe that's not automatic.  The application, compiler,
> whatever, must parse that environment variable, breaking it at colons
> and sequentially search each directory in the list.  (Might there be a
> library routine for that?)

strtok() and strtok_r(). The first one is ISO standard C and the second
one is POSIX standard C, at least according to the man page. See

man 3 strtok

on any Linux or BSD system.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Charles Mills]

My recollection is that STOW at least and probably BLDL and FIND are utterly 
character agnostic. You can create member names with non-printable characters 
in them, for example. As I recall you cannot reference them in JCL (of course) 
but ISPF displays them correctly and you can rename or delete them from 3.1. 
Been a long time -- I may be off on some of the details. Experiments would have 
been done around 1997.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, January 13, 2017 12:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

On Fri, 13 Jan 2017 13:43:37 -0600, John McKown wrote:
>
>​There is a UNIX command: cob2 which will do a COBOL compile and link.
>Basically this is just a "driver" which, as Gil indicated, parses the 
>UNIX command line parameters, does dynamic allocations for DDs needed 
>and then does (I think) a normal MVS LINK command to invoke the 
>standard COBOL compiler. Note that any UNIX directories in the command 
>are allocated to the proper DD and the "normal" BSAM / BPAM UNIX 
>interface code in the access method takes care of the I/O. That is, 
>there is no UNIX I/O code in the COBOL compiler itself. At least, I 
>don't think that there is. This is why the COBOL COPY verb cannot 
>process a file name like "SOMEFILE.cpy" and why the file in the UNIX directory 
>must in in UPPER CASE, not in "normal"
>lower case.​ On my system (z/OS 1.12), the cob2 command's full path
>is: /usr/lpp/cobol/bin/cob2
> 
I believe BPAM/BLDL/FIND is case-indifferent and that any UPPER CASE 
restriction lies in the compiler.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Paul Gilmartin]

On Fri, 13 Jan 2017 13:43:37 -0600, John McKown wrote:
>
>​There is a UNIX command: cob2 which will do a COBOL compile and link.
>Basically this is just a "driver" which, as Gil indicated, parses the UNIX
>command line parameters, does dynamic allocations for DDs needed and then
>does (I think) a normal MVS LINK command to invoke the standard COBOL
>compiler. Note that any UNIX directories in the command are allocated to
>the proper DD and the "normal" BSAM / BPAM UNIX interface code in the
>access method takes care of the I/O. That is, there is no UNIX I/O code in
>the COBOL compiler itself. At least, I don't think that there is. This is
>why the COBOL COPY verb cannot process a file name like "SOMEFILE.cpy" and
>why the file in the UNIX directory must in in UPPER CASE, not in "normal"
>lower case.​ On my system (z/OS 1.12), the cob2 command's full path
>is: /usr/lpp/cobol/bin/cob2
> 
I believe BPAM/BLDL/FIND is case-indifferent and that any UPPER CASE
restriction lies in the compiler.

HLASM and Binder have at least enough UNIX I/O code to display pathnames
correctly in a data set summary.  And in Binder you can select CASE(MIXED).

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[John McKown]

On Fri, Jan 13, 2017 at 1:45 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Is cob2 just a shell script or a REXX or something?  Or is it an actual
> binary?
>

​Binary executable. My guess is that the source is in C.​



>
> If its a script, can you post it?
>
>
-- 
There’s no obfuscated Perl contest because it’s pointless.

—Jeff Polk

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Paul Gilmartin]

On Fri, 13 Jan 2017 19:45:52 +, Frank Swarbrick wrote:

>Is cob2 just a shell script or a REXX or something?  Or is it an actual binary?
>
>If its a script, can you post it?
> 
I'd expect that if you have COBOL and you have UNIX you probably have cob2.
Otherwise it probably suffers copyright restrictions.

If I needed to do this, I'd use Rexx.  BPXWDYN to allocate and LINKMVS to 
execute.
STEPLIB could be an ugly wrinkle.  Shell is pretty unfriendly to allocations.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Frank Swarbrick]

Is cob2 just a shell script or a REXX or something?  Or is it an actual binary?

If its a script, can you post it?


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
John McKown <john.archie.mck...@gmail.com>
Sent: Friday, January 13, 2017 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

On Fri, Jan 13, 2017 at 1:36 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 13 Jan 2017 19:18:53 +, Vince Coen wrote:
>
> >Under *nix you set an environment variable in the bash (or what ever one
> you use) script
> >This points to the directory path containing the copy libs and that
> >directory path is mapped to the syslib you need.
> >
> >I am not an expert on z/OS but assuming you can do the last then the
> >rest is easy.
> >
> In UNIX I believe that's not automatic.  The application, compiler,
> whatever, must parse that environment variable, breaking it at colons
> and sequentially search each directory in the list.  (Might there be a
> library routine for that?)
>
> Library concatenation is one OS feature whose absence in UNIX I rue.
>
> >I was lead to believe that the compiler has a versions that runs under
> >the *nix sub system how ever I have not looked in detail for this.
> >
> I don't believe it's a distinct version.  The one version simply runs under
> z/OS UNIX, given suitable allocations and parameters.
>
> -- gil
>
>
There is a UNIX command: cob2 which will do a COBOL compile and link.
Basically this is just a "driver" which, as Gil indicated, parses the UNIX
command line parameters, does dynamic allocations for DDs needed and then
does (I think) a normal MVS LINK command to invoke the standard COBOL
compiler. Note that any UNIX directories in the command are allocated to
the proper DD and the "normal" BSAM / BPAM UNIX interface code in the
access method takes care of the I/O. That is, there is no UNIX I/O code in
the COBOL compiler itself. At least, I don't think that there is. This is
why the COBOL COPY verb cannot process a file name like "SOMEFILE.cpy" and
why the file in the UNIX directory must in in UPPER CASE, not in "normal"
lower case. On my system (z/OS 1.12), the cob2 command's full path
is: /usr/lpp/cobol/bin/cob2


--
There's no obfuscated Perl contest because it's pointless.

-Jeff Polk

Maranatha! <><
John McKown

--
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

Re: New free / open source z/OS tools from Dovetailed Technologies

[John McKown]

On Fri, Jan 13, 2017 at 1:36 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 13 Jan 2017 19:18:53 +, Vince Coen wrote:
>
> >Under *nix you set an environment variable in the bash (or what ever one
> you use) script
> >This points to the directory path containing the copy libs and that
> >directory path is mapped to the syslib you need.
> >
> >I am not an expert on z/OS but assuming you can do the last then the
> >rest is easy.
> >
> In UNIX I believe that's not automatic.  The application, compiler,
> whatever, must parse that environment variable, breaking it at colons
> and sequentially search each directory in the list.  (Might there be a
> library routine for that?)
>
> Library concatenation is one OS feature whose absence in UNIX I rue.
>
> >I was lead to believe that the compiler has a versions that runs under
> >the *nix sub system how ever I have not looked in detail for this.
> >
> I don't believe it's a distinct version.  The one version simply runs under
> z/OS UNIX, given suitable allocations and parameters.
>
> -- gil
>
>
​There is a UNIX command: cob2 which will do a COBOL compile and link.
Basically this is just a "driver" which, as Gil indicated, parses the UNIX
command line parameters, does dynamic allocations for DDs needed and then
does (I think) a normal MVS LINK command to invoke the standard COBOL
compiler. Note that any UNIX directories in the command are allocated to
the proper DD and the "normal" BSAM / BPAM UNIX interface code in the
access method takes care of the I/O. That is, there is no UNIX I/O code in
the COBOL compiler itself. At least, I don't think that there is. This is
why the COBOL COPY verb cannot process a file name like "SOMEFILE.cpy" and
why the file in the UNIX directory must in in UPPER CASE, not in "normal"
lower case.​ On my system (z/OS 1.12), the cob2 command's full path
is: /usr/lpp/cobol/bin/cob2


-- 
There’s no obfuscated Perl contest because it’s pointless.

—Jeff Polk

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Frank Swarbrick]

There is.  The 'cob2' command.  It has never been set up here, as we've never 
had a need for it. Perhaps I will ask.


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Vince Coen <vbc...@gmail.com>
Sent: Friday, January 13, 2017 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

Under *nix you set an environment variable in the bash (or what ever one
you use) script
This points to the directory path containing the copy libs and that
directory path is mapped to the syslib you need.

I am not an expert on z/OS but assuming you can do the last then the
rest is easy.

I was lead to believe that the compiler has a versions that runs under
the *nix sub system how ever I have not looked in detail for this.

Vince



On 13/01/17 19:11, Paul Gilmartin wrote:
> On Fri, 13 Jan 2017 18:01:41 +, Frank Swarbrick wrote:
>> The compiler then looks at the SYSLIB concatenation for a member named 
>> MYRECF.  A "PATH" can be part of the SYSLIB concatenation.  However it 
>> doesn't appear that there is any option for COBOL to look for a member (or 
>> file in the PATH case) to be anything other than exactly 'MYRECF'.  So, for 
>> example, it would not consider 'myrecf.cpy' or even 'MYRECF.CPY' to be a 
>> match to the above copy statement.
>>
>> I'm sure there are other more complex options, but I'd rather investigate 
>> the "simpler" options first.
>>
> A shadow directory of symbolic links?
>
> In days past, in HLASM we used the user exits to do such mappings.  Now we
> use a cross assembler.
>

--
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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Frank Swarbrick]

That is a good thought.  I will investigate.  Thanks!


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 13, 2017 12:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

On Fri, 13 Jan 2017 18:01:41 +, Frank Swarbrick wrote:
>
>The compiler then looks at the SYSLIB concatenation for a member named MYRECF. 
> A "PATH" can be part of the SYSLIB concatenation.  However it doesn't appear 
>that there is any option for COBOL to look for a member (or file in the PATH 
>case) to be anything other than exactly 'MYRECF'.  So, for example, it would 
>not consider 'myrecf.cpy' or even 'MYRECF.CPY' to be a match to the above copy 
>statement.
>
>I'm sure there are other more complex options, but I'd rather investigate the 
>"simpler" options first.
>
A shadow directory of symbolic links?

In days past, in HLASM we used the user exits to do such mappings.  Now we
use a cross assembler.

-- 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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Paul Gilmartin]

On Fri, 13 Jan 2017 19:18:53 +, Vince Coen wrote:

>Under *nix you set an environment variable in the bash (or what ever one you 
>use) script
>This points to the directory path containing the copy libs and that
>directory path is mapped to the syslib you need.
>
>I am not an expert on z/OS but assuming you can do the last then the
>rest is easy.
>
In UNIX I believe that's not automatic.  The application, compiler,
whatever, must parse that environment variable, breaking it at colons
and sequentially search each directory in the list.  (Might there be a
library routine for that?)

Library concatenation is one OS feature whose absence in UNIX I rue.

>I was lead to believe that the compiler has a versions that runs under
>the *nix sub system how ever I have not looked in detail for this.
>
I don't believe it's a distinct version.  The one version simply runs under
z/OS UNIX, given suitable allocations and parameters.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Vince Coen]

Under *nix you set an environment variable in the bash (or what ever one 
you use) script
This points to the directory path containing the copy libs and that 
directory path is mapped to the syslib you need.


I am not an expert on z/OS but assuming you can do the last then the 
rest is easy.


I was lead to believe that the compiler has a versions that runs under 
the *nix sub system how ever I have not looked in detail for this.


Vince



On 13/01/17 19:11, Paul Gilmartin wrote:

On Fri, 13 Jan 2017 18:01:41 +, Frank Swarbrick wrote:

The compiler then looks at the SYSLIB concatenation for a member named MYRECF.  A 
"PATH" can be part of the SYSLIB concatenation.  However it doesn't appear that 
there is any option for COBOL to look for a member (or file in the PATH case) to be 
anything other than exactly 'MYRECF'.  So, for example, it would not consider 
'myrecf.cpy' or even 'MYRECF.CPY' to be a match to the above copy statement.

I'm sure there are other more complex options, but I'd rather investigate the 
"simpler" options first.


A shadow directory of symbolic links?

In days past, in HLASM we used the user exits to do such mappings.  Now we
use a cross assembler.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Paul Gilmartin]

On Fri, 13 Jan 2017 18:01:41 +, Frank Swarbrick wrote:
>
>The compiler then looks at the SYSLIB concatenation for a member named MYRECF. 
> A "PATH" can be part of the SYSLIB concatenation.  However it doesn't appear 
>that there is any option for COBOL to look for a member (or file in the PATH 
>case) to be anything other than exactly 'MYRECF'.  So, for example, it would 
>not consider 'myrecf.cpy' or even 'MYRECF.CPY' to be a match to the above copy 
>statement.
>
>I'm sure there are other more complex options, but I'd rather investigate the 
>"simpler" options first.
>
A shadow directory of symbolic links?

In days past, in HLASM we used the user exits to do such mappings.  Now we
use a cross assembler.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Frank Swarbrick]

Good stuff to think about.  Thank you.


That does bring up a question...  Can you make something similar to "suffix 
rules" but at a directory level?  For example, can you say "this directory 
contains only source code" (so that the correct text translation is done)?


The reason I ask is that all of our COBOL source code "imports" copybooks with 
COBOL source code such as:
COPY MYRECF.


The compiler then looks at the SYSLIB concatenation for a member named MYRECF.  
A "PATH" can be part of the SYSLIB concatenation.  However it doesn't appear 
that there is any option for COBOL to look for a member (or file in the PATH 
case) to be anything other than exactly 'MYRECF'.  So, for example, it would 
not consider 'myrecf.cpy' or even 'MYRECF.CPY' to be a match to the above copy 
statement.


If someone can prove me wrong I'd like to hear it!  :-)


My point is that I think we still want/need our source code to be "non 
prefixed", but when shared using NFS or SMB we need them to be treated as text 
files.


I'm sure there are other more complex options, but I'd rather investigate the 
"simpler" options first.


Thanks!

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 13, 2017 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

On Fri, 13 Jan 2017 17:03:55 +, Frank Swarbrick wrote:
>
>Being COBOL we don't (currently) run our compiles under Unix.  Any thoughts 
>about if/how this process might interface with 'traditional' z/OS things like 
>ISPF and JCL?
>
Depends.  I have a Rexx EXEC that runs under z/OS UNIX using ADDRESS TSO
to start ISPF LM Services running an EXEC to update a PDS with ISPF
serialization.  All background.

And another that uses the SDSF Rexx API to unload JES spool to UNIX files.

I truly wish there were a way for a UNIX process  with X11 tunneling to pop
up in a user's desktop an x3270 session.  Or several.

We very successfully use NFS to mount Solaris filesystems on z/OS and
z/OS Classic data sets as directories on desktops.

/etc/startup.mk has suffix rules for:
# Suffix definitions
E:= # Executable
O:=.o   # Object
S:=.s   # Assembler
A:=.a   # Archive (library)
P:=.p   # Pascal
F:=.f   # Fortran

But, ironically, not COBOL.  Small wonder that dinosaurs loathe z/OS UNIX.

-- 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

Re: New free / open source z/OS tools from Dovetailed Technologies

[Paul Gilmartin]

On Fri, 13 Jan 2017 17:03:55 +, Frank Swarbrick wrote:
>
>Being COBOL we don't (currently) run our compiles under Unix.  Any thoughts 
>about if/how this process might interface with 'traditional' z/OS things like 
>ISPF and JCL?
>
Depends.  I have a Rexx EXEC that runs under z/OS UNIX using ADDRESS TSO
to start ISPF LM Services running an EXEC to update a PDS with ISPF
serialization.  All background.

And another that uses the SDSF Rexx API to unload JES spool to UNIX files.

I truly wish there were a way for a UNIX process  with X11 tunneling to pop
up in a user's desktop an x3270 session.  Or several.

We very successfully use NFS to mount Solaris filesystems on z/OS and
z/OS Classic data sets as directories on desktops.

/etc/startup.mk has suffix rules for:
# Suffix definitions
E:= # Executable
O:=.o   # Object
S:=.s   # Assembler
A:=.a   # Archive (library)
P:=.p   # Pascal
F:=.f   # Fortran

But, ironically, not COBOL.  Small wonder that dinosaurs loathe z/OS UNIX.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Frank Swarbrick]

Our sysprog group has been hesitant to set up SMB on z/OS before a "prove out" 
the use of git.  So this (the Ant tool) seemed like it could be of use.  I'm 
still pondering all of the options.

Thanks!


I used the Git z/OS beta as well and it is quite wonderful.  The only problem 
with using Git on z/OS directly is that you can't (as far as I know!) invoke a 
GUI merge tool!


Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
David Crayford <dcrayf...@gmail.com>
Sent: Thursday, January 12, 2017 10:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Git: Re: New free / open source z/OS tools from Dovetailed Technologies

On 13/01/2017 5:56 AM, Frank Swarbrick wrote:
> Can you give a bit more detail on how you are utilizing this Ant SSH process? 
>  I don't know anything about Ant.  I am thinking/wondering how it might be 
> used in conjunction with Git for source code management of z/OS COBOL 
> programs (and jobs).  I know that Rocket is releasing a z/OS version of Git, 
> but it still seems to me that for the main part of development (that is, 
> other than the move of code to production) it would be useful to use Eclipse 
> to update the source code on the local workstation and just send it (perhaps 
> using this Ant SSH interface?) to z/OS to be compiled.  Or something like 
> that!

I'm using Rockets git port for active development now it's GA (in fact I
was when it was still in beta). We use SMB network shares which are
mounted on Windows where I use Slickedit for C++ and HLASM. We run
bitbucket locally so the git servers are running on Windows servers. To
share code between different systems using git is easy. Once you've
cloned the repos just keep them in sync but doing "git push" on one
system and "git pull" on the other to fetch the updates. We've had code
review meetings where bugs are being fixed on different systems and then
pushed and pulled right there and then! All our Java development is done
using Eclipse on Windows. When we want to deploy it on z/OS we just use
the push/pull method and then build using maven. Git has revolutionized
the way we work. We also run Jira which has bitbucket integration. We
manage our projects using weekly agile sprints from a backlog using Jira
tasks. Each task is attached to a git branch in bitbucket (press of a
button). When the code is complete we use pull requests which double up
as code reviews (pull requests and merges are done by different members
of the team). We can then track every line of code to a Jira task.

Git has become indispensable. I've suggest to management that we should
pay Rocket for support.




>
> Thanks,
>
> Frank
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
> Kirk Wolf <k...@dovetail.com>
> Sent: Thursday, January 12, 2017 1:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: New free / open source z/OS tools from Dovetailed Technologies
>
> Today we have released several new free / open source tools on our website:
>See the new "Community" page at: http://dovetail.com
Dovetailed Technologies, LLC<http://dovetail.com/>
dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...


> Dovetailed Technologies, LLC<http://dovetail.com/>
Dovetailed Technologies, LLC<http://dovetail.com/>
dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...


> dovetail.com
> Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible 
> client may transfer files directly to z/OS datasets, controlling all aspects 
> of dataset ...
>
>
>
> Some highlights:
>
> *Ant SSH* is a set of enhanced SSH tasks for Apache Ant.  For many years we
> have used a workstation IDE (Eclipse) as a code editor for  C/C++, Java,
> and some Assembler.  We find this tool to be indispensable since it allows
> us with one button click in a couple of seconds to upload any dirty source
> files and run an incremental build (make) on z/OS.   These custom Ant tasks
> can be used with any (or no) IDE.
>
> *ncdu* is a curses based user interface for navigating Unix file systems,
> which can be very useful when trying to cull unused files from a highly
> populated file system. The main interface makes it easy to quickly see
> which directories contain the heaviest disk usage and the navigational
> model is very intuitive, making it easy to traverse and delete files and
> directories that are no longer needed.
>
> One thing that we have done is to include our source project 

Re: New free / open source z/OS tools from Dovetailed Technologies

[Frank Swarbrick]

Do we need the an server task (sshd?) running?  I don't have sysprog access to 
may not be able to 'just test this out', but we'll see.


Being COBOL we don't (currently) run our compiles under Unix.  Any thoughts 
about if/how this process might interface with 'traditional' z/OS things like 
ISPF and JCL?


Thanks!

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Kirk Wolf <k...@dovetail.com>
Sent: Thursday, January 12, 2017 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New free / open source z/OS tools from Dovetailed Technologies

On Thu, Jan 12, 2017 at 3:56 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> ...

it would be useful to use Eclipse to update the source code on the local
> workstation and just send it (perhaps using this Ant SSH interface?) to
> z/OS to be compiled.  Or something like that!
>

Exactly like that.

We use our workstation IDE's connection and tools for connecting to an
managing our SCCS.
You could certainly connect your workstation IDE to git.

Ant-SSH lets you write an Ant XML script to upload (only the changed) files
and run z/OS commands like "make" to build, on the same ssh connection.
We use a desktop ssh key agent so that our scripts don't need passwords or
user prompts.

If you are already using Eclipse, try these steps:

-  download Ant-SSH to your workstation, and import it as a general project
in Eclipse
-  follow the Ant-SSH README <https://dovetail.com/docs/antssh/readme.html> to
add the ant-ssh/lib/*.jars to your Eclipse Ant classpath
-  test by customizing/running the ant-ssh/test/test1.xml test script
 (right-click "Run as / Ant Build")

- download the ncdu zip file to your workstation
- follow the ncdu README <https://dovetail.com/docs/ncdu/readme.html>:
- customize build.properties per the README
- run Ant build.xml to upload and build ncdu on z/OS using ant-ssh

Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Dovetailed Technologies, LLC<http://dovetail.com/>
dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...



>
>

--
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

Git: Re: New free / open source z/OS tools from Dovetailed Technologies

[David Crayford]

On 13/01/2017 5:56 AM, Frank Swarbrick wrote:

Can you give a bit more detail on how you are utilizing this Ant SSH process?  
I don't know anything about Ant.  I am thinking/wondering how it might be used 
in conjunction with Git for source code management of z/OS COBOL programs (and 
jobs).  I know that Rocket is releasing a z/OS version of Git, but it still 
seems to me that for the main part of development (that is, other than the move 
of code to production) it would be useful to use Eclipse to update the source 
code on the local workstation and just send it (perhaps using this Ant SSH 
interface?) to z/OS to be compiled.  Or something like that!


I'm using Rockets git port for active development now it's GA (in fact I 
was when it was still in beta). We use SMB network shares which are 
mounted on Windows where I use Slickedit for C++ and HLASM. We run 
bitbucket locally so the git servers are running on Windows servers. To 
share code between different systems using git is easy. Once you've 
cloned the repos just keep them in sync but doing "git push" on one 
system and "git pull" on the other to fetch the updates. We've had code 
review meetings where bugs are being fixed on different systems and then 
pushed and pulled right there and then! All our Java development is done 
using Eclipse on Windows. When we want to deploy it on z/OS we just use 
the push/pull method and then build using maven. Git has revolutionized 
the way we work. We also run Jira which has bitbucket integration. We 
manage our projects using weekly agile sprints from a backlog using Jira 
tasks. Each task is attached to a git branch in bitbucket (press of a 
button). When the code is complete we use pull requests which double up 
as code reviews (pull requests and merges are done by different members 
of the team). We can then track every line of code to a Jira task.


Git has become indispensable. I've suggest to management that we should 
pay Rocket for support.







Thanks,

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Kirk Wolf 
<k...@dovetail.com>
Sent: Thursday, January 12, 2017 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: New free / open source z/OS tools from Dovetailed Technologies

Today we have released several new free / open source tools on our website:
   See the new "Community" page at: http://dovetail.com
Dovetailed Technologies, LLC<http://dovetail.com/>
dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...



Some highlights:

*Ant SSH* is a set of enhanced SSH tasks for Apache Ant.  For many years we
have used a workstation IDE (Eclipse) as a code editor for  C/C++, Java,
and some Assembler.  We find this tool to be indispensable since it allows
us with one button click in a couple of seconds to upload any dirty source
files and run an incremental build (make) on z/OS.   These custom Ant tasks
can be used with any (or no) IDE.

*ncdu* is a curses based user interface for navigating Unix file systems,
which can be very useful when trying to cull unused files from a highly
populated file system. The main interface makes it easy to quickly see
which directories contain the heaviest disk usage and the navigational
model is very intuitive, making it easy to traverse and delete files and
directories that are no longer needed.

One thing that we have done is to include our source project for *ncdu* that
includes a z/OS Makefile and Ant build.xml script that uses Ant-SSH.  This
serves as a complete demonstration of using a workstation IDE to develop
for z/OS.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Dovetailed Technologies, LLC<http://dovetail.com/>
dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...



*Join us at SHARE in San Jose*
  Thursday, March 09, 10:00 AM - 11:00 AM
  Finding the Needle in a Haystack - Diagnosing Common OpenSSH Problems

--
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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Kirk Wolf]

On Thu, Jan 12, 2017 at 3:56 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> ...

it would be useful to use Eclipse to update the source code on the local
> workstation and just send it (perhaps using this Ant SSH interface?) to
> z/OS to be compiled.  Or something like that!
>

Exactly like that.

We use our workstation IDE's connection and tools for connecting to an
managing our SCCS.
You could certainly connect your workstation IDE to git.

Ant-SSH lets you write an Ant XML script to upload (only the changed) files
and run z/OS commands like "make" to build, on the same ssh connection.
We use a desktop ssh key agent so that our scripts don't need passwords or
user prompts.

If you are already using Eclipse, try these steps:

-  download Ant-SSH to your workstation, and import it as a general project
in Eclipse
-  follow the Ant-SSH README  to
add the ant-ssh/lib/*.jars to your Eclipse Ant classpath
-  test by customizing/running the ant-ssh/test/test1.xml test script
 (right-click "Run as / Ant Build")

- download the ncdu zip file to your workstation
- follow the ncdu README :
- customize build.properties per the README
- run Ant build.xml to upload and build ncdu on z/OS using ant-ssh

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: New free / open source z/OS tools from Dovetailed Technologies

[Frank Swarbrick]

Can you give a bit more detail on how you are utilizing this Ant SSH process?  
I don't know anything about Ant.  I am thinking/wondering how it might be used 
in conjunction with Git for source code management of z/OS COBOL programs (and 
jobs).  I know that Rocket is releasing a z/OS version of Git, but it still 
seems to me that for the main part of development (that is, other than the move 
of code to production) it would be useful to use Eclipse to update the source 
code on the local workstation and just send it (perhaps using this Ant SSH 
interface?) to z/OS to be compiled.  Or something like that!


Thanks,

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Kirk Wolf <k...@dovetail.com>
Sent: Thursday, January 12, 2017 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: New free / open source z/OS tools from Dovetailed Technologies

Today we have released several new free / open source tools on our website:
  See the new "Community" page at: http://dovetail.com
Dovetailed Technologies, LLC<http://dovetail.com/>
dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...



Some highlights:

*Ant SSH* is a set of enhanced SSH tasks for Apache Ant.  For many years we
have used a workstation IDE (Eclipse) as a code editor for  C/C++, Java,
and some Assembler.  We find this tool to be indispensable since it allows
us with one button click in a couple of seconds to upload any dirty source
files and run an incremental build (make) on z/OS.   These custom Ant tasks
can be used with any (or no) IDE.

*ncdu* is a curses based user interface for navigating Unix file systems,
which can be very useful when trying to cull unused files from a highly
populated file system. The main interface makes it easy to quickly see
which directories contain the heaviest disk usage and the navigational
model is very intuitive, making it easy to traverse and delete files and
directories that are no longer needed.

One thing that we have done is to include our source project for *ncdu* that
includes a z/OS Makefile and Ant build.xml script that uses Ant-SSH.  This
serves as a complete demonstration of using a workstation IDE to develop
for z/OS.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Dovetailed Technologies, LLC<http://dovetail.com/>
dovetail.com
Using Co:Z SFTP-server, systems with OpenSSH or another SFTP compatible client 
may transfer files directly to z/OS datasets, controlling all aspects of 
dataset ...



*Join us at SHARE in San Jose*
 Thursday, March 09, 10:00 AM - 11:00 AM
 Finding the Needle in a Haystack - Diagnosing Common OpenSSH Problems

--
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

New free / open source z/OS tools from Dovetailed Technologies

[Kirk Wolf]

Today we have released several new free / open source tools on our website:
  See the new "Community" page at: http://dovetail.com

Some highlights:

*Ant SSH* is a set of enhanced SSH tasks for Apache Ant.  For many years we
have used a workstation IDE (Eclipse) as a code editor for  C/C++, Java,
and some Assembler.  We find this tool to be indispensable since it allows
us with one button click in a couple of seconds to upload any dirty source
files and run an incremental build (make) on z/OS.   These custom Ant tasks
can be used with any (or no) IDE.

*ncdu* is a curses based user interface for navigating Unix file systems,
which can be very useful when trying to cull unused files from a highly
populated file system. The main interface makes it easy to quickly see
which directories contain the heaviest disk usage and the navigational
model is very intuitive, making it easy to traverse and delete files and
directories that are no longer needed.

One thing that we have done is to include our source project for *ncdu* that
includes a z/OS Makefile and Ant build.xml script that uses Ant-SSH.  This
serves as a complete demonstration of using a workstation IDE to develop
for z/OS.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

*Join us at SHARE in San Jose*
 Thursday, March 09, 10:00 AM - 11:00 AM
 Finding the Needle in a Haystack - Diagnosing Common OpenSSH Problems

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN