ca.portal.admin

Re: [IDMSVENDOR-L] Diagnostics and Symbol tables - another

Discussion created by ca.portal.admin on Feb 1, 2008
question

It's been a while since I've dealt with any of this here's how I
remember it working. The symbol/diagnostic flag is in the load module
but when it abends it will try to go to the dictionary it was compile in
to find the source. If you compile your dialog in the test dictionary
with diagnostics then move it to your prod loadlib run out of the prod
loadlib here's what I think happens. When the dialog abends it will try
to find the process source in the dictionary it was compiled against.
More than likely you don't have the test dictionary defined to your
production IDMS so you will get an error when it tries to get the
process source. I think maybe it's a 1472 but I don't really remember.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
CA IDMS R17
"CA is pleased to offer you the opportunity to participate in the CA
IDMS^(TM) r17 Beta program. Scheduled to begin beta testing in
March 2008, CA IDMS r17 includes many highly requested features to
address improved open access, performance, availability and ease of use.


To learn more and register, see the CA IDMS r17 beta website
<http://supportconnectw.ca.com/public/beta/idms17/idms17beta.asp>. You
must log on to SupportConnect to access the site.



As a participant of this beta program, you will gain early access to new
features and contribute directly to the success of this release. We
consider your active participation in this program an essential part of
our ongoing development effort to deliver a quality product.



Your contribution to this critical product test cycle is directly
related to the success of the generally available (GA) release of CA
products and ensures we deliver solutions that are ready to meet your
real-world requirements. It should be noted that specific features and
functionality in the Beta products as well as any planned release dates
are subject to change based on the results of the Beta tests. CA does
not warranty that the product is generally available and therefore may
not comply with the initial design specifications.



As a participant in the beta program, you will communicate directly with
the Beta Research and Development team to investigate and address any
reported problems, questions, or comments.



Key CA IDMS r17 Features:

* **Open access**

o SQL routines written in SQL
o ANSI/ISO SQL Join
o SQL returned result sets
o New TCP/IP socket APIs

* Performance **

o zIIP exploitation
o CICS threadsafe application support
o CA IDMS DDS communications using TCP/IP
o Scratch area above the bar
o Large format files

* Availability **

o Dynamic journals
o Fault-tolerant CV changes
o Enhanced online tuning of indexes
o Extensible scratch
o FAST Format journal

* Ease of use **

o TCP/IP administration
o Enhanced Reorg, Print Index, and Tune Index utilities
o Enhanced warnings and diagnostics
o Numerous operational and application development enhancements

For more information and to register for the CA IDMS r17 beta program,
please go to the CA IDMS r17 beta website
<http://supportconnectw.ca.com/public/beta/idms17/idms17beta.asp>.



And for more information on CA's Enhanced Beta Programs and
Participation Requirements please visit ca.com/betas
<http://www.ca.com/betas>.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Writing to a queue from a COBOL subprogram
"Here's something you may want to consider.

I assume the problem here is you have three run-units (yours, the queue
run-unit, and the run-unit from the calling program).

You need something to signal you want to keep the results of the queue work,
hence the FINISH TASK.

The problem is that it FINISHes ALL run-units, including the one from the
calling program. If you DON'T tell IDMS you're done with the queue work, it
will get rolled back at step termination.

HOWEVER....

If you are willing to issue a COMMIT TASK (followed by a FINISH for your
run-unit), you should ensure what you've done with the queue to that point
stays put (at end of your batch program IDMS may complain about you not
FINISHing the queue run-unit, but it MAY be OK).

The consideration here is the impact of the COMMIT TASK on the calling
run-unit; if it is an update run-unit you won't be able to automatically
recover back prior to the COMMIT if an abort happens. This is likely not
acceptable. If it's a retrieval run-unit you may be OK with this approach.

For what it's worth.

Don Casey
Run Right, LLC

Outcomes