Home > Archive > Cobol > August 2006 > Is Region=128M allowed at your shop? Would it raise any eyebrows?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is Region=128M allowed at your shop? Would it raise any eyebrows?
|
|
| Vivian 2006-08-08, 6:55 pm |
| It's raising a few eyebrows here, since the job previously ran with a
region size of 4M, and now that it is writing to Oracle, it needs 128M.
So my question is, is it just me? Or would it raise any eyebrows at
your shop if you had to increase the region size on your job card
(cobol program) from 4M to 128M?
| |
| Clark F Morris 2006-08-08, 6:55 pm |
| On 8 Aug 2006 13:19:53 -0700, "Vivian" <vsaegesser@infogix.com> wrote:
>It's raising a few eyebrows here, since the job previously ran with a
>region size of 4M, and now that it is writing to Oracle, it needs 128M.
> So my question is, is it just me? Or would it raise any eyebrows at
>your shop if you had to increase the region size on your job card
>(cobol program) from 4M to 128M?
As someone who used to get upset when people put more than 100K in a
job card, I find today is a whole different world. We are running
computers that have more RAM than the computer that ran our business
had disk space. Oracle, SAP, DB2, etc. all seem to want what seem
like astounding amounts of memory to me. If you take a look at the
changes in the types of data and the way we process it, I think the
trend is such that soon 128M (about 131,000 K) will be looked upon as
small in the not too distant future. Frankly, I think some IBM
mainframe software vendors have failed to realize that it is taking an
increasing amount of computer resource to process the same amount of
business for an organization and thus may price themselves out of the
market. This is being done better. Databases are doing more for us
than indexed files could (when used properly). The enterprise
packages such as SAP also allow more insight into the business at the
cost of a lot more computer resource to manage the same volume of
business transactions in a timely manner.
| |
| Joe Zitzelberger 2006-08-11, 7:55 am |
| In article <1155068393.508621.271340@i42g2000cwa.googlegroups.com>,
"Vivian" <vsaegesser@infogix.com> wrote:
> It's raising a few eyebrows here, since the job previously ran with a
> region size of 4M, and now that it is writing to Oracle, it needs 128M.
> So my question is, is it just me? Or would it raise any eyebrows at
> your shop if you had to increase the region size on your job card
> (cobol program) from 4M to 128M?
Put a REGION=0M on everything -- it will gradually help get your
sysprogs out of the 1970's mentality of limiting resource consumption
simply because they have that power.
A job takes what it takes. If Oracle is a memory hog, tell them to
complain to whoever decided to buy that pig, not to preemptively murder
your job.
| |
| Clark F Morris 2006-08-11, 6:55 pm |
| On Fri, 11 Aug 2006 09:02:09 -0400, Joe Zitzelberger
<zberger@knology.net> wrote:
>In article <1155068393.508621.271340@i42g2000cwa.googlegroups.com>,
> "Vivian" <vsaegesser@infogix.com> wrote:
>
>
>Put a REGION=0M on everything -- it will gradually help get your
>sysprogs out of the 1970's mentality of limiting resource consumption
>simply because they have that power.
REGION=0M can have nasty consequences. I prefer not specifying REGION
and having things set up underneath the covers to allow things to run.
SAP, Oracle and DB2 are going to take a lot more resource but this is
something that should not be sprung on the systems staff. Bad things
happen when you run out of page data set space. Since Oracle, et al
are equal memory hogs, those systems people responsible for the
Unix/proprietary system of choice or affliction/etc. also have to
provide for the memory and disk usage.
>
>A job takes what it takes. If Oracle is a memory hog, tell them to
>complain to whoever decided to buy that pig, not to preemptively murder
>your job.
| |
|
| In article <r45pd2poah83uh46dd729ucsnj65f5mfai@4ax.com>,
Clark F Morris <cfmpublic@ns.sympatico.ca> wrote:
>On Fri, 11 Aug 2006 09:02:09 -0400, Joe Zitzelberger
><zberger@knology.net> wrote:
>
>
>REGION=0M can have nasty consequences. I prefer not specifying REGION
>and having things set up underneath the covers to allow things to run.
Just to make things a bit more complex... I regularly run a job for which
I've specified REGION=64M on several steps. (no database access and
minimal VSAM use) Just to revisit an old practise I ran it with no REGION
parms and a step blew up with an 878 (specifically ABEND=S878 U0000
REASON=00000010 387); with REGION=0M it ran to completion.
(Jobstats were:
for REGION=0M: JOB I/O COUNT= 347K JOB CPU TIME= 505.60
for REGION=64M: JOB I/O COUNT= 182K JOB CPU TIME= 487.56
.... and this, to some, might constitute 'a noticeable difference'.)
DD
| |
| Clark F Morris 2006-08-11, 9:55 pm |
| On Fri, 11 Aug 2006 17:02:27 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <r45pd2poah83uh46dd729ucsnj65f5mfai@4ax.com>,
>Clark F Morris <cfmpublic@ns.sympatico.ca> wrote:
I forgot to say that as I understand it, assuming the shop allows
REGION=0M (doesn't have an exit or other code blocking its use), the
construct may mean that memory normally reserved for end of job clean
up or abend clean up, may not be reserved if REGION=0M is specified.
[color=darkred]
>
>Just to make things a bit more complex... I regularly run a job for which
>I've specified REGION=64M on several steps. (no database access and
>minimal VSAM use) Just to revisit an old practise I ran it with no REGION
>parms and a step blew up with an 878 (specifically ABEND=S878 U0000
>REASON=00000010 387); with REGION=0M it ran to completion.
>
>(Jobstats were:
>
>for REGION=0M: JOB I/O COUNT= 347K JOB CPU TIME= 505.60
>for REGION=64M: JOB I/O COUNT= 182K JOB CPU TIME= 487.56
Same inputs and outputs? The reason I ask is that I don't understand
the difference in I/O counts. Also of interest would be the allocated
region sizes for each step in both scenarios.
>
>... and this, to some, might constitute 'a noticeable difference'.)
>
>DD
| |
|
| In article <ho9qd2hshlt7otk4vdol3nfbflh992q1nt@4ax.com>,
Clark F Morris <cfmpublic@ns.sympatico.ca> wrote:
>On Fri, 11 Aug 2006 17:02:27 +0000 (UTC), docdwarf@panix.com () wrote:
>
[snip]
[color=darkred]
>I forgot to say that as I understand it, assuming the shop allows
>REGION=0M (doesn't have an exit or other code blocking its use), the
>construct may mean that memory normally reserved for end of job clean
>up or abend clean up, may not be reserved if REGION=0M is specified.
>
>
>Same inputs and outputs?
Yep... I'll admit that I only checked the record counts and did not
perform a file-compare... but the inputs were the same and the major
output file was 334,195 records for both. For a quick look-see...
hmmmm... there's an IDCAMS at the top of the jobstream, uses two
concatenated VB datasets and REPROs them into one (using current input
there's 340,883 recs). Region=0M gave this step an I/O count of 2077 and
1.05 CPU sec, REGION=64M gave 2078 and 1.05... so not much difference
there... likewise a SORT, using an LRECL=135, RECFM=VB, SORT
FIELDS=(5,15,CH,A) and both jobs used 158 I/O and 1.09 CPU sec.
On t'other hand... the main difference seems to be in one program, the
major COBOL module that processes those 334,195 records, does a couple of
VSAM file interactions (key READs, START/READ NEXTs on an alternate key,
REWRITES) and an internal SORT of its output file of (in this run) 755,309
records (LRECL=160). REGION=0M caused this to use 341K I/O and 492.3 CPU
sec; Region=64M cut that to 175K I/O and 474.11 CPU.
>The reason I ask is that I don't understand
>the difference in I/O counts.
Makes two of us... but there are the numbers I saw in Living Green on
Black.
>Also of interest would be the allocated
>region sizes for each step in both scenarios.
No idea where I'd find that in the JESlog; if someone can give a pointer
I'll see what I can look up.
DD
| |
| Clark F Morris 2006-08-12, 7:55 am |
| On Sat, 12 Aug 2006 11:48:29 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <ho9qd2hshlt7otk4vdol3nfbflh992q1nt@4ax.com>,
>Clark F Morris <cfmpublic@ns.sympatico.ca> wrote:
>
>[snip]
>
>
>Yep... I'll admit that I only checked the record counts and did not
>perform a file-compare... but the inputs were the same and the major
>output file was 334,195 records for both. For a quick look-see...
>hmmmm... there's an IDCAMS at the top of the jobstream, uses two
>concatenated VB datasets and REPROs them into one (using current input
>there's 340,883 recs). Region=0M gave this step an I/O count of 2077 and
>1.05 CPU sec, REGION=64M gave 2078 and 1.05... so not much difference
>there... likewise a SORT, using an LRECL=135, RECFM=VB, SORT
>FIELDS=(5,15,CH,A) and both jobs used 158 I/O and 1.09 CPU sec.
>
>On t'other hand... the main difference seems to be in one program, the
>major COBOL module that processes those 334,195 records, does a couple of
>VSAM file interactions (key READs, START/READ NEXTs on an alternate key,
>REWRITES) and an internal SORT of its output file of (in this run) 755,309
>records (LRECL=160). REGION=0M caused this to use 341K I/O and 492.3 CPU
>sec; Region=64M cut that to 175K I/O and 474.11 CPU.
>
>
>Makes two of us... but there are the numbers I saw in Living Green on
>Black.
>
>
>No idea where I'd find that in the JESlog; if someone can give a pointer
>I'll see what I can look up.
If your shop prints the statistics when MSGLEVEL=(1,1), it should be
after each step. Also REGION=0M may be forced to a rather small
default. Just because you coded REGION=0M doesn't mean that the
system didn't do some overriding because of the dangers inherent in
0M.
>
>DD
| |
| Michael Mattias 2006-08-12, 7:55 am |
| > In article <ho9qd2hshlt7otk4vdol3nfbflh992q1nt@4ax.com>,
>
>
> Makes two of us... but there are the numbers I saw in Living Green on
> Black.
Depends on what is included in I/O counts. If the swaps to/from disk virtual
memory are included, a different REGION size would almost demand a different
I/O count, wouldn't it? When the region is fixed (nonzero), the swap areas
can be set up once. When region is dynamic, it may need to be resized
multiple times.
Hell, it's a thought.
MCM
| |
|
| In article <hfird2lqakmrmi559gntshj9a73khd4lek@4ax.com>,
Clark F Morris <cfmpublic@ns.sympatico.ca> wrote:
>On Sat, 12 Aug 2006 11:48:29 +0000 (UTC), docdwarf@panix.com () wrote:
>
[snip]
[color=darkred]
>If your shop prints the statistics when MSGLEVEL=(1,1), it should be
>after each step. Also REGION=0M may be forced to a rather small
>default. Just because you coded REGION=0M doesn't mean that the
>system didn't do some overriding because of the dangers inherent in
>0M.
Hmmmm... after the step for the REGION=0M job there is:
IEF374I STEP/STEP26 /STOP 2006223.1132 CPU 8MIN 12.40SEC SRB 0MIN 10.92SEC
VIRT 7200K SYS 604K EXT 9620K SYS 12616K
.... and, likewise, for the REGION=64M job there is:
IEF374I STEP/STEP26 /STOP 2006223.1241 CPU 7MIN 54.11SEC SRB 0MIN 05.65SEC
VIRT 7200K SYS 608K EXT 9620K SYS 12644K
.... which does not, to my admittedly inexperienced eye, explain too many
differences.
DD
| |
|
| In article <e1kDg.5983$o27.52@newssvr21.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:
>
>Depends on what is included in I/O counts.
Quite right, Mr Mattias... and I recall my first programming instructor
handing out to the class samples of a JESLOG for a run and going over the
various numbers that might be of interest... and rapidly skipping over the
I/O COUNT column saying 'Different shops calculate this in different ways;
it may be useful as a relative value between runs but as an absolute
value, in and of it'sself... who knows what the hell is going on there?'
DD
|
|
|
|
|