Messages help us to Understand what your problem is. However, This link from 2014 on www.ibm.com indicates a TSO XMIT or PDS/E UNLOAD then AMATERSE the dataset. https://www-304.ibm.com/connections/blogs/SterlingMFT/entry/how_to_terse_a_pdse_library?lang=en_us
And from this link http://techsupport.services.ibm.com/390/trsmain.html (AMATERSE from z/OS V1.8 - don't know the level of your z/OS system) PARTITIONED dataset Extended (PDSE) datasets, VSAM Datasets, DA datasets, and ISAM datasets are not supported. And from z/OS V2.1 Link http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieav100/terse.htm partitioned data sets extended (PDSE) that do not contain program objects. Further Restrictions The following restrictions apply to AMATERSE: VSAM data sets and direct (DSORG=DA) data sets are not supported. Data sets with keys (KEYLEN) are not supported. A partitioned data set (PDS) compressed by AMATERSE on MVS™ cannot be unpacked by VM TERSE. This results in a 1007 or 1009 return code from VM TERSE. A PDS must be compressed to a DASD. Partitioned data sets extended (PDSE) containing program objects are not supported. AMATERSE handles data sets with a LRECL of more than 32K but less than 64K only when RECFM=VBS DASD data sets are processed. A data set with the FB record format can be packed and unpacked to a FBS data set. However, during the UNPACK operation, extending a non-empty output data set with DISP=MOD is not possible because this results in a FB data set. An error message is issued for this. AMATERSE does not support large block interface (LBI). So over time AMATERSE does support PDS/E just not those with Program Objects. Do you have Program Objects in the PDS/E you are trying to use? Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Paul Gilmartin > Sent: Tuesday, April 07, 2015 9:23 AM > To: [email protected] > Subject: Re: AMATERSE and PDSE ? (and IEBCOPY and SMP/E) > > On Tue, 7 Apr 2015 04:29:15 -0500, Norbert Friemel wrote: > > >On Tue, 7 Apr 2015 03:59:30 -0500, Juergen Kehr wrote: > > > >> ... I get a RC=40 during UNTERSE of a PDSE (Load) LIBRARY. ... > >> > > > >http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/iea2v1c2/17.4.1 > >"Partitioned data sets extended (PDSE) containing program objects are not > supported. " > > > For Lizette and Scott, what more is needed than a citation of a manual stating > that the operation is not supported? (But is the diagnostic message lucid?) > > I had expected AMATERSE to use IEBCOPY internally. But that would require > a > (large) workfile. So the programmer must IEBCOPY unload the PDSE, then > AMATERSE the PDSU, so that programmer assumes the onus of the workfile. > I believe TSO TRANSMIT uses IEBCOPY. IIRC, there have been reports of > TRANSMIT's failing for an underallocated workfile. (I also suspect that > IEBCOPY uses Program Management API to deal with Program Objects.) > > It's a pity that IEBCOPY can't use POSIX pipes for only its PDSU data sets. > That > would allow AMATERSE and TRANSMIT to use IEBCOPY with only trivial > workfiles, piping IEBCOPY PDSU directly into the utility. > > And SMP/E keeps its SMPNTS in IEBCOPY PDSU copied to UNIX .tar.Z files > which it must first unzip to SMPWKDIR, then copy to DSORG=PS, and finally > reload with IEBCOPY. Two (large) workfiles. IEBCOPY would do AMATERSE, > TRANSMIT and SMP/E a favor by supporting UNIX files (including pipes) as its > PDSU. > > (SMP/E also performs some gyrations to break up large concatenations of > SMPPTFIN data sets (I believe it DYNALLOCs directly from SMPWKDIR, not > requiring a copy to DSORG=PS.) Even that storage requirement could be > reduced by allocating SMPPTFIN to the output of a single POSIX pipe and > feeding that with the unzipped .tar.Z files one-by-one, deleting each before > unzipping the next. (But would that complicate error reporting?) > > IIRC, AMATERSE has a restriction that a PDS can not be PACKed directly to a > tape, but must first be PACKED to DASD (another (large) workfile), then > copied to tape. > I suspect this restriction arises from a need to POINT to a prologue block and > update it in place at the end of the operation. I know IEBCOPY PDSU also > contains a prologue. I wonder how IEBCOPY generates that in a single pass? > Does it perform a trial scan of the PDS? > > -- gil > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
