Re: Time on one LPAR on CEC

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.

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

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

Re: RECEIVE ORDER failing

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:

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 =

Re: RECEIVE ORDER failing

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

Re: RECEIVE ORDER failing

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

Re: ShopZ order response

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.

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

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.

Re: git, z/OS and COBOL

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

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

Re: Question about management class autobackup=y

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:

Re: git, z/OS and COBOL

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

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

Destination z article: Reflecting on Technology Progress

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

Re: git, z/OS and COBOL

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:

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

PLO register specifications?

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,

Re: git, z/OS and COBOL

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

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

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

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

Re: Time on one LPAR on CEC

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

Re: Time on one LPAR on CEC

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

Re: Time on one LPAR on CEC

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

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)

Re: git, z/OS and COBOL

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

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

Transmit out class

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

Regular Expressions with Rexx

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,

Re: git, z/OS and COBOL

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:

Re: Regular Expressions with Rexx

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

Re: git, z/OS and COBOL

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

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

[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

Re: git, z/OS and COBOL

> 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

Re: git, z/OS and COBOL

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

Re: git, z/OS and COBOL

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

Re: Sort Question

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?

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

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

Re: git, z/OS and COBOL

[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

Re: git, z/OS and COBOL

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

Re: git, z/OS and COBOL

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

Re: Sort Question

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