|
Note that CL programs and modules can be created in a fashion to not log CL commands! 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 "oludare" <oludare@ix.netcom. To: <MIDRANGE-L@midrange.com> com> cc: Sent by: Subject: Re: V5R1 Library List Enhancement (was: PRTCMDUSG RTVJOBA) owner-midrange-l@mi drange.com 04/10/01 09:56 AM Please respond to MIDRANGE-L Get help for a start from an AS/400 guru. Change your session interactive job to log all CL commands at level 00, run the CL interactively, and retrieve the CL code from your joblog. Dare ----- Original Message ----- From: <barsa@barsaconsulting.com> To: <MIDRANGE-L@midrange.com> Sent: Tuesday, April 10, 2001 9:25 AM Subject: RE: V5R1 Library List Enhancement (was: PRTCMDUSG RTVJOBA) > > And what do you do for programs for which you have no source and where the > CL is not retrievable? What do you do if you don't have SEU? What do you > do if you are just a dumb user, and have an end-user system with an > unsupported package (that's worked since the year of the flood), with: > > a.) a vendor out of business > b.) support so far behind that you cannot afford to get current > > 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: V5R1 Library List Enhancement (was: PRTCMDUSG RTVJOBA) > owner-midrange-l@mi > drange.com > > > 04/09/01 08:15 PM > Please respond to > MIDRANGE-L > > > > > > > Gee, if we all had externalized our library list retrieval along with our > DB/IO programs we wouldn't have this problem, would we? > > In all seriousness, couldn't you just write a new command (call it > OLDRTVJOBA) and CL program to interpret the new library list results of > RTVJOBA? The new command would run the V5R1 RTVJOBA and return the 275 > character library string we know and love. Scan source or run Pathfinder > command usage to find as many occurrences as you can. The code > modification > would just require that you replace RTVJOBA with OLDRTVJOBA. If you missed > any programs you could easily change them as they blew up. The command > processing program for OLDRTVJOBA could also detect when you've crossed the > 25 library threshold. Eventually someone's going to take advantage of the > new feature and throw you out of compliance, so you might as well report it > on QSYSOPR. > > Those poor folks who don't have all their source (and those folks who don't > want to change their code) could make OLDRTVJOBA into the new RTVJOBA and > put it in a system library at a higher level than QSYS, and have the > command > processing program execute QSYS/RTVJOBA. > > As a veteran of software package hell I look forward to an increase in the > number of libraries in the user library list. I always liked letting the > OS > environment do the work for me instead of configuring software environments > via CL for all my packages. Unfortunately it was impossible to provide > library entries for coexisting merchandising, financial, EDI, spool > management, etc. package library lists. > > I agree that V5R1 has ripped the rug out from under us, but I also think > that providing a system value or old and new library list strings in > RTVJOBA > is a bit of a hack. I never got really liked the legacy fields in the > output files for DSPOBJD and DSPFD either. > > We're expecting the system to grow and respond the changing face of > technology, remaining competitive in a complex market, but we also want it > to painlessly run our 1989 legacy applications, gracelessly migrated off > the > System 38. Maybe IBM should set up an "AS/400 mode" for the iSeries. > > James Damato > Manager - Technical Administration > Dollar General Corporation > <mailto:jdamato@dollargeneral.com> > > > -----Original Message----- > From: barsa@barsaconsulting.com [mailto:barsa@barsaconsulting.com] > Sent: Friday, April 06, 2001 11:07 AM > To: MIDRANGE-L@midrange.com > Subject: V5R1 Library List Enhancement (was: PRTCMDUSG RTVJOBA) > > > > Hi, > > Just for the record, the correct spelling of the word "enhancement" is > "f-i-a-s-c-o". > > I intend to be very vocal about the V5R1 increase in number of libraries in > the user portion of the library list. I have refrained from comment in > this forum until I received a clearance from Rochester, which I received on > Tuesday. I had received clearance to speak about this informally at the > Fall COMMON conference in Baltimore. Prior to that conference, I also > conducted about 10 to 12 interviews on the topic, and reported those > results to IBM. IBM paid about as much attention to my findings as the > Morton Thiokol engineers did to the space shuttle o-rings. As far as I can > determine, they never contacted any of the interviewees (whose names and > identification I provided) on a timely basis when the resolution of this > problem was being determined. > > The problem is that IBM increased the number of libraries in the user > portion of the library list from 25 to 250 in the unannounced release of > OS/400. This will cause any properly coded RTVJOBA command (As well as > some APIs) that specified the USRLIBL to fail if more than 25 libraries are > found on the list (My definition of properly coded is that the return > value has to be 275 bytes.) > > IBM has provided a poorly designed band-aid for V5R1 via PTF. I was the > person that requested IBM to code the fix, and they coded it improperly. > (They cannot complain that they didn't know how to write the fix,as I gave > them the pseudo code. Depending on how inadequate the PTF proves, I may > clean it up and publish the pseudo code here, but I'm too busy at the > moment.) When you exceed 25 libraries on the list, the IBM PTF provides a > different escape message, so you code abends with a different error > message. This is about as exciting as kissing your sister. The fix > provides a system wide patch (no, not scoped over the job, which is what is > needed) that will only be supported for a few releases. (In fairness to > IBM, a system wide patch was about what we could have expected from them at > the time I discovered the problem anything else would have been too > expensive to code, based on how complete that release of OS/400 has > progressed. This negates the fact that the both the functional addition > and the patch were not well thought out.) > > They're fairly mad at me for complaining about this, but what else is new? > The last time I complained about anything as severely as I plan to complain > about this, it was when I said that "V3R1 sucked", and of course, IBM said > that V3R1 was stable and told me I was wrong. > > The long term solution is that you must find every RTVJOBA command that > uses the USRLIBL parameter, and replace the returned variable from 275 to > 2750 bytes. Depending on what you do with that data*, this could cause > other parts of that program to fail. > > Assuming that you have all of your source, this is not an impossible task. > You could scan for every RTVJOBA using PDM, and then examine every > command by hand for USRLIBL. > There is a new TAA Tool called Scan Command Keyword (SCNCMDKWD). You > can specify the command name and the keyword name. > > In both cases it is your responsibility to make sure that the program will > still run. You also (reasonably speaking) need a license to SEU. > > * Exactly what you do with the returned data will determine the > complexity of the fix. As far as I can determine, most people stuff it > into a few different variables, so the fix is easy. If you stuff it > into a data area, this is tougher, because the maximum length of a data > area is 2000 bytes. I know of one vendor that puts every library name > into a different field in a database file - oh god forbid! > > If you don't have your source, you have been @#$%ed by IBM. Why is this > significant? This is the first time that IBM has done this to you (making > a change to the architecture of the system and requiring you to go back to > source) ever in the system. There are some notable exceptions: > In Release 3.0 of CPF, IBM required you to recompile every CL program. > However in that release they added the new RTVCLSRC command, and of > course, prior to that, there was no notion of ALWRTVSRC(*NO). > The first release of the System/38 Migration Aid (5714MG1) had no notion > that observability could have been removed. When IBM discovered that > some vendors were removing the program template, they added a diagnostic > aid to this product. > The RMVOBS parameter of CHGPGM was added in V1R2M0 of OS/400, but (IMHO) > IBM provided adequate warning of the drawbacks. > > What IBM should have done (and should still do in a future release of the > system) is add this feature as a system value, allow the system value to > default into an attribute of a job description, and at job initiation time, > the value should be propagated to the job. The value needs to be > consistently added to both the native AS/400 functionality, and the > System/38 compatibility command set. (This sounds like a lot of work, but > it's really trivial. In fact the current PTF is inconsistently applied > over the native commands and the System/38 commands.) It also needs to be > extended to save/restore. I have privately submitted my proposed changes > to IBM in detail, and they have yet to respond with any intentions to do > anything other than file them in the circular file. > > In my opinion, the change was not well thought out by IBM. (My upcoming > magazine article on this subject might be less polite in terminology.) > > 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 > > > > > > > > > MacWheel99@aol.com > > Sent by: To: > MIDRANGE-L@midrange.com (AS400 & family discussion group), > owner-midrange-l@mi BPCS-L@midrange.com (BPCS > Users Discussion Group) > drange.com cc: > > Subject: PRTCMDUSG > RTVJOBA > > > 03/31/01 12:00 PM > > Please respond to > > MIDRANGE-L > > > > > > > > > > From > MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac) > > Below is cut & paste of information from an AS400network newsletter that I > want to talk about ... I left their advertiser URLs included in hopes they > will not get annoyed with me for forwarding their copyrighted stuff. Item > # > 4 affects BPCS & probably every other ERP & other software package that > anyone is using on the 400. > > PRTCMDUSG gets at a list of all programs that use a particular command. > I learned about this command in prior MIDRANGE-L discussion about > cross-referencing where various software objects are used. > > We have 800 CL programs in our BPCS 405 CD live environment library list > that > use RTVJOBA. Some of them are our modifications, but most are vanilla base > > BPCS. > RTVJOBA is the first of the 5 commands listed in the newsletter that will > return more information starting OS/400 V5. This is not the whole picture, > > but I have to start somewhere. > > RTVJOBA can be used to retrieve a lot of stuff about a job ... library list > > information is not its only usage, so in many cases the fact that OS400 V5 > is > going from 25 to 250 user libraries in the list won't make a bit of > difference, but when the retrieval is to access the library list > information, > the fact that more data is coming back could have a detrimental effect > depending on how the software is written, and depending on if & when we > utilize the extra libraries. > > The situation for BPCS V6 users is different than for BPCS 405 CD because > V6 > users do not have access to the source code, rather all code is via SSA's > "case" AS/Set. SSA had announced that they dropping support for 405 CD > effective end of May 2001. This IBM V5 is due out beginning of May 2001. > Now there are SEVERAL places that offer good quality tech support for BPCS > 405 CD when SSA's ends, so that is not a problem. My thoughts are > > a) Does SSA know about this? (I sent a general inquiry to SSA tech support > to > ask) > b) Can we expect a final REL 03 aggregate collection of BMRs at the end of > 405 CD that includes a fix for this nuance? > > Assuming that we can not depend on such an expectation, there is a joint > challenge of identifying inventorying what all our retrieve library list > software is doing to figure out the impact & what needs fixing. > > I think there is a PDM search & substitute command string that I need to > learn, except I like to look at what exactly is happening in each instance. > > However PDM search might help in mapping out how RTVJOBA is used in our 800 > > programs. > > Subj: Club Tech iSeries Programming Tips - 03.29.01 > From: ClubTechiSeriesPrgrmTips@list.as400network.com > (ClubTechiSeriesPrgrmTips) > > *********** Club Tech iSeries Programming Tips Newsletter *********** > An AS400 Network Publication http://www.as400network.com > Home of NEWS/400 Magazine > Issue 41 March 29, 2001 > > Sponsored by Generic Software, Inc., at (800) 698-5669 or visit > http://www.genericsoftware.com/html/save_output_queue.htm . > > <snip> > > THIS WEEK: > > APIs by Example: Read/Write an IFS File Line in RPG IV > > APIs by Example: Read an IFS File Line in Cobol > > Data Area Editor Utility > > Poor Man's Cross-Reference > > Maximum Libraries in *LIBL to Change from 25 to 250 > < big snip > > > * Make your RPG Programs happy! Download RPG-Alive... > http://www.RPGAlive.com > > <snip> > > 4. MAXIMUM LIBRARIES IN *LIBL TO CHANGE FROM 25 TO 250 > The V5 release of OS/400, due out in May, changes the maximum number > of libraries in the user part of a library list (*LIBL) from 25 to > 250. This will alleviate some problems that arose from the previous > limitations, but it may cause other problems with your existing code. > > The new versions of the RTVJOBA (Retrieve Job Attribute) command and > the QUSRJOBI (Retrieve Job Information), QWCRTVCA (Retrieve Current > Attributes), QUSRSPLA (Retrieve Spool File Attributes), and QWDRJOBD > (Retrieve Job Description) APIs can now return more data than in > previous releases. Be sure that any applications you have that use one > of these interfaces provides enough room for 250 libraries in the > return value. > > When you increase the size of a return variable, you can still safely > call V4R5 and earlier releases of these interfaces because there is no > harm in providing more space than needed. Just be sure that your own > application logic correctly handles however many library entries are > returned. > > For more information, see: > http://www.ibm.com/eserver/iseries/developer/os400/lib_list.html > > Thanks to Paul Conte for the above item > > <snip> > > http://as400network.com/str/books/uniquebook2.cfm?NextBook=181 . > > This newsletter is edited by Chuck Lundgren, > mailto:clundgren@as400network.com . > > FOR NEW SUBSCRIPTIONS, you can subscribe by joining the AS400 Network > with a handy Web form at http://www.as400network.com/join/ . > > IF YOU WANT TO SPONSOR a Club Tech iSeries Programming Tips > Newsletter, please contact your AS400 Network sales manager. Click > here for details: > http://www.as400network.com/info/mediakit/Sales/Index.htm . > ___________________________ > Copyright 2001, NEWS/400 > http://www.as400network.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 > +--- > > > > > > > +--- > | 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
