On Mon, 11 Nov 2013 18:04:40 -0500, Tony Harminc wrote: > >> //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... > Whatever their disagreeable motivation, you might have found it less curious if they had checked DEVICE TYPE first and bypassed the code issuing AMA527I and AMA573I entirely. But they probably wanted to display the (possibly alternate) DDNAME and DSNAME on the same line. They should have deferred the DEVICE TYPE check and AMA583E until and unless OPEN (and the first GET) failed.
"DSNAME: ...PATH=.SPECIFIED..." is issued by many utilities, often without an error, when confronted by a UNIX PATH. 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. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
