Thank you for the insight. The program in question is entirely BASIC. It is a subroutine called from an SB+ paragraph that then calls other subroutines to do the heavy lifting. So while it's called from SB+, it doesn't use anything in SB+, it's just some vendor-written subroutines calling other vendor-written subroutines. We have the source for it, but was hoping we could find a way to debug it as it's a massive number of lines across an equally massive number of routines, running against a pretty significant list of records across an equally impressive number of files.
At the time this started happening, Unidata had been running for about six months without a restart. Restarting Unidata didn't change the outcome of this program, it still aborts randomly, which leads me to think that there has been some change in the data that is causing this vendor code to misbehave, but without single-stepping through the code (which literally could take months) I was just wondering if there's anything in the debugger that would tell me how many un-returned GOSUBS have been hit? This site uses work order assemblies in this particular vendor product and I'm wondering if there's a loop in the bill of materials somewhere that's basically exhausting memory, but there just isn't time to single-step through the code to try to find that without some trickery or magic to help the process along. -K On Sat, Aug 10, 2013 at 5:23 PM, John Jenkins <u2g...@btinternet.com> wrote: > Kevin, > > Could someone be constantly using /process_name to constantly jump around > the system? If so, the. One of the SB files will build up a history (not > recalling which one off the top of my head) . Look for a massive increase > build up of records which will point to a culprit user or process. > > SB code - unless you code your own subroutines or generate code /GC - are > interpreted. > > Otherwise I recommend checking files and indexes for corruption. BASIC > catalog used can become corrupt just like any other data, it's incredibly > rare though. > > Regards > > JayJay > > > > On 10 Aug 2013, at 21:12, Kevin King <ke...@precisonline.com> wrote: > > > We have a customer that has a program (and associated subroutines) that > has > > not been modified in a good long while. Just this past week it started > > blowing up with a memory failure and segfault at different times in the > > process. Unidata was recently restarted. > > > > I'm suspecting that some bit of code in this quagmire is doing some > GOSUBs > > and not unravelling the stack, and eventually it's just running out of > > stack space. But ... how can I prove this without stepping through the > > code line by line? Is there something in the Unidata debugger that shows > > the GOSUB stack? > > > > I've tried running this through the MM -E trick (this is a SB+ app, btw) > > and it never drops in the debugger when this happens, the process just > > terminates and returns to AIX. So I'm a little uncertain as to how to go > > about figuring this one out. > > > > Any ideas? > > _______________________________________________ > > U2-Users mailing list > > U2-Users@listserver.u2ug.org > > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
