Re: git, z/OS and COBOL

[Edward Gould]

> On Oct 10, 2017, at 9:17 PM, ste...@copper.net  wrote:
> 
> My comments are on the bottom because it made more sense to put them after 
> the question(s).
> 
> --- cfmpub...@ns.sympatico.ca  wrote:
> 
> From: Clark Morris  >
> To:   IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: [IBM-MAIN] git, z/OS and COBOL
> Date: Tue, 10 Oct 2017 21:56:34 -0300
> 
> [Default] On 10 Oct 2017 10:48:59 -0700, in bit.listserv.ibm-main
> peter.far...@broadridge.com  (Farley, 
> Peter x23353) wrote:
> 
>> Frank,
>> 
> 
> 
>> Alternatively, do your programmers really make any sensible real-world use 
>> of COBOL line numbers in columns 1-6, or is it just "tradition"?  After all, 
>> no one has had to use a card sorter to re-order a program source whose card 
>> tray was dropped on the floor for some decades.
> 
> Vendors which supply COBOL source probably use IEBUPDTE or their own
> proprietary means of updating (and maybe even their own library
> system) that depends on sequence numbers in columns 1 - 6.  In the
> 1990s I had to deal with vendor source that was updated by their
> system using sequence numbers.  As I recall, JES2 and JES3 source
> maintenance used IEBUPDTE and sequence numbers in 73 - 80 back in the
> 1980s when I was doing SMP/E work (I was at an installation that went
> from HASP to JES3 to JES2).
> 
> Clark Morris
> 
I haven’t been exposed to them (Vendors who supplied source) in 4-5 years.
The ones I have dealt with were payroll systems and accounting systems and SMF 
reporting systems.
all used iebupdte and it really works well (for these systems).
However some of their systems were lets say less than fool proof. They would 
send out updates to copybooks and not necessarily recompile the programs that 
used the copy books.
When our person got an update for a copybook, he used fileaid to scan the 
source library and any source that used the copybook was recompiled, no matter 
what the vendor said.
This is a second hand story. One day the person got an update for a copybook 
from the vendor and was told that only Program #1 & 3 4 6 7 10 needed to be 
recompiled. He did a scan for other programs that used the copy book and found 
15. He called up the vendor and got into a heated discussion about the issue. 
The updates were really needed because of some tax thing. We went ahead and 
compiled 15 instead of the 6 that were called for. The update went well and the 
recompiles went well and moved into testing and ran well. Then they were moved 
into production and everything went well. The salesman for the product happened 
to be non and we asked for a quick meeting about this. The meeting took 30 
minutes and the salesman came out and headed for a phone and we couldn’t hear 
the conversation other than it was animated lets say. The salesman took it to 
his boss and apparently it got the whole company involved. From then on when 
copybooks were updated *All* of the referencing programs got recompiled. The 
vendor was not a friend anymore and relationship got strained. We were no 
longer asked out for any dinners (boo hoo).

Ed


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

Re: Sort Question

[Paul Gilmartin]

On Tue, 10 Oct 2017 22:18:47 -0500, Tim Hare wrote:

>I know I am late to this, but I see no BLOCK CONTAINS 0 RECORDS in the COBOL.  
>I'm not totally current on COBOL releases, but 
>A) is that still required to use block size from the JCL
>
Even better, it will use the block size supplied by SDB.

>B) is it even relevant in this instance - COBOL will use the block size value 
>of the dataset that's input, yes?

-- gil

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

Re: git, z/OS and COBOL

[Paul Gilmartin]

On Tue, 10 Oct 2017 19:17:25 -0700, ste...@copper.net wrote:
>
>Your question had to do with manually doing IEBUPDTE commands. The users where 
>I am probably do, but I honestly don't know. The ISV(s) that provide source 
>maint; I have no clue how they do theirs.
> 
I have not used IEBUPDTE extensively.  When I contributed to Charlotte, I made
more use of CMS UPDATE, which is similar to IEBUPDTE, but with further features
useful for source code control.  XEDIT can generate CMS UPDATE control files,
but they contain some noise which I filtered out with a final pass through 
SuperC.

There are more powerful tools than IEBUPDTE.  Embrace them.

Examples include diff3 and various GUI merge utilities.

-- gil

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

Re: Sort Question

[Tim Hare]

I know I am late to this, but I see no BLOCK CONTAINS 0 RECORDS in the COBOL.  
I'm not totally current on COBOL releases, but 
A) is that still required to use block size from the JCL
B) is it even relevant in this instance - COBOL will use the block size value 
of the dataset that's input, yes?

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

Re: git, z/OS and COBOL

[ste...@copper.net]

My comments are on the bottom because it made more sense to put them after the 
question(s).

--- cfmpub...@ns.sympatico.ca wrote:

From: Clark Morris 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] git, z/OS and COBOL
Date: Tue, 10 Oct 2017 21:56:34 -0300

[Default] On 10 Oct 2017 10:48:59 -0700, in bit.listserv.ibm-main
peter.far...@broadridge.com (Farley, Peter x23353) wrote:

>Frank,
>


>Alternatively, do your programmers really make any sensible real-world use of 
>COBOL line numbers in columns 1-6, or is it just "tradition"?  After all, no 
>one has had to use a card sorter to re-order a program source whose card tray 
>was dropped on the floor for some decades.

Vendors which supply COBOL source probably use IEBUPDTE or their own
proprietary means of updating (and maybe even their own library
system) that depends on sequence numbers in columns 1 - 6.  In the
1990s I had to deal with vendor source that was updated by their
system using sequence numbers.  As I recall, JES2 and JES3 source
maintenance used IEBUPDTE and sequence numbers in 73 - 80 back in the
1980s when I was doing SMP/E work (I was at an installation that went
from HASP to JES3 to JES2).

Clark Morris


And as I recall, that was still true of JES2/3 macros at OS/390 V2R4. I haven't 
paid any attention to them in that way since then. I haven't touched much in 
JES2 or JES3 since I stopped working on OBS/ACS/WYLBUR. 


Paul:

Your question had to do with manually doing IEBUPDTE commands. The users where 
I am probably do, but I honestly don't know. The ISV(s) that provide source 
maint; I have no clue how they do theirs. 

If you need me to answer anything else on this, have some patience, I probably 
won't get back to this until next week when I am back in my office.

Regards,
Steve Thompson

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

Re: Distributing source maintenance without sequence numbers was Re: git, z/OS and COBOL

[Paul Gilmartin]

On Tue, 10 Oct 2017 21:59:54 -0300, Clark Morris wrote:
>
>>>From what you say, diff and patch will not know or understand where the 
>>>source being supplied to update the original source goes.
>>> 
>>Patch uses a combination of relative line numbers and context lines (such as 
>>appear
>>in a SuperC listing).  It works.
>>
>>>So, I don't think your method is going to fly with source coming from a 
>>>vendor that has to be updated via IEBUPDTE, nor is it going to fly with one 
>>>of our groups that uses IEBUPDTE to update their source...
>>> 
>>Do those groups create their IEBUPDTE command files by hand?
>
>Other than by total replacement, how would you distribute source
>maintenance other than by an IEBUPDTE like maintenance mechanism that
>depends on sequence numbers?
> 
"patch" works.  It does not depend on sequence numbers.  It's widely used.

-- gil

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

Distributing source maintenance without sequence numbers was Re: git, z/OS and COBOL

[Clark Morris]

[Default] On 10 Oct 2017 17:30:54 -0700, in bit.listserv.ibm-main
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:

>On Tue, 10 Oct 2017 17:21:29 -0700, stevet wrote:
>>
>>So how does one merge fixes into source if the "source" numbering is removed? 
>>The fixes may issue delete of lines, addition of lines and replace of lines 
>>and there may be multiple delta decks to be applied anytime one wants to do 
>>changes to the source. This is not a spec I'm providing, this is a 
>>requirement I would have to live with.
>>
>>From what you say, diff and patch will not know or understand where the 
>>source being supplied to update the original source goes.
>> 
>Patch uses a combination of relative line numbers and context lines (such as 
>appear
>in a SuperC listing).  It works.
>
>>So, I don't think your method is going to fly with source coming from a 
>>vendor that has to be updated via IEBUPDTE, nor is it going to fly with one 
>>of our groups that uses IEBUPDTE to update their source...
>> 
>Do those groups create their IEBUPDTE command files by hand?
>

Other than by total replacement, how would you distribute source
maintenance other than by an IEBUPDTE like maintenance mechanism that
depends on sequence numbers?

Clark Morris
>-- 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: git, z/OS and COBOL

[Clark Morris]

[Default] On 10 Oct 2017 10:48:59 -0700, in bit.listserv.ibm-main
peter.far...@broadridge.com (Farley, Peter x23353) wrote:

>Frank,
>
>The *ix compare utility is usually the "diff" command, and looking up the 
>possible parameters for "diff" I don't see any options that would allow 
>filtering the columns compared.  It should be possible to craft a shell script 
>to chop the line numbers off in temporary files and then do the compare with 
>the chopped files, but the output would not, of course, reflect the line 
>numbers in the difference listing (or "patch" compatible output file).  
>Another possible issue would be whether it is even possible to make git use 
>the shell script instead of "diff", and whether or not that is even desirable 
>for any language but COBOL.
>
>Looks like an opportunity for someone to contribute to the open-source 
>community to implement a column filter for the "diff" and "patch" suite, and 
>maybe "git" as well.
>
>Alternatively, do your programmers really make any sensible real-world use of 
>COBOL line numbers in columns 1-6, or is it just "tradition"?  After all, no 
>one has had to use a card sorter to re-order a program source whose card tray 
>was dropped on the floor for some decades.

Vendors which supply COBOL source probably use IEBUPDTE or their own
proprietary means of updating (and maybe even their own library
system) that depends on sequence numbers in columns 1 - 6.  In the
1990s I had to deal with vendor source that was updated by their
system using sequence numbers.  As I recall, JES2 and JES3 source
maintenance used IEBUPDTE and sequence numbers in 73 - 80 back in the
1980s when I was doing SMP/E work (I was at an installation that went
from HASP to JES3 to JES2).

Clark Morris
>
>I abandoned using any line numbers at all in any language many years ago, and 
>I use those (now just comment) COBOL line number columns to "tag" changed 
>COBOL lines during maintenance edits to identify the project for which the 
>change was done.  I use ISPF "UNNUM" on all numbered source programs when I 
>first edit them to remove all line numbering.
>
>COBOL V5/6 implementation of line comments (*>) may somewhat alleviate the 
>need/desire to use the COBOL line number columns for tags, but I can still see 
>using them that way going forward.
>
>YMMV of course, I realize that it is quite hard to change the ways that people 
>are used to working.
>
>Peter
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Frank Swarbrick
>Sent: Tuesday, October 10, 2017 1:19 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: git, z/OS and COBOL
>
>The reason I asked about the line numbers thing is that git seems to use a 
>Unix compare utility that has no way (that I can tell) to ignore the line 
>numbers.  So if you insert a new line then the compare thinks that every line 
>after that has changed, when truly only the line number has changed.  If you 
>have a way around that I'd be interested.
>I've downloaded the DBBz alpha but am waiting on resources from other groups 
>to do what parts are required so I can try it out.
>Jerry, do you mind if I email you privately for more information?
>Thanks, Frank
>
>From: IBM Mainframe Discussion List  on behalf of 
>Edgington, Jerry 
>Sent: Tuesday, October 10, 2017 10:47 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: git, z/OS and COBOL
>
>Frank,
>
>I have been working with several tools to build Cobol programs with as much 
>open source as possible.  Here is what I am using;
>
>Open Source
>- Eclipse based IDE, with IBM Aqua and Jenkins plugins
>- Jenkins
>- git.  The git server is running off z/OS supported by another team
>
>Cost item;
>- IBM Dependency Based Build in Beta
>- Deployment tool, if you wish to replace mainframe SCLM tool
>
>Some general items;
>- The compilers being used are the same ones used in z/OS batch compiles. So, 
>same rules apply
>#1, if the z/OS batch compiler allows them, then no
>#2, the open source eclipse based IDE will perform that same as ISPF.  So, no 
>Cobol syntax checking
>#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically 
>allocate the necessary files, then executing the compile. However, I believe 
>there is an issue between zFS and PDS, where you can't mix them.
>#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can 
>submit JCL from the IDE for example
>#5, using this setup, they will not know they are running on Unix on z/OS
>#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP 
>provides more functionality
>#7, Eclipse has plugins to allow for merge, diff, etc.  I am using what was 
>built for the Java environment here
>
>There are some differences that the developer will see, for example separating 
>out the various types of sources, like Cobol, Copybooks, BMS, etc with 
>different mime 

Re: git, z/OS and COBOL

[scott Ford]

Frank,

I do all my editing up on z/OS, the other developers, Java guys do it via 
desktop. We don't use GIT on z/OS yet.

Scott

On Oct 10, 2017, 7:35 PM -0400, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu>, wrote:
> On Tue, 10 Oct 2017 23:19:38 +, Farley, Peter x23353 wrote:
> >
> > Once you start using git (or for that matter any of the *ix-based source 
> > repository utilities) for mainframe source maintenance, you stop using 
> > IEBUPDTE (or any other sequence-number-based source update process) and 
> > start using the "patch" utility. The input to "patch" is the output from 
> > "diff" (when properly configured with options, as is done inside of git and 
> > other source repository utilities).
> >
> The input to IEBUPDTE is the output from "SuperC" (when properly configured 
> with options).
> The glaring restriction of IEBUPDTE is that it chokes on an apparent IEBUPTDE 
> command
> appearing as a data line, as might happen in a JCL member invoking an 
> IEBUPDTE step.
>
> And Fixed-80.
>
> > The "diff" and "patch" utilities could care less what is on each line. They 
> > just compare lines and try to find the maximal number of non-differences 
> > (sets of matching lines) between the minimal number of difference lines. 
> > It's an art, but it mostly works.
> >
> SuperC appears to use a similar algorithm.
>
> > Any kind of sequence numbering in the source lines defeats "diff" entirely 
> > and everything after an insert looks like it changed.
> >
> Only if you are so foolish as to configure your editor to renumber in each 
> session.
>
> > So if you plan to move to git or one of its predecessors, plan to eliminate 
> > all sequence numbering in the source when you first move it into the 
> > repository.
> >
> Or don't renumber. I once wrote a utility using SuperC and IEBUPDTE to repair
> carelessly modified sequence numbers.
>
> -- 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: git, z/OS and COBOL

[Paul Gilmartin]

On Tue, 10 Oct 2017 23:19:38 +, Farley, Peter x23353 wrote:
>
>Once you start using git (or for that matter any of the *ix-based source 
>repository utilities) for mainframe source maintenance, you stop using 
>IEBUPDTE (or any other sequence-number-based source update process) and start 
>using the "patch" utility.  The input to "patch" is the output from "diff" 
>(when properly configured with options, as is done inside of git and other 
>source repository utilities).
>
The input to IEBUPDTE is the output from "SuperC" (when properly configured 
with options).
The glaring restriction of IEBUPDTE is that it chokes on an apparent IEBUPTDE 
command
appearing as a data line, as might happen in a JCL member invoking an IEBUPDTE 
step.

And Fixed-80.

>The "diff" and "patch" utilities could care less what is on each line.  They 
>just compare lines and try to find the maximal number of non-differences (sets 
>of matching lines) between the minimal number of difference lines.  It's an 
>art, but it mostly works.
>
SuperC appears to use a similar algorithm.

>Any kind of sequence numbering in the source lines defeats "diff" entirely and 
>everything after an insert looks like it changed.
>
Only if you are so foolish as to configure your editor to renumber in each 
session.

>So if you plan to move to git or one of its predecessors, plan to eliminate 
>all sequence numbering in the source when you first move it into the 
>repository.
>
Or don't renumber.  I once wrote a utility using SuperC and IEBUPDTE to repair 
carelessly modified sequence numbers.

-- gil

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

Re: git, z/OS and COBOL

[Farley, Peter x23353]

Steve,

Once you start using git (or for that matter any of the *ix-based source 
repository utilities) for mainframe source maintenance, you stop using IEBUPDTE 
(or any other sequence-number-based source update process) and start using the 
"patch" utility.  The input to "patch" is the output from "diff" (when properly 
configured with options, as is done inside of git and other source repository 
utilities).

The "diff" and "patch" utilities could care less what is on each line.  They 
just compare lines and try to find the maximal number of non-differences (sets 
of matching lines) between the minimal number of difference lines.  It's an 
art, but it mostly works.

Any kind of sequence numbering in the source lines defeats "diff" entirely and 
everything after an insert looks like it changed.

So if you plan to move to git or one of its predecessors, plan to eliminate all 
sequence numbering in the source when you first move it into the repository.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ste...@copper.net
Sent: Tuesday, October 10, 2017 7:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Peter, et al:

I am quite interested in git. And so I thought I would address a statement made 
about COBOL Numbering, and "standard" numbering locations in source.

There are some products that ship source and do use COBOL numbering while 
others use the 73-80 numbering (both are COBOL based products). In either case, 
they are generally maintained by using IEBUPDTE to insert the maintenance 
and/or USER changes.

I know of some user source that is maintained that way because that source is 
used where different "mods" have to be applied (terminology not to imply any 
relationship to SMPE). 

So, where I am working, I am given to understand that there is a POC going with 
git. If they do not understand our shop, this could cause a headache (the 
stripping or ignoring 1-6 and/or 73-80). 

In source that I maintain, the change codes are in 73-80, while NUM COB is used 
(ISPF), I don't care about that information -- I care about the change codes 
for what I maintain. 

But I am just waiting for the chance to use git for ISPF panels, skeletons, 
COBOL source, REXX and ALC code that I am responsible for.

I'd like to run into the problems before the applications people have a chance 
to hit it so we can head that all off. 

And I'd love to know the answers to this before the POC dies. So I am very 
interested in this thread.

Regards,
Steve Thompson



--- peter.far...@broadridge.com wrote:

From: "Farley, Peter x23353" 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] git, z/OS and COBOL
Date: Tue, 10 Oct 2017 17:50:10 +

Frank,

The *ix compare utility is usually the "diff" command, and looking up the 
possible parameters for "diff" I don't see any options that would allow 
filtering the columns compared.  It should be possible to craft a shell script 
to chop the line numbers off in temporary files and then do the compare with 
the chopped files, but the output would not, of course, reflect the line 
numbers in the difference listing (or "patch" compatible output file).  Another 
possible issue would be whether it is even possible to make git use the shell 
script instead of "diff", and whether or not that is even desirable for any 
language but COBOL.

Looks like an opportunity for someone to contribute to the open-source 
community to implement a column filter for the "diff" and "patch" suite, and 
maybe "git" as well.

Alternatively, do your programmers really make any sensible real-world use of 
COBOL line numbers in columns 1-6, or is it just "tradition"?  After all, no 
one has had to use a card sorter to re-order a program source whose card tray 
was dropped on the floor for some decades.

I abandoned using any line numbers at all in any language many years ago, and I 
use those (now just comment) COBOL line number columns to "tag" changed COBOL 
lines during maintenance edits to identify the project for which the change was 
done.  I use ISPF "UNNUM" on all numbered source programs when I first edit 
them to remove all line numbering.

COBOL V5/6 implementation of line comments (*>) may somewhat alleviate the 
need/desire to use the COBOL line number columns for tags, but I can still see 
using them that way going forward.

YMMV of course, I realize that it is quite hard to change the ways that people 
are used to working.

Peter
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify 

Re: Regular Expressions with Rexx

[Paul Gilmartin]

On Tue, 10 Oct 2017 21:28:49 +, Ze'ev Atlas wrote:

>John Gateley and I will be publishing a full Rexx API to Perl Compatible 
>Regular Expression package in z/OS, probably next week.  This release will be 
>complete if somewhat primitive, comparing to the experimental 1st release.  I 
>have noticed that there is not a lot of interest in that subject, which I 
>understand, knowing the Rexx culture.  However many of you do Java, ooRexx and 
>are exposed to regular expressions even in Rexx context.
>I would like to get feedback about the whole subject and about the API (I will 
>publish its availability on the same lists) Ze'ev Atlas
> 
ISPF Edit supports regular expressions, now, sort of, with some conspicuous
deficiencies.

Code pages intrude.  The metacharacters in regular expressions are interpreted
according to the code page of the attached terminal.  Even in a macro.  So the
programmer would need to supply an instance of each macro for each supported
terminal code page.  Or translate (iconv()?) any regex from a canonical code
page (1047?) to the active code page.

It is not documented which code page is presumed if Edit runs in background, 
with
no terminal attached.

Java has its own support for code pages.

I hate EBCDIC!

-- gil

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

Re: git, z/OS and COBOL

[Frank Swarbrick]

Thanks Scott.  So you do all of your source code editing on z/OS?  Do you use 
GIT on z/OS for any of this?

From: IBM Mainframe Discussion List  on behalf of 
scott Ford 
Sent: Tuesday, October 10, 2017 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank:

We have a Develop Branch ...and when we put in a fix for example.
...1.  Created a GIT branch off Dev ..we have an internal fix number.
...2   My GIT Repo is on my ldaptop.
...3   I then upload either via FTP or IND$FILE to my Sandbox
...4   Make the changes on my Sandbox, compile, link and unit test
...5   when everything looks good, download source to my Laptop
...6   Commit the source
...7   Push the source
.. 8   When we merge after approval, this kicksoff our CI process
which clones the source, does a complete build of our product ...
All this is done with CI-Jenkins ...


HTH

Scott

On Tue, Oct 10, 2017 at 4:37 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Thanks Scott.  Let me see if I understand this.  It sounds like your
> developers, when starting changes for a program, use git to "check out" the
> source code to their workstation.  Do they make changes, save locally, FTP
> to z/OS and then compile on z/OS?  Are these last two steps (assuming I am
> understanding you) "automated" in any manner?  Or do they have to "manually
> FTP" and then manually submit the compile job?
> 
> From: IBM Mainframe Discussion List  on behalf
> of scott Ford 
> Sent: Tuesday, October 10, 2017 1:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: git, z/OS and COBOL
>
> Frank and Kirk:
>
> Yes we are using Assembler and Cobol in GIT.
>
> At least one person has said they are using git for source code management
> of their z/OS COBOL programs.  A few questions, if you don't mind.
> 1) Did you have to eliminate the line numbers in columns 1-6?
>  -- We dont use them
> 2) What do your developers use for their COBOL editor?  ISPF?  Off platform
> IDE?
> --  We upload to z/OS sandbox
> --  JCL compile there
> --   Unit tests
> 3) Do you compile using JCL or UNIX?
> 4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between
> z/OS and workstations?
> --  GIT CLONE to Linux and FTP to z/OS
> 5) How much UNIX knowledge do your developers need to be productive in this
> environment?
> -- I am the only one with Unix knowledge, everyone else is not unix
> savy
> 6) How do you connect to z/OS UNIX?  ssh?  TSO OMVS?
>-- see above
> 7) Do you use a GUI/visual merge product?  How?
>-- BeyondCompare
> 8) Anything else you'd like to add
>
>
> HTH Frank and Kirk..
>
> Scott
>
> On Tue, Oct 10, 2017 at 2:26 PM, Kirk Wolf  wrote:
>
> > Just curious - is anyone using any COBOL syntax-aware editors in Eclipse?
> > The SlickEdit Core ?   Others?
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
> www.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: 
> www.idmworks.com/blog>
>
>
>
>
>
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
>
> --
> 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
>



--



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary 

Re: git, z/OS and COBOL

[scott Ford]

Frank:

We have a Develop Branch ...and when we put in a fix for example.
...1.  Created a GIT branch off Dev ..we have an internal fix number.
...2   My GIT Repo is on my ldaptop.
...3   I then upload either via FTP or IND$FILE to my Sandbox
...4   Make the changes on my Sandbox, compile, link and unit test
...5   when everything looks good, download source to my Laptop
...6   Commit the source
...7   Push the source
.. 8   When we merge after approval, this kicksoff our CI process
which clones the source, does a complete build of our product ...
All this is done with CI-Jenkins ...


HTH

Scott

On Tue, Oct 10, 2017 at 4:37 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Thanks Scott.  Let me see if I understand this.  It sounds like your
> developers, when starting changes for a program, use git to "check out" the
> source code to their workstation.  Do they make changes, save locally, FTP
> to z/OS and then compile on z/OS?  Are these last two steps (assuming I am
> understanding you) "automated" in any manner?  Or do they have to "manually
> FTP" and then manually submit the compile job?
> 
> From: IBM Mainframe Discussion List  on behalf
> of scott Ford 
> Sent: Tuesday, October 10, 2017 1:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: git, z/OS and COBOL
>
> Frank and Kirk:
>
> Yes we are using Assembler and Cobol in GIT.
>
> At least one person has said they are using git for source code management
> of their z/OS COBOL programs.  A few questions, if you don't mind.
> 1) Did you have to eliminate the line numbers in columns 1-6?
>  -- We dont use them
> 2) What do your developers use for their COBOL editor?  ISPF?  Off platform
> IDE?
> --  We upload to z/OS sandbox
> --  JCL compile there
> --   Unit tests
> 3) Do you compile using JCL or UNIX?
> 4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between
> z/OS and workstations?
> --  GIT CLONE to Linux and FTP to z/OS
> 5) How much UNIX knowledge do your developers need to be productive in this
> environment?
> -- I am the only one with Unix knowledge, everyone else is not unix
> savy
> 6) How do you connect to z/OS UNIX?  ssh?  TSO OMVS?
>-- see above
> 7) Do you use a GUI/visual merge product?  How?
>-- BeyondCompare
> 8) Anything else you'd like to add
>
>
> HTH Frank and Kirk..
>
> Scott
>
> On Tue, Oct 10, 2017 at 2:26 PM, Kirk Wolf  wrote:
>
> > Just curious - is anyone using any COBOL syntax-aware editors in Eclipse?
> > The SlickEdit Core ?   Others?
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
> www.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: www.idmworks.com/blog
>
>
>
>
>
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
>
> --
> 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
>



-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

Regular Expressions with Rexx

[Ze'ev Atlas]

John Gateley and I will be publishing a full Rexx API to Perl Compatible 
Regular Expression package in z/OS, probably next week.  This release will be 
complete if somewhat primitive, comparing to the experimental 1st release.  I 
have noticed that there is not a lot of interest in that subject, which I 
understand, knowing the Rexx culture.  However many of you do Java, ooRexx and 
are exposed to regular expressions even in Rexx context.
I would like to get feedback about the whole subject and about the API (I will 
publish its availability on the same lists) Ze'ev Atlas



|  | Virus-free. www.avast.com  |


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

Transmit out class

[Tony Thigpen]

How does TRANSMIT determine the 'class' as indicated in the NJE headers?

What I am testing shows 'B' when it gets to z/VM, but on this JES2 
system, the definition of OUTCLASS(B) is one of PRINT, not PUNCH so z/VM 
does not recognize that the file is in NETDATA format.


--
Tony Thigpen

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

Re: git, z/OS and COBOL

[Frank Swarbrick]

Thanks Scott.  Let me see if I understand this.  It sounds like your 
developers, when starting changes for a program, use git to "check out" the 
source code to their workstation.  Do they make changes, save locally, FTP to 
z/OS and then compile on z/OS?  Are these last two steps (assuming I am 
understanding you) "automated" in any manner?  Or do they have to "manually 
FTP" and then manually submit the compile job?

From: IBM Mainframe Discussion List  on behalf of 
scott Ford 
Sent: Tuesday, October 10, 2017 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank and Kirk:

Yes we are using Assembler and Cobol in GIT.

At least one person has said they are using git for source code management
of their z/OS COBOL programs.  A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
 -- We dont use them
2) What do your developers use for their COBOL editor?  ISPF?  Off platform
IDE?
--  We upload to z/OS sandbox
--  JCL compile there
--   Unit tests
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between
z/OS and workstations?
--  GIT CLONE to Linux and FTP to z/OS
5) How much UNIX knowledge do your developers need to be productive in this
environment?
-- I am the only one with Unix knowledge, everyone else is not unix savy
6) How do you connect to z/OS UNIX?  ssh?  TSO OMVS?
   -- see above
7) Do you use a GUI/visual merge product?  How?
   -- BeyondCompare
8) Anything else you'd like to add


HTH Frank and Kirk..

Scott

On Tue, Oct 10, 2017 at 2:26 PM, Kirk Wolf  wrote:

> Just curious - is anyone using any COBOL syntax-aware editors in Eclipse?
> The SlickEdit Core ?   Others?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

--
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: git, z/OS and COBOL

[scott Ford]

Frank and Kirk:

Yes we are using Assembler and Cobol in GIT.

At least one person has said they are using git for source code management
of their z/OS COBOL programs.  A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
 -- We dont use them
2) What do your developers use for their COBOL editor?  ISPF?  Off platform
IDE?
--  We upload to z/OS sandbox
--  JCL compile there
--   Unit tests
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between
z/OS and workstations?
--  GIT CLONE to Linux and FTP to z/OS
5) How much UNIX knowledge do your developers need to be productive in this
environment?
-- I am the only one with Unix knowledge, everyone else is not unix savy
6) How do you connect to z/OS UNIX?  ssh?  TSO OMVS?
   -- see above
7) Do you use a GUI/visual merge product?  How?
   -- BeyondCompare
8) Anything else you'd like to add


HTH Frank and Kirk..

Scott

On Tue, Oct 10, 2017 at 2:26 PM, Kirk Wolf  wrote:

> Just curious - is anyone using any COBOL syntax-aware editors in Eclipse?
> The SlickEdit Core ?   Others?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: Question about management class autobackup=y

[Allan Staller]

Replying to my own post. The below should read:
HSM (by default) will not expire a dataset if HSM does not own a backup copy.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, October 10, 2017 1:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question about management class autobackup=y

HSM (by default) will not expire a dataset if HSM does own a backup copy. It 
does not communicate w/FDR, nor know anything about any backups FDR may/may not 
have. 
This is the meaning of RC=53.

This behavior can be changed by a patch described in: SC23-6869-02 z/OS 
DFSMShsm Implementation and Customization Guide
pp360 "Disabling delete-if-backed-up (DBU) processing for SMS data sets"  

The citation above is the z/OS 2.2 version. Check the Impl/Cust guide for your 
release as the offset may have changed.

HTH,


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hervey Martinez
Sent: Tuesday, October 10, 2017 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question about management class autobackup=y

We have several files that are receiving RC=53 and the management class has 
autobackup=y. The help panel in ISMF, describes this field as, "Automatic 
backup is allowed" but since these files are erroring that means that "backup 
are required".

We don't run HSM backups since we rely on FDR for that.

just wondering as to why the discrepancy on this field and if anybody can offer 
an explanation.

 

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


::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: Question about management class autobackup=y

[Allan Staller]

HSM (by default) will not expire a dataset if HSM does own a backup copy. It 
does not communicate w/FDR, nor know anything about any backups FDR may/may not 
have. 
This is the meaning of RC=53.

This behavior can be changed by a patch described in: SC23-6869-02 z/OS 
DFSMShsm Implementation and Customization Guide
pp360 "Disabling delete-if-backed-up (DBU) processing for SMS data sets"  

The citation above is the z/OS 2.2 version. Check the Impl/Cust guide for your 
release as the offset may have changed.

HTH,


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hervey Martinez
Sent: Tuesday, October 10, 2017 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question about management class autobackup=y

We have several files that are receiving RC=53 and the management class has 
autobackup=y. The help panel in ISMF, describes this field as, "Automatic 
backup is allowed" but since these files are erroring that means that "backup 
are required".

We don't run HSM backups since we rely on FDR for that.

just wondering as to why the discrepancy on this field and if anybody can offer 
an explanation.

 

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


::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: git, z/OS and COBOL

[Kirk Wolf]

Just curious - is anyone using any COBOL syntax-aware editors in Eclipse?
The SlickEdit Core ?   Others?

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

Question about management class autobackup=y

[Hervey Martinez]

We have several files that are receiving RC=53 and the management class has 
autobackup=y. The help panel in ISMF, describes this field as, "Automatic 
backup is allowed" but since these files are erroring that means that "backup 
are required".

We don't run HSM backups since we rely on FDR for that.

just wondering as to why the discrepancy on this field and if anybody can offer 
an explanation.



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

Re: git, z/OS and COBOL

[Frank Swarbrick]

As far as I know the COBOL line numbers in cols 1-6 are just historical, and of 
no real value.  I imagine we'd eliminate their usage via some mass conversion 
process at the time we load the source in to git.

It sounds like you are referring to columns 73-80, however.  We use that for an 
8 character 'work order number'.  I don't think they will cause us any issues.

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, October 10, 2017 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank,

The *ix compare utility is usually the "diff" command, and looking up the 
possible parameters for "diff" I don't see any options that would allow 
filtering the columns compared.  It should be possible to craft a shell script 
to chop the line numbers off in temporary files and then do the compare with 
the chopped files, but the output would not, of course, reflect the line 
numbers in the difference listing (or "patch" compatible output file).  Another 
possible issue would be whether it is even possible to make git use the shell 
script instead of "diff", and whether or not that is even desirable for any 
language but COBOL.

Looks like an opportunity for someone to contribute to the open-source 
community to implement a column filter for the "diff" and "patch" suite, and 
maybe "git" as well.

Alternatively, do your programmers really make any sensible real-world use of 
COBOL line numbers in columns 1-6, or is it just "tradition"?  After all, no 
one has had to use a card sorter to re-order a program source whose card tray 
was dropped on the floor for some decades.

I abandoned using any line numbers at all in any language many years ago, and I 
use those (now just comment) COBOL line number columns to "tag" changed COBOL 
lines during maintenance edits to identify the project for which the change was 
done.  I use ISPF "UNNUM" on all numbered source programs when I first edit 
them to remove all line numbering.

COBOL V5/6 implementation of line comments (*>) may somewhat alleviate the 
need/desire to use the COBOL line number columns for tags, but I can still see 
using them that way going forward.

YMMV of course, I realize that it is quite hard to change the ways that people 
are used to working.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 1:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

The reason I asked about the line numbers thing is that git seems to use a Unix 
compare utility that has no way (that I can tell) to ignore the line numbers.  
So if you insert a new line then the compare thinks that every line after that 
has changed, when truly only the line number has changed.  If you have a way 
around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to 
do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank

From: IBM Mainframe Discussion List  on behalf of 
Edgington, Jerry 
Sent: Tuesday, October 10, 2017 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank,

I have been working with several tools to build Cobol programs with as much 
open source as possible.  Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git.  The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, 
same rules apply
#1, if the z/OS batch compiler allows them, then no
#2, the open source eclipse based IDE will perform that same as ISPF.  So, no 
Cobol syntax checking
#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically 
allocate the necessary files, then executing the compile. However, I believe 
there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can 
submit JCL from the IDE for example
#5, using this setup, they will not know they are running on Unix on z/OS
#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP 
provides more functionality
#7, Eclipse has plugins to allow for merge, diff, etc.  I am using what was 
built for the Java environment here

There are some differences that the developer will see, for example separating 
out the various types of sources, like Cobol, Copybooks, BMS, etc with 
different mime types. But, using Eclipse IDE, git and Jenkins, a developer can 
push code from the IDE to the git 

PLO register specifications?

[Charles Mills]

The syntax of PLO is of course PLO R1,D2(B2),R3,D4(B4).

For many of the operation codes (5, e.g.) R1 and R3 (in the syntax, not GPRs
1 and 3) are unused. What is the recommended practice for what registers to
specify? It seems odd to me that the PoOp is silent. GPR 0 would be the
obvious choice, but it is specifically dis-recommended for R3 under certain
circumstances. I kind of have a funny gut feeling about specifying a
particular GPR other than 0.

What do people do generally? Or am I missing something in the documentation?

Charles 

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

Re: git, z/OS and COBOL

[Farley, Peter x23353]

Frank,

The *ix compare utility is usually the "diff" command, and looking up the 
possible parameters for "diff" I don't see any options that would allow 
filtering the columns compared.  It should be possible to craft a shell script 
to chop the line numbers off in temporary files and then do the compare with 
the chopped files, but the output would not, of course, reflect the line 
numbers in the difference listing (or "patch" compatible output file).  Another 
possible issue would be whether it is even possible to make git use the shell 
script instead of "diff", and whether or not that is even desirable for any 
language but COBOL.

Looks like an opportunity for someone to contribute to the open-source 
community to implement a column filter for the "diff" and "patch" suite, and 
maybe "git" as well.

Alternatively, do your programmers really make any sensible real-world use of 
COBOL line numbers in columns 1-6, or is it just "tradition"?  After all, no 
one has had to use a card sorter to re-order a program source whose card tray 
was dropped on the floor for some decades.

I abandoned using any line numbers at all in any language many years ago, and I 
use those (now just comment) COBOL line number columns to "tag" changed COBOL 
lines during maintenance edits to identify the project for which the change was 
done.  I use ISPF "UNNUM" on all numbered source programs when I first edit 
them to remove all line numbering.

COBOL V5/6 implementation of line comments (*>) may somewhat alleviate the 
need/desire to use the COBOL line number columns for tags, but I can still see 
using them that way going forward.

YMMV of course, I realize that it is quite hard to change the ways that people 
are used to working.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 1:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

The reason I asked about the line numbers thing is that git seems to use a Unix 
compare utility that has no way (that I can tell) to ignore the line numbers.  
So if you insert a new line then the compare thinks that every line after that 
has changed, when truly only the line number has changed.  If you have a way 
around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to 
do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank

From: IBM Mainframe Discussion List  on behalf of 
Edgington, Jerry 
Sent: Tuesday, October 10, 2017 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank,

I have been working with several tools to build Cobol programs with as much 
open source as possible.  Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git.  The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, 
same rules apply
#1, if the z/OS batch compiler allows them, then no
#2, the open source eclipse based IDE will perform that same as ISPF.  So, no 
Cobol syntax checking
#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically 
allocate the necessary files, then executing the compile. However, I believe 
there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can 
submit JCL from the IDE for example
#5, using this setup, they will not know they are running on Unix on z/OS
#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP 
provides more functionality
#7, Eclipse has plugins to allow for merge, diff, etc.  I am using what was 
built for the Java environment here

There are some differences that the developer will see, for example separating 
out the various types of sources, like Cobol, Copybooks, BMS, etc with 
different mime types. But, using Eclipse IDE, git and Jenkins, a developer can 
push code from the IDE to the git server, like Bitbucket, kick of Jenkins 
build, which will push/pull the source code from Bitbucket/git to zFS using git 
client and Jenkins slave. That is using all open source.

>From there, something like DBBz, ANT script, possibly the mainframe SCM, or 
>JCL to copy the source to PDS and compile the programs.

However, to do a full SCLM, like the current mainframe source management tools, 
you can forget about deployment or movement between environments.

Jerry Edgington

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Tuesday, October 10, 

Re: git, z/OS and COBOL

[Paul Gilmartin]

On Tue, 10 Oct 2017 17:18:44 +, Frank Swarbrick wrote:

>The reason I asked about the line numbers thing is that git seems to use a 
>Unix compare utility that has no way (that I can tell) to ignore the line 
>numbers.  So if you insert a new line then the compare thinks that every line 
>after that has changed, when truly only the line number has changed.  If you 
>have a way around that I'd be interested.
>
Turn AUTONUMBER off in your editor.

If your lines are numbered consecutively, re-number with an interval
of 100 or more so there's slack for insertions.

What editor are you using?  What others are available?

>I've downloaded the DBBz alpha but am waiting on resources from other groups 
>to do what parts are required so I can try it out.

-- gil

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

Re: git, z/OS and COBOL

[Edgington, Jerry]

Sorry Frank. Here is my email address at work

jerry.edging...@kroger.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Tuesday, October 10, 2017 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Sure Frank. No problem with emailing privately.  Happy to help, if I can.

From: Frank Swarbrick [mailto:frank.swarbr...@outlook.com]
Sent: Tuesday, October 10, 2017 1:19 PM
To: Edgington, Jerry; IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

The reason I asked about the line numbers thing is that git seems to use a Unix 
compare utility that has no way (that I can tell) to ignore the line numbers.  
So if you insert a new line then the compare thinks that every line after that 
has changed, when truly only the line number has changed.  If you have a way 
around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to 
do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank

From: IBM Mainframe Discussion List 
> on behalf of 
Edgington, Jerry >
Sent: Tuesday, October 10, 2017 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank,

I have been working with several tools to build Cobol programs with as much 
open source as possible.  Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git.  The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, 
same rules apply #1, if the z/OS batch compiler allows them, then no #2, the 
open source eclipse based IDE will perform that same as ISPF.  So, no Cobol 
syntax checking #3, Actually both can be used. With DBBz, it is using SVC 99 to 
dynamically allocate the necessary files, then executing the compile. However, 
I believe there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can 
submit JCL from the IDE for example #5, using this setup, they will not know 
they are running on Unix on z/OS #6, The IBM Aqua connection, I believe, is 
either FTP or SSH. But, I think FTP provides more functionality #7, Eclipse has 
plugins to allow for merge, diff, etc.  I am using what was built for the Java 
environment here

There are some differences that the developer will see, for example separating 
out the various types of sources, like Cobol, Copybooks, BMS, etc with 
different mime types. But, using Eclipse IDE, git and Jenkins, a developer can 
push code from the IDE to the git server, like Bitbucket, kick of Jenkins 
build, which will push/pull the source code from Bitbucket/git to zFS using git 
client and Jenkins slave. That is using all open source.

>From there, something like DBBz, ANT script, possibly the mainframe SCM, or 
>JCL to copy the source to PDS and compile the programs.

However, to do a full SCLM, like the current mainframe source management tools, 
you can forget about deployment or movement between environments.

Jerry Edgington

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: git, z/OS and COBOL

At least one person has said they are using git for source code management of 
their z/OS COBOL programs.  A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor?  ISPF?  Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS 
and workstations?
5) How much UNIX knowledge do your developers need to be productive in this 
environment?
6) How do you connect to z/OS UNIX?  ssh?  TSO OMVS?
7) Do you use a GUI/visual merge product?  How?
8) Anything else you'd like to add!
Thanks, Frank

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



This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is confidential and 
protected by law from unauthorized disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If 

Re: git, z/OS and COBOL

[Edgington, Jerry]

Sure Frank. No problem with emailing privately.  Happy to help, if I can.

From: Frank Swarbrick [mailto:frank.swarbr...@outlook.com]
Sent: Tuesday, October 10, 2017 1:19 PM
To: Edgington, Jerry; IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

The reason I asked about the line numbers thing is that git seems to use a Unix 
compare utility that has no way (that I can tell) to ignore the line numbers.  
So if you insert a new line then the compare thinks that every line after that 
has changed, when truly only the line number has changed.  If you have a way 
around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to 
do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank

From: IBM Mainframe Discussion List 
> on behalf of 
Edgington, Jerry >
Sent: Tuesday, October 10, 2017 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank,

I have been working with several tools to build Cobol programs with as much 
open source as possible.  Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git.  The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, 
same rules apply
#1, if the z/OS batch compiler allows them, then no
#2, the open source eclipse based IDE will perform that same as ISPF.  So, no 
Cobol syntax checking
#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically 
allocate the necessary files, then executing the compile. However, I believe 
there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can 
submit JCL from the IDE for example
#5, using this setup, they will not know they are running on Unix on z/OS
#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP 
provides more functionality
#7, Eclipse has plugins to allow for merge, diff, etc.  I am using what was 
built for the Java environment here

There are some differences that the developer will see, for example separating 
out the various types of sources, like Cobol, Copybooks, BMS, etc with 
different mime types. But, using Eclipse IDE, git and Jenkins, a developer can 
push code from the IDE to the git server, like Bitbucket, kick of Jenkins 
build, which will push/pull the source code from Bitbucket/git to zFS using git 
client and Jenkins slave. That is using all open source.

>From there, something like DBBz, ANT script, possibly the mainframe SCM, or 
>JCL to copy the source to PDS and compile the programs.

However, to do a full SCLM, like the current mainframe source management tools, 
you can forget about deployment or movement between environments.

Jerry Edgington

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: git, z/OS and COBOL

At least one person has said they are using git for source code management of 
their z/OS COBOL programs.  A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor?  ISPF?  Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS 
and workstations?
5) How much UNIX knowledge do your developers need to be productive in this 
environment?
6) How do you connect to z/OS UNIX?  ssh?  TSO OMVS?
7) Do you use a GUI/visual merge product?  How?
8) Anything else you'd like to add!
Thanks, Frank

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



This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is confidential and 
protected by law from unauthorized disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply e-mail and destroy all copies of 
the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Re: git, z/OS and COBOL

[Frank Swarbrick]

The reason I asked about the line numbers thing is that git seems to use a Unix 
compare utility that has no way (that I can tell) to ignore the line numbers.  
So if you insert a new line then the compare thinks that every line after that 
has changed, when truly only the line number has changed.  If you have a way 
around that I'd be interested.
I've downloaded the DBBz alpha but am waiting on resources from other groups to 
do what parts are required so I can try it out.
Jerry, do you mind if I email you privately for more information?
Thanks, Frank

From: IBM Mainframe Discussion List  on behalf of 
Edgington, Jerry 
Sent: Tuesday, October 10, 2017 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git, z/OS and COBOL

Frank,

I have been working with several tools to build Cobol programs with as much 
open source as possible.  Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git.  The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, 
same rules apply
#1, if the z/OS batch compiler allows them, then no
#2, the open source eclipse based IDE will perform that same as ISPF.  So, no 
Cobol syntax checking
#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically 
allocate the necessary files, then executing the compile. However, I believe 
there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can 
submit JCL from the IDE for example
#5, using this setup, they will not know they are running on Unix on z/OS
#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP 
provides more functionality
#7, Eclipse has plugins to allow for merge, diff, etc.  I am using what was 
built for the Java environment here

There are some differences that the developer will see, for example separating 
out the various types of sources, like Cobol, Copybooks, BMS, etc with 
different mime types. But, using Eclipse IDE, git and Jenkins, a developer can 
push code from the IDE to the git server, like Bitbucket, kick of Jenkins 
build, which will push/pull the source code from Bitbucket/git to zFS using git 
client and Jenkins slave. That is using all open source.

>From there, something like DBBz, ANT script, possibly the mainframe SCM, or 
>JCL to copy the source to PDS and compile the programs.

However, to do a full SCLM, like the current mainframe source management tools, 
you can forget about deployment or movement between environments.

Jerry Edgington

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: git, z/OS and COBOL

At least one person has said they are using git for source code management of 
their z/OS COBOL programs.  A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor?  ISPF?  Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS 
and workstations?
5) How much UNIX knowledge do your developers need to be productive in this 
environment?
6) How do you connect to z/OS UNIX?  ssh?  TSO OMVS?
7) Do you use a GUI/visual merge product?  How?
8) Anything else you'd like to add!
Thanks, Frank

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



This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is confidential and 
protected by law from unauthorized disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply e-mail and destroy all copies of 
the original message.

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

Destination z article: Reflecting on Technology Progress

[Gabe Goldberg]

Reflecting on Technology Progress
As IBM Z advances and evolves, varied skills are needed

http://www.destinationz.org/Mainframe-Solution/Trends/Reflecting-Technology-Progress
http://tinyurl.com/y9m9w8jc

--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0

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

Re: git, z/OS and COBOL

[Edgington, Jerry]

Frank,

I have been working with several tools to build Cobol programs with as much 
open source as possible.  Here is what I am using;

Open Source
- Eclipse based IDE, with IBM Aqua and Jenkins plugins
- Jenkins
- git.  The git server is running off z/OS supported by another team

Cost item;
- IBM Dependency Based Build in Beta
- Deployment tool, if you wish to replace mainframe SCLM tool

Some general items;
- The compilers being used are the same ones used in z/OS batch compiles. So, 
same rules apply
#1, if the z/OS batch compiler allows them, then no
#2, the open source eclipse based IDE will perform that same as ISPF.  So, no 
Cobol syntax checking
#3, Actually both can be used. With DBBz, it is using SVC 99 to dynamically 
allocate the necessary files, then executing the compile. However, I believe 
there is an issue between zFS and PDS, where you can't mix them.
#4, the IBM Aqua allows for direct connection between z/OS and IDE. You can 
submit JCL from the IDE for example
#5, using this setup, they will not know they are running on Unix on z/OS
#6, The IBM Aqua connection, I believe, is either FTP or SSH. But, I think FTP 
provides more functionality
#7, Eclipse has plugins to allow for merge, diff, etc.  I am using what was 
built for the Java environment here

There are some differences that the developer will see, for example separating 
out the various types of sources, like Cobol, Copybooks, BMS, etc with 
different mime types. But, using Eclipse IDE, git and Jenkins, a developer can 
push code from the IDE to the git server, like Bitbucket, kick of Jenkins 
build, which will push/pull the source code from Bitbucket/git to zFS using git 
client and Jenkins slave. That is using all open source.

>From there, something like DBBz, ANT script, possibly the mainframe SCM, or 
>JCL to copy the source to PDS and compile the programs.

However, to do a full SCLM, like the current mainframe source management tools, 
you can forget about deployment or movement between environments.

Jerry Edgington

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Tuesday, October 10, 2017 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: git, z/OS and COBOL

At least one person has said they are using git for source code management of 
their z/OS COBOL programs.  A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor?  ISPF?  Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS 
and workstations?
5) How much UNIX knowledge do your developers need to be productive in this 
environment?
6) How do you connect to z/OS UNIX?  ssh?  TSO OMVS?
7) Do you use a GUI/visual merge product?  How?
8) Anything else you'd like to add!
Thanks, Frank

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



This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain information that is confidential and 
protected by law from unauthorized disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply e-mail and destroy all copies of 
the original message.

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

Re: Time on one LPAR on CEC

[White, Andy]

Thanks Paul and everyone else we got things to work on our lab with the 
following values, similar to yours Paul

STPMODE YES
STPZONE NO
TIMEZONE=E.09.00.00
OPERATOR NOPROMPT



Andy, we have STP setup to provide UTC (GMT) to the lpars/hardware.  Them we 
use the offset in the CLOCK member to set the "local" time for the lpars.  We 
have two CECs running lpars on US central time and lpars running on UK time.  I 
hope this helps.

Our CLOCK member for the US lpars with DST:
OPERATOR NOPROMPT
TIMEZONE W.05.00.00
STPMODE  YES
STPZONE  NO

Our CLOCK member for the UK lpars with DST:
OPERATOR NOPROMPT
TIMEZONE E.01.00.00
STPMODE  YES
STPZONE  NO

Thanks..

Paul Feller
AGT Mainframe Technical Support

The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only.  Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited.  If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

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

Re: Time on one LPAR on CEC

[Feller, Paul]

Andy, we have STP setup to provide UTC (GMT) to the lpars/hardware.  Them we 
use the offset in the CLOCK member to set the "local" time for the lpars.  We 
have two CECs running lpars on US central time and lpars running on UK time.  I 
hope this helps.

Our CLOCK member for the US lpars with DST:
OPERATOR NOPROMPT  
TIMEZONE W.05.00.00
STPMODE  YES   
STPZONE  NO

Our CLOCK member for the UK lpars with DST:
OPERATOR NOPROMPT  
TIMEZONE E.01.00.00
STPMODE  YES   
STPZONE  NO

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of White, Andy
Sent: Tuesday, October 10, 2017 08:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Time on one LPAR on CEC

George - Does this look right for the clockxx, so we won't use STP at all let 
the lpar use the system clock?

STPMODE NO
STPZONE NO
ETRMODE NO
ETRZONE NO
TIMEZONE=E.09.00.00
OPERATOR NOPROMPT

-


The Logical partition time offset is used when there is a requirement to run 
with LOCAL = UTC. In that case the LPAR time offset is set to the local time 
zone offset (e.g. +9 hours for Japan) and STPZONE NO, TIMEZONE=W.00.00.00 in 
CLOCKxx.

If you are running the z/OS systems with a local time zone offset and you do 
not wish to use the time zone specified via STP (e.g. as it is set to the US 
time zone) then you can specify STPZONE NO, TIMEZONE=E.09.00.00 (for Japan) in 
CLOCKxx.

Regards,George Kozakos
z/OS Software Service, Level 2 Supervisor

The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only.  Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited.  If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

--
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: Time on one LPAR on CEC

[Alan Altmark]

On Mon, 9 Oct 2017 16:31:58 +, Jesse 1 Robinson  
wrote:

>We run all LPARs on UTC with local time managed by STP. However, the LPAR 
>profile definition screen on HMC includes this:
>
>Clock Type Assignment  
>_   Standard time of day   
>_   Logical partition time offset  
>
>I believe that this option allows an LPAR to run with a (presumably 
>geographic) offset different from other LPARs on the same
>CEC. I thought that the option was intended specifically to allow shops to run 
>LPARs in support of various business applications
> around the world. I have no actual experience here. ;-(

Skip, all of the LPARs should be set to UTC with TOD clock offset 0.  Using TOD 
clock offsets is just a way to let you easily test future events today.   "I've 
got this code that supposed to run on April 1st of every year.  Will it?"

To get a different *timezone* in an LPAR, you use the OS's own timezone 
support.  While you CAN get the tz from the hardware as a default, you don't 
have to.

Alan Altmark
IBM Lab Services
z/VM and Linux

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

git, z/OS and COBOL

[Frank Swarbrick]

At least one person has said they are using git for source code management of 
their z/OS COBOL programs.  A few questions, if you don't mind.
1) Did you have to eliminate the line numbers in columns 1-6?
2) What do your developers use for their COBOL editor?  ISPF?  Off platform IDE?
3) Do you compile using JCL or UNIX?
4) Do you have a 'direct' file system connection (NFS, SMB, etc.) between z/OS 
and workstations?
5) How much UNIX knowledge do your developers need to be productive in this 
environment?
6) How do you connect to z/OS UNIX?  ssh?  TSO OMVS?
7) Do you use a GUI/visual merge product?  How?
8) Anything else you'd like to add!
Thanks, Frank

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

Re: ShopZ order response

[Paul Gilmartin]

On Mon, 9 Oct 2017 23:56:47 -0500, Edward Gould wrote:
>
>Our auditors would hop all over me and my management if we ever did something 
>like what you are talking about. One time I got a fix for one of our MF 
>products and I had to get the Presidents personal OK for me to upload it to 
>the MF. It was an *EXTREMELY* important fix. The auditor sat with me while I 
>explained to the President how I got the fix and how I was going to upload it 
>to the MF. The auditor grilled me like there was his job on the line (mine was 
>more likely the case). The auditor asked every blankety blank detail on how I 
>learned about the fix and the product that was involved the fix number and how 
>I d/l’d it. How was I going to get it to the MF and on and on. I felt like I 
>was guilty for even asking for it. I asked him in the future did he want to 
>get involved and micromanage every fix and he said *YES*. The President said 
>well we have a solution. I *Never* want to go through that again. He did not 
>blink when I asked him if Tape was OK and he said sure as long as the package 
>is sealed from the vendor to us.
> 
What if you need it within hours?  Well, the express services can be very 
prompt,
on a graduated price scale.  Or a courier pouch on a private jet, for even 
higher
cost.

>IOW we are going to be majorly hurt if IBM decided to drop tape.
> 
I'd be inclined to trust the SHA-1 checksum transmitted via an independent
verifiable conduit more than a heat-sealed polyethylene sleeve on a 3480 
cartridge.
SMP/E will verify the checksum and Do No Evil.

 All the risk with email, www, USB, arises from clients that 
automatically
execute programs embedded in documents or support cross-site scripting.  The
defense should be clients which unconditionally, not optionally, refuse to open
attachments.  Does CURL satisfy this? 

-- gil

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

Re: RECEIVE ORDER failing

[Richards, Robert B.]

Dave,

I *DO NOT* have UA93632 applied. Received, yes, applied, no.

Please post the outcome of your investigation. Inquiring minds want to avoid 
the same issue! :-)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, October 10, 2017 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RECEIVE ORDER failing

I suspect the change may have occurred at my end due to recent install of IBM 
maintenance.   Now, I'm wondering if the TLS handshake is failing at the IBM 
end due to the fact that this PTF removed depreciated ciphers...I have my TCPIP 
guys at our end reviewing.

TYPEREASON ID  FMID SYSMOD   ++HOLD DATA
 
--  -  ---  ---  

SYSTEM  ACTION HCPT420  UA93632  ++ HOLD(UA93632) SYS FMID(HCPT420) 
REASON(ACTION) DATE(17265)   
COMMENT 
 
 
(   
  * FUNCTION AFFECTED: z/OS SYSTEM SSL  
   (OA51519) *   
  
   
  * DESCRIPTION  : ACTION   
 *   
  
   
  * TIMING   : PRE-APPLY AND 
POST-APPLY  *   
  
   
  In this PTF, z/OS System SSL is 
changing the default SSL/TLS   
  cipher support.   
 

 
  The cipher defines the 
authentication, encryption, message 
  authentication code (MAC) and key 
exchange algorithm used when 
  negotiating a secure connection using 
SSL or TLS. When a System
  SSL application calls the 
gsk_environment_open() routine to
  establish a secure environment or 
calls the deprecated SSL/TLS 
  routine gsk_secure_soc_init() setting 
cipher_specs and/or  
  v3cipher_specs to NULL, the default 
enabled ciphers will no
  longer include the following DES and 
Triple DES ciphers.   
   SSL V3/TLS ciphers   
  
   09/0009: TLS_RSA_WITH_DES_CBC_SHA
  
   0A/000A: TLS_RSA_WITH_3DES_EDE_CBC_SHA   
  
   12/0012: TLS_DHE_DSS_WITH_DES_CBC_SHA
  
   13/0013: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA   
  
   15/0015: TLS_DHE_RSA_WITH_DES_CBC_SHA
  
   16/0016: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA   
  

  
_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Tuesday, October 10, 2017 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RECEIVE ORDER failing

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Yup!

220-dhebpcb01 secure FTP server
220  ready.
EZA1701I >>> AUTH TLS  
234 TLSv1  
EZA2895I Authentication negotiation succeeded  
EZA1701I >>> PBSZ 0
200 PBSZ=0 

Re: RECEIVE ORDER failing

[Jousma, David]

I suspect the change may have occurred at my end due to recent install of IBM 
maintenance.   Now, I'm wondering if the TLS handshake is failing at the IBM 
end due to the fact that this PTF removed depreciated ciphers...I have my TCPIP 
guys at our end reviewing.

TYPEREASON ID  FMID SYSMOD   ++HOLD DATA
 
--  -  ---  ---  

SYSTEM  ACTION HCPT420  UA93632  ++ HOLD(UA93632) SYS FMID(HCPT420) 
REASON(ACTION) DATE(17265)   
COMMENT 
 
 
(   
  * FUNCTION AFFECTED: z/OS SYSTEM SSL  
   (OA51519) *   
  
   
  * DESCRIPTION  : ACTION   
 *   
  
   
  * TIMING   : PRE-APPLY AND 
POST-APPLY  *   
  
   
  In this PTF, z/OS System SSL is 
changing the default SSL/TLS   
  cipher support.   
 

 
  The cipher defines the 
authentication, encryption, message 
  authentication code (MAC) and key 
exchange algorithm used when 
  negotiating a secure connection using 
SSL or TLS. When a System
  SSL application calls the 
gsk_environment_open() routine to
  establish a secure environment or 
calls the deprecated SSL/TLS 
  routine gsk_secure_soc_init() setting 
cipher_specs and/or  
  v3cipher_specs to NULL, the default 
enabled ciphers will no
  longer include the following DES and 
Triple DES ciphers.   
   SSL V3/TLS ciphers   
  
   09/0009: TLS_RSA_WITH_DES_CBC_SHA
  
   0A/000A: TLS_RSA_WITH_3DES_EDE_CBC_SHA   
  
   12/0012: TLS_DHE_DSS_WITH_DES_CBC_SHA
  
   13/0013: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA   
  
   15/0015: TLS_DHE_RSA_WITH_DES_CBC_SHA
  
   16/0016: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA   
  

  
_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Tuesday, October 10, 2017 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RECEIVE ORDER failing

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Yup!

220-dhebpcb01 secure FTP server
220  ready.
EZA1701I >>> AUTH TLS  
234 TLSv1  
EZA2895I Authentication negotiation succeeded  
EZA1701I >>> PBSZ 0
200 PBSZ=0 
EZA1701I >>> PROT P
200 Command PROT okay. 
EZA2906I Data connection protection is private 
EZA1459I NAME (deliverycb-bld.dhe.ibm.com:ABCDEFG):<--- not real Userid :-)

Then IBM generated user and password, followed by CCC (command channel 
cleared), the GET statement, TYPE I, EPSV, and finally opening a BINARY mode 

Re: Time on one LPAR on CEC

[White, Andy]

George - Does this look right for the clockxx, so we won't use STP at all let 
the lpar use the system clock?

STPMODE NO
STPZONE NO
ETRMODE NO
ETRZONE NO
TIMEZONE=E.09.00.00
OPERATOR NOPROMPT

-


The Logical partition time offset is used when there is a requirement to run 
with LOCAL = UTC. In that case the LPAR time offset is set to the local time 
zone offset (e.g. +9 hours for Japan) and STPZONE NO, TIMEZONE=W.00.00.00 in 
CLOCKxx.

If you are running the z/OS systems with a local time zone offset and you do 
not wish to use the time zone specified via STP (e.g. as it is set to the US 
time zone) then you can specify STPZONE NO, TIMEZONE=E.09.00.00 (for Japan) in 
CLOCKxx.

Regards,George Kozakos
z/OS Software Service, Level 2 Supervisor

The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only.  Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited.  If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

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

Re: RECEIVE ORDER failing

[Richards, Robert B.]

Yup!

220-dhebpcb01 secure FTP server
220  ready.
EZA1701I >>> AUTH TLS  
234 TLSv1  
EZA2895I Authentication negotiation succeeded  
EZA1701I >>> PBSZ 0
200 PBSZ=0 
EZA1701I >>> PROT P
200 Command PROT okay. 
EZA2906I Data connection protection is private 
EZA1459I NAME (deliverycb-bld.dhe.ibm.com:ABCDEFG):<--- not real Userid :-)

Then IBM generated user and password, followed by CCC (command channel 
cleared), the GET statement, TYPE I, EPSV, and finally opening a BINARY mode 
connection.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, October 10, 2017 8:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RECEIVE ORDER failing

Well, that's not the answer I was expecting!!!  It's the secured (FTP with TLS 
and HTTPS) that are failing for me.  I assume that's one of the methods you are 
using?

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Tuesday, October 10, 2017 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RECEIVE ORDER failing

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I succeeded within a minute of your email timestamp with a RFN to the same IP 
address (ending in 117 and using port 21)

bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, October 10, 2017 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RECEIVE ORDER failing

All,

Looks like SMPE RECEIVE ORDER is failing this morning.  I've tried HTTPS 
download too.

200 Type set to I.
EZA1460I Command:
EZA1701I >>> PASV
227 Entering Passive Mode (170,225,15,117,254,55) EZA1701I >>> RETR 
/2017101027988/PROD/GIMPAF.XML
150 Opening BINARY mode data connection for /2017101027988/PROD/GIMPAF.XML.
EZA2870I TLS security mechanism negotiation failed - data connection closed
425 Can't open data connection.
EZA1735I Std Return Code = 16425, Error Code = 00017 EZA1701I >>> QUIT
221 Goodbye.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




--
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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: RECEIVE ORDER failing

[Jousma, David]

Well, that's not the answer I was expecting!!!  It's the secured (FTP with TLS 
and HTTPS) that are failing for me.  I assume that's one of the methods you are 
using?

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Tuesday, October 10, 2017 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RECEIVE ORDER failing

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I succeeded within a minute of your email timestamp with a RFN to the same IP 
address (ending in 117 and using port 21)

bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, October 10, 2017 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RECEIVE ORDER failing

All,

Looks like SMPE RECEIVE ORDER is failing this morning.  I've tried HTTPS 
download too.

200 Type set to I.
EZA1460I Command:
EZA1701I >>> PASV
227 Entering Passive Mode (170,225,15,117,254,55) EZA1701I >>> RETR 
/2017101027988/PROD/GIMPAF.XML
150 Opening BINARY mode data connection for /2017101027988/PROD/GIMPAF.XML.
EZA2870I TLS security mechanism negotiation failed - data connection closed
425 Can't open data connection.
EZA1735I Std Return Code = 16425, Error Code = 00017 EZA1701I >>> QUIT
221 Goodbye.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




--
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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: RECEIVE ORDER failing

[Richards, Robert B.]

I succeeded within a minute of your email timestamp with a RFN to the same IP 
address (ending in 117 and using port 21)

bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, October 10, 2017 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RECEIVE ORDER failing

All,

Looks like SMPE RECEIVE ORDER is failing this morning.  I've tried HTTPS 
download too.

200 Type set to I.
EZA1460I Command:
EZA1701I >>> PASV
227 Entering Passive Mode (170,225,15,117,254,55) EZA1701I >>> RETR 
/2017101027988/PROD/GIMPAF.XML
150 Opening BINARY mode data connection for /2017101027988/PROD/GIMPAF.XML.
EZA2870I TLS security mechanism negotiation failed - data connection closed
425 Can't open data connection.
EZA1735I Std Return Code = 16425, Error Code = 00017 EZA1701I >>> QUIT
221 Goodbye.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




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

RECEIVE ORDER failing

[Jousma, David]

All,

Looks like SMPE RECEIVE ORDER is failing this morning.  I've tried HTTPS 
download too.

200 Type set to I.
EZA1460I Command:
EZA1701I >>> PASV
227 Entering Passive Mode (170,225,15,117,254,55)
EZA1701I >>> RETR /2017101027988/PROD/GIMPAF.XML
150 Opening BINARY mode data connection for /2017101027988/PROD/GIMPAF.XML.
EZA2870I TLS security mechanism negotiation failed - data connection closed
425 Can't open data connection.
EZA1735I Std Return Code = 16425, Error Code = 00017
EZA1701I >>> QUIT
221 Goodbye.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: Time on one LPAR on CEC

[White, Andy]

Thank you George this will work for us!  Andy

If you are running the z/OS systems with a local time zone offset and you do 
not wish to use the time zone specified via STP (e.g. as it is set to the US 
time zone) then you can specify STPZONE NO, TIMEZONE=E.09.00.00 (for Japan) in 
CLOCKxx.

Regards,George Kozakos
z/OS Software Service, Level 2 Supervisor
The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only.  Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited.  If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

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