IDMS

  • 1.  Problem in cobol converting dbkey

    Posted Apr 07, 2005 01:16 PM
    Hi everyone:

    We have an Ads prog that work with this example:

    COMPUTE DBKEY-1 = (1047614 * 256) + 1.
    OBTAIN TELEFONO DB-KEY IS DBKEY-1.

    The decimal value of the dbkey is 268189185. The DBKEY-1 field is s9(8) comp
    sync.

    If we try to do the same thing in cobol, we have the problem that we can
    never fit the decimal value in the s9(8) comp sync, all the time its trunc
    the 2 in the left in the decimal field. The only way that we can store this
    decimal number in a comp field in cobol its defining it s9(9) comp sync, but
    we can´t use it like a dbkey.

    Any ideas that how we can proceed in cobol to do that???

    TIA.

    Javier S.

    _________________________________________________________________
    Don’t just search. Find. Check out the new MSN Search!
    http://search.msn.click-url.com/go/onm00200636ave/direct/01/

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








    Normal

    Normal
    Re: Securing IDMS dictionaries
    "from what i remember

    10.2 type security only secure the access (ie what you could do in idd) - i
    do not think it would have had any bearing on a user program that accessed
    the dictionary as a database - i think the DB security would be used to
    secure the dict database as you would any other database - and then
    schema/subschema security like any application subschema security.

    chris

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








    Normal

    Normal
    Re: Problem in cobol converting dbkey
    "Javier,
    for cobol programs you can turn on the compiler option TRUNC(BIN) this wil avoid truncation even
    if you use s9(8) comp fields.
    If you have a cobol compiler like COBOL for MVS or Enterprise cobol and
    you don't want to use the TRUNC(BIN) option because of cpu overhead, you can use the s9(8) comp-5 definition.

    gr

    Peter


  • 2.  Re:Problem in cobol converting dbkey

    Posted Apr 07, 2005 01:16 PM
    Hi everyone:

    We have an Ads prog that work with this example:

    COMPUTE DBKEY-1 = (1047614 * 256) + 1.
    OBTAIN TELEFONO DB-KEY IS DBKEY-1.

    The decimal value of the dbkey is 268189185. The DBKEY-1 field is s9(8)
    comp
    sync.

    If we try to do the same thing in cobol, we have the problem that we can
    never fit the decimal value in the s9(8) comp sync, all the time its trunc
    the 2 in the left in the decimal field. The only way that we can store this
    decimal number in a comp field in cobol its defining it s9(9) comp sync,
    but
    we can´t use it like a dbkey.

    Any ideas that how we can proceed in cobol to do that???

    TIA.

    Javier S.

    _________________________________________________________________
    Don’t just search. Find. Check out the new MSN Search!
    http://search.msn.click-url.com/go/onm00200636ave/direct/01/
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    ADS Procedure for IDMS Server / SQL Option
    "Has anyone got an example of an ADS procedure which extracts
    an owner and associated member records to create a table on
    the client? We are just in the process of installing R16.0
    SP1 with IDMS Server and SQL Option and we have views and
    table procedures working but I'm having a hard time finding
    documentation on ADS procedures. Any assistance will be
    greatly appreciated.

    Margaret

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








    Normal

    Normal
    Securing IDMS dictionaries
    "Kay

    I think that a dictionary is secure when only authorised users are able to
    read/update it.

    We too secure resource type DB internally, and grant individual
    users/groups access to selected dictionaries by granting them EXECUTE on a
    Resource Category that includes:
    RUNUNIT <dictname>.*
    i.e. they can use any subschema and any program to do so.
    When greater granularity is necessary - for example, only to run dictionary
    reports against a dictionary, but not use a compiler against it, the
    category would include:
    RUNUNIT <dictname>.IDMSNWKA.IDMSCULP
    RUNUNIT <dictname>.IDMSNWKA.CULP*
    Thus we secure the dictionary against unauthorised use of CULPRIT, batch
    compilers and evil non-CA batch progams, supplementing restrictions on use
    of the task codes that invoke the online compilers.


    Disclosure of Material Facts
    Every Proposer or Insured / Reinsured when seeking new insurance / reinsurance or renewing an existing Policy must disclose any information which might influence the Insurer / Reinsurer in deciding whether or not to accept the risk, what the terms should be, or what premiums to charge. Failure to do so may render the insurance / reinsurance voidable from inception and enable the Insurer / Reinsurer to repudiate liability.

    This email, together with any attachments, is for the exclusive and confidential use of the addressee(s) and may contain legally privileged information. Any other distribution, use or reproduction without the sender's prior consent is unauthorised and strictly prohibited. If you have received this message in error, please notify the sender by email immediately and delete the message from your computer without making any copies. While attachments are virus checked, Aon Limited does not accept any liability in respect of any virus which is not detected.

    Aon Limited
    Company Number: 210725
    Registered Address: 8 Devonshire Square, London, EC2M 4PL

    Aon Limited is authorised and regulated by the Financial Services Authority in respect of insurance mediation activities only

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








    Normal

    Normal
    user information and database information for audit purpose
    "Hi Everybody:
    We have a client that have a audit requirenment, they want a report that
    contains information about what a user did at database level. The user idea
    its check witch users are using the databases and specifically some
    sensitive information. I know that there is some information in the
    journals, but I could not find any link betwen the user and the database
    information accessed or modified or erased and of course, the presentation
    of the information for a user, not in a complicated way like hex and not
    clear. I want to know if somebody in the idms word is using any tool for
    audit purposes that helpus with this requerinment.

    TIA.

    Javier S.

    _________________________________________________________________
    Express yourself instantly with MSN Messenger! Download today it's FREE!
    http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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








    Normal

    Normal
    Re: user information and database information for audit purpose
    "Javier ,

    CA-IDMS Journal Analyzer can produce Program reports in ' Subschema View
    ' which are better suited to non-technical users .

    Bob


  • 3.  Re:Problem in cobol converting dbkey

    Posted Apr 07, 2005 01:16 PM
    Hi everyone:

    We have an Ads prog that work with this example:

    COMPUTE DBKEY-1 = (1047614 * 256) + 1.
    OBTAIN TELEFONO DB-KEY IS DBKEY-1.

    The decimal value of the dbkey is 268189185. The DBKEY-1 field is s9(8) comp
    sync.

    If we try to do the same thing in cobol, we have the problem that we can
    never fit the decimal value in the s9(8) comp sync, all the time its trunc
    the 2 in the left in the decimal field. The only way that we can store this
    decimal number in a comp field in cobol its defining it s9(9) comp sync, but
    we can´t use it like a dbkey.

    Any ideas that how we can proceed in cobol to do that???

    TIA.

    Javier S.

    _________________________________________________________________
    Don't just search. Find. Check out the new MSN Search!
    http://search.msn.click-url.com/go/onm00200636ave/direct/01/

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








    Normal

    Normal
    Re: Problem in cobol converting dbkey
    "



    You should also use the Cobol compiler option TRUNC(BIN) to avoid the
    problem of the 9th digit being truncated.
    Gordon




    Art
    <art@IDMSDBA.COM>
    Sent by: IDMS To
    Public Discussion IDMS-L@LISTSERV.IUASSN.COM
    Forum cc
    <IDMS-L@LISTSERV.
    IUASSN.COM> Subject
    Re: Problem in cobol converting
    dbkey
    07/04/2005 11:38
    PM


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






    Hi Javier,

    The safest way (for any possible page number) is this, but not the
    only way.

    01 DBKEY-STUFF.
    05 WDBKEY-1.
    10 FILLER PIC X(01).
    10 WDBKEY-1-3 PIC X(03).
    05 PAGE-NUMBER REDEFINES WDBKEY-1 PIC S9(8) COMP.
    05 DBKEY-1 PIC S9(8) COMP SYNC.
    05 FILLER REDEFINES DBKEY-1.
    10 DBKEY-1-PAGE PIC X(03).
    10 FILLER PIC X(01).



    MOVE +1 TO DBKEY-1.
    MOVE 1047614 TO PAGE-NUMBER.
    MOVE WDBKEY-1-3 TO DBKEY-1-PAGE.
    OBTAIN TELEFONO DB-KEY IS DBKEY-1.

    Art W.