IDMS

Expand all | Collapse all

Writing to a queue from a COBOL subprogram

  • 1.  Writing to a queue from a COBOL subprogram

    Posted Feb 04, 2008 09:12 AM
    I have a batch COBOL program which calls another batch COBOL subprogram. I
    want this subprogram to write to a queue; it will also write a database
    record. But I am having bind issues. According to my understanding, in
    order for my subprogram to write to a queue, it must issue a BIND TASK and a
    FINISH TASK. I have my subprogram's PROTOCOL statement as DC-BATCH DEBUG,
    and COPY IDMS SUBSCHEMA-CONTROL in my working storage. My subprogram
    immediately does a BIND TASK, and a COPY IDMS SUBSCHEMA-BINDS. Then I ready
    my areas that my subprogram needs. When I leave my subprogram, I do a
    FINISH and FINISH TASK. When I run it, I get an 0077 in my calling program
    as soon as I return from my subprogram and attempt another DML command, so I
    assume my FINISH TASK finished my calling program's run unit. I have
    experimented somewhat, but no luck. I would prefer to not have to extend my
    run unit to my subprogram if possible. Can anyone shed some light on what
    needs to be done for this to work successfully? I have written IDMS batch
    COBOL programs that use queues before, but they have always been stand-alone
    and not subprograms.

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








    Normal

    Normal
    Re: Writing to a queue from a COBOL subprogram
    "
    A run-unit is identified by the address of the subschema-control used on the bind run-unit command.

    Is the calling program pass as a parameter to the subprogram the subschema control of the calling program used on the bind run-unit of the called subprogram? If this the case
    i assume that the FINISH of the subprogram terminate the common run-unit. For not to extend the calling program run-unit, I recommandthat the calling program pass the data to the subprogram in a way that the subprogram execute his bind run-unit not using the subschema-control of the calling program.

    Michel Lamoureux B.A., B.Sc.PrésidentLacosi Inc.212, ch. des Patriotes SudMont-Saint-Hilaire (Québec)J3H 3G6Tél.: (450) 281-2031Téléc.: (450) 281-2032Cell.: (514) 462-4282michel.lamoureux@videotron.cawww.lacosi.com> Date: Mon, 4 Feb 2008 16:12:06 -0600> From: JHUTCHIN@IPSCO.COM> Subject: Writing to a queue from a COBOL subprogram> To: IDMS-L@LISTSERV.IUASSN.COM> > I have a batch COBOL program which calls another batch COBOL subprogram. I want this subprogram to write to a queue; it will also write a database record. But I am having bind issues. According to my understanding, in order for my subprogram to write to a queue, it must issue a BIND TASK and a FINISH TASK. I have my subprogram's PROTOCOL statement as DC-BATCH DEBUG, and COPY IDMS SUBSCHEMA-CONTROL in my working storage. My subprogram immediately does a BIND TASK, and a COPY IDMS SUBSCHEMA-BINDS. Then I ready my areas that my subprogram needs. When I leave my subprogram, I do a FINISH and FINISH TASK. When I run it, I get an 0077 in my calling program as soon as I return from my subprogram and attempt another DML command, so I assume my FINISH TASK finished my calling program's run unit. I have experimented somewhat, but no luck. I would prefer to not have to extend my run unit to my subprogram if possible. Can anyone shed some light on what needs to be done for this to work successfully? I have written IDMS batch COBOL programs that use queues before, but they have always been stand-alone and not subprograms.> > Thanks in advance...
    _________________________________________________________________
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Writing to a queue from a COBOL subprogram
    "Joan,

    I have seen cases where the 0077 was the ""second error code"", while the
    real error code had been masked by the program's internal error-handling
    logic. In these cases, I sometimes found a more telling clue in the
    DC-log of the CV that the program ran against. Have a look there.

    Jim Ritterbusch

    Joan Hutchinson wrote:
    I have a batch COBOL program which calls another batch COBOL subprogram. I want this subprogram to write to a queue; it will also write a database record. But I am having bind issues. According to my understanding, in order for my subprogram to write to a queue, it must issue a BIND TASK and a FINISH TASK. I have my subprogram's PROTOCOL statement as DC-BATCH DEBUG, and COPY IDMS SUBSCHEMA-CONTROL in my working storage. My subprogram immediately does a BIND TASK, and a COPY IDMS SUBSCHEMA-BINDS. Then I ready my areas that my subprogram needs. When I leave my subprogram, I do a FINISH and FINISH TASK. When I run it, I get an 0077 in my calling program as soon as I return from my subprogram and attempt another DML command, so I assume my FINISH TASK finished my calling program's run unit. I have experimented somewhat, but no luck. I would prefer to not have to extend my run unit to my subprogram if possible. Can anyone shed some light on what needs to be done for this to work successfully? I have written IDMS batch COBOL programs that use queues before, but they have always been stand-alone and not subprograms.

    Thanks in advance...



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








    Normal

    Normal
    Writing to a queue from a COBOL subprogram
    "I have a batch COBOL program which calls another batch COBOL subprogram. I want this subprogram to write to a queue; it will also write a database record. But I am having bind issues. According to my understanding, in order for my subprogram to write to a queue, it must issue a BIND TASK and a FINISH TASK. I have my subprogram's PROTOCOL statement as DC-BATCH DEBUG, and COPY IDMS SUBSCHEMA-CONTROL in my working storage. My subprogram immediately does a BIND TASK, and a COPY IDMS SUBSCHEMA-BINDS. Then I ready my areas that my subprogram needs. When I leave my subprogram, I do a FINISH and FINISH TASK. When I run it, I get an 0077 in my calling program as soon as I return from my subprogram and attempt another DML command, so I assume my FINISH TASK finished my calling program's run unit. I have experimented somewhat, but no luck. I would prefer to not have to extend my run unit to my subprogram if possible. Can anyone shed some light on what needs to be done for this to work successfully? I have written IDMS batch COBOL programs that use queues before, but they have always been stand-alone and not subprograms.

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








    Normal

    Normal
    Re: Writing to a queue from a COBOL subprogram
    "I would remove the copy idms-subschema binds in the subprogram since you
    are not doing any database calls in that program. The main program is
    doing the database work and it should do the subschema binds and finish.
    Do not pass subschema-control between the programs. It reads like you
    have not, but I want to make sure.

    Lutz Petzold
    TDM UDB/IDMS Support
    (401) 782 2265 or (860) 636 0291
    Pager (860) 366 0865 or Telalert



    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
    Re: Writing to a queue from a COBOL subprogram
    "Thanks for all the comments and suggestions so far. Some clarification:

    - my subprogram does write a database record as well, and so I still need binds in my subprogram
    - I am currently not passing the subschema-control and extending the run unit to my subprogram
    - this subprogram will be called from many different programs, so I am leery to do anything that will commit the data in the calling programs. So if the FINISH TASK finishes all run-units, including the one from the calling program, does it also commit what was done in the calling program thus far?
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Writing to a queue from a COBOL subprogram
    "I would question that all the run-units are finished. The bind
    establishes a new run unit, but also a new task. The way IDMS sorts out
    mulitple run-units is through the subschema-control which points to the
    local request element which points to the ere. There should be three
    ere's created by your scenario, causing three tasks to be attached on
    the cv side. I am assuming that the calling program also has a protocol
    of dc-batch? The subschema-control has a different layout between batch
    and dc-batch. The dc-batch is longer, and different stuff is used in
    it. Does your subprogram have a bind and a bind-task statement? I would
    code it like that. To answer your question, I think the finish task
    statement should only finish the batch-dc requests like write printer
    and write queue. Then another finish for the database bind. But, as
    you can probably guess, I am only guessing. Run a PMRM active task
    display on the cv side while you're testing this program.



    Lutz Petzold
    TDM UDB/IDMS Support
    (401) 782 2265 or (860) 636 0291
    Pager (860) 366 0865 or Telalert



    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
    Re: Writing to a queue from a COBOL subprogram
    "Hi Joan

    When you issue a finish task it commits all run-units that are active
    under the task, that means the calling program as well as the subprogram
    that is why you are getting the 0077.

    For this to work successfully I think you need to have the subprogram as
    it's own task so when you issue the finish task or commit task that you
    only commit what the subprogram did and you can continue processing in
    the calling program from where you left off.

    If you run a journal report against these transaction id's you can
    determine when the transactions were committed or the transaction was
    finished.

    Dennis Robock
    Alberta Department of Energy


  • 2.  Re:Re: Writing to a queue from a COBOL subprogram

    Posted Feb 05, 2008 03:13 AM
    Thanks for all the comments and suggestions so far. Some clarification:

    - my subprogram does write a database record as well, and so I still
    need binds in my subprogram
    - I am currently not passing the subschema-control and extending the run
    unit to my subprogram
    - this subprogram will be called from many different programs, so I am
    leery to do anything that will commit the data in the calling programs.
    So if the FINISH TASK finishes all run-units, including the one from the
    calling program, does it also commit what was done in the calling
    program thus far?
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Writing to a queue from a COBOL subprogram
    "You didn't specify this, but my guess is that both programs are DC-BATCH.

    I believe you can own only one task, so there is no way for you to start a
    second task. It would be nice if that second BIND TASK would fail so we
    would know we are getting into trouble - but as far as I remember it does
    not, and unfortunately the FINISH TASK works, completing the task and all
    the run-units.

    To get around it you would need to do one of the following:
    - not execute a BIND TASK in the calling program - then it cannot be
    DC-BATCH.
    - not execute a BIND TASK in the called program.
    - in the called program check if a task is already established and if
    not issue the BIND TASK and the FINISH TASK.

    Only the first option would allow you to commit the queues for each call.

    Tommy Petersen




    Joan Hutchinson
    <JHUTCHIN@IPSCO.C
    OM> To
    Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
    Public Discussion cc
    Forum
    <IDMS-L@LISTSERV. Subject
    IUASSN.COM> Re: Writing to a queue from a COBOL
    subprogram

    02/05/2008 10:13
    AM


    Please respond to
    IDMS Public
    Discussion Forum
    <IDMS-L@LISTSERV.
    IUASSN.COM>







    Thanks for all the comments and suggestions so far. Some clarification:

    - my subprogram does write a database record as well, and so I still need
    binds in my subprogram
    - I am currently not passing the subschema-control and extending the run
    unit to my subprogram
    - this subprogram will be called from many different programs, so I am
    leery to do anything that will commit the data in the calling programs.
    So if the FINISH TASK finishes all run-units, including the one from the
    calling program, does it also commit what was done in the calling program
    thus far?
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Writing to a queue from a COBOL subprogram
    "Joan,

    Is there a reason you must use queue? I guess since this is causing so much
    trouble, could the application developers use another method to accomplish
    the same thing. Are these queue records being written in batch at night for
    processing during the day by another system? By this system? Are they
    triggering another process?

    Linda

    Linda J. Casey
    Managing Member
    Run Right, LLC


  • 3.  Re: Writing to a queue from a COBOL subprogram

    Posted Feb 05, 2008 03:13 AM
    Thanks for all the comments and suggestions so far. Some clarification:

    - my subprogram does write a database record as well, and so I still
    need binds in my subprogram
    - I am currently not passing the subschema-control and extending the run
    unit to my subprogram
    - this subprogram will be called from many different programs, so I am
    leery to do anything that will commit the data in the calling programs.
    So if the FINISH TASK finishes all run-units, including the one from the
    calling program, does it also commit what was done in the calling
    program thus far?
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Writing to a queue from a COBOL subprogram
    "Hi Dennis/Joan:

    In batch, I don't think you can start multiple tasks simultaneously. A
    'task' is started when a BIND TASK is issued, and you can have multiple
    BIND/FINISH run unit's under that 'task'.Any IDMS QUEUE activity is
    dependent on the 'task', not any individual run unit.

    So, perhaps one solution would be to BIND TASK in the caller, then BIND RUN
    UNIT as necessary and call the subroutine. The subroutine would BIND RUN
    UNIT, do it's database and queue work, and then COMMIT TASK. The 'commit'
    at this point should coordinate the 'recovery unit', which would include all
    work by the caller and subroutine up to this point. After a FINISH, the
    subroutine would return to the caller, who would ultimately terminate with a
    FINISH TASK. I suppose the COMMIT TASK could be done by either caller or
    callee.

    See IDMS Navigational DML for reference.

    Regards,

    Tom Schoenborn
    TA Schoenborn & Associates LLC




  • 4.  Re: Writing to a queue from a COBOL subprogram

    Posted Feb 05, 2008 08:52 AM
    You didn't specify this, but my guess is that both programs are DC-BATCH.

    I believe you can own only one task, so there is no way for you to start a
    second task. It would be nice if that second BIND TASK would fail so we
    would know we are getting into trouble - but as far as I remember it does
    not, and unfortunately the FINISH TASK works, completing the task and all
    the run-units.

    To get around it you would need to do one of the following:
    - not execute a BIND TASK in the calling program - then it cannot be
    DC-BATCH.
    - not execute a BIND TASK in the called program.
    - in the called program check if a task is already established and if
    not issue the BIND TASK and the FINISH TASK.

    Only the first option would allow you to commit the queues for each call.

    Tommy Petersen




    Joan Hutchinson
    <JHUTCHIN@IPSCO.C
    OM> To
    Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
    Public Discussion cc
    Forum
    <IDMS-L@LISTSERV. Subject
    IUASSN.COM> Re: Writing to a queue from a COBOL
    subprogram

    02/05/2008 10:13
    AM


    Please respond to
    IDMS Public
    Discussion Forum
    <IDMS-L@LISTSERV.
    IUASSN.COM>







    Thanks for all the comments and suggestions so far. Some clarification:

    - my subprogram does write a database record as well, and so I still need
    binds in my subprogram
    - I am currently not passing the subschema-control and extending the run
    unit to my subprogram
    - this subprogram will be called from many different programs, so I am
    leery to do anything that will commit the data in the calling programs.
    So if the FINISH TASK finishes all run-units, including the one from the
    calling program, does it also commit what was done in the calling program
    thus far?
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Writing to a queue from a COBOL subprogram
    "There have been many suggestions in this thread - one that I have not
    seen is the use of COMMIT ALL in the subprogram. COMMIT ALL only affects
    the one run unit - the ALL says to COMMIT both DB work AND Queue work.
    This command will NOT impact any other run units associated with the
    batch task. Note that there is also a COMMIT ALL TASK which would impact
    other run units.

    HTH - cheers - Gary

    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    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.


  • 5.  Re:Re: Writing to a queue from a COBOL subprogram

    Posted Feb 05, 2008 08:43 PM
    Thanks for all the comments and suggestions so far. Some clarification:

    - my subprogram does write a database record as well, and so I still
    need binds in my subprogram
    - I am currently not passing the subschema-control and extending the run
    unit to my subprogram
    - this subprogram will be called from many different programs, so I am
    leery to do anything that will commit the data in the calling programs.
    So if the FINISH TASK finishes all run-units, including the one from the
    calling program, does it also commit what was done in the calling
    program thus far?
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    ERROR DB006001in BCF doing UNLOCK SEGMENT
    "Hello All:

    I am trying to do an unlock segment in IDMSBCF release 15.0 SP6 and we get
    error DB006001 trying to unlock a segment with a special character in the
    name, for example the segment name is @CCS.

    We tried no quotes, single quotes and double quotes, nothing works.

    However, it does work when we do an individual area name with double quotes
    around the identifier? So we do have a get around but this segment has
    hundreds of areas.

    Has anyone else experienced this issue and know of an APAR?

    I searched support connect and found one issue for 16.0 only and it was not
    for the UNLOCK SEGMENT command.

    Thanks in advance for your support.

    Bill Allen
    (704) 641-0296

    @ccs



    **************Biggest Grammy Award surprises of all time on AOL Music.
    (http://music.aol.com/grammys/pictures/never-won-a-grammy?NCID=aolcmp003000000025
    48)
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: ERROR DB006001in BCF doing UNLOCK SEGMENT
    "Hello Chris:

    Thank you so much for your time and support, it is greatly appreciated.


  • 6.  Re: Writing to a queue from a COBOL subprogram

    Posted Feb 05, 2008 08:43 PM
    Thanks for all the comments and suggestions so far. Some clarification:

    - my subprogram does write a database record as well, and so I still
    need binds in my subprogram
    - I am currently not passing the subschema-control and extending the run
    unit to my subprogram
    - this subprogram will be called from many different programs, so I am
    leery to do anything that will commit the data in the calling programs.
    So if the FINISH TASK finishes all run-units, including the one from the
    calling program, does it also commit what was done in the calling
    program thus far?
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Local mode update and fastaccess
    "Hi everyone:



    We want to address a local mode update batch that runs for 20+ hours.



    We have Fastaccess 7.0 with IDMS 15.0 SP5.



    We want to implement Fastaccess into this local batch update job to get
    it to run faster.



    As always, you replies are appreciated in advance.



    J. Wayne Doneker

    BAE Systems

    York Pa.,

    717 225 8109

    John.Doneker@baesystems.com


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








    Normal

    Normal
    Re: Writing to a queue from a COBOL subprogram
    "Thanks to everyone for the many suggestions...I will do some experimenting based on them and see what works best in this situation.
    ""Cherlet, Gary (JTS)"" <Cherlet.Gary@SAUGOV.SA.GOV.AU> 2/5/2008 3:51 PM >>>
    There have been many suggestions in this thread - one that I have not
    seen is the use of COMMIT ALL in the subprogram. COMMIT ALL only affects
    the one run unit - the ALL says to COMMIT both DB work AND Queue work.
    This command will NOT impact any other run units associated with the
    batch task. Note that there is also a COMMIT ALL TASK which would impact
    other run units.

    HTH - cheers - Gary

    Gary Cherlet
    Justice Technology Services
    Department of Justice, SA Government
    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.


  • 7.  Re:Re: Writing to a queue from a COBOL subprogram

    Posted Feb 05, 2008 08:43 PM
    Thanks for all the comments and suggestions so far. Some clarification:

    - my subprogram does write a database record as well, and so I still
    need binds in my subprogram
    - I am currently not passing the subschema-control and extending the run
    unit to my subprogram
    - this subprogram will be called from many different programs, so I am
    leery to do anything that will commit the data in the calling programs.
    So if the FINISH TASK finishes all run-units, including the one from the
    calling program, does it also commit what was done in the calling
    program thus far?
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    QSAM or PREFETCH - pros and cons
    "Hi gang,

    Your posts on the topic ""Local mode update and fastaccess"" leads me to
    another question:

    When to use IDMSQSAM vs. when to use PREFETCH.

    I've used both in a limited way, and years ago, at another company,
    switched to PREFETCH because QSAM didn't seem to do much for me while
    PREFETCH did (after it came out.)

    Lutz's comment that QSAM only works on one file (the first file in a
    multi-file area?) kind of strikes me as why I wasn't overly impressed
    like most of you are with QSAM.

    In this shop, we have numerous huge areas (95% of all areas are 1
    rec/area) and a home-grown program that unloads records via full track
    reads. As a result, the only place QSAM is used is in UNLOAD/RELOAD
    jobs.

    Dick

    Richard Pierce
    (617) 973-8911
    richard.pierce@state.ma.us

    Remember, the answer to all questions is a reply, but a reply is not
    necessarily an answer.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Writing to a queue from a COBOL subprogram
    "I hate to disagree but the ALL in COMMIT ALL has nothing to do with
    Queues but relates to what happens to currencies
    From manual

    Currency: Use of the ALL option, as in COMMIT ALL, sets all currencies
    to
    null.

    The only way to commit queue work is with COMMIT TASK.

    Pete


  • 8.  Re:Re: Writing to a queue from a COBOL subprogram

    Posted Feb 05, 2008 08:43 PM
    Thanks for all the comments and suggestions so far. Some clarification:

    - my subprogram does write a database record as well, and so I still
    need binds in my subprogram
    - I am currently not passing the subschema-control and extending the run
    unit to my subprogram
    - this subprogram will be called from many different programs, so I am
    leery to do anything that will commit the data in the calling programs.
    So if the FINISH TASK finishes all run-units, including the one from the
    calling program, does it also commit what was done in the calling
    program thus far?
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Writing to a queue from a COBOL subprogram
    "Hi, I'm coming late to this ""party"" but I have a thought or two (I know
    that is dangerous!). Anyway, why couldn't the subprogram here be
    attached via an MVS attach? That would solve the separate run unit
    issue, right?

    Dan Miley
    Lockheed Martin


  • 9.  Re:Re: Writing to a queue from a COBOL subprogram

    Posted Feb 05, 2008 08:43 PM
    Thanks for all the comments and suggestions so far. Some clarification:

    - my subprogram does write a database record as well, and so I still
    need binds in my subprogram
    - I am currently not passing the subschema-control and extending the run
    unit to my subprogram
    - this subprogram will be called from many different programs, so I am
    leery to do anything that will commit the data in the calling programs.
    So if the FINISH TASK finishes all run-units, including the one from the
    calling program, does it also commit what was done in the calling
    program thus far?
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Local mode update and fastaccess
    "Great idea. Fastaccess works good. Start off with it autotuning
    itself, and study the statistics. Unfortunately, the stats are only
    produced on a successful completion. One technique I found very useful
    is to run trial and error with the parm changes I thought were worth
    trying. Using SDSF and excp's for a given time frame, like 10 minutes,
    I would check the results of the parm changes. Then cancel the job and
    make another parm change. This is practical for very large jobs that
    run for hours and letting it run to completion to get the stats is
    really time consuming. For the initial runs, the trial and error then
    cancel job is fine.

    The aim in using Fastacess is to reduce io, aka excps in sdsf speak. It
    works best with sequential access to pages, and worst with wildly random
    access to pages. It can run longer then before, if the random access is
    hopscotch and the buffers are very large.

    If it's only one file/area you're updating, the fastest by far is
    idmsqsam. Unfortunately it's engagement is tricky, and doesn't work
    with multiple files. But whipping through a single idms file, idmsqsam
    has no equal.

    Lutz Petzold
    TDM UDB/IDMS Support
    (401) 782 2265 or (860) 636 0291
    Pager (860) 366 0865 or Telalert



    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
    Re: Local mode update and fastaccess
    "well first - before you even start looking at ANY read-ahead tool, a
    few things to consider:

    1) how does the program navigate much/most of an area or areas? if so
    - how does it do it? through sets or area sweeps? are there lots of
    OBTAIN CALCs on lookup tables? - are the updates interspersed with
    the retreivals?

    i have been handed this problem several times

    if you can convert the navigation to a series of area sweeps (with
    appropriate selection criteria) and sort afterwards to mimic set sequence
    instead of OBTAIN CALCS on lookup tables- sweep the area - sort by
    CALC key - and use match logic against the data you already have
    (also sorted in lookup table CALC KEY sequence

    also - if you can put the updates into a separate program - or finish
    and re-ready the areas in update mode at the end of your program,
    this might help

    i will dig up some parms we use for local mode updates and pass them
    along .....








    This is Chris Hoelscher and I approved this email
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Local mode update and fastaccess
    "Lutz,

    Does IDMSQSAM have the same caveat, i.e. sequential access good, random
    access bad?

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








    Normal

    Normal
    Re: Local mode update and fastaccess
    "Yes, I would think IDMSQSAM has the same caveat. But, I would try it,
    because todays dasd is often raid devices with large caches with their
    own chips that determine whether to prefetch large amounts of data.
    Subsequent random IO requests may very well find the data already in the
    cache. IDMSQSAM has some super-efficient way of doing IO. There is more
    to it then meets the eye. Unfortunately I have never really persued it
    all the way through, but I was blown away by how much faster it is when
    I wrote a utility to update bdam files. In one case, what took IDMS 2
    days sequentially updating every page in the area through dml, QSAM did
    in 20 minutes using an assembler program and mvs qsam file io.

    When it comes to tuning, I am a big proponent of try it first, then look
    at the details for an explanation of how the magic happened. The world
    of dasd io is full of surprises, so is apps going after their data.

    Lutz Petzold
    TDM UDB/IDMS Support
    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
    Re: Local mode update and fastaccess
    "Hi John,

    We use Fast Access here extensively to speed up batch jobs. The time
    saved depends on the programs DML navigation but I can say I have tuned
    some jobs from 20 hours to 3 hours. Plus with FIOSTATS DD Fast Access
    will tell you have much your saving.

    Steve Harmeson


  • 10.  Re:Re: Writing to a queue from a COBOL subprogram

    Posted Feb 05, 2008 08:43 PM
    Thanks for all the comments and suggestions so far. Some clarification:

    - my subprogram does write a database record as well, and so I still
    need binds in my subprogram
    - I am currently not passing the subschema-control and extending the run
    unit to my subprogram
    - this subprogram will be called from many different programs, so I am
    leery to do anything that will commit the data in the calling programs.
    So if the FINISH TASK finishes all run-units, including the one from the
    calling program, does it also commit what was done in the calling
    program thus far?
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: QSAM or PREFETCH - pros and cons
    "As these comments indicate, not all IO is the same. Fastaccess and
    QSAM's fame to claim is that they do not do block io. Fastaccess does
    either track IO or cylinder IO. Meaning, one IO request and a whole
    cylinder's worth of data ends up in the buffer. Additionally,
    Fastaccess allows for large buffer allocations. One caveat though,
    these buffers are searched sequentially for data. That is not the most
    efficient. IDMS searches its buffers through an algorithm, resulting in
    less CPU. What kind of IO QSAM does I dont know, I just know it's so
    lightening fast, that it took me more time proving the program actually
    updated all the data then writing the thing in the first place.
    However, due to its limitations, I've never used QSAM for production
    batch jobs. Fastaccess I have, and the full cylinder read feature does
    save a ton of time. Searching through large buffers for data, only to
    find it isn't there and a full cylinder IO is required, burns CPU. And,
    full cylinder io does take more milliseconds (or are they down to
    nannoseconds now?) then one block io, so if your app only uses one page
    of the cylinder's worth of pages, your performance will actually
    decrease. Comparing Fastaccess performance to prefetch has always shown
    me, and the people that i worked with, that fastaccess is faster if
    applied judiciously. But reading the statistics, understanding the
    access path, and coming up with the right parms, can be a head trip. I
    happened to work with the unofficial guru of Fastacess at one time, and
    he made sure that every dba understood the product. It can get
    complicated, especially with indexes, and cross area sets and mixed mode
    (sequential and random) acess.

    The bottom line with Fastaccess is, the dba has to know what the dba is
    doing, or it can hurt.


    Lutz Petzold
    TDM UDB/IDMS Support
    (401) 782 2265 or (860) 636 0291
    Pager (860) 366 0865 or Telalert



    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
    Tool kit products
    "Does anyone use the following IDMS tool kit products and, if so, can you
    explain why they are better than the corresponding utilities and reports
    that are already bundled in with the IDMS base product?

    1) DB Analyzer
    2) DB Reorg
    3) Journal Analyzer
    4) Log Analyzer
    5) Task Analyzer
    6) Dictionary Query Facility

    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: QSAM or PREFETCH - pros and cons
    "We generally use PREFETCH for local mode retrieval jobs. I wrote an
    assembler program that attaches multiple sub-tasks (each doing PREFETCH)
    for each file in an area and it greatly improves thruput for area
    sweeps. If anyone wants more details on this technique, they may
    contact me directly at dan.l.miley@lmco.com.

    On backups, we use Hartman Canon's dump programs which do QSAM I/O.
    Hartman's programs are amazingly fast and efficient!

    Now, as to the original subject which started these threads, I believe
    that the person was initially inquiring about improving local mode
    update. In general, we have avoided local mode updates because of the
    problems with restart (we use my ""famous"" auto-restart/retry programs to
    restart without human intervention). But I think that the person said
    that the update run was taking 20 hours in local mode--man, that must be
    a lot of data OR the application program is exceedingly inefficient.
    Without the benefit of looking at the program, I would tend to believe
    that the application program could be tuned to improve performance.
    Perhaps it could be split into 5 concurrent runs divided by page ranges
    or CALC keys (obviously, in CV mode). Or the real culprit could be
    something as silly as reading a file multiple times instead of loading
    it to a table (yes, I've seen it done here), linking to non-reusable
    subprogram (forcing a load every time!), or a whole host of other
    equally moronic stunts that programmers do. Bottom line: look at the
    program first before thinking of exotic solutions.

    Dan Miley
    Lockheed Martin


  • 11.  Re: Writing to a queue from a COBOL subprogram

    Posted Feb 07, 2008 05:15 AM
    I hate to disagree but the ALL in COMMIT ALL has nothing to do with
    Queues but relates to what happens to currencies
    From manual

    Currency: Use of the ALL option, as in COMMIT ALL, sets all currencies
    to
    null.

    The only way to commit queue work is with COMMIT TASK.

    Pete


  • 12.  Re:Re: Writing to a queue from a COBOL subprogram

    Posted Feb 07, 2008 09:55 AM
    Joan --

    Gary's suggestion is a good one.
    Calling and called program are one task thread and two run-units
    (actually
    three run-units if you count queue activity in the called program)

    You mentioned that you don't want to do anything in the subprogram that
    COMMITS work in the calling program.
    That means you need to move all your COMMIT TASK and / or FINISH TASK
    work
    to the calling program.

    If you don't want to do that, then do a COMMIT ALL and then a FINISH in
    the
    subprogram (since you are doing DB work in the called program, too).

    I think doing the COMMIT ALL should be sufficient in your subprogram for
    the
    queue work.
    Queue work is actually done by a run-unit not even defined by your
    program
    anyways.
    Queue work is done by queue RHDCRUAL pre-allocated run-units which
    aren't
    really going to FINISH anyways.
    They are allocated at startup and idle all day long to handle queue
    work.
    If you have heavy queue activity on your system that uses all
    pre-allocated
    run-units, but needs one more for your task, an overflow RHDCRUAL is
    started
    and then finished free of charge.

    Thanks.
    Jon Gocher




  • 13.  Re: Writing to a queue from a COBOL subprogram

    Posted Feb 07, 2008 09:55 AM
    Joan --

    Gary's suggestion is a good one.
    Calling and called program are one task thread and two run-units
    (actually
    three run-units if you count queue activity in the called program)

    You mentioned that you don't want to do anything in the subprogram that
    COMMITS work in the calling program.
    That means you need to move all your COMMIT TASK and / or FINISH TASK
    work
    to the calling program.

    If you don't want to do that, then do a COMMIT ALL and then a FINISH in
    the
    subprogram (since you are doing DB work in the called program, too).

    I think doing the COMMIT ALL should be sufficient in your subprogram for
    the
    queue work.
    Queue work is actually done by a run-unit not even defined by your
    program
    anyways.
    Queue work is done by queue RHDCRUAL pre-allocated run-units which
    aren't
    really going to FINISH anyways.
    They are allocated at startup and idle all day long to handle queue
    work.
    If you have heavy queue activity on your system that uses all
    pre-allocated
    run-units, but needs one more for your task, an overflow RHDCRUAL is
    started
    and then finished free of charge.

    Thanks.
    Jon Gocher




  • 14.  Re:Re: Writing to a queue from a COBOL subprogram

    Posted Feb 07, 2008 09:55 AM
    Joan --

    Gary's suggestion is a good one.
    Calling and called program are one task thread and two run-units
    (actually
    three run-units if you count queue activity in the called program)

    You mentioned that you don't want to do anything in the subprogram that
    COMMITS work in the calling program.
    That means you need to move all your COMMIT TASK and / or FINISH TASK
    work
    to the calling program.

    If you don't want to do that, then do a COMMIT ALL and then a FINISH in
    the
    subprogram (since you are doing DB work in the called program, too).

    I think doing the COMMIT ALL should be sufficient in your subprogram for
    the
    queue work.
    Queue work is actually done by a run-unit not even defined by your
    program
    anyways.
    Queue work is done by queue RHDCRUAL pre-allocated run-units which
    aren't
    really going to FINISH anyways.
    They are allocated at startup and idle all day long to handle queue
    work.
    If you have heavy queue activity on your system that uses all
    pre-allocated
    run-units, but needs one more for your task, an overflow RHDCRUAL is
    started
    and then finished free of charge.

    Thanks.
    Jon Gocher




  • 15.  Re: Writing to a queue from a COBOL subprogram

    Posted Feb 07, 2008 08:45 PM
    I hate to disagree but the ALL in COMMIT ALL has nothing to do with
    Queues but relates to what happens to currencies
    From manual

    Currency: Use of the ALL option, as in COMMIT ALL, sets all currencies
    to
    null.

    The only way to commit queue work is with COMMIT TASK.

    Pete