> //UNP EXEC PGM=AMATERSE,PARM=UNPACK [...] > ** 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
>It's curious looked at as a whole. The very existence of an AMA527I >suggests that PATH= is supported; it's an "I" message (nothing wrong), >and there must be code to discover that PATH= was specified. But the >AMA583E then stops the works. Did they intend to support UNIX files >properly, and then discover some case that fails in a subtle way that >led them to add the "device type" check? Who knows... TRSMAIN was an IBM internal tool which was written before the advent of PATH= in MVS. When TRSMAIN morphed into AMATERSE, there was no intention of adding PATH= support. AMATERSE does a DEVTYPE, and checks DVACLASS (in IHADVA mapping). If it is not x'80' (tape) or x'20' (DASD), then the AMA583E meessage is issued. I don't know what will be in DVACLASS for a Unix File System. > >I suspect that it's something DFSMS jams into some control block > >(TIOT?) where those utilities expect to find DSNAME when DFSMS > >has allocated a PATH instead. > > The TIOT indicates that there is a path, but I don't know how to get > the path name without going to the DSAB. The data set name in the AMA527I message comes from JFCBDSNM. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
