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
+---