Re: [EXTERNAL] Analyzing RUNSQLSTMT jobs

If there is contention, it will show up in the job’s run-wait signature in the Performance Data Investigator (PDI).

If you have Collection Services with the default collection interval of 15 minutes, there may only be one interval of data if the job started and ended within that one interval, but it will be broken into stacked bars that show where the time was spent. I generally recommend using 5-minute intervals, so if a job runs from 10-15 minutes, you’ll have two or three intervals of data to see what is happening. Smaller intervals show spikes of activity that larger intervals hide.

There are various ways to locate a job in the Collection Services data - then you can display the job’s run-wait signature. This will show whether the job is using CPU, doing a lot of I/O, or is blocked due to some type of contention.

The easiest way to find the job is to go into Navigator: Performance -> Investigate Data -> Collection Services -> Job Statistics Overviews -> Job Statistics by Job or Task, and select the collection in which the job was running (most recent is probably good). (This table may take a bit of time to load).

You can then filter that table to find the job of interest.

Once you have found the job, click on the Actions box and drill down to “Waits for One Job or Task” to view what the job did over time.

(Note: if you are relatively current on PTFs, PDI has “Display” and “Display classic”. Use “Display”.)

Dawn

On Jul 15, 2021, at 8:35 AM, Alan Shore via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

Hi everyone
Just for giggles, I ended the job and manually resubmitted the same job
It ended in 10 minutes and a few seconds
!@#$%^&*()_
That’s me swearing
Is there a file contention somewhere?
If so – how can I find out what that contention is as I have looked at the job while it is running and I do not see any locks anywhere
PLUS – even if the locks went away – surely that would free up my job?
NONE of this is making any sense to me right now

Alan Shore
Solutions Architect
IT Supply Chain Execution

[cid:image004.png@01D77954.558E4580]

60 Orville Drive
Bohemia, NY 11716
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
E-mail : ASHORE@xxxxxxxxxxxxxxxxxxxx

‘If you're going through hell, keep going.’
Winston Churchill

From: Alan Shore
Sent: Thursday, July 15, 2021 7:46 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: [EXTERNAL] Re: Analyzing RUNSQLSTMT jobs


Ah well – back to the drawing board
The creation of the logicals didbt seem to make any difference what so ever
The job is STILL running from 10:30 last night

Anyone have any suggestions?

Alan Shore
Solutions Architect
IT Supply Chain Execution

[cid:image006.png@01D77954.558E4580]

60 Orville Drive
Bohemia, NY 11716
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
E-mail : ASHORE@xxxxxxxxxxxxxxxxxxxx<mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx>

‘If you're going through hell, keep going.’
Winston Churchill

From: Alan Shore
Sent: Wednesday, July 14, 2021 2:47 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>>
Subject: RE: [EXTERNAL] Re: Analyzing RUNSQLSTMT jobs

Thanks for your reply Vern
As it happens – the logicals have already been promoted to production
However, I can still see what happens

Alan Shore
Solutions Architect
IT Supply Chain Execution

[cid:image008.png@01D77954.558E4580]

60 Orville Drive
Bohemia, NY 11716
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
E-mail : ASHORE@xxxxxxxxxxxxxxxxxxxx<mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx>

‘If you're going through hell, keep going.’
Winston Churchill

From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Wednesday, July 14, 2021 2:18 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: [EXTERNAL] Re: Analyzing RUNSQLSTMT jobs

Alan

The logicals might not get used - so be sure to do more analysis after
creating them. I wouldn't do them all, necessarily. If you have a test
environment, make the LFs or indexes there, look at the nodes in VE and
at the detail on the right, try to see which changes make sense to do -
just all automatic doesn't always help - you don't want indexes that
need to be maintained, if they don't help - now sometimes an index helps
to eliminate a direction for the optimizer to take - trade-off on
performance when writing or updating files vs. possible better
performance when reading as in this app.

Regards
Vern

On 7/14/2021 7:34 AM, Alan Shore via MIDRANGE-L wrote:

Hi Jack
Thanks for your e-mail
Yes – I did run Visual explain against it
First time that I had used it, so it took me some time
The result is that, from Visual explain I need to create 11 new logicals for access paths
As long as nobody objects – with a valid reason as to why – I will be moving them into production
From this document that you sent
https://www.ibm.com/docs/en/ssw_ibm_i_73/rzajq/rzajqpdf.pdf<https://www.ibm.com/docs/en/ssw_ibm_i_73/rzajq/rzajqpdf.pdf><https://www.ibm.com/docs/en/ssw_ibm_i_73/rzajq/rzajqpdf.pdf<https://www.ibm.com/docs/en/ssw_ibm_i_73/rzajq/rzajqpdf.pdf>>
It was suggested that the parameters on the RUNSQLSTM command needed to be changed
I will also be making those changes as well

Alan Shore
Solutions Architect
IT Supply Chain Execution

[cid:image003.png@01D7788B.1C65A650]

60 Orville Drive
Bohemia, NY 11716
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
E-mail : ASHORE@xxxxxxxxxxxxxxxxxxxx<mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx>

‘If you're going through hell, keep going.’
Winston Churchill

From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Jack Kingsley
Sent: Wednesday, July 14, 2021 6:25 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>>
Subject: [EXTERNAL] Re: Analyzing RUNSQLSTMT jobs

Alan, did you ever run visual explain against it.

On Tue, Jul 13, 2021 at 2:40 PM Timothy P Clark <timclark@xxxxxxxxxx<mailto:timclark@xxxxxxxxxx<mailto:timclark@xxxxxxxxxx%3cmailto:timclark@xxxxxxxxxx>>> wrote:

Hi Rick,

That scenario is a little trickier. QS only looks at individual queries,
not at the entire body of a procedure. It also depends on how unique the
signature of that troublesome SQL is. QS provides a number of knobs to let
you focus your thresholds down to a particular job/user/subsystem. As
well, there's a lot of information that gets passed to the exit program
that would allow it to do post-filtering before deciding to dump the
cached plan, etc. So I can imagine a situation where a particular workload
runs most queries most of the time in less than a second but you want to
log data about a query that departs from this normal behavior. In that
case you could set up a QS threshold for an elapsed time of three or five
seconds or whatever seems appropriate. You can also set thresholds for
I/O, CPU time or temp storage, if you suspect that overuse of those
resources is contributing to the troublesome query. In short, there's
probably some way to use QS to help with your situation, but it may
require some iterative tweaking (and more than the 15 minutes I advertised
in my earlier email.)

Hope that helps!

Tim Clark
DB2 for IBM i / SQL Optimizer


"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx>>> wrote on 07/13/2021
12:23:49 PM:

From: "Rick Rauterkus" <rick.a.rauterkus@xxxxxxxxxx<mailto:rick.a.rauterkus@xxxxxxxxxx<mailto:rick.a.rauterkus@xxxxxxxxxx%3cmailto:rick.a.rauterkus@xxxxxxxxxx>>>
To: "Midrange Systems Technical Discussion"

<midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx>>>,

Date: 07/13/2021 12:24 PM
Subject: [EXTERNAL] Re: Analyzing RUNSQLSTMT jobs
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx>>>

Sadly, still stuck at 7.2.

And not sure this would help. It's not a query running for 8 hours, it

is

a procedure with SQL that instead of taking a split second to complete

its

task like normal, it is taking several seconds. Called many 1000s of
times, adds up to the job taking 8 hours instead of 2 minutes. But

maybe

it could find something like that?


On Tue, Jul 13, 2021 at 11:38 AM Timothy P Clark <timclark@xxxxxxxxxx<mailto:timclark@xxxxxxxxxx<mailto:timclark@xxxxxxxxxx%3cmailto:timclark@xxxxxxxxxx>>>
wrote:

I could have not set this up better if I were paying you... And now

that

you've pushed the soapbox conveniently into place, I'll take just a

minute

to get up on it and say that scenarios like this are *exactly* the

reason

that IBM delivered the Query Supervisor in the most recent TRs for IBM

i

7.3 and 7.4.

With QS, you can set up a threshold for query elapsed time (e.g. 6

hours)

and then have an exit program that dumps any information about the

query

or the job you may be interested in. For example, I would start by

dumping

the cached query plan for the query and then comparing it to a fast
running plan. Did the plan change? Was an index advised? You could

also

dump the job stack to show whether you may be waiting for a resource.

Or

start job watcher for the job or dump Mimix status or...

In fact, you can probably set this up in under 15 minutes...

CALL QSYS2.ADD_QUERY_THRESHOLD(
THRESHOLD_NAME=>'6 hour queries',
THRESHOLD_TYPE=>'ELAPSED TIME',
THRESHOLD_VALUE=>6*60*60,
LONG_COMMENT=>'Detects queries that run for more than 6 hours');

Then go to

https://www.ibm.com/docs/en/i/7.4?topic=programs-exit-program-<https://www.ibm.com/docs/en/i/7.4?topic=programs-exit-program-><https://www.ibm.com/docs/en/i/7.4?topic=programs-exit-program-<https://www.ibm.com/docs/en/i/7.4?topic=programs-exit-program->>

dump-plan-cache-information-query

and pick your favorite programming language. Copy and paste the sample
program and build instructions.

Next time a query runs for 6 hours, you'll have a plan cache snapshot

in

the SUPERVISOR library containing only the query/queries that ran

long.

You can use the SQL performance center in ACS to import the snapshot

and

then Visual Explain the query.

And if you want to automatically kill the query, there is sample code

for

that, too:

https://www.ibm.com/docs/en/i/7.4?topic=programs-exit-program-end-query<https://www.ibm.com/docs/en/i/7.4?topic=programs-exit-program-end-query><https://www.ibm.com/docs/en/i/7.4?topic=programs-exit-program-end-query<https://www.ibm.com/docs/en/i/7.4?topic=programs-exit-program-end-query>>

Hope that helps!

Tim Clark
DB2 for IBM i / SQL Optimizer

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx>>> wrote on

07/13/2021

08:56:26 AM:

From: "Rick Rauterkus" <rick.a.rauterkus@xxxxxxxxxx<mailto:rick.a.rauterkus@xxxxxxxxxx<mailto:rick.a.rauterkus@xxxxxxxxxx%3cmailto:rick.a.rauterkus@xxxxxxxxxx>>>
To: "Midrange Systems Technical Discussion"

<midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx>>>,

Date: 07/13/2021 08:57 AM
Subject: Re: [EXTERNAL] Re: Analyzing RUNSQLSTMT jobs
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx>>>

We have had something very similar happen 3 or 4 times over the past

year.

Something that runs every day and takes about 2 minutes to complete

(an

inventory report to a customer), will suddenly one day take 8 hours

to

run. The job runs, and makes steady progress, but just really

slowly.

Looking at the call stack during a slow run, it shows the same spot

almost

every time, a procedure in a service program that is using embedded

SQL

to

extract some data from a file. This procedure is called for every

item.

During the last long run, we killed the job, and then immediately
resubmitted it, and it ran in its normal 2 minutes.

The only theory we could muster up is that for some reason when the

first

call to that procedure happened, the access path that the SQL

normally

used

was not available for some reason, so it ended up with a very much

less

efficient one. And was stuck with it for the duration of the job.

As

to

why it wouldn't be available, maybe the system was rebuilding the

index?

Maybe Mimix had it locked for whatever it was doing? We have found

nothing

to explain this either. We are considering changing the embedded

SQL to

RPG and see if the issue ever comes up again.


On Tue, Jul 13, 2021 at 7:58 AM Alan Shore via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx>>> wrote:

Hi everyone
Here is my latest quirk/conundrum
I ran the reorgs this past weekend and the SQL query that was

causing

me

heartache ran EXTRMELY quick on Sunday night, with no problems
However, the run on Monday night was STILL running in batch

Tuesday

morning – 11 hours later
Now heres the next kicker
I took a copy of the query that is being run, and changed it to

create

a

file in a different library and ran it interactively
It finished in under 2 minutes
I have NO idea what to look at or even where to start
Does anyone have ANY ideas or hunches
As always – ALL answers gratefully accepted

Alan Shore
Solutions Architect
IT Supply Chain Execution

[cid:image001.png@01D777C5.3A4B1220]

60 Orville Drive
Bohemia, NY 11716
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
E-mail : ASHORE@xxxxxxxxxxxxxxxxxxxx<mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx<mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx%3cmailto:ASHORE@xxxxxxxxxxxxxxxxxxxx>>

‘If you're going through hell, keep going.’
Winston Churchill

From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On

Behalf

Of Alan Shore via MIDRANGE-L
Sent: Tuesday, July 6, 2021 11:57 AM
To: Midrange Systems Technical Discussion

<midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx>>>

Cc: Alan Shore <ashore@xxxxxxxx<mailto:ashore@xxxxxxxx<mailto:ashore@xxxxxxxx%3cmailto:ashore@xxxxxxxx>>>
Subject: RE: [EXTERNAL] Re: Analyzing RUNSQLSTMT jobs

Thanks for your reply Mark

Re-use deleted records is NOT set on the files that I am looking

at. I

would DEFINITELY need to perform a RE-ORG on 3 files in particular

THEN

change them to re-use deleted records



Heres another question - hopefully you know the answer.

On at least 2 of the 3 files, there are some join logicals of BOTH

of

these 3 files

I was thinking of running 3 separate jobs at the same time doing a

re-org

on these 3 files

However - because of the join logicals - will that cause some

conflict

between the 2 re-orgs?




Alan Shore
Solutions Architect
IT Supply Chain Execution

[cid:image001.png@01D7725D.FBFDACB0]

60 Orville Drive
Bohemia, NY 11716
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
E-mail : ASHORE@xxxxxxxxxxxxxxxxxxxx<<mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx%3c<mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx%3c%3cmailto:ASHORE@xxxxxxxxxxxxxxxxxxxx%3c>>

mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx>

‘If you're going through hell, keep going.’
Winston Churchill

From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On

Behalf

Of Mark Waterbury
Sent: Tuesday, July 6, 2021 11:52 AM
To: Alan Shore via MIDRANGE-L

<midrange-l@xxxxxxxxxxxxxxxxxx<mailto:

<mailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:%0b>> <mailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:%0b>> > > > > midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx>>>>

Subject: Re: [EXTERNAL] Re: Analyzing RUNSQLSTMT jobs

Alan,

A "mass purge" of database records could impact your applications
performance if those physical files are not using REUSEDLT(*YES),

so

that a

RGZPFM is needed to reorganize the PF member(s) to reclaim the

space

used

by the deleted records.

After such a RGZPFM, any and all Logical File access paths over

those

PF

members need to be updated; if the Logical Files (or physical

files

with

keys) were not set to MAINT(*IMMED), this access path rebuild will

occur on

the next OPEN of that file. This could significantly slow down

your

applications, the first time each file is used after such a

"re-org."

HTH,

Mark S. Waterbury

On Tuesday, July 6, 2021, 11:30:44 AM EDT, Alan Shore via

MIDRANGE-L

<

midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx>>

<mailto:

<mailto:%0b>> <mailto:%0b>> > > > >

midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx%3cmailto:midrange-l@xxxxxxxxxxxxxxxxxx>>>>>

wrote:

Thanks for your reply Vern
I am wading my way through the document that Jack sent, and it's a

LOT

of

information to soak in
My problem is that a job that's presently running is still running

from

last night
Its been running for about 5 weeks or so - taking different times

to

complete - but NOTHING like it is today
However - in my analysis I have discovered that I believe a purge

was

recently run on a couple of the files
There are quite a number of deleted rows in these files
My question is - would the deleted rows impact SQL queries?
Forgive my ignorance as I haven't had a decent nights sleep in

quite a

few

days and Im not thinking straight

Alan Shore
Solutions Architect
IT Supply Chain Execution

60 Orville Drive
Bohemia, NY 11716
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
E-mail : ASHORE@xxxxxxxxxxxxxxxxxxxx<<mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx%3c<mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx%3c%3cmailto:ASHORE@xxxxxxxxxxxxxxxxxxxx%3c>>

mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx

<

mailto:ASHORE@xxxxxxxxxxxxxxxxxxxx%3cmailto:ASHORE@xxxxxxxxxxxxxxxxxxxx>>

'If you're going through hell, keep going.' --Winston Churchill

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx%3cmailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx>>
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l<https://lists.midrange.com/mailman/listinfo/midrange-l><https://lists.midrange.com/mailman/listinfo/midrange-l<https://lists.midrange.com/mailman/listinfo/midrange-l>>
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx%3cmailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx>>
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l<https://archive.midrange.com/midrange-l><https://archive.midrange.com/midrange-l<https://archive.midrange.com/midrange-l>>.

Please contact support@xxxxxxxxxxxxxxxxxxxx<mailto:support@xxxxxxxxxxxxxxxxxxxx<mailto:support@xxxxxxxxxxxxxxxxxxxx%3cmailto:support@xxxxxxxxxxxxxxxxxxxx>> for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com<https://amazon.midrange.com><https://amazon.midrange.com<https://amazon.midrange.com>>

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx%3cmailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx>>
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l<https://lists.midrange.com/mailman/listinfo/midrange-l><https://lists.midrange.com/mailman/listinfo/midrange-l<https://lists.midrange.com/mailman/listinfo/midrange-l>>
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx%3cmailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx>>
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l<https://archive.midrange.com/midrange-l><https://archive.midrange.com/midrange-l<https://archive.midrange.com/midrange-l>>.

Please contact support@xxxxxxxxxxxxxxxxxxxx<mailto:support@xxxxxxxxxxxxxxxxxxxx<mailto:support@xxxxxxxxxxxxxxxxxxxx%3cmailto:support@xxxxxxxxxxxxxxxxxxxx>> for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com<https://amazon.midrange.com><https://amazon.midrange.com<https://amazon.midrange.com>>

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l<https://lists.midrange.com/mailman/listinfo/midrange-l>
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l<https://archive.midrange.com/midrange-l>.

Please contact support@xxxxxxxxxxxxxxxxxxxx<mailto:support@xxxxxxxxxxxxxxxxxxxx> for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com<https://amazon.midrange.com>
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com