On Thu, 26 Apr 2018 12:51:40 -0500, John McKown wrote:
>
>So, in any mixed platform environment, the beginners are at a disadvantage.
>That is one reason given for the "Windows only" mantra chanted here. There
>is no need for people to be as intelligent or knowledgeable.
>
Ah! A principle of unif
On Thu, Apr 26, 2018 at 11:50 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Thu, 26 Apr 2018 07:33:39 +0200, Peter Hunkeler wrote:
> >
> >>IMHO it is problem with IBM. Are you deaf?
> >Sometimes it is; sometimes they are. However, not this time.
> >
> >>People r
On Thu, Apr 26, 2018 at 11:45 AM, R.S.
wrote:
> "know your job" should not be an excuse for inconvenience.
> Why realtively simple and frequently performed activities do require
> sophisticated knowledge?
> Why new user generations still have to thoroughly study ftp advanced
> parameters to final
On Thu, 26 Apr 2018 07:33:39 +0200, Peter Hunkeler wrote:
>
>>IMHO it is problem with IBM. Are you deaf?
>Sometimes it is; sometimes they are. However, not this time.
>
>>People really NEED the functionality to simply make single dataset archive,
>>transmit it to PC *with no tricks and black magi
"know your job" should not be an excuse for inconvenience.
Why realtively simple and frequently performed activities do require
sophisticated knowledge?
Why new user generations still have to thoroughly study ftp advanced
parameters to finally find out there is no solution for
downloading/uploa
>IMHO it is problem with IBM. Are you deaf?
Sometimes it is; sometimes they are. However, not this time.
>People really NEED the functionality to simply make single dataset
archive, transmit it to PC *with no tricks and black magic* and then
upload it to a z/OS and unpack.
Know your job. Wha
IMHO it is problem with IBM. Are you deaf? The problem is know for
years, decades.
People really NEED the functionality to simply make single dataset
archive, transmit it to PC *with no tricks and black magic* and then
upload it to a z/OS and unpack.
What would be wrong with "DUMP DS() OUDATAS
Jerry,
Yes, IND$FILE is OK to transfer to/from a PC.
I have a program to dump VSAM and OSAM/QSAM datasets in IPCS-readable
LRECL=BLKSIZE=4160 format. Let me know if you want a copy.
Cheers, CP
On 24/04/2018 12:00, Jerry Paper wrote:
> Dear colleagues,
>
> thank you for sharing your opinio
On Tue, 24 Apr 2018 00:24:00 -0500, Brian Westerman wrote:
>That sequence won't work, when you upload it the the PC the blocks will be
>messed up. DFDSS (and FDR) both use special blocking that gets broken if you
>don't handle it correctly.
>
>If you need to go to the PC, then you should ters
Dear colleagues,
thank you for sharing your opinions and experiences. I'm aware that tersing
first or using an alternative block-preservation method is the right approach
(as we are doing it for years), but it wasn't the case in this scenario.
The data only exists as a file on PC at the moment
-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] DFSMSdss dump fix after binary transfer
That sequence won't work, when you upload it the the PC the blocks will be
messed up. DFDSS (and FDR) both use special blocking that gets broken if you
don't handle it correctly.
If you need to go
That sequence won't work, when you upload it the the PC the blocks will be
messed up. DFDSS (and FDR) both use special blocking that gets broken if you
don't handle it correctly.
If you need to go to the PC, then you should terse it or use AWStape as
previously offered. If you can go direct
ADRDSSU backup to dasd then FTP the backup to PC and restore to Hercules.
On Mon, Apr 23, 2018 at 3:05 PM, John McKown
wrote:
> On Mon, Apr 23, 2018 at 2:45 PM, Brian Westerman <
> brian_wester...@syzygyinc.com> wrote:
>
>> z/pdt and Hercules both run z/OS on PC's. That's the platform combinatio
On Mon, Apr 23, 2018 at 2:45 PM, Brian Westerman <
brian_wester...@syzygyinc.com> wrote:
> z/pdt and Hercules both run z/OS on PC's. That's the platform combination
> I meant. Getting your volumes to your PC based z/OS is what I thought the
> purpose was for this op.
>
I would think, in that c
z/pdt and Hercules both run z/OS on PC's. That's the platform combination I
meant. Getting your volumes to your PC based z/OS is what I thought the
purpose was for this op.
Since the op wanted to transmit their Volume to their PC, my assumption was
that they "probably" wanted to use it there
80 byte records respectively.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Peter Hunkeler
Sent: Monday, April 23, 2018 10:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: DFSMSdss dump fix after binary transfer
[External Email]
>A colleague has made a logical data set
>A colleague has made a logical data set DUMP of important data and downloaded
>to his PC in binary (by mistake, without additional steps). As expected, after
>uploading from PC to z/OS, the format is broken, and ADRDSSU doesn't recognize
>the DUMP (uploaded as blksize=27998, lrecl=0, recfm=u).
I always take a peek at the DCB attributes of the tersed file and
preallocate the same on the receiving system. FTP is then simply binary and
get/put into the newly allocated file.
On Sun, Apr 22, 2018 at 11:52 PM, CM Poncelet wrote:
> 'm afraid I can't help much with this. I FTP'd from mainfram
'm afraid I can't help much with this. I FTP'd from mainframe to
mainframe server, but not to/from my PC (I used TN3270 Plus or QWS3270
for that).
However, from vague memory, tersed files used to have to be RECFM=FB
BLKSIZE=6144 LRECL=1024 and the PGM=FTP step's SYSIN required a LOCSITE
and BINA
On Sat, 21 Apr 2018 23:07:34 -0500, Brian Westerman wrote:
>No, it has to be z/OS to z/OS
>
I suppose I was misled when you wrote "to z/OS on your PC" twice.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructi
No, it has to be z/OS to z/OS
Brian
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
On Sat, 21 Apr 2018 19:13:30 -0500, Brian Westerman wrote:
>You can skip the terse step as long as you use the following on your FTP and
>transfer it directly from z/OS on the mainframe to z/OS on your PC:
>
>TYPE E
>MODE C
>
If you're afflicted with a PC that runs z/OS. Hercules? FLEX-ES?
You can skip the terse step as long as you use the following on your FTP and
transfer it directly from z/OS on the mainframe to z/OS on your PC:
TYPE E
MODE C
MODE C denotes that you are sending a compressed format dataset
TYPE E tells FTP that you are transferring an EBCDIC file.
That's a
On Sat, 21 Apr 2018 14:43:55 -0400, Tom Conley wrote:
>
>... And don't hit me with FTP EBCDIC BLOCK, that only
>works 99% of the time. I've hit the 1% where it doesn't, and I don't
>need that headache again. TERSE works 100% of the time.
>
Most non-IBM platforms don't support BLOCK; they suppor
On 4/21/2018 11:13 AM, Gord Tomlin wrote:
On 2018-04-21 05:27, Wayne Bickerdike wrote:
I always terse the dump first, seems problematic if you don't.
ADRDDSU DUMP, TERSE, FTP in Binary.
Reverse the process on the next MVS platform.
That's exactly what we've been doing for years, and it works
On 2018-04-21 05:27, Wayne Bickerdike wrote:
I always terse the dump first, seems problematic if you don't.
ADRDDSU DUMP, TERSE, FTP in Binary.
Reverse the process on the next MVS platform.
That's exactly what we've been doing for years, and it works fine.
--
Regards, Gord Tomlin
Action Sof
I always terse the dump first, seems problematic if you don't.
ADRDDSU DUMP, TERSE, FTP in Binary.
Reverse the process on the next MVS platform.
On Sat, Apr 21, 2018 at 4:03 PM, CM Poncelet wrote:
> (a) Is the original ADDRSSU dump dataset still on the mainframe? If yes
> transfer it to a *.da
(a) Is the original ADDRSSU dump dataset still on the mainframe? If yes
transfer it to a *.dat (or *.bin) file on the PC, using e.g. TN3270
Plus, and as binary (no EBCDIC to ASCII). You should then be able to
upload that from the PC to a preallocated mainframe dataset (specifying
BLKSIZE=27998).
(b
If still on the PC, transfer in binary again. (high odds of success).
If only on the mainframe, and it was transferred with translation
(ASCII->EBCDIC), then download to PC with translation (EBCDIC->ASCII),
then back to the mainframe in Binary. (suspect you may have some drop
out errors).
On Fri
M Mainframe Discussion List On
> Behalf Of Jerry Paper
> Sent: Friday, April 20, 2018 7:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFSMSdss dump fix after binary transfer
>
> Hello all,
>
> this one is for the old-timers on the list (I guess :).
> A colleague has made a l
Hello all,
this one is for the old-timers on the list (I guess :).
A colleague has made a logical data set DUMP of important data and downloaded
to his PC in binary (by mistake, without additional steps). As expected, after
uploading from PC to z/OS, the format is broken, and ADRDSSU doesn't rec
31 matches
Mail list logo
