Re: A DADSM error while scratching a dsn.
Claude, These are in the DFSMSdfp Diagnosis Ref, under the appropriate DADSM function. For SCRATCH (Table 61), I get X'04' X'0B' ENQRET X'25' Verify DADSM SCRATCH request; enqueue on SYSDSN failed. hth, Richard Crook zOS Technical Specialist, (64 4) 576-9795 [EMAIL PROTECTED] "Richbourg, Claude" cc Sent by: IBM Mainframe Subject Discussion List A DADSM error while scratching a <[EMAIL PROTECTED] dsn. .EDU> 09/01/2008 02:34 PM Please respond to IBM Mainframe Discussion List <[EMAIL PROTECTED] .EDU> Sending again as I did not get a copy back from the list server. Hello all, This one stumps me for now and I need some help from the group. I am at z/OS 1.7 and in the process of cleaning up un-cataloged datasets on SMS managed volumes. This one that is holding tight is a non-vsam PO dataset. I usually run this JCL to delete them and it works fine: //STEP1 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //DISK DD DISP=SHR,UNIT=3390,VOL=SER=DASEFA //SYSIN DD * DELETE XXX.XX NVR FILE(DISK) /* The job gets a return code of '0', but the dataset is still there. A =3.4 display shows it, as well as an old IEHLIST job. In looking in the log or messages portion of the output from the delete job, I see this: IEC331I 042-006(040B0425),DELNVR1 ,STEP1 ,SCRT,IGG0CLH0 IEC331I VOL,DASEFA,NAME,XXX.X IEF142I DELNVR1 STEP1 - STEP WAS EXECUTED - COND CODE The fine manual says: RETURN CODE 42 Explanation: A DADSM error occurred on branch entry to DADSM back end. The DADSM error return data from the invoked sub-function (SFI) field is the value of the variable sfierror in message IEC331I. REASON CODE 6 Explanation: A DADSM SCRATCH error occurred on branch entry. No luck finding the '040B0425' meaning so far. Now the REAL question, how can I delete this dsn. Any and all responses are quite welcome. Regards, Claude Richbourg The contents of this e-mail are confidential. If you have received this communication by mistake, please advise the sender immediately and delete the message and any attachments. Nothing in this email designates an information system for the purposes of Section 11(a) of the New Zealand Electronic Transactions Act 2002. Westpac New Zealand Limited. -- 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
Re: Managing system logger data
Skip, We're still at 1.7, so I can't speak to SMF data yet. Operlog we just set up with a 5 day RETPD in the logstream def'n. After that, Logger manages the datasets and makes them disappear. Copying to DASD for archiving is still done from the Syslog, and happens the way it always has. Syslog and Operlog are independant. For Logrec, IFCEREP1 has a LASTRUN parm. This marks the logstream data at the place that it last read up to, so that next time it's run it knows to start from there. Richard Crook zOS Technical Specialist, IBM Global Technology Services (64 4) 576-9795 [EMAIL PROTECTED] Skip Robinson To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List <[EMAIL PROTECTED] Subject .EDU> Managing system logger data 01/02/2008 01:58 PM Please respond to IBM Mainframe Discussion List <[EMAIL PROTECTED] .EDU> After a decade of parallel sysplexing, I feel like a rookie with log streams. Up to now we've used system logger only for CICS and RRS. No operlog, no logrec. So we've never had to deal with the question of how to handle real data that needs to be kept (archived), massaged, and cleaned up. I'm now playing with the new SMF log stream available in z/OS 1.9. Not many folks have done this yet, but I think the problems are similar to other data-type log streams. Capturing the SMF data in a CF structure is easy. Logger writes the data out to data sets of the form 'hlq.IFASMF.xxx' where you choose the qualifier and tell the system what the name is. There is a new dump utility called IFASMFDL. Here's the problem. IFASMFDL does most of what IFASMFDP does (and more), but what it *doesn't* do is clear out the dumped SMF data. In other words, after archiving the contents of a log stream to a flat file, the now dumped records are still sitting just where they were. A subsequent run of IFASMFDL appears to pick up the same records all over again. The output file just gets bigger and bigger each time the dump is run. For those of you who use system logger for operlog or logrec, how do you clean up log streams so that you get one and only copy of all the data produced? . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] -- 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 The contents of this e-mail are confidential. If you have received this communication by mistake, please advise the sender immediately and delete the message and any attachments. Nothing in this email designates an information system for the purposes of Section 11(a) of the New Zealand Electronic Transactions Act 2002. Westpac New Zealand Limited. -- 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
