Re: Reducing ODBC connection impact

Hello Larry,

Am 06.12.2019 um 14:50 schrieb DrFranken <midrange@xxxxxxxxxxxx>:

So this had me laughing out loud.

Glad I could brighten your day a bit. :-)

I was SHOCKED at how slow it was and I remember installing that very machine brand new 'some years ago' and thinking how impressively fast it was back then!

Yes, it's very easy to get used to more comfy stuff until you take it for granted and forget about the slow-fast contrast. But when you do the opposite and have the fast-slow-contrast experience, well… ;-)

Just restoring the S/36 source and OCL (about a dozen libraries) took overnight. Including the customer's data the *SAVF I created for them was a gargantuan ginourmous hugemoungous 375MB. Yes MB.

Maybe that's not only a problem of the 170 but also of the comparably low transfer rate of the tape drive? Add "need to try again and again" because of an old tape and frequent read errors…

So while I do suspect there are some things you can do to assist a bit in lowering the impact of these inserts, such as lowering the priority in the COSD as others have suggested

Adjusting the (relative) priority isn't helping at all. I tested. It's less a CPU problem but after a few inserts, it feels (and sounds, from the head movement noises) like SLIC must swap in stuff for my interactive job again. So I suspect I somehow need to make sure the incoming data doesn't kick out my interactive session's data in RAM over time. Maybe that's what memory pools are good for?

I'm glad it's a hobby machine and not running real production!!

A similar machine actually *was* in production a year ago and still would have been happily. ;-P It was (amongst lesser stuff) providing a database shared via ODBC to a self-made DynDNS-Perl Script on Linux to check credentials for the service. And I did a 5250 form for easy maintenance of credentials. Did it's job perfectly, even if a dozen hosts or so tried to refresh their IP every 5 minutes. No noticeable impact.

But a 150 is simply not rack mountable in an orderly way and that was the main reason to migrate to a 8203.

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc