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

WRKDBF includes a patched program UNDELM (read undeleted record).  It's
system state, patched code (forged pointer) and the correct checksums needed
to allow it to be restored.


Keith

----- Original Message ----- 
From: "Mark S. Waterbury" <mark.s.waterbury@xxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, April 06, 2004 2:51 PM
Subject: 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.
> >
>
> _______________________________________________
> 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.
>