ca.portal.admin

Re:Interesting (if somewhat scary) Site

Discussion created by ca.portal.admin on Feb 13, 2009
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

Outcomes