RE: Modify SYSVAL QSYSLIBL -- MIDRANGE-L

First, given that there is a *NONE option on the CRTJOBD command for the
initial library list I think we can safely assume that a job will run w/o a
user portion.

Second, the SEPT is used for most system-level program resolution anyway so
I'd guess that changing the order of the system library list, or removing
entries from it for that matter, probably wouldn't kill a system. I'm not
saying that things wouldn't be all fuc*ed up, I'm sure the web server
wouldn't start, I don't think TCP would be to happy, etc. But I'm sure the
base jobs would come up perfectly fine. Mind you, I'm not about to test my
theory.

-Walden

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



-----Original Message-----
From: jt [mailto:jt@ee.net]
Sent: Monday, December 17, 2001 18:06
To: midrange-l@midrange.com
Subject: RE: Modify SYSVAL QSYSLIBL


Just to play "Devil's Advocate":

I'm was talking about a **production 400 system**, in my post below.  OTOH,
there are other ways to experiment with this, in other environments.

Sometimes it helps to approach a problem tangentially, meaning, not directly
head-on.  (Now I'm pre-supposing an actual **business need** to do something
like this, whereas follow-on posts indicated that wasn't so, in the
particular case of the original question.)

IF (big if) I had a business need to try something like this, I'd first see
if the system could run WITHOUT a SYSLIBL.  If I wasn't working on a
production computer, I'd consider experimenting with seeing if jobs could
run with only having entries in the USER portion of the *LIBL.  AFAIK,
there's nothing unique about the system, product, and *CURLIB portions of
the library list.  Just that they're always prior to the user portion.  So
this experiment would put all libraries on an equal footing, in the USRLIBL.
Which just eliminates a variable to deal with.


Now IF that worked, I'd consider (again, NOT on a production computer)
playing with the order of the system libraries.  At that point, I'd expect
the system to tank, but would have a fallback plan, prepared just for that
expected possibility.


IOW, I'm not opposed to experiementing with something, per se, IF there's
some possible business justification from the experimentation, and IF that's
in line with the risk and time involved in the experiment.


jt

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of jt
| Sent: Monday, December 17, 2001 10:27 AM
| To: midrange-l@midrange.com
| Subject: RE: Modify SYSVAL QSYSLIBL
|
|
| Al,
|
| Don't know what the precise odds are.  Maybe 50/50...?
|
| But I'm EXTREMELY risk-aversive, myself...  Even if the odds were a
| million to one, I wouldn't take that risk (on a production system).
| "Not gonna do it" because the recovery on a cratered system would
| surely not be worth any
| potential gain, that I can see from trying something like this.
|
|
| I'd like to other thoughts on the subject, though.
|
|
| jt
|
|
| | -----Original Message-----
| | From: midrange-l-admin@midrange.com
| | [mailto:midrange-l-admin@midrange.com]On Behalf Of
| | barsa@barsaconsulting.com
| | Sent: Monday, December 17, 2001 10:04 AM
| | To: midrange-l@midrange.com
| | Subject: RE: Modify SYSVAL QSYSLIBL
| |
| |
| |
| | If you attempt to "run" a command from QSYSV4R4M0, you get a
| | diagnostic message CPD0118, and an escape message of CPF0001.  My
| | thought
| is that if
| | you attempted to put this library higher in your library list that
| | QSYS, you likely might crater your system.  Anyone have thoughts????
| |
| | 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
| |
| |
| |
| |
| |
| |
| |                     "jt" <jt@ee.net>
| |                     Sent by:                  To:
| | <midrange-l@midrange.com>
| |                     midrange-l-admin@mi       cc:
| |                     drange.com                Subject:     RE:
| | Modify SYSVAL QSYSLIBL
| |
| |
| |                     12/16/01 11:59 PM
| |                     Please respond to
| |                     midrange-l
| |
| |
| |
| |
| |
| |
| | Frank,
| |
| | You wrote, "IBM should prevent the backwards compatibility libs
| | getting into the SYSLIBL."
| |
| | Ya...  I'd say I agree with that...!  Can users implement this
| | through security if IBM doesn't.  RVKOBJAUT, but then you need a
| | program that adopts, to run compiles...  Kludge...?  (Which I
| | pronounce
| kloooodge...;-)
| |
| | jt
| |
| | | -----Original Message-----
| | | From: midrange-l-admin@midrange.com
| | | [mailto:midrange-l-admin@midrange.com]On Behalf Of
| | | Frank.Kolmann@revlon.com
| | | Sent: Sunday, December 16, 2001 11:32 PM
| | | To: midrange-l@midrange.com
| | | Subject: Modify SYSVAL QSYSLIBL
| | |
| | |
| | | >I have not done this but I wonder what happens if
| | | >I modify QSYSLIBL to put QSYSV4R4M0 at the top,
| | | >on an OS at V4R5.   Warning do not be tempted to try.
| | | >Frank Kolmann
| | |
| | |
| | | >>DON'T DO IT.  QSYSV4R4M0 is a library provided for *PRV
| | | >>compilations
| | | only.
| | | >>Al
| | | >>Al Barsa, Jr.
| | |
| | | >I, and I'm sure Jerry too, agree completely.
| | | >
| | | >Didn't catch the REASON behind the question...  Maybe there's
| | | >another
| | way
| | | to
| | | >accomplish this, via LPAR.  But don't know the original
| | problem that was
| | | >being addressed.
| | | >
| | | >jt
| | |
| | | I dont have a reason as such. One of our programmers modified a
| | | jobs *LIBL (system portion) with CHGSYSLIBL. Could not even do a
| | | SYS REQ cancel, or SIGNOFF. It is simply something that is very
| | | easy to do and I suspect will disable the AS400.
| | | IBM should prevent the backwards compatibility libs
| | | getting into the SYSLIBL.
| | |
| | | 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.
| |
|
| _______________________________________________
| 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.