[EMAIL PROTECTED] wrote: >snippage > Today, however, I deleted in DSLIST a VSAM data set which was > migrated. To my surprise, DSLIST merely issued HDELETE which > deleted the VSAM data set with no ISRUVPC9 options dialog. > Now I'm perplexed: > > o If ISRUVPC9 is important, it should be issued for a migrated > data set or an unmigrated data set alike. > > o If ISRUVPC9 is unimportant, it should be eliminated and spare > us the distraction. > > o In the worst case, if information necessary to present ISRUVPC9 > is unavailable from a migrated data set, it must be recalled > in order to be able to present ISRUVPC9. > > Which is it? > > -- gil
My guess is option 2. Whatever (which ever?) it really is, my diagnosis it that it is just another symptom of the "tack on" that VSAM was to OS over 30 years ago. So, "normally" ISPF would just issue the SCRATCH and uncatalog for non-VSAM data sets, but for VSAM it issues a DELETE (because it knows SCRATCH is inappropriate). Migrated data sets (even VSAM ones) just appear as non-VSAM data sets in the catalog entry, so the extra panel is not invoked. At least these days newer smarts mean that an HDELETE is issued rather than a HRECALL (caused by the allocation) followed by a delete, which saves resources and time. Now, I might expect a higher degree of handshaking between IBM's data management plus ISPF and IBM's (DF)HSM, but that could preclude similar functionality with drop-in HSM replacement products from other vendors. Still, these days, what with IFAPRDxx and all, it should be possible to tell if it really is DFHSM, but by this time it is all a matter of business case and requirements, so it is not really worth it. Can VSAM data sets be allocated by ISPF option 3.2 yet? Or does that remain a future goal for the 21st century? (Or maybe it is not even that.... <g>) How much more information than: //NEWDS DD DSN=USERID.MYVSAM,DISP=(NEW,CATLG),UNIT=3390, // SPACE=(CYL,(3,2)),DSORG=VS,RECFM=FB,LRECL=320,KEYLEN=20,RKP=8 for example, should "the system" need to allocate a new VSAM data set? And in such a case, I don't even think it should matter if it is SMS-managed or not - it should all be handled as appropriate. So there. (Anyone know the smilie for poking out one's tongue?) A new VSAM data set allocated as above needs no pre-formatting, so any missing information required for actual processing should be suppliable (supplyable?) by a program at OPEN time. (No, I am not suggesting that DCB processing should be available for VSAM. Although, now that you mention it.... only joking.) And of course, come OPEN time, if insufficient data is present to enable correct processing then OPEN can always be abended. (I just hope there are some spare reason codes for S013 or whichever code would be chosen.) But I suppose it's all a bit too avant-garde. Now where did I put my future shock meds? Cheers, Greg ---------------------------------------------------------------------- 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
