On Wed, 27 Feb 2008 10:12:12 -0700, Steve Comstock wrote: >> >> IEW2455W 9205 SYMBOL FOOBAR UNRESOLVED. NOCALL OR NEVERCALL SPECIFIED. >> >> ... after a brief diversion with an unintelligible error message when >> I tried to allocate SYSLMOD to UNIT=VIO,DSNTYPE=LIBRARY. M&C says: >> >> IGD17040I ERROR IN DADSM PROCESSING FOR DATA SET dsname HISTORIC RETURN >> CODE IS rc DIAGNOSTIC INFORMATION IS cde >> ... >> Application Programmer Response: Use the record in the logrec data set, >> the return code and the diagnostic information to determine the error. >> Use z/OS DFSMSdfp Diagnosis to determine the meaning of the DADSM >> historic return code and the DADSM diagnostic information. >> >> Sheesh! I'd prefer a "self-explanatory" message. E.g.: >> "requested DSNTYPE is incompatible with requested UNIT." This >> does not seem to be suitable action to expect of an "Application >> Programmer". And why, in the first place, shouldn't VIO support >> PDSE? VIO is just a RAM disk emulating a hard drive. The >> emulation is deficient. > >But Paul, you hijacked the OPs original concern. > No, I well addressed the OP's concern by verifying that as you suspected, the workaround would get RC=4. We don't know whether this meets the OP's requirements.
>If you had set up your job to allocate SYSLMOD to >a standard PDS, it would have run as I suggested: > I did, on the second try. >you get a warning message (like yours above) and >a RC of 4, but the module is stored into the >SYSLMOD dataset marked as executable. > Yes, and this should work even in the absence of PARM=LET. But, I'll confess to hijacking the thread. I'll try to make amends by changing the Subject: line. My chief objection to MVS, et. al., is its unnecessary complexity. I now have three examples in VIO alone. VIO should emulate real DASD using paging I/O. If the emulation were correct, many such problems wouldn't occur. o VIO used to be incompatible with IEBCOPY because IEBCOPY used EXCP V=R, not supported by VIO. This is incomplete emulation. Lately, this has been fixed, but I believe not by fixing the broken emulation, but by modifying IEBCOPY to detect VIO and avoid EXCP V=R in the VIO case, adding to the complexity of IEBCOPY while leaving VIO broken for other prospective users. o A few years ago, I reported the problem in OA10628 TRUNCATED RECORDS WITH VIO NOT REPORTED. The chatter in the PMR reported that [IDDWISVR?] processed an IOB with the Length Indicate flag set and RBC=0, but failed to report the error, resulting in IEBGENER's failing to issue IEB351I. But why should there have been a separate code path for VIO? If the emulation of real DASD were complete, the same code path could have processed the IOB for both, and both would be correct (or incorrect, but consistent, leading to earlier detection and correction of the error.) The APAR text leads me to suspect that the fix was not by eliminating the separate code path for VIO, but by modifying that separate code. o And, most recently, as above. Why should VIO be incompatible with PDSE? But, is VIO obsolete nowadays, leaving little motivation to clean it up? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
