Re: Ignore *SYSTEM state of objects?? Search 400 article.

Right on! I second that!

Sadly, I do know that there are still vendors shipping "patched" code... :-o
(Buyer beware...)

----- Original Message -----
> From: "James H H Lampert" <jamesl@xxxxxxxxxxx>
> To: <midrange-l@xxxxxxxxxxxx>
> Sent: Tuesday, April 06, 2004 3:40 PM
> Subject: RE: Ignore *SYSTEM state of objects?? Search 400 article.
>

> >> As an aside, if you're in SST to do this frequently, it's much less
> >> time consuming to modify the SLIC module that actually does the
> >> checking of states/domains and 'turn' the checking off once and for
> >> all...
> >
> > Is this a good thing to do? I would think that circumventing IBM's
> > security would be less than desireable.
>
> I second that. Hacking programs to system state may be a common technique
> among SOME MI programmers, but it's one for which I've done my best to
> remain ignorant of the details, because (1) nearly everything I write is
> part of some commercial product that's expected to be
> Security-50-friendly, and (2) commercial products with hacks in them (the
> only reason I know of to patch to system state) tend to be less reliable
> (and less trusted) than those that stick to supported APIs.
>
> While I still think it ridiculous to keep a system locked up with
> QFRCCVNRST set so high it won't accept non-observable programs compiled on
> an earlier release, this is a genuine security threat, and if some vendor
> is still putting out commercial products (or custom jobs, for that matter)
> that aren't Security-50-friendly, you're probably better off looking for a
> different software vendor.
>
> --
> JHHL
>
>
> _______________________________________________
> 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.
>