On 2013-11-07 19:11, Jon Perryman wrote: > This response feels like we're playing a game of Jeopardy (Alex, I'll take > datasets for $100). Did you actually contact IBM to ask them "what is a > dataset"? > In other words, should I ask them whether the information in "Using Data Sets" is correct?
> Did it have something to do with specifying a Unix file name in a DSN > parameter? > No. Do you not trust me to know better than that? If so, then the answer is that not all datasets have a dataset name. UNIX datasets have a file name (no DSN). SYSOUT datasets have SYSOUT attributes (no DSN). Subsystem datasets have subsystem information (no DSN). DSF and DFDSS use entire volumes as datasets which doesn't have a DSN for the DD. > > Can you give us some context? Why is this important or even relavent? > AMATERSE. I, like many others, find it easier to FTP a TERSEd archive to my desktop than to the z. And I have a directory NFS mounted to both the desktop and the z. So: //* SET PATH redacted. // SET ATTRS='RECFM=FB,LRECL=1024,BLKSIZE=30720' //* //* ========================================================= //UNPACK PROC //* //UNP EXEC PGM=AMATERSE,PARM=UNPACK //SYSPRINT DD SYSOUT=(,) //SYSUT2 DD UNIT=SYSALLDA,SPACE=(1000,1000) //* // PEND //* ========================================================= //* UNIX file only! //* //TESTC EXEC UNPACK //* //SYSUT1 DD PATHOPTS=ORDONLY,PATH='&PATH',&ATTRS ... fails with: ********************************* TOP OF DATA *********************************************** ** AMA572I STARTING TERSE DECODE UNPACK 20:08:51 11/07/2013 **** ** AMA527I INPUT - DDNAME : SYSUT1 DSNAME: ...PATH=.SPECIFIED... ** AMA583E INPUT DEVICE TYPE IS UNSUPPORTED ** AMA573I TERSE COMPLETE DECODE UNPACK 20:08:51 11/07/2013 **** ** AMA504I RETURN CODE: 32 ******************************** BOTTOM OF DATA ********************************************* Ironically, this: //* ========================================================= //* Temporary DS followed by UNIX file! //* //TESTB EXEC UNPACK //SYSUT1 DD UNIT=SYSALLDA,SPACE=(1,00000),&ATTRS,DSORG=PS // DD PATHOPTS=ORDONLY,PATH='&PATH',&ATTRS //* //* ========================================================= ... succeeds: ********************************* TOP OF DATA *********************************************** ** AMA572I STARTING TERSE DECODE UNPACK 20:08:50 11/07/2013 **** ** AMA527I INPUT - DDNAME : SYSUT1 DSNAME: SYS13311.T200847.RA000.TERSEHFS.R0165256 ** AMA528I OUTPUT - DDNAME : SYSUT2 DSNAME: SYS13311.T200847.RA000.TERSEHFS.R0165255 ** AMA555I THE VALUES ARE: BLKSIZE= 3120 LRECL=80 PACKTYPE=SPACK RECFM=FIXED ** AMA583I INPUT DATASET SIZE IN BYTES: 4096 OUTPUT DATASET SIZE IN BYTES: 15360 COMPRESSION RATIO: 26% ** AMA573I TERSE COMPLETE DECODE UNPACK 20:08:50 11/07/2013 **** ** AMA504I RETURN CODE: 0 ******************************** BOTTOM OF DATA ********************************************* The access method is quite capable of reading the UNIX file; merely AMATERSE hates UNIX and refuses to deal with it, but isn't smart enough to look beyond the first catenand. I haven't reported this specific case; I've come to expect, and become weary of IBM's stock answer; some form of "WAD; that's not a data set." The design is wrong: rather than anticipating an error that will never occur, the utility should simply OPEN and READ/GET, passing on any errors reported by the access method. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
