Well, in this case, they ARE read-only. The members in QSYSINC cannot be
changed by us mortals. And this looks like normal behavior.

The problem I have is with how it is handled - having it look like a "hard"
error when it isn't. And that it works differently between the 2 editors.


At 12:46 PM 10/15/02 -0400, you wrote:
I've noticed that many communications errors or abnormal terminations cause
other problems.

If CODE crashes and I go back to the recently-used list to re-open the
member, it often opens as read-only, and subsequent used of the entry on the
RUL also open the member as read-only.  Even after I go into the iSeries and
kill the server job (WRKOBJLCK is my most popular CODE command), it still
opens in the RUL as read-only.  My conclusion is that the RUL contains a
status bit indicating read-only; I have to use the command line and the "LX"
macro to open the member in update mode.  That open replaces the read-only
entry in the RUL.


-----Original Message-----
Subject: [WDSCI-L] Opening system includes

Got a little funky behavior today. I have member filters for the system
includes, QSYSINC/H and QSYSINC/MIH. When I open a member with LPEX, I get
an error, saying it is read-only. Well, that's true, but it's disconcerting
to have it handled this way. It looks like a hard error, then it goes ahead
and opens it read-only.

This does not happen, using the opening with CODE.


Vern Hamberg

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.