Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

v5r3 issues/concerns

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • v5r3 issues/concerns

    We've been up on v5r3 now for a 1.5 weeks. I finished the upgrade on July 8th at the end of a week-long company shutdown. Everything's been running fine so far. We don't have application maintenance for our ERP system & there were reportedly some problems with our ERP & v5rx so I got a 2nd test box & did some testing there before upgrading the production machine. Our production & test machines are identical 170s with 1gig of ram & 34 gig of DASD, of which about 80% is now used ! I upgraded from v4r2 so the upgrade process chewed up about 15% of the free DASD, but hey, we're current now & our DASD doesn't get used up that fast anyway. I am, however, going to push for some additional DASD though. The only thing that I have left to do is get Electronic Services Agent up and running. This is the new name for what was called Service Director on v4r2. That entails installing a licensed program that I got with the v5r3 order, 5722-AC3; it's some kind of cryptographic application/component. Also got 5722-CE3 with the order but I haven't installed it yet. I think 5722-CE3 is support for SSL. Put Cum package C5102530 on right after installing the OS & that took about 5 hours by itself. Just as long as each upgrade: I upgraded in steps from v4r2 to v4r4 to v5r1 to v5r3 and each one took about 4-5 hours. I had heard some rumors that folks saw big performance hits once they got v5r3 installed but I haven't seen anything significant yet, although my system is pretty small with a small # of users, about 50 give or take. I'm wondering if these CE3 & AC3 components might cause performance issues, but I am going to install AC3 anyway. Client Access, which is now named iSeries Access, now supports SSL but I am assuming that you have to have the CE3 Licensed Program installed in order to use it. The new iSeries Access 5250 emulator now shows a picture of a lock in the lower-left corner of the emulator window & it's unlocked on my system. I presume because I haven't installed the CE3 stuff (& don't intend to right now). Hope this helps. Martin

  • #2
    v5r3 issues/concerns

    II13978 When upgrading to V5R3, message file (*MSGF) conversions are needed. These conversions occur when the *MSGF is first used and require an exclusive (*EXCL) lock on the *MSGF. I wrote this code to 'touch' all the objects. V5R3_MSGF: PGM DCL VAR(&MSGF) TYPE(*CHAR) LEN(30) DCLF FILE(QADSPOBJ) OVRDBF FILE(QADSPOBJ) TOFILE(QTEMP/MSGFS) DSPOBJD OBJ(*ALL/*ALL) OBJTYPE(*MSGF) + OUTPUT(*OUTFILE) OUTFILE(QTEMP/MSGFS) LOOP: RCVF /* READ A RECORD */ MONMSG MSGID(CPF0864) EXEC(GOTO EOF) /* EOF */ RTVMSG MSGID(USR0001) MSGF(&ODLBNM/&ODOBNM) MSG(&MSGF) GOTO CMDLBL(LOOP) EOF: ENDPGM I also did a STROBJCVN which I submitted after the entire upgrade was complete. Good luck

    Comment


    • #3
      v5r3 issues/concerns

      What version were you coming from VxRx Richard when the message files required conversion -- I hadn't heard anything similar to this since the switch from CISC-to-RISC?? Thank you - Lee.

      Comment


      • #4
        v5r3 issues/concerns

        We came from V5R2. Here is the location for the APAR info http://www-912.ibm.com/n_dir/nas4apa...e?OpenDocument In another forum there were replies anecdotally indicating the STROBJCVN seemed to help as well. In our own instance the *MSGF definitely!!! created a problem. Users would be on the main production menu and wait the default time (1 minute) before getting into order entry. After the program was run (no one could be using the menu) it returned to its normal response time.

        Comment


        • #5
          v5r3 issues/concerns

          we will be upgrading our os from v5r2 to v5r3 soon. Does anyone have any unexpected issues/problems they encountered? appreciate your input.

          Comment


          • #6
            v5r3 issues/concerns

            Inside a service program we have the code: if not %open (FILE) OPEN FILE endif chain key FILE This is working fine for the first run. But during a second call (due to some activation group issue we assume) the %OPEN returns file open status, while it is actually not. So it will not open the file and the program crashes at the CHAIN. Please reply if anybody has an explaination for this.

            Comment


            • #7
              v5r3 issues/concerns

              dkrk wrote: > > Inside a service program we have the code: > > if not %open (FILE) > OPEN FILE > endif > chain key FILE > > This is working fine for the first run. > > But during a second call (due to some activation group issue we assume) the %OPEN returns file open status, while it is actually not. So it will not open the file and the program crashes at the CHAIN. Please reply if anybody has an explaination for this. If the service program is running in the default activation group, and you use the RCLRSC command, then the file will get closed by the RCLRSC, but the static storage for the service program will not get reset. So the RPG service program will think that the file is still open. RCLRSC only behaves this way with service programs; if you have a *CALLER program called into the default activation group, RCLRSC would reset the program's storage too, and you'd be ok.

              Comment

              Working...
              X