DB Analyzer DBNAME not working

Discussion created by ca.portal.admin on May 16, 2007
Hello All:

I cannot get DB Analyzer to honor a DBNAME in SYSIDMS? We are running
IDMS 15.0 SP3, is anyone aware of any problems with this? It appears to
be ignoring Subschema Mapping Rules in the DBTABLE and also the DBNAME
supplied in SYSIDMS, I also put a PARM='DBNAME=SEG2' on the execute

What we have is two segments with the same areas names, example
SEG1.area-1 and SEG2.area-1, no matter what I do I cannot get it to
select SEG2 as the DBNAME?

Also take note that SEG1 happens to be in the first DBNAME in the
DBTABLE as well.

What also makes this suspicious is what I found on Support Connect:

Question: How and in what order are DBNAME/DBNODE values processed
by the CA-IDMS batch tools - in particular Advantage CA-IDMS
DB/Analyzer, Advantage CA-IDMS DB/Audit and Advantage CA-IDMS DB/Reorg.
The CA-IDMS batch tools use the DBIO sub-component modules to build a
Pseudo Subschema and associated control blocks for use in the batch
environment. In particular, this affects Advantage CA-IDMS DB/Audit,
Advantage CA-IDMS DB/Analyzer, Advantage CA-IDMS DB/Reorg and the batch
components of Advantage CA-IDMS Database Extractor. The DBNAME and
DBNODE (or in the case of Advantage CA-IDMS DB/Reorg OLDDBN and NEWDBN)
parameters may be used to pass a DBNAME/DBNODE value to these DBIO
routines. The order of processing of DBNAME/DBNODE when building the
control blocks is as follows:
1. Use the DBNAME/DBNODE (if any) that was passed as a product
2. Use the DBNAME/DBNODE (if any) that was specified in the SYSIDMS
parameters by issuing a #GETPROF Macro.
3. If neither of the above contains any value then DBNAME/DBNODE
values are set to blanks.

************************************** See what's free at
IDMS Public Discussion Forum


Modifying an IDD record
"OK, I'm adding some fields to an existing database record, actually carving some bytes out of an already-allocated FILLER area. I haven't done this in a while (we're a CAS shop) so did some experimentation on my test dictionary, and I have the process all figured out except for when the time comes to actually make the change to the record - the only way I have been able to get the changes into the record (once it's been 'detached' from the schema) is to delete the record and re-add it with the new record layout.

Of course, as far as what fields are available to dialogs and programs that use the record, this accomplished my objective, but surely I'm missing something.

Anyone have any words of wisdom for me?

Thanks as usual to all the great folks on IDMS-L who are always ready and willing to help.


Michel J Champagne
Systems Analyst / DBA
Voice: 504-712-7589
FAX: 504-712-3589

Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
IDMS Public Discussion Forum


Modifying non-IDD owned records
"You can certainly create a new version of the new record and modify the
schema to include it, but this will cause all of the subschemas, maps, etc.
to be flagged for re-generation. A far less intrusive is to modify the
record that is in the schema directly. In the case of simply naming fields
in a previous FILLER space, this is very easy to do and has NO impact on the
entities associated with the schema (maps, subschemas, programs, etc) except
those which need to address the new fields. The DDDL documentation has a
special writeup under the title ""Modification of non-IDD Owned Records"" that
has numerous syntax examples on how this is done. It's been in the doc
since 10.0. Hope this helps.
IDMS Public Discussion Forum


Re: Linking Rules Extended and not with DC and Batch
"I think that you are wrestling with a couple of issues here. The first -
the MODE - defines the protocol that is used to access IDMS services.
What the MODE does is directs the pre-compiler to generate different
code to pass to the compiler. In a BATCH environment the IDMS calls are
to a module called IDMS, while DC-BATCH the calls go to IDMSDCBI and DC
calls go to IDMSCOBI. Depending on the MODE different functionality is
supported based on the environment that your program has indicated it
will be running in. MODE is BATCH does not support any but Database
verbs, DC-BATCH supports all database verbs PLUS the WRITE PRINTER and
QUEUE related commands. MODE is DC supports all of the above, plus
SCRATCH, STORAGE, TERMINAL, MAPPING and other ""DC"" type functionality.

The second issue that you are dealing with has to do with accessibility
to SUBSCHEMA-CONTROL and already bound RUN UNITs. In order to have any
communication with IDMS requires SUBSCHEMA-CONTROL - which is used to at
a minimum pass the DB/DC verbs being invoked, other verb specific
parameters, and receive status information back. Whether or not a RUN
UNIT is extended decides whether or not an existing, already BOUND
SUBSCHEMA-CONTROL is passed to the CALLED program. In the case where an
existing Run Unit is extended the CALLED program receives
chose to ignore this SUBSCHEMA-CONTROL (using a DUMMY place holder in
the Procedure Division USING statement) and BIND its own RUN UNIT with a

When there is no RUN UNIT extension - the CALLED program MUST establish
its own SUBSCHEMA-CONTROL and issue the appropriate house keeping
commands - BIND RUN UNIT and so forth. It might issue the FINISH after
each call - or if it will be CALLED multiple times it might do only the
BIND on the first call and FINISH on the last call - or can rely on the
mainline to do a FINISH TASK which explicitly finishes all bound RUN
UNITS associated with the entire TASK.

Confused? So are lots of people - if there's anything I can do to
clarify please let me know - cheers - Gary