Re: IEBPTPCH questions
On 6/19/2012 7:02 AM, McKown, John wrote: AMATERSE ... With PARM=UNPACK, it restores the original dataset while dynamically allocating it (and can create it as well). AMATERSE can dynamically allocate the original data set? It can create it as well?? Is this behavior documented??? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ADRDSSU (was: IEBPTPCH questions)
In 5098408892869838.wa.paulgboulderaim@listserv.ua.edu, on 06/19/2012 at 09:22 AM, Paul Gilmartin paulgboul...@aim.com said: Would any responsible administrator unload a data set to an archive and grant read access to that archive to any user not having read access to the original data set? Have you never encountered an irresponsible administrator? Belt and surrenders. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ADRDSSU (was: IEBPTPCH questions)
In CAArMM9Tuco_MNbtQ5ZEg=uhy48ojk0gmk5ys-n3mvnvlxa2...@mail.gmail.com, on 06/19/2012 at 06:19 PM, Tony Harminc t...@harminc.net said: Well, then we're into the dangerous and powerful utilities auditor checklist again. IEFBR14 with the RC=0 fix? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBPTPCH questions
In 0096899832141155.wa.paulgboulderaim@listserv.ua.edu, on 06/19/2012 at 08:25 AM, Paul Gilmartin paulgboul...@aim.com said: An unfortunate restriction of TSO TRANSMIT is that its output is not suitable for an instream data set. Why does that matter? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBPTPCH questions
shmuel+...@patriot.net (Shmuel Metz , Seymour J.) writes: Are you sure you mean 407 and not 709? re: http://www.garlic.com/~lynn/2012i.html#12 IEBPTPCH the operators said 407 ... I'm repeated story as told me. I was complaining about the 360 sitting idle for a couple hrs. note that the 709 execution workload had been tape-to-tape, with 1401 tape-unit-record front end ... and tapes manually moved from 1401 drives to 709 drives. nobody would have been observing the 709 status since job start/end activity tended to be continuous. the 1401 ran front-end MPIO for tape-unit-record. the univ. got a 360/30 to replace 1401 as part of transition to replacing both with 360/67 running tss/360 (possibly a couple dozen univ. got 360/67 for tss/360 ... which never quiet materialized ... many spent their life running os/360 as straight 360/65). the 360/30 started out mostly in 1401 hardware emulation mode. I got (first) student job to re-implement MPIO in 360/30 ... I guess it was part of univ. gaining 360 experience ... since it could have continued to run 1401 hardware emulation. I got to design my own monitor, device drivers, storage management, interrupt handlers, error recovery, messaging, etc. It was eventually a box of (2000) cards ... with added assemble directive that would either assemble as stand-alone monitor or to run under os/360 with open/close, read/write DCB macros. The stand-line version took approx 30mins elapsed time to assemble on 360/30. The os/360 version took an hour to assemble ... the extra 30mins was elapsed time it took expanding DCB macros. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBPTPCH questions
Gil, Good points. I was also thinking that it might be useful to unload/reload a PDS or PDSE in tar format.Its a pity that the z/OS pax command doesn't support this. It would solve the transparency problem, and also would be good for platform interchange. Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, Jun 19, 2012 at 8:25 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Tue, 19 Jun 2012 07:20:24 -0500, Tom Marchant wrote: the CBT utility that outputs in IEBUPDTE format is really the best, but I was looking for something standard that I could wrap in a REXX script so that end-users would need to install anything else. It is not at all clear to me what you want to do. Have you considered using IEBGENER? What about TSO TRANSMIT, perhaps to a data set? An unfortunate restriction of TSO TRANSMIT is that its output is not suitable for an instream data set. While it's FB 80, there's no guarantee that '//' or any other digraph chosen for DLM= won't occur in the data. Gerhard's assertion that ']' is extremely unlikely doesn't satisfy me. But I've experimented with using uuencode on a tar-unloaded UNIX (USS) directory containing, among other things, a TRANSMIT-unloaded PDS. This fits safely in an instream data set, and can be created and reconstituted using only standard z/OS utilities. It all works, but Rube Goldberg. But I continue to believe that IEBUPDTE is not data-pattern safe. -- 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: IEBPTPCH questions
Why not use AMATERSE? It creates a FB/1024/1024 output dataset from a PDS, PDSE, PS, or VSAM dataset and compresses it as well. With PARM=UNPACK, it restores the original dataset while dynamically allocating it (and can create it as well). It does not support z/OS UNIX files as input or output. But you can pax the z/OS UNIX files to a PS dataset and then AMATERSE,PARM=PACK that. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@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-MAIN@listserv.ua.edu] On Behalf Of Kirk Wolf Sent: Tuesday, June 19, 2012 8:52 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: IEBPTPCH questions Gil, Good points. I was also thinking that it might be useful to unload/reload a PDS or PDSE in tar format.Its a pity that the z/OS pax command doesn't support this. It would solve the transparency problem, and also would be good for platform interchange. Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, Jun 19, 2012 at 8:25 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Tue, 19 Jun 2012 07:20:24 -0500, Tom Marchant wrote: the CBT utility that outputs in IEBUPDTE format is really the best, but I was looking for something standard that I could wrap in a REXX script so that end-users would need to install anything else. It is not at all clear to me what you want to do. Have you considered using IEBGENER? What about TSO TRANSMIT, perhaps to a data set? An unfortunate restriction of TSO TRANSMIT is that its output is not suitable for an instream data set. While it's FB 80, there's no guarantee that '//' or any other digraph chosen for DLM= won't occur in the data. Gerhard's assertion that ']' is extremely unlikely doesn't satisfy me. But I've experimented with using uuencode on a tar-unloaded UNIX (USS) directory containing, among other things, a TRANSMIT-unloaded PDS. This fits safely in an instream data set, and can be created and reconstituted using only standard z/OS utilities. It all works, but Rube Goldberg. But I continue to believe that IEBUPDTE is not data-pattern safe. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBPTPCH questions
On Tue, 19 Jun 2012 08:51:12 -0500, Tom Marchant wrote: I didn't see anything in the OP's query that required instream data. I'm sorry. I violated the cardinal rule of IBM-MAIN, that a followup never addresses matters not raised by the OP. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBPTPCH questions
On 6/18/2012 4:33 PM, Kirk Wolf wrote: I'll tried the FIELD=(80) thing, but no difference. The manual would lead you to believe that you always get some kind of control character (ASA or M), so that's probably how it works. It is, after all, just for printing or punching :-) I thought I had done this long ago (haven't used IEBPTPCH since early 70's). After reading the manual, I agree it seems to say it always adds CC. Should have tested it first. Sorry -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ADRDSSU (was: IEBPTPCH questions)
On 19 June 2012 08:12, Paul Gilmartin paulgboul...@aim.com wrote: Can an ADRDSSU archive be transmitted over the Internet? Sure, but since it comprises RECFM U records, it is likely to lose something in the process. I suppose AMATERSE solves most such problems. Can an ADRDSSU archive be tersed? Certainly. And even detersed... I don't see this done routinely; not, for example, on cbttape.org. I've seen it and used it, but I agree it's not something you encounter a lot. And when this topic arose here previously, there was a strong sentiment that I shouldn't even be allowed to use ADRDSSU; its use should be restricted to qualified data administrators who would have the needed privileges and skills. Well, then we're into the dangerous and powerful utilities auditor checklist again. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEBPTPCH questions
I haven't used this beast since last century I can't quite figure out a couple of things: 1) is there a way to PUNCH all members of an FB/80 source PDS and NOT prepend each record with an ASA or M control characters?I'm seeing the output as FBA/81 with the character V as the ASA control character, which doesn't make much sense. 2) Does anyone know if I specify DISP=SHR on SYSUT1 for a PDS if there is a data integrity problem if another job adds a member or even compresses the PDS? Thanks! Kirk Wolf Dovetailed Technologies http://dovetail.com PS Maybe there is another utility that efficiently gets a flattened version of a source PDS? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBPTPCH questions (slight change to previous reply)
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Kirk Wolf
Sent: Monday, June 18, 2012 12:57 PM
To: IBM-MAIN@listserv.ua.edu
Subject: IEBPTPCH questions
I haven't used this beast since last century I can't
quite figure out a
couple of things:
1) is there a way to PUNCH all members of an FB/80 source PDS and NOT
prepend each record with an ASA or M control characters?
I'm seeing the
output as FBA/81 with the character V as the ASA control
character, which
doesn't make much sense.
Not using IEBPTPCH.
2) Does anyone know if I specify DISP=SHR on SYSUT1 for a PDS
if there is a
data integrity problem if another job adds a member or even
compresses the
PDS?
I wouldn't do this.
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2u160/3.11?SHELF=DGT2BKA0.bksDT=20100615142149
quote
Attention: Do not compress a partitioned data set currently being used by more
than one user. If you do, the other users will see the data set as damaged,
even though it is not. If any of these other users update the partitioned data
set after you compress it, then their update will actually damage the
partitioned data set.
/quote
Thanks!
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
PS Maybe there is another utility that efficiently gets a flattened
version of a source PDS?
SAS has PROC SOURCE which I have used for this function.
http://cbttape.org/cbtdowns.htm, file #093 says that it sequentializes a PDS.
Not sure about ISPF LMPRINT
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ISPZSG80/2.45.5
Being a z/UNIX savvy person, perhaps you've heard of Co:Z Batch? GRIN/
//PROCLIB JCLLIB ORDER=(SYS3.COZ.V2R1M1.SAMPJCL)
//EX1 EXEC PROC=COZBATCH
//STDINDD *
set -x
directory=$TMP/seq.$$
mkdir ${directory}
cd ${directory}
cp //'some.dsn' .
for i in *;do cat $i;done|todsn 'DD:OUTPUT'
cd $TMP
rm -rf ${directory}
/*
//OUTPUT DD DISP=(NEW,CATLG),
// DSN=some.dsn.ps,DCB=(some.dsn,DSORG=PS),
// SPACE=(...)
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//CEEDUMP DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBPTPCH questions
On 6/18/2012 1:47 PM, John P Kalinich wrote: You can use the OFFLOAD program from CBT file 093 (http://www.cbttape.org) to create a sequential file (flat PDS) of all members. This is a good solution, but to answer your question, I think this will do it: PRINT TYPORG=PO,MAXFLDS=1 RECORD FIELD=(80) -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBPTPCH questions
Richard: There is also a utility on the CBT Tape that will create a IEBUPDTE stream. Very handy (at least for me) . Ed On Jun 18, 2012, at 2:10 PM, Richard Peurifoy wrote: On 6/18/2012 1:47 PM, John P Kalinich wrote: You can use the OFFLOAD program from CBT file 093 (http:// www.cbttape.org) to create a sequential file (flat PDS) of all members. This is a good solution, but to answer your question, I think this will do it: PRINT TYPORG=PO,MAXFLDS=1 RECORD FIELD=(80) -- Richard -- 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
