ca.portal.admin

One program One queue Two Schemas in One CV

Discussion created by ca.portal.admin on Apr 28, 2008
Latest reply on Apr 28, 2008 by ca.portal.admin
Hi,

Help!
I have a problem that needs a simple (or very little programming)
solution. If not possible, I believe, our other course is to use two
CVs.

Current environmSent:
1. ADS/DC-COBOL writes to a trigger queue. (we have about 10 of these
situations)
2. Queue-QA starts associated ""non-terminal"" Task-TA which initiates
associated Program-PA 3. Same with Queue-QB 4. With a necessary and
complex evil, we have two projects in development which require separate
Database schemas till August, when they can be combined. (Don't go
there... Please!) 4. Both projects will use most of the, approx. 10,
trigger queues 5. Program PA needs to access Database Version-D1, and,
you guessed it, PB needs to access D2. That is, trigger initiated
programs need to see their version (schema changes) of the database.
6. The queue record contains the database name and can be used to choose
the correct version of the queue initiated DC-COBOL load module compiled
against the appropriate dictionary/subschema.
7. Source between PA and PB is currently different, but, someday,
hopefully in the fall, will be the same again.

Problem:
1. Current environment exists and works well.
2. Is it possible for CV to choose correctly from two DC-COBOL programs
with the same name from a non-terminal task 3. It appears that DCUF SET
TEST is not available in this environment.
3. I believe a non-terminal task does not maintain user info, such as,
DICTNAME or DBNAME.
4. There are versions in queues, but, my reading seems to indicate only
one version can be used by CV.
5. And worse, some of these DC-COBOLs start a SET TIMER to re-inititiate
themselves if failure occurs during the process. One in particular is
continuously re-starting at set intervals.

Again, just in case I missed a feature or lack the brain power, does
anyone see an alternative, rather than a second CV.

Just for infTo:
I have already designed a ""traffic cop"" type program which will be
started by each queue, but it requires maintaining two programs for each
DC-COBOL with different internal and external names and queue
references, etc.
But, again. It's deemed not worth the effort compared to using another
CV till the Fall of this year.

I hope I explained this problem sufficiently!


Take Care,
Bruce
Office: (717) 605-2019
Cell: (610) 468-9506
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
OUT OF THE CLOSET: IDMSCALC on the fly
"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.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: OUT OF THE CLOSET: IDMSCALC on the fly
"Chris:

Did you sort DBKEY's in descending sequence instead of ascending
sequence? Theoretically, it should result in smaller calc overflow.
Also, do you load any VIA records along with their CALC owning records
at the same time? I do this in a generic utility I wrote for Lockheed
Martin. Unfortunately, I am not permitted to share code but I can share
ideas.


Dan Miley
Lockheed Martin

Outcomes