IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Invalid block size


IBM Mainframe Forums -> ABENDS & Debugging
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
orchestrate

New User


Joined: 11 Feb 2010
Posts: 7
Location: India

PostPosted: Tue Sep 20, 2011 2:04 pm
Reply with quote

After taking backup of tape datasets , i have tried to open those DS i got Invalid block size, Please hep me.
Back to top
View user's profile Send private message
Gnanas N

Active Member


Joined: 06 Sep 2007
Posts: 792
Location: Chennai, India

PostPosted: Tue Sep 20, 2011 2:07 pm
Reply with quote

Taking backup job or process was successful?
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Sep 20, 2011 2:07 pm
Reply with quote

unfortunately we can do nothing with the scarce info You provided
Back to top
View user's profile Send private message
orchestrate

New User


Joined: 11 Feb 2010
Posts: 7
Location: India

PostPosted: Tue Sep 20, 2011 2:08 pm
Reply with quote

Yeah its success i got RC=0
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Sep 20, 2011 2:19 pm
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Sep 20, 2011 2:24 pm
Reply with quote

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
View user's profile Send private message
orchestrate

New User


Joined: 11 Feb 2010
Posts: 7
Location: India

PostPosted: Tue Sep 20, 2011 2:43 pm
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Sep 20, 2011 2:47 pm
Reply with quote

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 ? icon_evil.gif

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
View user's profile Send private message
orchestrate

New User


Joined: 11 Feb 2010
Posts: 7
Location: India

PostPosted: Tue Sep 20, 2011 3:11 pm
Reply with quote

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
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Tue Sep 20, 2011 3:22 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Sep 20, 2011 3:34 pm
Reply with quote

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
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India

PostPosted: Tue Sep 20, 2011 6:42 pm
Reply with quote

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
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Tue Sep 20, 2011 7:17 pm
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Sep 20, 2011 7:23 pm
Reply with quote

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 ? icon_cool.gif

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 icon_biggrin.gif
certainly the most wrong approach, leading to big damages and misunderstandings
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Wed Sep 21, 2011 12:29 am
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Wed Sep 21, 2011 1:11 am
Reply with quote

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 icon_biggrin.gif
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Wed Sep 21, 2011 6:38 pm
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Wed Sep 21, 2011 6:44 pm
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> ABENDS & Debugging

 


Similar Topics
Topic Forum Replies
No new posts Using Java/C/C++ to retrieve dataset ... Java & MQSeries 6
No new posts Find the size of a PS file before rea... COBOL Programming 13
No new posts Masking variable size field - min 10 ... DFSORT/ICETOOL 4
No new posts I need a 4 lines block where substrin... DFSORT/ICETOOL 12
No new posts Dataset size increase on adding 1 byt... DFSORT/ICETOOL 8
Search our Forums:

Back to Top