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

I can read that either of two ways... #1:They're chasing the money, or.. 
#2 their AS/400 product is stable, the other platforms get the changes 
because the other operating systems keep shifting under them and they have 
to apply energy just to stand still.

_______________________
Booth Martin
Booth@MartinVT.com
http://www.MartinVT.com
_______________________




Don <dr2@cssas400.com>
Sent by: owner-midrange-l@midrange.com
04/10/2001 01:21 PM
Please respond to MIDRANGE-L

 
        To:     MIDRANGE-L@midrange.com
        cc: 
        Subject:        RE: V5R1 Library List Enhancement (was: PRTCMDUSG 
RTVJOBA)


Actually, it would be nice if some vendors would keep thier AS400
production code version functionality at the same level as the NT, unix,
etc., versions which tend to get currency BEFORE the 400!  Kinda give you
a hint of any sort folks??



On Tue, 10 Apr 2001 barsa@barsaconsulting.com wrote:

> 
> Some vendors that "port" code have indicated that they will not support 
the
> system unless it supports more than 25 libraries.
> 
> 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
> 
> 
> 
> 
> 
>  
>                     rob@dekko.com   
>                     Sent by:                   To: 
MIDRANGE-L@midrange.com 
>                     owner-midrange-l@mi        cc:    
>                     drange.com                 Subject:     RE: V5R1 
Library List Enhancement (was: PRTCMDUSG RTVJOBA) 
>  
>  
>                     04/10/01 11:42 AM   
>                     Please respond to   
>                     MIDRANGE-L   
>  
>  
> 
> 
> 
> 
> 
> Keep chugging along.  Really.  If no one starts using the capability to
> have more than 25 libraries in a list.  No change is necessary.  If so,
> then you may, or may not have a problem.  Like I said, it's a single 
point
> of change for SSA.  (And who would of thought of them as forward 
thinking?)
> 
> Rob Berendt
> 
> ==================
> Remember the Cole!
> 
> 
> 
>                     barsa@barsaconsulti
> 
>                     ng.com                     To:
> MIDRANGE-L@midrange.com
>                     Sent by:                   cc:
> 
>                     owner-midrange-l@mi        Subject:     RE: V5R1
> Library List Enhancement
>                     drange.com                 (was: PRTCMDUSG RTVJOBA)
> 
> 
> 
>                     04/10/2001 08:25 AM
> 
>                     Please respond to
> 
>                     MIDRANGE-L
> 
> 
> 
> 
> 
> 
> 
> 
> 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
> +---
> 

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