daily listing of idms-l
Chris Hoelscher
Number 9
In this issue:
please check out WWW.IUASSN.COM
----------------------------------------------------------------------
Date: Mon, 28 Jun 1999 10:05:28 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: please check out WWW.IUASSN.COM
Message-ID: <8525679E.0...@d54mta03.raleigh.ibm.com>
At your convenience, please check out http://www.iuassn.com . Much has
been
updated in the last two weeks: on-line versions of recent IUA
CONNECTIONS, an
on-line scrapbook of IUA1999: Rock&RollFORWARD, notification of PROPOSED
changes
to the IUA BYLAWS that could affect the way IUA operates, and a look at
the IUA
schedule of events at IMC/CAWORLD 1999.
Also, a list of approved for ballot (but not yet balloted) IDMS
technical
enhancement requests
Chris Hoelscher
Sophisticated Business Systems
Dallas Texas
On Assignment to IBM Global Services
Outsourcers for GE Capital Corporation
------------------------------
End of IDMS-L V1 #9
*******************
Chris Hoelscher
Number 10
In this issue:
Paul J. DiVasta/NAESCO is on vacation.
RE: Paul J. DiVasta/NAESCO is on vacation.
IDMS-L needs your help
RE: using LS39000
Re: Paul J. DiVasta/NAESCO is on vacation.
RE: Paul J. DiVasta/NAESCO is on vacation.
idms-l list policy change
----------------------------------------------------------------------
Date: Mon, 28 Jun 1999 14:02:26 -0400
From: "Paul J. DiVasta" <DIV...@naesco.com>
To: IDM...@iuassn.com
Subject: Paul J. DiVasta/NAESCO is on vacation.
Message-ID: <8525679E.0...@sbnotesmta2.naesco.com>
I will be out of the office from 06/28/99 until 07/05/99.
I will respond to your message when I return.
------------------------------
Date: Mon, 28 Jun 1999 10:55:18 -0400
From: "Brennan, Bernie" <bbre...@bostongas.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Paul J. DiVasta/NAESCO is on vacation.
Message-ID:
<6730F8076A17D211815F00A024FC62995C2CD3@exchange_riv1.bostongas.com>
Hey Paul, how did I get this message on 6/28/99 at 11:00am, if you sent
it
at 2:00pm?.
BACK TO THE FUTURE?????
Have a great vaca!!!!!!!
-----Original Message-----
From: Paul J. DiVasta [mailto:DIV...@naesco.com]
Sent: Monday, June 28, 1999 2:02 PM
To: IDM...@iuassn.com
Subject: Paul J. DiVasta/NAESCO is on vacation.
I will be out of the office from 06/28/99 until 07/05/99.
I will respond to your message when I return.
------------------------------
Date: Mon, 28 Jun 1999 11:58:38 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: IDMS-L needs your help
Message-ID: <8525679E.0...@d54mta03.raleigh.ibm.com>
I have a subscriber that is noticing that his emails from
idm...@iuassn.com are
missing subject lines and much of the body. Is anyone else experiencing
these
problems? if so, please send your information to idms-l...@iuassn.com
thanks,
Chris Hoelscher
------------------------------
Date: Mon, 28 Jun 1999 12:06:59 -0500
From: "Runtsch, Steve" <Steve....@ecolab.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: using LS39000
Message-ID: <E994F67723A4D211B00C000083623DF015E3DB@CORPHQ2>
We've used it since its inception in June, 1997. Release 14.0 version
is
LO40688 which is activated by "optional APAR bit" 176. (I just noticed
that
LI37449, which documents these bits, lists 176 as unused.)
We use it because we do not want our production CVs' logs to fill and
require offloading during the online day, which can cause users to
"hang"
for long periods of time. A couple of drawbacks are that the CV waits
while
the dump is taking place (users are not hung for nearly as long as when
the
log fills, though) and you probably dump much more than you need or
want.
Steve Runtsch
Ecolab Inc.
-----Original Message-----
From: Jackson, Jeff [mailto:Jeff.J...@fmr.com]
Sent: Thursday, June 24, 1999 3:42 PM
To: 'idm...@iuassn.com'; idm...@listserv.uga.edu
Subject: RE: using LS39000
We are in the process of rolling it out with the 9809 maintenance
rollout.
It works "as advertised", and the only drawback we've found is that we
can
no longer fill up the log (for offload submission testing, "formatting"
after an init, etc) by system snaps...
Jeff Jackson
Database Technical Support
Fidelity Investments
400 E. Las Colinas Blvd., MZ CC2T
Irving, TX 75039
* - 972-584-5276
*!- 972-584-5273 - DBMS Hot Line
* Pager: http://www.skytel.com/Paging/pageme.cgi?pin=4197550,1
*mailto:Jeff.J...@fmr.com
> -----Original Message-----
> From: hoel...@us.ibm.com [SMTP:hoel...@us.ibm.com]
> Sent: Thursday, June 24, 1999 11:14 AM
> To: idm...@listserv.uga.edu; idm...@iuassn.com
> Subject: using LS39000
>
>
>
>
> I made my client aware of LS39000 (forcing system snaps to generate
SVC
> dumps),
> and they WANT IT . Does anyone have experience with this APAR?
drawbacks?
>
> thanks,
> Chris Hoelscher
> Sophisticated Business Systems
> Dallas Texas
> On Assignment to IBM Global Services
> Outsourcers for GE Capital Cooporation
>
------------------------------
Date: Mon, 28 Jun 1999 20:42:38 -0300
From: "geraldo.martins" <geraldo...@originet.com.br>
To: <idm...@iuassn.com>
Subject: Re: Paul J. DiVasta/NAESCO is on vacation.
Message-ID: <002301bec1c0$33777160$def9f5c8@martger>
Because his clock was wrong, I think.
----- Original Message -----
From: Brennan, Bernie <bbre...@bostongas.com>
To: <idm...@iuassn.com>
Sent: Monday, June 28, 1999 11:55 AM
Subject: RE: Paul J. DiVasta/NAESCO is on vacation.
> Hey Paul, how did I get this message on 6/28/99 at 11:00am, if you
sent
it
> at 2:00pm?.
>
> BACK TO THE FUTURE?????
>
> Have a great vaca!!!!!!!
>
> -----Original Message-----
> From: Paul J. DiVasta [mailto:DIV...@naesco.com]
> Sent: Monday, June 28, 1999 2:02 PM
> To: IDM...@iuassn.com
> Subject: Paul J. DiVasta/NAESCO is on vacation.
>
>
>
> I will be out of the office from 06/28/99 until 07/05/99.
>
> I will respond to your message when I return.
>
>
------------------------------
Date: Mon, 28 Jun 1999 21:22:26 -0400
From: "Al Shuryan" <AlSh...@PROVIDE.NET>
To: <idm...@iuassn.com>
Subject: RE: Paul J. DiVasta/NAESCO is on vacation.
Message-ID: <000501bec1cd$d9315d20$9278cecf@alshuryan>
good for you.
My vacation is from 7/5-7
and then later this summer
I plan another week.
I'll let you know when and where.
-----Original Message-----
From: Paul J. DiVasta [mailto:DIV...@naesco.com]
Sent: Monday, June 28, 1999 2:02 PM
To: IDM...@iuassn.com
Subject: Paul J. DiVasta/NAESCO is on vacation.
I will be out of the office from 06/28/99 until 07/05/99.
I will respond to your message when I return.
------------------------------
Date: Mon, 28 Jun 1999 20:55:47 -0500
From: Chris Hoelscher <hoel...@flash.net>
To: idm...@iuassn.com
Subject: idms-l list policy change
Message-ID: <1999062902...@ares.flash.net>
It didn't take long ......
I have received requests from 4 subscribers to be removed from this list
because of the unprofessional and cluttered list traffic concerning a
vacation out-of-office autoreply. It is not acceptable that anyone
should
feel the list is of so little value to them because of spam that they
would
want to unsubscribe.
As long as the REPLY-TO is set to IDM...@IUASSN.COM, *any* out-of-office
message will sent to the list. Yes, this is bothersome to many, but many
subscribers to the "classic" IDMS-L expressed concern when THAT list
changed its REPLY-TO from IDM...@UGA.CC.UGA.EDU to the address of the
poster. With that concern in mind, I chose to "test the waters" and
allow
replies to be directed to the list by default.
However, today there were at least three replies (to the list) in reply
to
the auto-out-of-office reply. At least one was accidental, but the
carelessness <best case> or disregard for the list policies <worst case>
of
all three posts has convinced me that the time is not right for the
default
REPLY-TO directed to the list.
Effective immediately, we will revert to the policy of replies being
directed, by default, to the poster. Replied are certainly encouraged to
the list; but as a courtesy to those who do not wish to receive email
intended for someone other than themselves (or who do not wish to read
email from those who choose to post contrary to list policies *and*
common
sense), you will have to make the effort to change to TO from the poster
to
IDM...@IUASSN.COM if you indeed wish your posting to be distributed to
the
list.
This is not "cast in granite". This issue may be revisited in the
future,
but I do NOT want to administer a list that drives its subscribers away
.....
Chris Hoelscher
------------------------------
End of IDMS-L V1 #10
********************
Chris Hoelscher
Number 11
In this issue:
RE: Paul J. DiVasta/NAESCO is on vacation.
IDMS 14.0 Database Corruption
RE: idms-l list policy change
RE: idms-l list policy change
Re: IDMS 14.0 Database Corruption
Re: idms-l list policy change
RE:IDMS 14.0 Database Corruption
RE: idms-l list policy change
Re: idms-l list policy change
RE: idms-l list policy change
RE: idms-l list policy change
RE: idms-l list policy change
RE: idms-l list policy change
RE: idms-l list policy change
Re: idms-l list policy change
=?iso-8859-1?Q?R=E9f.[2]:_idms-l_list_policy_change?=
RE: idms-l list policy change
Fw: IDMS 14.0 Database Corruption
list clear this up
Re: list clear this up
idms-l policy
Re: list clear this up
RE: list clear this up
Re: list clear this up
Anyone running 14.0 or 14.1 with OS390 release 2.7 ??
RE: idms-l policy
RE: list clear this up
RES: idms-l list policy change
RE: list clear this up
CA-IDMS Article
Re: About ISPF Version 4
DIGESTive aids
RE: IDMS 14.0 Database Corruption
RE: IDMS 14.0 Database Corruption
Fwd: RE: idms-l list policy change
----------------------------------------------------------------------
Date: Tue, 29 Jun 1999 07:12:30 -0400
From: "Al A Shuryan" <shur...@meritorauto.com>
To: idm...@iuassn.com
Subject: RE: Paul J. DiVasta/NAESCO is on vacation.
Message-ID: <8525679F.0...@amerhub.meritorauto.com>
This was not intended as SPAM. It was a simple reply to an unknown email
about someone sharing his vacation plans with me.
And why all the goofy mail?
Why do the replies no longer to directly to the person anymore?
That's the change and mistaken problem, not SPAM.
"Al Shuryan" <AlSh...@PROVIDE.NET> on 06/28/99 09:22:26 PM
Please respond to idm...@iuassn.com
cc: (bcc: Al A Shuryan/Amer/Auto)
Subject: RE: Paul J. DiVasta/NAESCO is on vacation.
good for you.
My vacation is from 7/5-7
and then later this summer
I plan another week.
I'll let you know when and where.
-----Original Message-----
From: Paul J. DiVasta [mailto:DIV...@naesco.com]
Sent: Monday, June 28, 1999 2:02 PM
To: IDM...@iuassn.com
Subject: Paul J. DiVasta/NAESCO is on vacation.
I will be out of the office from 06/28/99 until 07/05/99.
I will respond to your message when I return.
------------------------------
Date: Tue, 29 Jun 1999 09:29:10 -0400
From: glenn....@ac.com
To: idm...@iuassn.com
Subject: IDMS 14.0 Database Corruption
Message-ID: <8625679F.0...@amrhm1101.ac.com>
We are running IDMS 14.0 GL9711 and have two very serious database
corruption
problems that have caused us to lose data (something that is new to us!)
and
wanted to know if anyone else had experienced similar problems?
We upgraded several production CVs from IDMS 10.2 to 14.0 in November
and
December 1998. We then added additional applications to one of the CVs
at the
end of February.
The multi-application CV the next business day started to get a message
like:
CURRENCY SAVE/RESTOREINTERNAL ERROR CODE IS 5
RUN-UNIT xxxxxxx NOT RECOVERED! NON-ZERO status returned from BRBK
The problem occurred when the system was very busy and it appeared that
there
were rollback related problems due to deadlocks.
We opened an issue with CA and upon further investigation we found that
two of
our databases had become corrupted. IDMS
had wrote records from one area into the wrong area and even into the
other
application database! It obviously appeared
to be an internal bug. We spent a considerable amount of diagnostic time
review
the journals, dumps, and logs but could
never isolate the problem (we have heard that a similar problem has
happened
somewhere else but not resolved?).
CA supplied us with a patch that traps all IDMS stores to confirm that
in fact
the record is going to the right page range. If
a problem is found it abends the transaction with a SOC1 and snaps a
dump of it
to the log (for diagnostic purposes).
The problem did not occur again after the trap was implemented and the
problem
was forgotten (the trap, according to
CA will not prevent the problem but it will prevent the corruption from
occurring).
In late May we implemented two more upgraded CVs over several weekends
and the
problem occurred again. The
problem this time presented itself as batch jobs getting 0371 error
messages but
corruption was confirmed. We again
lost data but it was limited to only one CV and one application (it was
a single
application CV). We did not have the trap
in these CVs since we didn't want to introduce a problem in these new
environments. We have subsequently added
the trap to all of our 14.0 update CVs. Again, no further problems have
been
found.
We believe that there is a bug somewhere but we cannot isolate it or
replicate
it for CA to fix. The only commonality
is that the CVs/mainframe was very busy and batch jobs abended (due to
time-outs
or deadlocks). It appeared that
it might be rollback related but the journals had the problem records
going to
the wrong place so that rollback
cannot be at fault since it only applies what is in the journal.
We are upgrading a large database in July and are concerned that we have
yet to
identify or resolve this
problem.
If you have seen this problem or a similar problem at your site please
respond
to me (I have been working
with IDMS since 1984 and have never seen a problem like this!). The
intent of
this question is to solicite responses
to our problem, not to raise flags about the product itself (since we
appear to
be the only ones affected). We use
IDMS/DC, ADS and Cobol on OS 390 (no CICS).
Glenn Scott
------------------------------
Date: Tue, 29 Jun 1999 07:16:16 -0700
From: "Jerry Fica" <jf...@worldnet.att.net>
To: "Chris Hoelscher" <hoel...@flash.net>,
<idm...@iuassn.com>
Subject: RE: idms-l list policy change
Message-ID: <000001bec239$f3a40650$b3a7f2c7@jerry-fica>
I am totally dismayed that anyone would be so offended by the extra
posts to
the list. They are certainly irritating but the delete key works
extremely
well on my mail client, so guess what I delete them and read the
important
stuff.
Just my two cents about restricting replies to the sender. I think there
is
a tremendous loss to the rest of the list when that happens, and I would
encourage the list to keep the replies going to the complete
list........
Jerry Fica
>>-----Original Message-----
>>From: Chris Hoelscher [mailto:hoel...@flash.net]
>>Sent: Monday, June 28, 1999 6:56 PM
>>To: idm...@iuassn.com
>>Subject: idms-l list policy change
>>
>>
------------------------------
Date: Tue, 29 Jun 1999 10:21:48 -0400
From: "Dudley, Brad" <brad....@fmr.com>
To: "'Jerry Fica'" <jf...@worldnet.att.net>,
Chris Hoelscher
<hoel...@flash.net>, idm...@iuassn.com
Subject: RE: idms-l list policy change
Message-ID:
<1512C23F3473D211A3A...@msgdal531nts.fmr.com>
I concur. Tell the whiners to deal with it!
-----Original Message-----
From: Jerry Fica [SMTP:jf...@worldnet.att.net]
Sent: Tuesday, June 29, 1999 9:16 AM
To: Chris Hoelscher; idm...@iuassn.com
Subject: RE: idms-l list policy change
I am totally dismayed that anyone would be so offended by the extra
posts to
the list. They are certainly irritating but the delete key works
extremely
well on my mail client, so guess what I delete them and read the
important
stuff.
Just my two cents about restricting replies to the sender. I think
there is
a tremendous loss to the rest of the list when that happens, and I
would
encourage the list to keep the replies going to the complete
list........
Jerry Fica
>>-----Original Message-----
>>From: Chris Hoelscher [mailto:hoel...@flash.net]
>>Sent: Monday, June 28, 1999 6:56 PM
>>To: idm...@iuassn.com
>>Subject: idms-l list policy change
>>
>>
------------------------------
Date: Tue, 29 Jun 1999 10:44:23 -0400
From: "David R Slocum" <drsl...@cmsenergy.com>
To: IDM...@IUASSN.COM
Subject: Re: IDMS 14.0 Database Corruption
Message-ID: <8525679F.0...@pr1lns45.cpco.com>
Hi Glenn,
We've been on IDMS 14.0 (9711) for over a year now. Some applications
we
migrated from IDMS 12.0 (9601), and others were migrated from IDMS 10.21
(S10214). We had numerous problems for the first month of production
use. One
of the problems had to do with corruption in an integrated index area.
We
rebuilt the index, only to have it become corrupted again within minutes
after
turning it back over to the clients. We ended up backing off temporary
APAR
TD67228, but it was never confirmed that this was the problem (we never
did
reapply the APAR). If you haven't already done so, I would recommend
applying
all published APARs for the 9711 gen level. This is what we did after
our first
month of production, and most of our problems went away. There are a
number of
APARs dealing with locking problems and multitasking. We now have all
APARs
applied up through LO49003 and things are quite stable here. In
addition to the
published APARs, we have the following temporary APARs applied: TD67193,
TD67195, TD67244, TD67274, TEAM153, TE1E094, and TFEF027. We also have
a zap
applied that circumvents a problem with multitasking and signon
retention
(usermod OZ28001 - see problem IDMSDC/1790). Hope this helps.
DISCLAIMER: The views expressed in this note aren't necessarily those
of the
company.
David R. Slocum
Consumers Energy
drsl...@cmsenergy.com
glenn....@ac.com on 06/29/99 09:29:10 AM
To: idm...@iuassn.com
cc: (bcc: David R Slocum/Pr/Consumers/CMS)
Subject: IDMS 14.0 Database Corruption
We are running IDMS 14.0 GL9711 and have two very serious database
corruption
problems that have caused us to lose data (something that is new to us!)
and
wanted to know if anyone else had experienced similar problems?
We upgraded several production CVs from IDMS 10.2 to 14.0 in November
and
December 1998. We then added additional applications to one of the CVs
at the
end of February.
The multi-application CV the next business day started to get a message
like:
CURRENCY SAVE/RESTOREINTERNAL ERROR CODE IS 5
RUN-UNIT xxxxxxx NOT RECOVERED! NON-ZERO status returned from BRBK
The problem occurred when the system was very busy and it appeared that
there
were rollback related problems due to deadlocks.
We opened an issue with CA and upon further investigation we found that
two of
our databases had become corrupted. IDMS
had wrote records from one area into the wrong area and even into the
other
application database! It obviously appeared
to be an internal bug. We spent a considerable amount of diagnostic time
review
the journals, dumps, and logs but could
never isolate the problem (we have heard that a similar problem has
happened
somewhere else but not resolved?).
CA supplied us with a patch that traps all IDMS stores to confirm that
in fact
the record is going to the right page range. If
a problem is found it abends the transaction with a SOC1 and snaps a
dump of it
to the log (for diagnostic purposes).
The problem did not occur again after the trap was implemented and the
problem
was forgotten (the trap, according to
CA will not prevent the problem but it will prevent the corruption from
occurring).
In late May we implemented two more upgraded CVs over several weekends
and the
problem occurred again. The
problem this time presented itself as batch jobs getting 0371 error
messages but
corruption was confirmed. We again
lost data but it was limited to only one CV and one application (it was
a single
application CV). We did not have the trap
in these CVs since we didn't want to introduce a problem in these new
environments. We have subsequently added
the trap to all of our 14.0 update CVs. Again, no further problems have
been
found.
We believe that there is a bug somewhere but we cannot isolate it or
replicate
it for CA to fix. The only commonality
is that the CVs/mainframe was very busy and batch jobs abended (due to
time-outs
or deadlocks). It appeared that
it might be rollback related but the journals had the problem records
going to
the wrong place so that rollback
cannot be at fault since it only applies what is in the journal.
We are upgrading a large database in July and are concerned that we have
yet to
identify or resolve this
problem.
If you have seen this problem or a similar problem at your site please
respond
to me (I have been working
with IDMS since 1984 and have never seen a problem like this!). The
intent of
this question is to solicite responses
to our problem, not to raise flags about the product itself (since we
appear to
be the only ones affected). We use
IDMS/DC, ADS and Cobol on OS 390 (no CICS).
Glenn Scott
------------------------------
Date: Tue, 29 Jun 1999 09:49:25 -0500
From: "Rick L. Garvin" <r...@ksu.edu>
To: IDM...@IUASSN.COM
Subject: Re: idms-l list policy change
Message-ID: <3778DCF5...@ksu.edu>
I totaly agree!!!!!!!!!!!!!!!!!!
Jerry Fica wrote:
>
> I am totally dismayed that anyone would be so offended by the extra
posts to
> the list. They are certainly irritating but the delete key works
extremely
> well on my mail client, so guess what I delete them and read the
important
> stuff.
>
> Just my two cents about restricting replies to the sender. I think
there is
> a tremendous loss to the rest of the list when that happens, and I
would
> encourage the list to keep the replies going to the complete
list........
>
> Jerry Fica
>
------------------------------
Date: Tue, 29 Jun 1999 09:44:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: glenn....@ac.com
Cc: idm...@iuassn.com
Subject: RE:IDMS 14.0 Database Corruption
Message-ID: <NY9bd52d...@bfi.com>
> CURRENCY SAVE/RESTORE INTERNAL ERROR CODE IS 5
> RUN-UNIT xxxxxxx NOT RECOVERED! NON-ZERO status returned from BRBK
This may not be the exact solution you need, but it is a related
solution to
the problem
message mentioned above. Ask CA to connect you to test Apar TD67279:
"RUN UNITS RECEIVE DC209002 MESSAGES FROM RECOVERY,
THEN RECOVER CORRECTLY. ARCHIVE THEN WAITS FOR
RECOVERY RUN UNITS TO COMPLETE. THE RECOVERY OF
THE RUN UNITS IS OK, BUT RECOVERY FLAGS IN THE JOURNALS
ARE LEFT ON. THIS CAUSES ARCHIVE TO WAIT. THE MESSAGE
TEXT FOR MESSAGE DC209002 IS CHANGED TO: 'TEMPORARY
DELAY IN ROLLBACK'."
John Rich
Browning-Ferris Industries
------------------------------
Date: Tue, 29 Jun 1999 16:18:10 +0100
From: "Shaw, Brock" <brock...@MBUK.Mercedes-Benz.com>
To: "IDMS-L (List) (E-mail)" <idm...@iuassn.com>
Subject: RE: idms-l list policy change
Message-ID: <81C700BB8A25D3119EE50010E360DAC6087A13@S184EXC3>
This message is in MIME format. Since your mail reader does not
understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BEC242.478FC6AC
Content-Type: text/plain;
charset="iso-8859-1"
I have to say that there is a problem whichever way the policy of
reply-to
is set.
If it is set to the list, then all communications which are sent as a
"reply" in the email system (outlook or whatever) go to the list - even
personal comments to other individuals.
If instead, reply goes to the person who sent the message (as the policy
now
makes it), then only that person receives the response, answer,
solution,
comment or whatever. This seriously impairs the list in doing what it
is
supposed to do - viz communicate!
Over the last few months of the UGA hosting, we got half the story or
less
in many cases because of the reply only going to the individual. It was
seen as a benefit to the new IUA hosting that we would be able to
generate a
bit more email, but see all the relevant mail.
In view of this, I think it is helpful to change the reply policy back
to
being the list, and for each person simply to remember that personal
comments and conversations are more appropriately made directly, not
through
the list. It is easy to change the reply to when we know we want to
make a
personal message. It is still not the end of the world if someone
forgets
once in a while, but the default should be to the list. But missing the
information could be important!
Best regards,
Brock.
Brock Shaw, DBA (ISD)
Mercedes Benz (UK), England
-----Original Message-----
From: Rick L. Garvin [mailto:r...@ksu.edu]
Sent: 29 June 1999 15:49
To: IDM...@IUASSN.COM
Subject: Re: idms-l list policy change
I totaly agree!!!!!!!!!!!!!!!!!!
Jerry Fica wrote:
>
> I am totally dismayed that anyone would be so offended by the extra
posts
to
> the list. They are certainly irritating but the delete key works
extremely
> well on my mail client, so guess what I delete them and read the
important
> stuff.
>
> Just my two cents about restricting replies to the sender. I think
there
is
> a tremendous loss to the rest of the list when that happens, and I
would
> encourage the list to keep the replies going to the complete
list........
>
> Jerry Fica
>
------_=_NextPart_001_01BEC242.478FC6AC
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: idms-l list policy change
I have to say that there is a problem whichever way = the policy of
reply-to is set.
If it is set to the list, then all communications = which are sent as a
"reply" in the email system (outlook or = whatever) go to the list -
even personal comments to other = individuals.
If instead, reply goes to the person who sent the = message (as the
policy now makes it), then only that person receives = the response,
answer, solution, comment or whatever. This = seriously impairs the
list in doing what it is supposed to do - viz = communicate!
Over the last few months of the UGA hosting, we got = half the story or
less in many cases because of the reply only going to = the individual.
It was seen as a benefit to the new IUA hosting = that we would be able
to generate a bit more email, but see all the = relevant mail.
In view of this, I think it is helpful to change the = reply policy back
to being the list, and for each person simply to = remember that
personal comments and conversations are more = appropriately made
directly, not through the list. It is easy to = change the reply to
when we know we want to make a personal = message. It is still not the
end of the world if someone forgets = once in a while, but the default
should be to the list. But = missing the information could be
important!
Best regards,
Brock.
Brock Shaw, DBA (ISD)
Mercedes Benz (UK), England
-----Original Message-----
From: Rick L. Garvin [mailto:r...@ksu.edu]
Sent: 29 June 1999 15:49
To: IDM...@IUASSN.COM
Subject: Re: idms-l list policy change
I totaly agree!!!!!!!!!!!!!!!!!!
Jerry Fica wrote:
>
> I am totally dismayed that anyone would be so = offended by the extra
posts to
> the list. They are certainly irritating but the = delete key works
extremely
> well on my mail client, so guess what I delete = them and read the
important
> stuff.
>
> Just my two cents about restricting replies to = the sender. I think
there is
> a tremendous loss to the rest of the list when = that happens, and I
would
> encourage the list to keep the replies going to = the complete
list........
>
> Jerry Fica
>
------_=_NextPart_001_01BEC242.478FC6AC--
------------------------------
Date: Tue, 29 Jun 1999 11:43:07 -0400
From: "Hugh Laderman" <hu...@laderman.com>
To: "IDMS-L" <idm...@iuassn.com>
Subject: Re: idms-l list policy change
Message-ID: <005401bec246$1bd9a420$4dc0a4d8@oemcomputer>
This is a multi-part message in MIME format.
------=_NextPart_000_0051_01BEC224.8E7FBD60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
More agreement with the many who have already stated this opinion.
Hugh Laderman
Laderman Associates
(215) 493-3460 Voice
(215) 493-0573 Fax
-----Original Message-----
From: Shaw, Brock <brock...@MBUK.Mercedes-Benz.com>
To: IDMS-L (List) (E-mail) <idm...@iuassn.com>
Date: Tuesday, June 29, 1999 11:21 AM
Subject: RE: idms-l list policy change
=20
=20
I have to say that there is a problem whichever way the policy of =
reply-to is set.=20
If it is set to the list, then all communications which are sent as
=
a "reply" in the email system (outlook or whatever) go to the list - =
even personal comments to other individuals.
If instead, reply goes to the person who sent the message (as the =
policy now makes it), then only that person receives the response, =
answer, solution, comment or whatever. This seriously impairs the list
=
in doing what it is supposed to do - viz communicate!
Over the last few months of the UGA hosting, we got half the story =
or less in many cases because of the reply only going to the individual.
=
It was seen as a benefit to the new IUA hosting that we would be able =
to generate a bit more email, but see all the relevant mail.
In view of this, I think it is helpful to change the reply policy =
back to being the list, and for each person simply to remember that =
personal comments and conversations are more appropriately made =
directly, not through the list. It is easy to change the reply to when
=
we know we want to make a personal message. It is still not the end of
=
the world if someone forgets once in a while, but the default should be
=
to the list. But missing the information could be important!
Best regards,=20
Brock.=20
Brock Shaw, DBA (ISD)=20
Mercedes Benz (UK), England=20
=20
=20
-----Original Message-----=20
From: Rick L. Garvin [mailto:r...@ksu.edu]=20
Sent: 29 June 1999 15:49=20
To: IDM...@IUASSN.COM=20
Subject: Re: idms-l list policy change=20
=20
=20
I totaly agree!!!!!!!!!!!!!!!!!!=20
Jerry Fica wrote:=20
>=20
> I am totally dismayed that anyone would be so offended by the =
extra posts to=20
> the list. They are certainly irritating but the delete key works =
extremely=20
> well on my mail client, so guess what I delete them and read the =
important=20
> stuff.=20
>=20
> Just my two cents about restricting replies to the sender. I think
=
there is=20
> a tremendous loss to the rest of the list when that happens, and I
=
would=20
> encourage the list to keep the replies going to the complete =
list........=20
>=20
> Jerry Fica=20
>=20
------=_NextPart_000_0051_01BEC224.8E7FBD60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
More agreement with the many who have already = stated=20 this opinion.
Hugh Laderman
Laderman = Associates
(215)=20 493-3460 Voice
(215) 493-0573 Fax
-----Original = Message-----
From:=20 Shaw, Brock <brock...@MBUK.Mercede= s-Benz.com>
To:=20 IDMS-L (List) (E-mail) <idm...@iuassn.com>
Date:=20 Tuesday, June 29, 1999 11:21 AM
Subject: RE: idms-l = list=20 policy change
I have to say that there is a problem whichever = way the=20 policy of
reply-to is set.
If it is set to the list, then all communications = which are=20 sent as
a "reply" in the email system (outlook or = whatever) go to=20 the list
- even personal comments to other individuals.
If instead, reply goes to the person who sent the = message=20 (as the
policy now makes it), then only that person receives the = response,=20
answer, solution, comment or whatever. This seriously impairs = the
list=20 in doing what it is supposed to do - viz communicate!
Over the last few months of the UGA hosting, we = got half the=20 story
or less in many cases because of the reply only going to the=20
individual. It was seen as a benefit to the new IUA hosting = that
we=20 would be able to generate a bit more email, but see all the
relevant = mail.
In view of this, I think it is helpful to change = the reply=20 policy
back to being the list, and for each person simply to = remember that=20
personal comments and conversations are more appropriately made =
directly,=20 not through the list. It is easy to change the reply to
when = we know=20 we want to make a personal message. It is still not
the end of = the=20 world if someone forgets once in a while, but the
default should be = to the=20 list. But missing the information could
be = important!
Best regards,
Brock.
Brock Shaw, DBA (ISD)
Mercedes Benz=20 (UK), England
-----Original Message-----
From:=20 Rick L. Garvin [mailto:r...@ksu.edu]=20
Sent: 29 June 1999 15:49
To:=20 IDM...@IUASSN.COM
Subject: Re: idms-l list = policy=20 change
I totaly agree!!!!!!!!!!!!!!!!!!
Jerry Fica wrote:
>=20
> I am totally dismayed that anyone = would be so=20 offended by the
extra posts to
> the = list. They=20 are certainly irritating but the delete key works
extremely =
> well on my mail client, so guess what I delete them = and read the=20
important
> stuff.
>=20
> Just my two cents about restricting = replies to=20 the sender. I
think there is
> a = tremendous loss=20 to the rest of the list when that happens, and
I would =
> encourage the list to keep the replies going to the = complete=20
list........
>
> Jerry=20 Fica
> =
------=_NextPart_000_0051_01BEC224.8E7FBD60--
------------------------------ Date: Tue, 29 Jun 1999 08:46:54 -0700
From: Mary Williams To: "'idm...@iuassn.com'" Subject: RE: idms-l list
policy change Message-ID:
<82E57D16D1D7D111A6B3...@mainex2.asu.edu> Just one more
note that says I agree with the majority of the consensus. -----Original
Message----- From: Hugh Laderman [mailto:hu...@laderman.com] Sent:
Tuesday, June 29, 1999 8:43 AM To: IDMS-L Subject: Re: idms-l list
policy change More agreement with the many who have already stated this
opinion. Hugh Laderman Laderman Associates (215) 493-3460 Voice (215)
493-0573 Fax -----Original Message----- From: Shaw, Brock <
brock...@MBUK.Mercedes-Benz.com > To: IDMS-L (List) (E-mail) <
idm...@iuassn.com > Date: Tuesday, June 29, 1999 11:21 AM Subject: RE:
idms-l list policy change I have to say that there is a problem
whichever way the policy of reply-to is set. If it is set to the list,
then all communications which are sent as a "reply" in the email system
(outlook or whatever) go to the list - even personal comments to other
individuals. If instead, reply goes to the person who sent the message
(as the policy now makes it), then only that person receives the
response, answer, solution, comment or whatever. This seriously impairs
the list in doing what it is supposed to do - viz communicate! Over the
last few months of the UGA hosting, we got half the story or less in
many cases because of the reply only going to the individual. It was
seen as a benefit to the new IUA hosting that we would be able to
generate a bit more email, but see all the relevant mail. In view of
this, I think it is helpful to change the reply policy back to being the
list, and for each person simply to remember that personal comments and
conversations are more appropriately made directly, not through the
list. It is easy to change the reply to when we know we want to make a
personal message. It is still not the end of the world if someone
forgets once in a while, but the default should be to the list. But
missing the information could be important! Best regards, Brock. Brock
Shaw, DBA (ISD) Mercedes Benz (UK), England -----Original Message-----
From: Rick L. Garvin [ mailto:r...@ksu.edu ] Sent: 29 June 1999 15:49 To:
IDM...@IUASSN.COM Subject: Re: idms-l list policy change I totaly
agree!!!!!!!!!!!!!!!!!! Jerry Fica wrote: > > I am totally dismayed that
anyone would be so offended by the extra posts to > the list. They are
certainly irritating but the delete key works extremely > well on my
mail client, so guess what I delete them and read the important > stuff.
> > Just my two cents about restricting replies to the sender. I think
there is > a tremendous loss to the rest of the list when that happens,
and I would > encourage the list to keep the replies going to the
complete list........ > > Jerry Fica > ------------------------------
Date: Tue, 29 Jun 1999 11:41:23 -0400 From: Bruce_...@fmso.navy.mil
(Bruce S Swist/FMSO/NAVSUP) To: "Dudley; Brad" Cc: "'Jerry Fica'" ,
Chris Hoelscher , idm...@iuassn.com Subject: RE: idms-l list policy
change Message-ID: <001BE4D...@navsup.navy.mil>
--IMA.Boundary.3521760390 Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part
Chris, etal I believe this all started because someone did not
understand the replies would again be sent to the entire list. I believe
it doesn't require a great deal of attention and various human behaviors
we are experiencing. I humbly request, now that we understand the
replies will be propagated back to all, we read the idms-l list rules,
follow them, eliminate the unnecessary bantering, and go on with a very
productive use of this list. Thanks for your time, A concerned member,
Take Care, Bruce From: "Dudley; Brad" AT internet-emh2 on 06/29/99 10:21
AM To: "'Jerry Fica'" AT internet-emh2@ccnavsup, Chris Hoelscher AT
internet-emh2@ccnavsup, idm...@iuassn.com AT internet-emh2@ccnavsup cc:
(bcc: Bruce S Swist/FMSO/NAVSUP) Subject: RE: idms-l list policy change
--IMA.Boundary.3521760390 Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part I
concur. Tell the whiners to deal with it! -----Original Message-----
From: Jerry Fica [SMTP:jf...@worldnet.att.net] Sent: Tuesday, June 29,
1999 9:16 AM To: Chris Hoelscher; idm...@iuassn.com Subject: RE: idms-l
list policy change I am totally dismayed that anyone would be so
offended by the extra posts to the list. They are certainly irritating
but the delete key works extremely well on my mail client, so guess what
I delete them and read the important stuff. Just my two cents about
restricting replies to the sender. I think there is a tremendous loss to
the rest of the list when that happens, and I would encourage the list
to keep the replies going to the complete list........ Jerry Fica
>>-----Original Message----- >>From: Chris Hoelscher
[mailto:hoel...@flash.net] >>Sent: Monday, June 28, 1999 6:56 PM >>To:
idm...@iuassn.com >>Subject: idms-l list policy change >> >> >>It didn't
take long ...... >> >>I have received requests from 4 subscribers to be
removed from this list >>because of the unprofessional and cluttered
list traffic concerning a >>vacation out-of-office autoreply. It is not
acceptable that anyone should >>feel the list is of so little value to
them because of spam that >>they would >>want to unsubscribe. >> >>As
long as the REPLY-TO is set to IDM...@IUASSN.COM, *any* out-of-office
>>message will sent to the list. Yes, this is bothersome to many, but
many >>subscribers to the "classic" IDMS-L expressed concern when THAT
list >>changed its REPLY-TO from IDM...@UGA.CC.UGA.EDU to the address of
the >>poster. With that concern in mind, I chose to "test the waters"
and allow >>replies to be directed to the list by default. >> >>However,
today there were at least three replies (to the list) in reply to >>the
auto-out-of-office reply. At least one was accidental, but the
>>carelessness or disregard for the list policies >> of >>all three
posts has convinced me that the time is not right for >>the default
>>REPLY-TO directed to the list. >> >>Effective immediately, we will
revert to the policy of replies being >>directed, by default, to the
poster. Replied are certainly encouraged to >>the list; but as a
courtesy to those who do not wish to receive email >>intended for
someone other than themselves (or who do not wish to read >>email from
those who choose to post contrary to list policies *and* common
>>sense), you will have to make the effort to change to TO from the
>>poster to >>IDM...@IUASSN.COM if you indeed wish your posting to be
distributed to the >>list. >> >>This is not "cast in granite". This
issue may be revisited in the future, >>but I do NOT want to administer
a list that drives its >>subscribers away ..... >> >> >>Chris Hoelscher
>> --IMA.Boundary.3521760390-- ------------------------------ Date: Tue,
29 Jun 1999 10:53:27 -0500 From: Joan Planta To: 'Mary Williams' ,
"'idm...@iuassn.com'" Subject: RE: idms-l list policy change Message-ID:
<61DC7D5DAEFFD111BB22006008A341E403244D@AUSTIN> Me too. Joan Planta
Sophisticated Business Systems Austin, Texas 512.327.5005 x 14
512.327.6859 fax -----Original Message----- From:Mary Williams
[mailto:Mary.W...@asu.edu] Sent:Tuesday, June 29, 1999 10:47 AM
To:'idm...@iuassn.com' Subject:RE: idms-l list policy change Just one
more note that says I agree with the majority of the consensus.
-----Original Message----- From: Hugh Laderman
[mailto:hu...@laderman.com] Sent: Tuesday, June 29, 1999 8:43 AM To:
IDMS-L Subject: Re: idms-l list policy change More agreement with the
many who have already stated this opinion. Hugh Laderman Laderman
Associates (215) 493-3460 Voice (215) 493-0573 Fax -----Original
Message----- From: Shaw, Brock < brock...@MBUK.Mercedes-Benz.com > To:
IDMS-L (List) (E-mail) < idm...@iuassn.com > Date: Tuesday, June 29,
1999 11:21 AM Subject: RE: idms-l list policy change I have to say that
there is a problem whichever way the policy of reply-to is set. If it is
set to the list, then all communications which are sent as a "reply" in
the email system (outlook or whatever) go to the list - even personal
comments to other individuals. If instead, reply goes to the person who
sent the message (as the policy now makes it), then only that person
receives the response, answer, solution, comment or whatever. This
seriously impairs the list in doing what it is supposed to do - viz
communicate! Over the last few months of the UGA hosting, we got half
the story or less in many cases because of the reply only going to the
individual. It was seen as a benefit to the new IUA hosting that we
would be able to generate a bit more email, but see all the relevant
mail. In view of this, I think it is helpful to change the reply policy
back to being the list, and for each person simply to remember that
personal comments and conversations are more appropriately made
directly, not through the list. It is easy to change the reply to when
we know we want to make a personal message. It is still not the end of
the world if someone forgets once in a while, but the default should be
to the list. But missing the information could be important! Best
regards, Brock. Brock Shaw, DBA (ISD) Mercedes Benz (UK), England
-----Original Message----- From: Rick L. Garvin [ mailto:r...@ksu.edu ]
Sent: 29 June 1999 15:49 To: IDM...@IUASSN.COM Subject: Re: idms-l list
policy change I totaly agree!!!!!!!!!!!!!!!!!! Jerry Fica wrote: > > I
am totally dismayed that anyone would be so offended by the extra posts
to > the list. They are certainly irritating but the delete key works
extremely > well on my mail client, so guess what I delete them and read
the important > stuff. > > Just my two cents about restricting replies
to the sender. I think there is > a tremendous loss to the rest of the
list when that happens, and I would > encourage the list to keep the
replies going to the complete list........ > > Jerry Fica >
------------------------------ Date: Tue, 29 Jun 1999 10:52:07 -0500
From: "Verinder, Gene" To: idm...@iuassn.com Subject: RE: idms-l list
policy change Message-ID:
<05B56B254C18D2119EF...@sdadmail1.alldata.net> Chris and
all other members of IDMS-L, The current policy works well only if the
individual receiving assistance does a good job of re-posting the
solutions he/she receives back to the list for all to review. Many
members do this in a timely and accurate manner. Others do not. I would
much rather see all answers for both the content and user experience
(which in many instances is more helpful than just an apar #). When the
number of unneeded e-messages exceeds the amount of junk snail mail I
receive, then I would consider complaining. IMHO, I prefer the default
"return to" address be that of the list and if there are those whose
time is so precious that they can't delete an unwanted message here or
there, they don't deserve to be on the list anyway! What a bad attitude
to take towards such a good communications vehicle as IDMS-L. Gene
Verinder Alliance Data Systems rve...@alldata.net ph: 972-643-1441 fx:
972-643-1419 ---------- From: Jerry Fica [SMTP:jf...@worldnet.att.net]
Sent: Tuesday, June 29, 1999 9:16 AM To: Chris Hoelscher;
idm...@iuassn.com Subject: RE: idms-l list policy change I am totally
dismayed that anyone would be so offended by the extra posts to the
list. They are certainly irritating but the delete key works extremely
well on my mail client, so guess what I delete them and read the
important stuff. Just my two cents about restricting replies to the
sender. I think there is a tremendous loss to the rest of the list when
that happens, and I would encourage the list to keep the replies going
to the complete list........ Jerry Fica >>-----Original Message-----
>>From: Chris Hoelscher [mailto:hoel...@flash.net] >>Sent: Monday, June
28, 1999 6:56 PM >>To: idm...@iuassn.com >>Subject: idms-l list policy
change >> >> >>It didn't take long ...... >> >>I have received requests
from 4 subscribers to be removed from this list >>because of the
unprofessional and cluttered list traffic concerning a >>vacation
out-of-office autoreply. It is not acceptable that anyone should >>feel
the list is of so little value to them because of spam that >>they would
>>want to unsubscribe. >> >>As long as the REPLY-TO is set to
IDM...@IUASSN.COM, *any* out-of-office >>message will sent to the list.
Yes, this is bothersome to many, but many >>subscribers to the "classic"
IDMS-L expressed concern when THAT list >>changed its REPLY-TO from
IDM...@UGA.CC.UGA.EDU to the address of the >>poster. With that concern
in mind, I chose to "test the waters" and allow >>replies to be directed
to the list by default. >> >>However, today there were at least three
replies (to the list) in reply to >>the auto-out-of-office reply. At
least one was accidental, but the >>carelessness or disregard for the
list policies >> of >>all three posts has convinced me that the time is
not right for >>the default >>REPLY-TO directed to the list. >>
>>Effective immediately, we will revert to the policy of replies being
>>directed, by default, to the poster. Replied are certainly encouraged
to >>the list; but as a courtesy to those who do not wish to receive
email >>intended for someone other than themselves (or who do not wish
to read >>email from those who choose to post contrary to list policies
*and* common >>sense), you will have to make the effort to change to TO
from the >>poster to >>IDM...@IUASSN.COM if you indeed wish your posting
to be distributed to the >>list. >> >>This is not "cast in granite".
This issue may be revisited in the future, >>but I do NOT want to
administer a list that drives its >>subscribers away ..... >> >> >>Chris
Hoelscher >> ------------------------------ Date: Tue, 29 Jun 1999
11:58:57 -0400 From: "Al A Shuryan" To: Mary.W...@asu.edu Cc:
"'idm...@iuassn.com'" Subject: RE: idms-l list policy change Message-ID:
<8525679F.0...@amerhub.meritorauto.com> Ditto, and I apoligize
for replying to the vacation note not knowing it was from the IDMS-L and
not realizing it goes out to the world now. Mary Williams on 06/29/99
11:46:54 AM To: "'idm...@iuassn.com'" cc: (bcc: Al A Shuryan/Amer/Auto)
Subject: RE: idms-l list policy change Just one more note that says I
agree with the majority of the consensus. -----Original Message-----
From: Hugh Laderman [mailto:hu...@laderman.com] Sent: Tuesday, June 29,
1999 8:43 AM To: IDMS-L Subject: Re: idms-l list policy change More
agreement with the many who have already stated this opinion. Hugh
Laderman Laderman Associates (215) 493-3460 Voice (215) 493-0573 Fax
-----Original Message----- From: Shaw, Brock <
brock...@MBUK.Mercedes-Benz.com > To: IDMS-L (List) (E-mail) <
idm...@iuassn.com > Date: Tuesday, June 29, 1999 11:21 AM Subject: RE:
idms-l list policy change I have to say that there is a problem
whichever way the policy of reply-to is set. If it is set to the list,
then all communications which are sent as a "reply" in the email system
(outlook or whatever) go to the list - even personal comments to other
individuals. If instead, reply goes to the person who sent the message
(as the policy now makes it), then only that person receives the
response, answer, solution, comment or whatever. This seriously impairs
the list in doing what it is supposed to do - viz communicate! Over the
last few months of the UGA hosting, we got half the story or less in
many cases because of the reply only going to the individual. It was
seen as a benefit to the new IUA hosting that we would be able to
generate a bit more email, but see all the relevant mail. In view of
this, I think it is helpful to change the reply policy back to being the
list, and for each person simply to remember that personal comments and
conversations are more appropriately made directly, not through the
list. It is easy to change the reply to when we know we want to make a
personal message. It is still not the end of the world if someone
forgets once in a while, but the default should be to the list. But
missing the information could be important! Best regards, Brock. Brock
Shaw, DBA (ISD) Mercedes Benz (UK), England -----Original Message-----
From: Rick L. Garvin [ mailto:r...@ksu.edu ] Sent: 29 June 1999 15:49 To:
IDM...@IUASSN.COM Subject: Re: idms-l list policy change I totaly
agree!!!!!!!!!!!!!!!!!! Jerry Fica wrote: > > I am totally dismayed that
anyone would be so offended by the extra posts to > the list. They are
certainly irritating but the delete key works extremely > well on my
mail client, so guess what I delete them and read the important > stuff.
> > Just my two cents about restricting replies to the sender. I think
there is > a tremendous loss to the rest of the list when that happens,
and I would > encourage the list to keep the replies going to the
complete list........ > > Jerry Fica > ------------------------------
Date: Tue, 29 Jun 1999 11:59:22 -0400 From: Roger Lawrence To: IDMS-L
Subject: Re: idms-l list policy change Message-ID:
<3778ED5A...@seminole-electric.com> Okay, I tried to keep quiet;
but, here it is. To change the default reply-to address and
substantially decrease the inter-communication this forum exists to
promote simply because a few careless/inconsiderate folks can't resist
their urge to engage in mindless banter harkens back to grade school
when we all missed recess because Suzy was bad. If four people want to
cut and run because of some relatively small annoyance, that's a shame.
As for the rest of us, let's continue to share with one another as
adults. Count one more vote for returning to the list as the default
reply-to. Also, thank you, Chris, for your willingness to shoulder the
burden of list host. It IS appreciated! Roger Lawrence Chris Hoelscher
wrote: > It didn't take long ...... > > I have received requests from 4
subscribers to be removed from this list > because of the unprofessional
and cluttered list traffic concerning a > vacation out-of-office
autoreply. It is not acceptable that anyone should > feel the list is of
so little value to them because of spam that they would > want to
unsubscribe. > > As long as the REPLY-TO is set to IDM...@IUASSN.COM,
*any* out-of-office > message will sent to the list. Yes, this is
bothersome to many, but many > subscribers to the "classic" IDMS-L
expressed concern when THAT list > changed its REPLY-TO from
IDM...@UGA.CC.UGA.EDU to the address of the > poster. With that concern
in mind, I chose to "test the waters" and allow > replies to be directed
to the list by default. > > However, today there were at least three
replies (to the list) in reply to > the auto-out-of-office reply. At
least one was accidental, but the > carelessness or disregard for the
list policies of > all three posts has convinced me that the time is not
right for the default > REPLY-TO directed to the list. > > Effective
immediately, we will revert to the policy of replies being > directed,
by default, to the poster. Replied are certainly encouraged to > the
list; but as a courtesy to those who do not wish to receive email >
intended for someone other than themselves (or who do not wish to read >
email from those who choose to post contrary to list policies *and*
common > sense), you will have to make the effort to change to TO from
the poster to > IDM...@IUASSN.COM if you indeed wish your posting to be
distributed to the > list. > > This is not "cast in granite". This issue
may be revisited in the future, > but I do NOT want to administer a list
that drives its subscribers away ..... > > Chris Hoelscher
------------------------------ Date: Tue, 29 Jun 1999 18:05:45 +0200
From: Michel_G...@paribas.com To: JoanP...@soph.com Cc:
Mary.W...@asu.edu, idm...@iuassn.com Subject:
=?iso-8859-1?Q?R=E9f.[2]:_idms-l_list_policy_change?= Message-ID:
<8025679F.0...@lonn000101.uk.paribas.com> the same remark Michel
Guerriche IDMS DBA Paris, FRANCE Internet De : JoanP...@soph.com le
29/06/99 15:53 GMT Pour : Mary.Williams, idms-l cc : ccc: Michel
GUERRICHE Objet : RE: idms-l list policy change Me too. Joan Planta
Sophisticated Business Systems Austin, Texas 512.327.5005 x 14
512.327.6859 fax -----Original Message----- From: Mary Williams
[mailto:Mary.W...@asu.edu] Sent: Tuesday, June 29, 1999 10:47 AM To:
'idm...@iuassn.com' Subject: RE: idms-l list policy change Just one more
note that says I agree with the majority of the consensus. -----Original
Message----- From: Hugh Laderman [mailto:hu...@laderman.com] Sent:
Tuesday, June 29, 1999 8:43 AM To: IDMS-L Subject: Re: idms-l list
policy change More agreement with the many who have already stated this
opinion. Hugh Laderman Laderman Associates (215) 493-3460 Voice (215)
493-0573 Fax -----Original Message----- From: Shaw, Brock <
brock...@MBUK.Mercedes-Benz.com > To: IDMS-L (List) (E-mail) <
idm...@iuassn.com > Date: Tuesday, June 29, 1999 11:21 AM Subject: RE:
idms-l list policy change I have to say that there is a problem
whichever way the policy of reply-to is set. If it is set to the list,
then all communications which are sent as a "reply" in the email system
(outlook or whatever) go to the list - even personal comments to other
individuals. If instead, reply goes to the person who sent the message
(as the policy now makes it), then only that person receives the
response, answer, solution, comment or whatever. This seriously impairs
the list in doing what it is supposed to do - viz communicate! Over the
last few months of the UGA hosting, we got half the story or less in
many cases because of the reply only going to the individual. It was
seen as a benefit to the new IUA hosting that we would be able to
generate a bit more email, but see all the relevant mail. In view of
this, I think it is helpful to change the reply policy back to being the
list, and for each person simply to remember that personal comments and
conversations are more appropriately made directly, not through the
list. It is easy to change the reply to when we know we want to make a
personal message. It is still not the end of the world if someone
forgets once in a while, but the default should be to the list. But
missing the information could be important! Best regards, Brock. Brock
Shaw, DBA (ISD) Mercedes Benz (UK), England -----Original Message-----
From: Rick L. Garvin [ mailto:r...@ksu.edu ] Sent: 29 June 1999 15:49 To:
IDM...@IUASSN.COM Subject: Re: idms-l list policy change I totaly
agree!!!!!!!!!!!!!!!!!! Jerry Fica wrote: > > I am totally dismayed that
anyone would be so offended by the extra posts to > the list. They are
certainly irritating but the delete key works extremely > well on my
mail client, so guess what I delete them and read the important > stuff.
> > Just my two cents about restricting replies to the sender. I think
there is > a tremendous loss to the rest of the list when that happens,
and I would > encourage the list to keep the replies going to the
complete list........ > > Jerry Fica >
-----------------------------------------------------------------------------
This message is confidential; its contents do not constitute a
commitment by Paribas except where provided for in a written agreement
between you and Paribas. Any unauthorised disclosure, use or
dissemination, either whole or partial, is prohibited. If you are not
the intended recipient of the message, please notify the sender
immediately. Ce message est confidentiel ; son contenu ne représente en
aucun cas un engagement de la part de Paribas sous réserve de tout
accord conclu par écrit entre vous et Paribas. Toute publication,
utilisation ou diffusion, même partielle, doit être autorisée
préalablement. Si vous n'êtes pas destinataire de ce message, merci d'en
avertir immédiatement l'expéditeur. ------------------------------ Date:
Tue, 29 Jun 1999 16:54:02 +0100 From: "Stewart, Jeremy" To:
"'idm...@iuassn.com'" Subject: RE: idms-l list policy change Message-ID:
I agree also. Please let us have all the potentially useful information
- the "garbage" can easily be sifted out. Jeremy R.L. Stewart Database
Administrator Carbonless European Operations Arjo Wiggins Appleton
Holdings Ltd > -----Original Message----- > From:Mary Williams
[SMTP:Mary.W...@asu.edu] > Sent:29 June 1999 16:47 >
To:'idm...@iuassn.com' > Subject:RE: idms-l list policy change > > Just
one more note that says I agree with the majority of the > consensus. >
> -----Original Message----- > From: Hugh Laderman
[mailto:hu...@laderman.com] > Sent: Tuesday, June 29, 1999 8:43 AM > To:
IDMS-L > Subject: Re: idms-l list policy change > > > More agreement
with the many who have already stated this opinion. > > > Hugh Laderman
> Laderman Associates > (215) 493-3460 Voice > (215) 493-0573 Fax > >
-----Original Message----- > From: Shaw, Brock <
brock...@MBUK.Mercedes-Benz.com > > > To: IDMS-L (List) (E-mail) <
idm...@iuassn.com > > > Date: Tuesday, June 29, 1999 11:21 AM > Subject:
RE: idms-l list policy change > > > > I have to say that there is a
problem whichever way the policy of > reply-to > is set. > > If it is
set to the list, then all communications which are sent as a > "reply"
in the email system (outlook or whatever) go to the list - > even >
personal comments to other individuals. > > If instead, reply goes to
the person who sent the message (as the > policy now > makes it), then
only that person receives the response, answer, > solution, > comment or
whatever. This seriously impairs the list in doing what it > is >
supposed to do - viz communicate! > > Over the last few months of the
UGA hosting, we got half the story or > less > in many cases because of
the reply only going to the individual. It > was > seen as a benefit to
the new IUA hosting that we would be able to > generate a > bit more
email, but see all the relevant mail. > > In view of this, I think it is
helpful to change the reply policy back > to > being the list, and for
each person simply to remember that personal > comments and
conversations are more appropriately made directly, not > through > the
list. It is easy to change the reply to when we know we want to > make a
> personal message. It is still not the end of the world if someone >
forgets > once in a while, but the default should be to the list. But
missing > the > information could be important! > > Best regards, >
Brock. > > Brock Shaw, DBA (ISD) > Mercedes Benz (UK), England > > >
-----Original Message----- > From: Rick L. Garvin [ mailto:r...@ksu.edu ]
> Sent: 29 June 1999 15:49 > To: IDM...@IUASSN.COM > Subject: Re: idms-l
list policy change > > > I totaly agree!!!!!!!!!!!!!!!!!! > > Jerry Fica
wrote: > > > > I am totally dismayed that anyone would be so offended by
the extra > posts > to > > the list. They are certainly irritating but
the delete key works > extremely > > > well on my mail client, so guess
what I delete them and read the > important > > > stuff. > > > > Just my
two cents about restricting replies to the sender. I think > there > is
> > a tremendous loss to the rest of the list when that happens, and I >
would > > encourage the list to keep the replies going to the complete >
list........ > > > > Jerry Fica > > > >
___________________________________________________________________ >
This message has been checked for all viruses, including ExploreZip > by
the Star Screening System >
http://academy.star.co.uk/public/virustats.htm
___________________________________________________________________ This
message has been checked for all viruses, including ExploreZip by the
Star Screening System http://academy.star.co.uk/public/virustats.htm
------------------------------ Date: Tue, 29 Jun 1999 13:09:33 -0400
From: "Jon R. Gocher" To: Subject: Fw: IDMS 14.0 Database Corruption
Message-ID: <1999062917...@frontiernet.net> Glenn - I believe
the "somewhere else" you mentioned is us. We are 14.0 / 9711 and went
into production about the same time period you did. Our problem is
similar in that it seems to be related to heavy volume with lots of
stalls and deadlocks. Our problem is in our QUEUE area. Our queue area
gets pounded every Tuesday and Wednesday. Since going into production
4th quarter of '98, we have had a half dozen episodes. The destruction
to our queue area is massive. I have pulled all-nighters to try to
salvage as much of the data as possible before the start of the next
online day. Then I save the area off to another file and initialize for
the coming day. A few months ago, I posted to IDMS-L and got several
responses for queue APARS that we did not have on our system. I applied
every one of them and we went almost 2 months without any more problems.
In May, we had 3 episodes which murdered our business. We have the
"trap" to IDMSTMGR in our test environment now and the IDMSDPLX "trace"
exit installed in test and prod. The "trap" will be applied to
production this week. It sounds to me like you've been working with Dick
Weiland from C.A. in Chicago on this. We have also had C.A. customer
service reps onsite 3 to 5 days a week for the last two weeks waiting
for the next time it happens so they can jump all over it. We have an
open issue and Dick Weiland is the one who is working with us. Until
your post, I believed we were the only shop in the world having this
problem. Besides the fact that our problem seems to be localized to just
the queue area, we are not getting the SAVE/RESTORE error you described.
We have seen evidence where an entire page seems to be missing all of
the referenced records pointed to by QUEUE-SROOT and/or SROOT-SEXT sets
from records on other pages. Most of the breaks are with VLR fragments
and we also see that we are broken from the QUEUE-DCQ-138 and the first
SROOT-DCS-139. But... what also happens, which is interesting, is that
we get lots of duplicate DBKEYS which sometimes, by chance occurrence,
chain together a mostly complete set with one break in the middle of the
set somewhere, but leave behind thousands of member records as orphans
that are not attached in any way to this set. This means we can
sometimes go for hours without even realizing we have a problem because
we are not broken where we are storing new records.. We begin to realize
we have a problem because the queue calls return a 4407 status. Also, we
occassionally get ABRT1117. When I walk the various queue sets with OLQ,
I get 0361's. I am delighted to see by your post that I am not alone. I
empathize with your situation and fully expect to die 10 years early
because of this. Anybody else in the world having this kind of problem
or are we the only two? Thanks. Jon Gocher ---------- > From:
glenn....@ac.com > To: idm...@iuassn.com > Subject: IDMS 14.0
Database Corruption > Date: Tuesday, June 29, 1999 9:29 AM > > We are
running IDMS 14.0 GL9711 and have two very serious database corruption >
problems that have caused us to lose data (something that is new to us!)
and > wanted to know if anyone else had experienced similar problems? >
> We upgraded several production CVs from IDMS 10.2 to 14.0 in November
and > December 1998. We then added additional applications to one of the
CVs at the > end of February. > > The multi-application CV the next
business day started to get a message like: > > CURRENCY
SAVE/RESTOREINTERNAL ERROR CODE IS 5 > RUN-UNIT xxxxxxx NOT RECOVERED!
NON-ZERO status returned from BRBK > > The problem occurred when the
system was very busy and it appeared that there > were rollback related
problems due to deadlocks. > > We opened an issue with CA and upon
further investigation we found that two of > our databases had become
corrupted. IDMS > had wrote records from one area into the wrong area
and even into the other > application database! It obviously appeared >
to be an internal bug. We spent a considerable amount of diagnostic time
review > the journals, dumps, and logs but could > never isolate the
problem (we have heard that a similar problem has happened > somewhere
else but not resolved?). > > CA supplied us with a patch that traps all
IDMS stores to confirm that in fact > the record is going to the right
page range. If > a problem is found it abends the transaction with a
SOC1 and snaps a dump of it > to the log (for diagnostic purposes). >
The problem did not occur again after the trap was implemented and the
problem > was forgotten (the trap, according to > CA will not prevent
the problem but it will prevent the corruption from > occurring). > > In
late May we implemented two more upgraded CVs over several weekends and
the > problem occurred again. The > problem this time presented itself
as batch jobs getting 0371 error messages but > corruption was
confirmed. We again > lost data but it was limited to only one CV and
one application (it was a single > application CV). We did not have the
trap > in these CVs since we didn't want to introduce a problem in these
new > environments. We have subsequently added > the trap to all of our
14.0 update CVs. Again, no further problems have been > found. > > We
believe that there is a bug somewhere but we cannot isolate it or
replicate > it for CA to fix. The only commonality > is that the
CVs/mainframe was very busy and batch jobs abended (due to time-outs >
or deadlocks). It appeared that > it might be rollback related but the
journals had the problem records going to > the wrong place so that
rollback > cannot be at fault since it only applies what is in the
journal. > > We are upgrading a large database in July and are concerned
that we have yet to > identify or resolve this > problem. > > If you
have seen this problem or a similar problem at your site please respond
> to me (I have been working > with IDMS since 1984 and have never seen
a problem like this!). The intent of > this question is to solicite
responses > to our problem, not to raise flags about the product itself
(since we appear to > be the only ones affected). We use > IDMS/DC, ADS
and Cobol on OS 390 (no CICS). > > Glenn Scott > > > >
------------------------------ Date: Tue, 29 Jun 1999 13:14:17 -0400
From: hoel...@us.ibm.com To: idm...@iuassn.com Subject: list clear this
up Message-ID: <8525679F.0...@d54mta03.raleigh.ibm.com> due to
all the emails I am getting, there is certainly some confusion. So lets
set the record straight THERE IS NO RESTRICTION ON REPLYING TO ANY LEGIT
MESSAGE TO THE LIST!!! what *is* happening is that when you press the
REPLY button on your email program, the DEFAULT for the TO on your reply
will be the address of the POSTER. You are NOT, however, required (or
even encouraged) to leave it that way. In fact, for 99% of the posts,
you SHOULD change it to idm...@iuassn.com. However, until the list is
more stable and the full IUA board can decide this issue, we are making
the action of replying to the list the MANUAL action of each potential
reply-er. thanks, Chris Hoelscher ------------------------------ Date:
Tue, 29 Jun 1999 13:27:26 -0400 From: "Hugh Laderman" To: "IDMS-L"
Subject: Re: list clear this up Message-ID:
<000801bec254$a9302a20$c3c5a4d8@oemcomputer> Chris Your stewardship is
greatly appreciated, but you really shouldn't let the few who are
bothered by erroneous posts cause the list to become something less than
it should be. Information will be lost because people will, as is
natural, forget to change the reply ID. Please recconsider. Hugh
Laderman Laderman Associates (215) 493-3460 Voice (215) 493-0573 Fax
-----Original Message----- From: hoel...@us.ibm.com To:
idm...@iuassn.com Date: Tuesday, June 29, 1999 1:19 PM Subject: list
clear this up > > > >due to all the emails I am getting, there is
certainly some confusion. So lets >set the record straight > > >THERE IS
NO RESTRICTION ON REPLYING TO ANY LEGIT MESSAGE TO THE LIST!!! > >what
*is* happening is that when you press the REPLY button on your email
>program, the DEFAULT for the TO on your reply will be the address of
the POSTER. >You are NOT, however, required (or even encouraged) to
leave it that way. In >fact, for 99% of the posts, you SHOULD change it
to idm...@iuassn.com. However, >until the list is more stable and the
full IUA board can decide this issue, we >are making the action of
replying to the list the MANUAL action of each >potential reply-er. >
>thanks, >Chris Hoelscher > > ------------------------------ Date: Tue,
29 Jun 1999 13:31:47 -0400 From: "Harrison, Robert" To: 'idms-l
subscribers' Subject: idms-l policy I'm not sure what this discussion is
all about. Let's say for example that four idms-l subscribers go on
vacation for a given week, and let's say that they set their e-mail
systems in such a way that they reply automatically to alert their
co-workers that they are out of the office. And let's assume that,
during the five-day workweek, an average of eleven messages per day are
posted to idms-l. If replies are automatically sent out to the full
membership, each subscriber would then receive 220 "garbage" e-mail
messages that week, notifying them that someone they probably don't know
is out of the office. Again, I'm not sure I understand all the issues
involved here, but if this is indeed the case, it seems to me that a
system that forces its members to sift through that much junk is not one
which promotes good communication. Bob Harrison, Troll Book Clubs
------------------------------ Date: Tue, 29 Jun 1999 12:37:05 -0500
From: rpi...@mge.com To: hoel...@us.ibm.com, IDM...@iuassn.com
Subject: Re: list clear this up Message-ID:
<99Jun29.123...@dns.MGE.COM> Chris - I don't think there is any
confusion, it's just that people don't like the "new" policy - just like
we didn't like it when it was changed on the old list. It's a shame what
we (and you) need to go through just because a few people can't handle
the "I'm away from my office" messages (and a couple of people didn't
change the reply for a personal message - that kind of thing can be
handled in a personal note). There were 2 things I thought were great
about the IUA getting the list: 1: An auto-response to the list and not
a private auto-response. 2: Being able to talk about non-CA support
products - as appropriate. Now it seems we're loosing #2 because a few
can't handle it. If it sounds like I'm upset at the development, well -
I am. I can live with whatever policy develops (I won't quit because I
don't like some of the messages LIKE OTHER PEOPLE DID.) Please
re-consider. These thoughts are my own only and not necessarily my
employers. Dick
***************************************************************************
***** Richard A. Pierce Madison Gas and Electric Company DBA P.O. Box
1231, Madison, Wisconsin 53701-1231 e-mail:rpi...@mge.com Phone:
608-252-7205
***************************************************************************
***** hoel...@us.ibm.com on 06/29/99 12:14:17 PM To: idm...@iuassn.com
cc: (bcc: Richard Pierce/IMS/MGE) Subject: list clear this up due to all
the emails I am getting, there is certainly some confusion. So lets set
the record straight THERE IS NO RESTRICTION ON REPLYING TO ANY LEGIT
MESSAGE TO THE LIST!!! what *is* happening is that when you press the
REPLY button on your email program, the DEFAULT for the TO on your reply
will be the address of the POSTER. You are NOT, however, required (or
even encouraged) to leave it that way. In fact, for 99% of the posts,
you SHOULD change it to idm...@iuassn.com. However, until the list is
more stable and the full IUA board can decide this issue, we are making
the action of replying to the list the MANUAL action of each potential
reply-er. thanks, Chris Hoelscher ------------------------------ Date:
Tue, 29 Jun 1999 13:41:42 -0400 From: dennis ruggere To:
"'rpi...@mge.com'" , hoel...@us.ibm.com, IDM...@iuassn.com Subject:
RE: list clear this up Message-ID: I do not know about anyone else but I
am sick and tired of wasting my time today reading all the opinions on
this subject. In case, you haven't noticed we are being buried TODAY by
junk mail!!! Dennis J. Ruggere TACT Software Product Support 84 West
Park Place Stamford, CT 06901 Tel: (800) 433 8228 (413) 623 2260 Pager:
(800) 465 0622 email: drug...@tact.com sup...@tact.com -----Original
Message----- From:rpi...@mge.com [SMTP:rpi...@mge.com] Sent:Tuesday,
June 29, 1999 1:37 PM To:hoel...@us.ibm.com; IDM...@iuassn.com
Subject:Re: list clear this up Chris - I don't think there is any
confusion, it's just that people don't like the "new" policy - just like
we didn't like it when it was changed on the old list. It's a shame what
we (and you) need to go through just because a few people can't handle
the "I'm away from my office" messages (and a couple of people didn't
change the reply for a personal message - that kind of thing can be
handled in a personal note). There were 2 things I thought were great
about the IUA getting the list: 1: An auto-response to the list and not
a private auto-response. 2: Being able to talk about non-CA support
products - as appropriate. Now it seems we're loosing #2 because a few
can't handle it. If it sounds like I'm upset at the development, well -
I am. I can live with whatever policy develops (I won't quit because I
don't like some of the messages LIKE OTHER PEOPLE DID.) Please
re-consider. These thoughts are my own only and not necessarily my
employers. Dick
***************************************************************************
***** Richard A. Pierce Madison Gas and Electric Company DBA P.O. Box
1231, Madison, Wisconsin 53701-1231 e-mail:rpi...@mge.com Phone:
608-252-7205
***************************************************************************
***** hoel...@us.ibm.com on 06/29/99 12:14:17 PM To: idm...@iuassn.com
cc: (bcc: Richard Pierce/IMS/MGE) Subject: list clear this up due to all
the emails I am getting, there is certainly some confusion. So lets set
the record straight THERE IS NO RESTRICTION ON REPLYING TO ANY LEGIT
MESSAGE TO THE LIST!!! what *is* happening is that when you press the
REPLY button on your email program, the DEFAULT for the TO on your reply
will be the address of the POSTER. You are NOT, however, required (or
even encouraged) to leave it that way. In fact, for 99% of the posts,
you SHOULD change it to idm...@iuassn.com. However, until the list is
more stable and the full IUA board can decide this issue, we are making
the action of replying to the list the MANUAL action of each potential
reply-er. thanks, Chris Hoelscher ------------------------------ Date:
Tue, 29 Jun 1999 13:42:13 -0400 From: Roger Lawrence To: IDMS-L Subject:
Re: list clear this up Message-ID:
<37790575...@seminole-electric.com> Chris, If 99% of replies
SHOULD go to the list, that spells DEFAULT to the list! Please
reconsider your decision; unless, of course, the full board was needed
to make the decision to default to the poster. Thanks again to you and
the IUA for hosting this list. Roger Lawrence hoel...@us.ibm.com wrote:
> due to all the emails I am getting, there is certainly some confusion.
So lets > set the record straight > > THERE IS NO RESTRICTION ON
REPLYING TO ANY LEGIT MESSAGE TO THE LIST!!! > > what *is* happening is
that when you press the REPLY button on your email > program, the
DEFAULT for the TO on your reply will be the address of the POSTER. >
You are NOT, however, required (or even encouraged) to leave it that
way. In > fact, for 99% of the posts, you SHOULD change it to
idm...@iuassn.com. However, > until the list is more stable and the full
IUA board can decide this issue, we > are making the action of replying
to the list the MANUAL action of each > potential reply-er. > > thanks,
> Chris Hoelscher ------------------------------ Date: Tue, 29 Jun 1999
12:47:45 -0500 From: Chris Angerer To: IDMS-L Subject: Anyone running
14.0 or 14.1 with OS390 release 2.7 ?? Message-ID: We will be going to
OS390 release 2.7 in the middle of us converting all of our CV's to
14.1, and we wanted to know if anyone else is running this ??? Thanks in
advance. Chris W. Angerer State of Missouri, OA, DIS
cang...@mail.state.mo.us ------------------------------ Date: Tue, 29
Jun 1999 13:58:16 -0400 From: "McMahon, Rick" To: "'Harrison, Robert'" ,
'idms-l subscribers' Subject: RE: idms-l policy Message-ID: I think
you've exaggerated a bit on the number of auto-reply posts. My e-mail
client and most others that I know of will only auto-reply once to each
address that sends them a message for the entire duration of the
out-of-office condition. In this case, IDMS-L sends them the first
message and the auto-reply is returned. At this point, no more
auto-replies will be sent to IDMS-L until the next time the person turns
it on. Rick McMahon -----Original Message----- From: Harrison, Robert
[mailto:robert....@TROLL.COM] Sent: Tuesday, June 29, 1999 1:32 PM
To: 'idms-l subscribers' Subject: idms-l policy I'm not sure what this
discussion is all about. Let's say for example that four idms-l
subscribers go on vacation for a given week, and let's say that they set
their e-mail systems in such a way that they reply automatically to
alert their co-workers that they are out of the office. And let's assume
that, during the five-day workweek, an average of eleven messages per
day are posted to idms-l. If replies are automatically sent out to the
full membership, each subscriber would then receive 220 "garbage" e-mail
messages that week, notifying them that someone they probably don't know
is out of the office. Again, I'm not sure I understand all the issues
involved here, but if this is indeed the case, it seems to me that a
system that forces its members to sift through that much junk is not one
which promotes good communication. Bob Harrison, Troll Book Clubs
------------------------------ Date: Tue, 29 Jun 1999 14:34:13 -0400
From: "McMahon, Rick" To: 'dennis ruggere' , "IDMS-L (E-mail)" Subject:
RE: list clear this up Message-ID: Although some may find the volume of
messages on this topic bothersome, it is a discussion of an extremely
pertinent issue regarding list policy - one that impacts the ultimate
usefullness of this discussion medium. A similar reaction occurred when
the old IDMS-L changed the default reply-to policy. I found that when
the old IDMS-L changed it's default policy to send replies to the
original sender of the post, the list became much less useful. There
were many posts that went unanswered from the list's standpoint,
although I'm sure responses were directed back to the originator. With
the default reply to IDMS-L ,we ALL share in the responses from every
IDMS-Ler, not just the ones that remember or understand to change the
reply-to address. On a lighter note, a big thanks to Chris for taking on
this endeavor. Rick McMahon P.S. If one doesn't wish to particpate in
this (or any other) discussion, just press the key. That takes all of
about 1 second per message. -----Original Message----- From: dennis
ruggere [mailto:drug...@TACT.com] Sent: Tuesday, June 29, 1999 1:42 PM
To: 'rpi...@mge.com'; hoel...@us.ibm.com; IDM...@iuassn.com Subject:
RE: list clear this up I do not know about anyone else but I am sick and
tired of wasting my time today reading all the opinions on this subject.
In case, you haven't noticed we are being buried TODAY by junk mail!!!
Dennis J. Ruggere TACT Software Product Support 84 West Park Place
Stamford, CT 06901 Tel: (800) 433 8228 (413) 623 2260 Pager: (800) 465
0622 email: drug...@tact.com sup...@tact.com
------------------------------ Date: Tue, 29 Jun 1999 13:45:00 -0400
From: wrad...@bkb.com To: "'idm...@iuassn.com'" Subject: RES: idms-l
list policy change Message-ID: <00009BE...@bkb.com> Please, set
"REPLY" to the list, again. Radesca, Wagner Development Support
BankBoston Brazil -----Mensagem original----- De: "Stewart; Jeremy" at
INTERNET Enviada em: Ter=E7a-feira, 29 de Junho de 1999 17:54 Para:
"'idm...@iuassn.com'" at INTERNET Assunto: RE: idms-l list policy change
I agree also. Please let us have all the potentially useful information
- the "garbage" can easily be sifted out. Jeremy R.L. Stewart Database
Administrator Carbonless European Operations Arjo Wiggins Appleton
Holdings Ltd > -----Original Message----- > From: Mary Williams
[SMTP:Mary.W...@asu.edu] > Sent: 29 June 1999 16:47 > To:
'idm...@iuassn.com' > Subject: RE: idms-l list policy change > > Just
one more note that says I agree with the majority of the > consensus. >
> -----Original Message----- > From: Hugh Laderman
[mailto:hu...@laderman.com] > Sent: Tuesday, June 29, 1999 8:43 AM > To:
IDMS-L > Subject: Re: idms-l list policy change > > > More agreement
with the many who have already stated this opinion. > > > Hugh Laderman
> Laderman Associates > (215) 493-3460 Voice > (215) 493-0573 Fax > >
-----Original Message----- > From: Shaw, Brock <
brock...@MBUK.Mercedes-Benz.com > > > To: IDMS-L (List) (E-mail) <
idm...@iuassn.com > > > Date: Tuesday, June 29, 1999 11:21 AM > Subject:
RE: idms-l list policy change > > > > I have to say that there is a
problem whichever way the policy of > reply-to > is set. > > If it is
set to the list, then all communications which are sent as a > "reply"
in the email system (outlook or whatever) go to the list - > even >
personal comments to other individuals. > > If instead, reply goes to
the person who sent the message (as the > policy now > makes it), then
only that person receives the response, answer, > solution, > comment or
whatever. This seriously impairs the list in doing what it > is >
supposed to do - viz communicate! > > Over the last few months of the
UGA hosting, we got half the story or > less > in many cases because of
the reply only going to the individual. It > was > seen as a benefit to
the new IUA hosting that we would be able to > generate a > bit more
email, but see all the relevant mail. > > In view of this, I think it is
helpful to change the reply policy back > to > being the list, and for
each person simply to remember that personal > comments and
conversations are more appropriately made directly, not > through > the
list. It is easy to change the reply to when we know we want to > make a
> personal message. It is still not the end of the world if someone >
forgets > once in a while, but the default should be to the list. But
missing > the > information could be important! > > Best regards, >
Brock. > > Brock Shaw, DBA (ISD) > Mercedes Benz (UK), England > > >
-----Original Message----- > From: Rick L. Garvin [ mailto:r...@ksu.edu ]
> Sent: 29 June 1999 15:49 > To: IDM...@IUASSN.COM > Subject: Re: idms-l
list policy change > > > I totaly agree!!!!!!!!!!!!!!!!!! > > Jerry Fica
wrote: > > > > I am totally dismayed that anyone would be so offended by
the extra > posts > to > > the list. They are certainly irritating but
the delete key works > extremely > > > well on my mail client, so guess
what I delete them and read the > important > > > stuff. > > > > Just my
two cents about restricting replies to the sender. I think > there > is
> > a tremendous loss to the rest of the list when that happens, and I >
would > > encourage the list to keep the replies going to the complete >
list........ > > > > Jerry Fica > > > >
___________________________________________________________________ >
This message has been checked for all viruses, including ExploreZip > by
the Star Screening System >
http://academy.star.co.uk/public/virustats.htm
___________________________________________________________________ This
message has been checked for all viruses, including ExploreZip by the
Star Screening System http://academy.star.co.uk/public/virustats.htm
------------------------------ Date: Tue, 29 Jun 1999 14:48:19 -0400
From: "Jackson, Jeff" To: "IDMS-L (E-mail)" Subject: RE: list clear this
up Message-ID:
<1FF70DACAF51D2118FBD...@MSGDAL527NTS.fmr.com> I had
forgotten about this happening on the old list, but also noticed a drop
in the list value about this time. I truly hope this list doesn't go
down the same path. I would much rather get 10 or 20 garbage posts per
day than miss out on 1 or 2 valid responses. Jeff Jackson Database
Technical Support Fidelity Investments 400 E. Las Colinas Blvd., MZ CC2T
Irving, TX 75039 * - 972-584-5276 *!- 972-584-5273 - DBMS Hot Line *
Pager: http://www.skytel.com/Paging/pageme.cgi?pin=4197550,1
*mailto:Jeff.J...@fmr.com > -----Original Message----- >
From:McMahon, Rick [SMTP:Rick.M...@fns.usda.gov] > Sent:Tuesday, June
29, 1999 1:34 PM > To:'dennis ruggere'; IDMS-L (E-mail) > Subject:RE:
list clear this up > > > I found that when the old IDMS-L changed it's
default policy to send > replies > to the original sender of the post,
the list became much less useful. > There > were many posts that went
unanswered from the list's standpoint, although > I'm sure responses
were directed back to the originator. With the default > reply to IDMS-L
,we ALL share in the responses from every IDMS-Ler, not > just > the
ones that remember or understand to change the reply-to address. > > On
a lighter note, a big thanks to Chris for taking on this endeavor. > >
Rick McMahon > > P.S. If one doesn't wish to particpate in this (or any
other) > discussion, > just press the key. That takes all of about 1
second per > message. > > > -----Original Message----- > From: dennis
ruggere [mailto:drug...@TACT.com] > Sent: Tuesday, June 29, 1999 1:42
PM > To: 'rpi...@mge.com'; hoel...@us.ibm.com; IDM...@iuassn.com >
Subject: RE: list clear this up > > > I do not know about anyone else
but I am sick and tired of > wasting my time today reading all the
opinions on this subject. In case, > you > haven't noticed we are being
buried TODAY by junk mail!!! > > Dennis J. Ruggere > TACT Software
Product Support > 84 West Park Place > Stamford, CT 06901 > Tel: (800)
433 8228 > (413) 623 2260 > Pager: (800) 465 0622 > email:
drug...@tact.com > sup...@tact.com ------------------------------
Date: Tue, 29 Jun 1999 12:52:41 -0700 From: JB Moore To:
idm...@iuassn.com Subject: CA-IDMS Article Message-ID:
<377924...@ix.netcom.com> Hello list, Jim Moore here. I don't know
how many CA-IDMSers read Technical Support magazine. I write a regular
column for this magazine. The column is called Working Smarter. The
focus of my efforts over the last 2 years has been ISPF Version 4,
OS/390, the Language Environment and advanced COBOL and Assembler
programming techniques. The editor of the magazine is always looking for
interesting technical content. When I proposed a CA-IDMS article, she
gave me the go-ahead. So, 3,600 words later, I had my article: A TIOT
Browser for CA-IDMS DC I don't know what issue the article will appear
in, sometime later this year. If the article gets good feedback from the
readers (mostly blue-to-the-bone sysprogs and other bit-fiddlers), I
will continue to write on CA-IDMS for the trades. The cute little
utility that is the subject of the article is written in Assembler,
ADS/O and COBOL. It's kind of like ISRDDN in ISPF only not as powerful.
It allows you to pull up a scrollable display of the running DC region's
TIOT, you know, the allocated files. Issue REFRESH and it will pick up
the latest dynallocs or frees. Now quit griping about the list!!!! Moore
------------------------------ Date: Tue, 29 Jun 1999 13:05:52 -0700
From: JB Moore To: Stephen Sealy Cc: idm...@iuassn.com Subject: Re:
About ISPF Version 4 Message-ID: <377927...@ix.netcom.com> Stephen
Sealy wrote: > > Jim, > > I don't know if you are still at this
e-address but it's the only one > I have. Briefly, I read an excellent
article you wrote about Version > 4 ISPF and I had a question. I see how
Keylists can be turned off but > the use of the Global PF keys seems to
be hit and miss. I change one > key globally and it is reflected in many
places but not in all. Am I > missing something? Thanks for the articles
and any response you may > have time to make. > > Steve Sealy > ALLTEL >
Twinsburg OH Steve, Good name. That's my son's name! Thanks for writing.
Sure, I know what your problem is. It is actually 2 different problems.
First.... Even under older ISPF releases (pre V4), PF KEY settings were
stored in each application's profile pool. What is an application in
ISPF? You cross an application boundary because the developers use the
NEWAPPL parameter of the SELECT service to launch an application.
Examples are: SDSF, File-Aid, and lots of other third-party ISPF
software. This has long been the case with ISPF. Browse your ISPF
profile dataset with the following member mask:
tsoid.ispf.profile(*PROF) to get a feel for just how many discrete
application that you have entered. Second.... In the very latest
versions of ISPF (ISPF for OS/390 02.05.00 as seen in the ZISPFOS
variable at Dialog Test option 3 (7.3)) IBM has changed the KEYLIST OFF
command to only work on an application basis. Hope this helps, Jim Moore
Concentrated Logic Inc. "Working Smarter" ------------------------------
Date: Tue, 29 Jun 1999 16:43:20 -0400 From: hoel...@us.ibm.com To:
idm...@iuassn.com Subject: DIGESTive aids Message-ID:
<8525679F.0...@d54mta03.raleigh.ibm.com> remember - it you want
to see only ONE message a day, you can request DIGEST mode - send an
email to idms-l...@iuassn.com with your request and one of your
friendly list admins (Becky Robinson or myself) un powill set you up in
digest mode! thanks, Chris Hoelscher ------------------------------
Date: Tue, 29 Jun 1999 17:05:41 -0400 From: "David R Slocum" To:
IDM...@IUASSN.COM Subject: RE: IDMS 14.0 Database Corruption Message-ID:
<8525679F.0...@pr1lns45.cpco.com> Here are the descriptions of
the temporary APARs we have applied to our system: TD67193 and TD67195 -
USER GETS A IEC131I MESSAGE FROM THE OPERATING SYSTEM WHENEVER IDMS
OPENS A FILE WITH A BLANK DDNAME. (We use a blank DD name for our IDMS
security catalog so that people can't override it and try and circumvent
internal IDMS security. See problem IDMS/1782 and IDMS/1774) TD67244 -
USER CANNOT DEALLOCATE A FILE THAT WAS NOT OPENED. ALSO, THERE ARE
VARIOUS PROBLEMS ALLOCATING AND OPENING A FILE. THE DISPLAY FILE ALSO
SHOWS THE INCORRECT SOURCE FOR THE DSNAME AND THE DISP. THIS APAR MUST
BE INSTALLED WITH TD67195 AND EITHER APAR TD67193 OR TD67194. (See
problem IDMS/1913) TD67274 - IN MULTITASKING, A USER RECEIVES A DC249002
ERROR WHEN OPENING A NATIVE VSAM FILE. THIS WILL BE FOLLOWED BY A D002
ABEND. (See problem IDMS/2035) TEAM153 - Optional APAR to bypass use of
description field for a list of authorized users. (The description for
this isn't very good. We had to apply it in order to fix a problem that
was causing DMLO to abort when used in local mode through the TSO
interface. See problem DMLO/67) TE1E094 - Task abend results in a 3970
after DC040200 message when the task exceeds its lock limit. (We didn't
have lock limits turned on, but were still asked to apply this APAR to
fix an abort in module IDMSLKGD at offset +0BEE. This problem was nasty
because CV didn't always come down completely and had to be "forced" out
of MVS. See problem IDMS/1995) TFEF027 - V SYSGEN causes destinations to
stop printing (This APAR was developed to fix a problem with adding
printers dynamically in a UCF environment using the "DCMT V SYSGEN
REFRESH LINES" command. As far as I know there isn't any problem in DC
environments. See problem IDMSDC/1711) Hope this helps! "Kaufmann,
Raymond Jr." on 06/29/99 04:36:28 PM To: David R
Slocum/Pr/Consumers/CMS@CMS cc: Subject: RE: IDMS 14.0 Database
Corruption Hi Dave I have IDMS R14 G9810 all set to move into our
production CV's on 7/18. I'm concerned with the issues you had and
temporary fixes that aren't confirmed for distribution yet. I will be
running multitasking so I would be interested in any problems you have
encountered. Testing on our Y2K LPAR didn't show any problems, but we
don't have hardly any users on it. Any information on the TD fixes would
be appreciated. Will question CA in the meantime. Thanks, Ray Kaufmann
Jostens Inc. kaufmar@jostens > -----Original Message----- > From: David
R Slocum [SMTP:drsl...@cmsenergy.com] > Sent: Tuesday, June 29, 1999
9:44 AM > To: IDM...@IUASSN.COM > Subject: Re: IDMS 14.0 Database
Corruption > > Hi Glenn, > > We've been on IDMS 14.0 (9711) for over a
year now. Some applications we > migrated from IDMS 12.0 (9601), and
others were migrated from IDMS 10.21 > (S10214). We had numerous
problems for the first month of production use. > One > of the problems
had to do with corruption in an integrated index area. We > rebuilt the
index, only to have it become corrupted again within minutes > after >
turning it back over to the clients. We ended up backing off temporary >
APAR > TD67228, but it was never confirmed that this was the problem (we
never > did > reapply the APAR). If you haven't already done so, I would
recommend > applying > all published APARs for the 9711 gen level. This
is what we did after our > first > month of production, and most of our
problems went away. There are a > number of > APARs dealing with locking
problems and multitasking. We now have all > APARs > applied up through
LO49003 and things are quite stable here. In addition > to the >
published APARs, we have the following temporary APARs applied: TD67193,
> TD67195, TD67244, TD67274, TEAM153, TE1E094, and TFEF027. We also have
a > zap > applied that circumvents a problem with multitasking and
signon retention > (usermod OZ28001 - see problem IDMSDC/1790). Hope
this helps. > > DISCLAIMER: The views expressed in this note aren't
necessarily those of > the > company. > > David R. Slocum > Consumers
Energy > drsl...@cmsenergy.com > > > > > > glenn....@ac.com on
06/29/99 09:29:10 AM > > To: idm...@iuassn.com > cc: (bcc: David R
Slocum/Pr/Consumers/CMS) > Subject: IDMS 14.0 Database Corruption > > >
> > We are running IDMS 14.0 GL9711 and have two very serious database >
corruption > problems that have caused us to lose data (something that
is new to us!) > and > wanted to know if anyone else had experienced
similar problems? > > We upgraded several production CVs from IDMS 10.2
to 14.0 in November and > December 1998. We then added additional
applications to one of the CVs at > the > end of February. > > The
multi-application CV the next business day started to get a message >
like: > > CURRENCY SAVE/RESTOREINTERNAL ERROR CODE IS 5 > RUN-UNIT
xxxxxxx NOT RECOVERED! NON-ZERO status returned from BRBK > > The
problem occurred when the system was very busy and it appeared that >
there > were rollback related problems due to deadlocks. > > We opened
an issue with CA and upon further investigation we found that > two of >
our databases had become corrupted. IDMS > had wrote records from one
area into the wrong area and even into the > other > application
database! It obviously appeared > to be an internal bug. We spent a
considerable amount of diagnostic time > review > the journals, dumps,
and logs but could > never isolate the problem (we have heard that a
similar problem has > happened > somewhere else but not resolved?). > >
CA supplied us with a patch that traps all IDMS stores to confirm that
in > fact > the record is going to the right page range. If > a problem
is found it abends the transaction with a SOC1 and snaps a dump > of it
> to the log (for diagnostic purposes). > The problem did not occur
again after the trap was implemented and the > problem > was forgotten
(the trap, according to > CA will not prevent the problem but it will
prevent the corruption from > occurring). > > In late May we implemented
two more upgraded CVs over several weekends and > the > problem occurred
again. The > problem this time presented itself as batch jobs getting
0371 error > messages but > corruption was confirmed. We again > lost
data but it was limited to only one CV and one application (it was a >
single > application CV). We did not have the trap > in these CVs since
we didn't want to introduce a problem in these new > environments. We
have subsequently added > the trap to all of our 14.0 update CVs. Again,
no further problems have > been > found. > > We believe that there is a
bug somewhere but we cannot isolate it or > replicate > it for CA to
fix. The only commonality > is that the CVs/mainframe was very busy and
batch jobs abended (due to > time-outs > or deadlocks). It appeared that
> it might be rollback related but the journals had the problem records
> going to > the wrong place so that rollback > cannot be at fault since
it only applies what is in the journal. > > We are upgrading a large
database in July and are concerned that we have > yet to > identify or
resolve this > problem. > > If you have seen this problem or a similar
problem at your site please > respond > to me (I have been working >
with IDMS since 1984 and have never seen a problem like this!). The
intent > of > this question is to solicite responses > to our problem,
not to raise flags about the product itself (since we > appear to > be
the only ones affected). We use > IDMS/DC, ADS and Cobol on OS 390 (no
CICS). > > Glenn Scott > > > > > > > ------------------------------
Date: Tue, 29 Jun 1999 15:10:32 -0600 From: "Wood, Chris" To:
IDM...@iuassn.com Subject: RE: IDMS 14.0 Database Corruption Message-ID:
<71390C47E6E8D111B36B...@eoaexc01.enr.gov.ab.ca>
Raymond, I would take a look at LI23561. It has all required apars for
14.0 and 14.1 especially MT. Chris Wood Alberta Department of Resource
Development CANADA -----Original Message----- From: David R Slocum
[mailto:drsl...@cmsenergy.com] Sent: June 29, 1999 3:06 PM To:
IDM...@iuassn.com Subject: RE: IDMS 14.0 Database Corruption Here are
the descriptions of the temporary APARs we have applied to our system:
TD67193 and TD67195 - USER GETS A IEC131I MESSAGE FROM THE OPERATING
SYSTEM WHENEVER IDMS OPENS A FILE WITH A BLANK DDNAME. (We use a blank
DD name for our IDMS security catalog so that people can't override it
and try and circumvent internal IDMS security. See problem IDMS/1782 and
IDMS/1774) TD67244 - USER CANNOT DEALLOCATE A FILE THAT WAS NOT OPENED.
ALSO, THERE ARE VARIOUS PROBLEMS ALLOCATING AND OPENING A FILE. THE
DISPLAY FILE ALSO SHOWS THE INCORRECT SOURCE FOR THE DSNAME AND THE
DISP. THIS APAR MUST BE INSTALLED WITH TD67195 AND EITHER APAR TD67193
OR TD67194. (See problem IDMS/1913) TD67274 - IN MULTITASKING, A USER
RECEIVES A DC249002 ERROR WHEN OPENING A NATIVE VSAM FILE. THIS WILL BE
FOLLOWED BY A D002 ABEND. (See problem IDMS/2035) TEAM153 - Optional
APAR to bypass use of description field for a list of authorized users.
(The description for this isn't very good. We had to apply it in order
to fix a problem that was causing DMLO to abort when used in local mode
through the TSO interface. See problem DMLO/67) TE1E094 - Task abend
results in a 3970 after DC040200 message when the task exceeds its lock
limit. (We didn't have lock limits turned on, but were still asked to
apply this APAR to fix an abort in module IDMSLKGD at offset +0BEE. This
problem was nasty because CV didn't always come down completely and had
to be "forced" out of MVS. See problem IDMS/1995) TFEF027 - V SYSGEN
causes destinations to stop printing (This APAR was developed to fix a
problem with adding printers dynamically in a UCF environment using the
"DCMT V SYSGEN REFRESH LINES" command. As far as I know there isn't any
problem in DC environments. See problem IDMSDC/1711) Hope this helps!
"Kaufmann, Raymond Jr." on 06/29/99 04:36:28 PM To: David R
Slocum/Pr/Consumers/CMS@CMS cc: Subject: RE: IDMS 14.0 Database
Corruption Hi Dave I have IDMS R14 G9810 all set to move into our
production CV's on 7/18. I'm concerned with the issues you had and
temporary fixes that aren't confirmed for distribution yet. I will be
running multitasking so I would be interested in any problems you have
encountered. Testing on our Y2K LPAR didn't show any problems, but we
don't have hardly any users on it. Any information on the TD fixes would
be appreciated. Will question CA in the meantime. Thanks, Ray Kaufmann
Jostens Inc. kaufmar@jostens > -----Original Message----- > From: David
R Slocum [SMTP:drsl...@cmsenergy.com] > Sent: Tuesday, June 29, 1999
9:44 AM > To: IDM...@IUASSN.COM > Subject: Re: IDMS 14.0 Database
Corruption > > Hi Glenn, > > We've been on IDMS 14.0 (9711) for over a
year now. Some applications we > migrated from IDMS 12.0 (9601), and
others were migrated from IDMS 10.21 > (S10214). We had numerous
problems for the first month of production use. > One > of the problems
had to do with corruption in an integrated index area. We > rebuilt the
index, only to have it become corrupted again within minutes > after >
turning it back over to the clients. We ended up backing off temporary >
APAR > TD67228, but it was never confirmed that this was the problem (we
never > did > reapply the APAR). If you haven't already done so, I would
recommend > applying > all published APARs for the 9711 gen level. This
is what we did after our > first > month of production, and most of our
problems went away. There are a > number of > APARs dealing with locking
problems and multitasking. We now have all > APARs > applied up through
LO49003 and things are quite stable here. In addition > to the >
published APARs, we have the following temporary APARs applied: TD67193,
> TD67195, TD67244, TD67274, TEAM153, TE1E094, and TFEF027. We also have
a > zap > applied that circumvents a problem with multitasking and
signon retention > (usermod OZ28001 - see problem IDMSDC/1790). Hope
this helps. > > DISCLAIMER: The views expressed in this note aren't
necessarily those of > the > company. > > David R. Slocum > Consumers
Energy > drsl...@cmsenergy.com > > > > > > glenn....@ac.com on
06/29/99 09:29:10 AM > > To: idm...@iuassn.com > cc: (bcc: David R
Slocum/Pr/Consumers/CMS) > Subject: IDMS 14.0 Database Corruption > > >
> > We are running IDMS 14.0 GL9711 and have two very serious database >
corruption > problems that have caused us to lose data (something that
is new to us!) > and > wanted to know if anyone else had experienced
similar problems? > > We upgraded several production CVs from IDMS 10.2
to 14.0 in November and > December 1998. We then added additional
applications to one of the CVs at > the > end of February. > > The
multi-application CV the next business day started to get a message >
like: > > CURRENCY SAVE/RESTOREINTERNAL ERROR CODE IS 5 > RUN-UNIT
xxxxxxx NOT RECOVERED! NON-ZERO status returned from BRBK > > The
problem occurred when the system was very busy and it appeared that >
there > were rollback related problems due to deadlocks. > > We opened
an issue with CA and upon further investigation we found that > two of >
our databases had become corrupted. IDMS > had wrote records from one
area into the wrong area and even into the > other > application
database! It obviously appeared > to be an internal bug. We spent a
considerable amount of diagnostic time > review > the journals, dumps,
and logs but could > never isolate the problem (we have heard that a
similar problem has > happened > somewhere else but not resolved?). > >
CA supplied us with a patch that traps all IDMS stores to confirm that
in > fact > the record is going to the right page range. If > a problem
is found it abends the transaction with a SOC1 and snaps a dump > of it
> to the log (for diagnostic purposes). > The problem did not occur
again after the trap was implemented and the > problem > was forgotten
(the trap, according to > CA will not prevent the problem but it will
prevent the corruption from > occurring). > > In late May we implemented
two more upgraded CVs over several weekends and > the > problem occurred
again. The > problem this time presented itself as batch jobs getting
0371 error > messages but > corruption was confirmed. We again > lost
data but it was limited to only one CV and one application (it was a >
single > application CV). We did not have the trap > in these CVs since
we didn't want to introduce a problem in these new > environments. We
have subsequently added > the trap to all of our 14.0 update CVs. Again,
no further problems have > been > found. > > We believe that there is a
bug somewhere but we cannot isolate it or > replicate > it for CA to
fix. The only commonality > is that the CVs/mainframe was very busy and
batch jobs abended (due to > time-outs > or deadlocks). It appeared that
> it might be rollback related but the journals had the problem records
> going to > the wrong place so that rollback > cannot be at fault since
it only applies what is in the journal. > > We are upgrading a large
database in July and are concerned that we have > yet to > identify or
resolve this > problem. > > If you have seen this problem or a similar
problem at your site please > respond > to me (I have been working >
with IDMS since 1984 and have never seen a problem like this!). The
intent > of > this question is to solicite responses > to our problem,
not to raise flags about the product itself (since we > appear to > be
the only ones affected). We use > IDMS/DC, ADS and Cobol on OS 390 (no
CICS). > > Glenn Scott > > > > > > > ------------------------------
Date: Wed, 30 Jun 1999 09:16:07 +1000 From: Willem Oudyk To:
idm...@iuassn.com Subject: Fwd: RE: idms-l list policy change
Message-ID: <4.1.199906300...@pangaea.nu> I agree with all of
this as well !!!
X-POP3-Rcpt: willem@wxo
From: "Shaw, Brock" <brock...@MBUK.Mercedes-Benz.com>
To: "IDMS-L (List) (E-mail)" <idm...@iuassn.com>
Subject: RE: idms-l list policy change
Date: Tue, 29 Jun 1999 16:18:10 +0100
X-Mailer: Internet Mail Service (5.5.2448.0)
I have to say that there is a problem whichever way the policy of
reply-to is set.
If it is set to the list, then all communications which are sent as a
"reply" in the email system (outlook or whatever) go to the list - even
personal comments to other individuals.
If instead, reply goes to the person who sent the message (as the policy
now makes it), then only that person receives the response, answer,
solution, comment or whatever. This seriously impairs the list in doing
what it is supposed to do - viz communicate!
Over the last few months of the UGA hosting, we got half the story or
less in many cases because of the reply only going to the individual.
It was seen as a benefit to the new IUA hosting that we would be able to
generate a bit more email, but see all the relevant mail.
In view of this, I think it is helpful to change the reply policy back
to being the list, and for each person simply to remember that personal
comments and conversations are more appropriately made directly, not
through the list. It is easy to change the reply to when we know we
want to make a personal message. It is still not the end of the world
if someone forgets once in a while, but the default should be to the
list. But missing the information could be important!
Best regards,
Brock.
Brock Shaw, DBA (ISD)
Mercedes Benz (UK), England
-----Original Message-----
From: Rick L. Garvin [mailto:r...@ksu.edu]
Sent: 29 June 1999 15:49
To: IDM...@IUASSN.COM
Subject: Re: idms-l list policy change
I totaly agree!!!!!!!!!!!!!!!!!!
Jerry Fica wrote:
>
> I am totally dismayed that anyone would be so offended by the extra
posts to
> the list. They are certainly irritating but the delete key works
extremely
> well on my mail client, so guess what I delete them and read the
important
> stuff.
>
> Just my two cents about restricting replies to the sender. I think
there is
> a tremendous loss to the rest of the list when that happens, and I
would
> encourage the list to keep the replies going to the complete
list........
>
> Jerry Fica
>
-------------------------------------------------
Willem Oudyk
14 Fortescue Grove
Vermont Sth. Victoria 3133
Australia Ph/Fax: +61 (3) 9887 9121
Email:wil...@pangaea.nu
Web:www.pangaea.nu
-------------------------------------------------
------------------------------
End of IDMS-L V1 #11
********************
Chris Hoelscher
Number 12
In this issue:
badge-to-home?
RE: badge-to-home?
IDMS 14.0 Database Corruption - Follow-up
IDMS 14.0 & XADC
Re:IDMS 14.0 Database Corruption
R140 Corruption
Prefetch Corruption?
RE:R140 Corruption
raise your hands: who is experiencing LU6.2 problems in IDMS?
Overflow and IDMSDBAN
RE: Overflow and IDMSDBAN
RE: Overflow and IDMSDBAN
IDMS 14.0 & XADC - Response
RE:IDMS 14.0 & XADC - Response
RE: IDMS 14.0 & XADC - Response
Prefetch Corruption? -Reply
RE: IDMS 14.0 Database Corruption - Follow-up
make the old listmaster's job a little easier
R140 Corruption
----------------------------------------------------------------------
Date: Wed, 30 Jun 1999 09:35:23 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: badge-to-home?
Message-ID: <852567A0.0...@d54mta03.raleigh.ibm.com>
Did anyone encounter problems with the badge-to-home program this year?
I NEVER
got mine and CA says I will need to pick it up onsite! I was just
curious to see
if this was widespread or isolated.
thanks,
Chris Hoelscher
Sophisticated Business Systems
Dallas Texas
On Assignment to IBM Global Services
Outsourcers for GE Capital Cooporation
------------------------------
Date: Wed, 30 Jun 1999 09:05:24 -0500
From: "Rice, James L. Jim" <JLR...@southernco.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: badge-to-home?
Message-ID:
<F3E06C56DE75D211B3A...@GAXGPEX23.southernco.com>
I haven't received mine yet either.
> -----Original Message-----
> From: hoel...@us.ibm.com [SMTP:hoel...@us.ibm.com]
> Sent: Wednesday, June 30, 1999 9:35 AM
> To: idm...@iuassn.com
> Subject: badge-to-home?
>
>
>
>
> Did anyone encounter problems with the badge-to-home program this
year? I
> NEVER
> got mine and CA says I will need to pick it up onsite! I was just
curious
> to see
> if this was widespread or isolated.
>
> thanks,
> Chris Hoelscher
> Sophisticated Business Systems
> Dallas Texas
> On Assignment to IBM Global Services
> Outsourcers for GE Capital Cooporation
>
------------------------------
Date: Wed, 30 Jun 1999 10:48:01 -0400
From: glenn....@ac.com
To: idm...@iuassn.com
Subject: IDMS 14.0 Database Corruption - Follow-up
Message-ID: <862567A0.0...@amrhm1101.ac.com>
Thanks to all who have responded and have added some suggestions ... it
never
hurts
(which is exactly what this list is for ... thanks again Chris),
I have come to learn that we are not alone (I actually now have a list
of
problem sites that all want to be kept abreast
of any progress ... united we stand!). Attached below are some of the
replies I
have gotten without their addresses to
protect them.
What I am amazed at is how many IDMS shops are experiencing 14.0 data
corruption
problems with apparently
different scenerios affecting both databases and queue records. I
honestly
cannot remember when the last
time we ever had a database corruption problem and I have been working
with IDMS
since 1984. We have
lost data before but due to database (all right ... DBA errors) and
application
errors. The problems that
the collective "we" are experiencing appear to be deep within the code
and all
we can do is to implement
traps hoping to debug the problem (something are clients are not exactly
happy
with!) .......
We are aware of a potential prefetch problem (and yes CA won't admit
that there
is a problem although they SUGGESTED
we turn it off ....). What about your online performance without
prefetch? We
used a product from Allen Systems called
XA/DC that was essential in providing optimum online performance in
10.21 since
it allowed buffers above the line and was
"smart" in detecting an area sweeps. They have not upgraded the product
to 14.0
from 12.0 since pre-fetch had been
implemented (and was essentially the same). We are now left with only
prefetch
as a option (and cannot use it!).
I am sending this back through the list server since others may have
additional
comments .....
Thanks again for your feedback!
Glenn Scott
=========================================================================================
Hello Glenn:
After installing GJ9711 & applying GJ9810 maintenance to our release
14.0
systems we started experiencing database corruption.
We tracked it down to PREFETCH, but we can't get CA to admit that there
is a
problem. It appeared to occur whenever something did a rollback. We have
turned PREFETCH off for three weeks now and have not had a single broken
chain. We run 600 pages in all of our buffers so PREFETCH was on by
default,
we also run multitasking.
We turned PREFETCH off by using SYSIDMS, we do not allow any PREFETCH
now,
and we have not had a single problem.
========================================================================================================
Hi Glenn,
========================================================================================================
Glenn, we have been running 14.0 in production (20 CV's) for about a
year. Back
in January, we had a problem that reads exactly like TD67279 - except
that the
recovery of the database was NOT recovered and we had broken chains.
We opened an issue with CA - but unfortunately didn't get anywere -
mainly
because we were unable to supply them any useful information. (I was on
vacation
at the time and by the time I returned the info was gone).
None of our CV's are what I'd call busy and the problem has only
occurred the
once.
I know it's not much help, but that's all the information I have.
===============================================================================
Glenn -
------------------------------
Date: Wed, 30 Jun 1999 10:12:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: idm...@iuassn.com
Subject: IDMS 14.0 & XADC
Message-ID: <NZ40c002...@bfi.com>
> What about your online performance without prefetch? We used a product
> from Allen Systems called XA/DC that was essential in providing
optimum
> online performance in 10.21 since it allowed buffers above the line
and
> was "smart" in detecting an area sweeps. They have not upgraded the
> product to 14.0 from 12.0 since pre-fetch had been implemented (and
was
> essentially the same). We are now left with only prefetch as a option
> (and cannot use it!).
It is true that Allen Systems did not upgrade XADC to make it compatible
with IDMS 14.0, however, they have another product called Fast-Access
which
does the same thing, and it *is* 14.0 compatible. So if you still want
that functionality, you have to switch your XADC license to Fast-Access,
and then change your jobs and systems to use Fast-Access.
As we got into this process, we found that we could make the few jobs
that we had that were previously running with IDMS 12.0 XADC, run just
as
fast with native IDMS 14.0 buffer tuning features, like prefetch and
other
options. So as it turns out we no longer had the need for even
Fast-Access.
It took a lot of experimenting to reach that point though, and it would
be
easier to just slap the Fast-Access loadlib into the JCL. :-)
John Rich
Browning-Ferris Industries
------------------------------
Date: Wed, 30 Jun 1999 10:21:00 -0500
From: ("John Rich RR") <John...@bfi.com>
Subject: Re:IDMS 14.0 Database Corruption
Message-ID: <NZc54973...@bfi.com>
> I have come to learn that we are not alone (I actually now have a list
of
> problem sites that all want to be kept abreast of any progress ...
united
> we stand!).
I'll throw my hat into this ring too.
I have just finished converting nine IDMS systems with about 30 schemas
from IDMS 12.0 to 14.0, over a period of the last several months. We've
had one corruption problem, where a Calc record ended up outside the
calc
chain. You could retrieve the record by db-key, or by area-sweep, but
not
with the calc key. A DBA had to Pfix the page to patch-up the chain and
get
that record back in service. We don't have a clue how it got this way,
and
that makes me a bit nervous.
I did have prefetch active in that CV system, and am now considering
disabling it...
John Rich
Browning-Ferris Industries
------------------------------
Date: Wed, 30 Jun 1999 11:41:32 -0400
From: "Canon, Hartman" <hartma...@lmco.com>
To: "'IDMS-L Submission'" <IDM...@IUASSN.COM>
Subject: R140 Corruption
Message-ID:
<60875A437C39D211BE86...@emss03m03.orl.lmco.com>
I am following today's posts on R14.0 with great interest. We have been
100%
on the 9610 tape for over a year, and have not experienced any of these
problems to date. Some of the posts mention the 9711 tape explicity.
Some of
them do NOT mention a tape at all. It would be REAL information IF, when
relating about a problem of such potential magnitude that the TAPE be
specified in each and every case. Some of us might be more prone to
heart
attacks than others.
Hartman B. Canon
Lockheed-Martin
------------------------------
Date: Wed, 30 Jun 1999 10:43:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: idm...@iuassn.com
Subject: Prefetch Corruption?
Message-ID: <NZ239e57...@bfi.com>
Regarding the possibility of corruption due to the prefetch option, I
just
noticed the following
brand spanking new hyper Apar:
APAR #: LO49861 DATE: 4 JUN 1999
PROBLEM DESCRIPTION: IF MULTIPLE BATCH UTILITIES ARE RUN WITHIN THE
SAME BATCH JOBSTEP AND PREFETCH IS ENABLED
IT
IS
POSSIBLE THAT THE FIRST PAGE OF AN AREA
WILL
OVERLAY A LATER PAGE IN THE AREA WHEN THAT AREA
IS
UNLOCKED AT THE END OF THE JOBSTEP.
HYPER: YES
John Rich
Browning-Ferris Industries
------------------------------
Date: Wed, 30 Jun 1999 10:47:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: hartma...@lmco.com
Cc: (IDMS-L Submission) <IDM...@IUASSN.COM>
Subject: RE:R140 Corruption
Message-ID: <NY789979...@bfi.com>
> It would be REAL information IF, when relating about a problem of such
> potential magnitude that the TAPE be specified in each and every case.
You are correct, and I am one of the guilty parties. All of my IDMS
14.0
systems are at genlevel 9810.
John Rich
------------------------------
Date: Wed, 30 Jun 1999 12:04:08 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: raise your hands: who is experiencing LU6.2 problems in IDMS?
Message-ID: <852567A0.0...@d54mta03.raleigh.ibm.com>
my client has invensted a MAJOR portion if its business (58 regions,
20+million
trans/day) in idms and specifically in LU6.2 communications protocol
(idms<->idms, idms<->cics, idms<->AS400, idms<->PCs (via xcom), etc.
Since going
to 12.01, this client has had continual problems with LU62. This client
would
like to talk to other clients that have or had problems with lu6.2 - if
HAD is
the operative word, how did you solve them; if HAVE is the operative
word, what
are you doing about it. for obvious reasons, if you could reply to me
directly
if you are willing to discuss this with my client (or at least with me
and i
will feed the info to my client)
thanks a million,(or is that 20 million)
Chris Hoelscher
------------------------------
Date: Wed, 30 Jun 1999 10:32:09 -0700
From: Kim_Th...@ci.sf.ca.us
To: idm...@iuassn.com
Subject: Overflow and IDMSDBAN
Message-ID: <000BA84...@ci.sf.ca.us>
In the 12.01 documentation on overflow, it states IDMSDBAN can be
used
to determine the total number of overflows in a database. However,
I
don't see any overflow information on the reports? Am I missing
something? Is there any other utility I can run against a database
to
find out the extent of calc and via overflow on an area basis? I
am
aware of the system and journal reports that contain overflow
stats,
but I need the information by area. We have a client who is
concerned
about I/O costs and wants us to reload their entire database unless
we
can show areas that will not benefit much from being rebuilt.
TIA - Kim Thompson
City and County of SF
------------------------------
Date: Wed, 30 Jun 1999 12:43:19 -0500
From: Michael Newman <Michae...@soph.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Overflow and IDMSDBAN
Message-ID: <014CEBE84B9BD2118FFB0008C74C5E3C28A8@GRNSBORO>
The set analysis portion of DBAN will give you the info that you want.
The number of page changes for the CALC set, or the other sets in the
area will indicate the amount of overflow. If the set is not a via set,
then obviously the number of page changes will be meanings (calc to calc
set, or the member record is stored via another set).
Michael A. Newman
Sophisticated Business Systems, Inc.
101 CentrePort Drive, Suite 310
Greensboro, NC 27409
E-Mail: Michae...@soph.com
Phone: 336.605.4771 Ext. 116
Fax: 336.605.4772
-----Original Message-----
From: Kim_Th...@ci.sf.ca.us
[mailto:Kim_Th...@ci.sf.ca.us]
Sent: Wednesday, June 30, 1999 1:32 PM
To: idm...@iuassn.com
Subject: Overflow and IDMSDBAN
In the 12.01 documentation on overflow, it states
IDMSDBAN can be used
to determine the total number of overflows in a
database. However, I
don't see any overflow information on the reports?
Am I missing
something? Is there any other utility I can run
against a database to
find out the extent of calc and via overflow on an
area basis? I am
aware of the system and journal reports that
contain overflow stats,
but I need the information by area. We have a
client who is concerned
about I/O costs and wants us to reload their entire
database unless we
can show areas that will not benefit much from
being rebuilt.
TIA - Kim Thompson
City and County of SF
------------------------------
Date: Wed, 30 Jun 1999 13:48:19 -0400
From: "Fenton, Thomas C" <thomas....@lmco.com>
To: "'IDMS-L'" <idm...@iuassn.com>
Subject: RE: Overflow and IDMSDBAN
Message-ID:
<4B55904D9AC9D1119BA...@emss04m10.ems.lmco.com>
Kim,
You need to look at report # 5 output from DBAN, specifically the number
of
pages required to contain the sets, and the number of page changes per
set.
You can just request the CALC set if that's the only one you are
concerned
with.
Tom
Tom Fenton
Database & Information Engineering, NE
PAR Technology Park
8373 Seneca Turnpike, New Hartford, NY 13413
(315) 793-5772 fax (315) 793-5706
Pager 1-888-562-8398 Pin # 147-2425
> ----------
> From: Kim_Th...@ci.sf.ca.us[SMTP:Kim_Th...@ci.sf.ca.us]
> Sent: Wednesday, June 30, 1999 1:32 PM
> To: idm...@iuassn.com
> Subject: Overflow and IDMSDBAN
>
> In the 12.01 documentation on overflow, it states IDMSDBAN can be
> used
> to determine the total number of overflows in a database.
However, I
>
> don't see any overflow information on the reports? Am I missing
> something? Is there any other utility I can run against a
database
> to
> find out the extent of calc and via overflow on an area basis? I
am
> aware of the system and journal reports that contain overflow
stats,
> but I need the information by area. We have a client who is
> concerned
> about I/O costs and wants us to reload their entire database
unless
> we
> can show areas that will not benefit much from being rebuilt.
>
> TIA - Kim Thompson
> City and County of SF
>
------------------------------
Date: Wed, 30 Jun 1999 14:07:05 -0400
From: glenn....@ac.com
To: idm...@iuassn.com
Subject: IDMS 14.0 & XADC - Response
Message-ID: <862567A0.0...@amrhm1101.ac.com>
This topic has certainly generated some mail! It even exceeds the
"default
respond to" issue!
To others who have asked about the IDMS 14.0 release ... We are at
GL9711 and
are upgrading to GL9810
at the end of the summer (we are using it now in our test LPAR).
We have a trial license of Fast Access but it is only for LOCAL mode
batch jobs.
They do NOT have
a DC version available (like XA/DC). We relied heavily on the XA/DC
product
under 10.2 to help with
some "less than ideal" cv-mode reporting (like culprit!).
Glenn Scott
("John Rich RR") John...@bfi.com
06/30/99 03:12 PM GMT
To: idm...@iuassn.com
cc: (bcc: Glenn A. Scott)
Subject: IDMS 14.0 & XADC
> What about your online performance without prefetch? We used a product
> from Allen Systems called XA/DC that was essential in providing
optimum
> online performance in 10.21 since it allowed buffers above the line
and
> was "smart" in detecting an area sweeps. They have not upgraded the
> product to 14.0 from 12.0 since pre-fetch had been implemented (and
was
> essentially the same). We are now left with only prefetch as a option
> (and cannot use it!).
It is true that Allen Systems did not upgrade XADC to make it compatible
with IDMS 14.0, however, they have another product called Fast-Access
which
does the same thing, and it *is* 14.0 compatible. So if you still want
that functionality, you have to switch your XADC license to Fast-Access,
and then change your jobs and systems to use Fast-Access.
As we got into this process, we found that we could make the few jobs
that we had that were previously running with IDMS 12.0 XADC, run just
as
fast with native IDMS 14.0 buffer tuning features, like prefetch and
other
options. So as it turns out we no longer had the need for even
Fast-Access.
It took a lot of experimenting to reach that point though, and it would
be
easier to just slap the Fast-Access loadlib into the JCL. :-)
------------------------------
Date: Wed, 30 Jun 1999 14:12:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: glenn....@ac.com
Cc: idm...@iuassn.com
Subject: RE:IDMS 14.0 & XADC - Response
Message-ID: <NY77c421...@bfi.com>
> We have a trial license of Fast Access but it is only for LOCAL mode
batch
> jobs. They do NOT have a DC version available (like XA/DC). We relied
> heavily on the XA/DC product under 10.2 to help with some "less than
ideal"
> cv-mode reporting (like culprit!).
IDMS 14.0, vs. IDMS 10.2, has some robust features for tuning your
buffering
in CV-mode, very much like what XADC used to do for you. In effect,
since
you can now define large buffers in XA memory directly with IDMS, you
don't
need XADC/Fast-Access hooked into the CV system any more.
Why are you running Culprit in CV-mode? Since it is by definition a
retrieval-only reporting tool, local-mode seems like the way to go...
John Rich
------------------------------
Date: Wed, 30 Jun 1999 13:37:55 -0600
From: "Wood, Chris" <Chris...@gov.ab.ca>
To: idm...@iuassn.com
Subject: RE: IDMS 14.0 & XADC - Response
Message-ID:
<71390C47E6E8D111B36B...@eoaexc01.enr.gov.ab.ca>
John,
Remember that CULPRIT can call SQL so even though you may run it in
LOCAL it
will ready areas as the subschema it is using is defined. We had to
change
CULPRIT to use a read-only subschema then you can run it as LOCAL MODE.
Chris Wood
Alberta department of resource Development
CANADA
-----Original Message-----
From: John.Rich [mailto:John...@bfi.com]
Sent: June 30, 1999 1:12 PM
To: glenn....@ac.com
Cc: idm...@iuassn.com
Subject: RE:IDMS 14.0 & XADC - Response
> We have a trial license of Fast Access but it is only for LOCAL mode
batch
> jobs. They do NOT have a DC version available (like XA/DC). We relied
> heavily on the XA/DC product under 10.2 to help with some "less than
ideal"
> cv-mode reporting (like culprit!).
IDMS 14.0, vs. IDMS 10.2, has some robust features for tuning your
buffering
in CV-mode, very much like what XADC used to do for you. In effect,
since
you can now define large buffers in XA memory directly with IDMS, you
don't
need XADC/Fast-Access hooked into the CV system any more.
Why are you running Culprit in CV-mode? Since it is by definition a
retrieval-only reporting tool, local-mode seems like the way to go...
John Rich
------------------------------
Date: Wed, 30 Jun 1999 15:18:47 -0500
From: "EDWARD TIMM" <ET...@usagroup.com>
To: IDM...@IUASSN.COM
Subject: Prefetch Corruption? -Reply
Message-ID: <s77a35...@usagroup.com>
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=_89DFC9D7.D8B9DD8D
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
This APAR LO49861 (for rel 14.0) is "CODED HYPER=3DYES" and has been
on =
TCCSTAR (since early June). Other HYPER=3DYES APAR's for (9811)
LO49768, =
LO46430, LO44429, LO44381, LO44380). For 14.1 (9811) HYPER=3DYES
APAR's =
LO49863, LO46433. =20
Also interesting APAR to use Read AHEAD I/O.
++USERMOD (TE1E150) /* (To my understanding this could overlay of =
storage) =20
PROGRAM CHECK IN IDMSDBIO WHEN USING READ DRIVERS. WHEN USING READ =
DRIVERS, IT IS POSSIBLE FOR THE IDMSDBIO TO GET A PROGRAM CHECK IN THE =
SUBMODULE IDMSDBID DUE TO AN INCORRECT REGISTER BEING USED TO CLEAR A =
STORAGE LOCATION. THIS SOLUTION CORRECTS THE REGISTER
USAGE. =
=20
=20
Also many other APAR's that are quite serious. Our APAR procedures is
to =
attempt to apply the LOxxxxx APAR's at least once a week. First to =
development and UAT then Production. We would rather have and LOxxxxx =
APAR on than experience a "KNOWN" problem. =20
The 14.1 equivalent for LO49861 is LO49863.=20
For older releases (rel 14.0) look at LO31937 for queue problems being =
corrupted.
Edward A. Timm
USA GROUP
Indianapolis, IN.
>>> "John Rich RR" <John...@bfi.com> 99/06/30 10:43 am >>>
Regarding the possibility of corruption due to the prefetch option, I
just
noticed the following
brand spanking new hyper Apar:
APAR #: LO49861 DATE: 4 JUN 1999
PROBLEM DESCRIPTION: IF MULTIPLE BATCH UTILITIES ARE RUN WITHIN THE
SAME BATCH JOBSTEP AND PREFETCH IS ENABLED
=
IT
IS
POSSIBLE THAT THE FIRST PAGE OF AN AREA =
WILL
OVERLAY A LATER PAGE IN THE AREA WHEN THAT AREA
=
IS
UNLOCKED AT THE END OF THE JOBSTEP.
HYPER: YES
John Rich
Browning-Ferris Industries
--=_89DFC9D7.D8B9DD8D
Content-Type: message/rfc822
Received: from fshsun01.usagroup.com
([192.168.7.34])
by usagroup.com; Wed, 30 Jun 1999 10:48:53 -0500
Received: from loghost.usagroup.com (vulture.usagroup.com
[192.168.6.66])
by fshsun01.usagroup.com (8.9.1/8.9.1) with ESMTP id KAA17843;
Wed, 30 Jun 1999 10:48:52 -0500 (EST)
Received: from syncronicity.syncronicity.net (www.syncronicity.net
[206.168.112.84] (may be forged))
by loghost.usagroup.com (8.9.1/8.9.1) with ESMTP id KAA27005;
Wed, 30 Jun 1999 10:47:28 -0500
Received: from c-mail01.bfi.com (defiant.bfi.com [198.203.164.100])
by syncronicity.syncronicity.net (Post.Office MTA v3.1.2
release (PO205-101c) ID# 0-44991U2500L250S0) with ESMTP id
AAA210
for <idm...@iuassn.com>; Wed, 30 Jun 1999 09:49:49 -0600
Received: from bfi.com (10.30.250.21) by c-mail01.bfi.com (NPlex
2.0.108) for idm...@iuassn.com; 30 Jun 1999 10:46:09 -0500
X-Internal-ID: 3769C327000245A5
Message-ID: <NZ239e57...@bfi.com>
Date: Wed, 30 Jun 1999 10:43:00 -0500
From: ("John Rich RR") <John...@bfi.com>
Subject: Prefetch Corruption?
To: idm...@iuassn.com
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Regarding the possibility of corruption due to the prefetch option, I
just
noticed the following
brand spanking new hyper Apar:
APAR #: LO49861 DATE: 4 JUN 1999
PROBLEM DESCRIPTION: IF MULTIPLE BATCH UTILITIES ARE RUN WITHIN THE
SAME BATCH JOBSTEP AND PREFETCH IS ENABLED
=
IT
IS
POSSIBLE THAT THE FIRST PAGE OF AN AREA =
WILL
OVERLAY A LATER PAGE IN THE AREA WHEN THAT AREA
=
IS
UNLOCKED AT THE END OF THE JOBSTEP.
HYPER: YES
John Rich
Browning-Ferris Industries
--=_89DFC9D7.D8B9DD8D--
------------------------------
Date: Thu, 1 Jul 1999 08:19:00 +1000
From: "Pelly, Gabriel [IBM GSA]" <GPe...@vitgaxis.telstra.com.au>
To: idm...@iuassn.com
Subject: RE: IDMS 14.0 Database Corruption - Follow-up
Message-ID: <1999063022...@mail.cdn.telstra.com.au>
Glenn,
Another product, also from Allen Systems, is FAST ACCESS, it acts
similarly
to PREFETCH. As you would expect it has more control parameters than the
ON/OFF Prefetch type parameters.
While the doco talks about local-mode, it should also work in CVmode. I
have
not tested this.
Anyway, something to consider.
Cheers
Gabriel Pelly
----------
From: glenn....@ac.com
To: idm...@iuassn.com
Subject: IDMS 14.0 Database Corruption - Follow-up
Date: Thursday, 1 July 1999 0:48pm
Thanks to all who have responded and have added some suggestions ... it
never
hurts
(which is exactly what this list is for ... thanks again Chris),
I have come to learn that we are not alone (I actually now have a list
of
problem sites that all want to be kept abreast
of any progress ... united we stand!). Attached below are some of the
replies I
have gotten without their addresses to
protect them.
What I am amazed at is how many IDMS shops are experiencing 14.0 data
corruption
problems with apparently
different scenerios affecting both databases and queue records. I
honestly
cannot remember when the last
time we ever had a database corruption problem and I have been working
with
IDMS
since 1984. We have
lost data before but due to database (all right ... DBA errors) and
application
errors. The problems that
the collective "we" are experiencing appear to be deep within the code
and
all
we can do is to implement
traps hoping to debug the problem (something are clients are not exactly
happy
with!) .......
We are aware of a potential prefetch problem (and yes CA won't admit
that
there
is a problem although they SUGGESTED
we turn it off ....). What about your online performance without
prefetch?
We
used a product from Allen Systems called
XA/DC that was essential in providing optimum online performance in
10.21
since
it allowed buffers above the line and was
"smart" in detecting an area sweeps. They have not upgraded the product
to
14.0
from 12.0 since pre-fetch had been
implemented (and was essentially the same). We are now left with only
prefetch
as a option (and cannot use it!).
I am sending this back through the list server since others may have
additional
comments .....
Thanks again for your feedback!
Glenn Scott
============================================================================
=============
Hello Glenn:
After installing GJ9711 & applying GJ9810 maintenance to our release
14.0
systems we started experiencing database corruption.
We tracked it down to PREFETCH, but we can't get CA to admit that there
is a
problem. It appeared to occur whenever something did a rollback. We have
turned PREFETCH off for three weeks now and have not had a single broken
chain. We run 600 pages in all of our buffers so PREFETCH was on by
default,
we also run multitasking.
We turned PREFETCH off by using SYSIDMS, we do not allow any PREFETCH
now,
and we have not had a single problem.
============================================================================
============================
Hi Glenn,
============================================================================
============================
Glenn, we have been running 14.0 in production (20 CV's) for about a
year.
Back
in January, we had a problem that reads exactly like TD67279 - except
that
the
recovery of the database was NOT recovered and we had broken chains.
We opened an issue with CA - but unfortunately didn't get anywere -
mainly
because we were unable to supply them any useful information. (I was on
vacation
at the time and by the time I returned the info was gone).
None of our CV's are what I'd call busy and the problem has only
occurred
the
once.
I know it's not much help, but that's all the information I have.
============================================================================
===
Glenn -
mostly
two?
------------------------------
Date: Wed, 30 Jun 1999 16:28:58 -0500
From: Chris Hoelscher <hoel...@flash.net>
To: idm...@iuassn.com
Subject: make the old listmaster's job a little easier
Message-ID: <1999063022...@ares.flash.net>
a humble request from one of your listmasters. If your email profile (or
the server as a whole) defaults to requesting a return receipt, *PLEASE
TURN IT OFF* for every message that gets posted to the list with a
return
receipt requested, Becky and I get quite a few (500+) emails in OUR
inbox
(thankfully, the receipts are deflected from the list into the
list-owners'
inbox). We will be contacting the original posters of the mail which
requested return receipt, but for now, make sure that you do not
(un)intentionally post to idms-l with a return receipt requested.
thanks,
Chris Hoelscher
------------------------------
Date: Wed, 30 Jun 1999 11:50:40 -0400 (EDT)
From: del barlett <dbar...@ets.org>
To: idm...@iuassn.com
Subject: R140 Corruption
Message-ID: <vines.Oh...@cips06.ets.org>
I also have a questions for those with R14.x data corruption problems.
Those of you experiencing corruption:
did you have PRE-FETCH turned on or off??
were you using MT or not??
was it only in heavy batch updates or were there other situations??
For my own mind, just trying to isolate the environment and
circumstances.
Thanks,
Del Barlett
ETS
Princeton,NJ
609-734-5941
dbar...@ets.org
------------------------------
End of IDMS-L V1 #12
********************
Chris Hoelscher
Number 13
In this issue:
RE: please check out WWW.IUASSN.COM
IDMS 14.1 and ESA
Upgrading to 14.1 from 12.0 on os390
a solution!
RE: a solution!
RE: a solution!
RE: a solution!
----------------------------------------------------------------------
Date: Thu, 1 Jul 1999 10:04:42 +0100
From: "Shaw, Brock" <brock...@MBUK.Mercedes-Benz.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: please check out WWW.IUASSN.COM
Message-ID: <81C700BB8A25D3119EE50010E360DAC6087A1B@S184EXC3>
This message is in MIME format. Since your mail reader does not
understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BEC3A0.6AB3EBF4
Content-Type: text/plain;
charset="iso-8859-1"
Chris,
When I try to get into any of the links on the left side of the main
page,
it asks me for a userid and password. Is this expected? (I am trying
to
get the local server to update their cross-reference too. Meantime I am
still using the numerical IP address.)
Brock.
Brock Shaw, DBA (ISD)
Mercedes Benz (UK), England
-----Original Message-----
From: hoel...@us.ibm.com [mailto:hoel...@us.ibm.com]
Sent: 28 June 1999 15:05
To: idm...@iuassn.com
Subject: please check out WWW.IUASSN.COM
At your convenience, please check out http://www.iuassn.com . Much has
been
updated in the last two weeks: on-line versions of recent IUA
CONNECTIONS,
an
on-line scrapbook of IUA1999: Rock&RollFORWARD, notification of PROPOSED
changes
to the IUA BYLAWS that could affect the way IUA operates, and a look at
the
IUA
schedule of events at IMC/CAWORLD 1999.
Also, a list of approved for ballot (but not yet balloted) IDMS
technical
enhancement requests
Chris Hoelscher
Sophisticated Business Systems
Dallas Texas
On Assignment to IBM Global Services
Outsourcers for GE Capital Corporation
------_=_NextPart_001_01BEC3A0.6AB3EBF4
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: please check out WWW.IUASSN.COM
Chris,
When I try to get into any of the links on the left = side of the main
page, it asks me for a userid and password. Is = this expected? (I am
trying to get the local server to update = their cross-reference too.
Meantime I am still using the = numerical IP address.)
Brock.
Brock Shaw, DBA (ISD)
Mercedes Benz (UK), England
-----Original Message-----
From: hoel...@us.ibm.com [mailto:hoel...@us.ibm.com]
Sent: 28 June 1999 15:05
To: idm...@iuassn.com
Subject: please check out WWW.IUASSN.COM
At your convenience, please check out http://www.iuassn.com . Much has
been
updated in the last two weeks: on-line versions of = recent IUA
CONNECTIONS, an
on-line scrapbook of IUA1999: Rock&RollFORWARD, = notification of
PROPOSED changes
to the IUA BYLAWS that could affect the way IUA = operates, and a look
at the IUA
schedule of events at IMC/CAWORLD 1999.
Also, a list of approved for ballot (but not yet = balloted) IDMS
technical
enhancement requests
Chris Hoelscher
Sophisticated Business Systems
Dallas Texas
On Assignment to IBM Global Services
Outsourcers for GE Capital Corporation
------_=_NextPart_001_01BEC3A0.6AB3EBF4--
------------------------------
Date: Thu, 01 Jul 1999 10:43:25 -0500
From: "Rick L. Garvin" <r...@ksu.edu>
To: IDM...@IUASSN.COM
Subject: IDMS 14.1 and ESA
Message-ID: <377B8C9D...@ksu.edu>
FYI....
During the past month I have tried to bring up 14.1 in the MVS/XA
environment. As many of you already know (and thanks to all for the
suggested fixes), I have not been successful to this point. The current
thinking by CA is that there is a bug in RHDCOMVS causing my problem.
Hopefully this will be fixed very soon and I will keep the list advised.
However....
while waiting for the XA fix....I began the process of installing 14.1
into our ESA test system. I was sucessful in bringing up the system
(did a complete re-install using different DSN's) but ran into a problem
with Top Secret. I logged a problem with CA and they have now patched
TSS with a 14.1 re-fit of a 14.0 APAR. Note this problem was with TSS
interacting with IDMS...not an IDMS problem.
------------------------------
Date: Thu, 1 Jul 1999 14:44:16 -0230
From: "Dalton, Joe" <JoeD...@xwavesolutions.com>
To: "'IDM...@IUASSN.COM'" <IDM...@IUASSN.COM>
Subject: Upgrading to 14.1 from 12.0 on os390
Message-ID: <ECCF6A8A572BD311A94...@exchange.newtel.com>
Hi,
We have just started a project to upgrade idms from release 12 (9506) to
release 14.1 (9811) running on os/390. I was just wondering if anyone
has already gone through this type of upgrade and if you will be willing
to
share your experiences.
Thank you,
Joe
------------------------------
Date: Thu, 1 Jul 1999 15:43:52 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: a solution!
Message-ID: <852567A1.0...@d54mta03.raleigh.ibm.com>
The IUA's goal for IDMS-L is to share as much useful information between
the
subscribers as possible. Unfortunately, sometimes too much information
is
shared --- which is against the best interests of the subscribers --
when
someone automatically replies to all messages when they are not
available. Most
subscribers consider knowing when each other goes on vacation too much
information!
A compromise has been reached. The IDMS-L List Administrators (Chris
Hoelscher
and Becky Robinson), after consultation with the IUA board of Directors,
have
made the following modifications to the IDMS-L policy:
Effective Thursday, July 8, 1999, replies to list-distributed messages
will be
directed, by default, TO THE LIST. Repliers are encouraged to change the
TO:
address on a reply to that of an individual if, in fact, the reply would
be more
appropriately addressed to that individual. The lead time of
implementing this
change is intended to allow all subscribers an opportunity to request
being
placed in "digest mode" if you do not want to receive all the replies
individually.
Effective at the same time, when an "out-of-office" or any other
AUTOREPLY is
sent to the list, a list Administrator will unsubscribe that individual
from the
list, and notify that individual via email that they HAVE BEEN
unsubscribed, and
invite them to re-subscribe to IDMS-L when they are no longer
out-of-office.
Additionally, subscribers who continually disregard list policy and
direct
inappropriate replies to the list or another subscriber will be
unsubscribed
from the list and invited NOT to resubscribe to IDMS-L.
Please remember that the software on which IDMS-L now runs is NOT the
same
software upon which the previous IDMS-L ran; most noticeably the NOMAIL
option
does not exist, nor does the ability to moderate messages BY USER exist.
These
limitations require the administrators to take a more black/white
approach to
the list policies than we might prefer, but as the list software matures
(which
it will) the list policies will reflect those capabilities.
Becky Robinson
Chris Hoelscher
IDMS-L List Administrators
------------------------------
Date: Thu, 1 Jul 1999 15:03:48 -0500
From: "Runtsch, Steve" <Steve....@ecolab.com>
To: idm...@iuassn.com
Subject: RE: a solution!
Message-ID: <E994F67723A4D211B00C000083623DF002023FF9@CORPHQ2>
Thank you!!!
<
Effective Thursday, July 8, 1999, replies to list-distributed messages
will
be
directed, by default, TO THE LIST....
>
Excellent!!!
<
Effective at the same time, when an "out-of-office" or any other
AUTOREPLY
is
sent to the list, a list Administrator will unsubscribe that individual
from
the
list, and notify that individual via email that they HAVE BEEN
unsubscribed,
and
invite them to re-subscribe to IDMS-L when they are no longer
out-of-office.
>
------------------------------
Date: Thu, 1 Jul 1999 15:47:13 -0500
From: "Verinder, Gene" <GVER...@alldata.net>
To: idm...@iuassn.com
Subject: RE: a solution!
Message-ID:
<05B56B254C18D2119EF...@sdadmail1.alldata.net>
Chris and Becky,
Thanks for the compromise. If this is the type of conflict resolution
to be
expected from our list-server administrators, it will be a long and
rewarding experience.
(Now you better get back to your "day" jobs.)
Gene Verinder
------------------------------
Date: Thu, 1 Jul 1999 14:15:03 -0700
From: "Jerry Fica" <jf...@worldnet.att.net>
To: <hoel...@us.ibm.com>,
<idm...@iuassn.com>
Subject: RE: a solution!
Message-ID: <000201bec406$c9068c50$b3a7f2c7@jerry-fica>
Chris
Becky
Thank you very much for your efforts. I completely support this
approach, it
will make the list much more useful.
Jerry Fica
>>-----Original Message-----
>>From: hoel...@us.ibm.com [mailto:hoel...@us.ibm.com]
>>Sent: Thursday, July 01, 1999 12:44 PM
>>To: idm...@iuassn.com
>>Subject: a solution!
>>
>>
>>
>>
>>
>>The IUA's goal for IDMS-L is to share as much useful information
>>between the
>>subscribers as possible. Unfortunately, sometimes too much
information is
>>shared --- which is against the best interests of the subscribers --
when
>>someone automatically replies to all messages when they are not
>>available. Most
>>subscribers consider knowing when each other goes on vacation too much
>>information!
>>
>>A compromise has been reached. The IDMS-L List Administrators
>>(Chris Hoelscher
>>and Becky Robinson), after consultation with the IUA board of
>>Directors, have
>>made the following modifications to the IDMS-L policy:
>>
>>Effective Thursday, July 8, 1999, replies to list-distributed
>>messages will be
>>directed, by default, TO THE LIST. Repliers are encouraged to
>>change the TO:
>>address on a reply to that of an individual if, in fact, the
>>reply would be more
>>appropriately addressed to that individual. The lead time of
>>implementing this
>>change is intended to allow all subscribers an opportunity to
>>request being
>>placed in "digest mode" if you do not want to receive all the replies
>>individually.
>>
>>Effective at the same time, when an "out-of-office" or any other
>>AUTOREPLY is
>>sent to the list, a list Administrator will unsubscribe that
>>individual from the
>>list, and notify that individual via email that they HAVE BEEN
>>unsubscribed, and
>>invite them to re-subscribe to IDMS-L when they are no longer
>>out-of-office.
>>
>>Additionally, subscribers who continually disregard list policy and
direct
>>inappropriate replies to the list or another subscriber will be
>>unsubscribed
>>from the list and invited NOT to resubscribe to IDMS-L.
>>
>>Please remember that the software on which IDMS-L now runs is NOT the
same
>>software upon which the previous IDMS-L ran; most noticeably the
>>NOMAIL option
>>does not exist, nor does the ability to moderate messages BY USER
>>exist. These
>>limitations require the administrators to take a more black/white
>>approach to
>>the list policies than we might prefer, but as the list software
>>matures (which
>>it will) the list policies will reflect those capabilities.
>>
>>Becky Robinson
>>Chris Hoelscher
>>IDMS-L List Administrators
>>
>>
>>
------------------------------
End of IDMS-L V1 #13
********************
Chris Hoelscher
Number 14
In this issue:
Dictionary Sharing
Re: Dictionary Sharing
[Fwd: Dictionary Sharing]
RE: Dictionary Sharing
re: Dictionary Sharing
FW: CA Startrak Issue 7496538;01
TD67302 question
FW: Dictionary Sharing
RE: Dictionary Sharing
Re: FW: Dictionary Sharing
attention all LU6.2 users
Buffer Prefetch
Buffer Prefetch -Reply
RE:Buffer Prefetch -Reply
----------------------------------------------------------------------
Date: Fri, 2 Jul 1999 09:30:33 -0400
From: "Lupico, Joe" <Joe.L...@AIG.com>
To: "'IDM...@IUASSN.COM'" <IDM...@IUASSN.COM>
Subject: Dictionary Sharing
Message-ID: <4F1E68B5C708D11180860001FA372A6501CAFC3E@XCS_LIV01>
This message is in MIME format. Since your mail reader does not
understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BEC48E.07C4463A
Content-Type: text/plain
In release 10.2, I would share certain dictionaries among many CVs of
the
same type (such as test), especially the primary dictionary areas
DDLDML,
DDLDCLOD and DDLDCMSG. This allowed me to have only one "primary"
dictionary despite the number of IDMS systems I defined. Of course,
only
one CV could have the dictionary in UPDate mode, but that's never been a
problem.
I am now trying to install release 14.0 for the first time (I'm
skipping
release 12) and I would like to do the same thing. We have a license
for
every IDMS product and since I never know which products potential
clients
may have, when I install the software, I install nearly every product
(including ASF and SQL) except those that are so bizarre that no one
knows
what they do. So therefore, even though I may never (hopefully) use ASF
or
SQL, I create those dictionaries and demo databases.
My question is this...can I share all the dictionaries and databases
created during the installation except for the DDLDCLOG, DDLDCRUN and
DDLDCSCR areas? I realize I would need to split the SYSTEM segment into
two
separate segments - one containing DDLDML and DDLDCLOD, and the other
(which
I would call SYSTEMxx because it's specific to system xx) containing
DDLDCLOG, DDLDCRUN and DDLDCSCR. The SYSTEM DBNAME would then include
the
SYSTEM and SYSTEMxx segments.
Has anyone done this and are there any problems which I would not have
encountered under 10.2?
Thanks...Joe
------_=_NextPart_001_01BEC48E.07C4463A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
Dictionary Sharing
In release 10.2, I would share = certain dictionaries among many CVs
of the same type (such as test), = especially the primary dictionary
areas DDLDML, DDLDCLOD and = DDLDCMSG. This allowed me to have only one
"primary" = dictionary despite the number of IDMS systems I defined. Of
= course, only one CV could have the dictionary in UPDate mode, but =
that's never been a problem.
I am now trying to install = release 14.0 for the first time (I'm
skipping release 12) and I would = like to do the same thing. We have a
license for every IDMS = product and since I never know which products
potential clients may = have, when I install the software, I install
nearly every product = (including ASF and SQL) except those that are so
bizarre that no one = knows what they do. So therefore, even though I
may never = (hopefully) use ASF or SQL, I create those dictionaries and
demo = databases.
My question is this...can I = share all the dictionaries and databases
created during the = installation except for the DDLDCLOG, DDLDCRUN and
DDLDCSCR = areas? I realize I would need to split the SYSTEM segment
into = two separate segments - one containing DDLDML and DDLDCLOD, and
the = other (which I would call SYSTEMxx because it's specific to system
xx) = containing DDLDCLOG, DDLDCRUN and DDLDCSCR. The SYSTEM DBNAME =
would then include the SYSTEM and SYSTEMxx segments.
Has anyone done this and are = there any problems which I would not
have encountered under = 10.2?
Thanks...Joe
------_=_NextPart_001_01BEC48E.07C4463A--
------------------------------
Date: Fri, 02 Jul 1999 15:38:37 +0200
From: "Jan Lenders" <J.Le...@ohra.nl>
To: IDM...@iuassn.com
Subject: Re: Dictionary Sharing
Message-ID: <s77cdd...@ohra.nl>
Joe,
I'd expect IDMS to support dictionary sharing by now, since the parallel
=
sysplex "cv-cloning" would need the dictionary to be shared.
I'm not sure if IDMS R14 already REALLY supports sysplex. If not, it
would =
be a matter of time (if you can wait that long).
Regards,
Jan Lenders,
OHRA SO Service Center - A2-05
Tel. +31 26 400 9608
------------------------------
Date: Fri, 02 Jul 1999 16:59:53 +0300
From: Timo Kotilainen <timo.ko...@fennia.fi>
To: IDM...@iuassn.com
Subject: [Fwd: Dictionary Sharing]
Message-ID: <377CC5D9...@fennia.fi>
This is a multi-part message in MIME format.
--------------3626C140129ECA86921AA795
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--------------3626C140129ECA86921AA795
Content-Type: message/rfc822
Content-Disposition: inline
Message-ID: <377CC31B...@fennia.fi>
Date: Fri, 02 Jul 1999 16:48:11 +0300
From: Timo Kotilainen <timo.ko...@fennia.fi>
Reply-To: timo.ko...@fennia.fi
Organization: Yrittäjäin Fennia
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: "Lupico, Joe" <Joe.L...@AIG.com>
Subject: Re: Dictionary Sharing
References: <4F1E68B5C708D11180860001FA372A6501CAFC3E@XCS_LIV01>
Content-Type: multipart/alternative;
boundary="------------8D3D2EEF12DF3D20AEC44052"
--------------8D3D2EEF12DF3D20AEC44052
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I did that when installing 12.0, just like you
described, and I didn't encounter any problems.
You must define your SYSTEMxx-segments to SYSTEM
dbname in system xx's dbtable.
This "new style" is much more comfortable, it
allows to size DDLDCRUN or whatever individually
for each system, no need to worry about different
versions of network subschema load modules for
different systems like in the 10.2
Timo Kotilainen
Fennia Insurance
---------
Lupico, Joe wrote:
>
>
> In release 10.2, I would share certain
> dictionaries among many CVs of the same type
> (such as test), especially the primary
> dictionary areas DDLDML, DDLDCLOD and DDLDCMSG.
> This allowed me to have only one "primary"
> dictionary despite the number of IDMS systems I
> defined. Of course, only one CV could have the
> dictionary in UPDate mode, but that's never been
> a problem.
>
> I am now trying to install release 14.0 for
> the first time (I'm skipping release 12) and I
> would like to do the same thing. We have a
> license for every IDMS product and since I never
> know which products potential clients may have,
> when I install the software, I install nearly
> every product (including ASF and SQL) except
> those that are so bizarre that no one knows what
> they do. So therefore, even though I may never
> (hopefully) use ASF or SQL, I create those
> dictionaries and demo databases.
>
> My question is this...can I share all the
> dictionaries and databases created during the
> installation except for the DDLDCLOG, DDLDCRUN
> and DDLDCSCR areas? I realize I would need to
> split the SYSTEM segment into two separate
> segments - one containing DDLDML and DDLDCLOD,
> and the other (which I would call SYSTEMxx
> because it's specific to system xx) containing
> DDLDCLOG, DDLDCRUN and DDLDCSCR. The SYSTEM
> DBNAME would then include the SYSTEM and
> SYSTEMxx segments.
>
> Has anyone done this and are there any
> problems which I would not have encountered
> under 10.2?
>
> Thanks...Joe
--------------8D3D2EEF12DF3D20AEC44052
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
I did that when installing 12.0, just like you described, and I didn't
encounter any problems. You must define your SYSTEMxx-segments to
SYSTEM dbname in system xx's dbtable.
This "new style" is much more comfortable, it allows to size DDLDCRUN or
whatever individually for each system, no need to worry about different
versions of network subschema load modules for different systems like in
the 10.2
Timo Kotilainen
Fennia Insurance
---------
Lupico, Joe wrote:
In release 10.2, I would share certain dictionaries among many CVs of
the same type (such as test), especially the primary dictionary areas
DDLDML, DDLDCLOD and DDLDCMSG. This allowed me to have only one
"primary" dictionary despite the number of IDMS systems I defined. Of
course, only one CV could have the dictionary in UPDate mode, but that's
never been a problem.
I am now trying to install release 14.0 for the first time (I'm
skipping release 12) and I would like to do the same thing. We have a
license for every IDMS product and since I never know which products
potential clients may have, when I install the software, I install
nearly every product (including ASF and SQL) except those that are so
bizarre that no one knows what they do. So therefore, even though I may
never (hopefully) use ASF or SQL, I create those dictionaries and demo
databases.
My question is this...can I share all the dictionaries and databases
created during the installation except for the DDLDCLOG, DDLDCRUN and
DDLDCSCR areas? I realize I would need to split the SYSTEM segment into
two separate segments - one containing DDLDML and DDLDCLOD, and the
other (which I would call SYSTEMxx because it's specific to system xx)
containing DDLDCLOG, DDLDCRUN and DDLDCSCR. The SYSTEM DBNAME would
then include the SYSTEM and SYSTEMxx segments.
Has anyone done this and are there any problems which I would not have
encountered under 10.2?
Thanks...Joe
--------------8D3D2EEF12DF3D20AEC44052--
--------------3626C140129ECA86921AA795--
------------------------------
Date: Fri, 2 Jul 1999 10:01:52 -0500
From: "Collins, John" <John.C...@ameriserve.com>
To: "'Lupico, Joe'" <Joe.L...@AIG.com>, "'IDM...@IUASSN.COM'"
<IDM...@IUASSN.COM>
Subject: RE: Dictionary Sharing
Message-ID: <C7C2EDD6CB94D211A00...@dalhq50.dallas.ams>
Joe, I supported a client site for a year that was sharing the
dictionary in
the fashion you describe, running under R12.01 -
tape 9707.
John Collins
W: 972-364-2743
-----Original Message-----
From: Lupico, Joe [mailto:Joe.L...@AIG.com]
Sent: Friday, July 02, 1999 8:31 AM
To: 'IDM...@IUASSN.COM'
Subject: Dictionary Sharing
In release 10.2, I would share certain dictionaries among many CVs of
the
same type (such as test), especially the primary dictionary areas
DDLDML,
DDLDCLOD and DDLDCMSG. This allowed me to have only one "primary"
dictionary despite the number of IDMS systems I defined. Of course,
only
one CV could have the dictionary in UPDate mode, but that's never been a
problem.
I am now trying to install release 14.0 for the first time (I'm
skipping
release 12) and I would like to do the same thing. We have a license
for
every IDMS product and since I never know which products potential
clients
may have, when I install the software, I install nearly every product
(including ASF and SQL) except those that are so bizarre that no one
knows
what they do. So therefore, even though I may never (hopefully) use ASF
or
SQL, I create those dictionaries and demo databases.
My question is this...can I share all the dictionaries and databases
created during the installation except for the DDLDCLOG, DDLDCRUN and
DDLDCSCR areas? I realize I would need to split the SYSTEM segment into
two
separate segments - one containing DDLDML and DDLDCLOD, and the other
(which
I would call SYSTEMxx because it's specific to system xx) containing
DDLDCLOG, DDLDCRUN and DDLDCSCR. The SYSTEM DBNAME would then include
the
SYSTEM and SYSTEMxx segments.
Has anyone done this and are there any problems which I would not have
encountered under 10.2?
Thanks...Joe
------------------------------
Date: Fri, 2 Jul 1999 11:16:28 -0400
From: "Laura Rochon" <laura....@cloxt.com>
To: <IDM...@IUASSN.COM>
Subject: re: Dictionary Sharing
Message-ID: <1999070215...@franz.videotron.net>
You can share your SYSTEM.DDLDML area among several systems as long as
you're not using internal security to secure your environment. If you
plan
on using internal security you might have problems if you have different
security needs for different systems.
When using internal security, a program or task can only be assigned to
one
(and only one) RESOURCE CATEGORY. For example, let's say you create a
resource category called TASK_DMLO to secure the task code DMLO. Let's
also say you have a production and test systems both defined within the
same DDLDML. You might want to grant access to the TASK_DMLO to user
ABC
for the test environment but not for the production environment. The
grant
statement is the following GRANT EXECUTE ON CATEGORY TASK_DMLO TO ABC;
Notice there is no way to specify which system. If user ABC does not
have
access to the production system, that solves your problem. But, if user
ABC
also needs access to the production system, then there is no way to
specify
that user ABC has access to DMLO in test only and not in production.
So if you're planning on using internal security, I would suggest a
SYSTEM
DDLDML area for each CV.
Hope this helps,
Laura Rochon
Compuware Corporation of Canada
------------------------------
Date: Fri, 2 Jul 1999 10:21:42 -0500
From: "Kaufmann, Raymond Jr." <kau...@Jostens.com>
To: IDM...@iuassn.com
Subject: FW: CA Startrak Issue 7496538;01
Message-ID:
<C52E5E9BE724D311980...@ndpswntx1.owbswntu1.jostens.com>
Since Jostens has 9810 on our Y2K LPAR and will be moving it to
production
in July, I was concerned
about the ongoing corruption discussion and opened an issue with CA.
Below
is the response I received
back from CA.
> -----Original Message-----
> From: nie...@cai.com [SMTP:nie...@cai.com]
> Sent: Friday, July 02, 1999 9:35 AM
> To: kau...@jostens.com
> Subject: CA Startrak Issue 7496538;01
>
> CLI: RAY KAUFMANN
> TECH: IDMS;DAPHNE NIELD
> COMP: NUM 114862 NAME JOSTENS INC
> CCN: 7496538 ISS: 1 STAT: OPEN
> PROD: IDMS DESC: DATABASE CORRUPTION
QUESTION
>
> Ray,
> According to my research, 9810 does have to have some apars applied
> to resolve corruption issue.I've listed them below and also attached
the
> test
> apar.
> *
> Located LO50372, TD67302 (3024 ERRORS RETURNED FROM RECOVERY. Possible
jnl
> corruption), LO46431, LO46430,
> Broken Chain - LO46420
> Note: the High APAR for the 9810 tape was LO44174
> *
> However the problem with corruption of the DDLDCRUN (QUEUE) area was
> resolved at 9711.
> *
> Regards Daphne
>
>
>
> SEE THE FOLLOWING SOLUTION(S):
> IDMS 14.0 T 490
>
*_________________________________________________________________________
> _____*
>
> *ID: 490
> *PRODUCT: IDMS
> *RELEASE: 14.0
> *DESC: TCC TEST PTF
> *SOLUTION TYPE: TEST
> *SYSTEMS AFFECTED: OS
> *SOLUTION TEXT:
>
> 3024 ERRORS RETURNED FROM RECOVERY. POSSIBLE JOURNAL
> CORRUPTION. DC209002 ERRORS. THIS OCCURS ONLY IF
> CV RUNS SHORT OF STORAGE BELOW THE 24 BIT LINE.
>
> PROB #: 2133
>
>
> NOTE: THE LOWEST MAINTENANCE LEVEL TO WHICH THIS APAR
> APPLIES IS 9610.
>
>
> *** 9610/9711/9810 ***
>
> SMP INPUT (OS/MVS SYSTEMS):
> ___________________________
>
>
>
> ++USERMOD (TD67302).
> ++VER (Z038) FMID(CGJE000)
> PRE (GJ09711,GJ09810).
> ++ZAP (IDMSDBIJ) DISTLIB(DISTLOAD).
> NAME IDMSDBIJ
> IDRDATA TD67302 FT=AGJE0 CS=IDMSDBIJ ID=0001 AD=000000
> BASE 000000
> VER 002A46 4150,0100
> REP 002A46 4150,0140
>
>
> MSP INPUT (FUJITSU SYSTEMS):
> ____________________________
>
>
>
> ++USERMOD (TD67302).
> ++VER (C402) FMID(CGJE000)
> PRE (GJ09711,GJ09810).
> ++ZAP (IDMSDBIJ) DISTLIB(DISTLOAD).
> NAME IDMSDBIJ
> IDRDATA TD67302 FT=AGJE0 CS=IDMSDBIJ ID=0001 AD=000000
> BASE 000000
> VER 002A46 4150,0100
> REP 002A46 4150,0140
>
>
>
> MSHP INPUT (DOS/VSE SYSTEMS):
> _____________________________
>
>
> CORR 0202-IDD-01-VS2:TD67302
> AFF PHASE=IDMSDBIO
> ALT 00C706 41500100:41500140
>
>
> BS2000 INPUT (SIEMENS SYSTEMS):
> _______________________________
>
>
> ++USERMOD (TD67302).
> ++VER (Z038) FMID(CGJE000)
> PRE (GJ09711,GJ09810).
> ++ZAP (IDMSDBIJ) DISTLIB(DISTLOAD).
> NAME IDMSDBIJ
> IDRDATA TD67302 FT=AGJE0 CS=IDMSDBIJ ID=0001 AD=000000
> BASE 000000
> VER 002A46 4150,0100
> REP 002A46 4150,0140
>
>
> PTF INPUT (VM/CMS SYSTEMS):
> ___________________________
>
>
> * APPLY AGJE0 ZAP MODULE
> * NAME IDMSDBIO
> * DESC 3024 ERRORS RETURNED FROM RECOVERY. POSSIBLE JOURNAL
> NAME IDMSDBIO IDMSDBIJ
> * CS=IDMSDBIJ ID=0001 AD=000000 OF=000000
> VER 002A46 4150,0100
> REP 002A46 4150,0140
> LOG TD67302 ZAPLOG - 3024 ERRORS RETURNED FROM RECOVERY. POSSIBLE
>
>
>
>
*_________________________________________________________________________
> _____*
>
> * OS VERSION: 0 UNCONFIRMED
> *** NO ZAPS FOR THIS VERSION ***
>
>
>
**************************************************************************
> **
>
> ===> RESERVE THE DATES - JULY 18-23, 1999 <===
>
> CA-World 1999 Conference and Exposition New Orleans, LA, USA
>
> Attendee Hotline: 1-877-CAWORLD
> Exhibitor Hotline: 1-516-DIAL-EXHIBIT
>
> For Information visit us at:
> http://www.caworld.com
>
**************************************************************************
> **
> For more information or to be a speaker, visit us at:
> http://www.caworld.com
>
>
**************************************************************************
> **
>
>
>
>
> *** Announcing CA-TCC on the WWW See CA's Home Page WWW.CAI.COM
***
>
**************************************************************************
> ****
> *** PLEASE NOTE THAT THE 609 AREA CODE HAS BECOME 856
***
>
**************************************************************************
> ****
> *** To OPEN a call with a Technical Support Representative:
> ***
> ***
> **
> *** CA-IDMS/DC, DDS, PERF, UCF = (856)-273-3410
> **
> *** CA-IDMS/Compiler, EDB, Install, SQL = (856)-273-3411
> **
> *** CA-Culprit,CA-OLQ,CA-IDMS/Server,CA-TCC= (856)-273-3412
> **
> *** CA-ADS, Mapping = (856)-273-3414
> **
>
**************************************************************************
> *** CALLBACKS on assigned issues= (856)-273-3415
> **
>
> END OF STARTRAK MESSAGE
------------------------------
Date: Fri, 2 Jul 1999 10:38:52 -0500
From: "Kaufmann, Raymond Jr." <kau...@Jostens.com>
To: IDM...@iuassn.com
Subject: TD67302 question
Message-ID:
<C52E5E9BE724D311980...@ndpswntx1.owbswntu1.jostens.com>
Has anyone put on TD67302? If so, does it resolve the problem? Right
now,
TD67302 is unconfirmed so any input would be welcome.
Thank You
Ray Kaufmann
JOSTENS INC.
kau...@jostens.com
612.946.5510
------------------------------
Date: Fri, 2 Jul 1999 11:55:54 -0400
From: "Lupico, Joe" <Joe.L...@AIG.com>
To: "'IDM...@IUASSN.COM'" <IDM...@IUASSN.COM>
Subject: FW: Dictionary Sharing
Message-ID: <4F1E68B5C708D11180860001FA372A6501CAFC48@XCS_LIV01>
This message is in MIME format. Since your mail reader does not
understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BEC4A2.549F04EA
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Since a couple of people have written about security issues, I just =
wanted
to clarify that I don't mean to imply that I want to share dictionaries
across region types (such as test and prod), but rather create a set of
dictionaries that would be shared by all test systems, and another set =
of
dictionaries which would be shared by all production systems. Sharing
dictionaries between test and production was never my intention - =
people
should get committed for having such thoughts.
Joe
> ----------
> From: Lupico, Joe[SMTP:Joe.L...@AIG.com]
> Sent: Friday, July 02, 1999 9:30 AM
> To: 'IDM...@IUASSN.COM'
> Subject: Dictionary Sharing
>=20
> =A0 In release 10.2, I would share certain dictionaries among many =
CVs of
> the same type (such as test), especially the primary dictionary areas
> DDLDML, DDLDCLOD and DDLDCMSG.=A0 This allowed me to have only one =
"primary"
> dictionary despite the number of IDMS systems I defined.=A0 Of =
course, only
> one CV could have the dictionary in UPDate mode, but that's never =
been a
> problem.
>=20
> =A0 I am now trying to install release 14.0 for the first time (I'm =
skipping
> release 12) and I would like to do the same thing.=A0 We have a =
license for
> every IDMS product and since I never know which products potential =
clients
> may have, when I install the software, I install nearly every product
> (including ASF and SQL) except those that are so bizarre that no one =
knows
> what they do.=A0 So therefore, even though I may never (hopefully) =
use ASF
> or SQL, I create those dictionaries and demo databases.
>=20
> =A0 My question is this...can I share all the dictionaries and =
databases
> created during the installation except for the DDLDCLOG, DDLDCRUN and
> DDLDCSCR areas?=A0 I realize I would need to split the SYSTEM segment
=
into
> two separate segments - one containing DDLDML and DDLDCLOD, and the =
other
> (which I would call SYSTEMxx because it's specific to system xx)
> containing DDLDCLOG, DDLDCRUN and DDLDCSCR.=A0 The SYSTEM DBNAME =
would then
> include the SYSTEM and SYSTEMxx segments.
>=20
> =A0 Has anyone done this and are there any problems which I would not
=
have
> encountered under 10.2?=20
>=20
> =A0 Thanks...Joe=20
>=20
>=20
------_=_NextPart_001_01BEC4A2.549F04EA
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
FW: Dictionary Sharing
Since a couple of people have = written about security issues, I just
wanted to clarify that I don't = mean to imply that I want to share
dictionaries across region types = (such as test and prod), but rather
create a set of dictionaries that = would be shared by all test systems,
and another set of dictionaries = which would be shared by all
production systems. Sharing = dictionaries between test and production
was never my intention - = people should get committed for having such
thoughts.
Joe
----------
From: = Lupico, = Joe[SMTP:Joe.L...@AIG.com]
Sent: = Friday, July 02, 1999 9:30 = AM
To: = Subject: =
=A0 In release 10.2, I would share = certain dictionaries among many CVs
of the same type (such as test), = especially the primary dictionary
areas DDLDML, DDLDCLOD and = DDLDCMSG.=A0 This allowed me to have only
one "primary" = dictionary despite the number of IDMS systems I
defined.=A0 Of course, = only one CV could have the dictionary in UPDate
mode, but that's never = been a problem.
=A0 I am now trying to install release = 14.0 for the first time (I'm
skipping release 12) and I would like to = do the same thing.=A0 We have
a license for every IDMS product and = since I never know which products
potential clients may have, when I = install the software, I install
nearly every product (including ASF and = SQL) except those that are so
bizarre that no one knows what they = do.=A0 So therefore, even though I
may never (hopefully) use ASF or = SQL, I create those dictionaries and
demo databases.
=A0 My question is this...can I share = all the dictionaries and
databases created during the installation = except for the DDLDCLOG,
DDLDCRUN and DDLDCSCR areas?=A0 I realize I = would need to split the
SYSTEM segment into two separate segments - one = containing DDLDML and
DDLDCLOD, and the other (which I would call = SYSTEMxx because it's
specific to system xx) containing DDLDCLOG, = DDLDCRUN and DDLDCSCR.=A0
The SYSTEM DBNAME would then include the = SYSTEM and SYSTEMxx segments.
=A0 Has anyone done this and are there = any problems which I would not
have encountered under 10.2?
=A0 Thanks...Joe
------_=_NextPart_001_01BEC4A2.549F04EA--
------------------------------
Date: Fri, 2 Jul 1999 10:39:41 -0500
From: "Collins, John" <John.C...@ameriserve.com>
To: "'Lupico, Joe'" <Joe.L...@AIG.com>, "'IDM...@IUASSN.COM'"
<IDM...@IUASSN.COM>
Subject: RE: Dictionary Sharing
Message-ID: <C7C2EDD6CB94D211A00...@dalhq50.dallas.ams>
Joe, my earlier response about the client I supported for a year only
shared
dictionaries as you have stated. The security issues
mentioned are absolutely valid. I did not consider them for the same
reason
you have mentioned.
John
----Original Message-----
From: Lupico, Joe [mailto:Joe.L...@AIG.com]
Sent: Friday, July 02, 1999 10:56 AM
To: 'IDM...@IUASSN.COM'
Subject: FW: Dictionary Sharing
Since a couple of people have written about security issues, I just
wanted
to clarify that I don't mean to imply that I want to share dictionaries
across region types (such as test and prod), but rather create a set of
dictionaries that would be shared by all test systems, and another set
of
dictionaries which would be shared by all production systems. Sharing
dictionaries between test and production was never my intention - people
should get committed for having such thoughts.
Joe
----------
From: Lupico, Joe[SMTP:Joe.L...@AIG.com]
Sent: Friday, July 02, 1999 9:30 AM
To: 'IDM...@IUASSN.COM'
Subject: Dictionary Sharing
In release 10.2, I would share certain dictionaries among many CVs of
the
same type (such as test), especially the primary dictionary areas
DDLDML,
DDLDCLOD and DDLDCMSG. This allowed me to have only one "primary"
dictionary despite the number of IDMS systems I defined. Of course,
only
one CV could have the dictionary in UPDate mode, but that's never been a
problem.
I am now trying to install release 14.0 for the first time (I'm
skipping
release 12) and I would like to do the same thing. We have a license
for
every IDMS product and since I never know which products potential
clients
may have, when I install the software, I install nearly every product
(including ASF and SQL) except those that are so bizarre that no one
knows
what they do. So therefore, even though I may never (hopefully) use ASF
or
SQL, I create those dictionaries and demo databases.
My question is this...can I share all the dictionaries and databases
created during the installation except for the DDLDCLOG, DDLDCRUN and
DDLDCSCR areas? I realize I would need to split the SYSTEM segment into
two
separate segments - one containing DDLDML and DDLDCLOD, and the other
(which
I would call SYSTEMxx because it's specific to system xx) containing
DDLDCLOG, DDLDCRUN and DDLDCSCR. The SYSTEM DBNAME would then include
the
SYSTEM and SYSTEMxx segments.
Has anyone done this and are there any problems which I would not have
encountered under 10.2?
Thanks...Joe
------------------------------
Date: Fri, 2 Jul 1999 11:55:47 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: Re: FW: Dictionary Sharing
Message-ID: <852567A2.0...@d54mta03.raleigh.ibm.com>
Joe wrote: people should get committed for having such thoughts.
ahh ... if only it was a two-phase committed .......
Chris Hoelscher
Sophisticated Business Systems
Dallas Texas
On Assignment to IBM Global Services
Outsourcers for GE Capital Cooporation
------------------------------
Date: Fri, 2 Jul 1999 15:36:50 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: attention all LU6.2 users
Message-ID: <852567A2.0...@d54mta03.raleigh.ibm.com>
Many of us have expressed, both publicly and provately, many ,many
problems with
native LU62 connectivity (i.e. without the APPC add-on). We too, were so
plagued
- we had applied all published fixes, 6 test fixes, and some had-written
zaps,
but to no avail.
The solution came in the form of how we were calling #TREQ. The WAIT
option
seems to invoke a part of the LU line driver code that contains an as of
yet
unrecreatable "opportunity". Computer Associate's suggestion of changing
this
option to NOWAIT has *completely* removed the symptom (Computer
Associates will
continue to resolve the "opportunity", but the client now do their work
uninterrupted!)
This may not be a solution for everyone, but it worked for us. Code has
been
changed to the major interface program (dubbed the black box" program),
resulting in my client going from 15-20 cv hangs (or near misses) per
week
(since last november)(and even worse when we migrated to 12.01/9809) to
NO
OCCURRANCES/NO OUTAGES!!!!
Chris Hoelscher
Sophisticated Business Systems
Dallas Texas
On Assignment to IBM Global Services
Outsourcers for GE Capital Cooporation
------------------------------
Date: Fri, 2 Jul 1999 14:38:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: idm...@iuassn.com
Subject: Buffer Prefetch
Message-ID: <NY417fa7...@bfi.com>
I have something weird happening which I can't explain, and I'm
wondering if
anyone
else out there has run into this. I have IDMS 14.0 systems at genlevel
9810.
I have some large buffers that have greater than 255 pages, causing
prefetch
to be
invoked. I want to experiment with turning off prefetch for these
buffers
during my
daytime online processing, and then use a DCMT command to turn prefetch
back
on
for nighttime batch processing.
The DCMT VARY BUFFER <name> PREFETCH OFF command shows a buffer display
indicating that prefetch is now "not allowed". However, when I do a
PMRM PF8
buffer
display, the count of "prefetch hits" continues to increase as if
prefetch is
still active
for that buffer. These two things would seem to be mutually exclusive;
if
prefetch is
off, there shouldn't be any prefetch hits...
So it seems as if prefetch really isn't disabled at all, thus, the DCMT
command doesn't
really work.
Does anyone have any clues on this phenomenon?
John Rich
Browning-Ferris Industries
P.S. For full details on prefetch and the prefetch DCMT commands , see
PIB
GI44188.
------------------------------
Date: Fri, 02 Jul 1999 16:57:00 -0500
From: "EDWARD TIMM" <ET...@usagroup.com>
To: IDM...@IUASSN.COM
Subject: Buffer Prefetch -Reply
Message-ID: <s77cef...@usagroup.com>
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=_CD9B8ADA.C1A0CCBB
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
There are numerous ways to turn PREFETCH on/off
DCMT HELP DATA BASE ;
You will see commands for PREFETCH as DMCL, AREA, FILE, and BUFFERS,
=
also via JCL and SYSIDMS.
From STARTCC go to PIP GI44188.
NOTE: PIP (LI46150) is a list of ALL PIP'S for IDMS,=20
(within this list is pips GI44188.)
This pip GI44188 tells how to use PREFETCH..
>>> "John Rich RR" <John...@bfi.com> 99/07/02 2:38 pm >>>
I have something weird happening which I can't explain, and I'm
wondering =
if
anyone
else out there has run into this. I have IDMS 14.0 systems at genlevel
=
9810.
I have some large buffers that have greater than 255 pages, causing =
prefetch
to be
invoked. I want to experiment with turning off prefetch for these
buffers
during my
daytime online processing, and then use a DCMT command to turn prefetch
=
back
on
for nighttime batch processing.
The DCMT VARY BUFFER <name> PREFETCH OFF command shows a buffer display
indicating that prefetch is now "not allowed". However, when I do a
PMRM =
PF8
buffer
display, the count of "prefetch hits" continues to increase as if =
prefetch is
still active
for that buffer. These two things would seem to be mutually exclusive;
if
prefetch is
off, there shouldn't be any prefetch hits...
So it seems as if prefetch really isn't disabled at all, thus, the DCMT
command doesn't
really work. =09
Does anyone have any clues on this phenomenon?
John Rich
Browning-Ferris Industries
P.S. For full details on prefetch and the prefetch DCMT commands , see
=
PIB
GI44188.
--=_CD9B8ADA.C1A0CCBB
Content-Type: message/rfc822
Received: from fshsun01.usagroup.com
([192.168.7.34])
by usagroup.com; Fri, 02 Jul 1999 14:44:41 -0500
Received: from loghost.usagroup.com (vulture.usagroup.com
[192.168.6.66])
by fshsun01.usagroup.com (8.9.1/8.9.1) with ESMTP id OAA03683;
Fri, 2 Jul 1999 14:44:40 -0500 (EST)
Received: from syncronicity.syncronicity.net (www.syncronicity.net
[206.168.112.84] (may be forged))
by loghost.usagroup.com (8.9.1/8.9.1) with ESMTP id OAA21156;
Fri, 2 Jul 1999 14:43:18 -0500
Received: from c-mail01.bfi.com (defiant.bfi.com [198.203.164.100])
by syncronicity.syncronicity.net (Post.Office MTA v3.1.2
release (PO205-101c) ID# 0-44991U2500L250S0) with ESMTP id
AAA284
for <idm...@iuassn.com>; Fri, 2 Jul 1999 13:44:14 -0600
Received: from bfi.com (10.30.250.21) by c-mail01.bfi.com (NPlex
2.0.108) for idm...@iuassn.com; 2 Jul 1999 14:40:25 -0500
X-Internal-ID: 3769C3270002D400
Message-ID: <NY417fa7...@bfi.com>
Date: Fri, 2 Jul 1999 14:38:00 -0500
From: ("John Rich RR") <John...@bfi.com>
Subject: Buffer Prefetch
To: idm...@iuassn.com
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I have something weird happening which I can't explain, and I'm
wondering =
if
anyone
else out there has run into this. I have IDMS 14.0 systems at genlevel
=
9810.
I have some large buffers that have greater than 255 pages, causing =
prefetch
to be
invoked. I want to experiment with turning off prefetch for these
buffers
during my
daytime online processing, and then use a DCMT command to turn prefetch
=
back
on
for nighttime batch processing.
The DCMT VARY BUFFER <name> PREFETCH OFF command shows a buffer display
indicating that prefetch is now "not allowed". However, when I do a
PMRM =
PF8
buffer
display, the count of "prefetch hits" continues to increase as if =
prefetch is
still active
for that buffer. These two things would seem to be mutually exclusive;
if
prefetch is
off, there shouldn't be any prefetch hits...
So it seems as if prefetch really isn't disabled at all, thus, the DCMT
command doesn't
really work. =09
Does anyone have any clues on this phenomenon?
John Rich
Browning-Ferris Industries
P.S. For full details on prefetch and the prefetch DCMT commands , see
=
PIB
GI44188.
--=_CD9B8ADA.C1A0CCBB--
------------------------------
Date: Fri, 2 Jul 1999 17:03:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: (EDWARD TIMM) <ET...@usagroup.com>
Cc: IDM...@IUASSN.COM
Subject: RE:Buffer Prefetch -Reply
Message-ID: <NZ3b7815...@bfi.com>
> There are numerous ways to turn PREFETCH on/off
> DCMT HELP DATA BASE ; You will see commands for PREFETCH
> as DMCL, AREA, FILE, and BUFFERS, also via JCL and SYSIDMS.
> From STARTCC go to PIP GI44188.
Yes, I am aware of that, and I mentioned GI44188 in my message.
But the question is why, after one of those commands is issued,
does PMRM PF8 still show "prefetch hits" being incurred? And
if prefetch hits are still occurring, then are you really sure
that prefetch was actually turned off by the command?
John Rich
------------------------------
End of IDMS-L V1 #14
********************
Chris Hoelscher
last week I have migrated a 10.2 dictionary with shared DDLDCLOAD to
Rel. 14.0.
The migration jobs run fine, but I had problems in some functions i.e.
setting the DICTIONARY NAME.
I found out, that 14.0 dictionary concept differs from 10.2:
You can no longer share one DDLDCLOAD area to multiple DDLDML areas.
After defining an additional DDLDCLOAD area in the segment for the
migrated dictionary=20
I was able to set the correct DICTNAME and accessing it with IDD.
Regards,
Hartmut Grenzd=F6rfer
Debis Systemhaus Stuttgart/Germany
Chris Hoelscher
Date: Mon, 05 Jul 1999 07:21:10 -0500
From: Chris Hoelscher <hoel...@flash.net>
To: idm...@iuassn.com
Subject: sharing DDLDCLOD to multiple DDLDMLs
Message-ID: <1999070512...@ares.flash.net>
A previous post asserts that you are unable to share a DDLDCLOD area
against multiple DDLDML areas. There is in fact a way to accomplish
this.
If the DDLDCLOD area in question is placed in its OWN segment (segment
A),
that segment can be included in any DBNAME that includes a segment
(segment
B) that includes a DDLDML area (as long as segment B does not also
contain
a DDLDCLOD area). Another change from 10.2 days is that, while in 10.2
you
could name your DDLDML and DDLDCLOD areas just about anything you wanted
because the page ranges linked the subschema to the DMCL, in 12/14/15
the
area MUST be named DDLDML/DDLDCLOD because the area name links the
subschema (in this case IDMSNWK?) to the dmcl (the segment prefix allows
for multiple ddldml or ddldclod defined to the DMCL; the subschema
simply
cares about the area name; the program being executed uses the subschema
AND the DBNAME to determine what are the correct files to use!
Chris Hoelscher
------------------------------
Date: Mon, 5 Jul 1999 15:47:27 +0200
From: =?iso-8859-1?Q?Brandt_Ren=E9?= <r...@ubp.ch>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Unsigned numeric field
Message-ID:
<693E4DC6C79FD211907...@mailgva.geneve.ubp.ch>
COBOL II permits you to conserve the field as it was by using the =
option
NUMPROC=3DMIG.
But don't forget to have also DEBUG=3DNO for IDMS programs.
COBOL II works exactely as you define your datas : ex : in LINKAGE =
section
if you define level 01 with a wrong length can lead to storage =
violation, a
field with PIC 99 COMP cannot be greater than 99 (in COBOL I you can go
until 32767). The default option for the WORKING STORAGE in not cleared
=
(you
can change it).
Assembler programs calling COBOL programs have problems if they have =
the
CALL in input and output of SORT (see also RTE option).
> -----Message d'origine-----
> De: Lorenzen, David C [SMTP:david.l...@eds.com]
> Date: Thursday, June 24, 1999 3:57 PM
> =C0: 'idm...@iuassn.com'
> Objet: Unsigned numeric field
>=20
> Our applications staff came to the DBA staff with the following:
>=20
> In a change from COBOL I to COBOL II an unsigned numeric field will =
no
> longer be checked for negative numbers. In this case, the field was
> defined
> as 9(03) comp-3. The field on the database contained 002d, a =
negative
> number. The comparison was 'IF FIELD GREATER THAN ZEROS'. COBOL I =
takes
> the negative and says its less than zero. COBOL II throws out the =
sign
> and
> says its greater than zero. =20
>=20
> My first fix was to revert back to COBOL I. I have analyzed our =
database
> definitions and determined that "way back when" we have thousands of
> database records with fields defined as unsigned numeric. We could
> determine
> why we have negative numbers, but I'm also interested on hearing =
other
> suggestions.
>=20
> Thanks.
> David Lorenzen
> EDS
------------------------------
Date: Mon, 5 Jul 1999 11:21:19 -0400
From: glenn....@ac.com
To: idm...@iuassn.com
Subject: IDMS 14.0 Problems
Message-ID: <862567A5.0...@amrhm1101.ac.com>
Thanks for those who have replied ... the list is growing!
To answer a few questions I have been asked.
1. The corruption happened when pre-fetch was turned on
2. We are not using MT
3. We are running 14.0 GL9711 on OS/390 version 1.3
4. The corruption happened with heavy batch updates
5. We have not been able to replicate the problem (thankfully?)
6. We run CV-mode (even for retrieval) for read-consistency (due to
updated data
not being written yet)
Glenn Scott
------------------------------
Date: Mon, 5 Jul 1999 09:42:53 -0600
From: "Wood, Chris" <Chris...@gov.ab.ca>
To: IDM...@iuassn.com
Subject: Test Apar TB96327
Message-ID:
<71390C47E6E8D111B36B...@eoaexc01.enr.gov.ab.ca>
Hi,
I see that test apar for 14.0 TB96327 has been raised. Does anybody on
the
list know the background to the problem and can explain what causes the
error and how it shoes itself?
Thanks
Chris Wood
Alberta Department of Resource Development
CANADA
------------------------------
Chris Hoelscher
Date: Tue, 6 Jul 1999 08:46:00 -0400
From: Michael Newman <michae...@kayser-roth.com>
To: IDM...@IUASSN.COM
Subject:
This message is in MIME format. Since your mail reader does not
understand
this format, some or all of this message may not be legible.
------ =_NextPart_001_01BEC7AD.88027970
Content-Type: text/plain
Unsubscribe
------ =_NextPart_001_01BEC7AD.88027970
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
Unsubscribe
------ =_NextPart_001_01BEC7AD.88027970--
------------------------------
Date: Tue, 6 Jul 1999 08:05:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: idm...@iuassn.com
Subject: RE: Buffer Prefetch
Message-ID: <NZ8933bd...@bfi.com>
> Brock Shaw:
> Did you try the SYSIDMS parameter "PREFETCH=OFF".
Yes. When I plug that into my SYSIDMS that is used during system
startup, it does indeed work; I see no "prefetch hits" during the
life of the system.
This is one of the things that makes me suspicious about the
dynamic DCMT commands, since prefetch-hits don't cease when they
are issued. Two different behaviors out of two different commands
that should be doing the same thing; both should disable prefetch,
and one eliminates the prefetch-hits, while the other does not.
But with the SYSIDMS technique, a cycling of the system would be
necessary to change the prefetch status. We should be able to do
it dynamically on the fly...
John Rich
:-)
------------------------------
Date: Tue, 6 Jul 1999 08:16:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: IDM...@iuassn.com
Subject: RE:Buffer Prefetch
Message-ID: <NY69d31e...@bfi.com>
EDWARD.TIMM[ETIMM]@usagroup.com
> Could this buffer be so active with a run unit that the command
> can not invoke a change. What if you Close the Buffer and reopen
> it, much like DATASPACE?
That's a good thought. I was thinking of this possibility, but the
prefetch-hits
continued to accrue even hours after the command to disable prefetch had
been
issued - long after all run-units which were active at the time the
command was
issued had finished. So I don't think it's an issue with individual run
units.
However, there may be a need for some kind of quiesce for the entire
buffer.
I'm wondering if *all* activity in the buffer must cease before the
command can
take effect. I'm going to experiment some more with this. Thanks for
the
idea.
The DCMT VARY BUFFER documentation does give a warning that VARY
BUFFER commands may not take effect immediately if IDMS is using the
buffer.
But it does not then follow-through and tell you how to quiesce the
buffer to
force the change into effect. But I think you are on the right track
here!
John Rich
:-)
------------------------------
Date: Tue, 6 Jul 1999 07:34:44 -0600
From: "Wood, Chris" <Chris...@gov.ab.ca>
To: "'IDM...@iuassn.com'" <IDM...@iuassn.com>
Subject: Test Apar TB96327
Message-ID:
<71390C47E6E8D111B36B...@eoaexc01.enr.gov.ab.ca>
I am re-sending this message as I am unsure it got through yesterday.
Hi,
I see that test apar for 14.0 TB96327 has been raised. Does anybody on
the
list know the background to the problem and can explain what causes the
error and how it shoes itself?
Thanks
Chris Wood
Alberta Department of Resource Development
CANADA
------------------------------
Date: Tue, 6 Jul 1999 09:45:01 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: a reminder from the administrators
Message-ID: <852567A6.0...@d54mta03.raleigh.ibm.com>
Please remember that Thursday morning this list will revert to
defaulting
replies made to list-distributed emails BACK TO THE LIST. As there is
always the
chance that this might result in unintended emails being delivered to
the list,
anyone who does not want to receive messages individually is invited to
request
DIGEST MODE (all messages during a day will be deferred and distributed
under
one email header). please send that request to :
in order for the request to be processed, the list administrators will
unsubscribe and resubscribe you to the list - so you WILL see an
unsubscribe
notice and a new welcome letter - do not be concerned with this.
thanks,
Becky Robinson
Chris Hoelscher
IDMS-L Administrators
------------------------------
Date: Tue, 6 Jul 1999 09:47:15 -0400
From: "Jon R. Gocher" <jgo...@frontiernet.net>
To: <dbar...@ets.org>, <idm...@iuassn.com>
Subject: Re: R140 Corruption
Message-ID: <19990706134...@frontiernet.net>
Del -
In my particular situation with broken queues,
OS/390, Rel 14.0 at 9711:
1. PREFETCH is not allowed (OFF).
2. Not using multi-tasking.
3. Queue and scratch mapped to same buffer,
but SCRATCH IN XA STORAGE IS YES.
4. QUEUE JOURNAL ALL.
5. Most activity against the queue area is:
ADSO does PUT QUEUE.
DC-COBOL does GET and DELETE QUEUE.
DC-BATCH COBOL on selected queues does GET and DELETE QUEUE.
All occur throughout the day and evening... very heavy on Tuesday
and
Wednesday.
6. I see from responses to the list that I do NOT have all HYPERs
applied. I
am in the
process of doing that this week.
Thanks.
Jon Gocher
----------
> From: del barlett <dbar...@ets.org>
> To: idm...@iuassn.com
> Subject: R140 Corruption
> Date: Wednesday, June 30, 1999 11:50 AM
>
> I also have a questions for those with R14.x data corruption
problems.
>
> Those of you experiencing corruption:
> did you have PRE-FETCH turned on or off??
> were you using MT or not??
> was it only in heavy batch updates or were there other situations??
> For my own mind, just trying to isolate the environment and
circumstances.
>
> Thanks,
> Del Barlett
>
> ETS
> Princeton,NJ
> 609-734-5941
> dbar...@ets.org
>
------------------------------
Date: Tue, 06 Jul 1999 10:41:31 -0500
From: "Rick L. Garvin" <r...@ksu.edu>
To: IDM...@IUASSN.COM
Subject: CA-IDMS14 error
Message-ID: <378223AB...@ksu.edu>
I am running CA-IDMS 14.1 in an ESA environment. When I try to execute
ADSCT I get the following DC msg: 498302 (Internal Compiler Error).
The error manual says to call tech support but I thought I would chk the
collective minds of this group first.
Anyone experience this problem?
PS I searched on TCC for 498302 and came up empty handed.
------------------------------
Date: Tue, 06 Jul 1999 09:46 -0600 (MDT)
From: Will Hathcock <Will.H...@wcom.com>
To: IDM...@iuassn.com
Subject: Re: CA-IDMS14 error
Message-ID: <19990706154919.KDTH433@localHost>
The CA90's 'C' run time library is not in the link list so you need to
put a steplib in to point to it.
Date: Tue, 06 Jul 1999 09:41 -0600 (MDT)
From: "Rick L. Garvin" <r...@ksu.edu>
Organization: K-State Information Systems
To: IDM...@iuassn.com
Subject: CA-IDMS14 error
I am running CA-IDMS 14.1 in an ESA environment. When I try to execute
ADSCT I get the following DC msg: 498302 (Internal Compiler Error).
The error manual says to call tech support but I thought I would chk the
collective minds of this group first.
Anyone experience this problem?
PS I searched on TCC for 498302 and came up empty handed.
------------------------------
Date: Tue, 06 Jul 1999 13:47:51 -0500
From: "Rick L. Garvin" <r...@ksu.edu>
To: IDM...@IUASSN.COM
Subject: Re: CA-IDMS14 error
Message-ID: <37824F57...@ksu.edu>
Does anyone have an idea what the DSN is for this data set. We have
tried several that looked like C run time "stuff" and we are still
getting the error.
Will Hathcock wrote:
>
> The CA90's 'C' run time library is not in the link list so you need to
> put a steplib in to point to it.
>
> Date: Tue, 06 Jul 1999 09:41 -0600 (MDT)
> From: "Rick L. Garvin" <r...@ksu.edu>
> Organization: K-State Information Systems
> To: IDM...@iuassn.com
> Subject: CA-IDMS14 error
>
> I am running CA-IDMS 14.1 in an ESA environment. When I try to
execute
> ADSCT I get the following DC msg: 498302 (Internal Compiler Error).
> The error manual says to call tech support but I thought I would chk
the
> collective minds of this group first.
>
> Anyone experience this problem?
>
> PS I searched on TCC for 498302 and came up empty handed.
------------------------------
Date: Tue, 06 Jul 1999 13:58:56 -0500
From: "Rick L. Garvin" <r...@ksu.edu>
To: IDM...@IUASSN.COM
Subject: Re: CA-IDMS14 error
Message-ID: <378251F0...@ksu.edu>
We have found the problem. The C runtime is in the CAI.CAILIB DSN. The
DSN only needs to be defined to the CDMSLIB and therefore the LINK list
is not relevant. Executables are pulled from the CDMSLIB not the
STEPLIB.
Thanks to everyone who helped on the problem.
Rick
------------------------------
Date: Tue, 06 Jul 1999 14:13:35 -0500
From: "EDWARD TIMM" <ET...@usagroup.com>
To: IDM...@IUASSN.COM
Subject: CA-IDMS14 error -Reply
Message-ID: <s7820f...@usagroup.com>
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=_EEB85666.4829451E
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Need to have the ca90s loadlib on the cdmslib dd in the startup jcl.=20
>>> "Rick L. Garvin" <r...@ksu.edu> 99/07/06 10:41 am >>>
I am running CA-IDMS 14.1 in an ESA environment. When I try to execute
ADSCT I get the following DC msg: 498302 (Internal Compiler Error).=20
The error manual says to call tech support but I thought I would chk the
collective minds of this group first.
Anyone experience this problem?
PS I searched on TCC for 498302 and came up empty handed.
--=_EEB85666.4829451E
Content-Type: message/rfc822
Received: from fshsun01.usagroup.com
([192.168.7.34])
by usagroup.com; Tue, 06 Jul 1999 10:41:09 -0500
Received: from loghost.usagroup.com (vulture.usagroup.com
[192.168.6.66])
by fshsun01.usagroup.com (8.9.1/8.9.1) with ESMTP id KAA14918;
Tue, 6 Jul 1999 10:41:08 -0500 (EST)
Received: from syncronicity.syncronicity.net (www.syncronicity.net
[206.168.112.84] (may be forged))
by loghost.usagroup.com (8.9.1/8.9.1) with ESMTP id KAA32670;
Tue, 6 Jul 1999 10:39:50 -0500
Received: from mailhub.cns.ksu.edu (grunt.ksu.ksu.edu [129.130.12.17])
by syncronicity.syncronicity.net (Post.Office MTA v3.1.2
release (PO205-101c) ID# 0-44991U2500L250S0) with ESMTP id
AAA179
for <IDM...@IUASSN.COM>; Tue, 6 Jul 1999 09:42:04 -0600
Received: from ksu.edu ([129.130.220.60])
by mailhub.cns.ksu.edu (8.9.1/8.9.1/mailhub+tar) with ESMTP id KAA02294
for <IDM...@IUASSN.COM>; Tue, 6 Jul 1999 10:40:40 -0500 (CDT)
Message-ID: <378223AB...@ksu.edu>
Date: Tue, 06 Jul 1999 10:41:31 -0500
From: "Rick L. Garvin" <r...@ksu.edu>
Organization: K-State Information Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
To: IDM...@iuassn.com
Subject: CA-IDMS14 error
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I am running CA-IDMS 14.1 in an ESA environment. When I try to execute
ADSCT I get the following DC msg: 498302 (Internal Compiler Error).=20
The error manual says to call tech support but I thought I would chk the
collective minds of this group first.
Anyone experience this problem?
PS I searched on TCC for 498302 and came up empty handed.
--=_EEB85666.4829451E--
------------------------------
Date: Tue, 06 Jul 1999 17:13:49 -0500
From: Chris Hoelscher <hoel...@flash.net>
To: idm...@iuassn.com
Subject: another passing of an old friend
Message-ID: <1999070622...@ares.flash.net>
I am saddened to learn of news of the passing of another long-time idms
DBA. Brian Swett passed away yesterday (7/5) after suffering a massive
heart attack. As many of you know, Brian worked for many years at the
University of Louisville for many years before going to Computer
Associates
(Indianapolis) in 1997. Brian served as Treasurer of the Ohio Valley
(IDMS)
User Group while I served as president. As I remembered him, he always
kept
a positive attitude despite personal tragedies in his life. He will be
missed.
Visitation will be Thursday, 2pm to 9pm
Barret - Nusz Funeral Home
located at Barret & Oak (old Hassenour's bldg)
1028 Barret Avenue
Louisville, KY 40204
Funeral will be Friday, 10am
St. John Lutheran Church
901 Breckenridge
Louisville, KY
Burial at Calvary Cemetary (1600 Newburg Rd)
Friends and family will gather back at the church following the burial.
------------------------------
Date: Tue, 06 Jul 1999 20:42:12 -0500
From: Chris Hoelscher <hoel...@flash.net>
To: idm...@iuassn.com
Subject: Fwd: BIND PROBLEMS
Message-ID: <1999070701...@ares.flash.net>
forward from a post sent to an incorrect address
>Date: Tue, 6 Jul 1999 17:36:19 -0700 (PDT)
>From: pattabhi nanduri <nsp...@yahoo.com>
>Subject: BIND PROBLEMS
>To: list...@uga.cc.uga.edu
>Cc: hoel...@flash.net
>
>Hi ,
>
>Iam trying to execute a DC-COBOL program in a CV which doesnot have a
>default DBNAME defined . The subject CV has got more than one DB
>segments.The users should be able to invoke the DC-COBOL program by
>initiating a task , processing data in different databases.
>If I hard code the DBNAME in the BIND RUN-UNIT statement the task can
>be initiated for the particular DBNAME only and for all other DBNAMES
>it is blowing up on status code 1492.
>Is there anyway that I could pass the DBNAME so that it is
>successfully BOUND without modifying/adding the code or additional
>on-line program every time the task is executed.
>The DC-COBOL pogram is initiated as and when some records are written
>to a trigger queue.
>
>Any help is greatly appreciated.
>
>Thanks in advance,
>
>Pattabhi Srinivas,
>Programmer,
>GAC,Savh.
>
>_________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.com address at http://mail.yahoo.com
>
------------------------------
lpet...@my-deja.com
There's a way to share loadareas between dictionaries. Create a stand
alone segment for the shared load-area. Then in the dbname table for
each dictionary dbname include the load-area segment. You'll need to
remove the load area from the dictionary segment containing the ddldml
area.
Lutz Petzold
CSC
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.