|
View previous topic :: View next topic
|
| Author |
Message |
jain.eti
New User
Joined: 23 Jan 2007
Posts: 25
Location: delhi
|
|
|
|
Dick,
I have not got around S813 abend. As I mentioned earlier, whenever I was taking one step of our complete job to check why the complete job ended with CC=12, we received S813. I do not know why! OK! I checked this in CA-1 that the tape is associated with other DSN at label 1. Was it the reason?
But I am confirmed about the label and VOL-SER I used with the particular tape file. And I am confirm that they are pretty fine.
Robert, (Though I am angry wtih you) thanks for your input. I have changed the SPACE with more secondary space. Job is still running and let you all know about its condition once this job gets completed (hopefully this time with CC=0)! |
|
| Back to top |
|
 |
jain.eti
New User
Joined: 23 Jan 2007
Posts: 25
Location: delhi
|
|
|
|
Sorry in my last post, it was not Robert but Enrico ...  Sorry for the confusion ... |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Well it confused me! 
But if you're reading records and getting SB37 abends then the tape label DSNAME and the JCL DSNAME are matching enough to let the job run. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| I checked this in CA-1 that the tape is associated with other DSN at label 1. Was it the reason? |
Yes, file #1 would probably be a different dsn. That is not the cause of the s813.
What does CA1 have to say about file #727 on that volume? It has been a while, but i recall being able to list all of the DSNs on a tape using EARL (i prefer that to GRW). Until the mis-match between the jcl and the tape label is resolved, the s813 will continue.
What type of data is on this tape? Having more than 700 user data files on the same tape volume is not something i've seen very often (trying to remember if ever).
If you are still having sb37 abends, it may help to post the OUTFILE dd statement. If we can see what you are using, we can better offer suggestions on how to modify it so it will not abend. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
it looks like Your sense of humor is close to 0, haven' t You seen the smiley
I just went to see my ophthalmologist and he confirmed that my sight is good
can You say the same ? 
in the first post you have
| Quote: |
| SYS3.QPP1D.ARCH.D08118.T112723.F01 |
and in the second
| Quote: |
| SYS3.QPP1D.ARCH.D08119.T105510.F01 |
so You might have been using the same datasets, but You posted something different
being angry is just a personal choice, nobody forced You to |
|
| Back to top |
|
|
gcicchet
Senior Member
Joined: 28 Jul 2006
Posts: 1702
Location: Australia
|
|
|
|
Hi,
I don't know if it's just me, but I'm confused with this whole thread, so let's see if I can add more to it.
Firstly, why is the file written to disk as a temporary dataset, what is going to read the temporary dataset ?
Why not process directly from tape ?
Blocksize of 32760 is very inefficient, 27998 will improve space usage by about 40%
Gerry |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Gerry,
Welcome aboard. . .
Been so long since i've looked at the front of the topic, i completely missed/forgot that the OUTFILE dd was there. . . 
Jain, Sorry 'bout that (the dd info request).
As you will probably continue to write to dasd for ftp (i suppose it might run from tape, but i've never tried it), suggest you change this:
| Code: |
// UNIT=TEMPDA,
// SPACE=(CYL,(100,5),RLSE),
// RECFM=VBA,LRECL=240,BLKSIZE=32760
|
to
| Code: |
// UNIT=(TEMPDA,4),
// SPACE=(CYL,(100,100),RLSE),
// RECFM=VBA,LRECL=240
|
You might also consider using the sort product for the copy as it will most likely run faster than IDCAMS. |
|
| Back to top |
|
|
|
|
