RE: Object authority -- MIDRANGE-L

If the objective is to allow programmers to do anything but delete the file, try setting the programmer authority to the library to *USE. Then the file authority would be basically *CHANGE with *OBJMGT added. That allows members to be added, cleared. That's not perfect as you can't remove members. No other objects can be added to the library or changed. This works on 7.3 with the exception of removing a member. If members must be removed by programmers, you would have to adopt authority.

But if programmers can clear all the members on a production file, they might as well be able to delete the file. We never allow programmers more than *USE authority on production data.

Michael Quigley
Computer Services
The Way international
www.TheWay.org

-----Original Message-----
----------------------------------------------------------------------
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf
Of Wim Jongman
Sent: Sunday, June 12, 2022 5:37 AM
To: Midrange Systems Technical Discussion <midrange-
l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Object authority

[You don't often get email from wim.jongman@xxxxxxxxxxxxxxxxxx. Learn
why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the
content is safe.

I am looking for a very specific solution of that blocks the
manipulation of objects (creating, deleting, renaming) while still
allowing the use of member commands like ADDPFM, RNMM, and RMVM.

There is no practical difference between DLTF FILE(LIB/FILE) and RMVM
FILE(LIB/FILE) MBR(*ALL)

It appears that IBM has tied the execution of the member commands to
the authority of the file AND LIBRARY which makes no sense to me.

From your story, your programmers do not see the complete picture of their
actions. In that case, you have no choice but to block the library and only
allow access via the change management software (which probably needs
replacing if your programmers are dodging it).

To manipulate members in this restricted environment, you create specific
commands that adopt authority to allow access to the members, or do as Rob
suggested; assign specific authority to certain commands. The latter will be
system-wide, so it also affects other libraries.

Best regards,

Wim Jongman

Embrace Change. Remain In Control.
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Frem
ainsoftware.com%2F&data=05%7C01%7Cmichaelquigley%40theway.org
%7C82ec08a1eba040c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b
6650f%7C0%7C0%7C637907251488984278%7CUnknown%7CTWFpbGZsb3d8e
yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
%7C3000%7C%7C%7C&sdata=yCMqkNRBJNM6aC0h3e%2Feqtp9jIzbVZ3
mXKb09W3%2FKKA%3D&reserved=0

--
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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
midrange.com%2Fmailman%2Flistinfo%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=y%2FAltTuA2VsmILcmaZZQqP0s7k2Zw7CO%2Bci3nb0qW8A%
3D&reserved=0
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchi
ve.midrange.com%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=aE83s6nlgL1S5ZwCXD8PigqcR9y7mEyqKfaWzv8Cs1Y%3D&am
p;reserved=0.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fama
zon.midrange.com%2F&data=05%7C01%7Cmichaelquigley%40theway.o
rg%7C82ec08a1eba040c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4
b6650f%7C0%7C0%7C637907251488984278%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C3000%7C%7C%7C&sdata=ERkBfF%2FFdrowEhlaVpH2%2B8L9CKmv
n6%2FQ2yqKlU6vudk%3D&reserved=0

------------------------------

message: 2
date: Mon, 13 Jun 2022 11:17:20 +0000
from: Rob Berendt <rob@xxxxxxxxx>
subject: RE: Open cursor, fetch all, close cursor, process, open same
cursor with same statement, fetch all, no data !

I'm curious as to what extra work gets processed by the F5 because,
obviously, SQL cares not a whit about screen function keys.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
.dekko.com%2F&data=05%7C01%7Cmichaelquigley%40theway.org%7C
82ec08a1eba040c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650
f%7C0%7C0%7C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWI
joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
000%7C%7C%7C&sdata=%2FpuLK9WCeRMkaxeWrRtzHxONrxnatLEFrm
kYtLGkkj4%3D&reserved=0

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf
Of Alan Cassidy
Sent: Friday, June 10, 2022 10:16 AM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Open cursor, fetch all, close cursor, process, open same cursor with
same statement, fetch all, no data !

CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the
content is safe.

A colleague at work helped me resolve the datetime problem (posted in
midrange-L list) by setting the date and time format in both the RPG ctl-opt
to *ISO, and in EXEC SQL SET OPTION DATFMT = *ISO.

So now I get data in the cursor. I use FETCH NEXT for up to 5000 rows to get
all the selected rows for the subfile.

That works.

But then I do an F5 to clear the data and get fresh data. It changes fast with
the team pounding on it, and the date-relevant data get processed. Then I
close the cursor. FWIW, the SQL statement for the cursor is based on an SQL
View object.

So the program enables F5 to refresh the screen.

*Here is the issue:*

So the user (me, testing) presses F5 to refresh the screen. It opens the
same-named cursor again, okay, but the FETCH returns SQLCODE = 100.
That's after /closing/ the cursor --EXEC SQL CLOSE M1-- and then opening it
again. So I get an empty subfile with zero subfile lines.

But F5 to refresh again, and voila! The data is back!

_(1) Is there a value in the SQLCA after the first OPEN that has the cursor
open at the end of data? _

I'm going to clear the SQLCA data when I close the cursor, or before I reopen
it, and see if that fixes this, but I'd like to hear from somebody who knows.

_(2) The cursor SELECTs from an SQL View. Each time the View runs it would
have changed data. _

_Would opening this cursor as DYNAMIC SENSITIVE SCROLL be a good
solution, _so when I do an F5 on the subfile screen, I can position it back to
whatever is the current first row in the cursor (i.e. which would also be the
first row in the View)/

--
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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
midrange.com%2Fmailman%2Flistinfo%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=y%2FAltTuA2VsmILcmaZZQqP0s7k2Zw7CO%2Bci3nb0qW8A%
3D&reserved=0
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchi
ve.midrange.com%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=aE83s6nlgL1S5ZwCXD8PigqcR9y7mEyqKfaWzv8Cs1Y%3D&am
p;reserved=0.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fama
zon.midrange.com%2F&data=05%7C01%7Cmichaelquigley%40theway.o
rg%7C82ec08a1eba040c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4
b6650f%7C0%7C0%7C637907251488984278%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C3000%7C%7C%7C&sdata=ERkBfF%2FFdrowEhlaVpH2%2B8L9CKmv
n6%2FQ2yqKlU6vudk%3D&reserved=0

------------------------------

message: 3
date: Mon, 13 Jun 2022 13:51:58 +0000 (UTC)
from: Mark Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>
subject: Re: Object authority

Hi, John,?

I do not think you should need to "... rewrite security on the machine."

It should require only a few carefully thought out (and then tested)
"adjustments" to the current set-up.

For example, for those few programs that issue ADDPFM, RMVM or RNMM,
just ensure those *PGMs are owned by the "application owner" and that
application owner also owns the library containing those files, and the *FILE
objects in that library, and ensure that those programs are compiled with
USRPRF(*OWNER) so they adopt owner authority.

It should be possible to do this without disturbing much else.

Of course, testing is necessary.? It is fortunate that you have a "test-bed" or
"sand-box" system in your basement, so you can set up a subset of the
actual "live" environment, with perhaps a few representative "users" and
test each proposed change, one by one, to ensure there are no adverse
impacts or unintended consequences.

Also,? you really should become very familiar with IBM i security and
authorization, as you said you are developing a "change management"
toolset.? Ideally, a change management product, properly implemented,
should automatically enforce and support such "good practices," while
preventing developers from bypassing the established "rules" of proper
change management.

Let me know if you have any other questions, or if I can offer some added
assistance.??

All the best,
Mark S. Waterbury

On Friday, June 10, 2022, 06:46:46 PM EDT,
<smith5646midrange@xxxxxxxxx> wrote:

I appreciate all of the input that I have gotten but I am not looking to rewrite
the security on the machine.

I am looking for a very specific solution of that blocks the manipulation of
objects (creating, deleting, renaming) while still allowing the use of member
commands like ADDPFM, RNMM, and RMVM.

It appears that IBM has tied the execution of the member commands to the
authority of the file AND LIBRARY which makes no sense to me.? I was sure
that I was missing something in the combination but it does not appear that I
am.

And to further clarify, I am trying to prevent the developers from screwing
up their own environment which is breaking the testing for other
developers.
It is stupid stuff like the renaming a PF and creating a new one but not
changing the logicals so they are still pointing to the old file.? The change
management software handles this so if they used it, there wouldn't be a
problem.

Production is a whole other story that I don't have the energy to fight so I'm
not going to bother.? Besides, they will get reprimanded for breaking
production but nobody cares if they break the test environments.

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf
Of vforbes@xxxxxxxxx
Sent: Friday, June 10, 2022 11:49 AM
To: 'Midrange Systems Technical Discussion' <midrange-
l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Object authority

The best method is having production on one box/partition & development
on another.

Adopting authority programs should not be needed.

This is one method of setting security.? This may not be complete, but it is a
start.

Create new 'Group' user profiles.? APPUSER, APPOWNER, PGMR.? These ids
have no password & cannot sign on.
Change developers to be part of the Grpprf PGMR, App users to the Grpprf
APPUSER Create an AUTL (authorization lists).? I.e. PROD ??? Add PGMR to
this Autl with only *USE access if you want problem support or *NONE if you
don't want them to even see it.
??? Add APPUSER to this Autl with either *CHANGE or *ALL access.? You
need to test this.
Revoke *ALL authority to *ALL users to all 'Production' objects & libs.
Leave IBM libs alone.? Do this after hours.
Change the owner of all 'Production' objects & libs to a new id APPOWNER
Grant authority to all 'Production' objects & libs to the Autl PROD.? Any
future authority changes are done in the Autl.? I.e. adding a 'FireFight'
id.

Make a copy of production libs for developers.?
Create new Autl DEV
??? Add PGMR to this list with only *CHANGE or *ALL access Restore prod
libs to new names Change obj & lib Autl to new Autl DEV Optional, you may
want to create a 'Sterilization' program to mask things like account SIN, name,
address etc.

Vincent

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf
Of dr2@xxxxxxxx
Sent: June 9, 2022 3:40 PM
To: Midrange Systems Technical Discussion <midrange-
l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Object authority

Among other things I would look at using programmes that adopt
authority...and firing a few programmers....

On 2022-06-09 14:42, smith5646midrange@xxxxxxxxx wrote:

We are having problems with developers "installing" new objects
outside of the change management software and also renaming existing
objects and creating new versions of them.

We are an IP based company so we rely heavily on adding and removing
PF and LF members.

Is there a level of security that I am overlooking that will allow us
to lock down a library to prevent the creation of new objects and the
renaming of existing objects yet still allow the ADDPFM/ADDLFM and
RMVM

commands?
--
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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
midrange.com%2Fmailman%2Flistinfo%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=y%2FAltTuA2VsmILcmaZZQqP0s7k2Zw7CO%2Bci3nb0qW8A%
3D&reserved=0
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchi
ve.midrange.com%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=aE83s6nlgL1S5ZwCXD8PigqcR9y7mEyqKfaWzv8Cs1Y%3D&am
p;reserved=0.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fama
zon.midrange.com%2F&data=05%7C01%7Cmichaelquigley%40theway.o
rg%7C82ec08a1eba040c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4
b6650f%7C0%7C0%7C637907251488984278%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C3000%7C%7C%7C&sdata=ERkBfF%2FFdrowEhlaVpH2%2B8L9CKmv
n6%2FQ2yqKlU6vudk%3D&reserved=0

--
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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
midrange.com%2Fmailman%2Flistinfo%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=y%2FAltTuA2VsmILcmaZZQqP0s7k2Zw7CO%2Bci3nb0qW8A%
3D&reserved=0
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchi
ve.midrange.com%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=aE83s6nlgL1S5ZwCXD8PigqcR9y7mEyqKfaWzv8Cs1Y%3D&am
p;reserved=0.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fama
zon.midrange.com%2F&data=05%7C01%7Cmichaelquigley%40theway.o
rg%7C82ec08a1eba040c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4
b6650f%7C0%7C0%7C637907251488984278%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C3000%7C%7C%7C&sdata=ERkBfF%2FFdrowEhlaVpH2%2B8L9CKmv
n6%2FQ2yqKlU6vudk%3D&reserved=0

--
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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
midrange.com%2Fmailman%2Flistinfo%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=y%2FAltTuA2VsmILcmaZZQqP0s7k2Zw7CO%2Bci3nb0qW8A%
3D&reserved=0
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchi
ve.midrange.com%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=aE83s6nlgL1S5ZwCXD8PigqcR9y7mEyqKfaWzv8Cs1Y%3D&am
p;reserved=0.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fama
zon.midrange.com%2F&data=05%7C01%7Cmichaelquigley%40theway.o
rg%7C82ec08a1eba040c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4
b6650f%7C0%7C0%7C637907251488984278%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C3000%7C%7C%7C&sdata=ERkBfF%2FFdrowEhlaVpH2%2B8L9CKmv
n6%2FQ2yqKlU6vudk%3D&reserved=0

------------------------------

Subject: Digest Footer

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) digest list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
midrange.com%2Fmailman%2Flistinfo%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=y%2FAltTuA2VsmILcmaZZQqP0s7k2Zw7CO%2Bci3nb0qW8A%
3D&reserved=0
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchi
ve.midrange.com%2Fmidrange-
l&data=05%7C01%7Cmichaelquigley%40theway.org%7C82ec08a1eba04
0c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4b6650f%7C0%7C0%7
C637907251488984278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=aE83s6nlgL1S5ZwCXD8PigqcR9y7mEyqKfaWzv8Cs1Y%3D&am
p;reserved=0.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fama
zon.midrange.com%2F&data=05%7C01%7Cmichaelquigley%40theway.o
rg%7C82ec08a1eba040c4379708da4d43f2ae%7Cdfc3789155b94fe0bc8b34a0f4
b6650f%7C0%7C0%7C637907251488984278%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C3000%7C%7C%7C&sdata=ERkBfF%2FFdrowEhlaVpH2%2B8L9CKmv
n6%2FQ2yqKlU6vudk%3D&reserved=0

------------------------------

End of MIDRANGE-L Digest, Vol 21, Issue 720
*******************************************