i am pulling another useful(useless?) coding tip OUT OF THE CLOSET ...
when i am asked to reduce the runtime of long running IDMS jobs - the
solution is almost ALWAYS to reduce the I/O. In this case - the solution
was to sort the LOAD input data into DBKEY sequence. But .. the
development
team did not want to modify any code to achieve this . so ... the
solution
was ...
add two steps to the job stream without modifying the input data!
1) a program to determine the page range of the area in which the load
was
to occur:
DATABASE DICTNAME=SYSDIRL DBNAME=SYSTEM
IN 4000 F DB(D) SS=IDMSNWKG,IDMSNTWK
PATH01 AREA-1026 (IX-AREA)
SELECT AREA-1026 IN PATH 01 WHEN SEGMENT-1026 = 'your segment'
* AND NAME-1026 = 'your area'
01OUT 080 D PS DD=OFA
01SORT NOSORT
01510001 ' 010 X-AREA-LOPAGE '
01510020 LOWPAGE-1026 FM '9999999999'
01520001 ' 010 X-AREA-HIPAGE '
01520020 CALCHIGHPAGE-1026 FM '9999999999'
the next step was to read the LOAD input data - for each record -
determine
the potential dbkey to which it would be assigned,
sort the data by that potential dbkey - and pass the input date to the
load
unscathed:
IN 080 PS DD=INF
REC I-RECORD 001 080 <== the length of the LOAD input
REC I-KEY 001 015 <== the position and length of the CALC key
IN 029 PS MB=DUMMY
REC PARM-FIELDS 001 029
REC Z-TARGET-PAGE 001 004 1
REC Z-HIGH-PAGE 005 004 1
REC Z-LOW-PAGE 009 004 1
REC Z-CALC-LENGTH 013 002 1
REC Z-CALC-VALUE 015 015
010 X-CALC-LENGTH 15 <== the calc key value
01OUT 080 D PS DD=OFA
01SORT Z-TARGET-PAGE
01510001 I-RECORD
017 CALL US33 (X-AREA-HIPAGE 8 Z-HIGH-PAGE 4)
017 CALL US33 (X-AREA-LOPAGE 8 Z-LOW-PAGE 4)
017 CALL US33 (X-CALC-LENGTH 8 Z-CALC-LENGTH 2)
017 CALL US43 (I-KEY Z-CALC-VALUE 15)
017 CALL US00 ('IDMSCALC' PARM-FIELDS)
010 X-AREA-LOPAGE 0006000001 <== the output from program 1
010 X-AREA-HIPAGE 0007005000
i could have written additional programs to make this process even more
generic and available to all load programs
(and to accomodate the same loads efen if such things as page range or
even
lenght of sort key changes - if
I get more such requests at work then i probably will make this a more
generic process
Chris Hoelscher
Senior IDMS & DB2 Database Administrator
Humana Inc
502-476-2538
choelscher@humana.com
The information transmitted is intended only for the person or entity to
which it is addressed and may contain CONFIDENTIAL material. If you
receive this material/information in error, please contact the sender
and delete or destroy the material/information.
The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: One program One queue Two Schemas in One CV
"Hi Gary,
Sorry for the delayed response...
I don't believe I can use your suggestion, and, I'm sure, it's my
explanation which is at fault. We have 10 trigger queues - tasks -
programs. These 10 queues are written to by many more than 10
programs. It would be difficult, in this current environment, for the
developers to open all those programs and maintain the changes of
choosing two different queue names based on the system version being
developed. Again, these two version should only be in existence till
the Fall when we should be back to one.
The problem on the other end, is if I start using different names,
coding changes are necessary in all 10 programs, which read from the
queues after being initiated.
A ""traffic cop"" program runs into the same problem.
But, by now, this problem has diminished. After realizing the
difficulties, the developers decided they could sacrifice their QA CV
until the two versions merge. Therefore, I can relax from this technical
difficult (unless an easier solution is available) and go forward to
others
Thanks again for trying!!!
Take Care,
Bruce
Office: (717) 605-2019
Cell: (610) 468-9506