RE: Modify SYSVAL QSYSLIBL (Walden)

["Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>]

And even then the command objects are normal command objects with two
differences.

1) Service data at offset x31 shows V4R4M0 instead of V5R1M0 (on a V5R1
machine)

2) The SEPT entry for the command processing program is missing so normal
object resolution would be used to find the CPP if you could call it. The
second difference surprises me since I didn't think the SEPT could change
between releases since SEPT entry numbers are hardcoded in programs so why
bother blanking them out?

-Walden


------------
Walden H Leverich III
President
Tech Software
(516)627-3800 x11
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com



-----Original Message-----
From: barsa@barsaconsulting.com [mailto:barsa@barsaconsulting.com]
Sent: Tuesday, December 18, 2001 09:47
To: midrange-l@midrange.com
Subject: RE: Modify SYSVAL QSYSLIBL (Walden)



Frank,

I agree with Walden, but please look closely.  There is nothing different
about the *PRV libraries.  The difference is in the command objects that
they contain, which cannot be executed.

As a user community, we could ask IBM for an attribute in the *LIB object
that prevents them from being in QSYSLIBL or QUSRLIBL, but I think that is
too much to ask for, and IBM has bigger fish to fry.  As I indicated
yesterday, I spoke with a developer in Rochester, and as he said, someone
has to take some responsibility!

Al

Al Barsa, Jr.
Barsa Consulting Group, LLC

400>390

914-251-1234
914-251-9406 fax

http://www.barsaconsulting.com
http://www.taatool.com






                    Frank.Kolmann@revlo
                    n.com                     To:
midrange-l@midrange.com
                    Sent by:                  cc:
                    midrange-l-admin@mi       Subject:     RE: Modify SYSVAL
QSYSLIBL (Walden)
                    drange.com


                    12/17/01 10:06 PM
                    Please respond to
                    midrange-l






>From: "Walden H. Leverich" <WaldenL@TechSoftInc.com>
>
>There is nothing "special" about the *PRV libraries, they are normal
>everyday libraries from an object point of view. The change you're
>suggesting would require a change to every piece of the system that
>deals with library lists and since we just had one of those at V5R1 I
>don't
think
>you'll find Rochester too egger to make another such change anytime
>soon.
>
>-Walden

I beg to differ.  Try running a command out of a *PRV lib.
If the system has the info to prevent commands being executed then it has
the info to prevent the *PRV lib being added to the LibL. Is there not a
check presently to validate that a library in fact exists, then how hard is
it to put in a check to ensure the library is of the right type.

Frank Kolmann

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
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@midrange.com To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.