Slight OT: Linux/390 and standalone dump/restore

[Mike Ross]

I'd ask this on the Linux/390 list, but I got kicked off it a couple
of years ago for getting into one too many fights with Phil Payne
(don't worry, he got kicked off too!).

What is the current status of Linux/390 WRT its ability to grok CKD
volumes belonging to other mainframe OSes.

Scenario: I want to move a bunch of 3390 MVS-type CCKD volumes on a
Hercules system to a Real Mainframe.

Option 1: run ADRDSSU, take standalone backups to SCSI 4mm DAT on the
Herc box, IPL DFDSS from DAT & restore from 4mm DAT on Real Mainframe
(the only tape device on the Real Mainframe). This could be a PITA.

Option 2: IPL Linux on Herc & on the Real Mainframe, establish TCP/IP
connection, and somehow (hazy bit here) use Linux facilities to
transmit the MVS volumes from Herc CCKD 3390 to 'real' 3390 volumes
on the Real Mainframe. In an FTP-like manner.

Does Linux/390 have any facilities that would help in this regard?
Only interested in whole volumes, not datasets.

Cheers

Mike






------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->

[Adam Thornton]

Post by Mike Ross
I'd ask this on the Linux/390 list, but I got kicked off it a couple
of years ago for getting into one too many fights with Phil Payne
(don't worry, he got kicked off too!).
What is the current status of Linux/390 WRT its ability to grok CKD
volumes belonging to other mainframe OSes.
Scenario: I want to move a bunch of 3390 MVS-type CCKD volumes on a
Hercules system to a Real Mainframe.
Option 1: run ADRDSSU, take standalone backups to SCSI 4mm DAT on the
Herc box, IPL DFDSS from DAT & restore from 4mm DAT on Real Mainframe
(the only tape device on the Real Mainframe). This could be a PITA.

Uh, doesn't PIPE exist for TSO? If so, create an AWSTAPE file, and then
use the DEBLOCK AWS stage and PIPEDDR to get it back. This is how I'd
do it.

Post by Mike Ross
Does Linux/390 have any facilities that would help in this regard?
Only interested in whole volumes, not datasets.

I guess you could dd if=/dev/dasdb (that is, the whole-volume device)
bs=tracksize to a network socket, and then write the tracks on the far
end. Dave Jones and I wrote something similar for VM once, which read a
track, spat it across the network, summed it, and went to the next if
the sums matched.

Adam



------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->

[Ian S Worthington]

Unfortunatly PIPELINES has *still* not got rolled into TSO :( One day, one
day... (How long did it take REXX?)

So unless you have John Hartmann's PRPQ on your system, or an obselete (?) and
little known product called Hyberbatch (? iirc), you don't have PIPE. There
*is* a lite version (no branching) shipped with NetView but I never
investigated if that is useful enough to do anything other than automation
tasks.

ian
...

------ Original Message ------
Received: Mon, 01 Nov 2004 10:48:38 PM EST
From: Adam Thornton <adam-l+/***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Subject: Re: [hercules-390] Slight OT: Linux/390 and standalone dump/restore

Post by Adam Thornton

Post by Mike Ross
I'd ask this on the Linux/390 list, but I got kicked off it a couple
of years ago for getting into one too many fights with Phil Payne
(don't worry, he got kicked off too!).
What is the current status of Linux/390 WRT its ability to grok CKD
volumes belonging to other mainframe OSes.
Scenario: I want to move a bunch of 3390 MVS-type CCKD volumes on a
Hercules system to a Real Mainframe.
Option 1: run ADRDSSU, take standalone backups to SCSI 4mm DAT on the
Herc box, IPL DFDSS from DAT & restore from 4mm DAT on Real Mainframe
(the only tape device on the Real Mainframe). This could be a PITA.

Uh, doesn't PIPE exist for TSO? If so, create an AWSTAPE file, and then
use the DEBLOCK AWS stage and PIPEDDR to get it back. This is how I'd
do it.

Post by Mike Ross
Does Linux/390 have any facilities that would help in this regard?
Only interested in whole volumes, not datasets.

I guess you could dd if=/dev/dasdb (that is, the whole-volume device)
bs=tracksize to a network socket, and then write the tracks on the far
end. Dave Jones and I wrote something similar for VM once, which read a
track, spat it across the network, summed it, and went to the next if
the sums matched.
Adam
http://groups.yahoo.com/group/hercules-390
http://www.conmicro.cx/hercules
Yahoo! Groups Links

Ian S Worthington
...




------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->

[Mike Ross]

Post by Ian S Worthington
Unfortunatly PIPELINES has *still* not got rolled into TSO :( One day, one
day... (How long did it take REXX?)
So unless you have John Hartmann's PRPQ on your system, or an

obselete (?) and

Post by Ian S Worthington
little known product called Hyberbatch (? iirc), you don't have PIPE. There
*is* a lite version (no branching) shipped with NetView but I never
investigated if that is useful enough to do anything other than automation
tasks.
ian
...
------ Original Message ------
Received: Mon, 01 Nov 2004 10:48:38 PM EST

<snip>

Post by Ian S Worthington

Post by Adam Thornton
Uh, doesn't PIPE exist for TSO? If so, create an AWSTAPE file, and then
use the DEBLOCK AWS stage and PIPEDDR to get it back. This is how I'd
do it.

Post by Mike Ross
Does Linux/390 have any facilities that would help in this

regard?

Post by Ian S Worthington

Post by Adam Thornton

Post by Mike Ross
Only interested in whole volumes, not datasets.

I guess you could dd if=/dev/dasdb (that is, the whole-volume device)
bs=tracksize to a network socket, and then write the tracks on the far
end. Dave Jones and I wrote something similar for VM once, which read a
track, spat it across the network, summed it, and went to the next if
the sums matched.

OK, you're both talking about PIPE and TSO... I'm confused: I haven't
done much with Linux/390 in a while; are you saying that TSO has been
ported to Linux? If not, I don't see how it helps my stated aim of
using Linux to move MVS volumes between systems...

Would it be hopelessly naive to suggest that Linux might have the
ability to simply move raw devices using FTP? - it treats everything
as a file after all...

e.g. ftp {from} /dev/dasdx (the raw MVS 3390 volume) {to} /dev/dasdx
(a new file on the Real Mainframe)?

(/dev/dasdx being an MVS volume, nothing to do with Linux, containing
MVS PDSes etc. - doesn't matter whether or not Linux can mount the
volume or access the data on it, so long as it can move the raw
device file (i.e. the whole volume) from one place to another)

I've no idea whether or not Linux/390 can even *see* MVS 3390 volumes
in this fashion... something I've never considered before.

Mike





------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->

[Adam Thornton]

Post by Mike Ross
OK, you're both talking about PIPE and TSO... I'm confused: I haven't
done much with Linux/390 in a while; are you saying that TSO has been
ported to Linux? If not, I don't see how it helps my stated aim of
using Linux to move MVS volumes between systems...

Because it would give you a way to package the tracks on the "real
system" side.

Post by Mike Ross
Would it be hopelessly naive to suggest that Linux might have the
ability to simply move raw devices using FTP? - it treats everything
as a file after all...
e.g. ftp {from} /dev/dasdx (the raw MVS 3390 volume) {to} /dev/dasdx
(a new file on the Real Mainframe)?

That might work. I wouldn't be surprised if it did. I also would not
be surprised if it did not. What the hell, give it a try.

Post by Mike Ross
(/dev/dasdx being an MVS volume, nothing to do with Linux, containing
MVS PDSes etc. - doesn't matter whether or not Linux can mount the
volume or access the data on it, so long as it can move the raw
device file (i.e. the whole volume) from one place to another)
I've no idea whether or not Linux/390 can even *see* MVS 3390 volumes
in this fashion... something I've never considered before.

Sure, as long as the device is online to Linux. Are you in a VM
environment or an LPAR? You may need to

echo add device range=dasdrange > /proc/dasd/devices

But then you should be fine. Let us know whether it works.

Adam



------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->

[mikeprotts]

Post by Adam Thornton

Post by Mike Ross
Would it be hopelessly naive to suggest that Linux might have the
ability to simply move raw devices using FTP? - it treats everything
as a file after all...
e.g. ftp {from} /dev/dasdx (the raw MVS 3390 volume) {to} /dev/dasdx
(a new file on the Real Mainframe)?

That might work. I wouldn't be surprised if it did. I also would not
be surprised if it did not. What the hell, give it a try.

**Warning - I've not tested this **

You would probably be better off with dd.

If you have a large spare space on a file system(could be nfs mounted)
you would use:

dd if=/dev/dasdx of=/mnt/verybigspace/dasdx.ckd

The file dasdx.ckd would now be a disk image. This could then be
copied back to a real device with the if and of reversed, eg:

dd if=/mnt/verybigspace/dasdx.ckd of=/dev/dasdy

Of course you could pipe this via rexec so the intermediate file would
not be needed. I've never tried, but at a guess it would be something
like:
rexec HOST dd of=/dev/dasdy < dd if=/dev/dasdx

Cheers
Mike





------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->

[somitcw]

--- In hercules-390-***@public.gmane.org, "Mike Ross"
<***@a...> wrote:
- - - snipped - - -

Post by Mike Ross
Scenario: I want to move a bunch of 3390 MVS-type
CCKD volumes on a Hercules system to a Real Mainframe.

- - - snipped - - -

1. ftp the cckd hercules files binary to zOS.
Run CCKDLOAD

2. Copy dasd volumes to .aws tape images with
ddr or adrdssu. Best to block below 32KB.
Restore on big iron.





------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->

[Mike Ross]

Post by somitcw
- - - snipped - - -

Post by Mike Ross
Scenario: I want to move a bunch of 3390 MVS-type
CCKD volumes on a Hercules system to a Real Mainframe.

- - - snipped - - -
1. ftp the cckd hercules files binary to zOS.
Run CCKDLOAD

I'll have to read up CCKDLOAD... I would ftp the CCKD images to
Linux/390 on the big iron, not zOS - the only OS I can bring up on
the big iron with TCPIP support is Linux. Don't have zOS on it!! I
presume CCKDLOAD is a standalone application which loads a Herc CCKD
file to a real 3390 device? Like CCKDDUMP in reverse? Just googled
and it returns zero results for 'CCKDLOAD'...

Post by somitcw
2. Copy dasd volumes to .aws tape images with
ddr or adrdssu. Best to block below 32KB.
Restore on big iron.

And ftp the .aws images from Herc box to Linux/390 on big iron? That
would also work... same principles at work.

Both ideas avoid messing about with a bunch of physical tapes, which
is the main object of the exercise. I guess CCKDLOAD provides
the 'manipulate CCKD images under Linux' functionality I was looking
for - it presumably doesn't care if the CCKD contains Linux or MVS or
anything else.. Thanks!

Mike







------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->

[g***@public.gmane.org]

Post by Mike Ross
I'll have to read up CCKDLOAD... I would ftp the CCKD images to
Linux/390 on the big iron, not zOS - the only OS I can bring up on
the big iron with TCPIP support is Linux. Don't have zOS on it!! I
presume CCKDLOAD is a standalone application which loads a Herc
CCKD
file to a real 3390 device? Like CCKDDUMP in reverse? Just googled
and it returns zero results for 'CCKDLOAD'...

cckdload, like cckddump, only works on mvs. It's included with the cckddump package in the files area.

I've spent a few minutes looking at what would have to be done to write a program on linux/390 to restore a cckd file. Doesn't look impossible but not exactly trivial either.

dasdfmt.c simply does ioctl(..., BIODASDFMT, ...);
dasd_format is called in kernel space which in turn calls dasd_eckd_format_device (both in dasd_ioctl.c). dasd_eckd_format_device builds the channel program and dasd_format schedules the channel program and waits for it to complete.

So, we would need a module running in kernel space doing something similar to the two routines above.

Greg



------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->

[Mike Ross]

Post by g***@public.gmane.org

Post by Mike Ross
I'll have to read up CCKDLOAD... I would ftp the CCKD images to
Linux/390 on the big iron, not zOS - the only OS I can bring up on
the big iron with TCPIP support is Linux. Don't have zOS on it!! I
presume CCKDLOAD is a standalone application which loads a Herc
CCKD
file to a real 3390 device? Like CCKDDUMP in reverse? Just

googled

Post by g***@public.gmane.org

Post by Mike Ross
and it returns zero results for 'CCKDLOAD'...

cckdload, like cckddump, only works on mvs. It's included with the

cckddump package in the files area.

Post by g***@public.gmane.org
I've spent a few minutes looking at what would have to be done to

write a program on linux/390 to restore a cckd file. Doesn't look
impossible but not exactly trivial either.

Ah ok - means I will have to fix TCPIP on the OS/390 2.4 that was
bundled with the Real Iron, get CCKDLOAD working on it, and bang away
at my minimal JCL 'skills' to get the job done. Guess why I was
attracted to the Linux -> Linux route? :-)

CCKDLOAD appears to have been written in *assembler*, ye gods and
little fishes... would it have been so hard to make it portable?

Mike






------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->

[Ronald Tatum]

Mike et al,
Is the CCKDLOAD you're apparently looking at an IBM product? I'd be
curious to know if the title lines in the assembler listing perhaps show
PL/S, BSL or some other acronym indicating the original source language used
to create the program, or if the title does in fact indicate the source was
"real" assembler ...
rant/
If IBM s going to continue to use their internal higher-level systems
software-writing language to create supposedly understandable/maintainable
code, why can't they release the compiler for it? It actuallly antedates
OS/360 MVT. Besides that, C or C++ seem to be at least as good for writing
that sort of S/W, as the existence and success of Hercules proves very well
..
/rant
Regards,
Ron Tatum
----- Original Message -----
From: "Mike Ross" <abaddon-***@public.gmane.org>
To: <hercules-390-***@public.gmane.org>
Sent: Tuesday, November 02, 2004 11:34 AM
Subject: [hercules-390] Re: Slight OT: Linux/390 and standalone dump/restore

Post by Mike Ross

Post by g***@public.gmane.org

Post by Mike Ross
I'll have to read up CCKDLOAD... I would ftp the CCKD images to
Linux/390 on the big iron, not zOS - the only OS I can bring up

on

Post by g***@public.gmane.org

Post by Mike Ross
the big iron with TCPIP support is Linux. Don't have zOS on it!!

I

Post by g***@public.gmane.org

Post by Mike Ross
presume CCKDLOAD is a standalone application which loads a Herc
CCKD
file to a real 3390 device? Like CCKDDUMP in reverse? Just

googled

Post by g***@public.gmane.org

Post by Mike Ross
and it returns zero results for 'CCKDLOAD'...

cckdload, like cckddump, only works on mvs. It's included with the

cckddump package in the files area.

Post by g***@public.gmane.org
I've spent a few minutes looking at what would have to be done to

write a program on linux/390 to restore a cckd file. Doesn't look
impossible but not exactly trivial either.
Ah ok - means I will have to fix TCPIP on the OS/390 2.4 that was
bundled with the Real Iron, get CCKDLOAD working on it, and bang away
at my minimal JCL 'skills' to get the job done. Guess why I was
attracted to the Linux -> Linux route? :-)
CCKDLOAD appears to have been written in *assembler*, ye gods and
little fishes... would it have been so hard to make it portable?
Mike
http://groups.yahoo.com/group/hercules-390
http://www.conmicro.cx/hercules
Yahoo! Groups Links

------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->

[Greg Smith]

Post by Ronald Tatum
Mike et al,
Is the CCKDLOAD you're apparently looking at an IBM product? I'd be
curious to know if the title lines in the assembler listing perhaps show
PL/S, BSL or some other acronym indicating the original source language used
to create the program, or if the title does in fact indicate the source was
"real" assembler ...
rant/
If IBM s going to continue to use their internal higher-level systems
software-writing language to create supposedly understandable/maintainable
code, why can't they release the compiler for it? It actuallly antedates
OS/360 MVT. Besides that, C or C++ seem to be at least as good for writing
that sort of S/W, as the existence and success of Hercules proves very well
..
/rant
Regards,
Ron Tatum

Hi Ron,

Nah, cckdload is entirely my creation. AFAIK, I invented the term `cckd'.
If not, at least I came up with it independently.

Actually cckdload is derived from offlindr, which I also wrote (and which
should be found from a google search). Offlindr can dump and restore from
mvs an offline eckd dasd to/from a qsam file. The restore part was copied
for cckdload, along with the normal cckd stuff.

As you might imagine, writing to an offline volume on mvs is not exactly
something you find in Data Management Macros nor is writing data to
something that is not a dataset. DEBs have to be created, channel programs
constructed, asynchronous i/o's scheduled (cckdload uses two IOBs so
while one channel program is being executed the next can be constructed).
Not exactly something you would find in SPEC1170. If you have doubts
about an mvs program being able to write to an offline dasd, consider
ickdsf.
The unit just has to be physically available.

As far as writing a similar program for linux/390, things do not get any
simpler. `dd' is simply not going to work.

CKD stands for count-key-data. On a typical CKD track there is a home
address (HA), record 0 (R0) and user records R1 up to R255. Each record
(not to be confused with the mvs concept of a record) contains an 8 byte
count, a 0 to 255 byte key, and a 0 .. 65535 piece of data. However, the
records on a track cannot exceed the track capacity. The track capacity
depends on a rather complicated formula involving the number of records,
key sizes and data sizes.

Anyway, as far as mvs is concerned, each track is potentially a blank slate
that can be formatted to the programmer's whim.

Back to `dd'. As far as linux/390 is concerned (or at least dasd_eckd_mod)
each track image already contains `x' number of blocks `y' bytes long. This
is why you have to execute dasdfmt before being able to use a ckd dasd
unit. Count, key and data fields are not going to be reformatted by the
eckd
device driver. cckdload wants to write count, key and data fields.
`dd' is not
going to write anything but data.

So, for a cckdload type function to work on linux/390, we need code in
kernel space that builds it's own channel programs and reformats each track
being loaded.

Greg






------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/W4wwlB/TM
--------------------------------------------------------------------~->