Re:Re: [IDMSVENDOR-L] Strange thing in IDMS 17.0 SP1 DCLOG

Discussion created by ca.portal.admin on May 5, 2010
are you checking for ""both"" log full msgs?


i believe DC050004 is spit out when the log is 100% full - this message is
NOT checked by vanilla WTOexit

i have seen a log fill up so quicly due to a dump that the DC050001 is
never issues - only the DC050004 - and the vamilla wtoexit would never
catch it

Chris Hoelscher
IDMS/DB2 Database Architect
Humana Inc

you only need to test the programs that you want to work correctly

""William M. Allen, Jr."" <archcons@ARCHCONS.COM>
05/05/2010 04:29 PM
[IDMSVENDOR-L] Strange thing in IDMS 17.0 SP1 DCLOG
Sent by:
IDMS 3rd-party providers forum <IDMSVENDOR-L@LISTSERV.IUASSN.COM>

Hello All:

I just upgraded another Client to 17.0 SP1 and we are having a few issues;
one was with TSSMAI from Top Secret and there is a fix for that from CA.

The next issue is that the CV is not spitting out the log % full message
what is happening is that the log is filling up and the offload job is
getting submitted?

The exit is fine because it is submitting the Journal archive just fine.

The Messages for the Journal and log have the same destination and OS
codes, I have checked all of that. I have even restored and re-received
applied the startup user modification with no change.

The Log was formatted before we brought the CV up using IDMS 17.0 SP1

We also had an issue with easy test causing system module program checks
near RHDCUXIT with all the tool kit exits installed. We have pulled all
exits from RHDCUXIT and easy test works fine. We still have to work with
vendors on a resolution for this one.

The last issue is the submission of the log archive, I know the exit is
working and the log has filled many times, but the IDMS Region is simply
issuing the log % full message?

And here is another strange thing when we view the log with LOGD we see
these system module program checks from four days ago and the log has
at least five times since then because we have to archive it manually.

So my question is how does IDMS issue that log message, is there some sort
of header record in the log that might be corrupted?

We can always format the log but the Client is reluctant to do that
an explanation of why this is happening.

William M. Allen, Jr.

ARCH Consulting Associates, Ltd.

(704) 641-0296

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


"Re: question about ""get storage"""
"I'm a long time lurker here and thought I would offer my two cents. I
have a little experience playing with GET STORAGE as an application
programmer, and think that the operation of the GET STORAGE in PROGRAMA
is being misunderstood.

Here's what the manual says:

""The GET STORAGE statement is used either to acquire variable storage
from a DC system storage pool or to obtain the address of a previously
acquired storage area.""

Assuming I understand the app correctly, the GET STORAGE in PROGRAMB
will initially acquire the storage and assign a STGID. The GET STORAGE
in PROGRAMA, using the same STGID, then merely obtains the address of
the previously acquired storage and associates that address with the
named 01 level in PROGRAMA's linkage section. Since the STGID already
exists, any parameters in the GET STORAGE in PROGRAMA that appear to
define size have no effect; you get addressability to what was
previously acquired by PROGRAMB. No new storage is obtained, and there
is no 'moving' of data into the linkage section of PROGRAMA, as it's the
same space. So nothing should get clobbered by the GET STORAGE itself.
The program code is, of course, another story. There are all sorts of
possibilities, including the case where PROGRAMB acquires less storage
than the maximum defined in the linkage section of PROGRAMA.

Tom McFarland
Educational Testing Service
(609) 734-1147