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

The last time that I remember that we had to recompile our programs when we
upgraded the OS was on the System/38, and we had to recompile all of our C/L
programs. I think that was around 1982. 

The system/38 was still fairly new at that time and IBM was apologetic about
it. They said they would never do it again. So far, they haven't.

        -----Original Message-----
        From:   Jim Damato [SMTP:jdamato@dollargeneral.com]
        Sent:   Tuesday, April 10, 2001 12:30 PM
        To:     'MIDRANGE-L@midrange.com'
        Subject:        RE: V5R1 Library List Enhancement (was: PRTCMDUSG
RTVJOBA)

        I still like the idea of an AS/400 mode.  Keep all V4 commands
intact in
        AS/400 mode just like System 38 mode.  Make all OS changes to the
"native
        iSeries environment."  IBM could initially make vague threats that
AS/400
        mode is going away some day, eventually leading up to the iSeries
V5R4
        announcement that V5R5 will be the last AS/400 mode release and that
V6 will
        not support old AS/400 commands.  That way folks would have to start
taking
        responsibility for their dinosaur applications instead of clinging
to the
        mentality that if an application runs today IBM will always support
it.



        -----Original Message-----
        From: barsa@barsaconsulting.com [mailto:barsa@barsaconsulting.com]
        Sent: Tuesday, April 10, 2001 10:39 AM
        To: MIDRANGE-L@midrange.com
        Subject: RE: V5R1 Library List Enhancement (was: PRTCMDUSG RTVJOBA)



        I agree that I don't want to start a war, but this is the first
significant
        change to CL that makes you recompile ever!  Given the fact that IBM
has
        allowed us to avoid this for over 20 years, they could have done it
now.

        There are several possible techniques:

           Support a second portion of the user library list.  Possibly with
access
           to both parts together in certain commands.
           Add job level support for short vs. long library lists.  This
would
           require change to a *JOBD, and likely an added system value.
           Not support the requirement.  IBM made a statement many years ago
that
           there would "never be support for over 25 libraries in the user
portion
           of the library list".  They could have kept to that promise.
           Teach people how to code properly.

        The only untenable solution that I could imagine was to break user's
code.

        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/10/01 10:34 AM

                            Please respond to

                            MIDRANGE-L

         

         





        There are a number of choices.

        -You stay on V4R5 until you can switch to a supportable product.

        -You hire a consultant who has SEU and a CL compiler to produce the
hack to
        RTVJOBA I've described.

        -You stay on V4R5 forever.  As long as your software is
unsupportable you
        may as well bring your OS to the same state.

        -You recognize that you've been living on borrowed time, and that
you won't
        be supported forever.

        I don't want to start another war here, but I really don't believe
that
        systems vendors are obligated to provide full
backwards-compatibility
        forever.  This is a relatively minor change compared to what we've
seen in
        the Oracle or Windows world.  The poor fools who are in the mess you
        describe can run V4R5 fully supported for quite a while, during
which time
        they can plan and budget for patches, upgrades, or replacements.

        The moment your software vendor goes out of business you yourself
are
        responsible for contingency planning.  Who would you blame if the
hardware
        vendor went out of business?  And falling behind in software support
is a
        business decision with associated risks.

        We moan about IBM's failure to market properly, but we expect them
to
        produce a competitive, cutting edge machine that can also continue
to run
        every third-party nightmare ever produced on this platform and the
System
        38.

        In all seriousness, with your presence in the market why don't you
lobby to
        IBM for an "AS/400 mode"?  It might help the brand if they were able
to
        draw
        that line in the sand between the iSeries and its legacies.

        James Damato
        Manager - Technical Administration
        Dollar General Corporation
        <mailto:jdamato@dollargeneral.com>



        -----Original Message-----
        From: barsa@barsaconsulting.com [mailto:barsa@barsaconsulting.com]
        Sent: Tuesday, April 10, 2001 8:26 AM
        To: MIDRANGE-L@midrange.com
        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
        +---
        +---
        | 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
+---