Re: Upgrade Issue -- MAPICS-L

There's an easy way to automate the open and save of queries:
    Start recording in client acces
    Do one screen and then page down
    stop recording
    Edit this recording to eliminate all the waits
    Select all commands and then paste them about 20 times
    save this recording
Now each time you run it, you've done 20 screens of queries (=about 250
queries). At the end it'll get an input inhibited and you can move to the
next library.  It speeds up nicely this way without programming for any
gazillion dumb sequence.

Good luck,

Kris De Vlieger

----- Original Message -----
From: <DaleGindlesperger@fft-inc.com>
To: <mapics-l@midrange.com>
Sent: Wednesday, 01 May, 2002 01:23 AM
Subject: Re: Upgrade Issue


> This is a multipart message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Connie,
>
> We usually make an effort to stay current, with one exception over the
> last several years - we skipped XA/R4 and went straight from R3 to R5.  As
> we implemented EPDM at the same time, that was a BIG conversion.  On the
> other hand, our conversion from R5 to R6 was VERY easy.  We basically only
> recompiled our add-on code (in a separate library).  As we were in the
> middle of a major project at the time, I actually outsourced the upgrade
> prep to my affiliate, who did it remotely in a couple days of compiling
> and checking on their system.  Then they brought the source code on a
> tape, loaded it on my AS/400, recompiled everything, and we were ready.  I
> love library lists!
>
> The actual upgrade was done on a Sunday afternoon, took me about 6 hours.
> Quite easy, and about the easiest upgrade we've done since we went from DB
> Mod 3 to DB Mod 4.  Most of the users never really noticed, except for the
> new functionality.  (FYI, we are on an AS/400 Model 720-2062.)
>
> Query conversion, on the other hand, is always a pain.  We have about a
> gajillion and two queries, and we have to open and save all of them to
> prevent the annoying level checks.  Serious annoyance.  My operator
> basically gets a listing and spends a couple days just opening and saving
> them in sequence.  Boooooring!  And definitely not a "value add" use of
> his time and abilities.  I'd love an automated way of doing that.  (Hint
> hint - any of you system geniuses out there figure something out for
> that?)
>
> I am actually very much anticipating our upgrade to R7.  Our MAPICS
> Browser implementation has been very successful (EPDM, CSM, AMPlus, and
> Integrator), but since we are using applications that aren't converted to
> Java yet, we have to wait.  I am quite eager to be able to extend EPDM
> inquiries to the plant floor on thin clients, instead of limiting it to a
> couple PCs placed in fairly clean offices.  (Plus the ability to put
> certain apps out on the web.)  I am curious as to how much AS/400
> horsepower will be required.  We had to add an addition 500MB of memory to
> my existing 1GB of memory in my AS/400 to get acceptable response time
> with CSM and MDCC, all allocated to QSERVER.
>
> I noticed a comment earlier on this thread about not wanting to move to
> "obsolete" technology like Browser or R7?   I must be missing something
> there - I think that the move to Java for R7 (with EZ-Link, too!) is
> pretty darn current!  We are quite pleased with how current MAPICS has
> stayed, especially with all the user exits and off-line loads that let you
> hang custom stuff on and off MAPICS without modification of base code. And
> the new COM_Net, woo-hoo sweet!  Now with the free enhancements MAPICS is
> offering, like off-line shipping to take care of the (in my opinion)
> cumbersome pick-pack-ship process, it's even better.  (No, I don't work
> for MAPICS, just use it a lot....)
>
> Incidentally, I also don't understand why MAPICS keeps the old PDM files
> as actual physical files after you implement EPDM.  It would seem to me
> that they should be able to convert them to logical files and just use the
> actual EPDM files for the data.  Then the other apps that use the
> ITEMASA/B/C, PSTRUC, ROUTNG, and so on would just use the EPDM databases
> via the logicals.  Of course, not being personally conversant with the
> couple million lines of code using the PDM files, I don't know how
> reasonable that is.
>
> Dale Gindlesperger @ Fleetwood
>
>
>
>
>
>
> Connie Webb <cwebb@grahamwhite.com>
> Sent by: mapics-l-admin@midrange.com
> 04/30/02 10:29 AM
> Please respond to mapics-l
>
>
>         To:     "'mapics-l@midrange.com'" <mapics-l@midrange.com>
>         cc:
>         Subject:        Upgrade Issue
>
>
> Has anyone moved to REL 7 or have immediate plans to do so?
>
> I am interested in the resources you consider necessary to move from
> different releases of MAPICS. Do you migrate with internal resources? Do
> you
> have programmers on site?  When did you move from REL 4 to REL 6?
> _______________________________________________
> This is the MAPICS ERP System Discussion (MAPICS-L) mailing list
> To post a message email: MAPICS-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/mapics-l
> or email: MAPICS-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/mapics-l.
>
>
>
> _______________________________________________
> This is the MAPICS ERP System Discussion (MAPICS-L) mailing list
> To post a message email: MAPICS-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/mapics-l
> or email: MAPICS-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/mapics-l.
>
>