Yes, the TF terminates at the first blank space found at the TF's
starting COL position.
On 14/07/2020 03:31, Paul Gilmartin wrote:
> On Mon, 13 Jul 2020 20:10:15 -0500, Lionel B Dyck wrote:
>
>> Tried the suggestion and it flowed all the lines together - true it did
>> ignore 72+
>>
>> It appea
Thanks for the overview. (I should write this out on the palm of my hand; too
much hand washing these days, though.) As you or someone else pointed out, for
z/OS Global, an 'XRC license' is required only at the source/prod site because,
at the DR site, data is written to the mirror volumes via s
A final caution. You will need to do DASD housekeeping on the DR system. In
order to do that remotely, you will need to put DR volumes online to prod. That
will require unique device addresses. Just saying.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
S
I sustain all of the worries except problems with ftp and RECFM=U.
It is still better to avoid unnecessary ftp step. Shared DASD solve it.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 14.07.2020 o 16:47, Joe Monk pisze:
I would agree with you if this weren't an LPAR to LPAR copy. So, there's a
I would agree with you if this weren't an LPAR to LPAR copy. So, there's a
direct connection between the LPARs, and most of the worries that you are
concerned about dont really exist in that situation.
Joe
On Tue, Jul 14, 2020 at 9:39 AM R.S. wrote:
> Because of reasons. ;-)
> Seriously: it is
RECFM=U works fine with FTP. MODE B and TYPE E are your best friends for
FTPing between mainframes.
That said, I would never FTP hundreds of GB between LPARs with shared DASD.
Just dump/restore and done. As far as I know, FTP doesn't work with VSAM (PS-E
is fine though), so you'll have to du
Because of reasons. ;-)
Seriously: it is better to make it simpler and faster.
Your method: dump, ftp, restore.
Other methods: a) dump, restore. b) copy.
Which is faster?
Which consume less CPU?
Which require less disk space for intermediate copies?
Not to mention issues with RECFM=U and ftp.
-
That is exactly what I do from individual datasets to full volume dump/restore.
In the case of the latter, its tape to tape FTP to get it to the remote site,
then a restore.
_
Dave Jousma
AVP |
Why not just dump them, FTP the dump file between the two partitions, then
restore the dump file?
Joe
On Tue, Jul 14, 2020 at 8:11 AM R.S. wrote:
> Well, that change the perspective. It's a pity you didn't mention it
> before ;-)
> In this case one step is better (faster) than two-step approach
Well, that change the perspective. It's a pity you didn't mention it
before ;-)
In this case one step is better (faster) than two-step approach.
However in this case you should share catalog (BCS). Then you can try to
share storage group.
Or do it from target system - you still need to share vol
Thanks
I guess I'll have to bite the bullet. It's 393GB of files.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of R.S.
Sent: Tuesday, July 14, 2020 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Copying Extended format datasets between partitions
You cannot do it.
Hi Peter,
Try looking at the SMF 30, type 1, records, which you can process with RACF's
SMF unload and which zSecure should also be able to report on.
There might be other events shown in SYSLOG immediately before and after the
ICH408I message that give some clue as to its origins.
If JESINPUT
NFS?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Gadi Ben-Avi [gad...@malam.com]
Sent: Tuesday, July 14, 2020 6:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Copying E
You cannot do it.
Both datasets require to be DFSMS-managed and then cataloged.
So you have to share the catalog (BCS), otherwise you will get error or
uncataloged datasets on SMS volume, which is also not the best idea.
Another method: dump you datasets to PS file on shared volume. Then
restore
I hate new names of PPRC and XRC (and PPRC-XD), but... But one should
know there are new features. New features with new names, but no old
name exist for them.
There are still PPRC, XRC, PPRC-XD, but there is also some kind of "XRC
without z/OS", performed by dasd arrays without host involveme
W dniu 14.07.2020 o 00:27, TenEyck, Peter pisze:
What SMF record and report/tool could I use to determine the point of origin
for this attempted logon?
M 008 ABCD 20180 07:40:36.85 JOB03275 0090 ICH408I USER(RACFID )
GROUP() NAME(??? ) 395
E
HI,
I have to copy extended format (PS-E and VS-E) datasets between partitions.
The partitions share DASD but do not share anything else.
They have different SMS configurations.
The same Storage Group is defined in both partitions, but each partition has
different volumes.
I've been copying datas
17 matches
Mail list logo
