|
View previous topic :: View next topic
|
| Author |
Message |
liminsh
New User
Joined: 16 Jul 2012
Posts: 6
Location: 中国
|
|
|
|
I got a requirement to write a job which can do the continuously I/O for several hours. so, I wrote a job which will do an infinite loop to create/write/read/delete a data set with a TIME=* to terminate the job in * Mins.
The job like below.
//* CREATE TARGET DATASETS
//MYJOB JOB MSGLEVEL=(0,0),REGION=4M,NOTIFY=&SYSUID,TIME=480
//STEP1 EXEC PGM=IEFBR14,COND=(0,NE)
//.....
//*
//* CREATE OUTPUT RECORDS FROM UTILITY CONTROL STATEMENTS
//STEP2 EXEC PGM=IEBDG,COND=(0,NE)
//...
//* READ DATA SET TO OUTPUT
//STEP3 EXEC PGM=ADRDSSU
//...
//* DELETE THE DATA SET
//STEP4 EXEC PGM=IDCAMS
//...
//* SUBMIT THE JOB MYJOB
//IF (STEP4.RC = 0) THEN
//STEP5 EXEC PGM=IKJEFT01,PARM='SUBMIT ''&SYSUID..JCL(MYJOB)'''
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//ENDIF
/*
The job submit itself to do a infinite loop.The Time=480 will terminate this job in 8hours.
But ,I got a problem with the spool. After this job be execute, 'SPOOL VOLUMES ARE FULL' error happened.
I tried to print the job sysout to a dataset using the below jcl
//SYSOUT DD DSN=***,
// DISP=(NEW,CATLG,DELETE),
// UNIT=3390,VOL=SER=SNDBXB,
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=800),AVGREC=U,
// SPACE=(80,6580)
but ,the sysout still be printed to the spool ,not to the dataset(I can browse the output logs using 'S' on sdsf).
can anyone give me some advice for it?
Can I delete the job output using the PGM=SDSF?
Thanks in advance! |
|
| Back to top |
|
 |
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Quote: |
can anyone give me some advice for it?
|
Yes, give the necessary information. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
Perhaps a career outside of IT may be of benefit to both yourself and the rest of us, as it abundantly clear that you have absolutely no idea of what you are doing.
Please explain the background to this rather inane requirement, why does it need to be done.
Have you ever read a JCL manual in your life. Do you not know that the submitted job is totally independant of the submitting job, therefor the TIME= parameter for the submitted job is started from zero for each and every job that you submit.
Causing the spool to fill up may crash the system, and your career with it. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| The job submit itself to do a infinite loop.The Time=480 will terminate this job in 8hours. |
This is complete idiocy -- the TIME=480 parameter will NOT terminate the job in 8 hours. You need to research and figure out what this parameter really tells the system.
The "requirement" is absurd, and your implementation of it makes no sense. I'm not sure about JES2, but I know that JES3 stops allowing most activity when the spool utilization hits 90% -- nobody can sign onto TSO, no jobs are submitted, and the system is basically at a standstill until the spool utilization gets back below 90%. Someone deliberately doing this at my site would have an excellent chance of being asked to take their programming "skills" somewhere else. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
Well I'll walk slowly and ask - what is that you are trying to do?  |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Follow Anuj's suggestion. Tell us what you are supposed to do, and why.
Do not do something like this again, until you can understand fully why you shouldn't do it.
Why do you think you can get a sensible answer from us about deleting one of your spool files? If you get advice on the internet about that, don't follow it, please. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello and welcome to the forum,
Now that you have been thoroughly whupped on . . .
As others mentioned, you need to explain just what you are trying to accomplish. Other than wasting system resources, not much will be accomplished by this process.
Who decided you should do this? Did they have a goal in mind or just wanted you to implement something to be doing so. . . 
Filling the spool is a bad thing - doing it again may cause the system support people to come looking for you. . . |
|
| Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2594
Location: Silicon Valley
|
|
|
|
| Quote: |
| write a job which can do the continuously I/O for several hours. |
In the 1980's, I had to do something similar. I was asked to write an 'arm breaker' program.
The problem was that we had some beta level DASD and sometimes they were not reliable. We were burned a few times before learning to stress the device first.
We reported so many hardware problems a day or two after they were installed that the vendor changed their process to do their own stress testing before delivering their products.
Fast forward to 2012... although I do not follow DASD developments as much as I used to, I think the quality of DASD is pretty good and such arm breaking is not required. Or is it? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
I've not seen anyone run an "arm breaker" for a long, long time - and then it was not assigned to someone new. . . We did once, just for fun, write some assembler code that would "walk" a drive by throwing the heads from the center of the drive to the outter edge. These devices had 4 spindles in one cabinet (Telex iirc) in a block of 4 . . .
Usually, these days if something like this is done at my sites, it is to benchmark different kinds of dasd to see how they compare. And the tests are not for hours and hours. . .
Maybe yet we'll learn just why this has been assigned |
|
| Back to top |
|
|
parsesource
New User
Joined: 06 Feb 2006
Posts: 97
|
|
|
|
| expat wrote: |
Perhaps a career outside of IT may be of benefit to both yourself and the rest of us, as it abundantly clear that you have absolutely no idea of what you are doing.
Please explain the background to this rather inane requirement, why does it need to be done.
Have you ever read a JCL manual in your life. Do you not know that the submitted job is totally independant of the submitting job, therefor the TIME= parameter for the submitted job is started from zero for each and every job that you submit.
Causing the spool to fill up may crash the system, and your career with it. |
well, it´s clear that he/she is not an expert (a beginner). it seems the main problem here is, that his/her supervisor allowed to do this. |
|
| Back to top |
|
|
liminsh
New User
Joined: 16 Jul 2012
Posts: 6
Location: 中国
|
|
|
|
| dick scherrer wrote: |
Hello and welcome to the forum,
Now that you have been thoroughly whupped on . . .
As others mentioned, you need to explain just what you are trying to accomplish. Other than wasting system resources, not much will be accomplished by this process.
Who decided you should do this? Did they have a goal in mind or just wanted you to implement something to be doing so. . .
Filling the spool is a bad thing - doing it again may cause the system support people to come looking for you. . . |
hello, Thanks for your reply.
actually, the requirement assigned to me is that I should run an I/O job for long time(such as 8hours)on a particular volume to do the DASD stress test. But, I don't know how to realize it using jcl... |
|
| Back to top |
|
|
liminsh
New User
Joined: 16 Jul 2012
Posts: 6
Location: 中国
|
|
|
|
| Robert Sample wrote: |
| Quote: |
| The job submit itself to do a infinite loop.The Time=480 will terminate this job in 8hours. |
This is complete idiocy -- the TIME=480 parameter will NOT terminate the job in 8 hours. You need to research and figure out what this parameter really tells the system.
The "requirement" is absurd, and your implementation of it makes no sense. I'm not sure about JES2, but I know that JES3 stops allowing most activity when the spool utilization hits 90% -- nobody can sign onto TSO, no jobs are submitted, and the system is basically at a standstill until the spool utilization gets back below 90%. Someone deliberately doing this at my site would have an excellent chance of being asked to take their programming "skills" somewhere else. |
thanks for your advice. Do you mean the Time=480 is only for one job not the whole loop in my jcl?
Do you know any other method can implement an loop for 8hours? |
|
| Back to top |
|
|
liminsh
New User
Joined: 16 Jul 2012
Posts: 6
Location: 中国
|
|
|
|
| Pedro wrote: |
| Quote: |
| write a job which can do the continuously I/O for several hours. |
In the 1980's, I had to do something similar. I was asked to write an 'arm breaker' program.
The problem was that we had some beta level DASD and sometimes they were not reliable. We were burned a few times before learning to stress the device first.
We reported so many hardware problems a day or two after they were installed that the vendor changed their process to do their own stress testing before delivering their products.
Fast forward to 2012... although I do not follow DASD developments as much as I used to, I think the quality of DASD is pretty good and such arm breaking is not required. Or is it? |
Thanks for your reply. Actually, the requirement I got is to write a long time I/O job to do the DASD stress test... |
|
| Back to top |
|
|
liminsh
New User
Joined: 16 Jul 2012
Posts: 6
Location: 中国
|
|
|
|
| parsesource wrote: |
| expat wrote: |
Perhaps a career outside of IT may be of benefit to both yourself and the rest of us, as it abundantly clear that you have absolutely no idea of what you are doing.
Please explain the background to this rather inane requirement, why does it need to be done.
Have you ever read a JCL manual in your life. Do you not know that the submitted job is totally independant of the submitting job, therefor the TIME= parameter for the submitted job is started from zero for each and every job that you submit.
Causing the spool to fill up may crash the system, and your career with it. |
well, it´s clear that he/she is not an expert (a beginner). it seems the main problem here is, that his/her supervisor allowed to do this. |
yes...I am a beginner... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| yes...I am a beginner... |
Not to worry - we all were once. . . 
TIME=480 is NOT wall-time, it is CPU time.
Why does someone believe you should stress test your dasd? Once upon a time, each dasd unit was a single unit and they were prone to problems. Almost everywhere uses large dasd arrays and the single-unit stress test is not as it was.
If you intend to do more with this, suggest you talk with your storage management people and learn how you should proceed.
If the goal is to pound on the dasd, why was there enough "output" to fill the spool? |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| Quote: |
| // UNIT=3390,VOL=SER=SNDBXB, |
First, You've mentioned 3390 as your UNIT - I also like to inquire if stress-test is really needed for I/O. Pardon my ignorance, I never worked with kind of DASDs such 3350, which might, possibly, ask for DASD tests.
Second, when you used this
| Quote: |
| //SYSOUT DD DSN=***, |
why would this
| Quote: |
| but ,the sysout still be printed to the spool ,not to the dataset(I can browse the output logs using 'S' on sdsf). |
happen? |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK
|
|
|
|
| JCL does NOT loop. Programs can. Bad programs fail to stop their loop. |
|
| Back to top |
|
|
liminsh
New User
Joined: 16 Jul 2012
Posts: 6
Location: 中国
|
|
|
|
| Can I use the rexx to do the long time loop? is it feasible？ |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| Can I use the rexx to do the long time loop? is it feasible？ |
You could cause lots of i/o using rexx (though you'd probably use more cpu than you want), or COBOL, or simply copy millions and millions of records, delete them, and repeat some number of times.
You really need to post something that we can use to help you . . . Most of the details of your questions need to come from you. This question does not provide much for us to use to help. . . |
|
| Back to top |
|
|
|
|
