Memory Utilization with Database Allowed Core

[Mitchell Lyter]

What happens when you allocate more allowed core memory to a database then the system has?

Our production systems has a lot of memory so the allowed core on our databases is set to utilize it. We also have other small development MCPs, like and lx180 laptop, that we set up to resemble our production mainframe. If I set up the production database on these smaller machines and do not change the allowed core what happens when the database tries to use more memory then there is available? How does this affect the system processes using the memory as well?

Do you know of any process or tools to view the utilization of system memory throughout the day?

We are running MCP 17.0

Thanks,
Mitch

[Vern]

I used Viewpoint when I was a contractor at Cooper Tire in Findlay, Oh back around 2008ish and gave a presentation at Unite, but not specifically on memory. Based on the data I had sleeping WFL's make system changes automagically. Can’t remember what it cost. SMFII should get that for you.

Vern, old Unisys guy, medium systems, “Only need 6 char file names !”.

[Marc Wilson]

In comp.sys.unisys, (Vern) wrote in
<642c644e-9c00-4c03...@googlegroups.com>::

>
>Vern, old Unisys guy, medium systems, “Only need 6 char file names !”.

Oh, that takes me back to the DECSystem 10.
--
Marc Wilson

Cleopatra Consultants Limited - IT Consultants
Fernrhoyd, Chester Road, Alpraham, Tarporley, Cheshire CW6 9JE
Tel: (44/0) 1829 262696 Tel: (44/0) 161 408 6449
Fax: (44/0) 844 779 0968 Mobile: (44/0) 7973 359850
Skype: cleo-marc Mail: enqu...@cleopatra.co.uk
Web: http://www.cleopatra.co.uk
Registered in England and Wales no: 2588943 VAT Reg: 561 1182 69
Registered office: St George's House, 215-219 Chester Road
Manchester M15 4JE

https://plus.google.com/100816173414569062406

[Paul Kimpel]

You don't "allocate" memory to a DMSII data base -- instead the
ALLOWEDCORE parameter sets an upper limit on how much memory the data
base will allow itself to use for I/O buffers. Buffers are allocated on
demand, as they are needed. Once the ALLOWEDCORE threshold is reached,
DMSII will start reusing buffers (writing them back to disk first if
necessary) or returning buffer areas to the system to keep its total
buffer memory usage below the threshold. Note that this affects only the
"save" memory used for buffers -- there is no control over the amount of
memory DMSII will use for control structures, code segments, etc.

Also note that the amount of buffer memory a data base uses is
potentially constrained further by the BUFFERS attribute on each
structure. That specifies a fixed number of buffers, plus a number of
per-user buffers the data base will allow itself to use. "User" in this
context is an invocation of a structure. If your program invokes a
structure three times, that's three users in terms of buffer counting.
Those buffers will not actually be allocated, though, unless the data
access pattern of the program actually requires additional buffers. Like
ALLOWEDCORE, BUFFERS should be viewed as a threshold that DMSII will try
not to cross. The BUFFERS specification is ignored, however, the the
OVERLAYGOAL parameter is non-zero.

So the first part of the answer to your question is that the amount of
buffer memory actually used by a data base depends on the access
patterns of your mix of programs. If that mix only touches 200 unique
blocks, you'll have at most 200 buffers allocated, assuming that
collection of buffers does not cross the ALLOWEDCORE or any of the
BUFFERS thresholds. If the mix you are running doesn't chew up the
remaining memory with buffers, there is no impact.

The second part of this is what happens when the mix actually does
demand more buffer memory than is available? I honestly don't know the
answer to this, as I haven't been in that position in almost 40 years.
The Accessroutines will return SYSTEMERROR #9 if main memory is
exhausted, but if the MCP has been backed that far into a corner, it's
likely that other bad things are going to be happening -- task aborts,
lockups, possibly the MCP itself will lock up. I wouldn't be surprised
if you need to Halt/Load to get out of such a situation.

It's so easy to avoid this problem, though -- ALLOWEDCORE can be changed
dynamically using the <mix>SM command. You don't need to modify the
parameter in DASDL. The value will be stored in the data base CONTROL
file and will persist across Halt/Loads and DASDL updates. Just set it
once after each time you clone the data base to your test system, and
you're done.

While most performance monitors on the market will track and analyze
both DMSII and system memory utilization, it is not that difficult to
write a utility that will do it yourself.

DMSII buffer memory utilization can be obtained on a global or
per-structure basis using the DMINQ function in DMALGOL. In particular,
see the discussion of the Get Statistics Information call (A[0]=25) in
Section 3 of the DMALGOL manual, with A[1]=0 and A[2]=1. This is the API
behind a <mix>SM STATISTICS command.

Total system memory utilization can be obtained by making a SYSTEMSTATUS
Type-2 call. See Section 3 in the SYSTEMSTATUS manual.

--
Paul

[Scott Lurndal]

Vern <VLfa...@comcast.net> writes:

>Vern, old Unisys guy, medium systems, Only need 6 char file names

Medium systems wiki: http://vseries.lurndal.org/doku.php

Emulator boot: http://vseries.lurndal.org/doku.php?id=simulator:installation:tarball

[Mitchell Lyter]

Thank you Paul. This has been helpful

Mitch

[Vern]

On Tuesday, May 31, 2016 at 5:26:19 PM UTC-4, Mitchell Lyter wrote:

Excellent post Paul ! And Scott, WoW ! Those links are fantastic ! You knew what I needed to fully understand the V Series evolution as I was a big proponent of it in the early 90's when with Unisys, I worked at the Atlanta Development Center of GFS, the notorious GLOBAL FINANCIAL SYSTEM having modules for loans and deposits, running on A/V platforms. I was on a team that developed it for medium to large banks (and S&Loans) that was rather unwieldly to install.

Countless Parameter files, database fields, flat files, but not PCR decks, as we used WFL as primitive as it was compared to A/Clearpath MCP line.

I take that back as I did use data passed thru a PCR deck from WFL.

We still used PCR decks when as a Staff SGT in the USAF around 1982 at the Design Center in Al, we were running around 165 AFB's worldwide on B-3500/3700's Base Level systems. Then when the PHASE-IV project ramped up, due to timing issues, I was trained for weeks on Sperry 1100 systems up at Tysons Corner in DC and was on that Sperry team benchmark against Burroughs Large Systems, think? a B-5900 vs a Sperry 1100/60 and Verne Orr, don't remember what he was but he awarded a huge contract to Sperry in 1983. I did some MASM, SSG, @CTS,I editor? and managed each base's (165) Software configurations. Then I got on with Burroughs in 1986, layed off in 1996, with Progeni 1997-2001, they had some impressive brainpower there, recruited to Capital One in 2001, took care of Master/Visa software that pooshed out 2 M credit cards a day. Wrote some pretty fancy WFL's to communicate with foreign systems that required weird data, alot of'em Unix, which I worked on Unisys/HP Unix back with UIS on Coinserv, laser disk report archiving. It used these great big Jukebox storage, I guess 20 yrs ago. From there to Administrating Cooper Tire Clearpath 590's? that kept the tire factories chugging around the US and China.

This is long enough, but I wanted to add that back in 1992?, I got to stay at Embassy Suites at the Pasadena Plant for a week benchmarking GFS from a single 6250bpi tape that would run on a V380 for 90 min from a Master WFL. Then I used my own WFL's for running XRLOG and Flame Files for analysis.

I ran the benchmark on a V-530/560, remember you changed a V530 to a V560 by a short SPO (Supervisory Printer Output) Command, +P??.

And I had access to a GB of Zitel SSD Ramdisk as itel wanted me to push that but it was out of most bank's budgets (read that cheapass).

It was fun. I haven't looked at the Emulator yet as I was giddy reading the specs, like looking at them for a Classic Car, BTW I have a 1965 Corvair Corsa Conv, black on black, white power top, 2.7L H-6, 140hp 4x1bbls carbs.

[Vern]

> It was fun. I haven't looked at the Emulator yet as I was giddy reading the specs, like looking at them for a Classic Car, BTW I have a 1965 Corvair Corsa Conv, black on black, white power top, 2.7L H-6, 140hp 4x1bbls carbs, 85% restored.

I just wanted to add that in that 90 min benchmark (V380) I ran, for the V560 benchmark I avoided the file equation and put all the files to the Zitel SSD configured as LAK (look alike 100 bytes per sector disk) and it brought the batch run time from 90 to 12 min !!!

[Scott Lurndal]

Vern <VLfa...@comcast.net> writes:
>On Tuesday, May 31, 2016 at 5:26:19 PM UTC-4, Mitchell Lyter wrote:

>

>Excellent post Paul ! And Scott, WoW ! Those links are fantastic ! You knew=
> what I needed to fully understand the V Series evolution as I was a big pr=
>oponent of it in the early 90's when with Unisys, I worked at the Atlanta D=
>evelopment Center of GFS, the notorious GLOBAL FINANCIAL SYSTEM having modu=
>les for loans and deposits, running on A/V platforms. I was on a team that =
>developed it for medium to large banks (and S&Loans) that was rather unwiel=
>dly to install.=20

I mainly worked on the MCP. Didn't ever run GFS, however I did have to
use IPS a bit when debugging reader/sorters in MCPVS 2.0.

>
>Countless Parameter files, database fields, flat files, but not PCR decks, =
>as we used WFL as primitive as it was compared to A/Clearpath MCP line.=20

>
>I take that back as I did use data passed thru a PCR deck from WFL.

PCR's were used "under the covers" by a number of tools, including often
by CANDE to submit compiles and other jobs.


>This is long enough, but I wanted to add that back in 1992?, I got to stay =
>at Embassy Suites at the Pasadena Plant for a week benchmarking GFS from a =
>single 6250bpi tape that would run on a V380 for 90 min from a Master WFL. =
>Then I used my own WFL's for running XRLOG and Flame Files for analysis.=20
>

I transferred form Pasadena to the Unix Group (former Convergent Technologies)
in San Jose in 1989, as I saw that there wasn't much possibility of V-Series
surviving the merger.

>I ran the benchmark on a V-530/560, remember you changed a V530 to a V560 b=
>y a short SPO (Supervisory Printer Output) Command, +P??.=20

It wasn't that short:

ALTER PROC + 2

Would bring the second processor online.

ALTER PROC - 2

Would take it off line.

(I implemented the ALTER command in MCPVS).

>
>And I had access to a GB of Zitel SSD Ramdisk as itel wanted me to push tha=
>t but it was out of most bank's budgets (read that cheapass). =20

Yeah, I remember one of those cycling through the plant, but we couldn't
keep it. We did have a bunch of old 5N's as DISK, which were pretty fast.

[Scott Lurndal]

Vern <VLfa...@comcast.net> writes:
>On Friday, June 3, 2016 at 5:17:43 PM UTC-4, Vern wrote:

>

>I just wanted to add that in that 90 min benchmark (V380) I ran, for the V5=
>60 benchmark I avoided the file equation and put all the files to the Zitel=
> SSD configured as LAK (look alike 100 bytes per sector disk) and it brough=

>t the batch run time from 90 to 12 min !!!

I figure vsim (the emulator, which emulates V3x0, V4x0 and V5x0, up to the
four processor V590 (which was never actually built)) can run it on a fast
64-bit x86 host in 10 minutes or so - With 32 GB of DRAM, all the LAK and
PACK fit in memory :-). I've measured compile speeds comparable to the V560
on my old laptop (The only large source I have is for ADSINP, which is written
in BPL).