ca.portal.admin

Modifying non-IDD owned records

Discussion created by ca.portal.admin on May 18, 2007
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
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Linking Rules Extended and not with DC and Batch
"Hi Gary,

Thanks for the explanation, but I actually wasn't confused on those principals. Let's just say, I've been around for a long time. I've created my own dictionary MODE profiles and advised many on SUBSCHEMA-CONTROL in the ADS and program environment. Heck, I knew Jon Gocher when he was a young IDMS energetic upstart in Cullinet making his way. He must be 70 by now. We sometimes taught the IDMS classes in separate rooms in the Philadelphia Office where coffee and donuts were plentiful. (I was fairly young too!)

The real problem is - sometimes one hasn't tackled an issue that was close to one's heart for many years, and in this case, understanding your very wonderful and detailed explanation, I wanted to be sure the explanation I stated for our programmers was accurate. You see we are developing a few programs, where each will be called from ADS, BATCH, and DC-BATCH, and I wanted to be sure my statements were accurate as I look for tricks and ingenious methods to avoid maintaining two programs for reasons of different MODES. I can come up with the TRICKS. I look to others for the ingenious methods (Jon - are you listening???).

Any help is always appreciated.

Take Care,
Bruce
NAVSISA - (717) 605-2019 DSN 430-2019
Cell - (610) 468-9506

________________________________

From: IDMS Public Discussion Forum on behalf of Cherlet, Gary (JTS)
Sent: Thu 5/17/2007 6:45 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: 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
SUBSCHEMA-CONTROL in its LINKAGE SECTION. In fact the CALLED program can
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
SUBSCHEMA-CONTROL that is in its WORKING STORAGE.

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

Outcomes