Hello everyone,
Many thanks to all your contributions to solve the problem of PDS, s,
Sequential Files that were downloaded from a Z / OS in 2007. At present I have
no possibility of being able to download them again using the correct way
(AMATERSE and FTP binary ).
I have carried out many
Fortunately to reconstruct the BDWs, it is not necessary to look at the ckd
stuff.
The only info necessary can be found in the copyr1, the container length. (At least if the corrupted
data end properly. )
On 26/04/2021 08:29, Michael Stein wrote:
On Sat, Apr 24, 2021 at 08:05:26PM +0200,
On Sat, Apr 24, 2021 at 08:05:26PM +0200, Peter Sylvester wrote:
> then beginning with the directory blocks, you always have a 12 byte
> header which contains the length of the followong data. there are
> zero length records to terminate.
Have you done EXCP or built channel programs for DASD?
I
I had 3 tries: the ibm doc + iEYIBAL , well, got it almost right
I spend too much time correcting th 12 byte logic etc., got lost.
this morning, I just read the hercules dasdload.c for the VS format, and bingo. needed some oisters
fand foie gras for breakfast. :-)
the first two records have
On Sat, 24 Apr 2021 18:14:20 +0200, Peter Sylvester wrote:
>
>finally I hacked a little python (need to learn rexx) to reconstruct the
>bdws/rdws of an ind$file
>corrupted iebcopy unloaded pds.
>
>this (is |was known to be) possible since the content is self describing.
>
I'm curious. How did
Hi,
finally I hacked a little python (need to learn rexx) to reconstruct the bdws/rdws of an ind$file
corrupted iebcopy unloaded pds.
this (is |was known to be) possible since the content is self describing.
best
Peter
on an CD
On Tue, 20 Apr 2021 18:14:30 +, Seymour J Metz wrote:
>The sample I saw ...
>
Aw, gee. Please include enough headers that readers can refer
to it without a tedious search. E.g. (I'm guessing):
Date: Mon, 19 Apr 2021 07:41:14 +0200
SUBJECT: Re: Format PDS unloaded on an CD
Mess
The BDW/RDW are there...
0094A0 FFF8 7FE4 7FE0
The 7FE4/7FE0 are the BDW/RDW.
Joe
On Tue, Apr 20, 2021 at 3:47 PM Michael Stein wrote:
> On Tue, Apr 20, 2021 at 08:38:25PM +, Seymour J Metz wrote:
> > IEBCOPY will work if no records are missing. I don't know
On Tue, Apr 20, 2021 at 08:38:25PM +, Seymour J Metz wrote:
> IEBCOPY will work if no records are missing. I don't know whether that
> it sthe case.
At a minimum the BDW/RDWs are missing. Possibly they were transfered
in binary but with the BDW/RDWs removed. Or there might be more
mangling.
-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, April 20, 2021 9:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Format PDS unloaded on an CD
On Tue, 20 Apr 2021 13:20:49 +, Seymour J Metz wrote:
>It looked like there were intact BDWs and RDWs. Does anybody have a link for
>the IEBCOPY
guessing):
Sorry about that. The original message had "vertical" hex which I find
about impossible to read so I reformated it.
> Date: Mon, 19 Apr 2021 07:41:14 +0200
> SUBJECT: Re: Format PDS unloaded on an CD
> Message-ID:
>
> FROM: Hilario Garcia
>
> > ...included
On Tue, 20 Apr 2021 18:14:30 +, Seymour J Metz wrote:
>The sample I saw ...
>
Aw, gee. Please include enough headers that readers can refer
to it without a tedious search. E.g. (I'm guessing):
Date: Mon, 19 Apr 2021 07:41:14 +0200
SUBJECT: Re: Format PDS unloaded on an CD
Message-ID:
On Tue, Apr 20, 2021 at 06:14:30PM +, Seymour J Metz wrote:
> The sample I saw included what looked like valid BDWs and RDWs. If it
> is not missing records then it should work with a DCB override.
I didn't see that -- I think they may be missing. It starts:
: 00ca 6d0f 0200 18b0
] on behalf of
Peter Sylvester [peter.sylves...@gmail.com]
Sent: Tuesday, April 20, 2021 10:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Format PDS unloaded on an CD
Joe Monk seems right with the déjà vu:
If you have an iebcopy unload file transferred (as binary), the outmost layer
On Tue, 20 Apr 2021 16:58:32 +0200, Peter Sylvester wrote:
>Joe Monk seems right with the déjà vu:
>
>If you have an iebcopy unload file transferred (as binary), the outmost layer
>of the rdws an bdws
>are simply gone.
>
I have been able to preserve them by overriding with //SYSUT1 DD
Joe Monk seems right with the déjà vu:
If you have an iebcopy unload file transferred (as binary), the outmost layer of the rdws an bdws
are simply gone.
On the PC, the data are simply concatenated. not was to retrieve the blocks/records usin ind$file.
Ok, so be it.
This is not a
On Tue, 20 Apr 2021 13:20:49 +, Seymour J Metz wrote:
>It looked like there were intact BDWs and RDWs. Does anybody have a link for
>the IEBCOPY unload format?
>
Why bother? Just reconstruct the block structure and reload it with IEBCOPY.
>If there was translation then all bets are off.
Subject: Re: Format PDS unloaded on an CD
On Tue, Apr 20, 2021 at 04:59:19AM -0700, Hilario Garcia wrote:
> Hi Mike, Thank you very much for the information that you have sent me to
> be able to recover files (mostly PDS) but there are also data files and PDS
> LOADLIB. I'm going to ge
Well, the LOADLIB members are going to be U 32760 (or less) for a
library. Not sure if the PDS reload via IEBUPDTE will work.
Data files should reload with records broken every LRECL, unless they
have Varible length fields with a 2 byte binary count ahead of the
data. They are greatly helped by
On Tue, Apr 20, 2021 at 04:59:19AM -0700, Hilario Garcia wrote:
> Hi Mike, Thank you very much for the information that you have sent me to
> be able to recover files (mostly PDS) but there are also data files and PDS
> LOADLIB. I'm going to get to work on it as you have indicated. The work is
>
554 / 5000
Resultados de traducción
Hi Mike, Thank you very much for the information that you have sent me to
be able to recover files (mostly PDS) but there are also data files and PDS
LOADLIB. I'm going to get to work on it as you have indicated. The work is
very laborious and there are about 30
On Mon, Apr 19, 2021 at 7:23 AM Joe Monk wrote:
>
> So, now you know what you have. An ISPF panel library, that was
> unloaded via IEBCOPY, then IND$FILE to a PC without specifying CRLF then
> back to the mainframe.
>
> Joe
>
Well, since this is going to be a text only, FB 80 PDS(e) file,
El lun, 19 abr 2021 a las 7:40, Hilario Garcia ()
escribi=C3=B3:
> I have done multiple tests with different utilities (XMIT, FTP, IND $
> FILE, AMATERSE) and I have not been able to download them in a valid
> format.
Not surprising as it's been mangled -- the begining is chopped off plus
On Mon, 19 Apr 2021 11:06:52 -0500, Joe Monk wrote:
>
>So, you have a format problem. The format is IEBCOPY unload to a
>sequential file on DASD. BUT that was then run thru IND$FILE TWICE, without
>specifying the CRLF option to insert CRLFs on the PC to denote record ends.
>So, you have a PC
Discussion List On Behalf Of Joe
Monk
Sent: Monday, April 19, 2021 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Format PDS unloaded on an CD
The problem is that he is missing the EOR indicators. The file he has is an
IEBCOPY PDS UNLOAD to sequential file, but when the IND$FILE
On Mon, 19 Apr 2021 13:26:42 +0200, Hilario Garcia wrote:
>Hello,
>
>I had tested multiple combinations:
>
>RECFM LREL BLKSIZE
>FB 80 0
>VB 256 6233
>FB 1024 0
>VS 32736 32740
>FB 803120
>.. Too other combinations of different
> > > > Thank you very much in advance.
> > > >
> > > > Kind Regards
> > > >
> > > > Hilario
> > > >
> > > > El lun, 19 abr 2021 a las 10:29, Styles, Andy (ITS zPlatform
> Services)
> > (<
> > > > 0
(ITS zPlatform Services)
> (<
> > > 00d68f765d25-dmarc-requ...@listserv.ua.edu>) escribió:
> > >
> > > > Classification: Public
> > > >
> > > > I wonder if these are IEBCOPY unload format - that is, IEBCOPY from a
>
@LISTSERV.UA.EDU
Subject: Re: Format PDS unloaded on an CD
Hello,
I have tried to upload the files through both the native FTP protocol and
through FILEZILLA. The problem is the same as the format of the file received
is not correct.
Would you recommend me to take any other action to solve the problem
t - that is, IEBCOPY from a
> PDS
> > > to a PS. It's been years since I had to deal with those, probably
> since
> > I
> > > installed products directly from a vendor tape (one of those round
> things
> > > with the write-protect ring).
> > >
Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Joe Monk
> Sent: Monday, April 19, 2021 8:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Format PDS unloaded on an CD
>
> OK ... maybe now we're getting somewhere...
>
> I think we are having a cas
.
Eileen Barkow ebar...@doitt.nyc.gov
CICS systems
Desk: 718-403-8649
Cell: 917-436-0508
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Joe
Monk
Sent: Monday, April 19, 2021 8:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Format PDS unloaded on an CD
OK ... maybe now
and then using an IEBCOPY PS
> > to PDS to reload it?
> >
> > Andy Styles
> > z/Series System Programmer
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf
> > Of Hilario Garcia
> > Sent: 19 April 2021 06:42
round
> things
> > > with the write-protect ring).
> > >
> > > IEBCOPY seems to create unload format dasd datasets (here, at least) as
> > >
> > > Organization . . . : PS
> > > Record format . . . : VS
> >
length . . . : 32736
> > Block size . . . . : 32740
> >
> > Worth uploading one of those files as binary and then using an IEBCOPY PS
> > to PDS to reload it?
> >
> > Andy Styles
> > z/Series System Programmer
> >
> > -Original Message-
> > F
; > -- Forwarded message -
> > De: Hilario Garcia
> > Date: lun, 19 abr 2021 a las 7:40
> > Subject: Format PDS unloaded on an CD
> > To:
> >
> >
> > Hello,
> >
> > Thank you very much for your contributions.
> > I have don
Hm, Doesn't this looks like an unloaded PDS via IEBCOPY? Was it unloaded initially to a tape? And
then copied to the CD?
/PS
On 19/04/2021 07:42, Hilario Garcia wrote:
-- Forwarded message -
De: Hilario Garcia
Date: lun, 19 abr 2021 a las 7:40
Subject: Format PDS unloaded
z/Series System Programmer
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Hilario Garcia
> Sent: 19 April 2021 06:42
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Fwd: Format PDS unloaded on an CD
>
> -- This email has reached the Bank via an exter
System Programmer
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Hilario Garcia
Sent: 19 April 2021 06:42
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: Format PDS unloaded on an CD
-- This email has reached the Bank via an external source --
-- Forwarded message
-- Forwarded message -
De: Hilario Garcia
Date: lun, 19 abr 2021 a las 7:40
Subject: Format PDS unloaded on an CD
To:
Hello,
Thank you very much for your contributions.
I have done multiple tests with different utilities (XMIT, FTP, IND $ FILE,
AMATERSE) and I have not been
El lun, 19 abr 2021 a las 7:40, Hilario Garcia ()
escribió:
> Hello,
>
> Thank you very much for your contributions.
> I have done multiple tests with different utilities (XMIT, FTP, IND $
> FILE, AMATERSE) and I have not been able to download them in a valid format.
> Attached I send in
Hello,
Thank you very much for your contributions.
I have done multiple tests with different utilities (XMIT, FTP, IND $ FILE,
AMATERSE) and I have not been able to download them in a valid format.
Attached I send in hexadecimal format the beginning of one of the PDS (loaded
as FB, lrecl = 80)
Hilario,
There is no simple solution.
However the solution exist!
You need to find it.
Some hints:
1. Install any XMI viewer (I can help here) and simply try to open any
file. If it will work, this would be the end of investigation.
2. Install any EBCDIC viewer. HxD is good choice, but I would
If you can provide the first 50 or so bytes from the beginning of the file in
hex, someone might be able to identify the program that created it.
One way to create a file containing a hex representation of the contents of one
of your CD files is to use this command, which comes with windows.
determine the inner format?
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Gibney, Dave
Sent: Sunday, April 18, 2021 2:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Format PDS unloaded on an CD
If the content via notepad is readable (ASCII) then it's likely that
ay, April 18, 2021 10:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Format PDS unloaded on an CD
>
> If it's XMIT format then you can do a binary transfer to an FB LRECL 80
> dataser
> and use RECEIVE. There's also at least one XMIT manager that runs on
> windoze.
>
[IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Hilario Garcia [libr...@gmail.com]
Sent: Sunday, April 18, 2021 1:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Format PDS unloaded on an CD
811 / 5000
Resultados de traducción
I have a CD with download of several PDS files. The person who generated it is
dead
Hello,
All files have different extensions. The extension is an idea of the content of
the PDS (SOURCE, CNTL, COBOL, ASM, DATA, ...
The problem is that I do not know the different DCB values of all the files (I
suppose that not all have the same since some are LOAD libraries. If I load
them
ssion List On
>> Behalf Of Hilario Garcia
>> Sent: Sunday, April 18, 2021 10:13 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Format PDS unloaded on an CD
>>
>> 811 / 5000
>> Resultados de traducción
>> I have a CD with download of several PDS files. The
Are there any clues in the file extensions? Any .txt files of documentation?
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Hilario Garcia
> Sent: Sunday, April 18, 2021 10:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Format PDS unloaded
811 / 5000
Resultados de traducción
I have a CD with download of several PDS files. The person who generated it is
dead and the system where these files were has died and it cannot be
download again.
I don't know how these files were obtained (eg: DFDSS, IEBCOPY, AMATERSE, XMIT,
IND $ FILE, FTP
51 matches
Mail list logo
