RE: V5R1 Library List Enhancement (was: PRTCMDUSG RTVJOBA) -- MIDRANGE-L

LOGCLPGM(*YES) will not work for the retrieval of CL source; many CL
commands are not logged regardless of this setting;  CHGVAR and IF
statements are examples.

Jeff Bull

-----Original Message-----
From: oludare [mailto:oludare@ix.netcom.com]
Sent: Tuesday, April 10, 2001 2:56 PM
To: MIDRANGE-L@midrange.com
Subject: Re: V5R1 Library List Enhancement (was: PRTCMDUSG RTVJOBA)


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
+---