Re: Inspecting and extracting from /OS transportable files on other platforms?

[Radoslaw Skorupka]

W dniu 03.02.2021 o 21:40, Tony Harminc pisze:

On Sat, 30 Jan 2021 at 11:36, Bernd Oppolzer  wrote:

Am 30.01.2021 um 00:39 schrieb Tony Harminc:

On Fri, 29 Jan 2021 at 18:21, Radoslaw Skorupka  wrote:


Few remarks:

...

4. Source code EBCDIC-ASCII translation. Example: I hate REXX
translation. REXX use || characters while in CP852 it should be !!.
Simple translation corrupts REXX code. C code is corrupted as well.

The | character is at the same code point X'7C' in CP852 (ISO Latin-2)
as it is in CP819 (ISO Latin-1) and most other European language CPs.
The ! character is at X'21' in CP852 and most others. So your problem
is with neither REXX nor with CP852 - it's presumably with some bad
translation table in your FTP or TN3270 or...

The problem is not at the client side (ASCII codepages);
the problem is that the EBCDIC codepages in Europe have the
exclamation point (!) at the place, where the American EBCDIC has |,
and so, if you transfer from an European EBCDIC codepage (273, for
example), which is standard here in Europe, you will get exclamation points
instead of | on the PC.

But this is still a problem of using the wrong translation table - not
of REXX or of EBCDIC or ASCII (ISO) code pages. All of the mentioned
CPs contain both the | and ! characters, so any translation that
changes one character to another is wrong. (I understand some historic
reasons for intentionally mistranslating - mostly because various
terminals could not enter or display certain characters. But in the
days of terminal emulators, there is surely no longer any excuse.)


Yes and no.
It can be fixed by customization of translation tables. At least for 
REXX code. However it will break translation of regular text with 
punctuations. So, one has to choose: REXX or regular text.
More the responsibility of terminal emulator user is to ...use it. When 
installing PCOMM I have no customization questions with regard to 
translation tables - installation program recognize my Windows locale 
and follow it.
After I installed PCOMM, Nexus or other emulator I can use IND$FILE or 
simply copy-paste. Both methods work - the EBCDIC text is translated to 
ASCII and vice versa. Almost all characters. A, B, C, space - it will be 
translated correctly.
However exclamation mark and | will not be translated as REXX code 
require. Can I change translation tables for the above processes? Yes, 
at least in PCOMM I remember how to do it. But this is quite nonstandard 
operation.
Last but not least: there is still need to recognize the purpose of 
transmitted content - is it REXX code or just a text.


That's why I strongly prefer to use XMIT format for REXX sources. 
Nothing will be lost in translation, because there is no translation.


--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Tony Harminc]

On Sat, 30 Jan 2021 at 11:36, Bernd Oppolzer  wrote:
>
> Am 30.01.2021 um 00:39 schrieb Tony Harminc:
> > On Fri, 29 Jan 2021 at 18:21, Radoslaw Skorupka  
> > wrote:
> >
> >> Few remarks:
> > ...
> >> 4. Source code EBCDIC-ASCII translation. Example: I hate REXX
> >> translation. REXX use || characters while in CP852 it should be !!.
> >> Simple translation corrupts REXX code. C code is corrupted as well.
> > The | character is at the same code point X'7C' in CP852 (ISO Latin-2)
> > as it is in CP819 (ISO Latin-1) and most other European language CPs.
> > The ! character is at X'21' in CP852 and most others. So your problem
> > is with neither REXX nor with CP852 - it's presumably with some bad
> > translation table in your FTP or TN3270 or...
>
> The problem is not at the client side (ASCII codepages);
> the problem is that the EBCDIC codepages in Europe have the
> exclamation point (!) at the place, where the American EBCDIC has |,
> and so, if you transfer from an European EBCDIC codepage (273, for
> example), which is standard here in Europe, you will get exclamation points
> instead of | on the PC.

But this is still a problem of using the wrong translation table - not
of REXX or of EBCDIC or ASCII (ISO) code pages. All of the mentioned
CPs contain both the | and ! characters, so any translation that
changes one character to another is wrong. (I understand some historic
reasons for intentionally mistranslating - mostly because various
terminals could not enter or display certain characters. But in the
days of terminal emulators, there is surely no longer any excuse.)

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Seymour J Metz]

If none of your data are binary, all character data use the same EBCDIC code 
page and all the characters exist in the target code page then that will work 
as far as visual fidelity is concerned. If you intend to use the data with a 
language processor then you also need to ensure that it supports the code point 
assignments of that code page. As an example, some implementations of REXX 
expect ¬ at 'AA'X while others expect it at 'AC'X.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, January 31, 2021 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

On Sat, 30 Jan 2021 17:35:57 +0100, Bernd Oppolzer wrote:
>
>The problem is not at the client side (ASCII codepages);
>the problem is that the EBCDIC codepages in Europe have the
>exclamation point (!) at the place, where the American EBCDIC has |,
>and so, if you transfer from an European EBCDIC codepage (273, for
>example),
>which is standard here in Europe, you will get exclamation points
>instead of |
>on the PC.
>
I'd expect the other way around: that I'd get '|' where an exclamation
point appears in CP 273.

But is there a case where FTP SITE SBDataconn does not suffice
with built-in code pages?

-- gil

--
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: Inspecting and extracting from /OS transportable files on other platforms?

[Seymour J Metz]

Yes, EBCDIC code pages are a mare's nest, even from a US-centric perspective.

IND$FILE uses a 3270 datastream and runs within your TSO session. WSA uses an 
SNA or TCP/IP session totally independent of your 3270 session, and supports 
ISPF running in batch.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Sunday, January 31, 2021 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

Am 31.01.2021 um 15:19 schrieb Paul Gilmartin:
> On Sat, 30 Jan 2021 17:35:57 +0100, Bernd Oppolzer wrote:
>> The problem is not at the client side (ASCII codepages);
>> the problem is that the EBCDIC codepages in Europe have the
>> exclamation point (!) at the place, where the American EBCDIC has |,
>> and so, if you transfer from an European EBCDIC codepage (273, for
>> example),
>> which is standard here in Europe, you will get exclamation points
>> instead of |
>> on the PC.
>>
> I'd expect the other way around: that I'd get '|' where an exclamation
> point appears in CP 273.

Maybe this is true, too.


>
> But is there a case where FTP SITE SBDataconn does not suffice
> with built-in code pages?
>
> -- gil


Let me try to explain the problem from a German mainframe programmer's
point of view,
who is using European EBCDIC codepages since the early 1980s.

For languages like PL/1 and REXX, who don't have both ! and | as
language elements,
the difference between US EBCDIC and Euro EBCDIC concerning those
characters
is not really a problem; we are accustomed to use ! instead of |, when
programming
PL/1 or REXX ... the concatenation is done using !! in both languages;
when downloading sources to the PC, we also get !! and the German umlauts
and all works well ...

as long as we don't try to run the programs on the PC or to upload the
sources
to a machine which uses US EBCDIC ... then we run into problems.

Then came C (around the early 1990s), and suddenly we were in big trouble,
because both | and ! are part of the language

and { and }, which turned out to be ä and ü in our Euro EBCDIC - the C
sources
looked horrible at our mainframe terminals.

(At that time, we did not use FTP, BTW, to send to sources to the
mainframe;
the tools were IND$FILE or something called workstation agent ... maybe
using
IND$FILE under the cover. You started the editing session on the mainframe,
but then the file was transferred to the PC and a local editing window
on the
PC opened; when saving the file, it was re-transferred to the mainframe.
Big fun :-) ...)

And so we had to translate all our programs (which we prepared and
tested on
the PC) to trigraphs etc., because the early C compilers only supported
US EBCDIC.

Today it is much better, because the C compiler can be controlled to
understand
whatever codepage you want (at a certain point in time, this was true
for the
C compiler, but not for the DB2 preprocessor, so we had to stay with the
trigraph mechanism for C/DB2-programs).

--
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: Inspecting and extracting from /OS transportable files on other platforms?

[Bernd Oppolzer]

Am 31.01.2021 um 15:19 schrieb Paul Gilmartin:

On Sat, 30 Jan 2021 17:35:57 +0100, Bernd Oppolzer wrote:

The problem is not at the client side (ASCII codepages);
the problem is that the EBCDIC codepages in Europe have the
exclamation point (!) at the place, where the American EBCDIC has |,
and so, if you transfer from an European EBCDIC codepage (273, for
example),
which is standard here in Europe, you will get exclamation points
instead of |
on the PC.


I'd expect the other way around: that I'd get '|' where an exclamation
point appears in CP 273.


Maybe this is true, too.




But is there a case where FTP SITE SBDataconn does not suffice
with built-in code pages?

-- gil



Let me try to explain the problem from a German mainframe programmer's 
point of view,

who is using European EBCDIC codepages since the early 1980s.

For languages like PL/1 and REXX, who don't have both ! and | as 
language elements,
the difference between US EBCDIC and Euro EBCDIC concerning those 
characters
is not really a problem; we are accustomed to use ! instead of |, when 
programming

PL/1 or REXX ... the concatenation is done using !! in both languages;
when downloading sources to the PC, we also get !! and the German umlauts
and all works well ...

as long as we don't try to run the programs on the PC or to upload the 
sources

to a machine which uses US EBCDIC ... then we run into problems.

Then came C (around the early 1990s), and suddenly we were in big trouble,
because both | and ! are part of the language

and { and }, which turned out to be ä and ü in our Euro EBCDIC - the C 
sources

looked horrible at our mainframe terminals.

(At that time, we did not use FTP, BTW, to send to sources to the 
mainframe;
the tools were IND$FILE or something called workstation agent ... maybe 
using

IND$FILE under the cover. You started the editing session on the mainframe,
but then the file was transferred to the PC and a local editing window 
on the
PC opened; when saving the file, it was re-transferred to the mainframe. 
Big fun :-) ...)


And so we had to translate all our programs (which we prepared and 
tested on
the PC) to trigraphs etc., because the early C compilers only supported 
US EBCDIC.


Today it is much better, because the C compiler can be controlled to 
understand
whatever codepage you want (at a certain point in time, this was true 
for the

C compiler, but not for the DB2 preprocessor, so we had to stay with the
trigraph mechanism for C/DB2-programs).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Paul Gilmartin]

On Sat, 30 Jan 2021 17:35:57 +0100, Bernd Oppolzer wrote:
>
>The problem is not at the client side (ASCII codepages);
>the problem is that the EBCDIC codepages in Europe have the
>exclamation point (!) at the place, where the American EBCDIC has |,
>and so, if you transfer from an European EBCDIC codepage (273, for
>example),
>which is standard here in Europe, you will get exclamation points
>instead of |
>on the PC.
> 
I'd expect the other way around: that I'd get '|' where an exclamation
point appears in CP 273.

But is there a case where FTP SITE SBDataconn does not suffice
with built-in code pages?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Seymour J Metz]

> 4. Source code EBCDIC-ASCII translation. Example: I hate REXX
> translation. REXX use || characters while in CP852 it should be !!. 

Rubbish. It is not the fault of CP852, C or REXX. CP852 has | and ! at the same 
code points as CP437. The issue is the EBCDIC code page and translation that 
you're using.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Radoslaw Skorupka [r.skoru...@hotmail.com]
Sent: Friday, January 29, 2021 6:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

I did it. There is no simple solution, not "one size fit all".
Few remarks:
1. EBCDIC-ASCII conversion. It is crucial for text file, however
sometimes record contain binary fields which should not be translated or
the translation is quite different.
2. Programs. There is no big reason to migrate PDS libraries (program
objects or load modules).
3. Source code. Why? It's not so obvoius.
4. Source code EBCDIC-ASCII translation. Example: I hate REXX
translation. REXX use || characters while in CP852 it should be !!.
Simple translation corrupts REXX code. C code is corrupted as well.
5. PDS/PDSE data. It is simple to download XMI files or just convert
PDS(E) to directory of members. Why?
6. "Archival purposes" can be EASILY fulfilled with ADRDSSU DUMP "all
files" and then XMIT and download. It is good archive, but it is
readable under z/OS. Bad? This is the only 100% exact copy. And let's
imagine, you can use two (or more) ways - one for "exact, but unreadable
copy", other for more readable copies, but not necessarily exact.

--
Radoslaw Skorupka
(currently unemployed)
Lodz, Poland



W dniu 28.01.2021 o 23:31, Gibney, Dave pisze:
>Isn't that a long winder subject?
> In preparation for shutting down my z/OS 2.3 system, sometime this year, 
> I am looking at options for unloading/storing both my z/OS files as well as 
> my application data and infrastructure files.
> I thought of experimenting with GIMZIP. Which, for a PDS/E uses IEBCOPY  
> to create a sequential  unload and then uses pax to create a 
> S.dsname.pax.Z file containing the unload and a GIMFAF.XML descriptive 
> file.
> I can download the .pax.Z file, and using 7zip decompress it.
> I looked on CBTTAPE.org and found the Xmit tools, and some terse/unterse 
> options. And tools for .aws files.
>I didn't find anything to process ot look at IEBCOPY unloaded files. Does 
> such a tool exist out there.
>
>I can of course TRANSMIT (and even AMATERSE it) before GIMZIP, or run pax 
> outside GIMZIP. But, I'd kind of like the GIMFAF.XML file...
>
> 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: Inspecting and extracting from /OS transportable files on other platforms?

[Seymour J Metz]

Some tools to consider including in the mix, with binary FTP:

   AMS EXPORT
   IEBCOPY unload
   tar
   zip


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Gibney, Dave [gib...@wsu.edu]
Sent: Friday, January 29, 2021 8:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

Thank you to all who have responded, I appreciate the several suggestions so 
far, I may try several of them. I may get shifted into other efforts.
 Right now, this is an  exploratory, researching, POC,  project and with 
undefined or incomplete and amorphous goals..
Even the ultimate target users/audience isn't clear, and they may not, in the 
end, actually ever need to look. But, it is very unlikely that, as least for 
any preliminary looking, they are unlikely to have access to a z/OS system (or 
even a Hercules/MVS 3.8)
  because if the need arises very far into the future , it probably won't be 
me. I'll have 40 years in  here  come August, and may or may not be available 
to them.

  I want something )or several different "things" that will, at least 
hypothetically let there be a chance for a  historical, investigatory, or, god 
forbid, a forensic effort to get started.
   I also don't want it to be significantly manual. I have SMP/E, DCOLLECT, 
ADRDSSU, TRANSMIT, FTP, (Could install CCKDDUMP), DFSORT, Rexx and other tools 
(Natural) available. And aside from PS, PDS, VSAM, there is also Adabas, 
Control-D and probably Endevor data to consider.


> 6. "Archival purposes" can be EASILY fulfilled with ADRDSSU DUMP "all
> files" and then XMIT and download. It is good archive, but it is
> readable under z/OS. Bad? This is the only 100% exact copy. And let's
> imagine, you can use two (or more) ways - one for "exact, but unreadable
> copy", other for more readable copies, but not necessarily exact.
>
> > In preparation for shutting down my z/OS 2.3 system, sometime this
> year, I am looking at options for unloading/storing both my z/OS files as well
> as my application data and infrastructure files.


--
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: Inspecting and extracting from /OS transportable files on other platforms?

[Seymour J Metz]

I see that it also handles AWS :-)


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [rob...@prino.org]
Sent: Saturday, January 30, 2021 2:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

On 2021-01-29 16:44, Seymour J Metz wrote:
> XMIT is not supported on all platforms. Other formats, e.g., tar, zip, are
> nigh near universal.

The XMIT format is with a high degree of certainty supported on every platform
that has Java:

<https://secure-web.cisco.com/16WWy-0-gt4g_mjKyEwhkIqGWo9KaNdMHHzjweR84JmITS-fJxoXOObrPIArwZ2644pdB_Y9vXCauJNEn0ayoMpSzb1SXbWOvaRPf6EEG-rUxuhfYsgFKGACLjVbP5KPK3XEx8pfb9YA0ZPGF6fiTej2kd0u-r1oag9h7P9XfXSSYeKUpwTXBjyJODnZb26uFG2_w36oXH8X5tz93VSSTll3E7hfG8mhyGMxzoF5Z0OhvNpIILKJUlMjhzwTaU1YEfL3TikZ41D9fP_fsDxcbv8QADWHLlU5exeOeonYeSNANBg5NKRZCRaJBScYiXnXC9tJaUn5o2S8jsVrZF7odf4Vp3an1Bk9n2_MJH3XLC42z7hlYzjCyFr_fqt13b-of5Po7iBLpJgcB_sz0-RUOiieDMjjrBuxKyL07LlppXN7WgqEpwZTa52kqr4Rb9hRka1k7rfM7fIqFtkDsnJjMyQ/https%3A%2F%2Fgithub.com%2Fdmolony%2FXmit>,
 and I'm sure the C version on the CBTTape
site (File # 776) will compile on any system, although that program can only
handle PDS'es.

> FTP of a PDS won't preserve all of the data. Does Info-Zip include all of
> the  directory information? Also, FTP raises the issues of binary data and 
> code pages.

Not just FTP. IND$FILE and the WSA have the same problems.

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - 
https://secure-web.cisco.com/1pv_BExGlhLZXiOFWSYqHo-06BzGoPv4zniVm2gqSILrmijDWZhfdZ0i7vHFu0LI5lnLwgXCFhDvYX2Gauxc1sx1d6wUtAyIJW1VcmnISBTA1dyWOhQ16iVolc4IgGRGFybk7IcSNntqYqvlrL0kIdkb1TFXPryjn9-RF8NdLkPTWZzVjbKgdrnpq4bw2PpDenAfRy5SKVJbVD_lU0LkPKEMgmmjTAZgYA_2RIDonvUb5rMxZfNhru6KUlANsT8WruR4_4DpBDiWZFCFj_uXqLBrtfJKp7IvzavdAuCsXm1HLACX8tG6vKfXYb0qNLNXxUNxzF3HgcXRQS5fqEDngat3jypz2bTkVR-Uvi2g02tIa5mw8PmMIDQ1dJNLzxtWj50fPsVb5Sq295XBKS2yfg4vR5GA8zsKHgfP3UEO-zojzkz9Zj8oN01gMRR2xEdsQcN8-e1EPUNFcF_mnyhmOcg/https%3A%2F%2Fprino.neocities.org%2Findez.html
Some REXX code for use on z/OS - 
https://secure-web.cisco.com/1dmwoUmiKVwhkMfwrWpgXiP2wM3i-OC-n7vKuYrPHuwO_2gblPNBJUSMXDYhckHyxdzIK2gQkpnG2r-l2FtN7bHwKcWUbjzn3DgsRhEPEGtiP5erj2vlFT7ohGKIQQY5ciuFFEXv0GnocY2F5aLTqKTBLjT-9x8y_c6BCvzAdtaPRKfMnK_Q8EuATrJ_8G2SR0kmyOlcZbAqs5g7h20UkuBWwhb56LdVq8TD_itAHxwci8d4H9o5kX0lV12-vew146DTUvx21-0k0maNUNzdIi1yQRZkDY7EOSkt0Ep2-nAtD_OwvnBzZQYaPsb8Wvs0KB3QOwUQVeH6Z1aYp_9BfDLHC5nKbMRiHPf6Ol5olYz29rOeXpu-DXcQ0vrosgm4K-7tWyluuI7_icTdEpoqmLc_d2skAy2KzXbVovTiH5dRo6ky1vdGMELLnhHB1iUB3U_L69bdMUaR2lAhceIv7wA/https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.html

> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Brian Westerman [brian_wester...@syzygyinc.com]
> Sent: Friday, January 29, 2021 3:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Inspecting and extracting from /OS transportable files on other 
> platforms?
>
> I think I would use transmit format for transporting things between systems, 
> it's easily transportable and common no matter where you go and is even 
> usable on a desktop PC.
>
> The other thing you can do (which I personally do) is simply FTP the PDS's 
> and sequential files directly to your PC (on a USB drive) in ASCII format.  I 
> do this weekly, rotating the encrypted USB drive that I have on my keychain 
> so that if it's broken or lost (that's why I encrypt), I can just get the 
> previous one.  My USB drives are pre-encrypted with Bitlocker so I really 
> don't have to do much (ever).  Previously I used to use those little USB 
> drives with the combination lock built in to them, but they are very 
> unreliable (and slow).  So now, when fast USB drives go on sale at Amazon, I 
> always buy several.  I like the sandisk 256GB ones because a) they are fast, 
> and more importantly b) they have a lifetime warranty.
>
> I have a batch file that I run to do this.  I plug in my USB drive and start 
> the batch file and go get a diet coke.
>
> I'm thinking about moving the process to one of the ruggedized external NVMe 
> drives.  I'm currently testing the new Sabrent 2TB one and it's VERY fast 
> (1Gb+/sec) and is small enough to easily fit in a pocket.  Plus being 
> ruggedized it's waterproof and drop-proof (so far).  The sandisk drives 
> typically load at around 140MB/s, but the Sabrent drive is almost 10 times 
> faster.
>
> The reason I want 2TB is that I would like to keep a whole Disaster recovery 
> system on that drive (DF/DSS unloaded virtual tapes).  At the faster speed, 
> it's actually not a bad process, I just need to work out the kinks a l

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Radoslaw Skorupka]

W dniu 30.01.2021 o 20:29, Robert Prins pisze:

On 2021-01-29 16:44, Seymour J Metz wrote:
XMIT is not supported on all platforms. Other formats, e.g., tar, 
zip, are

nigh near universal.


The XMIT format is with a high degree of certainty supported on every 
platform that has Java:


, and I'm sure the C version on the 
CBTTape site (File # 776) will compile on any system, although that 
program can only handle PDS'es.


FTP of a PDS won't preserve all of the data. Does Info-Zip include 
all of
the  directory information? Also, FTP raises the issues of binary 
data and code pages.


Not just FTP. IND$FILE and the WSA have the same problems.


XMIT files are somehow supported on PC side for decades. There are 
several programs for that, most of them are free and unfortunately most 
of them are abandonware.

However they exist.
What does it mean?
1. You can read members from XMIT'ted PDS(E).
2. Of course members can be saved files in directory/folder - PDS is 
kind of folder. However in this case EBCDIC-ASCII conversion issues do 
apply.
3. In few cases a content of PDS directory is interesting. In that case 
XMIT tools are not helpful. However let's be honest: what is the value 
of accessing PDS directory details on PC side? Usually it is interesting 
for load modules or program objects. Rather not interesting on PC side.
4. Philosophical question: do we care about content or just 10% 
exact bit to bit copy? Do you want to know members content or you also 
care about PDS bitmap before it is compressed (in terms of PDS compress)?



Advertisement: A set of XMIT tools can be found on 
http://cbttape.org/xmitview.htm

My choice is XMI Explorer. The second one is Xmit-Manager.
In my opinion java-based tools are doubtful choice because of changes in 
java status.


--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Robert Prins]

On 2021-01-29 16:44, Seymour J Metz wrote:

XMIT is not supported on all platforms. Other formats, e.g., tar, zip, are
nigh near universal.


The XMIT format is with a high degree of certainty supported on every platform 
that has Java:


<https://github.com/dmolony/Xmit>, and I'm sure the C version on the CBTTape 
site (File # 776) will compile on any system, although that program can only 
handle PDS'es.



FTP of a PDS won't preserve all of the data. Does Info-Zip include all of
the  directory information? Also, FTP raises the issues of binary data and code 
pages.


Not just FTP. IND$FILE and the WSA have the same problems.

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Brian Westerman [brian_wester...@syzygyinc.com]
Sent: Friday, January 29, 2021 3:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

I think I would use transmit format for transporting things between systems, 
it's easily transportable and common no matter where you go and is even usable 
on a desktop PC.

The other thing you can do (which I personally do) is simply FTP the PDS's and 
sequential files directly to your PC (on a USB drive) in ASCII format.  I do 
this weekly, rotating the encrypted USB drive that I have on my keychain so 
that if it's broken or lost (that's why I encrypt), I can just get the previous 
one.  My USB drives are pre-encrypted with Bitlocker so I really don't have to 
do much (ever).  Previously I used to use those little USB drives with the 
combination lock built in to them, but they are very unreliable (and slow).  So 
now, when fast USB drives go on sale at Amazon, I always buy several.  I like 
the sandisk 256GB ones because a) they are fast, and more importantly b) they 
have a lifetime warranty.

I have a batch file that I run to do this.  I plug in my USB drive and start 
the batch file and go get a diet coke.

I'm thinking about moving the process to one of the ruggedized external NVMe 
drives.  I'm currently testing the new Sabrent 2TB one and it's VERY fast 
(1Gb+/sec) and is small enough to easily fit in a pocket.  Plus being 
ruggedized it's waterproof and drop-proof (so far).  The sandisk drives 
typically load at around 140MB/s, but the Sabrent drive is almost 10 times 
faster.

The reason I want 2TB is that I would like to keep a whole Disaster recovery 
system on that drive (DF/DSS unloaded virtual tapes).  At the faster speed, 
it's actually not a bad process, I just need to work out the kinks a little bit 
more so that I can automate it.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Bernd Oppolzer]

Am 30.01.2021 um 00:39 schrieb Tony Harminc:

On Fri, 29 Jan 2021 at 18:21, Radoslaw Skorupka  wrote:


Few remarks:

...

4. Source code EBCDIC-ASCII translation. Example: I hate REXX
translation. REXX use || characters while in CP852 it should be !!.
Simple translation corrupts REXX code. C code is corrupted as well.

The | character is at the same code point X'7C' in CP852 (ISO Latin-2)
as it is in CP819 (ISO Latin-1) and most other European language CPs.
The ! character is at X'21' in CP852 and most others. So your problem
is with neither REXX nor with CP852 - it's presumably with some bad
translation table in your FTP or TN3270 or...



The problem is not at the client side (ASCII codepages);
the problem is that the EBCDIC codepages in Europe have the
exclamation point (!) at the place, where the American EBCDIC has |,
and so, if you transfer from an European EBCDIC codepage (273, for 
example),
which is standard here in Europe, you will get exclamation points 
instead of |

on the PC.

Same problem, if you transfer C programs written on the PC to mainframes;
you have to make sure, that the mainframe C compiler uses the European
EBCDIC codepage, which was not possible in the early days of C on the 
mainframe,
so we had to translate the source code to trigraphs after transferring 
it to

the mainframe.

Kind regards

Bernd




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: Inspecting and extracting from /OS transportable files on other platforms?

[Radoslaw Skorupka]

W dniu 30.01.2021 o 00:39, Tony Harminc pisze:

On Fri, 29 Jan 2021 at 18:21, Radoslaw Skorupka  wrote:


Few remarks:

...

4. Source code EBCDIC-ASCII translation. Example: I hate REXX
translation. REXX use || characters while in CP852 it should be !!.
Simple translation corrupts REXX code. C code is corrupted as well.

The | character is at the same code point X'7C' in CP852 (ISO Latin-2)
as it is in CP819 (ISO Latin-1) and most other European language CPs.
The ! character is at X'21' in CP852 and most others. So your problem
is with neither REXX nor with CP852 - it's presumably with some bad
translation table in your FTP or TN3270 or...


Tony,
I live with this issue for more than 20 years. First time I met it in 
1999 when I tried to run ...Star Wars move on ISPF.
Of course I know how to manage it, but default codepage translation 
tables do not. It doesn't matter you use ftp, IND$FILE or just 
copy-paste from Notepad to 3270 emulator (various types/vendors).
Of course the table can be modified, but it will fix REXX sourcecode 
problem and will be bad for other text files.
BTW: I think it is not simply my problem or problem of Eastern Europe 
(actually I live in Central Europe). It is also described on Mark Zelden 
website. And Mark provided good advice there: use XMIT format whenever 
possible. I follow it. Of course it is not applicable for "copy-pasted" 
small portions of code from some redbook or other publication.


BTW: I vaguely remember when I fixed the issue of square brackets and 
code page not displaying it correctly - AFAIR it took them one and half 
day before I helped them. It was some backup product, nevermind.


Regarding to the topic - Charles was good on this point - small errors 
do not prevent to review the code. And exact (but hard to read) copy can 
be done as well.


--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Mike Schwab]

PDSE Edit Generations ISPF package.
https://github.com/lbdyck/pdsegen

On Fri, Jan 29, 2021 at 6:20 PM Tony Harminc  wrote:
>
> On Fri, 29 Jan 2021 at 14:55, Gibney, Dave  wrote:
> >
> >I am still interested in a Windows (or Linux) tool that can understand 
> > PDS/E unload format.
>
> It's an interesting issue, because while the IEBCOPY unload format of
> a PDSE is documented in some detail, the PDSE format itself (as it
> exists on disk) is not. I don't know if IBM has extended this unload
> doc to include the newer features like large format and member
> generations. Probably not...
>
> In any case while I have vague memory of some non-mainframe tools out
> there that can read IEBCOPY unloads, I can't at the moment find them.
> It's not all *that* complicated; perhaps you'd like to contribute.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Gibney, Dave]

Thank you to all who have responded, I appreciate the several suggestions so 
far, I may try several of them. I may get shifted into other efforts. 
 Right now, this is an  exploratory, researching, POC,  project and with 
undefined or incomplete and amorphous goals..
Even the ultimate target users/audience isn't clear, and they may not, in the 
end, actually ever need to look. But, it is very unlikely that, as least for 
any preliminary looking, they are unlikely to have access to a z/OS system (or 
even a Hercules/MVS 3.8) 
  because if the need arises very far into the future , it probably won't be 
me. I'll have 40 years in  here  come August, and may or may not be available 
to them. 
  
  I want something )or several different "things" that will, at least 
hypothetically let there be a chance for a  historical, investigatory, or, god 
forbid, a forensic effort to get started.
   I also don't want it to be significantly manual. I have SMP/E, DCOLLECT, 
ADRDSSU, TRANSMIT, FTP, (Could install CCKDDUMP), DFSORT, Rexx and other tools 
(Natural) available. And aside from PS, PDS, VSAM, there is also Adabas, 
Control-D and probably Endevor data to consider. 
  

> 6. "Archival purposes" can be EASILY fulfilled with ADRDSSU DUMP "all
> files" and then XMIT and download. It is good archive, but it is
> readable under z/OS. Bad? This is the only 100% exact copy. And let's
> imagine, you can use two (or more) ways - one for "exact, but unreadable
> copy", other for more readable copies, but not necessarily exact.
> 
> > In preparation for shutting down my z/OS 2.3 system, sometime this
> year, I am looking at options for unloading/storing both my z/OS files as well
> as my application data and infrastructure files.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Tony Harminc]

On Thu, 28 Jan 2021 at 17:32, Gibney, Dave  wrote:

>In preparation for shutting down my z/OS 2.3 system, sometime this year, I 
> am looking at options for unloading/storing both my z/OS files as well as my 
> application data and infrastructure files.

Another approach to the many mentioned is to use the CCKDDUMP utility
(CBT file 541 and other places) that runs on z/OS and creates a
Hercules format CCKD file that represents an entire z/OS disk volume.
Or you can select what gets dumped by wildcarded DSNs and still get a
complete volume image containing tracks from just those datasets. Or
if you're in a position to do so, you could create (or reuse) an
entire volume, copy all your data to it, and CCKDDUMP that.

What to do with this dump, then? Well you can use it with the Hercules
emulator, or possibly (with conversion) on some others such as a P390
or a zPDT.

Of course I'm not suggesting you should unload z/OS itself, but in
general the old MVS 3.8 (with hobbyist community updates) can mount
fairly modern volumes. There's no PDSE support, unfortunately, and
VSAM is back level, but most else should be fine.

Like the "run a DFDSS dump of all your datasets", this is a "collect
it all" approach. It may be less easy to use, but you'll know you have
all your stuff, and can always find someone to mount the volume and
restore something you may forget if you do it piece by piece.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Tony Harminc]

On Fri, 29 Jan 2021 at 14:55, Gibney, Dave  wrote:
>
>I am still interested in a Windows (or Linux) tool that can understand 
> PDS/E unload format.

It's an interesting issue, because while the IEBCOPY unload format of
a PDSE is documented in some detail, the PDSE format itself (as it
exists on disk) is not. I don't know if IBM has extended this unload
doc to include the newer features like large format and member
generations. Probably not...

In any case while I have vague memory of some non-mainframe tools out
there that can read IEBCOPY unloads, I can't at the moment find them.
It's not all *that* complicated; perhaps you'd like to contribute.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Tony Harminc]

On Fri, 29 Jan 2021 at 18:21, Radoslaw Skorupka  wrote:

> Few remarks:
...
> 4. Source code EBCDIC-ASCII translation. Example: I hate REXX
> translation. REXX use || characters while in CP852 it should be !!.
> Simple translation corrupts REXX code. C code is corrupted as well.

The | character is at the same code point X'7C' in CP852 (ISO Latin-2)
as it is in CP819 (ISO Latin-1) and most other European language CPs.
The ! character is at X'21' in CP852 and most others. So your problem
is with neither REXX nor with CP852 - it's presumably with some bad
translation table in your FTP or TN3270 or...

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Charles Mills]

> you can use two (or more) ways - one for "exact, but unreadable 
> copy", other for more readable copies, but not necessarily exact.

That is exactly what I do. ADRDSSU of everything gives you a perfect restore 
with all the attributes and so forth. You can terse it if you wish and bring it 
to and from a small system in binary.

Then the source and JCL and similar files you also bring down member by member 
translated to "ASCII" (as FTP calls it -- please, no rants about code pages). 
Perfect for many things and "good enough" for others. You can satisfy "how did 
I do that before?" even if a few characters are corrupted, and worst case a few 
CHANGE commands makes everything right.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Radoslaw Skorupka
Sent: Friday, January 29, 2021 3:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

I did it. There is no simple solution, not "one size fit all".
Few remarks:
1. EBCDIC-ASCII conversion. It is crucial for text file, however 
sometimes record contain binary fields which should not be translated or 
the translation is quite different.
2. Programs. There is no big reason to migrate PDS libraries (program 
objects or load modules).
3. Source code. Why? It's not so obvoius.
4. Source code EBCDIC-ASCII translation. Example: I hate REXX 
translation. REXX use || characters while in CP852 it should be !!. 
Simple translation corrupts REXX code. C code is corrupted as well.
5. PDS/PDSE data. It is simple to download XMI files or just convert 
PDS(E) to directory of members. Why?
6. "Archival purposes" can be EASILY fulfilled with ADRDSSU DUMP "all 
files" and then XMIT and download. It is good archive, but it is 
readable under z/OS. Bad? This is the only 100% exact copy. And let's 
imagine, you can use two (or more) ways - one for "exact, but unreadable 
copy", other for more readable copies, but not necessarily exact.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Radoslaw Skorupka]

I did it. There is no simple solution, not "one size fit all".
Few remarks:
1. EBCDIC-ASCII conversion. It is crucial for text file, however 
sometimes record contain binary fields which should not be translated or 
the translation is quite different.
2. Programs. There is no big reason to migrate PDS libraries (program 
objects or load modules).

3. Source code. Why? It's not so obvoius.
4. Source code EBCDIC-ASCII translation. Example: I hate REXX 
translation. REXX use || characters while in CP852 it should be !!. 
Simple translation corrupts REXX code. C code is corrupted as well.
5. PDS/PDSE data. It is simple to download XMI files or just convert 
PDS(E) to directory of members. Why?
6. "Archival purposes" can be EASILY fulfilled with ADRDSSU DUMP "all 
files" and then XMIT and download. It is good archive, but it is 
readable under z/OS. Bad? This is the only 100% exact copy. And let's 
imagine, you can use two (or more) ways - one for "exact, but unreadable 
copy", other for more readable copies, but not necessarily exact.


--
Radoslaw Skorupka
(currently unemployed)
Lodz, Poland



W dniu 28.01.2021 o 23:31, Gibney, Dave pisze:

   Isn't that a long winder subject?
In preparation for shutting down my z/OS 2.3 system, sometime this year, I 
am looking at options for unloading/storing both my z/OS files as well as my 
application data and infrastructure files.
I thought of experimenting with GIMZIP. Which, for a PDS/E uses IEBCOPY  to 
create a sequential  unload and then uses pax to create a S.dsname.pax.Z 
file containing the unload and a GIMFAF.XML descriptive file.
I can download the .pax.Z file, and using 7zip decompress it.
I looked on CBTTAPE.org and found the Xmit tools, and some terse/unterse 
options. And tools for .aws files.
   I didn't find anything to process ot look at IEBCOPY unloaded files. Does 
such a tool exist out there.

   I can of course TRANSMIT (and even AMATERSE it) before GIMZIP, or run pax 
outside GIMZIP. But, I'd kind of like the GIMFAF.XML file...

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

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Gibney, Dave]

Looking at the doc for XMIT viewers and processors, it seems clear that, 
inside them is logic to process PDS/E Unloaded data. And, if I do elect to use 
TRANSMIT to archive, then these would help. 
   However, GIMZIP uses /pax -x pax -zvwf  with an input of a straight unloaded 
format. So, my desire is something that can look directly at the unzipped PDS/E 
unloaded file.

   I have not installed and exercised any of the Xmit managers. 


> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Charles Mills
> Sent: Friday, January 29, 2021 12:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Inspecting and extracting from /OS transportable files on other
> platforms?
> 
> Is this information relevant?
> 
> https://urldefense.com/v3/__http://www.cbttape.org/xmitview.htm__;!!J
> mPEgBY0HMszNaDT!5QfEXb_BCXkCkkV7xs-
> uf_BOyVUHTbfwMmxjOtanxPWXxVCWDsYjVMLrxwMLOA$
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> Behalf Of Gibney, Dave
> Sent: Friday, January 29, 2021 11:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Inspecting and extracting from /OS transportable files on other
> platforms?
> 
>I am still interested in a Windows (or Linux) tool that can understand
> PDS/E unload format.
> 
> But, here is another question. GIMZIP creates a GIMPAF.XML file
> describing the contents. I would like to process this file back into the
> GIMZIP package control tags. The purpose is to re-archive my system at it's
> current RSU state.
>   I've never needed to really pay attention to XML or predecessors (I was
> last in the general arena with DCE 35 years ago)
>   I am sure I can do this with ordinary editors (ISPF), or Rexx, probably
> even SORT. Or throw in some Excel.
>  Seems there might be an XML editor to make this easier.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Gibney, Dave
> > Sent: Thursday, January 28, 2021 2:32 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Inspecting and extracting from /OS transportable files on other
> > platforms?
> >
> >   Isn't that a long winder subject?
> >In preparation for shutting down my z/OS 2.3 system, sometime this
> year, I
> > am looking at options for unloading/storing both my z/OS files as well as
> my
> > application data and infrastructure files.
> >I thought of experimenting with GIMZIP. Which, for a PDS/E uses IEBCOPY
> > to create a sequential  unload and then uses pax to create a
> > S.dsname.pax.Z file containing the unload and a GIMFAF.XML
> > descriptive file.
> >I can download the .pax.Z file, and using 7zip decompress it.
> >I looked on CBTTAPE.org and found the Xmit tools, and some
> terse/unterse
> > options. And tools for .aws files.
> >   I didn't find anything to process ot look at IEBCOPY unloaded files.
> Does such
> > a tool exist out there.
> >
> >   I can of course TRANSMIT (and even AMATERSE it) before GIMZIP, or run
> > pax outside GIMZIP. But, I'd kind of like the GIMFAF.XML file...
> >
> > 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: Inspecting and extracting from /OS transportable files on other platforms?

[Gibney, Dave]

I probably should have analyised the problem a bit more, before asking, Looks 
like this is a few change commands, and some exclude/del all x

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Seymour J Metz
> Sent: Friday, January 29, 2021 12:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Inspecting and extracting from /OS transportable files on other
> platforms?
> 
> There are a lot of packages for transforming XML. It might be easier to use
> one of them rather than writing an edit macro to do it.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> BY0HMszNaDT!7-
> x9D7Ivq6ZvckDcfunTdzLEl6PJ6edQQGWHeacgsU6iI1iysFaKE7Yq-5fZvQ$
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Gibney, Dave [gib...@wsu.edu]
> Sent: Friday, January 29, 2021 2:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Inspecting and extracting from /OS transportable files on other
> platforms?
> 
>I am still interested in a Windows (or Linux) tool that can understand 
> PDS/E
> unload format.
> 
> But, here is another question. GIMZIP creates a GIMPAF.XML file
> describing the contents. I would like to process this file back into the 
> GIMZIP
> package control tags. The purpose is to re-archive my system at it's current
> RSU state.
>   I've never needed to really pay attention to XML or predecessors (I was last
> in the general arena with DCE 35 years ago)
>   I am sure I can do this with ordinary editors (ISPF), or Rexx, probably even
> SORT. Or throw in some Excel.
>  Seems there might be an XML editor to make this easier.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Gibney, Dave
> > Sent: Thursday, January 28, 2021 2:32 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Inspecting and extracting from /OS transportable files on other
> > platforms?
> >
> >   Isn't that a long winder subject?
> >In preparation for shutting down my z/OS 2.3 system, sometime this year,
> I
> > am looking at options for unloading/storing both my z/OS files as well as my
> > application data and infrastructure files.
> >I thought of experimenting with GIMZIP. Which, for a PDS/E uses IEBCOPY
> > to create a sequential  unload and then uses pax to create a
> > S.dsname.pax.Z file containing the unload and a GIMFAF.XML
> > descriptive file.
> >I can download the .pax.Z file, and using 7zip decompress it.
> >I looked on CBTTAPE.org and found the Xmit tools, and some
> terse/unterse
> > options. And tools for .aws files.
> >   I didn't find anything to process ot look at IEBCOPY unloaded files. Does
> such
> > a tool exist out there.
> >
> >   I can of course TRANSMIT (and even AMATERSE it) before GIMZIP, or run
> > pax outside GIMZIP. But, I'd kind of like the GIMFAF.XML file...
> >
> > 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: Inspecting and extracting from /OS transportable files on other platforms?

[Tim Hare]

The best tool to transform XML is XSLT.  It's a little funky to learn, because 
it's a "functional programming language"  but it's designed for XML.  I used it 
this way



] >

&myfile;


The stylesheet does all the work.  You'll find information about XSLT around 
the 'net. I don't claim to be good at it, I hack away until I get what I need. 
Note that the contents of &myfile do not _have_ to be XML, I have used this to 
transform calendar text files into XML and played with extracting info from 
COBOL source.  Also note: I have not done this with the XML you're talking 
about.

I don't remember (Semi-retired) if z/OS contains a 'batch' XML processor;  the 
one I have on my PC at home was XT, written in Java.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Charles Mills]

Is this information relevant?

http://www.cbttape.org/xmitview.htm 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gibney, Dave
Sent: Friday, January 29, 2021 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other
platforms?

   I am still interested in a Windows (or Linux) tool that can understand
PDS/E unload format.
   
But, here is another question. GIMZIP creates a GIMPAF.XML file
describing the contents. I would like to process this file back into the
GIMZIP package control tags. The purpose is to re-archive my system at it's
current RSU state.
  I've never needed to really pay attention to XML or predecessors (I was
last in the general arena with DCE 35 years ago)
  I am sure I can do this with ordinary editors (ISPF), or Rexx, probably
even SORT. Or throw in some Excel. 
 Seems there might be an XML editor to make this easier.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gibney, Dave
> Sent: Thursday, January 28, 2021 2:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Inspecting and extracting from /OS transportable files on other
> platforms?
> 
>   Isn't that a long winder subject?
>In preparation for shutting down my z/OS 2.3 system, sometime this
year, I
> am looking at options for unloading/storing both my z/OS files as well as
my
> application data and infrastructure files.
>I thought of experimenting with GIMZIP. Which, for a PDS/E uses IEBCOPY
> to create a sequential  unload and then uses pax to create a
> S.dsname.pax.Z file containing the unload and a GIMFAF.XML
> descriptive file.
>I can download the .pax.Z file, and using 7zip decompress it.
>I looked on CBTTAPE.org and found the Xmit tools, and some
terse/unterse
> options. And tools for .aws files.
>   I didn't find anything to process ot look at IEBCOPY unloaded files.
Does such
> a tool exist out there.
> 
>   I can of course TRANSMIT (and even AMATERSE it) before GIMZIP, or run
> pax outside GIMZIP. But, I'd kind of like the GIMFAF.XML file...
> 
> 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: Inspecting and extracting from /OS transportable files on other platforms?

[Lennie Dymoke-Bradshaw]

"  I am still interested in a Windows (or Linux) tool that can understand
PDS/E unload format."

This is my favourite.
https://www.fileviewer.com/

Lennie Dymoke-Bradshaw
Consultant working on contract for BMC mainframe Services by RSM Partners
'Dance like no one is watching. Encrypt like everyone is.'


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Gibney, Dave
Sent: 29 January 2021 19:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other
platforms?

   I am still interested in a Windows (or Linux) tool that can understand
PDS/E unload format.
   
But, here is another question. GIMZIP creates a GIMPAF.XML file
describing the contents. I would like to process this file back into the
GIMZIP package control tags. The purpose is to re-archive my system at it's
current RSU state.
  I've never needed to really pay attention to XML or predecessors (I was
last in the general arena with DCE 35 years ago)
  I am sure I can do this with ordinary editors (ISPF), or Rexx, probably
even SORT. Or throw in some Excel. 
 Seems there might be an XML editor to make this easier.

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Gibney, Dave
> Sent: Thursday, January 28, 2021 2:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Inspecting and extracting from /OS transportable files on 
> other platforms?
> 
>   Isn't that a long winder subject?
>In preparation for shutting down my z/OS 2.3 system, sometime this 
> year, I am looking at options for unloading/storing both my z/OS files 
> as well as my application data and infrastructure files.
>I thought of experimenting with GIMZIP. Which, for a PDS/E uses 
> IEBCOPY to create a sequential  unload and then uses pax to create a 
> S.dsname.pax.Z file containing the unload and a GIMFAF.XML 
> descriptive file.
>I can download the .pax.Z file, and using 7zip decompress it.
>I looked on CBTTAPE.org and found the Xmit tools, and some 
> terse/unterse options. And tools for .aws files.
>   I didn't find anything to process ot look at IEBCOPY unloaded files. 
> Does such a tool exist out there.
> 
>   I can of course TRANSMIT (and even AMATERSE it) before GIMZIP, or 
> run pax outside GIMZIP. But, I'd kind of like the GIMFAF.XML file...
> 
> 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: Inspecting and extracting from /OS transportable files on other platforms?

[Seymour J Metz]

There are a lot of packages for transforming XML. It might be easier to use one 
of them rather than writing an edit macro to do it.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Gibney, Dave [gib...@wsu.edu]
Sent: Friday, January 29, 2021 2:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

   I am still interested in a Windows (or Linux) tool that can understand PDS/E 
unload format.

But, here is another question. GIMZIP creates a GIMPAF.XML file describing 
the contents. I would like to process this file back into the GIMZIP package 
control tags. The purpose is to re-archive my system at it's current RSU state.
  I've never needed to really pay attention to XML or predecessors (I was last 
in the general arena with DCE 35 years ago)
  I am sure I can do this with ordinary editors (ISPF), or Rexx, probably even 
SORT. Or throw in some Excel.
 Seems there might be an XML editor to make this easier.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gibney, Dave
> Sent: Thursday, January 28, 2021 2:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Inspecting and extracting from /OS transportable files on other
> platforms?
>
>   Isn't that a long winder subject?
>In preparation for shutting down my z/OS 2.3 system, sometime this year, I
> am looking at options for unloading/storing both my z/OS files as well as my
> application data and infrastructure files.
>I thought of experimenting with GIMZIP. Which, for a PDS/E uses IEBCOPY
> to create a sequential  unload and then uses pax to create a
> S.dsname.pax.Z file containing the unload and a GIMFAF.XML
> descriptive file.
>I can download the .pax.Z file, and using 7zip decompress it.
>I looked on CBTTAPE.org and found the Xmit tools, and some terse/unterse
> options. And tools for .aws files.
>   I didn't find anything to process ot look at IEBCOPY unloaded files. Does 
> such
> a tool exist out there.
>
>   I can of course TRANSMIT (and even AMATERSE it) before GIMZIP, or run
> pax outside GIMZIP. But, I'd kind of like the GIMFAF.XML file...
>
> 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: Inspecting and extracting from /OS transportable files on other platforms?

[Gibney, Dave]

   I am still interested in a Windows (or Linux) tool that can understand PDS/E 
unload format.
   
But, here is another question. GIMZIP creates a GIMPAF.XML file describing 
the contents. I would like to process this file back into the GIMZIP package 
control tags. The purpose is to re-archive my system at it's current RSU state.
  I've never needed to really pay attention to XML or predecessors (I was last 
in the general arena with DCE 35 years ago)
  I am sure I can do this with ordinary editors (ISPF), or Rexx, probably even 
SORT. Or throw in some Excel. 
 Seems there might be an XML editor to make this easier.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gibney, Dave
> Sent: Thursday, January 28, 2021 2:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Inspecting and extracting from /OS transportable files on other
> platforms?
> 
>   Isn't that a long winder subject?
>In preparation for shutting down my z/OS 2.3 system, sometime this year, I
> am looking at options for unloading/storing both my z/OS files as well as my
> application data and infrastructure files.
>I thought of experimenting with GIMZIP. Which, for a PDS/E uses IEBCOPY
> to create a sequential  unload and then uses pax to create a
> S.dsname.pax.Z file containing the unload and a GIMFAF.XML
> descriptive file.
>I can download the .pax.Z file, and using 7zip decompress it.
>I looked on CBTTAPE.org and found the Xmit tools, and some terse/unterse
> options. And tools for .aws files.
>   I didn't find anything to process ot look at IEBCOPY unloaded files. Does 
> such
> a tool exist out there.
> 
>   I can of course TRANSMIT (and even AMATERSE it) before GIMZIP, or run
> pax outside GIMZIP. But, I'd kind of like the GIMFAF.XML file...
> 
> 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

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Farley, Peter x23353]

This seller also has the same item at a much lower (and more reasonable) price 
(ignore the USB 3.2 in the title, the specs says it is USB 3.1):

https://urldefense.com/v3/__https://www.amazon.com/Sabrent-Rocket-External-Aluminum-SB-2TB-NVME/dp/B07N15HD51__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!fg0k1gCTn9i0zgMznTvL5nuR3KPVk1Wie_rMvIJ9Cs35Uvls5rmD-MbubLptCivPZERQJg$

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Friday, January 29, 2021 10:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

It appears that Sabrent only sells the enclosure, you can then provide your own 
NVMe drive.  Amazon sells the enclosure for 49.99USD:

https://urldefense.com/v3/__https://www.sabrent.com/product/EC-WPNE/usb-3-2-rugged-waterproof-enclosure-ip67-for-m-2-nvme-ssds-ec-wpne/__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!fg0k1gCTn9i0zgMznTvL5nuR3KPVk1Wie_rMvIJ9Cs35Uvls5rmD-MbubLptCivtzWtzXQ$
 

Someone also is selling the enclosure with 2TB already installed but for more 
than 10x the cost of the enclosure:

https://urldefense.com/v3/__https://www.amazon.com/Sabrent-Rocket-External-Aluminum-SB-2TB-NVME/dp/B07N15HD51__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!fg0k1gCTn9i0zgMznTvL5nuR3KPVk1Wie_rMvIJ9Cs35Uvls5rmD-MbubLptCivPZERQJg$
 

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Friday, January 29, 2021 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

Hi Brian,
I tried to find the Sabrent device you referenced, but, did not find any that 
goes 16 Gb/sec.
Can you please supply a link to this?

Thanks and regards,
David

On 2021-01-29 03:36, Brian Westerman wrote:
> I think I would use transmit format for transporting things between systems, 
> it's easily transportable and common no matter where you go and is even 
> usable on a desktop PC.
>
> The other thing you can do (which I personally do) is simply FTP the PDS's 
> and sequential files directly to your PC (on a USB drive) in ASCII format.  I 
> do this weekly, rotating the encrypted USB drive that I have on my keychain 
> so that if it's broken or lost (that's why I encrypt), I can just get the 
> previous one.  My USB drives are pre-encrypted with Bitlocker so I really 
> don't have to do much (ever).  Previously I used to use those little USB 
> drives with the combination lock built in to them, but they are very 
> unreliable (and slow).  So now, when fast USB drives go on sale at Amazon, I 
> always buy several.  I like the sandisk 256GB ones because a) they are fast, 
> and more importantly b) they have a lifetime warranty.
>
> I have a batch file that I run to do this.  I plug in my USB drive and start 
> the batch file and go get a diet coke.
>
> I'm thinking about moving the process to one of the ruggedized external NVMe 
> drives.  I'm currently testing the new Sabrent 2TB one and it's VERY fast 
> (1Gb+/sec) and is small enough to easily fit in a pocket.  Plus being 
> ruggedized it's waterproof and drop-proof (so far).  The sandisk drives 
> typically load at around 140MB/s, but the Sabrent drive is almost 10 times 
> faster.
>
> The reason I want 2TB is that I would like to keep a whole Disaster recovery 
> system on that drive (DF/DSS unloaded virtual tapes).  At the faster speed, 
> it's actually not a bad process, I just need to work out the kinks a little 
> bit more so that I can automate it.
>
> Brian
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Seymour J Metz]

XMIT is not supported on all platforms. Other formats, e.g., tar, zip, are nigh 
near universal.

FTP of a PDS won't preserve all of the data. Does Info-Zip include all of the 
directory information? Also, FTP raises the issues of binary data and code 
pages.

BTW, what do you use to label your USB thumb drives?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Brian Westerman [brian_wester...@syzygyinc.com]
Sent: Friday, January 29, 2021 3:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

I think I would use transmit format for transporting things between systems, 
it's easily transportable and common no matter where you go and is even usable 
on a desktop PC.

The other thing you can do (which I personally do) is simply FTP the PDS's and 
sequential files directly to your PC (on a USB drive) in ASCII format.  I do 
this weekly, rotating the encrypted USB drive that I have on my keychain so 
that if it's broken or lost (that's why I encrypt), I can just get the previous 
one.  My USB drives are pre-encrypted with Bitlocker so I really don't have to 
do much (ever).  Previously I used to use those little USB drives with the 
combination lock built in to them, but they are very unreliable (and slow).  So 
now, when fast USB drives go on sale at Amazon, I always buy several.  I like 
the sandisk 256GB ones because a) they are fast, and more importantly b) they 
have a lifetime warranty.

I have a batch file that I run to do this.  I plug in my USB drive and start 
the batch file and go get a diet coke.

I'm thinking about moving the process to one of the ruggedized external NVMe 
drives.  I'm currently testing the new Sabrent 2TB one and it's VERY fast 
(1Gb+/sec) and is small enough to easily fit in a pocket.  Plus being 
ruggedized it's waterproof and drop-proof (so far).  The sandisk drives 
typically load at around 140MB/s, but the Sabrent drive is almost 10 times 
faster.

The reason I want 2TB is that I would like to keep a whole Disaster recovery 
system on that drive (DF/DSS unloaded virtual tapes).  At the faster speed, 
it's actually not a bad process, I just need to work out the kinks a little bit 
more so that I can automate it.

Brian

--
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: Inspecting and extracting from /OS transportable files on other platforms?

[Farley, Peter x23353]

It appears that Sabrent only sells the enclosure, you can then provide your own 
NVMe drive.  Amazon sells the enclosure for 49.99USD:

https://www.sabrent.com/product/EC-WPNE/usb-3-2-rugged-waterproof-enclosure-ip67-for-m-2-nvme-ssds-ec-wpne/

Someone also is selling the enclosure with 2TB already installed but for more 
than 10x the cost of the enclosure:

https://www.amazon.com/Sabrent-Rocket-External-Aluminum-SB-2TB-NVME/dp/B07N15HD51

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Friday, January 29, 2021 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inspecting and extracting from /OS transportable files on other 
platforms?

Hi Brian,
I tried to find the Sabrent device you referenced, but, did not find any that 
goes 16 Gb/sec.
Can you please supply a link to this?

Thanks and regards,
David

On 2021-01-29 03:36, Brian Westerman wrote:
> I think I would use transmit format for transporting things between systems, 
> it's easily transportable and common no matter where you go and is even 
> usable on a desktop PC.
>
> The other thing you can do (which I personally do) is simply FTP the PDS's 
> and sequential files directly to your PC (on a USB drive) in ASCII format.  I 
> do this weekly, rotating the encrypted USB drive that I have on my keychain 
> so that if it's broken or lost (that's why I encrypt), I can just get the 
> previous one.  My USB drives are pre-encrypted with Bitlocker so I really 
> don't have to do much (ever).  Previously I used to use those little USB 
> drives with the combination lock built in to them, but they are very 
> unreliable (and slow).  So now, when fast USB drives go on sale at Amazon, I 
> always buy several.  I like the sandisk 256GB ones because a) they are fast, 
> and more importantly b) they have a lifetime warranty.
>
> I have a batch file that I run to do this.  I plug in my USB drive and start 
> the batch file and go get a diet coke.
>
> I'm thinking about moving the process to one of the ruggedized external NVMe 
> drives.  I'm currently testing the new Sabrent 2TB one and it's VERY fast 
> (1Gb+/sec) and is small enough to easily fit in a pocket.  Plus being 
> ruggedized it's waterproof and drop-proof (so far).  The sandisk drives 
> typically load at around 140MB/s, but the Sabrent drive is almost 10 times 
> faster.
>
> The reason I want 2TB is that I would like to keep a whole Disaster recovery 
> system on that drive (DF/DSS unloaded virtual tapes).  At the faster speed, 
> it's actually not a bad process, I just need to work out the kinks a little 
> bit more so that I can automate it.
>
> Brian
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Inspecting and extracting from /OS transportable files on other platforms?

[David Spiegel]

Hi Brian,
I tried to find the Sabrent device you referenced, but, did not find any 
that goes 16 Gb/sec.

Can you please supply a link to this?

Thanks and regards,
David

On 2021-01-29 03:36, Brian Westerman wrote:

I think I would use transmit format for transporting things between systems, 
it's easily transportable and common no matter where you go and is even usable 
on a desktop PC.

The other thing you can do (which I personally do) is simply FTP the PDS's and 
sequential files directly to your PC (on a USB drive) in ASCII format.  I do 
this weekly, rotating the encrypted USB drive that I have on my keychain so 
that if it's broken or lost (that's why I encrypt), I can just get the previous 
one.  My USB drives are pre-encrypted with Bitlocker so I really don't have to 
do much (ever).  Previously I used to use those little USB drives with the 
combination lock built in to them, but they are very unreliable (and slow).  So 
now, when fast USB drives go on sale at Amazon, I always buy several.  I like 
the sandisk 256GB ones because a) they are fast, and more importantly b) they 
have a lifetime warranty.

I have a batch file that I run to do this.  I plug in my USB drive and start 
the batch file and go get a diet coke.

I'm thinking about moving the process to one of the ruggedized external NVMe 
drives.  I'm currently testing the new Sabrent 2TB one and it's VERY fast 
(1Gb+/sec) and is small enough to easily fit in a pocket.  Plus being 
ruggedized it's waterproof and drop-proof (so far).  The sandisk drives 
typically load at around 140MB/s, but the Sabrent drive is almost 10 times 
faster.

The reason I want 2TB is that I would like to keep a whole Disaster recovery 
system on that drive (DF/DSS unloaded virtual tapes).  At the faster speed, 
it's actually not a bad process, I just need to work out the kinks a little bit 
more so that I can automate it.

Brian

--
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

AW: Inspecting and extracting from /OS transportable files on other platforms?

[Kerstin Schwob]

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List  Im Auftrag von
Gibney, Dave
Gesendet: Donnerstag, 28. Januar 2021 23:32
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Inspecting and extracting from /OS transportable files on other
platforms?

  Isn't that a long winder subject?
   In preparation for shutting down my z/OS 2.3 system, sometime this year,
I am looking at options for unloading/storing both my z/OS files as well as
my application data and infrastructure files.
   I thought of experimenting with GIMZIP. Which, for a PDS/E uses IEBCOPY
to create a sequential  unload and then uses pax to create a
S.dsname.pax.Z file containing the unload and a GIMFAF.XML descriptive
file.
   I can download the .pax.Z file, and using 7zip decompress it.
   I looked on CBTTAPE.org and found the Xmit tools, and some terse/unterse
options. And tools for .aws files.
  I didn't find anything to process ot look at IEBCOPY unloaded files. Does
such a tool exist out there.

  I can of course TRANSMIT (and even AMATERSE it) before GIMZIP, or run pax
outside GIMZIP. But, I'd kind of like the GIMFAF.XML file...

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

Re: Inspecting and extracting from /OS transportable files on other platforms?

[Brian Westerman]

I think I would use transmit format for transporting things between systems, 
it's easily transportable and common no matter where you go and is even usable 
on a desktop PC.

The other thing you can do (which I personally do) is simply FTP the PDS's and 
sequential files directly to your PC (on a USB drive) in ASCII format.  I do 
this weekly, rotating the encrypted USB drive that I have on my keychain so 
that if it's broken or lost (that's why I encrypt), I can just get the previous 
one.  My USB drives are pre-encrypted with Bitlocker so I really don't have to 
do much (ever).  Previously I used to use those little USB drives with the 
combination lock built in to them, but they are very unreliable (and slow).  So 
now, when fast USB drives go on sale at Amazon, I always buy several.  I like 
the sandisk 256GB ones because a) they are fast, and more importantly b) they 
have a lifetime warranty.

I have a batch file that I run to do this.  I plug in my USB drive and start 
the batch file and go get a diet coke.

I'm thinking about moving the process to one of the ruggedized external NVMe 
drives.  I'm currently testing the new Sabrent 2TB one and it's VERY fast 
(1Gb+/sec) and is small enough to easily fit in a pocket.  Plus being 
ruggedized it's waterproof and drop-proof (so far).  The sandisk drives 
typically load at around 140MB/s, but the Sabrent drive is almost 10 times 
faster.

The reason I want 2TB is that I would like to keep a whole Disaster recovery 
system on that drive (DF/DSS unloaded virtual tapes).  At the faster speed, 
it's actually not a bad process, I just need to work out the kinks a little bit 
more so that I can automate it.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Inspecting and extracting from /OS transportable files on other platforms?

[Gibney, Dave]

  Isn't that a long winder subject?
   In preparation for shutting down my z/OS 2.3 system, sometime this year, I 
am looking at options for unloading/storing both my z/OS files as well as my 
application data and infrastructure files.
   I thought of experimenting with GIMZIP. Which, for a PDS/E uses IEBCOPY  to 
create a sequential  unload and then uses pax to create a S.dsname.pax.Z 
file containing the unload and a GIMFAF.XML descriptive file.
   I can download the .pax.Z file, and using 7zip decompress it.
   I looked on CBTTAPE.org and found the Xmit tools, and some terse/unterse 
options. And tools for .aws files.
  I didn't find anything to process ot look at IEBCOPY unloaded files. Does 
such a tool exist out there.

  I can of course TRANSMIT (and even AMATERSE it) before GIMZIP, or run pax 
outside GIMZIP. But, I'd kind of like the GIMFAF.XML file...

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