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.
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. VK On May 27, 12:55 am, "Jim Idle" <[email protected]> wrote: > OK - I don't know why TEMENOS would use a SELECT statement for archiving > (which I presume therefore is not archiving to back up, but T24 archiving)... > well perhaps I do know why... > > However, you are basically running out of memory. Setting the LDR_CNTRL is an > attempt to make more memory available, but I think that your data set is so > large that you won't be able to get around this in this way. TEMENOS should > not use SELECT for such things, but should iterate in BASIC. Perhaps you can > write some custom code to do this? Is there are a way to cut down on the > number of items being archived? > > Please note that you cannot use tar for backup unless you have taken everyone > offline or otherwise paused, flushed the database and made some mirror > snapshot. If you are not doing this, then all your backups are essentially > useless :-( > > Jim > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Agim > > Sent: Wednesday, May 26, 2010 1:30 PM > > To: jBASE > > Subject: Re: (T24) LDR_CNTRL and Segementation violation > > > Hi Jim, > > Thank you > > To archive the file we run core T24 routines - and error is probably > > on the selection phase since the process does not fill the job list > > because of the error "Segementation ...". > > For backup we use tar but in this case i don't see any connection with > > error. > > Operating system is AIX and we have done test on two servers, one > > first server we have AIX 6.1 and other server AIX 5.3 - results are > > same. > > > Regarding file corruption in this test environment we have run jrf -Rv > > and after that we have done resizing of all the part files since > > resizing was also requested from our support. Only after resizing > > didn't solve the problem we were instructed to export LDR_CNTRL. > > > Now we have changed ulimit for user to unlimited and we have inserted > > on .profile - export LDR_CNTRL=MAXDATA=0x60000000 but the problem was > > not solved since the ulimit -d is changing from unlimited to > > "data(kbytes) =1572864" - as it previously described. > > > On May 26, 7:16 pm, "Jim Idle" <[email protected]> wrote: > > > When do you get this? What backup tool are you using? What operating > > system? Looks like AIX? Will anyone ever read the posting guidelines? > > > > Higher on the list than LDR_CNTRL for me would be the need to run > > jcheck on the file parts and make sure that you do not have a corrupt > > file, which seems likely. > > > > Jim > > > > > -----Original Message----- > > > > From: [email protected] [mailto:[email protected]] On > > Behalf > > > > Of Agim > > > > Sent: Wednesday, May 26, 2010 1:56 AM > > > > To: jBASE > > > > Subject: (T24) LDR_CNTRL and Segementation violation > > > > > We need to archive file that is distributed on 32 part files and > > > > during this process we are getting error "jBASE: Segmentation > > > > violation. Aborting". > > > > Limit for the user that is starting process is: > > > > ulimit -a > > > > time(seconds) unlimited > > > > file(blocks) unlimited > > > > data(kbytes) unlimited > > > > stack(kbytes) 4194304 > > > > memory(kbytes) unlimited > > > > coredump(blocks) unlimited > > > > nofiles(descriptors) 2000 > > > > threads(per process) unlimited > > > > processes(per user) unlimited > > > > > We have contacted Temenos and we are advised to put on .profile > > > > following - export LDR_CNTRL=MAXDATA=0x60000000 > > > > > Even after we have exported LDR_CNTRL the problem is not solved and > > > > reason for that could be that when the .profile is executed the > > value > > > > for ulimit -d changes. > > > > ulimit -a > > > > time(seconds) unlimited > > > > file(blocks) unlimited > > > > data(kbytes) 1572864 > > > > stack(kbytes) 4194304 > > > > memory(kbytes) unlimited > > > > coredump(blocks) unlimited > > > > nofiles(descriptors) 2000 > > > > threads(per process) unlimited > > > > processes(per user) unlimited > > > > > I will appreciate any help regarding this issue > > > > > -- > > > > 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 > > > -- > > 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 -- 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
