|
midrange.com
This is a modified version of a page that I presented at COMMON.
V5R1 Library List Enhancement:
The correct spelling of the word "enhancement" is "fiasco".
In response to numerous customer and ISV requests, IBM is increasing the
length of the user portion of the library list from 25 to 250 libraries
effective in V5R1. Although IBM developers understand that this change
will impact some users, they contend that this is in the best interest of
the long-term interest of the platform. This would be the significant
first change in the history of the System/38, AS/400, iSeries platform that
will break users code, forcing you to make changes to keep existing
applications working in the event that those application encountered more
than 25 libraries on the user's portion of the library list.
The following is an example of some pseudo code that would have to
ultimately be changed:
DCL VAR(&USRLIBL) TYPE(*CHAR) LEN(275)
DCL VAR(&CMD) TYPE(*CHAR) LEN(6000)
RTVJOBA USRLIBL(&USRLIBL)
CHGLIBL LIBL(MYLIB1 MYLIB2 QGPL QTEMP)
/* Do my thing, sing my song, yada, yada, yada */
CHGVAR &CMD ('CHGLIBL LIBL(' *CAT &USRLIBL *TCAT ')')
CALL PGM(QCMDEXC) PARM(&CMD 6000)
If you did not have access to your source code, or did not have support
from your ISV, the above code would break. Retrieving a user library list
into a variable of insufficient length would cause a new escape message of
CPF098A.
To minimize the impact of this change, IBM has created a new data area in
V5R1 (QLILMTLIBL in QUSRSYS) that acts as a system wide switch only
allowing access to the first 25 libraries in the all commands that support
a library list parameter. Prior to COMMON, IBM told me that "The data area
will not be shipped in V5R2, and in fact will be deleted when you install
V5R2. You have the option of saving and restoring it after the install of
V5R2, or recreating it. The functionality of the data area will be honored
in V5R2, but not in any follow-on release." At COMMON, when asked about
this at Soundoff, IBM waffled, indicating that they did not know what their
future plans were.
Detailed documentation about this change can be found at:
http://www.iseries.ibm.com/developer/os400/lib_list.html
Here's a copy of (a portion of) my remarks that I made at Soundoff at
COMMON:
Today I intend to talk about two topics, and as usual the first will be
technical, and the second marketing.
I've been spending the last few months studying the next release of OS/400,
V5R1, and I am pleased to report that this looks to be a very feature rich
release.
However, I have noticed a few issues which I predict will cause users
problems, some minor and confusing, others major which will break many
users.
The first confusing problems involve the addition of the new user profiles
in DST, which have now been extended into SST. Whereas enhanced security
is a good thing, users will have to know about two different types of user
profiles, DST user profiles and OS/400 user profiles. The DST user
profiles have their own set of rules, including case sensitive passwords
with other rules inconsistent with your other rules from OS/400.
I can foresee that this will confuse users, and untrained third party
hardware maintenance vendors. If you sign into SST for the first time, and
sign on as QSECOFR with your old password, which you may, or may not have
changed, you will fail to sign on. Being perplexed, you will retry, and
once again you will fail. Give it one more try, and the password becomes
disabled. Of course, unless you read the detailed documentation, no where
did it tell you that your old password was in upper case, and in V5R1 the
password is case sensitive.
So now you have to reset your SST password, and nowhere does the help or
documentation for the CHGDSTPWD command mention that it also resets the
passwords for SST. For that matter, you can now create your own user
profiles in DST and SST, which are completely different from OS/400 user
profiles, which have different passwords and likely have other password
rules. Of course, the DST and OS/400 passwords never have to be the same,
unless you use the new LPAR APIs, in which case they must be identical.
I don't know who came up with this brilliant design, but we provide many
thanks for the adventure and award one gift certificate redeemable at the
Mayo Clinic for one lobotomy.
The DST/SST password issue is just confusing. But now let's talk about the
enhancement in V5R1 that will break your existing code.
This is a doosey. Never before, in the 22-year history of this platform
have you ever made a system enhancement that will break existing code, ah
but who knows, maybe copying Microsoft techniques might be a good thing.
At first blush, it sounds like increasing the size of the user library list
from 25 to 250 libraries is a great thing. But then when you realize that
every instance of the RTVJOBA (Retrieve Job Attributes) command where you
specify the USRLIBL (user library list) parameter will have to be re-coded
to allow a longer variable, or else Retrieve Job Attributes will get a new
escape message for having a return variable that is too short if you have
more than 25 libraries in your list.
At my personal insistence, to minimize the impact, the system provides a
switch at the system level to limit the length of the user portion the
library list to 25 libraries, but not the job level. You have announced
that this switch is turned on in V5R1, but will be turned off in V5R2.
Some software vendors will make you turn off the switch in V5R1, and this
will break software that you have not modified or from other vendors, and
at no time in the future does the system ever plan any support for this at
the job level.
A system design change of this magnitude requires a new job attribute for
long or short library list support, which should default from a job
description, and ultimately a system value. If you don't have your source,
or don't own SEU, or don't have the skills to make the fix, you will break
in V5R2 (if not before).
I really want to thank you for this enhancement. It's like kind of
creating your own Y2K problem. The difference with this and Y2K is that
you created it, rather than inherited it from Pope Saint Gregory. Many
customers will have to spend money to remediate this problem. I look
forward to this remediation work, as I plan on sending my kids to very
expensive colleges.
For this brilliant enhancement, we provide no award. The people who dreamt
this up have obviously already been to Mayo for their lobotomies.
I cannot believe that for the first time in 22 years, you have gone out of
your way to break certain users code, and I urge you to add the appropriate
support to the system to avoid this.
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
Jim Damato
<jdamato@dollargene To:
"'MIDRANGE-L@midrange.com'" <MIDRANGE-L@midrange.com>
ral.com> cc:
Sent by: Subject: 250 libraries again
(was V3R1 QUSRTOOL, *PRDLOD)
owner-midrange-l@mi
drange.com
05/29/01 10:52 AM
Please respond to
MIDRANGE-L
Let me get this straight...
Are you saying the expansion to 250 libraries in the user library list is
only a problem on RTVJOBA if you expand your library list?
Suppose I have a legacy application with irretrievable CL source, coded
with
RTVJOBA statements using declared library variables of 255 characters or
less. Will the programs bomb if I leave my user library list as-is, or
will
the programs bomb just from the upgrade to V5R1?
-Jim
James Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@dollargeneral.com>
-----Original Message-----
From: barsa@barsaconsulting.com [mailto:barsa@barsaconsulting.com]
Sent: Saturday, May 26, 2001 2:55 PM
To: MIDRANGE-L@midrange.com
Subject: Re: V3R1 QUSRTOOL, *PRDLOD
If the variable provided is not sufficiently long enough to handle the
number of libraries in the list, then a new exception message is flagged.
There is a new TAA Tool that scans all of your source for the RTVJOBA
command, and it's used with the USRLIBL parameter, attempts to figure out
the length of that variable. It's not always possible. It also scans for
any of the four affected APIs.
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
"Steve Richter"
<srichter@AutoCoder To:
<MIDRANGE-L@midrange.com>
.com> cc:
Sent by: Subject: Re: V3R1
QUSRTOOL, *PRDLOD
owner-midrange-l@mi
drange.com
05/26/01 03:27 PM
Please respond to
MIDRANGE-L
>
>The longer library list does not cause compilation problems, only
execution
>time problems.
>
>Al
What are the execution time problems?
Steve
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com 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.
