IDMS

Re:Interesting (if somewhat scary) Site

  • 1.  Re:Interesting (if somewhat scary) Site

    Posted Feb 13, 2009 10:12 AM
    While googling around for answers to our upgrade issues I came
    across this site. I don't know which is scarier - the
    questions being asked or the advice being given by the ""experts"".

    http://www.ibmmainframes.com/forum-15.html

    Jim Irwin
    Database Technical Support
    non impediti ratione congitatonis
    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: [IDMSVENDOR-L] Interesting (if somewhat scary) Site
    "This site is NOT a joke. This site has existed for several years, and our
    ""offshore"" compatriots use it quite often. If only management at some of the
    firms thinking about outsourcing would look at the content....

    On Fri, Feb 13, 2009 at 5:33 PM, Chris Hoelscher <choelscher@humana.com>wrote:
    Assuming this site is not a (intended) joke, i really have to wonder - at
    least 1/2 of the questions posed could be answered by (dare i say) reading
    the friendly manuals - i think most of us here would do so before
    posting, but i must ask - do these folks not have access to IDMS manuals?
    do they simpply choose to use that kind of forum rathen that RTM? I have
    seen other lists (DB2-L for one) where a poster would get skewered for
    asking some ot the questions posted on this website..... are the
    individuals asking these kinds of questions running the same individuals
    writing and maintaining the code that runs our companys' businesses ?????
    <yikes>



    The information transmitted is intended only for the person or entity to
    which it is addressed and may contain CONFIDENTIAL material. If you receive
    this material/information in error, please contact the sender and delete or
    destroy the material/information.
    --
    Thanx,
    Jerry Roberson
    781-395-1485 (home)
    774-289-6754 (cell)

    Truth is generally the best vindication against slander.
    - Abraham Lincoln
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: Interesting (if somewhat scary) Site
    "This site is NOT a joke. This site has existed for several years, and our
    ""offshore"" compatriots use it quite often. If only management at some of the
    firms thinking about outsourcing would look at the content....

    On Fri, Feb 13, 2009 at 5:33 PM, Chris Hoelscher <choelscher@humana.com>wrote:
    Assuming this site is not a (intended) joke, i really have to wonder - at
    least 1/2 of the questions posed could be answered by (dare i say) reading
    the friendly manuals - i think most of us here would do so before
    posting, but i must ask - do these folks not have access to IDMS manuals?
    do they simpply choose to use that kind of forum rathen that RTM? I have
    seen other lists (DB2-L for one) where a poster would get skewered for
    asking some ot the questions posted on this website..... are the
    individuals asking these kinds of questions running the same individuals
    writing and maintaining the code that runs our companys' businesses ?????
    <yikes>



    The information transmitted is intended only for the person or entity to
    which it is addressed and may contain CONFIDENTIAL material. If you receive
    this material/information in error, please contact the sender and delete or
    destroy the material/information.
    --
    Thanx,
    Jerry Roberson
    781-395-1485 (home)
    774-289-6754 (cell)

    Truth is generally the best vindication against slander.
    - Abraham Lincoln
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: IDMS-L Digest - 14 Feb 2009 to 15 Feb 2009 (#2009-24)
    "--a66802eb-b328-4a6a-89cd-02f3ac5aa7d9
    Content-Type: text/plain; charset=""Windows-1252""
    Content-Transfer-Encoding: quoted-printable


    Jerry=2C that 007 in your handle is a lucky number? As a responsible perso=
    n one would have to wonder why someone who doesn't have accesss to a site's=
    dmlo=2C ads=2C olq=2C cobol=2C etc. is asking how to get access to data fr=
    om a database. It seems they dont have the authority to look. Or they ar=
    e have 0 IDMS and mainframe experience=2C trying their luck with bogus cred=
    entials. I think every one in this newsgroup has an implicit responsibilit=
    y not to aid and abet the anauthorirzed access of data. And quite honestly=
    I got to wonder about a dba who uses 007 in his handle. That is not case=
    dispersions on the aforementioned newsgroup. I've never heard of them=2C =
    northeir conritbutors.






    _________________________________________________________________
    Windows Live=99: E-mail. Chat. Share. Get more ways to connect.=20
    http://windowslive.com/explore?ocid=3DTXT_TAGLM_WL_t2_allup_explore_022009=

    a66802eb-b328-4a6a-89cd-02f3ac5aa7d9
    Content-Type: text/plain; charset=""ISO-8859-1""
    Content-Transfer-Encoding: 7bit

    This site is NOT a joke. This site has existed for several years, and our
    ""offshore"" compatriots use it quite often. If only management at some of the
    firms thinking about outsourcing would look at the content....

    On Fri, Feb 13, 2009 at 5:33 PM, Chris Hoelscher <choelscher@humana.com>wrote:
    Assuming this site is not a (intended) joke, i really have to wonder - at
    least 1/2 of the questions posed could be answered by (dare i say) reading
    the friendly manuals - i think most of us here would do so before
    posting, but i must ask - do these folks not have access to IDMS manuals?
    do they simpply choose to use that kind of forum rathen that RTM? I have
    seen other lists (DB2-L for one) where a poster would get skewered for
    asking some ot the questions posted on this website..... are the
    individuals asking these kinds of questions running the same individuals
    writing and maintaining the code that runs our companys' businesses ?????
    <yikes>



    The information transmitted is intended only for the person or entity to
    which it is addressed and may contain CONFIDENTIAL material. If you receive
    this material/information in error, please contact the sender and delete or
    destroy the material/information.
    --
    Thanx,
    Jerry Roberson
    781-395-1485 (home)
    774-289-6754 (cell)

    Truth is generally the best vindication against slander.
    - Abraham Lincoln

    a66802eb-b328-4a6a-89cd-02f3ac5aa7d9--
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: IDMS-L Digest - 14 Feb 2009 to 15 Feb 2009 (#2009-24)
    "
    Jerry, that 007 in your handle is a lucky number? As a responsible person one would have to wonder why someone who doesn't have accesss to a site's dmlo, ads, olq, cobol, etc. is asking how to get access to data from a database. It seems they dont have the authority to look. Or they are have 0 IDMS and mainframe experience, trying their luck with bogus credentials. I think every one in this newsgroup has an implicit responsibility not to aid and abet the anauthorirzed access of data. And quite honestly I got to wonder about a dba who uses 007 in his handle. That is not case dispersions on the aforementioned newsgroup. I've never heard of them, northeir conritbutors.






    _________________________________________________________________
    Windows Live™: E-mail. Chat. Share. Get more ways to connect.
    http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_022009
    "
    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-L Digest - 14 Feb 2009 to 15 Feb 2009 (#2009-24)
    "The 007 is for my secondary email address, where all of my List-serv
    messages go, so I can keep them sorted, since I consider the List-serv to b=
    e
    a valuable resource.

    And, I don't condone the ibmmainframes site. I personally find it to be an
    affront to those of us who have worked with IDMS, some, like myself, since
    the 5.7 days. My comment was merely informational, attesting to the fact
    that it's been around for quite a while. I'm surprised more members here
    haven't heard of it, given the fact that IDMS was one of the first mainfram=
    e
    DBMSs to be outsourced en-masse. I'm sure that most of us here have been
    forced to not only work with the offshore people, but some, like myself,
    have been forced to train them to take our jobs.

    And, not everyone here is purely a DBA, either. I have worked primarily as
    an applications guy, with the majority of my DBA work on the applications
    side. Wonder about my handle all you will. It doesn't make me any less
    knowledgeable about IDMS than anyone else. Nor does it give anyone,
    including you, the right to make snide judgements about my character, just
    because of a 007 in my email address.

    Yes, if you look thru the aforementioned site, you can pretty well get the
    correct gist of the fact that most of the posters there DON'T have
    legitimate IDMS training or credentials. They don't understand currency, or
    database navigation, and probably don't have access to manuals, or even a
    quick reference. I don't think anything in my original post could be even
    mildly construed as condoning its' existence.

    On Sun, Feb 15, 2009 at 8:52 AM, lutz petzold <lutzpetzold@hotmail.com>wrot=
    e:

    >
    Jerry, that 007 in your handle is a lucky number? As a responsible perso=
    n
    one would have to wonder why someone who doesn't have accesss to a site's
    dmlo, ads, olq, cobol, etc. is asking how to get access to data from a
    database. It seems they dont have the authority to look. Or they are h=
    ave
    0 IDMS and mainframe experience, trying their luck with bogus credentials=
    .
    I think every one in this newsgroup has an implicit responsibility not t=
    o
    aid and abet the anauthorirzed access of data. And quite honestly I got =
    to
    wonder about a dba who uses 007 in his handle. That is not case
    dispersions on the aforementioned newsgroup. I've never heard of them,
    northeir conritbutors.






    _________________________________________________________________
    Windows Live=99: E-mail. Chat. Share. Get more ways to connect.
    http://windowslive.com/explore?ocid=3DTXT_TAGLM_WL_t2_allup_explore_02200=
    9




    --=20
    Thanx,
    Jerry Roberson
    781-395-1485 (home)
    774-289-6754 (cell)

    Truth is generally the best vindication against slander.
    - Abraham Lincoln
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: IDMS-L Digest - 14 Feb 2009 to 15 Feb 2009 (#2009-24)
    "The 007 is for my secondary email address, where all of my List-serv
    messages go, so I can keep them sorted, since I consider the List-serv to be
    a valuable resource.

    And, I don't condone the ibmmainframes site. I personally find it to be an
    affront to those of us who have worked with IDMS, some, like myself, since
    the 5.7 days. My comment was merely informational, attesting to the fact
    that it's been around for quite a while. I'm surprised more members here
    haven't heard of it, given the fact that IDMS was one of the first mainframe
    DBMSs to be outsourced en-masse. I'm sure that most of us here have been
    forced to not only work with the offshore people, but some, like myself,
    have been forced to train them to take our jobs.

    And, not everyone here is purely a DBA, either. I have worked primarily as
    an applications guy, with the majority of my DBA work on the applications
    side. Wonder about my handle all you will. It doesn't make me any less
    knowledgeable about IDMS than anyone else. Nor does it give anyone,
    including you, the right to make snide judgements about my character, just
    because of a 007 in my email address.

    Yes, if you look thru the aforementioned site, you can pretty well get the
    correct gist of the fact that most of the posters there DON'T have
    legitimate IDMS training or credentials. They don't understand currency, or
    database navigation, and probably don't have access to manuals, or even a
    quick reference. I don't think anything in my original post could be even
    mildly construed as condoning its' existence.

    On Sun, Feb 15, 2009 at 8:52 AM, lutz petzold <lutzpetzold@hotmail.com>wrote:

    >
    Jerry, that 007 in your handle is a lucky number? As a responsible person
    one would have to wonder why someone who doesn't have accesss to a site's
    dmlo, ads, olq, cobol, etc. is asking how to get access to data from a
    database. It seems they dont have the authority to look. Or they are have
    0 IDMS and mainframe experience, trying their luck with bogus credentials.
    I think every one in this newsgroup has an implicit responsibility not to
    aid and abet the anauthorirzed access of data. And quite honestly I got to
    wonder about a dba who uses 007 in his handle. That is not case
    dispersions on the aforementioned newsgroup. I've never heard of them,
    northeir conritbutors.






    _________________________________________________________________
    Windows Live™: E-mail. Chat. Share. Get more ways to connect.
    http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_022009
    --
    Thanx,
    Jerry Roberson
    781-395-1485 (home)
    774-289-6754 (cell)

    Truth is generally the best vindication against slander.
    - Abraham Lincoln
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    a slight change to John Siraco's IDMS + zIIP presentation
    "Good Day/Night all:

    Through testing (and actually reading the presentation), i stumbled upon
    something

    to exploit zIIP engines, the load library from which RHDCUXIT is loaded
    need not be authorized - this was at odds with the very helpful
    presentation I attended last year. I contacted John on this and he
    confirmed that the presentation was incorrect in this one area - he
    provided the following response: (he also agreed that I could pass this
    info on to you!)

    Exits are never entered in SRB mode. (They were at one point but that was
    changed ). It was decided not to require that exits or other
    user-supplied code must come from an authorized library. Relevant section
    from R17.0 SystemOperations, Section A.3.1 follows. It is copied from the
    CA Web site and is correct:

    A.3.1 zIIP Eligibility





    Most CA IDMS system code is eligible to run on a zIIP processor. However,
    user exits, database procedures, SQL-invoked routines, and application
    programs are not eligible to run on a zIIP processor. CA IDMS runtime
    processing ensures that a non-zIIP processor is selected to run
    non-eligible routines.

    To ensure that only eligible modules are selected to be run on a zIIP
    processor, some load modules must be loaded from one of the following
    secured locations:

    An authorized load library named in the STEPLIB concatenation or in the
    CDMSLIB concatenation. A library is authorized by adding it to the list of
    APF-authorized libraries in the appropriate PROGxx or IEAAPFxx member in
    SYS1.PARMLIB.

    The Link Pack Area, which includes the following modules:

    Dynamic LPA modules, as specified in PROGxx members in SYS1.PARMLIB

    Fixed LPA (FLPA) modules, as specified in IEAFIXxx members

    Modified LPA (MLPA) modules, as specified in IEALPAxx members

    Pageable LPA (PLPA) modules, loaded from libraries specified in LPALSTxx
    or PROGxx members

    A library in the linklist, as specified in PROGxx and LNKLST xx members.




    Note: For more information about authorized libraries, the LPA, and the
    linklist, see the IBM documentation.
    The specific rules for load module residence for zIIP processing are as
    follows:

    The load module that is executed to start the CA IDMS CV must reside in an
    authorized library in the STEPLIB concatenation or in a linklist library.
    This module is RHDCOMVS or the startup routine. For more information about
    the startup routine, see ""Step 1: Link Edit the Startup Routine"" in topic
    2.2.1.

    CA IDMS nucleus modules, including all line drivers and service drivers,
    must be loaded from an authorized load library in the CDMSLIB
    concatenation or from the LPA. The IBM Language Environment library
    (usually CEE.SCEERUN) must be authorized if it is included in the CDMSLIB
    concatenation. Alternatively, the following modules must reside in the
    LPA: CEEPIPI, CEEPLPKA, and CEEEV003.

    z/OS Callable Services library (SYS1.CSSLIB) must be in the linklist or it
    must be authorized and included in the STEPLIB concatenation.

    Use of the LPA or linklist for modules supplied during the CA IDMS
    installation is not generally recommended. Maintenance of such modules is
    difficult to manage and can lead to the inadvertent use of a module with
    one release of CA IDMS when the module was created for a different
    release.


    Modules that consist of non-executable code or code that is never eligible
    to run on a zIIP processor do not have to come from a secured location.
    Most modules which are supplied by a client or which are modifiable at a
    client site are in this category. This category includes the following:

    Client-written code, including application programs, CA ADS dialogs, table
    procedures, database procedures, and SQL routines

    Stand-alone load modules for DC exits WTOEXIT or WTOREXIT

    RHDCUXIT and stand-alone load modules for numbered exits

    DMCL load modules

    Database name tables

    Control blocks or tables that contain no executable code


    The IDMSDBIO load module can be modified at a client site by linking a DB
    user exit with it. It is a nucleus module containing executable code, and
    it must be loaded from a secured location for zIIP eligibility regardless
    of whether it is modified.

    Individual nucleus members in a load library do not have to be authorized
    and should not be linked with SETCODE AC(1). The startup module (RHDCOMVS
    or site-linked startup module) must be linked with SETCODE AC(1) if and
    only if the AUTHREQ parameter is specified for the CA IDMS SVC. For more
    information about the AUTHREQ parameter, see ""z/OS"" in topic 3.5.1.

    Note that not every load library in the CA IDMS startup STEPLIB and
    CDMSLIB needs to be authorized; only those libraries from which nucleus
    modules are loaded must be authorized. Appropriate startup error messages
    are provided to assist in this effort.

    To ensure that all nucleus modules are loaded from an authorized library,
    it is recommended that one of the following actions be taken:

    Authorize the SMP/E target load library created during the installation of
    CA IDMS.

    Maintain two separate but identical SMP/E target zones except that one
    contains an authorized load library and the other contains a
    non-authorized load library.

    Manually copy all modules in the SMP/E target load library to an
    authorized library to be used by CV startup. Recopy all modules in this
    library whenever maintenance is applied.


    When CA IDMS is used with a batch program, no modules are made
    zIIP-eligible. There are, however, considerations that arise from the use
    of an authorized load library. The z/OS operating system enforces certain
    rules for programs that are loaded from a set of authorized load
    libraries. In particular, any program that is linked with the RENT
    attribute cannot be modified at runtime. If this rule is violated, an S0C4
    program check occurs. Application programs linked with the CA IDMS
    interface module will be modified at runtime by CA. Therefore, the batch
    STEPLIB concatenation should contain at least one non-authorized load
    library, or such user programs should be linked without the RENT
    attribute.

    CA-supplied application programs (such as IDDSDDDL) are linked
    appropriately in the SMP/E target load library, so no special action is
    required for these programs.

    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    a slight change to John Siraco's IDMS + zIIP presentation
    "Good Day/Night all:

    Through testing (and actually reading the presentation), i stumbled upon
    something

    to exploit zIIP engines, the load library from which RHDCUXIT is loaded
    need not be authorized - this was at odds with the very helpful
    presentation I attended last year. I contacted John on this and he
    confirmed that the presentation was incorrect in this one area - he
    provided the following response: (he also agreed that I could pass this
    info on to you!)

    Exits are never entered in SRB mode. (They were at one point but that was
    changed ). It was decided not to require that exits or other
    user-supplied code must come from an authorized library. Relevant section
    from R17.0 SystemOperations, Section A.3.1 follows. It is copied from the
    CA Web site and is correct:

    A.3.1 zIIP Eligibility





    Most CA IDMS system code is eligible to run on a zIIP processor. However,
    user exits, database procedures, SQL-invoked routines, and application
    programs are not eligible to run on a zIIP processor. CA IDMS runtime
    processing ensures that a non-zIIP processor is selected to run
    non-eligible routines.

    To ensure that only eligible modules are selected to be run on a zIIP
    processor, some load modules must be loaded from one of the following
    secured locations:

    An authorized load library named in the STEPLIB concatenation or in the
    CDMSLIB concatenation. A library is authorized by adding it to the list of
    APF-authorized libraries in the appropriate PROGxx or IEAAPFxx member in
    SYS1.PARMLIB.

    The Link Pack Area, which includes the following modules:

    Dynamic LPA modules, as specified in PROGxx members in SYS1.PARMLIB

    Fixed LPA (FLPA) modules, as specified in IEAFIXxx members

    Modified LPA (MLPA) modules, as specified in IEALPAxx members

    Pageable LPA (PLPA) modules, loaded from libraries specified in LPALSTxx
    or PROGxx members

    A library in the linklist, as specified in PROGxx and LNKLST xx members.




    Note: For more information about authorized libraries, the LPA, and the
    linklist, see the IBM documentation.
    The specific rules for load module residence for zIIP processing are as
    follows:

    The load module that is executed to start the CA IDMS CV must reside in an
    authorized library in the STEPLIB concatenation or in a linklist library.
    This module is RHDCOMVS or the startup routine. For more information about
    the startup routine, see ""Step 1: Link Edit the Startup Routine"" in topic
    2.2.1.

    CA IDMS nucleus modules, including all line drivers and service drivers,
    must be loaded from an authorized load library in the CDMSLIB
    concatenation or from the LPA. The IBM Language Environment library
    (usually CEE.SCEERUN) must be authorized if it is included in the CDMSLIB
    concatenation. Alternatively, the following modules must reside in the
    LPA: CEEPIPI, CEEPLPKA, and CEEEV003.

    z/OS Callable Services library (SYS1.CSSLIB) must be in the linklist or it
    must be authorized and included in the STEPLIB concatenation.

    Use of the LPA or linklist for modules supplied during the CA IDMS
    installation is not generally recommended. Maintenance of such modules is
    difficult to manage and can lead to the inadvertent use of a module with
    one release of CA IDMS when the module was created for a different
    release.


    Modules that consist of non-executable code or code that is never eligible
    to run on a zIIP processor do not have to come from a secured location.
    Most modules which are supplied by a client or which are modifiable at a
    client site are in this category. This category includes the following:

    Client-written code, including application programs, CA ADS dialogs, table
    procedures, database procedures, and SQL routines

    Stand-alone load modules for DC exits WTOEXIT or WTOREXIT

    RHDCUXIT and stand-alone load modules for numbered exits

    DMCL load modules

    Database name tables

    Control blocks or tables that contain no executable code


    The IDMSDBIO load module can be modified at a client site by linking a DB
    user exit with it. It is a nucleus module containing executable code, and
    it must be loaded from a secured location for zIIP eligibility regardless
    of whether it is modified.

    Individual nucleus members in a load library do not have to be authorized
    and should not be linked with SETCODE AC(1). The startup module (RHDCOMVS
    or site-linked startup module) must be linked with SETCODE AC(1) if and
    only if the AUTHREQ parameter is specified for the CA IDMS SVC. For more
    information about the AUTHREQ parameter, see ""z/OS"" in topic 3.5.1.

    Note that not every load library in the CA IDMS startup STEPLIB and
    CDMSLIB needs to be authorized; only those libraries from which nucleus
    modules are loaded must be authorized. Appropriate startup error messages
    are provided to assist in this effort.

    To ensure that all nucleus modules are loaded from an authorized library,
    it is recommended that one of the following actions be taken:

    Authorize the SMP/E target load library created during the installation of
    CA IDMS.

    Maintain two separate but identical SMP/E target zones except that one
    contains an authorized load library and the other contains a
    non-authorized load library.

    Manually copy all modules in the SMP/E target load library to an
    authorized library to be used by CV startup. Recopy all modules in this
    library whenever maintenance is applied.


    When CA IDMS is used with a batch program, no modules are made
    zIIP-eligible. There are, however, considerations that arise from the use
    of an authorized load library. The z/OS operating system enforces certain
    rules for programs that are loaded from a set of authorized load
    libraries. In particular, any program that is linked with the RENT
    attribute cannot be modified at runtime. If this rule is violated, an S0C4
    program check occurs. Application programs linked with the CA IDMS
    interface module will be modified at runtime by CA. Therefore, the batch
    STEPLIB concatenation should contain at least one non-authorized load
    library, or such user programs should be linked without the RENT
    attribute.

    CA-supplied application programs (such as IDDSDDDL) are linked
    appropriately in the SMP/E target load library, so no special action is
    required for these programs.

    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    MS-SQL Server listerv?
    "A co-worker who supports SQL Server says that he has not been able to find =
    a good way of communicating with other SQL Server DBA's. He says that ther=
    e are lot of sites and bulletin boards, but that they are usually either no=
    t well-maintained, or have a secret agenda (peddling a product or pumping a=
    ds). Can anyone recommend a high-quality listserv (like this one) for SQL =
    Server?

    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 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    MS-SQL Server listerv?
    "A co-worker who supports SQL Server says that he has not been able to find a good way of communicating with other SQL Server DBA's. He says that there are lot of sites and bulletin boards, but that they are usually either not well-maintained, or have a secret agenda (peddling a product or pumping ads). Can anyone recommend a high-quality listserv (like this one) for SQL Server?

    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: MS-SQL Server listerv?
    "Kay,

    As an MS SQL DBA and part-time IDMS DBA I am a member of PASS
    http://www.sqlpass.org/ The membership is free and is heavily supported
    by MS. There is a list of Blogs that can be accessed from PASS but I
    also use http://sqlblog.com/ It is more blogs than listserv's in the MS
    Windows world.

    Chris