Thanks for the response, I have googled for answers. :) And we are pre-Aurora version of System21 too. I was hoping that someone else was, like us, running an older version and has done an OS update to v5r4. xyzzy wrote: On Sep 13, 11:41 pm, Barb <gryper_1...@yahoo.com> wrote: We are getting ready to upgrade our iSeries to v5r4 from v5r2. We're running an older version of Geac System21
Barb wrote: We are getting ready to upgrade our iSeries to v5r4 from v5r2. We're running an older version of Geac System21 - v3.5.2b and Geac System21 Explorer v3.5.1 (Sept 2001 release). Does anyone know if there will be a problem with our System21 on v5r4? Or better yet has anyone upgraded their OS to v5r4 and are running older System21 software? What problems were encountered
Thanks for that info. I'm going to pass this off to the client who is in communication with the vendor. Mike -----Original Message----- From: owner-vse-l@Lehigh.EDU [mailto:owner-vse-l@Lehigh.EDU] On Behalf Of Kevin Corkery Sent: September 19, 2007 12:03 PM To: VSE Discussion List Subject: Re: Abend in z/VSE GEAC program I have a subroutine that called $IJBCJC in order to set the return
Hello, I don't think it is in the SVA. I did a LIBR LD SDL and checking the output I see the last phase in the SVA with the highest address is $JOBCTLN at 05618678. From the MAP command I see: AR 0015 SPACE AREA V-SIZE GETVIS V-ADDR UNUSED NAME ... AR 0015 S SVA-31 13732K 3676K 4600000 This address "2E22170C" seems way too high to be in the SVA
The abend address (2E22170C) is well beyond the top of the 50M partition, which would indicate the code involved is an SVA module. I am not at all familiar with the application involved (GEAC or whatever it's called), but my first guess would be that a payroll application would not include its own SVA modules. Also, the fact that the abend occurs while it is running AMODE31 rules out the problem
