| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2557.1 | Additional info. | KERNEL::BURDENI | | Thu Mar 06 1997 10:09 | 9 |
| Additional information,
The ALL-IN-1 version is v3.1, The file is a data file not created by
ALL-IN-1. Also, the procedure has been run on a clear system with
initialized disks and no other applications running and the timings are
still disproportionate.
Many Thanks
Ivan.
|
| 2557.2 | WAGs | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Thu Mar 06 1997 14:02 | 7 |
| It's a little difficult to say anything without seeing the script...
However, is the file indexed? If so, why is the script doing sequential
access? How optimal is the file? Have they done ANAL/RMS/FDL on it?
Sensible SYSUAF parameters for the account, which might use a lot of VM
to read and write it? Disc fragmented?
|
| 2557.3 | SCRIPT in question | KERNEL::BURDENI | | Thu Mar 06 1997 15:45 | 62 |
| Thanks for the reply, I realise it was a little vague to say the least.
I have obtained a copy of the script, it is as follows. There is no
fragmentation problem, I believe this file is used for other purposes,
which is where the index comes into play.
I will post the account information when I get it.
!
! test4.scp copy of test3.scp
!
GET #START_TIME = OA$DATE_NBS
DECIMAL I
GET #COUNT_UPDATE = 0
!OPEN FORM LIBRARIES
!
OA$FLO_OPEN CTS$LIB:DEVELOP
GET #WPF_KEY = "199611"
GET #WPF_SAVESET = "199611"
GET #WPF_TAPE_LABEL = "TEST1NOV"
GET #NEW_DOC_STATUS = "A"
! REMOVED BETWEEN IF AND WRITE
! GET #DOC_STATUS = .CC_DOCUMENT_STATUS \\\\ -
! GET #NEW_DOC_STATUS = "A" #DOC_STATUS:1:1 \\\\ -
FOR NIB$CCF$ENTRY1 DO -
IF .CC_DOC_SUBMIT_NBS_DT = #WPF_KEY THEN -
WRITE CHANGE NIB$CCF$ENTRY1 -
%KEY = %KEY, -
CC_DOCUMENT_STATUS = #NEW_DOC_STATUS, -
CC_ARCH_TAPE_ID = #WPF_TAPE_LABEL, -
CC_ARCH_SAVESET = #WPF_SAVESET, -
CC_ARCH_STORE_DT = oa$date_full \\\\ -
DECIMAL I \\\\ -
INCREMENT #COUNT_UPDATE
! GET #TOTAL = .%COUNT
GET #END_TIME = OA$DATE_NBS
GET #LOG_FILE = 'CTS$DATA:ARCHIVE_KT.log'
TEXT_FILE OPEN F #LOG_FILE /WRITE
!
! Common fields
!
GET #MAIL_TEXT = "Start Time = " #START_TIME
TEXT_FILE WRITE F #MAIL_TEXT
GET #MAIL_TEXT = 'Date = " #WPF_SAVESET
TEXT_FILE WRITE F #MAIL_TEXT
GET #MAIL_TEXT = "End Time = " #END_TIME
TEXT_FILE WRITE F #MAIL_TEXT
GET #MAIL_TEXT = "Total update Archive CCF records = " #COUNT_UPDATE
TEXT_FILE WRITE F #MAIL_TEXT
TEXT_FILE CLOSE F
|
| 2557.4 | | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Fri Mar 07 1997 07:52 | 32 |
| I'm not sure why this should take longer for more updates, but it's not
a very sensibly written piece of code...
First, taking the 'DECIMAL I' out of the loop might be a good idea!
Why isn't the test of .CC_DOC_SUBMIT_NBS_DT part of the DO? This would
also mean that OA$SEL_COUNT could be used rather than a separate count:
FOR NIB$CCF$ENTRY1 WITH .CC_DOC_SUBMIT_NBS_DT = #WPF_KEY DO -
WRITE CHANGE etc.....
GET #MAIL_TEXT = "Total update Archive CCF records = " OA$SEL_COUNT
Since they're using '=' (i.e. begins with) for the comparison, then
this will always be a serial search.
Also, if they're planning on doing this sort of thing often, it would
make a lot of sense to make the CC_DOC_SUBMIT_NBS_DT field an
alternate key, or better, a short version of it that only contains the
Month and year they're searching for. This would enable them to use an
'==' comparison, which would then be a keyed lookup.
I guess you're going to have to turn tracing on to see what's going on
here, although that's going to make a very big log file. I would also
suggest you look into page faulting or other things happening to
the process.
Finally, I tend to use this sort of syntax for the key field:
FOR Form WITH .... DO WRITE CHANGE Form K = .%KEY, ....
I'm not sure if there are any implications of the syntax they're using.
|
| 2557.5 | I shall look at process performance. | KERNEL::BURDENI | | Fri Mar 07 1997 08:49 | 7 |
| Thanks very much for all the info, this should at least help with his
main problem and that is the time taken to run the procedure. I will
post any further information I can get from him, and I will have a good
look at the performance side of things.
Many Thanks
Ivan.
|
| 2557.6 | Did the trick | KERNEL::BURDENI | | Fri Mar 07 1997 16:13 | 4 |
| The changes offered improved the turnaround times considerably, and the
customer is happy.
Many Thanks.
|
| 2557.7 | Where do I send my consultancy bill? :-) | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Mon Mar 10 1997 08:09 | 0 |
| 2557.8 | Cheque | KERNEL::BURDENI | | Mon Mar 10 1997 09:28 | 1 |
| Would you believe that a check is in the post ????
|
| 2557.9 | Nope :-) | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Mon Mar 10 1997 17:58 | 0 |
| 2557.10 | | GIDDAY::BACOT | | Tue Mar 11 1997 22:26 | 3 |
| Ahh Graham, I do believe you are becoming a bit of a cynic... ;')
|
| 2557.11 | (OK, it's a pint on Monday,Graham!) | ZUR01::ASHG | Grahame Ash @RLE | Wed Mar 12 1997 07:48 | 6 |
| > Ahh Graham, I do believe you are becoming a bit of a cynic... ;')
Something seems to have gone wrong with Notes here - wasn't this Note
originally posted in about 1984?!
g
|
| 2557.12 | Boom, boom! | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Wed Mar 12 1997 08:11 | 3 |
| <<<< OK, it's a pint on Monday,Graham!
Alas no, I'll be on holiday (again)...
|