View previous topic :: View next topic
|
Author |
Message |
vikram gopalarathinam
New User
Joined: 28 Jan 2012 Posts: 8 Location: India
|
|
|
|
Hi we all know only 255 steps can be allowed in a JCL and 15 instream procs are allowed in a job and 3273 DD statments are allowed.. May i know why are this limits and on which condition these limits are set. I want o know in details.. please give me some idea or tell me some good url to know abt this... |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
Back to top |
|
|
David Robinson
Active User
Joined: 21 Dec 2011 Posts: 199 Location: UK
|
|
|
|
255 crops up in all sorts of places as it's the highest number you can store in one byte - x'FF' |
|
Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
|
|
|
|
vikram gopalarathinam wrote: |
Hi we all know only 255 steps can be allowed in a JCL and 15 instream procs are allowed in a job and 3273 DD statments are allowed.. May i know why are this limits and on which condition these limits are set. I want o know in details.. please give me some idea or tell me some good url to know abt this... |
The limitations are in place because computers are finite machines with finite resources. If you are having problems with them I think you have serious design (or implementation) problems. |
|
Back to top |
|
|
vikram gopalarathinam
New User
Joined: 28 Jan 2012 Posts: 8 Location: India
|
|
|
|
thanks David I agree with your point why is the the limits for DD statments and 15 instream procs..I need to know a detailed info abt this. please give me some URL or any document to know abt that if u have.. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
In some cases, the limits come about due to physical restrictions (255, 15 are numbers that are upper limits of 2-byte and 1-byte counters respectively). Others come about indirectly (3273 DD statements in a job, for example, is a limit because that's how many 20-byte DD statements can be defined in a 64 KB TIOT).
MUCH more important than knowing WHY the limit, however, is knowing the actual value for the limit to ensure you don't design anything that would violate a limit. Many of the specific values go back to design decisions made in the early to mid 1960's when the original S360 was being designed and built, and have not been changed to ensure backward compatibility. It is unlikely at this date that you could EVER find out the precise WHY of these design decisions, but remember the machines were much smaller in those days -- memory sizes were 16, 32, 64 KB (etc) for the entire mainframe. |
|
Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006 Posts: 1042 Location: Richmond, Virginia
|
|
|
|
While these are certainly interesting questions and the answers inform us about how these things are implemented, why you need to know this remains a mystery. Why do you need? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
I need to know a detailed info abt this. |
What kind of detail are you looking for?
As Phil asked - why does someone believe there is a need for "detail"?
If we knew what you are trying to address, we might be able to offer more usefull replies. |
|
Back to top |
|
|
vikram gopalarathinam
New User
Joined: 28 Jan 2012 Posts: 8 Location: India
|
|
|
|
Hi..
I have been asked these questions in an interview. Just want to know what willbe the answers for this and certainly it is intresting to know |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
The chance that you'll ever need to know these answers "in detail" and from memory is very, very, slim.
I've never been bothered by them. If I thought I might be in some circumstance, then what is important is knowing how to find out.
A dumb interview question, that could only check fro whether someone has researched answers to dumb interview questions.
OK, they happen. Don't answer them directly, they do not deserve a direct answer in an interview. Answer them "well" instead. For instance, toss a few manual (names) at them, and as an aside say that you've never, ever, heard of anyone having a problem with them... |
|
Back to top |
|
|
|