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


  • Subject: RE: System values vs. the registry (Was: What counts as technically slick?)
  • From: Jim Damato <jdamato@xxxxxxxxxxxxxxxxx>
  • Date: Mon, 9 Apr 2001 20:59:01 -0500

> altering the configuration is neither supported nor documented.


"big words. If not documented, how come we know about it..."



You're joking.  You claim "big words" then spout off on an irrelevant Tale
of Two Cities on accessing encapsulated internals.  Please don't be
selectively stupid.

"How come we know about it..."  -  Because it was announced.  As part of the
announcement they also announced that they would not, for the time being, be
documenting a means of turning this security change on or off (altering the
configuration).  You fully understood what I said, you're just misdirecting
and changing the subject.  There's a huge difference between supported,
documented, integrated system values and the often at-your-own-risk nature
of the registry.  This is my only point.  You'd gain a bit more respect if
you'd concede before you change the subject.



-----Original Message-----
From: Leif Svalgaard [mailto:leif@leif.org]
Sent: Monday, April 09, 2001 7:26 PM
To: MIDRANGE-L@midrange.com
Subject: Re: System values vs. the registry (Was: What counts as
technically slick?)


From: Jim Damato <jdamato@dollargeneral.com>
> (Do I dare contradict Leif Svalgaard more than once?)

you are not the only one :-)

>
> "Editing the registry is not much harder than fiddling with system
values."
> Yeah, right.  Most MCSE's approach the registry with the appropriate fear

I'm no MCSE, and I have no problems with the registry, nor fear..

>
> "it is next to impossible to disable the feature ... The only way to
disable
> the feature is to patch OS/400."
>
> You deliberately didn't choose QALWOBJRST for your example.

most of the things I do are deliberate   :-)


>(I'm still trying to FIND the
> QVFYOBJRST value).

V5R1 !

This new value is to "fix" the problem that IBM thought that the
program validation value algorithm would remain secret forever.
But security by "obscurity" doesn't work.

The deep architectural problem with system-state is that most of
MY (and everybody else's) private objects are placed by OS/400
in the system domain rather than in the user domain where they belong.
This is done to prevent me from accessing the internals of the object.
The word is that the objects are "encapsulated". This is fine if
there are APIs to do and access what I want. But there are just
so many things people want and need (sometimes justified and
sometimes silly) that there never are going to be APIs for everything
(there are already several thousand).

If you need an AP,I IBM will tell you one of:
1) there is no business need (for IBM) for the new API
2) APIs are expensive (for IBM) and your are not gonna get it
3) IBM will tell you about and let you use one of their internal APIs
provided you sign an agreement not to even disclose that the
API exists.
4) You may get the API in a future release (doing your no good now)
5) the list goes on

So, many people (and many vendors) roll their own,
requiring their programs to be system-state for no other
reason. But system-state programs are *too* powerful",
e.g. capable of circumventing security. This is the flaw.

Therefore you end with this "cat-and-mouse" game
where IBM comes up with yet a new way of preventing
you to go system-state [we may note in passing without
implying that this is really so :-) that making it more
difficult to go system-state also nicely excludes serious
competition] and you again and again breaking the scheme
just to stay in business.

>
> My point was that the system values are supported, documented, integrated
> entry points into the system.  Microsoft's new "feature" is a hack for
which
> altering the configuration is neither supported nor documented.


big words. If not documented, how come we know about it...

> They've worked out a quick fix to a high-profile problem.

same thing with IBM. Another quick IBM fix in V5R1 is the new
128-character password facility. As if anyone would use
a password like
"Qe%4&:jKKx
9)-=#4!2#fg^./saqpTh&8!2%~]\H99MmSe$3<.//S3BVCCbGt(8*3$5^@11#dFefGhyYIfDf"
this is only about HALF of the 128 allowed.

As IBM notes: this new facility is optional, "But for seamless integration"
with Windows they recommend people to stay with the old.
Now, most people have no choice than to want seamless integration
with windoze.


Leif




+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.