ca.portal.admin

3985 During Startup of Release 16.0 SP2 (maximize Screen)

Discussion created by ca.portal.admin on Jul 19, 2005
Hello Everyone:

Has anyone seen this abort (U 3985) with IDMS Release 16.0 SP 2. The CV
comes all the way up but right after the Central Version Initialization
Complete
message is issued it aborts with the U 3985? The new SVC has been
installed
with CAIRIM, the Sysgen is pointing to the new SVC, the journals, log,
run and
scr were formatted, all dictionary updates were made.

Here is a cut and paste of the SMP/E control cards for linking the
startup
module, the usermod created by the install was used and the only change
was to
the RHDCPARM and WTOEXIT:

//DISTLOAD DD DSN=DO.NOT.CHANGE.DISTLOAD,DISP=SHR
//SYSLMOD DD DSN=DO.NOT.CHANGE.LOADLIB,DISP=SHR
//SYSLIN DD *
INCLUDE DISTLOAD(TESTPARM)
INCLUDE DISTLOAD(RHDCOMWP)
INCLUDE DISTLOAD(RHDCOESA)
INCLUDE DISTLOAD(RHDCOMOC)
INCLUDE DISTLOAD(RHDCHPCS)
INCLUDE DISTLOAD(RHDCACHE)
INCLUDE DISTLOAD(RHDCOPTS)
INCLUDE DISTLOAD(TESTEXIT)
ENTRY STARTUP
NAME TESTDBCV(R)
/*
++SRC(TESTPARM) DISTLIB(DISTSRC) DISTMOD(DISTLOAD) TXLIB(PPOPTION).
++SRC(TESTEXIT) DISTLIB(DISTSRC) DISTMOD(DISTLOAD) TXLIB(PPOPTION).

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Performance monitor question
"Does anyone know how to monitor a table procedure? You can't select it
by program name, because the top-level program is always something else
- OCF, BCF, IDMS Server task, etc.

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
U 3985 Abort resolved
"Hello All:

During the normal installation I ran the SGENCOPY job to copy everything
from system 99 to our running system. During Startup there were a large amount
of PTERM error messages and of course the U 3985 Abort.

To correct this I modified the SGENCOPY job to only copy the TASKS and
PROGRAMS to our running system. This resolved the startup PTERM error messages and
the U 3985 Abort.

There is a problem with PTERMS that were added to the dictionary using IDD
or IDMSDDDL. It has to do with the new feature/parameter on the PTERM
Definition called REPEAT COUNT.

This will not occur at any site that adds their PTERM & LTERMS using the
SYSGEN Compiler only. I have never added a PTERM using IDD, I always use the
SYSGEN Compiler, someone at this site must have used IDD at one time.

I am attaching a Document that explains the problem and provides a
correction.

Bill Allen
ARCH Consulting Associates, Ltd.

Just in case you cannot get the attachment, here is a cut and paste:


Author: Brian Brendlinger
Product: CA-IDMS/DB
Release: 14.1, 15.0, 16.0
Platform: OS/390,z/OS, VSEESA, z/VM
ComponSent: CAIDMS
Q: Are there any procedures undocumented in 16.0 UPGRADE instructions that
must be performed to my SYSTEM definition to avoid any unexpected problems?
A: The PTERM definition in 16.0 has a new parameter called REPEAT COUNT.
Prior to 16.0 the element REPEAT-COUNT-074 in dictionary record PTRM-074 was the
first 2 bytes of an 8 byte FILLER element.
We have discovered that PTERM definitions that were added through
IDD/IDMSDDDL had this FILLER field initialized as SPACES. PTERM definitions added
through the SYSGEN compiler had this FILLER initialized to binary zeroes. Any
PTERM's added through IDD/IDMSDDDL therefore would contain X’4040’ in this
element.
In 16.0 the REPEAT-COUNT-074 element is defined as a binary numeric so any
PTRM-074 records that were added through IDD/DDDL will show a REPEAT COUNT of
16448.
Use subschema IDMSNWKA in OLQ or similar product or program to view this
element in each PTRM-074 record in the SYSTEM.DDLDML area. If there are any that
contain spaces in this element, they need to be modified to contain binary
zeroes. There are several ways to accomplish this. One way is to exclude the
PTERM from each SYSTEM in which it has been included, physically delete it
from the dictionary using IDD/IDMSDDDL, then ADD the PTERM definition back to
the appropriate SYSTEM(S) using the SYSGEN/RHDCSGEN compiler.

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Collecting Stats for PMAM Reports
"Hi,



We currently have set statistics collection off to preserve resources.
If we wanted to be able to produce PMAM reports 31 and 36 to examine
wait stats temporarily would we just need to have Transaction stats
being collected by this entry in the sysgen SYSTEM statement STATISTICS
INTERVAL OFF NOLINE TASK WRITE NOUSER TRANSACTION ?



Thanks



Chris Wood

Alberta Department of Energy

CANADA

This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact us immediately if you are not the intended recipients of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed.

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Collecting Stats for PMAM Reports
"STATISTICS INTERVAL OFF NOLINE TASK WRITE NOUSER TRANSACTION ?

You don't need the ""WRITE"" component for PerfMon - ""COLLECT"" is all that is
required. ""WRITE"" causes stats to be written to the DC Log which can cause
performance issues. ""COLLECT"" just accumulates the stats in control blocks
which PerfMon will then deal with according to your settings in the #PMOPT
macro. In #PMOPT you can direct the stats to the Log or SMF. For performance
reasons of course SMF is recommended - avoid the Log.

TRANSACTION/NOTRANSACTION is interesting - I don't think that there's any
cost for having it set. What it lets you do is a BIND TRANSACTION STATISTICS
to initiate collection of stats for a ""transaction"" that can span multiple
tasks - then you can do an ACCEPT TRANSACTION STATISTICS to get these stats
- and finally an END TRANSACTION STATISTICS to end the collection. This
would be useful for determining the total cost of a ""business transaction""
that spans multiple ADS/Cobol screens for example. I have never seen anybody
use this - but the functionality is there. I note from the sysgen manual
that TRANSACTION is required for ADS statistics to be enabled.

Back to the original question - it's the TASK COLLECT/ TASK WRITE / NOTASK
option that affects PerfMon. With NOTASK PerfMon will not be able give you
any information at all. I think a look at the PerfMon Administration manual
would be advised - as I have not followed my own advice to many people which
is to read the manual - so the information in this e-mail may be
contaminated by the odd ""elderly moment"" or two. ;-)

HTH - cheers - Gary


Gary Cherlet
Justice Technology Services
Telephone +61 (0)8 8226 5199
Facsimile +61 (0)8 8226 5311
Mobile +61 (0)41 333 1613
MailTo:cherlet.gary@saugov.sa.gov.au

This e-mail message and any attachments are qualified as follows:
Addressing: If you have received this e-mail in error, please advise by
reply e-mail to the sender. Please also destroy the original transmission
and its contents.
Confidentiality: This e-mail may contain confidential information which
also may be legally privileged. Only the intended recipient(s) may access,
use, distribute or copy this e-mail.
Individual Views: Unless otherwise indicated, the views expressed are those
of the sender, not Justice Technology Services.
Computer Viruses: It is the recipient's responsibility to check the e-mail
and any attached files for viruses.

Outcomes