View previous topic :: View next topic
|
Author |
Message |
orchestrate
New User
Joined: 11 Feb 2010 Posts: 7 Location: India
|
|
|
|
After taking backup of tape datasets , i have tried to open those DS i got Invalid block size, Please hep me. |
|
Back to top |
|
|
Gnanas N
Active Member
Joined: 06 Sep 2007 Posts: 792 Location: Chennai, India
|
|
|
|
Taking backup job or process was successful? |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
unfortunately we can do nothing with the scarce info You provided |
|
Back to top |
|
|
orchestrate
New User
Joined: 11 Feb 2010 Posts: 7 Location: India
|
|
|
|
Yeah its success i got RC=0 |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Any idea of which particular piece of software you used to do the back-up?
It is not unknown for a "back-up" to be in a different format from the original dataset, thus being unusable without a "restore" of some sort. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
Quote: |
After taking backup of tape datasets |
the statement makes no/little sense ...
to take a backup of a tape dataset usually means just copy the tape
You will have to do a better job in explaining if You want any help !
but if, on the other hand, You are taking a backup on tape of some dasd datasets
usually the backup can be processed only by the program which created it
usually, in the IBM zOS world, ADRDSSU
reasonable for any other program to get an invalid block size |
|
Back to top |
|
|
orchestrate
New User
Joined: 11 Feb 2010 Posts: 7 Location: India
|
|
|
|
This is the JCL i have used for copying
Code: |
//XXX EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=XXXX.B1000.FILE.AAA.ABEC,
// DISP=SHR
//SYSUT4 DD DSN=XXXX.B1000.FILE.AAA.ABEC.D20SEP,
// DCB=(*.SYSUT1),SPACE=(CYL,(50,1),RLSE),
// DISP=(NEW,CATLG,DELETE) |
|
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
the topic is going down the sewer
inconsistent wording, jcl that would never run
would it be too much trouble to post also the output of the run ?
I just tested a jcl like the one You posted will never, repeat never run
with a 0 return code
to start with You would get
Code: |
11.22.17 JOB04323 IEC130I SYSIN DD STATEMENT MISSING |
and after adding a SYSIN DD DUMMY
Code: |
11.18.57 JOB04321 IEC130I SYSUT2 DD STATEMENT MISSING |
so what should we do apart suggesting that You should get a bit more training ??? |
|
Back to top |
|
|
orchestrate
New User
Joined: 11 Feb 2010 Posts: 7 Location: India
|
|
|
|
Might be i need , but see the full JCL below.
I thought u could have added that sysin part while chking, yes i was wrong. check the below JCL
Code: |
//abbada JOB CTOOS014,'COPY',MSGCLASS=E,CLASS=P,TIME=1440,
// REGION=4M,NOTIFY=&SYSUID
//**
//JS0010 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=abcdef.d1000.TNFILE.bbJ.KEYED,
// DISP=SHR
//SYSUT4 DD DSN=abcdef.d1000.TNFILE.bbJ.KEYED.D20SEP,
// DCB=(*.SYSUT1),SPACE=(CYL,(50,1),RLSE),
// DISP=(NEW,CATLG,DELETE)
//SYSIN DD DUMMY
/*
// |
|
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
That JCL still won't run. Did you read Dr. Sorichetti's post immediately above? Do you understand the significance of the second JCL error message?
Mr. Scherrer has commented elsewhere that unchecked "backups" are just media with dubiously useful information on them. You apparently created your "backups" through some process which you can neither understand nor explain, and now find that they are unusable. Too bad, so sad. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
I think you have to go right back to the start and explain fully what you are doing.
There must be at least two jobs/processes, since you claim you have a back-up and then get "invalid blocksize".
So show us everything, please. JCL (if done that way) or commands for both and all the output messages for both. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
DCB=(*.SYSUT1) is questionable for two reasons - first when the output is on DASD, why do you refer back to a Tape? So, remove the refer back - code UNIT=SYSDA (or DASD or 3990 or whatever is your site-stadard) and code the DCB.
Second, using this kind of refer back you'll waste a lot of DASD space.
For the second case, I hope you know that the optimum blocksize for tape is 32760, whilst for 3390 is 27998. Using 27998 each track will contain 2 blocks. Let's consider an example of FB/80:
For tape the blksize will be 32720, with each block containing 409 records. For 3390 the blksize should be 27920, with each block containing 349 records. 2 blocks per track = 2 * 349 = 698 records per track.
Code DCB=*.SYSUT1 you will then use BLKSIZE=32720 and you only get one block per track with 409 records, instead of 698 when you use BLKSIZE=27920.
(289 / 698) * 100 = 42%. Obviously, you are only utilising 58% of the available DASD capacity -- which means that you need to allocate 42% more DASD to store the same number of records! |
|
Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011 Posts: 556 Location: USA
|
|
|
|
from the hip: Since you used SYSUT4 instead of SYSUT2, the output file was never opened. You got a cataloged file that was never opened, so no end-of-file marker.
If you have something like stopx37 installed, you will be able to see that some temporary file got opened for DD SYSUT2, and THAT'S why your job is ending with RC=0.
This drove me CRAZY for a few days several years ago. I had a misspelled DD name in my JCL, was getting RC=0 on a step, getting a cataloged file, getting invalid blocksize when opening it. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
Quote: |
I thought u could have added that sysin part while chking, yes i was wrong. check the below JCL
|
why should I have...
I know how to write a IEBGENER step
to make You understand what is going on I had to reproduce exactly what You told You had submitted!
Quote: |
Since you used SYSUT4 instead of SYSUT2 |
the output file was never opened, and the step return code was 12
but we cannot do anything since the TS tells that the step RC was 0
as per
Code: |
IEF236I ALLOC. FOR ENRICO1 IEB
IEF237I DMY ALLOCATED TO SYSIN
IEF237I JES2 ALLOCATED TO SYSPRINT
IEF237I 0AB4 ALLOCATED TO SYSUT1
IGD100I 0AB3 ALLOCATED TO DDNAME SYSUT4 DATACLAS (FB80)
IEC130I SYSUT2 DD STATEMENT MISSING
IEF142I ENRICO1 IEB - STEP WAS EXECUTED - COND CODE 0012
|
Code: |
DATA SET UTILITY - GENERATE
IEB316I DDNAME SYSUT2 CANNOT BE OPENED |
I wonder why we waste time trying to educate people ?
Quote: |
If you have something like stopx37 installed, you will be able to see that some temporary file got opened for DD SYSUT2, and THAT'S why your job is ending with RC=0. |
I wonder who was the idiot who customized stopx37 that way
certainly the most wrong approach, leading to big damages and misunderstandings |
|
Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011 Posts: 556 Location: USA
|
|
|
|
You quoted my answer to say he would have gotten an RC=12, but I think it's possible that he still got RC=0 exactly as I did.
I can tell you that it no longer happens here. I get the UNABLE TO OPEN error just as you show.
I'm sure the TS will deliver an answer... |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
Quote: |
but I think it's possible that he still got RC=0 exactly as I did.
|
Ed, I was not questioning Your facts,
I was just resuming the events and making a consideration about the foolish way of customizing stopx37.
Now it would be even worse, for disp=new datasets the latest zOS might write an eof record
imagine what kind of sith... no wrong length record, the procedure flowing to the end with empty datasets
a nightmare wouldn' it |
|
Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011 Posts: 556 Location: USA
|
|
|
|
A nightmare indeed. But I guess we can just put the new "SET MAXCC=0" JES command in the JCL to keep from getting called. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
even a worse nightmare, but we have still a few days of peace left
AFAIK z/OS 1.13 goes GA on 30th of September 2011.
But you could have your Shopz-Orders in the queue since the 16th |
|
Back to top |
|
|
|