Copy z/OS USS pax format file to another z/OS system without FTP
Ray Overby
For example:
01) Copy USS file to some type of z/os file on source z/OS system.
02) IND$FILE source system z/os file to USB drive.
03) Plug USB drive into new machine that has TN3270 to target z/OS system
04) IND$FILE file on USB drive to target z/OS.
05) Copy z/os file to a USS directory on target z/os.
Notes:
01) FTP or similar products are not available on the target system.
02) INF$FILE is available for file transfer.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Mark Zelden
>Is there a way to copy a z/OS USS pax file to another z/OS system without using FTP and have the pax file still be usable when copy completed?
>
>For example:
>
>01) Copy USS file to some type of z/os file on source z/OS system.
>02) IND$FILE source system z/os file to USB drive.
>03) Plug USB drive into new machine that has TN3270 to target z/OS system
>04) IND$FILE file on USB drive to target z/OS.
>05) Copy z/os file to a USS directory on target z/os.
>
>Notes:
>
>01) FTP or similar products are not available on the target system.
>02) INF$FILE is available for file transfer.
>
Hi Ray,
I've never tried this, but how about OGET (binary) and IND$FILE (binary) then OPUT
on the reverse end. If that doesn't work, you could also try AMATERSE in-between the
OGET / OPUT and IND$FILE also and that should work.
I don't think AMATERSE supports z/OS unix files as input, but I haven't checked for
that since it replaced TRSMAIN.
Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:ma...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
McKown, John
pax -wvf "//'HLQ.DSN.PAX'" /my/sub/directory/*
But I'd pre-allocate HLQ.DSN.PAX. RECFM=FB,LRECL=1,BLKSIZE=27998 for 3390. Use IND$FILE in BINary mode (or ftp on source, if available). Now, why so weird a DCB? Because IND$FILE is not too good at file transfer and LRECL=1 will work fairly well even with IND$FILE. I don't think RECFM=U or RECFM=VB would work right, but I could be wrong. I am sure LRECL=1 and RECFM=FB will work, but inefficiently.
Why not just use a tape? The target system must be very weird if it does't have ftp or tapes. How do they do any maintenance? Or, no offense, are you simply trying to bypass some security measures that the target management has set up? Or, even worse, are you an auditor or security consultant trying to prove that the z/OS system is insecure? My paranoia is running rampant.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Ray Overby
reviewed the doc + tried several test cases.
Steve Comstock
> Is there a way to copy a z/OS USS pax file to another z/OS system without using
> FTP and have the pax file still be usable when copy completed?
>
> For example:
>
> 01) Copy USS file to some type of z/os file on source z/OS system.
> 02) IND$FILE source system z/os file to USB drive.
> 03) Plug USB drive into new machine that has TN3270 to target z/OS system
> 04) IND$FILE file on USB drive to target z/OS.
> 05) Copy z/os file to a USS directory on target z/os.
>
> Notes:
>
> 01) FTP or similar products are not available on the target system.
> 02) INF$FILE is available for file transfer.
You can pax a file directly into a member of a PDS; if you
have multiple files, each one becomes a separate member.
Then XMIT the PDS into a flat file, and download the flat
file in binary.
To reverse the process, upload the flat file in binary to
the target system; issues RECEIVE against the flat file; now
you have a PDS whose members are pax files. Under the shell
use pax -r to unwind each member into the unix file system.
Done it dozens of times.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
* Special promotion: 15% off on all DB2 training classes
scheduled by September 1, taught by year end 2011
* Check out our entire DB2 curriculum at:
http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm
McKown, John
Ray Overby
work (may be a limitation of my tn3270 support). I will check with the
tn3270 vendor shortly (I am using Tom B's VISTA). I think VISTA works
really well and really never have problems with it. I just have never
tried to IND$FILE from a USS directory before. Maybe there is some trick
that I am not aware of.
I did not know about pax's ability to read/write z/os datasets. That
sounds promising and I will research this more. Thanks. I was not sure
what the z/os file's DCB info should be as well.
FTP and tape are not currently available on the target z/OS system. I am
restricted from explaining why. I am not trying to bypass security, it
is just a strange setup that I currently don't have much control over. I
am sure we have all been there at one time or another....... I am trying
to apply vendor maintenance but have run into the problem of how to get
the pax file there with both hands tied behind my back.....
McKown, John
cd /some/sub/directory;pax -wvf "//'HLQ.SEQ.DSN.PAX'" *
to unload to HLQ.SEQ.DSN.PAX, use IND$FILE in BINary for that. On target IND$FILE upload in BINary with same DCB.
cd /some/target/directory;pax -rvf "//'HLQ.SEQ.DSN.PAX'"
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Ray Overby
> Sent: Thursday, August 18, 2011 9:50 AM
> To: IBM-...@bama.ua.edu
Paul Gilmartin
>My mistake on the "pax" writing to sequential. I thought I had done it before, but I don't seem to be able to get it to work now.
>
That should be APARable. I believe it's documented.
As IND$FILE becomes increasingly irrelevant, it's time to drive a
stake through its heart. Consider an interchange protocol for which
the data stream format documentation is unavailable!
-- gil
Kirk Wolf
"seqparms=" keyword also allows you to specify fopen() options, like
blksize, space, recfm.
I usually use blksize=27998,recfm=u for pax datasets.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Ray Overby
file from one z/os to another using John's suggestion. The only change I
made was to add "-x os390" option.
By default it appears that the z/OS file created was FB 80. I was able
to use IND$FILE binary transfer directly the created file. After I used
the pax command to copy it to the target system z/os uss directory the
file appeared to be useable (I used the pax command to extract data from
it). I will be using gimunzip later and hopefully I won't have any
problems.
All this work just to receive maintenance;-)
Staller, Allan
All this work just to receive maintenance;-)
Try this (I do this with some regularity):
1) Receive maintenance files to desktop (or other PC/*NIX dasd).
2) FTP in Binary GIMPAF.XSL, GIMPAF.XML
3) FTP in binary the contents of the SMPHOLD and SMPPTFIN directories
4) GIMUNZIP the files created IN Step 3.
5) RECEIVE, APPLy.....
HTH,
Paul Gilmartin
>
>Try this (I do this with some regularity):
>
>1) Receive maintenance files to desktop (or other PC/*NIX dasd).
>
>2) FTP in Binary GIMPAF.XSL, GIMPAF.XML
>3) FTP in binary the contents of the SMPHOLD and SMPPTFIN directories
>
>4) GIMUNZIP the files created IN Step 3.
>
>5) RECEIVE, APPLy.....
-- gil
Staller, Allan
required step.
Electronic delivery files are XML packaged. GIMUNZIP handles this .
DVD delivery files are sequential EBCDIC and directly usable without
translation. GIMUNZIP is not required in this case.
Hope this clarifies,
<snip>
>Try this (I do this with some regularity):
>
>1) Receive maintenance files to desktop (or other PC/*NIX dasd).
>
>2) FTP in Binary GIMPAF.XSL, GIMPAF.XML
>3) FTP in binary the contents of the SMPHOLD and SMPPTFIN directories
>
>4) GIMUNZIP the files created IN Step 3.
>
Step (4) seems superfluous.
>5) RECEIVE, APPLy.....
</snip>
Jerry Whitteridge
JCL:
//CREATE EXEC PGM=IEFBR14
//DD2 DD DISP=(NEW,CATLG),DSN=SFPRD1.CPT.ITRM.CICS.PAX(+1),
// UNIT=SYSDA,DATACLAS=DCDATAF,SPACE=(CYL,(2000,500))
//JS00010 EXEC PGM=BPXBATCH,PARM='SH /appl/itrm/pax_itrm_cics.sh'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//*
Shell script:
#! /bin/sh
pax -wzvf "//'SFPRD1.CPT.ITRM.CICS.PAX(0)'" /appl/itrm/cics/
Jerry Whitteridge
Design Engineer
Safeway Inc.
925 951 4184
If you feel in control
you just aren't going fast enough.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
> Behalf Of McKown, John
> Sent: Thursday, August 18, 2011 8:03 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: Copy z/OS USS pax format file to another z/OS system
> without FTP
>
"Email Firewall" made the following annotations.
------------------------------------------------------------------------------
Warning:
All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately.
==============================================================================
Shmuel Metz , Seymour J.
at 09:01 AM, Ray Overby <rayo...@COMCAST.NET> said:
>Is there a way to copy a z/OS USS pax file to another z/OS system
>without using FTP and have the pax file still be usable when copy
>completed?
If you have two z/OS systems in the same NJE network, then you can use
TSO XMIT and RECEIVE to copy the Unix files. A better option is to use
an NFS server for staging. By FTP do you specifically mean FTP, or are
you also excluding, e.g., IND$FILE, WSA?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Tony Harminc
> As IND$FILE becomes increasingly irrelevant, it's time to drive a
> stake through its heart. Consider an interchange protocol for which
> the data stream format documentation is unavailable!
Un-available? Typo, or did I miss the point?
So how about Kermit...?
Tony H.
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of Staller, Allan
>
> <snip>
> All this work just to receive maintenance;-)
> </snip>
>
> Try this (I do this with some regularity):
>
> 1) Receive maintenance files to desktop (or other PC/*NIX dasd).
>
> 2) FTP in Binary GIMPAF.XSL, GIMPAF.XML
> 3) FTP in binary the contents of the SMPHOLD and SMPPTFIN directories
>
> 4) GIMUNZIP the files created IN Step 3.
>
> 5) RECEIVE, APPLy.....
RECEIVE ORDER( ... ) works a treat here:
1. RECEIVE ORDER ...
2. APPLY CHECK ...
3. APPLY ...
<done>
-jc-
Paul Gilmartin
>On 18 August 2011 12:29, Paul Gilmartin wrote:
>
>> As IND$FILE becomes increasingly irrelevant, it's time to drive a
>> stake through its heart. �Consider an interchange protocol for which
>> the data stream format documentation is unavailable!
>
>Un-available? Typo, or did I miss the point?
>
Apologies; I didn't mean to recommend "[a] protocol for which ... documentation
is unavailable"; rather, "Ponder the risks in using an interchange protocol for
which the data stream format documentation is unavailable!" I understand
that IBM once published the specs of the IND$FILE data streams. That
publication has been withdrawn, and any specification of this widely used
legacy protocol is historic or by reverse engineering.
>So how about Kermit...?
>
So how about FTP? Or NFS? How many sites continue to use coax-attached
(like Irma or Attachmate) terminal emulators?
-- gil
>Tony H.
Ed Gould
For quite a long time I have complained about the lack of doc on IND$FILE and I gave up after a few years as hopeless. FTP is a reasonable alternative In my opinion. ESpecially since TCP is practically everywhere now days.
Ed