Re: connect time in SMF TYPE-30
All of these fields are zero... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: elapsed time for DFSORT
Hi Dave, I have send the joblog to your..thanks for checking... On Tue, 20 Sep 2011 07:44:18 -0400, David Betten bet...@us.ibm.com wrote: There is not enough information here to determine why the job ran longer. Please send the complete joblog (not just the DFSORT messages) to dfs...@us.ibm.com and we can analyze for you. Also, be sure to send joblogs from multiple days so we can see the variance in elapsed time. Have a nice day, Dave Betten DFSORT Development, Performance Lead IBM Corporation email: bet...@us.ibm.com DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 09/20/2011 12:38:45 AM: [image removed] elapsed time for DFSORT Wang Xiaobing to: IBM-MAIN 09/20/2011 12:39 AM Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Please respond to IBM Mainframe Discussion List Hi, Here we have a performance problem on DFSORT. The same DFSORT job run on different day have different elapsed time, the data processed is almost same. Form the job log, we find the different is the longer job show DFSORT COULD NOT DYNAMICALLY ALLOCATE THE OPTIMAL WORK DATA SET SPACE, but our DFSORT job aloways use Hiperspace instead of work data set space. Here is DFSORT log: ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0 ,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256 ICE128I 0 OPTIONS: SIZE=57313801,MAXLIM=1048576,MINLIM=450560,EQUALS=N,LIST=Y,ERET=RC16 ,MSGDDN=SYSOUT ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO ,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA ,004),ABCODE=MSG ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109 ,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2 ICE131I 0 OPTIONS: TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64 ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE ,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX ,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=MAX ICE235I 0 OPTIONS: NULLOUT=RC0 ... ICE258I 0 DFSORT COULD NOT DYNAMICALLY ALLOCATE THE OPTIMAL WORK DATA SET SPACE ICE165I 0 TOTAL WORK DATA SET TRACKS ALLOCATED: 33480 , TRACKS USED: 0 ICE199I 0 MEMORY OBJECT STORAGE USED = 0M BYTES ICE180I 0 HIPERSPACE STORAGE USED = 11628272K BYTES ICE188I 0 DATA SPACE STORAGE USED = 0K BYTES ... And, we checked the SMF TYPE30 for these 2 job, it shows the total connect time(SMF30TCN) obviously increased..and the increased connect time(SMF30DCT ) is only used for SYSOUT DD.. My question is : Q1, why DFSORT COULD NOT DYNAMICALLY ALLOCATE THE OPTIMAL WORK DATA SET SPACE ? and how to correct it ? we do not change the JOB. Q2, In this case, we use Hiperspace instead of work data set space, ICE258I will impace the total connect time ? and cause the elapsed become longer ? Q3, What's the possible root reason increased the total connect time(SMF30TCN) ? Welcome any comments...TIA. WXB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
connect time in SMF TYPE-30
Hi, I check my batch job from SMF TYPE30, but confused on SMF30TCN and SMF30AIC. One jcl's SMF30TCN is 13 minutes but SMF30AIC is 9 seconds. I have reviewed the description from IBM manual z/OS MVS System Management Facilities, but still can not well understand what's the difference. I assumed SMF30TCN is the total CONNECT time for the used datasets and SMF30AIC is the average CONNECT time for the DASD, but not true it is correct...Would you pls help to give some more explanation for these 2 SMF field? TIA WXB.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
elapsed time for DFSORT
Hi, Here we have a performance problem on DFSORT. The same DFSORT job run on different day have different elapsed time, the data processed is almost same. Form the job log, we find the different is the longer job show DFSORT COULD NOT DYNAMICALLY ALLOCATE THE OPTIMAL WORK DATA SET SPACE, but our DFSORT job aloways use Hiperspace instead of work data set space. Here is DFSORT log: ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0 ,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256 ICE128I 0 OPTIONS: SIZE=57313801,MAXLIM=1048576,MINLIM=450560,EQUALS=N,LIST=Y,ERET=RC16 ,MSGDDN=SYSOUT ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO ,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=(SYSDA ,004),ABCODE=MSG ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109 ,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2 ICE131I 0 OPTIONS: TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64 ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE ,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=MAX ,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=MAX ICE235I 0 OPTIONS: NULLOUT=RC0 ... ICE258I 0 DFSORT COULD NOT DYNAMICALLY ALLOCATE THE OPTIMAL WORK DATA SET SPACE ICE165I 0 TOTAL WORK DATA SET TRACKS ALLOCATED: 33480 , TRACKS USED: 0 ICE199I 0 MEMORY OBJECT STORAGE USED = 0M BYTES ICE180I 0 HIPERSPACE STORAGE USED = 11628272K BYTES ICE188I 0 DATA SPACE STORAGE USED = 0K BYTES ... And, we checked the SMF TYPE30 for these 2 job, it shows the total connect time(SMF30TCN) obviously increased..and the increased connect time(SMF30DCT ) is only used for SYSOUT DD.. My question is : Q1, why DFSORT COULD NOT DYNAMICALLY ALLOCATE THE OPTIMAL WORK DATA SET SPACE ? and how to correct it ? we do not change the JOB. Q2, In this case, we use Hiperspace instead of work data set space, ICE258I will impace the total connect time ? and cause the elapsed become longer ? Q3, What's the possible root reason increased the total connect time(SMF30TCN) ? Welcome any comments...TIA. WXB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Real Storage Occupancy
Ted, I am worried about if the real storage used more and more it will cause paging issue..is it right ? thanks. Wang Xiaobing. On Fri, 1 Jul 2011 21:16:04 +, Ted MacNEIL eamacn...@yahoo.ca wrote: I find the problem is only real storage is increasing, virtual storage looks ok..can not understand why.. As I've tried to tell, this NOT a problem. Virtual storage is stable. There is no paging issue. So, what's the problem? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Real Storage Occupancy
Thanks, TED and Kees.. The system is no paging..but I would like to know the reason. The Virtual Storage usage of the task - JCSOL is no increasing during the days.. Do you think it is normal ? thanks. Wang Xiaobing On Thu, 30 Jun 2011 09:59:45 +0200, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: Ted MacNEIL eamacn...@yahoo.ca wrote in message news:1461128744-1309404933-cardhu_decombobulator_blackberry.rim.net- 197 9920784-@b12.c1.bise6.blackberry... The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Is it a problem? Are you paging? Occupancy varies depending on the workload mix. The SRM has a concept called lazy pages. In other words, if no other task needs the memory, the working set won't be trimmed. This is especially the case, these days, with large stores z/OS. - Ted MacNEIL Agreed, CS usage does not say much in general. However, in this case I assume that the task's virtual storage is also increasing during the days and that could/should be a better trigger to suspect problems in the task with its storage management. So, forget CS, check the Virtual Storage usage of the task. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Real Storage Occupancy
On Thu, 30 Jun 2011 19:54:44 -0500, Dale R. Smith dale- sm...@columbus.rr.com wrote: On Wed, 29 Jun 2011 22:22:24 -0500, Wang Xiaobing wang...@bayss.com wrote: Hi, We use a rexx program invoking ISFAFD to monitor the BATCH JOB, it is a long term running address space. The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Are you using stems in this long running REXX program? If you are and they are not explicitly being dropped, then that could account for some/all of the increase in storage use. REXX does not free storage used for stem elements even if you reuse the same stem name, so you need to drop the stem explicity to have REXX free the storage used. This normally isn't a problem as most REXX programs only run for a short time and storage is freed when the program ends. In your case, the program doesn't end, so no storage is freed. For example: Do Forever ...some process creates REXX stem (say line.) ...process elements in stem (line.) Drop line. /* Free Storage for Stem line. */ End /* Do Forever */ -- Dale R. Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Dale, Thanks for you reply. I checked the program, looks like almost all stems have been explicitly DROPed...Anyway I will review the program again to see there is no missing. I find the problem is only real storage is increasing, virtual storage looks ok..can not understand why.. Wang Xiaobing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Real Storage Occupancy
It's difficult to find the reason from the program logic...:-( Wang Xiaobing On Fri, 1 Jul 2011 23:15:04 +0800, Johnny Luo johnny.xingkui@gmail.com wrote: Virtual storage used by the task won't increase unless new GETMAIN is issued. After initial GETMAIN the working set will increase as the task begins to access more pages without FREEMAIN. These days, as real storage is usually not a problem, it's possible that those pages will reside in central storage for a long time. I guess that's what you saw. So in my opinition, you should check the program logic to find the possible cause: do you declare more variables as time goes by and never FREEMAIN the no-longer-used ones? My two cents. Best Regards, Johnny Luo On Fri, Jul 1, 2011 at 10:59 PM, Wang Xiaobing wang...@bayss.com wrote: Thanks, TED and Kees.. The system is no paging..but I would like to know the reason. The Virtual Storage usage of the task - JCSOL is no increasing during the days.. Do you think it is normal ? Â thanks. Wang Xiaobing On Thu, 30 Jun 2011 09:59:45 +0200, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: Ted MacNEIL eamacn...@yahoo.ca wrote in message news:1461128744-1309404933- cardhu_decombobulator_blackberry.rim.net- 197 9920784-@b12.c1.bise6.blackberry... The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Is it a problem? Are you paging? Occupancy varies depending on the workload mix. The SRM has a concept called lazy pages. In other words, if no other task needs the memory, the working set won't be trimmed. This is especially the case, these days, with large stores z/OS. - Ted MacNEIL Agreed, CS usage does not say much in general. However, in this case I assume that the task's virtual storage is also increasing during the days and that could/should be a better trigger to suspect problems in the task with its storage management. So, forget CS, check the Virtual Storage usage of the task. Kees. *** * For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 *** * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Real Storage Occupancy
Hi, We use a rexx program invoking ISFAFD to monitor the BATCH JOB, it is a long term running address space. The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Service - Frame Occupancy - -- Active Frames -- AUX PGIN ES Jobname C Class TOTAL ACTV IDLE WSET FIXEDDIV SLOTS RATE RATE JSCOLS STCLO 18681 0 18681 0 332 0 000 JSCOLS STCLO 19631 0 19631 0 336 0 000 JSCOLS STCLO 26165 0 26165 0 499 0 000 JSCOLS STCLO 26861 0 26861 0 505 0 000 JSCOLS STCLO 30867 4652 26214 31016 562 0 000 JSCOLS STCLO 31886 0 31886 0 567 0 000 JSCOLS STCLO 36857 8132 28725 36965 590 0 000 JSCOLS STCLO 38122 0 38122 0 591 0 000 JSCOLS STCLO 38890 5834 33056 38896 591 0 000 JSCOLS STCLO 42842 0 42842 0 630 0 000 JSCOLS STCLO 44092 7957 36136 44204 634 0 000 JSCOLS STCLO 45171 6817 38355 45445 638 0 000 JSCOLS STCLO 60919 0 60919 0 694 0 000 JSCOLS STCLO 62220 0 62220 0 699 0 000 JSCOLS STCLO 62976 0 62976 0 713 0 000 JSCOLS STCLO 67255 5388 61867 67346 808 0 000 JSCOLS STCLO 68429 12345 56085 68581 806 0 000 JSCOLS STCLO 68963 0 68963 0 809 0 000 JSCOLS STCLO 72832 19684 53149 72902 887 0 000 JSCOLS STCLO 74052 13361 60691 74228 891 0 000 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
OMEG monitoring after HyperSwap
Hi , Today, after a HyperSwap processing, all are looks well, but the OMEGAMON For Storage can not get the Storage Group sapce information, any one experience the same problem ? Thanks. Wang -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OMEG monitoring after HyperSwap
Restart OMEGAMON still get nothing...:-( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFRMM confusion
Maybe you can check the pack mode in the edit profile for your EDGRMM00? Best Regards! Wang Xiaobing ( 王晓兵 ) Bayshore Consulting and Service Co. Mobile: 1391-186-4622 Fax: 8610-6439-1582 MSN: bj...@163.com Skype: bbjbxd Also for grins I change the proc to use EDGRM01, which does not exist, to see what error that would cause. EDG0206E MEMBER EDGRMM01 NOT PRESENT IN SYS1.PARMLIB Not much doubt about that one. On Tue, Nov 16, 2010 at 4:44 PM, Mark Pace pacemainl...@gmail.com wrote: Yes, I copied my EDGRM00 from the old system to SYS1.PARMLIB on the new system. On Tue, Nov 16, 2010 at 4:36 PM, Dennis Trojak dennis.tro...@radioshack.com wrote: Have you got the right PARMLIB? No EDGRMM00 member in the SYS1.PARMLIB supplied by IBM. PARMLIB concatenation error maybe? Dennis -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Tuesday, November 16, 2010 2:08 PM To: IBM-MAIN@bama.ua.edu Subject: DFRMM confusion I'm migrating DFRMM from a z/OS 1.11 system to a z/OS 1.12 I just installed. When I start RMM I get the following. IEF403I DFRMM - STARTED - TIME=14.56.36 EDG0204I DFSMSRMM BEING INITIALIZED FROM MEMBER EDGRMM00 IN SYS1.PARMLIB EDG0104E DFSMSRMM SUBSYSTEM INITIALIZATION FAILED 04 EDG0107A ENTER SUFFIX OF INITIALIZATION MEMBER OR CANCEL EDG0104E says *Explanation:* Errors occurred during initialization of the DFSMSrmm subsystem. A diagnostic message precedes this one. I see no other diagnostic message. Anyone have an idea of where I might look for information? This taken me by surprise as I've migrated RMM 3 or 4 times and never had an issue. -- Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark D Pace Senior Systems Engineer Mainline Information Systems -- Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IEC145I 413-18 error
Hello list, We use DFRMM and STK VSM,when we run DB2 IMGCOPY job to backup data to tapelib, sometime there are IEC145I errors occured as following: IEC145I 413- 18,IFG0194A,IMGCOP3,IMGCOPY,SYSCOPY1,07CA,,BACKUPP1.SIT2CBS.IMG.TS XREF.MON2314.M0930 Would you pls advise..thanks a lot. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC145I 413-18 error
Luo, No any mount message... Attached pls find the job log...thanks.. 23.16.26 JOB98181 MONDAY,25 OCT 2010 23.16.26 JOB98181 IRR010I USERID BAAP033 IS ASSIGNED TO THIS JOB. 23.18.10 JOB98181 ICH70001I BAAP033 LAST ACCESS AT 23:18:04 ON MONDAY, OCTOBER 25, 2010 23.18.10 JOB98181 $HASP373 IMGCOP3 STARTED - INIT 2- CLASS D - SYS CT15 23.18.10 JOB98181 IEF403I IMGCOP3 - STARTED - TIME=23.18.10 23.18.10 JOB98181 - --TIMINGS (MINS.)-- PAGING COUNTS--- 23.18.10 JOB98181 -JOBNAME STEPNAME PROCSTEPRC EXCPCPU SRB CLOCK SERV PG PAGE SWAPVIO SWAPS STEPNO 23.18.10 JOB98181 -IMGCOP3 XREF GENCARD 00 45.00.00.00503 0 0 0 0 0 1 23.18.11 JOB98181 IEC145I 413- 18,IFG0194A,IMGCOP3,IMGCOPY,SYSCOPY1,07CA,,BACKUPP1.SIT2CBS.IMG.TS XREF.MON2314.M0930 23.18.11 JOB98181 IDI0001I Fault Analyzer V9R1M0 (UK54591 2010/02/24) invoked by IDIXDCAP using ADIBM.FA910.PARMLIB(IDICNF00) 23.18.12 JOB98181 IDI0078E Open of fault history file ADIBM.FA710.HIST failed because: MVS SAF check shows no Write access allowed 23.18.12 JOB98181 IDI0053I Fault history file entry suppressed due to: History file access error 23.18.12 JOB98181 IDI0002I Module IGC0001I offset X'14290': Abend S413- X'18' 23.18.12 JOB98181 IEA995I SYMPTOM DUMP OUTPUT 630 630 SYSTEM COMPLETION CODE=413 REASON CODE=0018 630 TIME=23.18.11 SEQ=03611 CPU= ASID=003A 630 PSW AT TIME OF ERROR 075C1000 80DC0292 ILC 2 INTC 0D 630NO ACTIVE MODULE FOUND 630NAME=UNKNOWN 630DATA AT PSW 00DC028C - 41003B9A 0A0D41F0 38C256F0 630AR/GR 0: 9BD72C66/00DC0574 1: /A4413000 630 2: /001C76A8 3: /00DBF9DA 630 4: 00010003/008C2410 5: /008C27A4 630 6: /008C274C 7: 00010003/008C27A4 630 8: /008C276C 9: /008C4E40 630 A: /00DC1414 B: /00DC2B1C 630 C: /80DC2BFC D: /008C26D0 630 E: /80DBFB12 F: /0018 630 END OF SYMPTOM DUMP 23.18.12 JOB98181 IEA848I DUMP SUPPRESSED - ABDUMP MAY NOT DUMP STORAGE FOR KEY 0-7 JOB IMGCOP3 23.18.12 JOB98181 IEA848I INSTALLATION PREDUMP EXIT, IDIXDCAP, SUPPRESSED THE DUMP REQUEST 23.18.13 JOB98181 IEF450I IMGCOP3 IMGCOPY XREF - ABEND=S413 U REASON=0018 634 634 TIME=23.18.13 23.18.13 JOB98181 -IMGCOP3 XREF IMGCOPY *S413 1999.00.00.05 13507 0 0 0 0 0 2 23.18.13 JOB98181 IEF404I IMGCOP3 - ENDED - TIME=23.18.13 23.18.13 JOB98181 -IMGCOP3 ENDED. NAME- TOTAL CPU TIME= .00 TOTAL ELAPSED TIME= .05 23.18.13 JOB98181 $HASP395 IMGCOP3 ENDED -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html 1 J E S 2 J O B L O G -- S Y S T E M C T 1 5 -- N O D E N 1 0 23.16.26 JOB98181 MONDAY,25 OCT 2010 23.16.26 JOB98181 IRR010I USERID BAAP033 IS ASSIGNED TO THIS JOB. 23.18.10 JOB98181 ICH70001I BAAP033 LAST ACCESS AT 23:18:04 ON MONDAY, OCTOBER 25, 2010 23.18.10 JOB98181 $HASP373 IMGCOP3 STARTED - INIT 2- CLASS D - SYS CT15 23.18.10 JOB98181 IEF403I IMGCOP3 - STARTED - TIME=23.18.10 23.18.10 JOB98181 - --TIMINGS (MINS.)--PAGING COUNTS--- 23.18.10 JOB98181 -JOBNAME STEPNAME PROCSTEPRC EXCPCPUSRB CLOCK SERV PG PAGE SWAPVIO SWAPS STEPNO 23.18.10 JOB98181 -IMGCOP3 XREF GENCARD 00 45.00.00 .00503 0 0 0 0 0 1 23.18.11 JOB98181 IEC145I 413-18,IFG0194A,IMGCOP3,IMGCOPY,SYSCOPY1,07CA,,BACKUPP1.SIT2CBS.IMG.TSXREF.MON2314.M0930 23.18.11 JOB98181 IDI0001I Fault Analyzer V9R1M0 (UK54591 2010/02/24) invoked by IDIXDCAP using ADIBM.FA910.PARMLIB(IDICNF00) 23.18.12 JOB98181 IDI0078E Open of fault history file ADIBM.FA710.HIST failed because: MVS SAF check shows no Write access allowed 23.18.12 JOB98181 IDI0053I Fault history file entry suppressed due to: History file access error 23.18.12 JOB98181 IDI0002I Module IGC0001I offset X'14290': Abend S413-X'18' 23.18.12 JOB98181 IEA995I SYMPTOM DUMP OUTPUT 630 630 SYSTEM COMPLETION CODE=413 REASON CODE=0018 630 TIME=23.18.11 SEQ=03611 CPU= ASID=003A 630 PSW AT TIME OF ERROR 075C1000
Re: IEC145I 413-18 error
Thanks Ted for you reply.. IEC145I 413-18 form IBM manual means: The specified data set was opened for input, but no volume serial number was specified on the DD statement. A recovery attempt request may be specified in the DCB ABEND exit routine. But the dataset is new create, the DD statement code as following: //SYSCOPY1 DD DSN=BACKUPP1.SIT2CBS.IMG.TSXREF.MON2314.M0930,VOL= (,,,255),UNIT=VTAPE,LABEL=(1,SL),RETPD=7,SPACE=(CYL, (100,300),RLSE),DISP=(NEW,CATLG,DELETE) I do not think the volume serial have to be specified... This error does not occured everytime when we submit the IMGCOPY jcl, after error, resubmit may ok. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC145I 413-18 error
Thanks, mace. I think the IDI0078E means the IEC145I 413-18 error occured, Fault Analyzer detected the error, and then try to record it in fault history file, but no Write access allowed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC145I 413-18 error
Thanks for reply.. That's what I can not understand with.. If you're just creating the dataset, why does Image Copy think it's for input? Wang Xiaobing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEC145I 413-18 error
Norbert, thanks. that is the reason.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DFRMM extract file
Hi, I'm facing a strange problem when extracting the data from DFRMM CDS, the job step show as following: //HSKP EXEC PGM=EDGHSKP, // PARM='EXPROC,RPTEXT,DATEFORM(J)' //SYSPRINT DD SYSOUT=* //MESSAGE DD DSN=RMM.HSKP.PLEXR1.MESSAGE(00),DISP=SHR //XREPTEXT DD DSN=RMM.HSKP.PLEXR1.XREPTEXT(00),DISP=SHR The Housekeeping job always return 0, wothout any error in the joblog. the output list as following. EDG2420I PHYSICAL VOLUMES READ =172 EDG2421I PHYSICAL VOLUMES UPDATED = 2 EDG2424I TOTAL VOLUMES, THIS RUN, SET PENDING RELEASE = 0 EDG2425I TOTAL VOLUMES RETURNED TO SCRATCH = 0 EDG2429I MAIN INVENTORY MANAGEMENT UPDATES HAVE COMPLETED SUCCESSFULLY EDG2307I INVENTORY MANAGEMENT TASK EXPROC COMPLETED SUCCESSFULLY EDG2307I INVENTORY MANAGEMENT TASK RPTEXT COMPLETED SUCCESSFULLY EDG6901I UTILITY EDGHSKP COMPLETED WITH RETURN CODE 0 Normally the XREPTEXT file should be 105000 tracks, but sometime this file is less than this size, by examine the report created form the BAD XREPTEXT file, there are some data missing. Tracks %Used XT Device RMM.HSKP.PLEXR1.XREPTEXT.G0530V00 105000 91 16 3390 RMM.HSKP.PLEXR1.XREPTEXT.G0531V00 9 94 16 3390 RMM.HSKP.PLEXR1.XREPTEXT.G0532V00 105000 91 12 3390 For the sample, G0531V00 is a BAD XREPTEXT file, and G0530V00 and G0532V00 are GOOD files. Any clue? Wang Xiaobing Senior SP Bayshore co. -- 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
