ca.portal.admin

SYSIDMS QSAM PARMS

Discussion created by ca.portal.admin on Sep 6, 2005
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

-----Original Message-----
From: IDMS 3rd-party providers forum [mailTo:IDMSVENDOR-L@LISTSERV.IUASSN.COM] On Behalf Of Rozeboom, Kay [DAS]
Sent: Wednesday, September 07, 2005 12:40 PM
To: IDMSVENDOR-L@LISTSERV.IUASSN.COM
Subject: 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
ca world
"Hi everyone,

The IUA CA World conference committee just wanted to remind everyone that the early bird discount for registration ends just around the corner, on Monday September 12th 2005. Register by then and take $200 off the listed price. If you're a member of a CA user group, like the IUA, then you can get an additional $200 discount.

Visit www.ca.com/caworld for more details on ca world 2005.

I hope to see you in Las Vegas.

Laura Rochon
IUA

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








Normal

Normal
IDMS Server security
"Our site recently completed a large project to improve our security for
IDMS Server. Here are a couple of things we discovered, and corrected,
that some people may not realize:

- You do not have to enter a valid task code in the ODBC definition.
This defaults to task 'CASERVER'. But 'IDD', 'KAY', or 'XXXXXXXX' will
all work just fine, unless you have secured ALL task codes (valid or
invalid) in the SRTT, not just the IDMS Server ones. Another solution
is to use security exit 28 to check the task codes.

- If signon is not required for a CV (RESTYPE 'SGON' in the SRTT), then
your IDMS Server signon will check the user ID, but not the password!
It will accept any and all passwords as long as the user ID is valid.
The only solution I know of is to make signon required for any CV with
IDMS Server access. Along with any other changes that may result. (We
had been using CICS as a trusted source. But of course IDMS Server does
not go through CICS. It's a new world.)

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
IDMS-DC calls to IDMS-DC sub programs
"Hello All:

I have an ADSO Dialog that calls an IDMS-DC COBOL program, then that program
calls another IDMS-DC COBOL Program.

The question is this, can the IDMS-DC COBOL programs use dynamic calls or do
they have to use static calls?

ADSO Calls
IDMS-DC Program A, then this program calls
IDMS-DC Program B

Can program A use a dynamic call to IDMS-DC Program B?

Where can I read about this in the IDMS Manuals?

Bill Allen

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








Normal

Normal
Re: IDMS-DC calls to IDMS-DC sub programs
"Bill, the COBOL calls, as opposed to the idmsdc transfer controls could
be expensive. At one time idmsdc was enhanced with an svc screen to
trap getmains to initialize the cobol run time environment and turn
those into getstorage calls from an idms storage pool. For some reason
which I never fathomed, some users cant or wont change their cobol
source into idmsdc dml. I do believe transfer control is the preferred
way. The problem has always been the mvs service requests that cobol
programs did, and the storage(loads, etc) that mvs carved out of idms
regions beyond idms control. Also some mvs storage may be freemained,
but not reusable until idms comes to mvs job termination.

Lutz Petzold


-----------------------------------------
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by
reply e-mail and then delete this e-mail immediately. Thank you.
Aetna


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








Normal

Normal
IDMS 14.0 and Z/OS 1.4
"Hi,

Is it a site using IDMS Rel 14.0 on a Z/OS 1.4 system ?

Thanks,
Rene.

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








Normal

Normal
Re: IDMS-DC calls to IDMS-DC sub programs
"Bill,

I think you need to look at the TRANSFER CONTROL statement in the IDMS DML
Reference - Cobol manual.
There are also discussions about compiler and linkage options.

Tommy Petersen





Hello All:

I have an ADSO Dialog that calls an IDMS-DC COBOL program, then that
program
calls another IDMS-DC COBOL Program.

The question is this, can the IDMS-DC COBOL programs use dynamic calls or
do
they have to use static calls?

ADSO Calls
IDMS-DC Program A, then this program calls
IDMS-DC Program B

Can program A use a dynamic call to IDMS-DC Program B?

Where can I read about this in the IDMS Manuals?

Bill Allen

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








Normal

Normal
Re: IDMS-DC calls to IDMS-DC sub programs
"If memory serves correctly IDMS-DC does not support the DYNAM compiler
option. However, if in Cobol you do a CALL variable-name the CALL will
become a DYNAMIC call. STo:

- if you have a DC-Cobol program with CALL 'literal' and NODYNAM specified
as a compiler option - the CALL will be static and the ""called"" program will
become link edited into the resultant load module

- if you have a DC-Cobol program with CALL variable-name and NODYNAM you
will have a ""dynamic"" call and the ""called"" program will be loaded as a
separate executable at run time

We have been running in this manner since we converted from Fujitsu to
OS/370 in 1998 (now z/OS) - we were Release 12.0 at the time and are
currently Release 16.0 SP(1). Just for completeness - our batch Cobol
programs are compiled with DYNAM and all CALL statements are dynamic
regardless of whether or not they call 'literal' or variable-name.

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