× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



It allows you to free the storage associated with infrequently used objects.
When an application needs the object an exit program can be called to
restore the object. Following the restore the application program then
continues with its processing. I believe it was refered to, in the past, as
nearline storage.

Bruce

On Mon, Dec 7, 2009 at 11:13 AM, Graap, Kenneth <Kenneth.Graap@xxxxxxxxxxxxx
wrote:

Does anyone utilize the STG(*FREE) option that is available on most of the
SAV commands?

The reason I ask is that having access to the SAV* commands and also having
*SAVSYS Special Authority, gives a user the authority to effectively delete
any object on the system, by using the STG(*FREE) parameter.

Example -

SAVOBJ OBJ(UFILE1)
LIB(PRODLIB)
DEV(*SAVF)
OBJTYPE(*FILE)
SAVF(MYLIB/MYSAVFILE)
UPDHST(*NO)
STG(*FREE)

DLTF FILE(MYLIB/MYSAVF)

Being able to save objects that a programmer or operator doesn't have
direct authority to, may be a useful function that Special Authority *SAVSYS
addresses, but the security risk associated with STG(*FREE) makes giving
this authority to anyone extremely risky.

I understand that there are ways to mitigate this risk. The easiest is to
severely restrict who gets *SAVSYS Special Authority OR restrict access to
the SAV* commands OR force STG(*KEEP) via an exit or validity checking
program.

But if there isn't really any reason to free storage in the first place, we
wouldn't have to worry about this security risk at all...

This is why I'm wondering what the original purpose of having the
STG(*FREE) option might have been...

Is this something IBM should consider removing from the SAV commands?

Discussion ... Comments ????


P
Please consider the environment before printing this email

Kenneth
Kenneth E. Graap
Systems Administrator
NW Natural
keg@xxxxxxxxxxxxx<mailto:keg@xxxxxxxxxxxxx>
http://www.linkedin.com/in/kennethgraap
503-226-4211 x5537

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





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