Re: A new LPAR entry in a existing IODF
Hi, Thanks all for the response We are shutting down our z114 box and have just few weeks so wanted to try learn something out of it and it's an opportunity which I won't get as we have already moved our production to a new z hardware. So trying to explore some activity which can give me some good hardware knowledge and learning. Peter On Wed, 6 Feb, 2019, 12:21 AM Seymour J Metz ITYM a series of devices; HCD defines device numbering independent of any > OS, while the UCB is a control block specific to z/OS (and its relatives). > > You can change the logical CHPID associated with a physical CHPID without > re-cabling. What are you really trying to do? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Peter > Sent: Tuesday, February 5, 2019 4:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: A new LPAR entry in a existing IODF > > Thanks > > I would like to change the CHPID for a series of UCBs. > > Do I need to recable it or using the same port I can assign a different > CHPID ? > > Regards > Peter > > On Wed, 30 Jan, 2019, 8:34 PM R.S. > > Simply run HCD and play. > > You cannot destroy prod data (it will be WORK IODF), so feel safe > > playing - yes, just playing with various options. > > Your task is really simple, unless you have very specific requirements > > (not presented here) or your IODF is very complex. > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > > > > > > > > > > W dniu 2019-01-30 o 16:05, Peter pisze: > > > Hi, > > > > > > If I have to add a new LPAR name and use the same UCB,I/O, PROCESSOR > > > whatever the others LPARs are using in the same IODF then what would be > > > step to achieve this ? > > > > > > Is there an document or manual which explains about it ? > > > > > > Regards > > > Peter > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > . > > > > > > > > > == > > > > Jeśli nie jesteś adresatem tej wiadomości: > > > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > > zapisałeś na dysku). > > Wiadomość ta może zawierać chronione prawem informacje, które może > > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > > narusza prawo i może podlegać karze. > > > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > > > http://secure-web.cisco.com/1ljDvlh1HSwaay_z-uuKOntMxLnBf3e5SgXIuDBUqc6jtnM5-oP0BxQFe0kQivSeDzlWwPTTR1Ij5nX1XW0hmKfW7URb6x6jngWOCMO4ZFya_d5OaS8odmo9qFGlHI53uNytF167mqrx7Rm-Ea3cjUWDDwZvMCYBTBeQ4KtIJ06y3FM975ND5gxKjXGd6oQL5vsPU9iVewS4iGndPXtymfSUFIfSWMnhGYi9HcAWdUw2gjJldBN_iQfxlNCE3OI9Ezd8mIPW0ePO2gc2LU6H1jOfU8pbX4EPBTKdg_iheOn8Ao9NI6xZzFIBnYWWawB7k_UX8_-iXJT7p1q9sfyUAjG1ougjpQ2eCGxQoo72zXWIpaTlYbvFNnmP2o6FFBikvYG8E5UKJnHNsqtcxwVeNnL4nmN_cSYz9Pot3m2wE_O-mwkdRSdW-eLMbbMnNqDDj/http%3A%2F%2Fwww.mBank.pl, > e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > > 01.01.2018 r. wynosi 169.248.488 złotych. > > > > If you are not the addressee of this message: > > > > - let us know by replying to this e-mail (thank you!), > > - delete this message permanently (including all the copies which you > have > > printed out or saved). > > This message may contain legally protected information, which may be used > > exclusively by the addressee.Please be reminded that anyone who > > disseminates (copies, distributes) this message or takes any similar > > action, violates the law and may be penalised. > > > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, > 00-950 > > Warszawa, > http://secure-web.cisco.com/1ljDvlh1HSwaay_z-uuKOntMxLnBf3e5SgXIuDBUqc6jtnM5-oP0BxQFe0kQivSeDzlWwPTTR1Ij5nX1XW0hmKfW7URb6x6jngWOCMO4ZFya_d5OaS8odmo9qFGlHI53uNytF167mqrx7Rm-Ea3cjUWDDwZvMCYBTBeQ4KtIJ06y3FM975ND5gxKjXGd6oQL5vsPU9iVewS4iGndPXtymfSUFIfSWMnhGYi9HcAWdUw2gjJldBN_iQfxlNCE3OI9Ezd8mIPW0ePO2gc2LU6H1jOfU8pbX4EPBTKdg_iheOn8Ao9NI6xZzFIBnYWWawB7k_UX8_-iXJT7p1q9sfyUAjG1ougjpQ2eCGxQoo72zXWIpaTlYbvFNnmP2o6FFBikvYG8E5UKJnHNsqtcxwVeNnL4nmN_cSYz9Pot3m2wE_O-mwkdRSdW-eLMbbMnNqDDj/http%3A%2F%2Fwww.mBank.pl, > e-mail: kont...@mbank.pl. District Court for the > > Capital City of Warsaw, 12th Commercial Division of the National Court > > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > > amounting to PLN 169,248,488 as at 1 January 2018. > > > > -- > > For IBM-MAIN subscribe / signoff
Re: DFHSM FIXCDS before start-up?
So, the idea of running DFHSM with a a limited ARCCMDxx as part of the CDS restore job is not viable! Message ARC0009I DFSMSHSM STARTUP ATTEMPT FAILED, NOT A STARTED TASK happens So, I guess I have no choice but to document it as a task to be performed post 1st IPL of the recovered system And, I guess the errors ARC0747E UNABLE TO CATALOG DATA SET 753 ARC0747E (CONT.) HSM.MCDS.BACKUP.D0013495 DURING CDS BACKUP, RC=0008 ARC0747E UNABLE TO CATALOG DATA SET 754 ARC0747E (CONT.) HSM.BCDS.BACKUP.D0013495 DURING CDS BACKUP, RC=0008 ARC0747E UNABLE TO CATALOG DATA SET 755 ARC0747E (CONT.) HSM.OCDS.BACKUP.D0013495 DURING CDS BACKUP, RC=0008 ARC0747E UNABLE TO CATALOG DATA SET 756 ARC0747E (CONT.) HSM.JRNL.BACKUP.D0013495 DURING CDS BACKUP, RC=0008 ARC0748I LAST SUCCESSFUL CDS BACKUP-SET QUALIFIER IS 757 ARC0748I (CONT.) D0013495 ARC0741I CDS BACKUP ENDING AT 02:31:39 ON 2019/01/31, 758 ARC0741I (CONT.) STATUS=UNSUCCESSFUL Which only happen the first CDS backup cycle are not the end of the world. :) Just untidy > > > > If you don't want to run a special ARCCMDxx and you don't want to > > issue the FIXCDS command manually, what other approach did you have in > mind? > > > > > -Original Message- > > > From: IBM Mainframe Discussion List On > > > Behalf Of Gibney, Dave > > > Sent: Monday, February 04, 2019 3:19 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: DFHSM FIXCDS before start-up? > > > > > > I am refining our DR procedures. After I restore the DFHSM CDSs from > > > the > > most > > > recent back-up, I need to update so as to not overwrite that > > > back-up with > > the next > > > occurrence of CDS backup. The fine manual says to use FIXCDS S MHCR > > > PATCH(X'B1' nnn) to set the next back-up number. > > > FIXCDS requires an active DFHSM. Is there a supported way to make > > > this > > update > > > BEFORE starting DFHSM on the recovered system? > > > > > > I have thought of running DFHSM itself with a specifically tailored > > > parm > > to come up, > > > FIXCDS, and stop, but this seems overkill. I can also do it "manually" > > during the steps > > > documented for first IPL of recovered system, but this is more prone > > > to > > error or > > > omission. S DFHSM is in my COMMNDxx parmlib member. > > > > > > Dave Gibney > > > Information Technology Services > > > Washington State University > > > > > > > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO > > > IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS ADPLSEQS
In article you wrote: > Since 2008, forwarding to Bob has been possible only via a literal > "ether net" connection. Unfortunately, the IBM mail network does not > have such a connection. We wish it did. We as well find understanding > how to use some of the IPCS macros to be challenging. > > It is. It has the feel of an internal product that was handed off to > > someone to externalize and it's mostly there, but there are definitely > > corners that could use some re-vamping. 64-bit was a pain as it required > > non-intuitive calls to get what was needed. Bob Wright helped me out > > in this forum and if you open an SR, that's who I'd ask it get forwarded > > to. > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > Poughkeepsie NY Jim, Thanks. That is sad. I don't think I knew that, but these days it seems like we're losing more than I can keep track of. He was always helpful when I had some question about IPCS and the voodoo that surrounded it. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS ADPLSEQS
Since 2008, forwarding to Bob has been possible only via a literal "ether net" connection. Unfortunately, the IBM mail network does not have such a connection. We wish it did. We as well find understanding how to use some of the IPCS macros to be challenging. > It is. It has the feel of an internal product that was handed off to > someone to externalize and it's mostly there, but there are definitely > corners that could use some re-vamping. 64-bit was a pain as it required > non-intuitive calls to get what was needed. Bob Wright helped me out > in this forum and if you open an SR, that's who I'd ask it get forwarded > to. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Internal Coupling Channel on z13
It is possible to convert ENQ with SYSTEMS to RESERVE, but the performance ramifications are unacceptable. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony Harminc Sent: Monday, February 4, 2019 3:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Internal Coupling Channel on z13 On Wed, 30 Jan 2019 at 01:53, Ed Jaffe wrote: > Is it no longer possible to use "old school" shared DASD RESERVE/RELEASE > to protect data? I know it won't work for sharing PDSE, but for > old-school PDS and sequential, it should still work. Reserve/Release works only if someone issues those CCWs. DADSM issues them to protect the VTOC, and maybe catalog management does (I don't know), and the Binder does if SYSLMOD is on a shared device. But data management generally does not, so e.g. if you have two jobs on separate LPARs and each has DISP=OLD for the same dataset using QSAM or BPAM, say, nothing protects the data itself from being written from both sides at the same time. You can put the Reserve/Release in your application program (via ENQ), but that's not going to work very well for your typical COBOL program, and unless you have extreme data separation by volume, performance will suck, to put it politely. Typically what is wanted is the notion of ENQ with the SYSTEMS option, and that's just not available (and is silently ignored if requested) without either GRS or one of the products popular in the 1980s that implemented GRS-like behaviour using Reserve/Release on some kind of control dataset. I don't know if any of those products are still on the market. Or why not, as another poster suggested, use a GRS ring. This can protect applications against dataset corruption at on-the-box CTC speed, and I don't see any obvious reason if would be slower than a timeshared CF on the same machine. Of course you get GRS - not Parallel Sysplex, and there are various things such as JES2 shared SPOOL that need the Sysplex. Tony H. -- 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: Style (was: Newbie SMP/E questions)
LISTSERV and Netnews are both good; Stack Exchange is not bad; most of the other options run from bad on down. I find both gmail and outlook to be pathetic. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Monday, February 4, 2019 10:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Style (was: Newbie SMP/E questions) Random thoughts... The fundamental issue is that email isn't the best way to handle online group conversations. Many better solutions have been offered, from NNTP, Notes, Stack Exchange, Slash Dot, and Lord knows how many others. SX is extremely protective of their software, and for whatever reasons, none of the general solutions ever seem to catch on. Gmail does a pretty good job of managing this list for me. It does however, make it far to easy to regurgitate all previous messages as in-line quoting. I have gotten in the habit of trimming that (usually). Automatic quoting of the previous message is practically evil. Why we put up with that is beyond my understanding. No previous communication technology did that. sas -- 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: A new LPAR entry in a existing IODF
ITYM a series of devices; HCD defines device numbering independent of any OS, while the UCB is a control block specific to z/OS (and its relatives). You can change the logical CHPID associated with a physical CHPID without re-cabling. What are you really trying to do? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Peter Sent: Tuesday, February 5, 2019 4:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: A new LPAR entry in a existing IODF Thanks I would like to change the CHPID for a series of UCBs. Do I need to recable it or using the same port I can assign a different CHPID ? Regards Peter On Wed, 30 Jan, 2019, 8:34 PM R.S. Simply run HCD and play. > You cannot destroy prod data (it will be WORK IODF), so feel safe > playing - yes, just playing with various options. > Your task is really simple, unless you have very specific requirements > (not presented here) or your IODF is very complex. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2019-01-30 o 16:05, Peter pisze: > > Hi, > > > > If I have to add a new LPAR name and use the same UCB,I/O, PROCESSOR > > whatever the others LPARs are using in the same IODF then what would be > > step to achieve this ? > > > > Is there an document or manual which explains about it ? > > > > Regards > > Peter > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > . > > > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > http://secure-web.cisco.com/1ljDvlh1HSwaay_z-uuKOntMxLnBf3e5SgXIuDBUqc6jtnM5-oP0BxQFe0kQivSeDzlWwPTTR1Ij5nX1XW0hmKfW7URb6x6jngWOCMO4ZFya_d5OaS8odmo9qFGlHI53uNytF167mqrx7Rm-Ea3cjUWDDwZvMCYBTBeQ4KtIJ06y3FM975ND5gxKjXGd6oQL5vsPU9iVewS4iGndPXtymfSUFIfSWMnhGYi9HcAWdUw2gjJldBN_iQfxlNCE3OI9Ezd8mIPW0ePO2gc2LU6H1jOfU8pbX4EPBTKdg_iheOn8Ao9NI6xZzFIBnYWWawB7k_UX8_-iXJT7p1q9sfyUAjG1ougjpQ2eCGxQoo72zXWIpaTlYbvFNnmP2o6FFBikvYG8E5UKJnHNsqtcxwVeNnL4nmN_cSYz9Pot3m2wE_O-mwkdRSdW-eLMbbMnNqDDj/http%3A%2F%2Fwww.mBank.pl, > e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2018 r. wynosi 169.248.488 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,http://secure-web.cisco.com/1ljDvlh1HSwaay_z-uuKOntMxLnBf3e5SgXIuDBUqc6jtnM5-oP0BxQFe0kQivSeDzlWwPTTR1Ij5nX1XW0hmKfW7URb6x6jngWOCMO4ZFya_d5OaS8odmo9qFGlHI53uNytF167mqrx7Rm-Ea3cjUWDDwZvMCYBTBeQ4KtIJ06y3FM975ND5gxKjXGd6oQL5vsPU9iVewS4iGndPXtymfSUFIfSWMnhGYi9HcAWdUw2gjJldBN_iQfxlNCE3OI9Ezd8mIPW0ePO2gc2LU6H1jOfU8pbX4EPBTKdg_iheOn8Ao9NI6xZzFIBnYWWawB7k_UX8_-iXJT7p1q9sfyUAjG1ougjpQ2eCGxQoo72zXWIpaTlYbvFNnmP2o6FFBikvYG8E5UKJnHNsqtcxwVeNnL4nmN_cSYz9Pot3m2wE_O-mwkdRSdW-eLMbbMnNqDDj/http%3A%2F%2Fwww.mBank.pl, > e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169,248,488 as at 1 January 2018. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 4.2, 5.1 and 5.2 EOS Dates
Apologies: The V5.1 and V5.2 date is April 30, 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 SCHEDULE statement
replying to myself, I see that my user and myself were confused about SCHEDULE
and BEFORE and AFTER, not related. jobgroup is what I think he's looking for
and after I activate z22 level we can test.
thanks Al and David
Carmen Vitullo
- Original Message -
From: "Carmen Vitullo"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 5, 2019 1:08:36 PM
Subject: Re: JES2 SCHEDULE statement
KC got me again, when searching for the JES2 Schedule Statement, 2.3 was the
default, I should have stuck with my 2.2 books I have local
my user ran another test based on the examples David provided, it 'worked' with
the kaviot,
HASP JOBGROUP activation requires Z22 checkpoint level
I had not activated z22 mode on the prod mas just yet.
I'll review the Fine Manual again, thank you Al
Carmen Vitullo
- Original Message -
From: "Alva John Nims (Al)"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 5, 2019 1:02:51 PM
Subject: Re: JES2 SCHEDULE statement
In my z/OS 2.02 version of MVS JCL Reference, there is NO "AFTER=" option on
the SCHEDULE statement.
There is an "AFTER" JCL statement:
"AFTER statement
Purpose: Use the AFTER JCL statement, along with GJOB and JOBSET statements, to
define jobs and sets of jobs that must execute in a particular sequence. AFTER
and BEFORE statements have the same syntax and define the dependencies either
as a dependent/parent or parent/dependent. Internally, all relationships are
managed as parent/dependent."
Al Nims
Systems Admin/Programmer III
UF Information Technology
720 Bld. 3rd Floor, #9
P.O. Box 112050
Gainesville, FL. 32611
(e) ajn...@ufl.edu
(p) (352) 273-1298
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 05, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 SCHEDULE statement
I'm running z/OS 2.2 @ RSU1805 level and one of my users is trying to use the
JES2 schedule statement; from all the doc I found the AFTER=jobname should be
valid @ 2.2 but they are getting a JCL error during testing, my test had the
same results;
3 // SCHEDULE HOLDUNTL=('09:50','02/05/2019'),AFTER=joba
4 //A EXEC PGM=IEFBR14
STMT NO. MESSAGE
3 IEFC630I UNIDENTIFIED KEYWORD AFTER
checking the KC looks like this should be valid, am I missing something?
thanks
Carmen
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 SCHEDULE statement
yeah, I have z22 active on my test image, and the $Tactivate shows it would be
successful in prod, I'm just procrastinating - thanks again
Carmen Vitullo
- Original Message -
From: "David Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 5, 2019 1:16:34 PM
Subject: Re: JES2 SCHEDULE statement
>>HASP JOBGROUP activation requires Z22 checkpoint level
Forgot about that. We did it long ago. Nothing to worry about, just do the test
activate first to make sure your checkpoint is large enough.
_
Dave Jousma
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 On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 5, 2019 2:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 SCHEDULE statement
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
KC got me again, when searching for the JES2 Schedule Statement, 2.3 was the
default, I should have stuck with my 2.2 books I have local my user ran another
test based on the examples David provided, it 'worked' with the kaviot,
HASP JOBGROUP activation requires Z22 checkpoint level I had not activated
z22 mode on the prod mas just yet.
I'll review the Fine Manual again, thank you Al
Carmen Vitullo
- Original Message -
From: "Alva John Nims (Al)"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 5, 2019 1:02:51 PM
Subject: Re: JES2 SCHEDULE statement
In my z/OS 2.02 version of MVS JCL Reference, there is NO "AFTER=" option on
the SCHEDULE statement.
There is an "AFTER" JCL statement:
"AFTER statement
Purpose: Use the AFTER JCL statement, along with GJOB and JOBSET statements, to
define jobs and sets of jobs that must execute in a particular sequence. AFTER
and BEFORE statements have the same syntax and define the dependencies either
as a dependent/parent or parent/dependent. Internally, all relationships are
managed as parent/dependent."
Al Nims
Systems Admin/Programmer III
UF Information Technology
720 Bld. 3rd Floor, #9
P.O. Box 112050
Gainesville, FL. 32611
(e) ajn...@ufl.edu
(p) (352) 273-1298
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 05, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 SCHEDULE statement
I'm running z/OS 2.2 @ RSU1805 level and one of my users is trying to use the
JES2 schedule statement; from all the doc I found the AFTER=jobname should be
valid @ 2.2 but they are getting a JCL error during testing, my test had the
same results;
3 // SCHEDULE HOLDUNTL=('09:50','02/05/2019'),AFTER=joba
4 //A EXEC PGM=IEFBR14
STMT NO. MESSAGE
3 IEFC630I UNIDENTIFIED KEYWORD AFTER
checking the KC looks like this should be valid, am I missing something?
thanks
Carmen
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
**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,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 SCHEDULE statement
>>HASP JOBGROUP activation requires Z22 checkpoint level
Forgot about that. We did it long ago. Nothing to worry about, just do the
test activate first to make sure your checkpoint is large enough.
_
Dave Jousma
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 On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 5, 2019 2:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 SCHEDULE statement
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
KC got me again, when searching for the JES2 Schedule Statement, 2.3 was the
default, I should have stuck with my 2.2 books I have local my user ran another
test based on the examples David provided, it 'worked' with the kaviot,
HASP JOBGROUP activation requires Z22 checkpoint level I had not activated
z22 mode on the prod mas just yet.
I'll review the Fine Manual again, thank you Al
Carmen Vitullo
- Original Message -
From: "Alva John Nims (Al)"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 5, 2019 1:02:51 PM
Subject: Re: JES2 SCHEDULE statement
In my z/OS 2.02 version of MVS JCL Reference, there is NO "AFTER=" option on
the SCHEDULE statement.
There is an "AFTER" JCL statement:
"AFTER statement
Purpose: Use the AFTER JCL statement, along with GJOB and JOBSET statements, to
define jobs and sets of jobs that must execute in a particular sequence. AFTER
and BEFORE statements have the same syntax and define the dependencies either
as a dependent/parent or parent/dependent. Internally, all relationships are
managed as parent/dependent."
Al Nims
Systems Admin/Programmer III
UF Information Technology
720 Bld. 3rd Floor, #9
P.O. Box 112050
Gainesville, FL. 32611
(e) ajn...@ufl.edu
(p) (352) 273-1298
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 05, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 SCHEDULE statement
I'm running z/OS 2.2 @ RSU1805 level and one of my users is trying to use the
JES2 schedule statement; from all the doc I found the AFTER=jobname should be
valid @ 2.2 but they are getting a JCL error during testing, my test had the
same results;
3 // SCHEDULE HOLDUNTL=('09:50','02/05/2019'),AFTER=joba
4 //A EXEC PGM=IEFBR14
STMT NO. MESSAGE
3 IEFC630I UNIDENTIFIED KEYWORD AFTER
checking the KC looks like this should be valid, am I missing something?
thanks
Carmen
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
**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: JES2 SCHEDULE statement
KC got me again, when searching for the JES2 Schedule Statement, 2.3 was the
default, I should have stuck with my 2.2 books I have local
my user ran another test based on the examples David provided, it 'worked' with
the kaviot,
HASP JOBGROUP activation requires Z22 checkpoint level
I had not activated z22 mode on the prod mas just yet.
I'll review the Fine Manual again, thank you Al
Carmen Vitullo
- Original Message -
From: "Alva John Nims (Al)"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 5, 2019 1:02:51 PM
Subject: Re: JES2 SCHEDULE statement
In my z/OS 2.02 version of MVS JCL Reference, there is NO "AFTER=" option on
the SCHEDULE statement.
There is an "AFTER" JCL statement:
"AFTER statement
Purpose: Use the AFTER JCL statement, along with GJOB and JOBSET statements, to
define jobs and sets of jobs that must execute in a particular sequence. AFTER
and BEFORE statements have the same syntax and define the dependencies either
as a dependent/parent or parent/dependent. Internally, all relationships are
managed as parent/dependent."
Al Nims
Systems Admin/Programmer III
UF Information Technology
720 Bld. 3rd Floor, #9
P.O. Box 112050
Gainesville, FL. 32611
(e) ajn...@ufl.edu
(p) (352) 273-1298
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 05, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 SCHEDULE statement
I'm running z/OS 2.2 @ RSU1805 level and one of my users is trying to use the
JES2 schedule statement; from all the doc I found the AFTER=jobname should be
valid @ 2.2 but they are getting a JCL error during testing, my test had the
same results;
3 // SCHEDULE HOLDUNTL=('09:50','02/05/2019'),AFTER=joba
4 //A EXEC PGM=IEFBR14
STMT NO. MESSAGE
3 IEFC630I UNIDENTIFIED KEYWORD AFTER
checking the KC looks like this should be valid, am I missing something?
thanks
Carmen
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 SCHEDULE statement
In my z/OS 2.02 version of MVS JCL Reference, there is NO "AFTER=" option on
the SCHEDULE statement.
There is an "AFTER" JCL statement:
"AFTER statement
Purpose: Use the AFTER JCL statement, along with GJOB and JOBSET
statements, to define jobs and sets of jobs that must execute in a particular
sequence. AFTER and BEFORE statements have the same syntax and define the
dependencies either as a dependent/parent or parent/dependent. Internally, all
relationships are managed as parent/dependent."
Al Nims
Systems Admin/Programmer III
UF Information Technology
720 Bld. 3rd Floor, #9
P.O. Box 112050
Gainesville, FL. 32611
(e) ajn...@ufl.edu
(p) (352) 273-1298
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 05, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 SCHEDULE statement
I'm running z/OS 2.2 @ RSU1805 level and one of my users is trying to use the
JES2 schedule statement; from all the doc I found the AFTER=jobname should be
valid @ 2.2 but they are getting a JCL error during testing, my test had the
same results;
3 // SCHEDULE HOLDUNTL=('09:50','02/05/2019'),AFTER=joba
4 //A EXEC PGM=IEFBR14
STMT NO. MESSAGE
3 IEFC630I UNIDENTIFIED KEYWORD AFTER
checking the KC looks like this should be valid, am I missing something?
thanks
Carmen
--
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: Style (was: How can I get reports in the Output Queue in SDSF to print)
Paul Gilmartin wrote, in part: >Good idea. But why not start each of your responses on a new line? And >distingush original text by ">" quotation marks or indention? Does not >MS-Exchange, which appears to be your mailer, support such things? A nit, Gil: Exchange is an MTA, not an MUA. Outlook is the (usual but not always) MUA for Exchange. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS ADPLSEQS
Thanks for your help Don. I finally did get the symbol defined correctly … symbol 00. ASID(X'0046') DSPNAME(symbol) LENGTH(X'1000') AREA(symbol) DROP I was priming the ESSY with a DSECT=NO version and it had a -1 as the asid word. I was only updating the 2nd half of the word with a 2 byte ASID leaving in the top half. (dumb mistake) Thanks again, Dan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS ADPLSEQS
In article <7271721887429173.wa.zos.jes2gmail@listserv.ua.edu> you wrote: > The ESSY is rather odd ??? > If I use ABITS=64 it this request gets a RC 12. > When I list the symbol I get >symbol 00. ASID(X'0026') LENGTH(X'1000') AREA(symbol) DROP > If I issue "L symbol DSPNAME(symbol)" and list the symbols again a mysterious > "X" symbol is defined ??? > X 00. ASID(X'0026') DSPNAME(symbol) LENGTH(X'1000') > AREA(symbol) DROP > This stuff is just bizarre and not well documented. It is. It has the feel of an internal product that was handed off to someone to externalize and it's mostly there, but there are definitely corners that could use some re-vamping. 64-bit was a pain as it required non-intuitive calls to get what was needed. Bob Wright helped me out in this forum and if you open an SR, that's who I'd ask it get forwarded to. In this particular case though, did you set the BLSRXSSP field to say that you wanted ABITS(64)? &P.BIT64 EQU BIT2 BLSRESSY structures should be returned in ABITS(64) format -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Style (was: How can I get reports in the Output Queue in SDSF to print)
On Tue, 5 Feb 2019 17:10:52 +, McCabe, Ron wrote: > >I found it easier to put my responses below after each of your questions. > Good idea. But why not start each of your responses on a new line? And distingush original text by ">" quotation marks or indention? Does not MS-Exchange, which appears to be your mailer, support such things? And the voluminous confidentiality notice is simply absurd when you post to a publicly accessible list. >-Original Message- >From: Vince Getgood >Sent: Tuesday, February 05, 2019 1:41 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: How can I get reports in the Output Queue in SDSF to print > >Ron, >Forgive me, but it sounds like you are a little out of your depth with this. >- That is true and it is because I'm not good with the networking side of >things. > >Z13 doesn't allow a CTC? Since when? AFAIK, you can have a FICON CTC on ANY >z hardware. - True, but I was going to be using Virtual CTC which if I'm not >mistaken does work as long as I run z/OS as a guest under z/VM but I could be >wrong. > >"TCPNJE has been working for nearly 3 years and then all of a sudden it isn't >and networking says it's a mainframe problem" - er, NO. - I agree but that is >life and once I prove them wrong which happens all the time I will be able to >hold it over their heads for about 2 days because then they will forget about >it. > >If noihing changed on the mainframe, then HOW can it be a mainframe issue? >MUCH more likely that something in the network has changed. > >What, exactly, are you trying to achieve? Your original post didn't mention >anything about z/VM - you said you wanted output to print.. - We are >"transmitting" reports from our z/OS LPAR to our z/VM LPAR using TCPNJE on the >z/OS side and RSCS on the z/VM side. > >It sounds like you are trying to send output from a z/OS lpar to a z/VM lpar >(I assume on the same hardware) over a network. Can you clarify? - Hopefully >the answer from the last question helped explain what we are trying to >accomplish. > >I think you may need more in-depth help than the list can supply... You may >want to cross post on the z/VM list. - I do have an open PMR with IBM support >so I'm hoping that will be good enough to get this resolved.. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN >Confidentiality Notice: This e- mail and all attachments may contain >CONFIDENTIAL information and are meant solely for the intended recipient. It >may contain controlled, privileged, or proprietary information that is >protected under applicable law and shall not be disclosed to any unauthorized >third party. If you are not the intended recipient, you are hereby notified >that any unauthorized review, action, disclosure, distribution, or >reproduction of any information contained in this e- mail and any attachments >is strictly PROHIBITED. If you received this e- mail in error, please reply to >the sender immediately stating that this transmission was misdirected, and >delete or destroy all electronic and paper copies of this e-mail and >attachments without disclosing the contents. This e- mail does not grant or >assign rights of ownership in the proprietary subject matter herein, nor shall >it be construed as a joint venture, partnership, teaming agreement, or any >other formal business relationship. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS ADPLSEQS
The ESSY is rather odd … If I use ABITS=64 it this request gets a RC 12. When I list the symbol I get symbol 00. ASID(X'0026') LENGTH(X'1000') AREA(symbol) DROP If I issue "L symbol DSPNAME(symbol)" and list the symbols again a mysterious "X" symbol is defined … X 00. ASID(X'0026') DSPNAME(symbol) LENGTH(X'1000') AREA(symbol) DROP This stuff is just bizarre and not well documented. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM FIXCDS before start-up?
I regenerate my DR restore jobs at the end of the daily FDRABR DR back-up jobs. We use DFHSM for migration and application ack-and restore. When practicing the DR recovery, I need to restore DFHSM using the most recent CDS back-up. So, this scenario is that I've just restored all CDS (and JRNL) from the latest back-up. So, the version numder in the MCDS for the next backup is the one I used to restore. I'd like to reset that value before starting DFHSM with these restored CDSs. To me, this would be the least error prone path. I'd like it to be a step in the restore job. It seems that to do this, that step in the restore job needs to be DFHSM itself, with an abbreviated ARCCMDxx member that I'll need to also dynamically generate. In an temp PDS? So, now a three step DFHSM recovery job. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Allan Staller > Sent: Tuesday, February 05, 2019 5:18 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM FIXCDS before start-up? > > Why would you want to do this? > I presume you have the health-check recommended 4 backups (or more). > If the current backup is 'N', the next backup would be taken to N+1. > N will not be overwritten for 3 additional cycles. More than long enough to > make a backup copy. > > To answer your question about fixcds prior to startup, no. What I have done > is add the FIXCDS command to the end of ARCCMD* This will be executed > before a CDS backup can occur. > > You can also bring dfHSM up in emergency mode obtain the backup number > and issue the FIXCDS command followed by SETSYS NOEMERGENCY. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gibney, Dave > Sent: Monday, February 4, 2019 5:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM FIXCDS before start-up? > > I am refining our DR procedures. After I restore the DFHSM CDSs from the > most recent back-up, I need to update so as to not overwrite that back-up > with the next occurrence of CDS backup. The fine manual says to use FIXCDS > S MHCR PATCH(X'B1' nnn) to set the next back-up number. > FIXCDS requires an active DFHSM. Is there a supported way to make this > update BEFORE starting DFHSM on the recovered system? > > I have thought of running DFHSM itself with a specifically tailored parm to > come up, FIXCDS, and stop, but this seems overkill. I can also do it > "manually" > during the steps documented for first IPL of recovered system, but this is > more prone to error or omission. S DFHSM is in my COMMNDxx parmlib > member. > > Dave Gibney > Information Technology Services > Washington State University > > > -- > 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: How can I get reports in the Output Queue in SDSF to print
Vince, I found it easier to put my responses below after each of your questions. Thanks, Ron McCabe Mutual of Enumclaw -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vince Getgood Sent: Tuesday, February 05, 2019 1:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How can I get reports in the Output Queue in SDSF to print Ron, Forgive me, but it sounds like you are a little out of your depth with this. - That is true and it is because I'm not good with the networking side of things. Z13 doesn't allow a CTC? Since when? AFAIK, you can have a FICON CTC on ANY z hardware. - True, but I was going to be using Virtual CTC which if I'm not mistaken does work as long as I run z/OS as a guest under z/VM but I could be wrong. "TCPNJE has been working for nearly 3 years and then all of a sudden it isn't and networking says it's a mainframe problem" - er, NO. - I agree but that is life and once I prove them wrong which happens all the time I will be able to hold it over their heads for about 2 days because then they will forget about it. If nothing changed on the mainframe, then HOW can it be a mainframe issue? MUCH more likely that something in the network has changed. What, exactly, are you trying to achieve? Your original post didn't mention anything about z/VM - you said you wanted output to print.. - We are "transmitting" reports from our z/OS LPAR to our z/VM LPAR using TCPNJE on the z/OS side and RSCS on the z/VM side. It sounds like you are trying to send output from a z/OS lpar to a z/VM lpar (I assume on the same hardware) over a network. Can you clarify? - Hopefully the answer from the last question helped explain what we are trying to accomplish. I think you may need more in-depth help than the list can supply... You may want to cross post on the z/VM list. - I do have an open PMR with IBM support so I'm hoping that will be good enough to get this resolved.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality Notice: This e- mail and all attachments may contain CONFIDENTIAL information and are meant solely for the intended recipient. It may contain controlled, privileged, or proprietary information that is protected under applicable law and shall not be disclosed to any unauthorized third party. If you are not the intended recipient, you are hereby notified that any unauthorized review, action, disclosure, distribution, or reproduction of any information contained in this e- mail and any attachments is strictly PROHIBITED. If you received this e- mail in error, please reply to the sender immediately stating that this transmission was misdirected, and delete or destroy all electronic and paper copies of this e-mail and attachments without disclosing the contents. This e- mail does not grant or assign rights of ownership in the proprietary subject matter herein, nor shall it be construed as a joint venture, partnership, teaming agreement, or any other formal business relationship. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 SCHEDULE statement
No problem, it didn't wrap on my end, looks good, thanks David
Carmen Vitullo
- Original Message -
From: "David Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 5, 2019 10:11:05 AM
Subject: Re: JES2 SCHEDULE statement
Sorry about the wrap. That wasn’t how I sent it.
_
Dave Jousma
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 On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 5, 2019 11:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 SCHEDULE statement
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
No David, I'm not sure, the only testing I've done was with the holduntil,
looks like the jobgroup is required for the AFTER= statement by the looks of
your working example
Carmen Vitullo
- Original Message -
From: "David Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 5, 2019 10:05:46 AM
Subject: Re: JES2 SCHEDULE statement
Are you sure you have the syntax correct? Here is a jobgroup I actively use to
run my z/os cloning jobs. I am at V2.3 however.
//TESTG JOBGROUP ERROR=(RC>4),ONERROR=FLUSH //TESTA GJOB //TESTB GJOB // AFTER
NAME=TESTA,WHEN=(RC=0) //TESTC GJOB // AFTER NAME=TESTB,WHEN=(RC<=4) //TESTD
GJOB // AFTER NAME=TESTC,WHEN=(RC=0) //TESTG ENDGROUP //TESTA JOB '1 RST01A
Init', // CLASS=X,MSGCLASS=T // SCHEDULE JOBGROUP=TESTG .
.
.
.
_
Dave Jousma
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 On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 5, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 SCHEDULE statement
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
I'm running z/OS 2.2 @ RSU1805 level and one of my users is trying to use the
JES2 schedule statement; from all the doc I found the AFTER=jobname should be
valid @ 2.2 but they are getting a JCL error during testing, my test had the
same results;
3 // SCHEDULE HOLDUNTL=('09:50','02/05/2019'),AFTER=joba
4 //A EXEC PGM=IEFBR14
STMT NO. MESSAGE
3 IEFC630I UNIDENTIFIED KEYWORD AFTER
checking the KC looks like this should be valid, am I missing something?
thanks
Carmen
--
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, 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
Re: JES2 SCHEDULE statement
Sorry about the wrap. That wasn’t how I sent it.
_
Dave Jousma
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 On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 5, 2019 11:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 SCHEDULE statement
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
No David, I'm not sure, the only testing I've done was with the holduntil,
looks like the jobgroup is required for the AFTER= statement by the looks of
your working example
Carmen Vitullo
- Original Message -
From: "David Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 5, 2019 10:05:46 AM
Subject: Re: JES2 SCHEDULE statement
Are you sure you have the syntax correct? Here is a jobgroup I actively use to
run my z/os cloning jobs. I am at V2.3 however.
//TESTG JOBGROUP ERROR=(RC>4),ONERROR=FLUSH //TESTA GJOB //TESTB GJOB // AFTER
NAME=TESTA,WHEN=(RC=0) //TESTC GJOB // AFTER NAME=TESTB,WHEN=(RC<=4) //TESTD
GJOB // AFTER NAME=TESTC,WHEN=(RC=0) //TESTG ENDGROUP //TESTA JOB '1 RST01A
Init', // CLASS=X,MSGCLASS=T // SCHEDULE JOBGROUP=TESTG .
.
.
.
_
Dave Jousma
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 On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 5, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 SCHEDULE statement
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
I'm running z/OS 2.2 @ RSU1805 level and one of my users is trying to use the
JES2 schedule statement; from all the doc I found the AFTER=jobname should be
valid @ 2.2 but they are getting a JCL error during testing, my test had the
same results;
3 // SCHEDULE HOLDUNTL=('09:50','02/05/2019'),AFTER=joba
4 //A EXEC PGM=IEFBR14
STMT NO. MESSAGE
3 IEFC630I UNIDENTIFIED KEYWORD AFTER
checking the KC looks like this should be valid, am I missing something?
thanks
Carmen
--
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, 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: JES2 SCHEDULE statement
No David, I'm not sure, the only testing I've done was with the holduntil,
looks like the jobgroup is required for the AFTER= statement by the looks of
your working example
Carmen Vitullo
- Original Message -
From: "David Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 5, 2019 10:05:46 AM
Subject: Re: JES2 SCHEDULE statement
Are you sure you have the syntax correct? Here is a jobgroup I actively use to
run my z/os cloning jobs. I am at V2.3 however.
//TESTG JOBGROUP ERROR=(RC>4),ONERROR=FLUSH
//TESTA GJOB
//TESTB GJOB
// AFTER NAME=TESTA,WHEN=(RC=0)
//TESTC GJOB
// AFTER NAME=TESTB,WHEN=(RC<=4)
//TESTD GJOB
// AFTER NAME=TESTC,WHEN=(RC=0)
//TESTG ENDGROUP
//TESTA JOB '1 RST01A Init',
// CLASS=X,MSGCLASS=T
// SCHEDULE JOBGROUP=TESTG
.
.
.
.
_
Dave Jousma
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 On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 5, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 SCHEDULE statement
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
I'm running z/OS 2.2 @ RSU1805 level and one of my users is trying to use the
JES2 schedule statement; from all the doc I found the AFTER=jobname should be
valid @ 2.2 but they are getting a JCL error during testing, my test had the
same results;
3 // SCHEDULE HOLDUNTL=('09:50','02/05/2019'),AFTER=joba
4 //A EXEC PGM=IEFBR14
STMT NO. MESSAGE
3 IEFC630I UNIDENTIFIED KEYWORD AFTER
checking the KC looks like this should be valid, am I missing something?
thanks
Carmen
--
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,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 SCHEDULE statement
Are you sure you have the syntax correct? Here is a jobgroup I actively use
to run my z/os cloning jobs. I am at V2.3 however.
//TESTG JOBGROUP ERROR=(RC>4),ONERROR=FLUSH
//TESTA GJOB
//TESTB GJOB
// AFTER NAME=TESTA,WHEN=(RC=0)
//TESTC GJOB
// AFTER NAME=TESTB,WHEN=(RC<=4)
//TESTD GJOB
// AFTER NAME=TESTC,WHEN=(RC=0)
//TESTG ENDGROUP
//TESTA JOB '1 RST01A Init',
// CLASS=X,MSGCLASS=T
// SCHEDULE JOBGROUP=TESTG
.
.
.
.
_
Dave Jousma
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 On Behalf Of
Carmen Vitullo
Sent: Tuesday, February 5, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 SCHEDULE statement
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
I'm running z/OS 2.2 @ RSU1805 level and one of my users is trying to use the
JES2 schedule statement; from all the doc I found the AFTER=jobname should be
valid @ 2.2 but they are getting a JCL error during testing, my test had the
same results;
3 // SCHEDULE HOLDUNTL=('09:50','02/05/2019'),AFTER=joba
4 //A EXEC PGM=IEFBR14
STMT NO. MESSAGE
3 IEFC630I UNIDENTIFIED KEYWORD AFTER
checking the KC looks like this should be valid, am I missing something?
thanks
Carmen
--
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
COBOL 4.2, 5.1 and 5.2 EOS Dates
More than once on this forum, folks have asked about when Enterprise COBOL V4.2 will enter EOS. This announcement has the details: http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/2/897/ENUS919-022/index.html&lang=en&request_locale=en V5.1, V5.2 will be EOS May 30, 2020. V4.2 will be EOS September 30, 2021. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JES2 SCHEDULE statement
I'm running z/OS 2.2 @ RSU1805 level and one of my users is trying to use the
JES2 schedule statement; from all the doc I found the AFTER=jobname should be
valid @ 2.2 but they are getting a JCL error during testing, my test had the
same results;
3 // SCHEDULE HOLDUNTL=('09:50','02/05/2019'),AFTER=joba
4 //A EXEC PGM=IEFBR14
STMT NO. MESSAGE
3 IEFC630I UNIDENTIFIED KEYWORD AFTER
checking the KC looks like this should be valid, am I missing something?
thanks
Carmen
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM FIXCDS before start-up?
Why would you want to do this? I presume you have the health-check recommended 4 backups (or more). If the current backup is 'N', the next backup would be taken to N+1. N will not be overwritten for 3 additional cycles. More than long enough to make a backup copy. To answer your question about fixcds prior to startup, no. What I have done is add the FIXCDS command to the end of ARCCMD* This will be executed before a CDS backup can occur. You can also bring dfHSM up in emergency mode obtain the backup number and issue the FIXCDS command followed by SETSYS NOEMERGENCY. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Monday, February 4, 2019 5:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM FIXCDS before start-up? I am refining our DR procedures. After I restore the DFHSM CDSs from the most recent back-up, I need to update so as to not overwrite that back-up with the next occurrence of CDS backup. The fine manual says to use FIXCDS S MHCR PATCH(X'B1' nnn) to set the next back-up number. FIXCDS requires an active DFHSM. Is there a supported way to make this update BEFORE starting DFHSM on the recovered system? I have thought of running DFHSM itself with a specifically tailored parm to come up, FIXCDS, and stop, but this seems overkill. I can also do it "manually" during the steps documented for first IPL of recovered system, but this is more prone to error or omission. S DFHSM is in my COMMNDxx parmlib member. Dave Gibney Information Technology Services Washington State University -- 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: CryptoExpress zeroize domain
You can zeroize individual domains from the SE as well. Both are on the Crypto Configuration panel. I don't know of any way to do it from ICSF. Greg Boyd www.mainframeCrypto.com On Mon, 4 Feb 2019 17:42:18 +0100, R.S. wrote: >AFAIK there are ways to zeroize CryptoExpress engines using HMC/SE >facilities, but this is to zeroize whole card - all domains. > >Is there any method to zeroize CryptoExpress master keys from ICSF? >I would like to "clean up" the domain after myself. >I'm aware there's an option to simply enter new MK's and old keys will >be overwritten, but third party person will not be sure this is not prod >key, just some placeholder. > >Is there any ICSF command to clean up the domain? > >-- >Radoslaw Skorupka >Lodz, Poland > > > > >== > >Je�li nie jeste� adresatem tej wiadomo�ci: > >- powiadom nas o tym w mailu zwrotnym (dzi�kujemy!), >- usu� trwale t� wiadomo�� (i wszystkie kopie, kt�re wydrukowa�e� lub >zapisa�e� na dysku). >Wiadomo�� ta mo�e zawiera� chronione prawem informacje, kt�re mo�e wykorzysta� >tylko adresat.Przypominamy, �e ka�dy, kto rozpowszechnia (kopiuje, >rozprowadza) t� wiadomo�� lub podejmuje podobne dzia�ania, narusza prawo i >mo�e podlega� karze. > >mBank S.A. z siedzib� w Warszawie, ul. Senatorska 18, 00-950 >Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. S�d Rejonowy dla m. st. >Warszawy XII Wydzia� Gospodarczy Krajowego Rejestru S�dowego, KRS 025237, >NIP: 526-021-50-88. Kapita� zak�adowy (op�acony w ca�o�ci) wed�ug stanu na >01.01.2018 r. wynosi 169.248.488 z�otych. > >If you are not the addressee of this message: > >- let us know by replying to this e-mail (thank you!), >- delete this message permanently (including all the copies which you have >printed out or saved). >This message may contain legally protected information, which may be used >exclusively by the addressee.Please be reminded that anyone who disseminates >(copies, distributes) this message or takes any similar action, violates the >law and may be penalised. > >mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 >Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the >Capital City of Warsaw, 12th Commercial Division of the National Court >Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital >amounting to PLN 169,248,488 as at 1 January 2018. > >-- >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: A new LPAR entry in a existing IODF
W dniu 2019-02-05 o 10:48, Peter pisze: Thanks I would like to change the CHPID for a series of UCBs. Do I need to recable it or using the same port I can assign a different CHPID ? You can do the following: a) change cabling to CUs (not devices) - but why? b) change PCHID/CHPID numbering - there is one reason: to establish some naming convention. Is it you reason? c) change CHPID numbering in each LPAR. It is impossible for LPARs within same CSS, and reasonless. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A new LPAR entry in a existing IODF
Peter I am not sure what you are trying to achieve. The CEC has physical Channels called PCHPIDs which map to logical CHPIDs. You have some UCBS connected via a CHPID. Why would you want to change them? On Tue, 5 Feb 2019 at 11:49, Peter wrote: > Thanks > > I would like to change the CHPID for a series of UCBs. > > Do I need to recable it or using the same port I can assign a different > CHPID ? > > Regards > Peter > > On Wed, 30 Jan, 2019, 8:34 PM R.S. > > Simply run HCD and play. > > You cannot destroy prod data (it will be WORK IODF), so feel safe > > playing - yes, just playing with various options. > > Your task is really simple, unless you have very specific requirements > > (not presented here) or your IODF is very complex. > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > > > > > > > > > > W dniu 2019-01-30 o 16:05, Peter pisze: > > > Hi, > > > > > > If I have to add a new LPAR name and use the same UCB,I/O, PROCESSOR > > > whatever the others LPARs are using in the same IODF then what would be > > > step to achieve this ? > > > > > > Is there an document or manual which explains about it ? > > > > > > Regards > > > Peter > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > . > > > > > > > > > == > > > > Jeśli nie jesteś adresatem tej wiadomości: > > > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > > zapisałeś na dysku). > > Wiadomość ta może zawierać chronione prawem informacje, które może > > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > > narusza prawo i może podlegać karze. > > > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > > 01.01.2018 r. wynosi 169.248.488 złotych. > > > > If you are not the addressee of this message: > > > > - let us know by replying to this e-mail (thank you!), > > - delete this message permanently (including all the copies which you > have > > printed out or saved). > > This message may contain legally protected information, which may be used > > exclusively by the addressee.Please be reminded that anyone who > > disseminates (copies, distributes) this message or takes any similar > > action, violates the law and may be penalised. > > > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, > 00-950 > > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > > Capital City of Warsaw, 12th Commercial Division of the National Court > > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > > amounting to PLN 169,248,488 as at 1 January 2018. > > > > -- > > 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 > -- Mike Shorkend m...@shorkend.com www.shorkend.com Tel: +972524208743 Fax: +97239772196 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] ARC1139I RC39 RSB08
Hi, We use hold commands in the ARCCMD parm member to prevent an lpar from recalling, but it's allowed to put requests on the common queue (this was because we used to be short on tape drives). E.G. ONLYIF HSMHOST(2) HOLD RECALL(TAPE) ONLYIF HSMHOST(2) HOLD COMMONQUEUE(RECALL(SELECTION)) thanks, Simon. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Munif Sadek Sent: 30 January 2019 03:48 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] ARC1139I RC39 RSB08 WARNING: this email has originated from outside of the SSE Group. Please treat any links or attachments with caution. ** Dear listers we are SNSPLex and common recall queue between our Production and test LPAR ARC1500I PLEXNAME=ARCPLEX0,PROMOTE PRIMARYHOST=NO,PROMOTE SSM=NO,COMMON RECALL ARC1500I (CONT.) QUEUE BASE NAME=HSMPLEX,COMMON RECALL QUEUE Problem is a valid user with valid access recalling a dataset in Production but recall request is getting processed on Test LPAR where userid dose not exist. Dataset profile does exist as we share all the DASDs and other infrastructure. In Production SYSTEM ARC1001I XXX.YY.ZZ RECALL FAILED, RC=0039, REAS=0008 ARC1139I ERROR PROCESSING RACF PROTECTED DATA SET, RECOVERY/RECALL/DELETE ARC1139I (CONT.) TERMINATED In Test SYSTEM we get ICH408I USER(USERID ) GROUP(@@ACTIVE) NAME(USER NAME) LOGON/JOB INITIATION REVOKED USER ACCESS ATTEMPT Is there a PATCH / SURROGATE / HSM SAF facility that can fix this *generic* error. regards Munif -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** SSE and associated brands: Southern Electric, Scottish Hydro, SWALEC and Atlantic are all trading names of SSE Electricity Limited registered in England and Wales number 04094263 (supply of electricity and Feed-In Tariffs); Southern Electric Gas Limited registered in England and Wales number 02716495 (supply of gas); SSE Retail Telecoms Limited registered in England and Wales number 10086511 (supply of home phone and broadband); SSE Home Services Limited registered in Scotland number SC292102 (boiler and heating repair, servicing, cover, boiler Installations and electrical wiring cover); SSE Energy Solutions Limited registered in Scotland number SC386054 (energy efficiency installations and insulation products). All members of the SSE Group. The registered office of SSE Electricity Limited, Southern Electric Gas Limited and SSE Retail Telecoms Limited is No. 1 Forbury Place, 43 Forbury Road, Reading, RG1 3JH. The registered office of SSE Home Services Limited and SSE Energy Solutions Limited is Inveralmond House, 200 Dunkeld Road, Perth, PH1 3AQ. SSE Electricity Limited is an appointed representative of SSE Home Services Limited. SSE Home Services Limited is authorised and regulated by the Financial Conduct Authority (FCA) under reference number 695476. You can check this on the Financial Services Register by visiting the FCA website. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM FIXCDS before start-up?
> -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of retired mainframer > Sent: Monday, February 04, 2019 8:26 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM FIXCDS before start-up? > > Why would overwriting the CDSs during a CDS backup be a problem? You still > have the media they were restored from and can recreate that version at > will. The CDS backup overwrite fails because the DISP is NEW, but cataloged entries exist. And, It may be that these ideas below are answers. Just asking if I'm missing something > > If you don't want to run a special ARCCMDxx and you don't want to issue the > FIXCDS command manually, what other approach did you have in mind? > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Gibney, Dave > > Sent: Monday, February 04, 2019 3:19 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: DFHSM FIXCDS before start-up? > > > > I am refining our DR procedures. After I restore the DFHSM CDSs from > > the > most > > recent back-up, I need to update so as to not overwrite that back-up > > with > the next > > occurrence of CDS backup. The fine manual says to use FIXCDS S MHCR > > PATCH(X'B1' nnn) to set the next back-up number. > > FIXCDS requires an active DFHSM. Is there a supported way to make this > update > > BEFORE starting DFHSM on the recovered system? > > > > I have thought of running DFHSM itself with a specifically tailored > > parm > to come up, > > FIXCDS, and stop, but this seems overkill. I can also do it "manually" > during the steps > > documented for first IPL of recovered system, but this is more prone > > to > error or > > omission. S DFHSM is in my COMMNDxx parmlib member. > > > > Dave Gibney > > Information Technology Services > > Washington State University > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A new LPAR entry in a existing IODF
Thanks I would like to change the CHPID for a series of UCBs. Do I need to recable it or using the same port I can assign a different CHPID ? Regards Peter On Wed, 30 Jan, 2019, 8:34 PM R.S. Simply run HCD and play. > You cannot destroy prod data (it will be WORK IODF), so feel safe > playing - yes, just playing with various options. > Your task is really simple, unless you have very specific requirements > (not presented here) or your IODF is very complex. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2019-01-30 o 16:05, Peter pisze: > > Hi, > > > > If I have to add a new LPAR name and use the same UCB,I/O, PROCESSOR > > whatever the others LPARs are using in the same IODF then what would be > > step to achieve this ? > > > > Is there an document or manual which explains about it ? > > > > Regards > > Peter > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > . > > > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2018 r. wynosi 169.248.488 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169,248,488 as at 1 January 2018. > > -- > 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: How can I get reports in the Output Queue in SDSF to print
Ron, Forgive me, but it sounds like you are a little out of your depth with this. Z13 doesn't allow a CTC? Since when? AFAIK, you can have a FICON CTC on ANY z hardware. "TCPNJE has been working for nearly 3 years and then all of a sudden it isn't and networking says it's a mainframe problem" - er, NO. If nothing changed on the mainframe, then HOW can it be a mainframe issue? MUCH more likely that something in the network has changed. What, exactly, are you trying to achieve? Your original post didn't mention anything about z/VM - you said you wanted output to print.. It sounds like you are trying to send output from a z/OS lpar to a z/VM lpar (I assume on the same hardware) over a network. Can you clarify? I think you may need more in-depth help than the list can supply... You may want to cross post on the z/VM list. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
