Hi Yes, before posting this issue we have also tried options with less recent date on the archive record in order to have less records selected on the job list that is suggesting VK and also exported LDR_CNTRL=MAXDATA=0x80000000 but the problem was not solved. Regarding backup, first we do snapshot and after that we use tar ... What is not clear to me is why limit -d from unlimited after exporting LDR_CNTRL is changing to: data(kbytes) 1572864 since the request from support is to have data and stack unlimited for the user and also to export LDR_CNTRL=MAXDATA=0x60000000
thank you On May 27, 4:38 pm, "Jim Idle" <[email protected]> wrote: > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of VK > > Sent: Thursday, May 27, 2010 12:04 AM > > To: jBASE > > Subject: Re: (T24) LDR_CNTRL and Segementation violation > > > Hi, > > yes there's a SELECT in core routines to apply user's choice of date > > up to which achival is desired. I totally agree that it's > > inappropriate when you have large files... You can try to use less > > recent date for first archival to have less data being selected and > > then repeat archival once again with later date. > > That seems a wise next move, but it might be that the memory is being > exhausted because of the traversal of the files, in which case there would be > no fixing this. I would think that archiving should be a weekly or at least > monthly event, so perhaps this is a requirement for procedural policy change. > > Basically though, TEMENOS need to fix/improve this, as general policy remove > the use of SELECT/SSELECT (especially SSELECT) in programs, even though in > jBASE 4/5 it can be faster than a weaker jBC programmers code. An index on > the date field, and the jBC index functions/statements are your friend here. > > > > > Manual archival is possible but you need to know which concat files > > are archived by core procedure along with "main" file. > > > Also, as far as I remember you can increase LDR_CNTRL=MAXDATA up to > > 0x80000000. > > It is likely though that this would just delay the failure point ;-) > > Jim -- Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
