So this had me laughing out loud. I just cranked up an old 170 to assist a customer migrating S/36 programs, OCL, and data to IBM i. As they only had ancient QIC I needed the old girl to read that tape.

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! 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.

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, I'm glad it's a hobby machine and not running real production!!

- Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.

On 12/6/2019 7:07 AM, Patrik Schindler wrote:
Hello,

I'm doing some data transfers between my 150 (running V4R5) and a Linux VM elsewhere via ODBC. Especially INSERTs are very costly and slow down other (interactive) tasks on the box considerably. For that reason I want to lessen impact of the QZDASOINIT PJs in the QSERVER Subsystem. Also I'd prefer to do that in a way that the setting(s) survive an IPL.

I still didn't get a solid grip about jobs and work management. I have a rough idea about relative job priorities and time slices. My understanding of subsystems is even more terse. How would you achieve the described goal? No detailed steps necessary. Primarily I want to collect ideas how to do it (properly).

Please refrain from comments like "get a current machine" or likewise. I'm a hobbyist in Midrange terms with a tendency to retrocomputing. Thank you. :-)

:wq! PoC

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.