IDMS

  • 1.  SYSIDMS QSAM PARMS

    Posted Sep 06, 2005 07:03 AM
    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