When first learning IDMS, an expert DBA told me that using SYSIDMS parms
like the following could help reduce the time it took for a reload of a
large area to run (and sometimes it also reduces run time for DBANs):
//SYSIDMS DD *
ECHO=ON
DMCL=SD51DMCL
DICTNAME=PRODDICT
DBNAME=PRODDB00
USERCAT=OFF
PREFETCH=ON
DLBLMOD=ON
IDMSQSAM=ON
JOURNAL=OFF
BUFFERSTAT
PREFETCH_BUF=30
QSAMAREA=FMS-BI-A
QSAMBUF#=100
/*
In my experience, I have found this to be true most of the time. I have
also found that sometimes the parms have little to no effect, and in a
few situations, the QSAM parms have actually caused reloads to run
longer than without the parms. The expert DBA did not recommend these
parms for unloads or for restructures, but being quite the ""newbie"" at
the time, I never asked why not. I've never tried using the parms for
unloads or for restructures. I've read everything in the manuals that I
could find, but all I've learned is that QSAM uses sequential reads and
the restructure utility uses chained reads. A few months ago, I did a
restructure segment and restructure connect segment to add 8 pointers
across 3 areas containing 22 million records total. It took 2.7 hours
total. A co-worker of mine just did the same type of work, adding 9
pointers across 6 areas containing a total of 18 million records. For
some unknown reason, she put the QSAM parms in her restructure JCL. Her
restructure took more than 21 hours. So, my question is this--can
anyone tell me the difference between sequential reads and chained
reads, if any? Could the QSAM parms have been why the latter
restructure took incredibly longer?
Thanks in advance for your help!
*******************************************************
Christine A. Laughlin
Computer Information Technology Specialist I
Missouri Office of Administration
Information Technology Services Division
IDMS Database Administration
1621 East Elm Street
Jefferson City, MO 65101
(573) 751-2056 phone
Christine.A.Laughlin@dss.mo.gov
********************************
CONFIDENTIALITY STATEMSent: This electronic communication is from the
Department of Social Services (DSS) and is confidential, privileged, and
intended only for the use of the recipient named above. If you are not
the intended recipient or agent responsible for delivering the
information to the intended recipient, unauthorized disclosure, copying,
distribution or use of the contents of this transmission is strictly
prohibited. If you have received this transmission in error, please
notify the sender and delete all copies from your system.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: SYSIDMS QSAM PARMS
"Hello Christine:
In my experience you should never have both QSAM & PREFETCH in the same
SYSIDMS. For most Unload's & reload's I use IDMSQSAM=ON and QSAMBUF#=250. I have
used PREFETCH with a large number of buffers, PREFETCH_BUF=5000 and this
helps as well, it really depends on the utility function. Some time ago I
published results of testing between QSAM & PREFETCH of an area with 36 Million
records to the list.
I will try to see if I can find it and will send it to the list.
One thing for sure the data structure can really affect an Unload/Reload,
especially if the main record in the area is stored VIA an Index, in that case
IDMS will retrieve every member record thru the index.
Bill Allen
ARCH Consulting Associates, Ltd.
In a message dated 9/6/2005 2:08:57 P.M. Eastern Daylight Time,
Christine.A.Laughlin@DSS.MO.GOV writes:
When first learning IDMS, an expert DBA told me that using SYSIDMS parms
like the following could help reduce the time it took for a reload of a
large area to run (and sometimes it also reduces run time for DBANs):
=20
//SYSIDMS DD * =20
ECHO=3DON =20
DMCL=3DSD51DMCL =20
DICTNAME=3DPRODDICT=20
DBNAME=3DPRODDB00 =20
USERCAT=3DOFF =20
PREFETCH=3DON =20
DLBLMOD=3DON =20
IDMSQSAM=3DON =20
JOURNAL=3DOFF =20
BUFFERSTAT =20
PREFETCH_BUF=3D30 =20
QSAMAREA=3DFMS-BI-A=20
QSAMBUF#=3D100 =20
/* =20
=20
In my experience, I have found this to be true most of the time. I have
also found that sometimes the parms have little to no effect, and in a
few situations, the QSAM parms have actually caused reloads to run
longer than without the parms. The expert DBA did not recommend these
parms for unloads or for restructures, but being quite the ""newbie"" at
the time, I never asked why not. I've never tried using the parms for
unloads or for restructures. I've read everything in the manuals that I
could find, but all I've learned is that QSAM uses sequential reads and
the restructure utility uses chained reads. A few months ago, I did a
restructure segment and restructure connect segment to add 8 pointers
across 3 areas containing 22 million records total. It took 2.7 hours
total. A co-worker of mine just did the same type of work, adding 9
pointers across 6 areas containing a total of 18 million records. For
some unknown reason, she put the QSAM parms in her restructure JCL. Her
restructure took more than 21 hours. So, my question is this--can
anyone tell me the difference between sequential reads and chained
reads, if any? Could the QSAM parms have been why the latter
restructure took incredibly longer?
=20
Thanks in advance for your help!=20
=20
*******************************************************
Christine A. Laughlin
Computer Information Technology Specialist I
Missouri Office of Administration
Information Technology Services Division
IDMS Database Administration
1621 East Elm Street
Jefferson City, MO 65101
(573) 751-2056 phone
Christine.A.Laughlin@dss.mo.gov (mailTo:
Christine.A.Laughlin@dss.mo.gov)
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: ADS/BATCH
"Sam,
We use ADS/Batch and there has ALWAYS been issues...............
Scott Brady
Holland America Line
SBrady@HollandAmerica.com
________________________________
From: IDMS Public Discussion Forum on behalf of Mowbray, Sam
Sent: Tue 9/6/2005 6:20 PM
To:
IDMS-L@LISTSERV.IUASSN.COM
Subject: ADS/BATCH
Hi List,
Out of interest is there anyone using ADS/BATCH? We upgraded a site to
16.2 and came across some issues.
Regards
Sam
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
ADS/BATCH
"Hi List,
Out of interest is there anyone using ADS/BATCH? We upgraded a site to
16.2 and came across some issues.
Regards
Sam
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Mainframe CCI component
"We have been having a lot of problems with the mainframe CCI component
used by IDMS Server. Since this software lacks many of the useful
features that IDMS has (online monitor, ability to cancel a task,
optional timeout values, consistant task numbers, etc.), I am having
great difficulty correlating CCI events with IDMS events, or intervening
when problems occur.
Can anyone share tips and hints for debugging mainframe CCI problems?
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
Re: Mainframe CCI component
"Kay,
You are correct, debugging problems in CCI is a pain. Here are some things we do.
At 30 minute intervals, using automation, we issue a STATUS command against each CCI started task(we run 7). The following is a sample output display:
F CCITCP,STATUS
TASK# STATUS PC NAME PC APPLICATION PC IP ADDRESS/PORT #
#0001 ACTV #PCUserName IDMS0000275802345988 x.xx.xx.182/1518
CAS9899I: END OF LIST
This does tell us how many users are currently connected to the IDMS CV's via CCI. It does not tell you which CV's they are connected to. This is a problem for us since we have access to 10 different CV's via CCI. If you look at a memory display in the CV of the PTE entry of the CCI terminal, at offset x'12E' you can match up the ""PC APPLICATION"" field of the CCI STATUS display. At offset x'15C' is the IDMS userid. At offset x'184' is the task code being executed (default is CASERVER).
We also put a hook into exit 29 to make sure that all CCI terminals display the signon message (DC258003). For unknown reasons, by design this is not done normally.
Unfortunately, for most of the debugging, once we have the user's name (via the PCUserName or the IDMS UserID) we have to ask them what they were doing.
Once you get the problem narrowed down, there are several logging options available in the ODBC Admin panel. If you can recreate the issue, turn on the appropriate logging and rerun the transaction. The resulting logs will produce all the data you could ask for. CA has always been helpful examining these logs when I've passed them on.
BTW, if you are running an old version of CCI (and CA90s?), all storage is acquired below the line. This is a problem we ran into several years ago. CA has long since had this corrected, but you need to be sure you are relatively up to date with this software.
Daniel L. Hall
GE
Sr Systems Engineer
T 513-583-3525
D *330-3525
E
dan.hall@corporate.ge.com
www.ge.com
8700 Governors Hill Dr.
Cincinnati, OH. 45005
General Electric Company