It might not be possible in a real (total) disaster to reverse the replication.
However, the DR procedures can also be used in different situations.
The simplest is a partial disaster or other problem, like a problem in the CPU
room, without problems in the DISK room.
Or we executed the
Hi
I am trying to reapply a FMID to the target zone of DB2 but it is failing
to apply even though I have specified REDO with FMID and it's Associated
PTF.
I have checked the global zone that this FMID is already in
RECEIVED,APPLIED, ACCEPT status.
What will be the best approach to reapply the
I wonder: can I deallocate a dataset with DYNALLOC, that has been allocated
by the initiator because there is a DD statement?
Kees.
Table 1. Verb code 02 (dynamic unallocation) – Text unit keys, mnemonics,
and functions
Hex text unit key MnemonicDYNALLOC function
.
0007
https://en.wikipedia.org/wiki/Antikythera_mechanism
In a message dated 2/14/2019 4:41:47 PM Central Standard Time,
mike.a.sch...@gmail.com writes:
Starts with the Jacquard loom using punched cards,
--
For IBM-MAIN subscribe /
Starts with the Jacquard loom using punched cards,
Babich's unfinished difference engine, and
Holreith's punched cards for the 1890 census.
https://www.youtube.com/watch?v=R7-a7kzlk9g
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
On Thu, 14 Feb 2019 14:28:35 -0600, Tom Marchant wrote:
>On Thu, 14 Feb 2019 13:54:58 -0600, Paul Gilmartin wrote:
>
>>>// SET PARM2=
>>
>>Doesn't this run afoul of a rule elsewhere in the Ref. that symbols
>>are not to be defined in terms of other symbols.
>
>What rule is that? Where is it
NP Jerry.
I *suspect* what Tom suggested would work and would be simpler than what I
did.
// SET PARM1=
Rather than
// SET $PARM1=
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jerry Whitteridge
Sent: Thursday, February
On Thu, 14 Feb 2019 13:07:07 -0800, Charles Mills wrote:
>I think I could have done
>
>//jobname JOB ...
>// EXPORT SYMLIST=*
>//procname PROC ...
Maybe. I had a similar problem a few years ago, but in my case, I had a PROC
that was used in some jobs. I don't remember if I tried using the
Well, now that I have STC LONGPARM working, how long can the START command
be?
The commands reference describes two formats. It says most commands can use
format one, and it may be up to 126 characters. And it says three specific
commands must use format two, and does not indicate a maximum
I'm keeping this as my set of examples - Thanks Charles
Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871 Mobile
jerry.whitteri...@ibm.com
IBM Services
IBM Mainframe Discussion List wrote on
02/14/2019 02:07:07 PM:
> From: Charles Mills
> To:
+1
And easy for me to say but wouldn't it be trivial to fix? Just pull out the
code that checks for unused symbols? No compatibility issues -- no one is
conceivably COUNTING ON a JCL error in that situation.
Wasn't assembler the model for JCL? Assembler allows unreferenced fields.
(Although
@Tom's got it. Thanks.
EXPORT works in a PROC and so forth but must come before the definition of the
symbols it exports. (Again, seems kind of backwards, but what do I know?)
I think I could have done
//jobname JOB ...
// EXPORT SYMLIST=*
//procname PROC ...
But I have never coded a started
I might be posting twice here but I've been reading the list via Google
Groups and posting there not realizing that the posts don't necessary hit
the mailing list. So I've done the proper thing and subscribed to the list.
Sorry for any confusion.
Anyway when I started DR planning and Sysplex I
On Thu, 14 Feb 2019 13:54:58 -0600, Paul Gilmartin wrote:
>>// SET PARM2=
>
>Doesn't this run afoul of a rule elsewhere in the Ref. that symbols
>are not to be defined in terms of other symbols.
What rule is that? Where is it documented?
--
Tom Marchant
Tom - Global Mirror only requires the extra set of DASD at the receiving
site (or at least that is how we are setup). However you'd then need the
ability to reverse the replication so could need extra at the primary site
(our plan states if we declare we are in the DR site for an extended period
-
I get "entry not defined". Unfortunately that doesn't help, because on my
playground I have duplex tapes with their primary ML2 tape still existent, and
I get the same "not defined" message.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Allan Staller
Sent:
On Thu, 14 Feb 2019 10:57:06 -0800, Charles Mills wrote:
> ...
>Would it kill IBM to have some meaningful examples in the JCL reference?
>
The JCL Ref. contains a section:
Using symbols in started task JCL
Example: using JCL symbols
Prepare to be disappointed. I see no meaningful
Or I'm wondering if Global Mirror directly from DS8886 to DS8886 might
be worth looking into, simplifying that process by eliminating XRC.
That takes an extra copy of each DASD volume at each site though.
On 2/14/2019 10:12 AM, Stuart zseries wrote:
What was missing when I left:
The ability
On Thu, 14 Feb 2019 10:02:26 -0800, Charles Mills wrote:
> ...
>I have a started PROC with the typical sort of symbols declared on the PROC
>statement.
>...
>The second step contains //stepname EXEC PGM=program,PARMDD=MYDDNAME
>
>//MYDDNAME DD *,SYMBOLS=JCLONLY
>
>I have a // EXPORT SYMLIST=*. I
On Thu, 14 Feb 2019 11:01:44 -0800, Charles Mills wrote:
>> // EXPORT gets specified first before any // SET stmts
>
>How do I do that in a PROC where the SETs are implicit in the PROC
>statement, which is the very first statement?
>
>//procname PROC PARM1=value,PARM2=value
Try this:
The EXPORT needs to precede the PROC statement, but I am not sure if that is
legal for a STARTed PROC. In my experience at z/OS level 2.2, for regular
batch JCL you must put the EXPORT prior to any SET's **and** prior to any PROC
*execution* in order to catch the PROC default values.
And I
Job cards can be specified in members for libraries defined in MSTJCL00 -
//IEFJOBS concatenation - job cards can be specified - also in any proclib
member in //IEFPDSI concatenation.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Thursday,
> // EXPORT gets specified first before any // SET stmts
How do I do that in a PROC where the SETs are implicit in the PROC
statement, which is the very first statement?
//procname PROC PARM1=value,PARM2=value
Charles
-Original Message-
From: IBM Mainframe Discussion List
Hadn't seen SYMLIST=* learn something new every day...
// EXPORT gets specified first before any // SET stmts
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Thursday, February 14, 2019 10:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re:
I tried EXPORT SYMLIST=(PARM1,PARM2)
No difference.
Would it kill IBM to have some meaningful examples in the JCL reference?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Rich Tabor
Sent: Thursday, February 14, 2019 10:24
OK, I am making some progress. I got past the JCL error by coding a bunch of
dummy // SET FOO= statements.
I am not getting errors from the program. I can see that no symbol
substitution has been done.
Is there any restriction on DD *,SYMBOLS in a started PROC?
Where should the EXPORT statement
I really and truly have // EXPORT SYMLIST=*
I've used that before in batch jobs and you know how we lazy programmers are
-- I just copied it over.
Why?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Rich Tabor
Sent:
I tried spreading the first three parms across three lines -- no difference.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, February 14, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re:
Try doing each one on one line
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Charles Mills
> Sent: Thursday, February 14, 2019 11:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PARMDD and Symbols in a Started PROC
>
> Combo of the two, Lizette.
Do you really have // EXPORT SYMLIST=* or something like // EXPORT
SYMLIST=(PARM1,PARM2)
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Thursday, February 14, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] PARMDD and
Combo of the two, Lizette.
There are nine parms spread across three lines.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Thursday, February 14, 2019 10:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re:
Try HSEND DELVOL(XX) PURGE FORCE(?)
I haven't looked up the syntax.
Actually, if they are not in the TTOC you can probably just expire them.
Not sure if you are using RMM, TMS, or other, but RMM had a quirk, whereby if
the tape ever had a permanent error (as defined by having a SWAP
Actually, Skip, we were almost at the point to be able to do this when
we moved to the new data center. And, the procedure is very similar to
the way the move was done. With the new data center, both the primary
and secondary site had double disk, so that we could mirror in either
direction
How do you have your parms set in the PARMDD input?
I was told each parm needs to be on a separate line. Not sure how accurate that
is.
Have you tried individual lines?
Which way is your input coded?
//MYDDNAME DD *,SYMBOLS=JCLONLY
PARM1,PARM2,PARM3,etc
Or
//MYDDNAME DD
I know I am late to the party but I am just dipping my toe into the LONGPARM
pool.
I have a started PROC with the typical sort of symbols declared on the PROC
statement.
The PROC is two jobsteps, FWIW.
The second step contains //stepname EXEC PGM=program,PARMDD=MYDDNAME
And
Allan,
Sorry, this doesn't help. The LIST TTOC is only showing my VTS-based ML2 tapes
which have no duplex. BTW, LIST TTOC does show duplex volumes if they exist.
:-)
These duplex tapes all have old create dates and so I am confident they are
orphans. Now, how to get rid of them. I'll
Vince,
We were able to get this issue resolved. IBM support had me issue a QUERY LINK
on my z/VM side and noticed that the LINK was in a hold status. They then had
me issue a FREE LINK command and after starting the transmitters on the z/OS
side everything started working. Not sure how the
On Thu, 14 Feb 2019 07:27:36 +, Vernooij, Kees (ITOP NM) - KLM wrote:
>Just reverse the replication when starting up the DR site.
That isn't necessarily a real DR test. In a real disaster, you may not be able
to
replicate the data back to the primary site for a considerable period of time.
We run our parallel Sysplex at 2 locations between 15 and 20 km apart.
If you are interested in Parallel Sysplex performance, your next question
might/should be: do you run (with CFs in both sites) System Managed CF
Structure Duplexing? We are using SMCFSD.
Kees.
> -Original Message-
Well, if you don't mind taking out an initiator, ...
What's documented is that DYNALLOC is for allocating and freeing datasets in
your jobstep. The Initiator for your job is not in your jobstep.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
It used to be documented; I don't know if it still is.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, February 12,
Thanks you for Interesting discussion..
Just wanted to know if any organization running Parallel sysplex between two or
More CPCs located 12 KM (>7 miles) apart. I find running DEV+TEST and
PRODUCTION at different locations and cater for Service Continuity by swapping
over to other site
Most likely a continuation of a prior volume. Without going into a lot of
detail, if a dataset spans from 1 volume to another the 1st volume in the
sequence "owns it".
Duplex volumes are never referenced by DFHSM directly.
HSEND LIST TTOC will list all primary voulmes. I expect the duplex
For messaging, review of Message Flood Automation rules would seem to be in
order:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieae200/msgfld.htm
On Wed, Feb 13, 2019 at 9:44 PM Peter wrote:
> Hi
>
> One of our DS box in DR had a power failure last night and our
Peter,
My experience is over a decade old with XRC, but I imagine the potential for
some form of read/write/IO pacing is the same and that it could impact
performance. Open a PMR and ask IBM.
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On the sending DASD there is a 1 bit per track table of updated
tracks. When each track is sent the bit is reset. When it gets
caught up it sets a sync point.
On Wed, Feb 13, 2019 at 9:44 PM Peter wrote:
>
> Hi
>
> One of our DS box in DR had a power failure last night and our production
>
46 matches
Mail list logo
