|
If you use V5R1 as shipped, you will only have access to the first 25 libraries on the list. If you use additional libraries beyond 25, you are subject to having programs bomb. 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: RE: 250 libraries again (was V3R1 QUSRTOOL, *PRDLOD) owner-midrange-l@mi drange.com 05/29/01 02:22 PM Please respond to MIDRANGE-L As near as I can tell from your reply, the answer to: > "Will the programs bomb if I leave my user library list as-is, or will the programs bomb just from the upgrade to V5R1?" ...is that the programs will run just fine on V5R1 if I leave my library list as-is. The problem comes when I expand my library list to beyond the variable length defined in the legacy CL. Right or wrong? -Jim James Damato Manager - Technical Administration Dollar General Corporation (615) 855-4375 <mailto:jdamato@dollargeneral.com> -----Original Message----- From: barsa@barsaconsulting.com [mailto:barsa@barsaconsulting.com] Sent: Tuesday, May 29, 2001 12:28 PM To: MIDRANGE-L@midrange.com Subject: Re: 250 libraries again (was V3R1 QUSRTOOL, *PRDLOD) 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 +--- +--- | 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.
midrange.com
