Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

daily listing of IDMS-L

292 views

Skip to first unread message

Chris Hoelscher

unread,

Aug 12, 1999, 3:00:00 AM8/12/99

To: <IDM...@iuassn.com>
Subject: IDMS-L V1 #45

IDMS-L Wed, 4 Aug 1999 Volume 1 :
Number 45

In this issue:

APAR ls05738
Re: RE: Hot Backups without a QUIESCE point
Fw: RE: Hot Backups without a QUIESCE point
Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Re: [IDMS-L]APAR ls05738
RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
RACF Groups
Optimizer?
RE: Hot Backups without a QUIESCE point
RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
maintain index
Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
RE: [IDMS-L]maintain index
Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Re: [IDMS-L]maintain index
Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
RE: Hot Backups without a QUIESCE point
Program check in XASTGPL
Re: [IDMS-L]RE: Hot Backups without a QUIESCE point
RE: [IDMS-L]maintain index
Re: [IDMS-L]RE: Hot Backups without a QUIESCE point
Re: [IDMS-L]RE: Hot Backups without a QUIESCE point
RE: [IDMS-L]maintain index
Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
RE: Hot Backups without a QUIESCE point
Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Re: [IDMS-L]RE: Hot Backups without a QUIESCE point

----------------------------------------------------------------------

Date: Tue, 3 Aug 1999 09:38:29 -0400
From: "Gene.McCormack" <Gene.Mc...@plpit.fishersci.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: APAR ls05738
Message-ID:
<8BEC761BBB76D21196D9...@exchg-pdc-plpgh.fishersci.com>

This apar reduces CPU usage by changing the way XA storage is
allocated.
Did anybody create another Xa pool and if so what was the syntax and
why .
How did you determine the CPU savings ?

------------------------------

Date: Tue, 3 Aug 1999 15:14:10 +0100
From: "gary-b" <gar...@email.msn.com>
To: <idm...@iuassn.com>
Subject: Re: RE: Hot Backups without a QUIESCE point
Message-ID: <002001beddba$99676be0$415395c1@gary>

Hello Listers,

Some of the discussion thread about Hot-Backups identifies the
requirement for a "quiesce point" to be taken before the backup
is commenced. (That is, a period when there is no update
activity against the areas being backed-up). Of course this
Quiesce point itself is problematic for sites requiring true 24x7
undisrupted processing. Typically, users will vary affected areas
to retrieval or offline. After the "quiesce point" is
established, the journal is varied and the backup started. Both
online and batch jobs are impacted. While waiting for the
quiesce, online tasks are abended. Operations staff may have the
problem of determining which batch jobs may be accessing the
affected areas and prolonging the wait for quiesce. Consequently,
sites often have to carefully schedule overnight batch work
around the planned nightly backup. Even the future release 15.0
quiesce feature does not resolve this issue. The only difference
is that jobs will wait while the areas are quiescing rather than
abending as at present.

However, there is a solution. Cogito have now released the
DB-SoftQuiesce tool. This tool allows Hot-Backups to be taken
without any disruption to the CA-IDMS service whatsoever. Simply
start the DBSQP program. This is an online tool which
automatically varies the journal and then writes a console
message when it is safe to commence the backup. While waiting for
this "Soft Quiesce", currently active run-units continue
processing and new run-units ARE allowed to start. The process
will (optionally) automatically terminate long running run-units
if they do not COMMIT or FINISH within ten minutes. The process
allows true un-disrupted 24x7 service and provides the additional
important benefit of removing operator involvement thereby
allowing the opportunity of unattended (sometimes referred to as
"dark") operations.

DB-SQP also includes a special journal concatenate tool required
in the event of a recovery. By permitting concurrent recovery
streams, the recovery time may be greatly reduced. DB-SQP has
been in use for over two years at one of the largest CA-IDMS
customers in the world and has been proven in numerous recovery
situations

For Further information contact

soft...@tact.com or
soft...@cogito.co.uk

Gary Bronziet
Cogito

----- Original Message -----
From: Mark CONS:Caffrey <DBA...@mbusa.com>
To: <Idm...@iuassn.com>
Sent: 30 July 1999 18:24
Subject: Re: RE: Hot Backups

I have been watching the messages on this, and it seems many
people do not like this technique. I thought I would throw in
this alternative: We use ADRDSSU (from IBM), which has a
"concurrent copy" option.

You quiesce the areas (files) to be backed up, the utility then
"serializes" the files, basically taking a "checkpoint" if you
will. This takes only a minute or 2. Once it is serialized, you
can bring the areas back online to CV, but they will be backed up
in the state they were in when they were serialized. The backups
will be fully clean and usable, but the job ran with the areas
online to CV.

This does use (potentially quite a bit of) auxiliary storage in
MVS, and should be coordinated with the systems programmers, but
it works perfectly. I should also say that it can run much longer
if you are doing a large number of updates while the backup is
running. We run it early in the morning against the online CV,
when there are relatively few updates occurring.
I hope this helps.
Mark

>>> "Mowbray, Sam A" <sam.m...@eds.com> 07/30 1:05 AM >>>
Harold,
1. We have been doing hot backups (under 10.2) since approx. 1994
(currently
under 12.0)
2. Weekdays : Shut the CV down at 3am - condense any CV
loadlibs - bring up
the CV - kick the areas into update - backup databases - vary the
jnl at the
end
Sundays : standard CV down cold backup of dicts. CV up with
Applic
databases in retrieval while they are backed up. Switch these to
update
when complete.
3. Pitfalls - make the system keep a good note on when each of
the journals
and backups ran - preferably together
4. Recovery. We haven't done any recoveries under "duress". We
occassionally test the technique on backup recovery sites or
under a DBA
research environment. You just need to be more careful in doing
the
recovery to get the process in the right order.

Regards
Sam Mowbray
Database Administrator
EDS Australia
Level 8, 108 North Tce,
ADELAIDE, South Australia 5000
email : sam.m...@eds.com
phone : +61 8 8464 1503
fax : +61 8 8464 2135

> A few questions:
> How long have you used this backup technique ?
> How are you doing hot backups ?
> What problems or pitfalls, if any, have you encountered
using
> this backup technique ?
> How would you compare recovery using a hot backup to a recovery
> using a conventional static backup ?
>
>
> Thanks in advance.
>

------------------------------

Date: Tue, 3 Aug 1999 15:21:40 +0100
From: "gary-b" <gar...@email.msn.com>
To: "IDMS-L Users" <idm...@iuassn.com>
Subject: Fw: RE: Hot Backups without a QUIESCE point
Message-ID: <005001beddbb$935cade0$415395c1@gary>

Apologies -

Cogito email address should read
in...@cogito.co.uk

Gary Bronziet

----- Original Message -----
From: gary-b <gar...@email.msn.com>
To: <idm...@iuassn.com>
Sent: 03 August 1999 15:14
Subject: Re: RE: Hot Backups without a QUIESCE point

> Hello Listers,
>
> Some of the discussion thread about Hot-Backups identifies the
> requirement for a "quiesce point" to be taken before the backup
> is commenced. (That is, a period when there is no update
> activity against the areas being backed-up). Of course this
> Quiesce point itself is problematic for sites requiring true
24x7
> undisrupted processing. Typically, users will vary affected
areas
> to retrieval or offline. After the "quiesce point" is
> established, the journal is varied and the backup started.
Both
> online and batch jobs are impacted. While waiting for the
> quiesce, online tasks are abended. Operations staff may have
the
> problem of determining which batch jobs may be accessing the
> affected areas and prolonging the wait for quiesce.
Consequently,
> sites often have to carefully schedule overnight batch work
> around the planned nightly backup. Even the future release 15.0
> quiesce feature does not resolve this issue. The only
difference
> is that jobs will wait while the areas are quiescing rather
than
> abending as at present.
>
> However, there is a solution. Cogito have now released the
> DB-SoftQuiesce tool. This tool allows Hot-Backups to be taken
> without any disruption to the CA-IDMS service whatsoever.
Simply
> start the DBSQP program. This is an online tool which
> automatically varies the journal and then writes a console
> message when it is safe to commence the backup. While waiting
for
> this "Soft Quiesce", currently active run-units continue
> processing and new run-units ARE allowed to start. The process
> will (optionally) automatically terminate long running
run-units
> if they do not COMMIT or FINISH within ten minutes. The
process
> allows true un-disrupted 24x7 service and provides the
additional
> important benefit of removing operator involvement thereby
> allowing the opportunity of unattended (sometimes referred to
as
> "dark") operations.
>
> DB-SQP also includes a special journal concatenate tool
required
> in the event of a recovery. By permitting concurrent recovery
> streams, the recovery time may be greatly reduced. DB-SQP has
> been in use for over two years at one of the largest CA-IDMS
> customers in the world and has been proven in numerous recovery
> situations
>
> For Further information contact
>
> soft...@tact.com or
> soft...@cogito.co.uk
>
>
> Gary Bronziet
> Cogito
>
>
>
>
>
>
>
>
>
> ----- Original Message -----
> From: Mark CONS:Caffrey <DBA...@mbusa.com>
> To: <Idm...@iuassn.com>
> Sent: 30 July 1999 18:24
> Subject: Re: RE: Hot Backups
>
>
> I have been watching the messages on this, and it seems many
> people do not like this technique. I thought I would throw in
> this alternative: We use ADRDSSU (from IBM), which has a
> "concurrent copy" option.
>
> You quiesce the areas (files) to be backed up, the utility then
> "serializes" the files, basically taking a "checkpoint" if you
> will. This takes only a minute or 2. Once it is serialized, you
> can bring the areas back online to CV, but they will be backed
up
> in the state they were in when they were serialized. The
backups
> will be fully clean and usable, but the job ran with the areas
> online to CV.
>
> This does use (potentially quite a bit of) auxiliary storage in
> MVS, and should be coordinated with the systems programmers,
but
> it works perfectly. I should also say that it can run much
longer
> if you are doing a large number of updates while the backup is
> running. We run it early in the morning against the online CV,
> when there are relatively few updates occurring.
> I hope this helps.
> Mark
>
> >>> "Mowbray, Sam A" <sam.m...@eds.com> 07/30 1:05 AM >>>
> Harold,
> 1. We have been doing hot backups (under 10.2) since approx.
1994
> (currently
> under 12.0)
> 2. Weekdays : Shut the CV down at 3am - condense any CV
> loadlibs - bring up
> the CV - kick the areas into update - backup databases - vary
the
> jnl at the
> end
> Sundays : standard CV down cold backup of dicts. CV up with
> Applic
> databases in retrieval while they are backed up. Switch these
to
> update
> when complete.
> 3. Pitfalls - make the system keep a good note on when each of
> the journals
> and backups ran - preferably together
> 4. Recovery. We haven't done any recoveries under "duress".
We
> occassionally test the technique on backup recovery sites or
> under a DBA
> research environment. You just need to be more careful in
doing
> the
> recovery to get the process in the right order.
>
> Regards
> Sam Mowbray
> Database Administrator
> EDS Australia
> Level 8, 108 North Tce,
> ADELAIDE, South Australia 5000
> email : sam.m...@eds.com
> phone : +61 8 8464 1503
> fax : +61 8 8464 2135
>
>
>
> > A few questions:
> > How long have you used this backup technique ?
> > How are you doing hot backups ?
> > What problems or pitfalls, if any, have you encountered
> using
> > this backup technique ?
> > How would you compare recovery using a hot backup to a
recovery
> > using a conventional static backup ?
> >
> >
> > Thanks in advance.
> >
>
>

------------------------------

Date: Tue, 3 Aug 1999 10:52:29 -0400
From: "Hugh Laderman" <hu...@laderman.com>
To: <idm...@iuassn.com>
Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Message-ID: <004301beddbf$d0078b80$e2c0a4d8@oemcomputer>

Having seen the following reply, this subject has now piqued my interest

enough to admit my probable ignorance in this area. About 20 years ago,
as
an IDMS systems programmer, I investigated the possibility of "hot
backups".
At the time, I couldn't find any IDMS user who had even considered it
(although I imagine some had). It seemed to us that hot backups would
present no problem and that there was no need for any quiesce point.
Since
roll forward would apply all after-images, all would be fine as long as
we
applied all journal updates beginning no later than the start time of
the
hot backup. (If we used some earlier journals, that would be OK, since
they
would be overlaid with more recent updates.)

Well, as it turned out, we never had the need to actually do this; we
were
always allowed a 4 hour per week window to shut down and perform
maintenance. But now I'm curious. Can someone point out the flaws in our

conclusion ? Thanks.

Hugh Laderman
Laderman Associates
(215) 493-3460 Voice
(215) 493-0573 Fax

-----Original Message-----
From: gary-b <gar...@email.msn.com>
To: idm...@iuassn.com <idm...@iuassn.com>
Date: Tuesday, August 03, 1999 10:14 AM
Subject: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point

------------------------------

Date: Tue, 03 Aug 1999 10:04:46 -0500
From: "EDWARD TIMM" <ET...@usagroup.com>
To: idm...@iuassn.com
Subject: Re: [IDMS-L]APAR ls05738
Message-ID: <s7a6be...@usagroup.com>

Our site have utilized this APAR in Release 12.0, Release 14.0 and
Release =
14.1 (note: release 14.0 and above require #DEFOPTF OPT00193 to be =
activated for APAR to be effective). Release 14.0 APAR LO37619, for =
release 14.1 APAR is sourced, but for 14.0 and 14.1 not activated until
=
#DEFOPTF OPT00193 is activated

We found 5 to 10% savings in CPU with this APAR applied, depending upon
=
the CV, but at the expense of XA storage (we do not have paging
problems, =
so this was a good fit at our site).

For each CV: to determine utilization of pools
Issue command:
OPER W ST
Displayed values on screen as a GRID. =20

For example under column XA would be the XA pools needed.
In this example I would allocate:
SHARED and SHARED-KEPT as 1 pool (0 hits/5 hits)
USER as 1 pool (4543368 hits)
USER-KEPT as 1 pool (1262890 hits)
TERMINAL and DATABASE as 1 pool (0 hits/21182 hits)
----see below sample ("portion") of OPER W ST screen=20

x s s u u t d s #Pools #Requests=20
a h k s k r b y For Types For Types=20
x 1 0 =20
x 1 3 =20
x 1 2026086 =20
x 1 751 =20
x 1 0 =20
x 1 2 =20
x 1 47180 =20
x x 1 0 =20
x x 1 5 =20
x x 1 4543368 =20
x x 1 1262890 =20
x x 1 0 =20
x x 1 21182 =20
x x 1 445298 =20

SYSGEN MODIFICATIONS:

MOD SYS xx .
ADD XA STORAGE POOL 128 =20
SIZE IS 12288 =20
CUSHION IS 2048 =20
NOPGFIX =20
RELOCATABLE THRESHOLD IS NO =20
CONTAINS TYPES ( USER ) =20
. =20
ADD XA STORAGE POOL 129 =20
SIZE IS 14336 =20
CUSHION IS 2048 =20
NOPGFIX =20
RELOCATABLE THRESHOLD IS NO =20
CONTAINS TYPES ( USER-KEPT ) =20
. =20
ADD XA STORAGE POOL 130 =20
SIZE IS 5120 =20
CUSHION IS 1024 =20
NOPGFIX =20
RELOCATABLE THRESHOLD IS NO =20
CONTAINS TYPES ( SHARED SHARED-KEPT ) =20
. =20
ADD XA STORAGE POOL 131 =20
SIZE IS 7168 =20
CUSHION IS 1024 =20
NOPGFIX =20
RELOCATABLE THRESHOLD IS NO =20
CONTAINS TYPES ( TERMINAL DATABASE ) =20
.
. =
=20

Edward A. Timm
USA Group, Senior Database Analyst
et...@usagroup.com
(317) 596-1182

>>> "Gene.McCormack" <Gene.Mc...@plpit.fishersci.com> 99/08/03 8:38
AM =
>>>
This apar reduces CPU usage by changing the way XA storage is
allocated.
Did anybody create another Xa pool and if so what was the syntax and
why =
.
How did you determine the CPU savings ?

------------------------------

Date: Tue, 3 Aug 1999 10:08:26 -0500
From: Michael Newman <Michae...@soph.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Message-ID: <014CEBE84B9BD2118FFB0008C74C5E3C2921@GRNSBORO>

The first thought that comes to my mind would be in the case of an
active run-unit aborting, and rolling out. All the necessary before
images will not be on the offloaded Journals after the start of the hot
backup. Therefore rollforward would not be able to then rollback the
aborted run-unit to its begin point (or last commit point) if not on
these journal offloads.

Back to you Hugh.

-----Original Message-----
From: Hugh Laderman [mailto:hu...@laderman.com]
Sent: Tuesday, August 03, 1999 10:52 AM
To: idm...@iuassn.com
Subject: Re: [IDMS-L]Re: RE: Hot Backups without
a QUIESCE point

Having seen the following reply, this subject has now
piqued my interest
enough to admit my probable ignorance in this area.
About 20 years ago, as
an IDMS systems programmer, I investigated the
possibility of "hot backups".
At the time, I couldn't find any IDMS user who had even
considered it
(although I imagine some had). It seemed to us that hot
backups would
present no problem and that there was no need for any
quiesce point. Since
roll forward would apply all after-images, all would be
fine as long as we
applied all journal updates beginning no later than the
start time of the
hot backup. (If we used some earlier journals, that
would be OK, since they
would be overlaid with more recent updates.)

Well, as it turned out, we never had the need to
actually do this; we were
always allowed a 4 hour per week window to shut down and
perform
maintenance. But now I'm curious. Can someone point out
the flaws in our
conclusion ? Thanks.

------------------------------

Date: Tue, 03 Aug 1999 08:50:29 -0700
From: Richard Phelps <Richard...@asu.edu>
To: 'IDMS-L' <IDM...@IUASSN.com>
Subject: RACF Groups
Message-ID: <8093ABAD9B81D211878...@mainex3.asu.edu>

This is my second posting for this.
Since there were no replies I assume it cannot be done?

I have a need for an assembler routine that returns to the COBOL invoker
a
list
of the RACF Groups the user is connected to.
OS/390 2.5, IDMS 14.0 DC

thanks for your help

------------------------------

Date: Tue, 3 Aug 1999 17:52:39 +0200
From: IESD <in1...@juliusbaer.com>
To: IDM...@IUASSN.COM
Subject: Optimizer?
Message-ID: <1999080316...@mailhost.ip-plus.net>

Has anyone gained any meaningful insights into the workings of the SQL
opt=
imizer? Specifically with reference to accessing Network databases. I
got =
the following..

I have REC1 and REC2.
Each has its own area.
Each has a system owned index.
REC1 is CALC and owns REC2 and REC2 is stored via REC1-REC2.
There are 200000 REC1 and 500000 REC2.
AREA1 is 10000 Pages and AREA2 is 20000 pages and the page size is the
sam=
e.

If I do ..

SELECT
ELE-REC1, ELE-REC2
FROM
REC1, REC2
WHERE
ELE-REC1 =3D 'X'
AND
"REC1-REC2"
;

Where ELE-REC1 does not exist in any CALC or Sort Key. You would expect
a =
programmer and the optimizer to

1. Area sweep AREA1.
2. For every REC1 which has ELE-REC1 =3D 'X' to walk REC1-REC2.

This would give between 10K and 30K I/Os depending on the frequency of
'X=
' and assuming no overflow..

But the optimiser doesn't do that. It does..

1.Read the REC2-Index.
2.Obtain owner for every REC2 in REC1-REC2.
3.See if REC1 has a value of 'X' in ELE-REC1.

This gives a mininum of 30K I/Os and in practice many more!

If I add OPTIMIZE for 500000 rows to the Select statement then it
chooses =
the obvious route.

In reality the answer is around 30 rows.

I realise as a consultant that I should know the answer already so don't
w=
aste my valuable time with silly talk.

Thanks

Chris Trayler

Bank Julius Baer
Database Administration
8001 Zuerich
Switzerland
Tel +41 1 4374608
Fax +41 1 4374475
http:\\www.juliusbaer.com
databas...@juliusbaer.com

------------------------------

Date: Tue, 3 Aug 1999 12:13:15 EDT
From: ARCH...@aol.com
To: idm...@iuassn.com
Subject: RE: Hot Backups without a QUIESCE point
Message-ID: <795ab9da...@aol.com>

We have a client that has been using hot backups for 8 years with no
problems
encountered. It has been put to the test numerous times and also used at
the
offsite disaster site numerous times without fail.

This site is Kemet Manufacturing in Greenville, SC, they are a CA-CAS
site
with plants all over the world.

Every night at around 8:00PM we force a journal offload and log offload
(DCMT
VARY JOURNAL). When these jobs are complete we then start the nightly
backups
while all the areas are online and in update mode.

This is not a very difficult procedure and we have had to use it
numerous
times over the years. If we need to use the journal files for manual
recovery
the procedure we use is FIRST offload the current active journal file,
then
restore from the hot backup and rollforward and rollback from the
journal
file backups.

Before you start picking holes in this procedure as I stated earlier we
have
been using it for 8 Years and it has always worked flawlessly, and we
have
performed the recovery a few times over the years and have also executed
our
recovery procedures at the Sungard offsite disaster recovery with no
problems.

------------------------------

Date: Tue, 3 Aug 1999 12:14:48 -0400
From: "Hanley, Frank" <Frank....@gs.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Message-ID: <851279708234D3118C7...@gsny26e.et.gs.com>

I disagree ... you see aborted run units on journal reports ...
roll-forward will apply the before images. hit the abort checkpoint, and

then do a roll back .

> -----Original Message-----
> From: Michael Newman [SMTP:Michae...@soph.com]
> Sent: Tuesday, August 03, 1999 11:08 AM
> To: 'idm...@iuassn.com'
> Subject: RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
>
> The first thought that comes to my mind would be in the case of an
> active run-unit aborting, and rolling out. All the necessary before
> images will not be on the offloaded Journals after the start of the
hot
> backup. Therefore rollforward would not be able to then rollback the
> aborted run-unit to its begin point (or last commit point) if not on
> these journal offloads.
>
> Back to you Hugh.
>
> -----Original Message-----
> From: Hugh Laderman [mailto:hu...@laderman.com]
> Sent: Tuesday, August 03, 1999 10:52 AM
> To: idm...@iuassn.com
> Subject: Re: [IDMS-L]Re: RE: Hot Backups without
> a QUIESCE point
>
> Having seen the following reply, this subject has now
> piqued my interest
> enough to admit my probable ignorance in this area.
> About 20 years ago, as
> an IDMS systems programmer, I investigated the
> possibility of "hot backups".
> At the time, I couldn't find any IDMS user who had even
> considered it
> (although I imagine some had). It seemed to us that hot
> backups would
> present no problem and that there was no need for any
> quiesce point. Since
> roll forward would apply all after-images, all would be
> fine as long as we
> applied all journal updates beginning no later than the
> start time of the
> hot backup. (If we used some earlier journals, that
> would be OK, since they
> would be overlaid with more recent updates.)
>
> Well, as it turned out, we never had the need to
> actually do this; we were
> always allowed a 4 hour per week window to shut down and
> perform
> maintenance. But now I'm curious. Can someone point out
> the flaws in our
> conclusion ? Thanks.
>
>
>

------------------------------

Date: Tue, 3 Aug 1999 12:45:32 -0500
From: Michael Newman <Michae...@soph.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Message-ID: <014CEBE84B9BD2118FFB0008C74C5E3C2922@GRNSBORO>

The rollback is my point:

I guess I didn't explain my first thought too well. After giving it some

more thought, I will try again with a scenario:

Run unit A starts at 10:00
Run unit B starts at 10:01

A journal is varied off line at 10:03
Hot backups commence at 10:04

Run unit C starts at 10:05
Run unit B completes at 10:10
Run unit C aborts at 10:11
Run unit A aborts at 10:12
Hot backups complete at 10:15
A journal is varied offline at 10:16

Time passes ........... (tick tock)

The Database gets corrupted, and needs to be restored.
The database is restored to the Hot backup.

A rollforward is initiated with the offloaded journal that was created
during the hot backup (verify off).
After images for Run unit A, B, and C begin being applied.
The end check point for Run unit B is applied.
The abort for Run unit C is encountered, and it is rolled back to its
begin check point, which is on this journal offload.
The abort for Run unit A is encountered, and needs to be rolled back.
Before images for Run unit A are applied until a commit, or begin
checkpoint, neither of which are on this journal offload.
My question is What happens now? Rollback cannot complete recover of
this run-unit.

That is why I think there is a need for a quiesce point, so that all
required journal images are on the offloaded journal tapes that must be
processed with the hot backup.

I have a client that will be looking into hot backups in the near
future, so any insight I can gather from the list will be very helpful.
-----Original Message-----
From: Hanley, Frank [mailto:Frank....@gs.com]
Sent: Tuesday, August 03, 1999 12:15 PM
To: 'idm...@iuassn.com'
Subject: RE: [IDMS-L]Re: RE: Hot Backups without
a QUIESCE point

I disagree ... you see aborted run units on journal
reports ... roll-forward will apply the before images. hit the abort
checkpoint, and then do a roll back .

> -----Original Message-----
> From: Michael Newman
[SMTP:Michae...@soph.com] <mailto:[SMTP:Michae...@soph.com]>
> Sent: Tuesday, August 03, 1999 11:08 AM
> To: 'idm...@iuassn.com'
> Subject: RE: [IDMS-L]Re: RE: Hot Backups
without a QUIESCE point
>
> The first thought that comes to my mind would
be in the case of an
> active run-unit aborting, and rolling out.

------------------------------

Date: Tue, 3 Aug 1999 14:08:18 -0400
From: "Migliaccio, Ray (Contractor)" <rmig...@harris.com>
To: 'IDMS-L' <idm...@iuassn.com>
Subject: maintain index
Message-ID: <C01E7037C8FBD1119F8B00805F6F0BB703F2ACB0@CORPMX7>

Can anyone explain if the maintain index utility can be used to rebuild
a user
owned index?

Ray Migliaccio
HARRIS Semiconductor
email rmig...@harris.com
phone (407) 729-5178

------------------------------

Date: Tue, 3 Aug 1999 14:16:09 -0400
From: "Hugh Laderman" <hu...@laderman.com>
To: "IDMS-L" <idm...@iuassn.com>
Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Message-ID: <007001bedddc$43f006a0$e2c0a4d8@oemcomputer>

Michael

Your point seems valid, but doesn't it simply mean that you must start
rolling forward from an earlier point in time ? You could, for instance,

apply all journals starting an hour prior to your hot backup (assuming
your
shop enforces a standard that any longer running update would have
commit
checkpoints).

Back to you.

Hugh

-----Original Message-----
From: Michael Newman <Michae...@soph.com>
To: 'idm...@iuassn.com' <idm...@iuassn.com>
Date: Tuesday, August 03, 1999 1:55 PM
Subject: RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point

>The rollback is my point:
>
>I guess I didn't explain my first thought too well. After giving it
some
>more thought, I will try again with a scenario:
>
>Run unit A starts at 10:00
>Run unit B starts at 10:01
>
>A journal is varied off line at 10:03
>Hot backups commence at 10:04
>
>Run unit C starts at 10:05
>Run unit B completes at 10:10
>Run unit C aborts at 10:11
>Run unit A aborts at 10:12
>Hot backups complete at 10:15
>A journal is varied offline at 10:16
>
>Time passes ........... (tick tock)
>
>The Database gets corrupted, and needs to be restored.
>The database is restored to the Hot backup.
>
>A rollforward is initiated with the offloaded journal that was created
>during the hot backup (verify off).
>After images for Run unit A, B, and C begin being applied.
>The end check point for Run unit B is applied.
>The abort for Run unit C is encountered, and it is rolled back to its
>begin check point, which is on this journal offload.
>The abort for Run unit A is encountered, and needs to be rolled back.
>Before images for Run unit A are applied until a commit, or begin
>checkpoint, neither of which are on this journal offload.
>My question is What happens now? Rollback cannot complete recover of
>this run-unit.
>
>That is why I think there is a need for a quiesce point, so that all
>required journal images are on the offloaded journal tapes that must be

>processed with the hot backup.
>
>I have a client that will be looking into hot backups in the near
>future, so any insight I can gather from the list will be very helpful.

out.

------------------------------

Date: Tue, 03 Aug 1999 14:32:59 -0400
From: "Parker, Lawrence" <lawrenc...@lmco.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]maintain index
Message-ID:
<60875A437C39D211BE86...@emss03m03.orl.lmco.com>

According to the utilities manual you can. You must write a program
which
calls IDMSTBLU and passes information about the indexes to be operated
on
and the owner and member record occurrences participating in the
indexes. I
have never done this but the instructions seem pretty straight forward.
Look in the Utilities Manual under MAINTAIN INDEX chapter.
Larry Parker

-----Original Message-----
From: Migliaccio, Ray (Contractor) [mailto:rmig...@harris.com]
Sent: Tuesday, August 03, 1999 14:08
To: 'IDMS-L'
Subject: [IDMS-L]maintain index

Can anyone explain if the maintain index utility can be used to rebuild
a
user
owned index?

Ray Migliaccio
HARRIS Semiconductor
email rmig...@harris.com
phone (407) 729-5178

------------------------------

Date: Tue, 3 Aug 1999 13:41:25 -0500
From: "Art Walker" <ar...@asg.com>
To: <idm...@iuassn.com>
Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Message-ID: <0c4501bedddf$caded800$8b03...@asg.net>

Hi All,

Time for me to weigh in on this issue.

It's always better to have a quiesce point and a journal that starts
with
it. The fewer things to go wrong during your emergency,
VP-breathing-down-your-neck recovery. For instance.. what GDG of journal

should I concat first? What time should I use for the roll forward
start.
These questions are not easy ones to answer in an emergency. Using
either
Virtual DB hot backup quiesce or Release 15 DCMT quiesce shouldn't be a
problem if you do it at a time when there is no batch. i.e. 5:15pm,
lunch
time, etc. Since it's a hot backup, it doesn't matter when you do it.
Waiting an average of 1/2 your average response time for a true,
unadulterated, areas offline, quiesce point seems worth it to me (less
than
5 seconds at most shops).

Art Walker
Allen Systems Group

------------------------------

Date: Tue, 03 Aug 1999 13:56:50 -0500 (CDT)
From: "Dick Reeser" <ree...@tiburontech.com>
To: "IDMS-L" <idm...@iuassn.com>,
"Migliaccio, Ray (Contractor)" <rmig...@harris.com>
Subject: Re: [IDMS-L]maintain index
Message-ID: <004792600190...@hammerhead.tiburontech.com>

On Tue, 3 Aug 1999 14:04:03 -0400, Migliaccio, Ray (Contractor) wrote:

>Can anyone explain if the maintain index utility
>can be used to rebuild a user owned index?

Hi Ray,

From the 12.01 Database Administration manual:

####################################
30.2.5 MAINTAIN INDEX utility statement

What MAINTAIN INDEX does: The MAINTAIN INDEX utility
statement allows you to build, rebuild, and delete both
system-owned and user-owned indexes (indexed sets).
You can also change the characteristics of an index, such
as changing an index key from a compressed to an
uncompressed format.

Steps to modify indexes: To make changes to an index,
follow the procedure described in "Procedure for modifying
the non-SQL definitions" in topic 30.2.2, adding the steps
listed in the following table.

<<<snip>>>
For user-owned indexes (indexed sets):
Write a program that calls IDMSTBLU and
passes descriptor information
<<<snip>>>
####################################

It's never easy, is it?

Dick Reeser
Tiburon Technologies
http://www.tiburontech.com

------------------------------

Date: Tue, 3 Aug 1999 13:54:51 -0500
From: "Art Walker" <ar...@asg.com>
To: <idm...@iuassn.com>
Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Message-ID: <0c6b01bedde1$ab441b20$8b03...@asg.net>

Oh and one last issue to think about..... What if you loose the pack
containing the active
disk journal during the backup??? (happened to me twice in two weeks).

----- Original Message -----
From: Art Walker <ar...@asg.com>
To: <idm...@iuassn.com>
Sent: Tuesday, August 03, 1999 1:41 PM
Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point

> Hi All,
>
> Time for me to weigh in on this issue.
>
> It's always better to have a quiesce point and a journal that starts
with
> it. The fewer things to go wrong during your emergency,
> VP-breathing-down-your-neck recovery. For instance.. what GDG of
journal
> should I concat first? What time should I use for the roll forward
start.
> These questions are not easy ones to answer in an emergency. Using
either
> Virtual DB hot backup quiesce or Release 15 DCMT quiesce shouldn't be
a
> problem if you do it at a time when there is no batch. i.e. 5:15pm,
lunch
> time, etc. Since it's a hot backup, it doesn't matter when you do it.
> Waiting an average of 1/2 your average response time for a true,
> unadulterated, areas offline, quiesce point seems worth it to me (less

than
> 5 seconds at most shops).
>
> Art Walker
> Allen Systems Group
>
>
>

------------------------------

Date: Tue, 3 Aug 1999 15:48:37 -0400
From: "David R Slocum" <drsl...@cmsenergy.com>
To: idm...@iuassn.com
Subject: RE: Hot Backups without a QUIESCE point
Message-ID: <852567C2.0...@pr1lns45.cpco.com>

I tend to agree with Art. We've been doing hot backups since at least
5.7 days
(maybe earlier). My approach has evolved slightly as I have come to
understand
a little more about the inner workings of the recovery process. Like
Art, I
can't afford to spin my wheels examining every journal archive to see if
there
are any aborted run units that start on a prior tape. We have multiple
applications on both of our production CVs. Because of processing
requirements,
these applications are backed up and restored separately. So, I would
not only
have to check for aborted run units that start on an earlier tape, I
would also
have to determine which application was involved and decide whether or
not it
affected the current recovery. We have also decided to use the sort
exit
feature to shorten our recovery time. When you do this, it is
imperative that
you establish appropriate quiesce points by varying areas offline and
varying a
journal. Our current backup approach looks like this:

1. Vary all areas for an application offline and vary a journal while
they are
still offline. The areas can be varied back online after the journal
has been
varied. We have a generic utility that we've written in COBOL that
allows us to
do this. UCFBATCH is called from within the COBOL program to vary the
areas and
the journal after all areas have been successfully readied in a
protected
retrieval mode by the COBOL program. This assures that the areas get
varied
offline without any problems (such as quiescing messages). The FINISH
isn't
issued until control is returned from UCFBATCH.

2. Run the backup job while the areas are in update mode to the CV.

3. After the backup has completed, vary the areas offline again and vary
another
journal. Vary the areas back online after the journal is varied. (The
same
COBOL program is used to do this as in step 1).

Our current recovery approach looks like this:

1. Restore the database from the backup tapes.

2. Do a normal (non-sort exit mode) rollforward using the journal tape
created
in step 3 of the backup process (also, if any other journals were
triggered
between step 1 and 3, then these would have to be included as well).
The
journal tapes should be processed by the FIX ARCHIVE utility before
being used
in the recovery (this will create ABRT checkpoints for all run units
that were
open at the end of the last journal tape - i.e., run units from the
other
applications that aren't currently being recovered). When this
rollforward is
done, the database will be a "snap-shot" of what it looked like when the
journal
was varied in step 3 of the backup process (i.e., no broken pointers or
any
other database integrity issues).

3. Do a sort exit mode rollforward using all journals that were created
after
step 3 of the recovery process. Again, the journal tapes must first be
processed by the FIX ARCHIVE utility.

Note that in step 2 of the recovery process I don't use the sort exit
mode
rollforward. This is important! Sort exit mode doesn't apply AFTR
images for
aborted run units. Let's say that run unit A updates page 23 in an
area. The
backup job then makes a copy of page 23. Finally, run unit A aborts and
rolls
back the changes on page 23. If you were to use the sort exit mode
rollforward
to rollforward the changes that took place during the backup, then page
23 would
end up containing the updates that were made by the aborted run unit!
Of
course, this assumes that page 23 is never updated again after it is
updated by
the aborted run unit.

There are other issues having to do with backup and recovery, but it
would take
me too long to dig up all the details (even if I could). The nice thing
about
the approach I describe above is that I have been able to build an
automated
recovery procedure that handles most of the details for me. All I've
got to do
is specify the application to be recovered, the date and time of the
first
quiesce point (we save this in a database), and the volume(s) to be
recovered.
The automated process then generates all of the JCL for performing the
recovery.
I could have my entire recovery completed in the time that it takes
someone to
determine which journal to start with using Hugh's approach.

DISCLAIMER: The views expressed in this note aren't necessarily those of
the
company.

David R. Slocum
Consumers Energy

"Art Walker" <ar...@asg.com> on 08/03/99 02:41:25 PM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: David R Slocum/Pr/Consumers/CMS)
Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point

Hi All,

Time for me to weigh in on this issue.

Art Walker
Allen Systems Group

------------------------------

Date: Tue, 3 Aug 1999 16:28:11 -0400
From: "Lupico, Joe" <Joe.L...@AIG.com>
To: "'IDM...@IUASSN.COM'" <IDM...@IUASSN.COM>
Subject: Program check in XASTGPL
Message-ID: <4F1E68B5C708D11180860001FA372A6501CAFC96@XCS_LIV01>

I wrote last week that I was getting program checks near XASTGPL.
After
the weekly IPL on Sunday, the problem has not occurred again. So, I had
the
problem every day for the five work days last week - never before and
not
after.

Now I see if I get away with using the resolution the PC people always

seem to invoke - I rebooted the server and the problem is gone.

Joe

------------------------------

Date: Tue, 3 Aug 1999 16:30:44 -0400
From: "Hugh Laderman" <hu...@laderman.com>
To: <idm...@iuassn.com>
Subject: Re: [IDMS-L]RE: Hot Backups without a QUIESCE point
Message-ID: <009a01beddef$121d87c0$e2c0a4d8@oemcomputer>

David

You seem to have much experience in this area, and have apparently put
much
effort into establishing, testing, and refining your procedures, and it
seems to be an excellent map for anyone to follow, but wouldn't it work
almost exactly the same without a quiesce point ? Please tell me if I'm
wrong, but selecting which journal offload to start with is a non-issue
(and
takes no time), because as long as it is some predetermined time
(roughly
equal to the length of the longest possible update without commits)
prior to
the start of the hot backup, it will work, i.e. you cannot possibly
start
with a journal which is too old as long as all succeeding journals are
used.
Obviously, to shorten recovery time, you wouldn't want to roll forward
from
last Thursday, but, if you did, it would work just fine.

-----Original Message-----
From: David R Slocum <drsl...@cmsenergy.com>
To: idm...@iuassn.com <idm...@iuassn.com>
Date: Tuesday, August 03, 1999 3:54 PM
Subject: [IDMS-L]RE: Hot Backups without a QUIESCE point

>I tend to agree with Art. We've been doing hot backups since at least
5.7
days
>(maybe earlier). My approach has evolved slightly as I have come to
understand
>a little more about the inner workings of the recovery process. Like
Art,
I
>can't afford to spin my wheels examining every journal archive to see
if
there
>are any aborted run units that start on a prior tape. We have multiple

>applications on both of our production CVs. Because of processing
requirements,
>these applications are backed up and restored separately. So, I would
not
only
>have to check for aborted run units that start on an earlier tape, I
would
also
>have to determine which application was involved and decide whether or
not
it
>affected the current recovery. We have also decided to use the sort
exit
>feature to shorten our recovery time. When you do this, it is
imperative
that
>you establish appropriate quiesce points by varying areas offline and
varying a
>journal. Our current backup approach looks like this:
>
>1. Vary all areas for an application offline and vary a journal while
they
are
>still offline. The areas can be varied back online after the journal
has
been
>varied. We have a generic utility that we've written in COBOL that
allows
us to
>do this. UCFBATCH is called from within the COBOL program to vary the
areas and
>the journal after all areas have been successfully readied in a
protected
>retrieval mode by the COBOL program. This assures that the areas get
varied
>offline without any problems (such as quiescing messages). The FINISH
isn't
>issued until control is returned from UCFBATCH.
>
>2. Run the backup job while the areas are in update mode to the CV.
>
>3. After the backup has completed, vary the areas offline again and
vary
another
>journal. Vary the areas back online after the journal is varied. (The

same
>COBOL program is used to do this as in step 1).
>
>Our current recovery approach looks like this:
>
>1. Restore the database from the backup tapes.
>
>2. Do a normal (non-sort exit mode) rollforward using the journal tape
created
>in step 3 of the backup process (also, if any other journals were
triggered
>between step 1 and 3, then these would have to be included as well).
The
>journal tapes should be processed by the FIX ARCHIVE utility before
being
used
>in the recovery (this will create ABRT checkpoints for all run units
that
were
>open at the end of the last journal tape - i.e., run units from the
other
>applications that aren't currently being recovered). When this
rollforward
is
>done, the database will be a "snap-shot" of what it looked like when
the
journal
>was varied in step 3 of the backup process (i.e., no broken pointers or
any
>other database integrity issues).
>
>3. Do a sort exit mode rollforward using all journals that were created

after
>step 3 of the recovery process. Again, the journal tapes must first be

>processed by the FIX ARCHIVE utility.
>
>Note that in step 2 of the recovery process I don't use the sort exit
mode

>rollforward. This is important! Sort exit mode doesn't apply AFTR
images
for
>aborted run units. Let's say that run unit A updates page 23 in an
area.
The
>backup job then makes a copy of page 23. Finally, run unit A aborts
and
rolls
>back the changes on page 23. If you were to use the sort exit mode
rollforward
>to rollforward the changes that took place during the backup, then page
23
would
>end up containing the updates that were made by the aborted run unit!
Of
>course, this assumes that page 23 is never updated again after it is
updated by
>the aborted run unit.
>
>There are other issues having to do with backup and recovery, but it
would
take
>me too long to dig up all the details (even if I could). The nice
thing
about
>the approach I describe above is that I have been able to build an
automated
>recovery procedure that handles most of the details for me. All I've
got
to do
>is specify the application to be recovered, the date and time of the
first
>quiesce point (we save this in a database), and the volume(s) to be
recovered.
>The automated process then generates all of the JCL for performing the
recovery.
>I could have my entire recovery completed in the time that it takes
someone
to
>determine which journal to start with using Hugh's approach.
>
>DISCLAIMER: The views expressed in this note aren't necessarily those
of
the
>company.
>
>David R. Slocum
>Consumers Energy

------------------------------

Date: Tue, 3 Aug 1999 21:27:37 +0100
From: Steve Cannon <can...@globalnet.co.uk>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]maintain index
Message-ID: <01BEDDF7.028...@globalnet.co.uk>

There is available through CA support - it is on the FTP site - a
generic
program for rebuilding user owned indexes. It was originally developed
for
CAS but made available to the general IDMS client base. You just give it

the parms for teh index you want to rebuild.

Steve Cannon
-----Original Message-----
From: Dick Reeser [SMTP:ree...@tiburontech.com]
Sent: 03 August 1999 19:57
To: IDMS-L; Migliaccio, Ray (Contractor)
Subject: Re: [IDMS-L]maintain index

On Tue, 3 Aug 1999 14:04:03 -0400, Migliaccio, Ray (Contractor) wrote:

>Can anyone explain if the maintain index utility
>can be used to rebuild a user owned index?

Hi Ray,

From the 12.01 Database Administration manual:

####################################
30.2.5 MAINTAIN INDEX utility statement

<<<snip>>>
For user-owned indexes (indexed sets):
Write a program that calls IDMSTBLU and
passes descriptor information
<<<snip>>>
####################################

It's never easy, is it?

Dick Reeser
Tiburon Technologies
http://www.tiburontech.com

------------------------------

Date: Tue, 3 Aug 1999 15:53:36 -0500
From: "Art Walker" <ar...@asg.com>
To: <idm...@iuassn.com>
Subject: Re: [IDMS-L]RE: Hot Backups without a QUIESCE point
Message-ID: <0c9101beddf2$422074c0$8b03...@asg.net>

Hi Hugh,

I agree that you could do it that way and on a low activity or low
importance CV, it really wouldn't hurt. But, the question is "how do you

know you have the last commit?". You could be arbitrary and go back, say
4
hours, into the last journal set, you'll most likely get it (unless an
MRP
rollup or some new batch job created by a defective programmer was
running).
But, that will add hours to your roll forward time on a pretty active
system. How much will it cost your company to be down each hour, or
minute
even? And, if you didn't get the last commit, how do you know because
you
ran with verify off.... Worse yet...What if your shop allows local-mode
update, ugh.

Art Walker
Allen Systems Group

----- Original Message -----
From: Hugh Laderman <hu...@laderman.com>
To: <idm...@iuassn.com>
Sent: Tuesday, August 03, 1999 3:30 PM
Subject: Re: [IDMS-L]RE: Hot Backups without a QUIESCE point

> David
>
> You seem to have much experience in this area, and have apparently put

much
> effort into establishing, testing, and refining your procedures, and
it
> seems to be an excellent map for anyone to follow, but wouldn't it
work
> almost exactly the same without a quiesce point ? Please tell me if
I'm
> wrong, but selecting which journal offload to start with is a
non-issue
(and
> takes no time), because as long as it is some predetermined time
(roughly
> equal to the length of the longest possible update without commits)
prior
to
> the start of the hot backup, it will work, i.e. you cannot possibly
start
> with a journal which is too old as long as all succeeding journals are

used.
> Obviously, to shorten recovery time, you wouldn't want to roll forward

from
> last Thursday, but, if you did, it would work just fine.
>
> -----Original Message-----
> From: David R Slocum <drsl...@cmsenergy.com>
> To: idm...@iuassn.com <idm...@iuassn.com>
> Date: Tuesday, August 03, 1999 3:54 PM
> Subject: [IDMS-L]RE: Hot Backups without a QUIESCE point
>
>
> >I tend to agree with Art. We've been doing hot backups since at
least
5.7
> days
> >(maybe earlier). My approach has evolved slightly as I have come to
> understand
> >a little more about the inner workings of the recovery process. Like

Art,
> I
> >can't afford to spin my wheels examining every journal archive to see
if
> there
> >are any aborted run units that start on a prior tape. We have
multiple
> >applications on both of our production CVs. Because of processing
> requirements,
> >these applications are backed up and restored separately. So, I
would
not
> only
> >have to check for aborted run units that start on an earlier tape, I
would
> also
> >have to determine which application was involved and decide whether
or
not
> it
> >affected the current recovery. We have also decided to use the sort
exit
> >feature to shorten our recovery time. When you do this, it is
imperative
> that
> >you establish appropriate quiesce points by varying areas offline and

> varying a
> >journal. Our current backup approach looks like this:
> >
> >1. Vary all areas for an application offline and vary a journal while

they
> are
> >still offline. The areas can be varied back online after the journal
has
> been
> >varied. We have a generic utility that we've written in COBOL that
allows
> us to
> >do this. UCFBATCH is called from within the COBOL program to vary
the
> areas and
> >the journal after all areas have been successfully readied in a
protected
> >retrieval mode by the COBOL program. This assures that the areas get

> varied
> >offline without any problems (such as quiescing messages). The
FINISH
> isn't
> >issued until control is returned from UCFBATCH.
> >
> >2. Run the backup job while the areas are in update mode to the CV.
> >
> >3. After the backup has completed, vary the areas offline again and
vary
> another
> >journal. Vary the areas back online after the journal is varied.
(The
> same
> >COBOL program is used to do this as in step 1).
> >
> >Our current recovery approach looks like this:
> >
> >1. Restore the database from the backup tapes.
> >
> >2. Do a normal (non-sort exit mode) rollforward using the journal
tape
> created
> >in step 3 of the backup process (also, if any other journals were
triggered
> >between step 1 and 3, then these would have to be included as well).
The
> >journal tapes should be processed by the FIX ARCHIVE utility before
being
> used
> >in the recovery (this will create ABRT checkpoints for all run units
that
> were
> >open at the end of the last journal tape - i.e., run units from the
other
> >applications that aren't currently being recovered). When this
rollforward
> is
> >done, the database will be a "snap-shot" of what it looked like when
the
> journal
> >was varied in step 3 of the backup process (i.e., no broken pointers
or
any
> >other database integrity issues).
> >
> >3. Do a sort exit mode rollforward using all journals that were
created
> after
> >step 3 of the recovery process. Again, the journal tapes must first
be
> >processed by the FIX ARCHIVE utility.
> >
> >Note that in step 2 of the recovery process I don't use the sort exit

mode
>
> >rollforward. This is important! Sort exit mode doesn't apply AFTR
images
> for
> >aborted run units. Let's say that run unit A updates page 23 in an
area.
> The
> >backup job then makes a copy of page 23. Finally, run unit A aborts
and
> rolls
> >back the changes on page 23. If you were to use the sort exit mode
> rollforward
> >to rollforward the changes that took place during the backup, then
page
23
> would
> >end up containing the updates that were made by the aborted run
unit! Of
> >course, this assumes that page 23 is never updated again after it is
> updated by
> >the aborted run unit.
> >
> >There are other issues having to do with backup and recovery, but it
would
> take
> >me too long to dig up all the details (even if I could). The nice
thing
> about
> >the approach I describe above is that I have been able to build an
> automated
> >recovery procedure that handles most of the details for me. All I've
got
> to do
> >is specify the application to be recovered, the date and time of the
first
> >quiesce point (we save this in a database), and the volume(s) to be
> recovered.
> >The automated process then generates all of the JCL for performing
the
> recovery.
> >I could have my entire recovery completed in the time that it takes
someone
> to
> >determine which journal to start with using Hugh's approach.
> >
> >DISCLAIMER: The views expressed in this note aren't necessarily those
of
> the
> >company.
> >
> >David R. Slocum
> >Consumers Energy
>
>
>

------------------------------

Date: Tue, 03 Aug 1999 17:04:35 -0400
From: "Mark CONS:Caffrey" <DBA...@mbusa.com>
To: <Idm...@iuassn.com>
Subject: Re: [IDMS-L]RE: Hot Backups without a QUIESCE point
Message-ID: <s7a721...@mbna.com>

Quite an interesting conversation.
In relation to using journals created prior to your hot backup, my =
question is: What happens if the prior journal has an erase of a dbkey
on =
it? When it is used in rollforward, along with your backup, won't IDMS =

stumble trying to erase a dbkey that doesn't exist?
Mark

>>> "Hugh Laderman" <hu...@laderman.com> 08/03 4:30 PM >>>
David

You seem to have much experience in this area, and have apparently put =

much
effort into establishing, testing, and refining your procedures, and it
seems to be an excellent map for anyone to follow, but wouldn't it work
almost exactly the same without a quiesce point ? Please tell me if I'm
wrong, but selecting which journal offload to start with is a non-issue
=
(and
takes no time), because as long as it is some predetermined time
(roughly
equal to the length of the longest possible update without commits)
prior =
to
the start of the hot backup, it will work, i.e. you cannot possibly
start
with a journal which is too old as long as all succeeding journals are =

used.
Obviously, to shorten recovery time, you wouldn't want to roll forward =

from
last Thursday, but, if you did, it would work just fine.

>I tend to agree with Art. We've been doing hot backups since at least
=
5.7
days
>(maybe earlier). My approach has evolved slightly as I have come to
understand
>a little more about the inner workings of the recovery process. Like =

Art,
I
>can't afford to spin my wheels examining every journal archive to see
if
there
>are any aborted run units that start on a prior tape. We have multiple

>applications on both of our production CVs. Because of processing
requirements,
>these applications are backed up and restored separately. So, I would
=
not
only
>have to check for aborted run units that start on an earlier tape, I =
would
also
>have to determine which application was involved and decide whether or
=
not
it
>affected the current recovery. We have also decided to use the sort
exit
>feature to shorten our recovery time. When you do this, it is
imperative
that
>you establish appropriate quiesce points by varying areas offline and
varying a
>journal. Our current backup approach looks like this:
>
>1. Vary all areas for an application offline and vary a journal while =

they
are
>still offline. The areas can be varied back online after the journal
has
been
>varied. We have a generic utility that we've written in COBOL that =
allows
us to
>do this. UCFBATCH is called from within the COBOL program to vary the
areas and
>the journal after all areas have been successfully readied in a
protected
>retrieval mode by the COBOL program. This assures that the areas get
varied
>offline without any problems (such as quiescing messages). The FINISH
isn't
>issued until control is returned from UCFBATCH.
>
>2. Run the backup job while the areas are in update mode to the CV.
>
>3. After the backup has completed, vary the areas offline again and
vary
another
>journal. Vary the areas back online after the journal is varied. (The

same
>COBOL program is used to do this as in step 1).
>
>Our current recovery approach looks like this:
>
>1. Restore the database from the backup tapes.
>
>2. Do a normal (non-sort exit mode) rollforward using the journal tape
created
>in step 3 of the backup process (also, if any other journals were =
triggered
>between step 1 and 3, then these would have to be included as well).
The
>journal tapes should be processed by the FIX ARCHIVE utility before
being
used
>in the recovery (this will create ABRT checkpoints for all run units
that
were
>open at the end of the last journal tape - i.e., run units from the
other
>applications that aren't currently being recovered). When this
rollforwar=
d
is
>done, the database will be a "snap-shot" of what it looked like when
the
journal
>was varied in step 3 of the backup process (i.e., no broken pointers or
=
any
>other database integrity issues).
>
>3. Do a sort exit mode rollforward using all journals that were created

after
>step 3 of the recovery process. Again, the journal tapes must first be

>processed by the FIX ARCHIVE utility.
>
>Note that in step 2 of the recovery process I don't use the sort exit =

mode

>rollforward. This is important! Sort exit mode doesn't apply AFTR =
images
for
>aborted run units. Let's say that run unit A updates page 23 in an
area.
The
>backup job then makes a copy of page 23. Finally, run unit A aborts
and
rolls
>back the changes on page 23. If you were to use the sort exit mode
rollforward
>to rollforward the changes that took place during the backup, then page
=
23
would
>end up containing the updates that were made by the aborted run unit!
Of
>course, this assumes that page 23 is never updated again after it is
updated by
>the aborted run unit.
>
>There are other issues having to do with backup and recovery, but it =
would
take
>me too long to dig up all the details (even if I could). The nice
thing
about
>the approach I describe above is that I have been able to build an
automated
>recovery procedure that handles most of the details for me. All I've
got
to do
>is specify the application to be recovered, the date and time of the =
first
>quiesce point (we save this in a database), and the volume(s) to be
recovered.
>The automated process then generates all of the JCL for performing the
recovery.
>I could have my entire recovery completed in the time that it takes =
someone
to
>determine which journal to start with using Hugh's approach.
>
>DISCLAIMER: The views expressed in this note aren't necessarily those
of
the
>company.
>
>David R. Slocum
>Consumers Energy

------------------------------

Date: Tue, 3 Aug 1999 21:59:18 +0100
From: Steve Cannon <can...@globalnet.co.uk>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]maintain index
Message-ID: <01BEDDFB.6FE...@globalnet.co.uk>

Just to make life easy - follow the link ( better than the yellow brick
road ) .. ftp://ftp.cai.com/CAproducts/idms/RBLDINDX

Everything you need to know is in there.

Steve Cannon

-----Original Message-----
From: Steve Cannon [SMTP:can...@globalnet.co.uk]
Sent: 03 August 1999 21:28
To: 'idm...@iuassn.com'
Subject: RE: [IDMS-L]maintain index

the parms for teh index you want to rebuild.

Steve Cannon
-----Original Message-----
From: Dick Reeser [SMTP:ree...@tiburontech.com]
Sent: 03 August 1999 19:57
To: IDMS-L; Migliaccio, Ray (Contractor)
Subject: Re: [IDMS-L]maintain index

On Tue, 3 Aug 1999 14:04:03 -0400, Migliaccio, Ray (Contractor) wrote:

>Can anyone explain if the maintain index utility
>can be used to rebuild a user owned index?

Hi Ray,

From the 12.01 Database Administration manual:

####################################
30.2.5 MAINTAIN INDEX utility statement

<<<snip>>>
For user-owned indexes (indexed sets):
Write a program that calls IDMSTBLU and
passes descriptor information
<<<snip>>>
####################################

It's never easy, is it?

Dick Reeser
Tiburon Technologies
http://www.tiburontech.com

------------------------------

Date: Tue, 3 Aug 1999 11:55:33 -0700
From: Chrissy...@ual.com
To: IDM...@iuassn.com, hu...@laderman.com
Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Message-ID:
<0B0350E3*/DD.ID=u142766/PN=Chrissy.Howard/OU=sfoko/OU=sfo/O=UAL/PRMD=UAL/ADMD=IBMX400/C=US/@MHS>

We at United Airlines SFO indeed backed up our IDMS databases in that
way (beginning in 1989). We varied the journals and then backed up all
the production databases using ADRDSSU. When the backups were complete
we varied the journals again. I know that it works because I
(unfortunately) had to do a recovery. However I found that this method
took quite a bit of time when only one database needed to be recovered
since the backup contained all the production databases.
We have since changed our backup scenario to back up each database
(application) separately. The journals are varied and a sync point is
taken by varying the specific database exclusive retrieval. When the
vary is complete we then vary the database update and back it up.
On-line jobs are rarely affected. Our scheduling software is set up
not to allow any other batch job for the specific database to run for
the duration of the backup. We use ADRDSSU for the backups and it is
fast. At the end of the backup we take another sync point and vary the
journals.
We have a backup database that documents the beginning and ending synch
points. The database can be restored and rolled forward beginning with
the first journal after the beginning sync point. If rolled forward to
the second sync point, a good point-in-time database can be created. We
do this on a regular basis to create realistic test data and to
research production problems.
We run a 24X7 shop. The CVs are shut down once a week for less than 15
minutes to compress libraries.
Hope that this helps.
Chrissy Howard - United Airlines SFOKO

----------
From: IDMS-L(a)iuassn.com; hugh(a)laderman.com
To: idms-l(a)iuassn.com
Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Date: Tuesday, August 03, 1999 7:53AM

Having seen the following reply, this subject has now piqued my interest

conclusion ? Thanks.

Hugh Laderman
Laderman Associates
(215) 493-3460 Voice
(215) 493-0573 Fax

------------------------------

Date: Tue, 3 Aug 1999 17:12:22 -0400
From: "David R Slocum" <drsl...@cmsenergy.com>
To: idm...@iuassn.com
Subject: RE: Hot Backups without a QUIESCE point
Message-ID: <852567C2.0...@pr1lns45.cpco.com>

Hugh,

Are you purposefully playing "devil's advocate?" In a small shop with
very
little (read "none") update activity going on during the backup, you
might be
able to get by with the approach that you're describing. You might even
get
away with your approach 95% of the time in a highly active shop.
However, it's
going to come around and bite you sooner or later. There was a group of

individuals in the IUA that researched this quite extensively a few
years back.
They worked closely with CA to try and uncover all of the potential
pitfalls
that lurked in the recovery process. The end result was the IUA's Hot
Backup
package. We took our original backup and recovery methodology and
modified it
to take into account what we learned from the IUA's efforts. We have
made only
one or two modifications since then. I would rather use a procedure
that is
guaranteed to work 100% of the time under any circumstances, than use
the
"Russian roulette" approach and hope I don't get shot. True, most times
you're
not going to have an aborted run unit spanning your first journal
archive tape,
but "most times" isn't something I would want to stake my career on. I
also
have a problem with your phrase "the longest possible update without
commits."
What time do I plug in here? One minute? Ten minutes? An hour? I
know we
shouldn't have them, but there are some batch jobs in our shop that run
for
better than an hour without doing commits (we've tried to educate the
programmers, but to no avail). During that hour we can spin a lot of
journals.
Including all of these journals in our recovery can add substantially to
our
recovery time. What price are you willing to pay to minimize down
time? For
me, taking a couple of seconds to quiesce the system before and after
the backup
is well worth the effort.

In your previous notes, you make no mention of whether or not you use
the
sort-exit mode recovery feature. This feature can significantly reduce
your
recovery time if you're a 24-hour heavy update shop like we are. This
feature
is also known to have problems if you don't use it the way I described
in my
previous note. I mentioned one of the possible scenarios in that note.
There
are others. You can avoid some of these problems by choosing not to use
the
sort-exit feature, but then your recovery times could be double what
they would
be if you did use the feature, or worse. For me this whole thing is a
no-brainer. I choose to use the backup and recovery methodology that
will
ensure that I can recover a database under any situation in the shortest

possible time frame without jeopardizing database integrity.

DISCLAIMER: The views expressed in this note aren't necessarily those of
the
company.

David R. Slocum
Consumers Energy

------------------------------

Date: Tue, 03 Aug 1999 17:34:49 -0400
From: "Mark CONS:Caffrey" <DBA...@mbusa.com>
To: <Idm...@iuassn.com>
Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Message-ID: <s7a728...@mbna.com>

Chrissy,
If you are using ADRDSSU, and taking a sync point (quiesce point), then
=
why don't you use the concurrent copy option?
Then you have a backup that is complete, and not "hot". You don't have
to =
worry about any of these issues.
Mark

>>> <Chrissy...@ual.com> 08/03 2:55 PM >>>
We at United Airlines SFO indeed backed up our IDMS databases in that=20

way (beginning in 1989). We varied the journals and then backed up
all=20
the production databases using ADRDSSU. When the backups were
complete=20
we varied the journals again. I know that it works because I=20
(unfortunately) had to do a recovery. However I found that this
method=20
took quite a bit of time when only one database needed to be
recovered=20
since the backup contained all the production databases. =
=09
We have since changed our backup scenario to back up each database=20
(application) separately. The journals are varied and a sync point
is=20
taken by varying the specific database exclusive retrieval. When the=20
vary is complete we then vary the database update and back it up.=20
On-line jobs are rarely affected. Our scheduling software is set up=20
not to allow any other batch job for the specific database to run
for=20
the duration of the backup. We use ADRDSSU for the backups and it is=20
fast. At the end of the backup we take another sync point and vary
the=20
journals.
We have a backup database that documents the beginning and ending
synch=20
points. The database can be restored and rolled forward beginning
with=20
the first journal after the beginning sync point. If rolled forward
to=20
the second sync point, a good point-in-time database can be created.
We=20
do this on a regular basis to create realistic test data and to=20
research production problems.
We run a 24X7 shop. The CVs are shut down once a week for less than
15=20
minutes to compress libraries.
Hope that this helps.
Chrissy Howard - United Airlines SFOKO

----------
From: IDMS-L(a)iuassn.com; hugh(a)laderman.com
To: idms-l(a)iuassn.com
Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Date: Tuesday, August 03, 1999 7:53AM

Having seen the following reply, this subject has now piqued my interest

enough to admit my probable ignorance in this area. About 20 years ago,
as
an IDMS systems programmer, I investigated the possibility of "hot =
backups".
At the time, I couldn't find any IDMS user who had even considered it
(although I imagine some had). It seemed to us that hot backups would
present no problem and that there was no need for any quiesce point.
Since
roll forward would apply all after-images, all would be fine as long as
we
applied all journal updates beginning no later than the start time of
the
hot backup. (If we used some earlier journals, that would be OK, since =

they
would be overlaid with more recent updates.)

conclusion ? Thanks.

Hugh Laderman
Laderman Associates
(215) 493-3460 Voice
(215) 493-0573 Fax

------------------------------

Date: Tue, 3 Aug 1999 18:31:44 -0400
From: "Hugh Laderman" <hu...@laderman.com>
To: <idm...@iuassn.com>
Subject: Re: [IDMS-L]RE: Hot Backups without a QUIESCE point
Message-ID: <001801beddff$f8556ea0$51c0a4d8@oemcomputer>

Art, David, et al

Many thanks for the education. It is greatly appreciated. I am no longer

curious (and Chris H would probably add "neither curious yellow nor
curious
blue").

-----Original Message-----
From: Art Walker <ar...@asg.com>
To: idm...@iuassn.com <idm...@iuassn.com>
Date: Tuesday, August 03, 1999 5:03 PM
Subject: Re: [IDMS-L]RE: Hot Backups without a QUIESCE point

>Hi Hugh,
>
> I agree that you could do it that way and on a low activity or low
>importance CV, it really wouldn't hurt. But, the question is "how do
you
>know you have the last commit?". You could be arbitrary and go back,
say 4
>hours, into the last journal set, you'll most likely get it (unless an
MRP
>rollup or some new batch job created by a defective programmer was
running).
>But, that will add hours to your roll forward time on a pretty active
>system. How much will it cost your company to be down each hour, or
minute
>even? And, if you didn't get the last commit, how do you know because
you
>ran with verify off.... Worse yet...What if your shop allows local-mode

>update, ugh.
>
>Art Walker
>Allen Systems Group
>

------------------------------

End of IDMS-L V1 #45
********************

Chris Hoelscher

unread,

Aug 12, 1999, 3:00:00 AM8/12/99

To: <IDM...@iuassn.com>
Subject: IDMS-L V1 #46

IDMS-L Thu, 5 Aug 1999 Volume 1 :
Number 46

In this issue:

William Mitzmacher/NYLIC is out of the office.
RE: [IDMS-L]maintain index
Hot Backups , Quiesce etc
FW: Optional apar gs96467
RE: [IDMS-L]maintain index
Re: [IDMS-L]Hot Backups , Quiesce etc
Re: [IDMS-L]Hot Backups , Quiesce etc
RE: [IDMS-L]Hot Backups , Quiesce etc
Re: [IDMS-L]Hot Backups , Quiesce etc
RE: digest youself
LE/370 and Storage
expand of multiple areas in a file
Re: RE: [IDMS-L]E-Net
RE: [IDMS-L]LE/370 and Storage
Re: [IDMS-L]expand of multiple areas in a file
RE: [IDMS-L]expand of multiple areas in a file
RE: updating CLISTIN datasets

RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point

RE: [IDMS-L]expand of multiple areas in a file
RE: Hot Backups
RE: Hot Backups
RE: unsubscribe

RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point

RE: [IDMS-L]RE: Hot Backups
Hot Backups and E-Net Software
Re: [IDMS-L]LE/370 and Storage

Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point

Re: [IDMS-L]LE/370 and Storage
RE: [IDMS-L]expand of multiple areas in a file

----------------------------------------------------------------------

Date: Wed, 4 Aug 1999 04:55:31 -0400
From: "William Mitzmacher" <William_M...@NEWYORKLIFE.COM>
To: IDM...@iuassn.com (IDMS-L)
Subject: William Mitzmacher/NYLIC is out of the office.
Message-ID: <852567C3.0...@Email.NewYorkLife.com>

I will be out of the office from 08/02/99 until 08/06/99.

If you need immediate assistance please contact Roberta McCrorey x5937,
or
Poerwo Soeasono x6857

------------------------------

Date: Wed, 4 Aug 1999 10:29:52 +0100
From: "Shaw, Brock" <brock...@MBUK.Mercedes-Benz.com>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]maintain index

Message-ID: <81C700BB8A25D3119EE50010E360DAC6087A4F@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_01BEDE5B.82E6B320
Content-Type: text/plain;
charset="iso-8859-1"

Steve,

Yes RBLDINDX is an excellent guide to the process. I have had such
examples
mentioned from time to time, but can you direct the IDMS-L list to where
a
comprehensive catalogue of such FTPable CA items can be found.

Best regards,
Brock.

Brock Shaw, DBA (ISD)
Mercedes Benz (UK), England

-----Original Message-----
From: Steve Cannon [mailto:can...@globalnet.co.uk]
Sent: 03 August 1999 21:59
To: 'idm...@iuassn.com'
Subject: RE: [IDMS-L]maintain index

Just to make life easy - follow the link ( better than the yellow brick
road
) .. ftp://ftp.cai.com/CAproducts/idms/RBLDINDX

Everything you need to know is in there.

Steve Cannon

-----Original Message-----

------_=_NextPart_001_01BEDE5B.82E6B320
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]maintain index

Steve,

Yes RBLDINDX is an excellent guide to the = process. I have had such
examples mentioned from time to time, = but can you direct the IDMS-L
list to where a comprehensive catalogue = of such FTPable CA items can
be found.

Best regards,
Brock.

Brock Shaw, DBA (ISD)
Mercedes Benz (UK), England

-----Original Message-----
From: Steve Cannon [mailto:can...@globalnet.co.uk]
Sent: 03 August 1999 21:59
To: 'idm...@iuassn.com'
Subject: RE: [IDMS-L]maintain index

Just to make life easy - follow the link ( better = than the yellow
brick road ) .. ftp://ftp.cai.com/CAproducts/idms/RBLDINDX<= /P>

Everything you need to know is in there.

Steve Cannon

-----Original Message-----

------_=_NextPart_001_01BEDE5B.82E6B320--

------------------------------

Date: Wed, 4 Aug 1999 12:00:31 +0100
From: peter.g...@bt.com
To: IDM...@IUASSN.COM
Subject: Hot Backups , Quiesce etc
Message-ID:
<5F54BE0116BCD2118C9...@mclmsent02.lon.bt.com>

------_=_NextPart_000_01BEDE68.89EAD54A
Content-type: text/plain; charset="iso-8859-1"

The important issue with any back up strategy is of course to be sure
that
you can recover. This means that you have to be CERTAIN that your
backups
and journals contain ALL the data required to get you back to the point
of
failure. Now if a quiesce point is not taken before the back up then you

have the problem of guaranteeing that all the data you require is on the

backup or journals.

Lets take an extreme case.

I have a very large buffer pool and a process that updates a record then

does lots and lots of read only. The update causes the before and after
for
the update to be written to Journal 1. This fills and so does journal 2.
The
database page is not yet written to the database since my process has
not
yet issued a commit or finish. I now start my backup.

In this scenario I need the offloads of J1 J2 and J3 to guarantee my
recovery. I for one do not want to go checking that I have all the data
I
need on my journals when my system is down and people are breathing down
my
neck to get it back ASAP. So by taking the quiesce point and then
varying
journals I have a known and guaranteed 'recovery set' consisting of my
backup and all journals created after the vary journal.

The above is an extreme case but I have known the occasional production
program to go into a loop reading the same record again and again..
thus causing the situation described above.

The problem with taking the quiesce point is that all update activity
must
stop. This is becoming more and more difficult as batch work must be
scheduled round the quiecse. At the shop where I am a consultant this
became
a major issue. On many occasions the quiesce had problems due to batch
work
over running. These were 'well behaved' batch jobs that issued commits
but
still had areas in update. This meant operators had to figure out what
was
going on decide what action to take and quite often this meant they had
to
call the DBA.

What was required was a process that enabled them to take the backup
without
the quiesce but also have a known and 100% reliable recovery set. To
achieve
this EZ-SoftQuiesce from Cogito was developed ( Gary-b has already
posted a
description of this ). In simple terms the process is to vary the
journals
and start the SoftQuiesce. When the SoftQuiesce process ends the backup
is
started. All the time this is happening current updates continue to run
and
new updates are allowed to start. There is no vary to retrieval required
and
hence no impact on batch scheduling. The process ensures that ALL data
required for a recovery is either on the journals created since the vary

journal or on the backup. The process is fully automated at this shop
and
does not require any human intervention. The process has been in place
for
several years and many recoveries performed. Most of these recoveries
were
to get a static copy of the database for offline processes such as DBAN,

unload reload testing etc.

Pete

------_=_NextPart_000_01BEDE68.89EAD54A
Content-type: application/ms-tnef
Content-transfer-encoding: base64

eJ8+IhQLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy

b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcIAAQADAAAAB8AAwAQAQEggAMADgAAAM8HCAAE

AAwAAAASAAMAAwEBCYABACEAAABGRDNGMUM4RjU1NEFEMzExOEM5QjAwNjA2REQ2MTRFRABLBwEE

gAEAGwAAAEhvdCBCYWNrdXBzICwgUXVpZXNjZSBldGMgAMsIAQ2ABAACAAAAAgACAAEDkAYAcAwA

AC0AAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAAFRIAAB4AJYAIIAYAAAAAAMAAAAAAAABG

AAAAAFSFAAABAAAABQAAADguMDMAAAAAAwAmgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAAL

AACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsAL4AIIAYAAAAAAMAAAAAAAABGAAAAAA6F

AAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADADCACCAGAAAAAADAAAAAAAAA

RgAAAAARhQAAAAAAAAMAMoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgBBgAggBgAAAAAA

wAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AQoAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAAB

AAAAAQAAAAAAAAAeAEOACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAAgEJEAEA

AAAbBwAAFwcAAFQMAABMWkZ1Vp56+gMACgByY3BnMTI1JjIA+AtgbmcB0DU3nQH3IAKkA+MCAGNo

CsBgc2V0MCAHEwKAfRkKgXVjAFALA3VsbgUCIGULpiBUaGUgfQdwcAkRAHAFQAQBClAgEQPwdGgg

AHB5IGIBANBrIHVwIHN0YHJhdGVnFWAEACA4b2YgBaAIcBEwIHT+bxVwE9AUsAlwF1ARAAVAvnkI

YBbgA5EJcAWgdgSQ/i4ToRaRB4AGIhgXEQAZIAEXVUNFUlRBSU4/GAcFwBWCFdAEIABwZCD6aghh

bgdABCAFoAIwC3FZEXBMTBgBE9BkFjBhsRjRcXVpCXEXUmcRQP8YUxWDF2EekhQQC4AFQBbBnmYL

cApACXAZUE5vB+DbBpAVMCAfQQeQYyEGFpH3EuAFQAGQawnwF4ECEBfj/xPQFYYekQOgGngg8gNg

AmDkZW0Wsmd1CsAUUQng/QuAZxgEB0ADIB6XGGIfJb8WgwOgJPYV0QWxHUYuCqJ7CoQKgEwRQBoB

JDEVMSD8ZXgWECcgE9AYoBEwGVB9LApJGqQfABkhFWALYHL7H+AVcHUBIASQIREG8Bzz/x8AJtEj

IAQRGBMV0B7RB5HPHwIFoR+RJcJkbweRCQDfLOEdAjQTFsEJcGEdIAIgvGx5GVIT0DJkGJF1ETD/

GgIlESSUMTMBgDCxJKEeg3s2FRdkdwUQAkAkURdhSukdVCAxGVVmAxAdoR0CznMXcDPDHUUgMjW0

HtLfFYAXMQqwMEEjtXkf8TmZ1x6WPZMAkG4jIW0VYDGWnxEAPkgUkzFSBaBtbRUA5ysyO0ADAHNo

GVAvMBLg/wfgFgAKwAVAQMEchC5dKnL/FpEjER2ABRAXcEPhCeAzU5sWsQ7wbzVAFqNKMTow8jIc

80ozH6MnlkCyGOW/NaEvMDhCEvEzsSPTdxRS7x+yF3AQ8AWQaygXLzYoum9HJSphQMEdR3clwkDB

c955FgAnIRaRM8B3A6AdArhwZW8LUC1BF+FiNSH/RkEoIVFjQMETACCEH+JDAaEVg0FTQVAZUFMX

cX8VYCQhKBQT0CLcHQIls3bdCsB5KBIdRy83a0QBUZTzJ4cdIFxsH0Aj8BPQSmb/FfARQAAQWvQd

wgCQFgAoEv8WwUSnMSQosR1IUrJCcjfz/x6SV+IdNiv7E7IBoBkRFoLfLW0wYU2HWYRHk2MuEUbw

+zqCJtFkEjBdACphJtEJwP5hJzBMZCFBF3AfAAkAUhD7NRNV9nNmsFs0M0E98B4S+zEzaZIuLlYV

EDagNnNoR/8VACeQZhMBAATyF5AxUWIy/y5cE7Im1hTzVc8jOShXNhXbANBdAHYVABVgbTagBUD/

FgBSEBlVFpEXkELBKBIEYP83dXSjaDABIA3gEsAogXPx/xYwEPAU4AWwFbBy4xeSTMFvZeAnEB0g

A2B1V2RwM2PtLjJBJAFokmhn0VBBF+H/LzBmsUKiAIB14UwjGYJ0EX9o0h8AAMAdQAXAFJMZUE//

T2EVQmUGNtRwRhEAUdEm5P9RQRTBF2J2aBkSGNB4QAMA9w8gNbMXMXd6MlrWglAosb8XkBqyCzBc

JnZUHUBiGgX/QjVCxHPxY8Fc8SixfyJSYf9BgR4hMmQZWSFhUfAWIQWw/0FSH5M7QCeAF+EIYD7B

GCKfTBAEIEyQXRNskmNpAQD/irRyUipiIMEtJB0gH0E2Uf8WwDnTiGgekRVgiaUYoCi16ERCQS5c

V4rWHyeLEv8xfUaxJwEzU2bDLRMqmRTyP4qCcApjsh2RF3BZHzEw9DAlGNFsBzAnAVtLGVEfZ3EQ

8AiQJmMWkUVaLXtVYAGAUSLlA1JcgAhQZ/8VABdwixIBABkgCQBR8B0gyCggR1fxLWJBYwdA+zUi

QNFvUOExUmy0BTBmIvsWwUZDKUPBA6AAkBQAUjH/OAF/wSaVMcNxIhdwYFMekv8dRzujRFMekpvJ

GVCRoI5j/6WLMYcJ8EgxKplGYkRSCYB/eTEotV0ALeFGQxaREQBw/1HwgZIW4AhwCXAUYTJmHdL/

C4CABIFhHPMTAAfgMmc3cv8osCJQH4REQzWzKgQS4KOV/62REUAIgVfgAyAfJx0CJcH/IyGw4RPx

clEqUnZUd4WBpv+nuRfCGgUeUh7cOEIy5C/D/xaRKAAekUtCo+xfNkBkYB7/KzIqa7U8OxISwDWQ

FTBjwP8DcV9ze3V5wx0CM8Mj4im2/xVCaxADgiFBBJAZIK0RAiD/tTxBcheQJFEeIQtRnFIFsf8R

MBkhOpE+oBERdOQVQhjluyLxUeFyJKEHgKnRTZ+R/6DEghLGyYJTH7UfAERBXQD6YxbhcH2hyIM9

SEsjR+F/C4CipweRFLB2gUGBkJFO/iwVwDWASBGZEs7CMqFdA+0RQGMr+ywEUBFAExAsEwUR8QDS

MAALAAIAAQAAAB4AcAABAAAAGwAAAEhvdCBCYWNrdXBzICwgUXVpZXNjZSBldGMgAAACAXEAAQAA

ABYAAAABvt5omMRuQPIASlIR05GCAIBfCjz1AABAADkAIAGgkWjevgEDAPE/CQQAAB4AMUABAAAA

CQAAAENIQVJMRVBHAAAAAAMAGkAAAAAAHgAwQAEAAAAJAAAAQ0hBUkxFUEcAAAAAAwAZQAAAAAAD

AP0/5AQAAAMAJgAAAAAAAwA2AAAAAAADAIAQ/////wIBRwABAAAALwAAAGM9R0I7YT1CVDtwPUJU

O2w9TUNMTVNFTlQwMi05OTA4MDQxMTAwMzFaLTQzNDYAAAIB+T8BAAAATAAAAAAAAADcp0DIwEIQ

GrS5CAArL+GCAQAAAAAAAAAvTz1FWENIQU5HRS9PVT1CVFVLMDEvQ049UkVDSVBJRU5UUy9DTj1D

SEFSTEVQRwAeAPg/AQAAABoAAABDaGFybGVzLFBHLFBldGVyLE5DSjIyUCBYAAAAHgA4QAEAAAAJ

AAAAQ0hBUkxFUEcAAAAAAgH7PwEAAABMAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9P

PUVYQ0hBTkdFL09VPUJUVUswMS9DTj1SRUNJUElFTlRTL0NOPUNIQVJMRVBHAB4A+j8BAAAAGgAA

AENoYXJsZXMsUEcsUGV0ZXIsTkNKMjJQIFgAAAAeADlAAQAAAAkAAABDSEFSTEVQRwAAAABAAAcw

4Psut2fevgFAAAgwStXqiWjevgEeAD0AAQAAAAEAAAAAAAAAHgAdDgEAAAAbAAAASG90IEJhY2t1

cHMgLCBRdWllc2NlIGV0YyAAAB4ANRABAAAAPwAAADw1RjU0QkUwMTE2QkNEMjExOEM5NDAwNjA2

REQ2MTRFRDI5OTdFREBtY2xtc2VudDAyLmxvbi5idC5jb20+AAALACkAAAAAAAsAIwAAAAAAAwAG

EOsiuh0DAAcQJgkAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABUSEVJTVBPUlRBTlRJU1NV

RVdJVEhBTllCQUNLVVBTVFJBVEVHWUlTT0ZDT1VSU0VUT0JFU1VSRVRIQVRZT1VDQU5SRUNPVkVS

VEhJU01FQU5TVEhBVFlPVUhBVkVUT0JFQ0VSAAAAAAIBfwABAAAAPwAAADw1RjU0QkUwMTE2QkNE

MjExOEM5NDAwNjA2REQ2MTRFRDI5OTdFREBtY2xtc2VudDAyLmxvbi5idC5jb20+AAAmVw==

------_=_NextPart_000_01BEDE68.89EAD54A--

------------------------------

Date: Wed, 4 Aug 1999 12:35:34 +0100
From: bob.ra...@bt.com
To: idm...@iuassn.com
Subject: FW: Optional apar gs96467
Message-ID: <95116AD1D768D211BF630008C7A4C927F92CDE@MCARLENT01>

We did exactly this some time ago when we had an issue with IDMS CPU
single
engine limit .Our requirement was to increase the OLTP rate by 100%
without
significantly degrading response times . MT Queue depth changed from 2
(default) to 6 . We discovered the effects on transaction response time
and
CPU consumed purely as a result of increasing the queue depth were
negligible . In fact VARY MAX ACTIVE TASK (lower) did give a measurable
reduction in CPU . Eventually we dropped MT completely and went for
larger
engines . You need to watch your task / prog MPMODE .

> -----Original Message-----
> From: Klan, Robert (CORP) [SMTP:Rober...@Corporate.GE.com]
> Sent: 02 August 1999 15:04
> To: 'idm...@iuassn.com'
> Subject: Optional apar gs96467
>
> Has anyone experimented with optional apar GS96467 (Alter the
Multitasking
> Queue)? What did you discover by modifing the queue depths?
>
> Rob Klan
> rober...@corporate.ge.com
> 8*330-3565 (513) 583-3565
>
> Preliminary Information - GE Confidential,
> Y2K related information in this Email is covered
> under "Year 2000 Readiness Disclosure"
>

------------------------------

Date: Wed, 4 Aug 1999 13:43:53 +0200
From: =?ISO-8859-1?Q?Brandt_Ren=E9?= <r...@ubp.ch>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]maintain index
Message-ID:

<693E4DC6C79FD211907...@mailgva.geneve.ubp.ch>

Ray,
I am looking for a Cullinate engeneer who came to help us (at that time
=
we
called TRADE DEVELOPMENT BANK).
Is it you ?
Rene

> -----Message d'origine-----
> De: Migliaccio, Ray (Contractor) [SMTP:rmig...@harris.com]
> Date: Tuesday, August 03, 1999 8:08 PM
> =C0: 'IDMS-L'
> Objet: [IDMS-L]maintain index
>=20
> Can anyone explain if the maintain index utility can be used to =
rebuild a
> user
> owned index?=20
>=20
> Ray Migliaccio=09
> HARRIS Semiconductor=09

> email rmig...@harris.com
> phone (407) 729-5178

>=20

------------------------------

Date: Wed, 04 Aug 1999 05:02:54 PDT
From: "Jim Phillips" <jimphi...@hotmail.com>
To: idm...@iuassn.com
Subject: Re: [IDMS-L]Hot Backups , Quiesce etc
Message-ID: <1999080412025...@hotmail.com>

Yonks ago one of our clients suggested that we write them a journal
splitter i.e. a program which would take in a journal and sort out
all the records related to an area, segment or group thereof. The idea
being
that recovery for a given application is faster if a journal set is
available which contains only information for the areas to be recovered.
I
believe that they already had such a program but wanted to export the
support.

Nothing happened at the time, anyone interested now ?

Jim Phillips
ISP
(800) 295-7608

>From: peter.g...@bt.com
>Reply-To: idm...@iuassn.com
>To: IDM...@IUASSN.COM
>Subject: [IDMS-L]Hot Backups , Quiesce etc
>Date: Wed, 4 Aug 1999 12:00:31 +0100
>
>The important issue with any back up strategy is of course to be sure
that
>you can recover. This means that you have to be CERTAIN that your
backups
>and journals contain ALL the data required to get you back to the point
of
>failure. Now if a quiesce point is not taken before the back up then
you
>have the problem of guaranteeing that all the data you require is on
the
>backup or journals.
>
>Lets take an extreme case.
>
>I have a very large buffer pool and a process that updates a record
then
>does lots and lots of read only. The update causes the before and after
for
>the update to be written to Journal 1. This fills and so does journal
2.
>The
>database page is not yet written to the database since my process has
not
>yet issued a commit or finish. I now start my backup.
>
>In this scenario I need the offloads of J1 J2 and J3 to guarantee my
>recovery. I for one do not want to go checking that I have all the data
I
>need on my journals when my system is down and people are breathing
down my
>neck to get it back ASAP. So by taking the quiesce point and then
varying
>journals I have a known and guaranteed 'recovery set' consisting of my
>backup and all journals created after the vary journal.
>
>The above is an extreme case but I have known the occasional production

>program to go into a loop reading the same record again and again..
>thus causing the situation described above.
>
>The problem with taking the quiesce point is that all update activity
must
>stop. This is becoming more and more difficult as batch work must be
>scheduled round the quiecse. At the shop where I am a consultant this
>became
>a major issue. On many occasions the quiesce had problems due to batch
work
>over running. These were 'well behaved' batch jobs that issued commits
but
>still had areas in update. This meant operators had to figure out what
was
>going on decide what action to take and quite often this meant they had
to
>call the DBA.
>
>What was required was a process that enabled them to take the backup
>without
>the quiesce but also have a known and 100% reliable recovery set. To
>achieve
>this EZ-SoftQuiesce from Cogito was developed ( Gary-b has already
posted
>a
>description of this ). In simple terms the process is to vary the
journals
>and start the SoftQuiesce. When the SoftQuiesce process ends the backup
is
>started. All the time this is happening current updates continue to run
and
>new updates are allowed to start. There is no vary to retrieval
required
>and
>hence no impact on batch scheduling. The process ensures that ALL data
>required for a recovery is either on the journals created since the
vary
>journal or on the backup. The process is fully automated at this shop
and
>does not require any human intervention. The process has been in place
for
>several years and many recoveries performed. Most of these recoveries
were
>to get a static copy of the database for offline processes such as
DBAN,
>unload reload testing etc.
>
>
>Pete
><< attach3 >>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

------------------------------

Date: Wed, 04 Aug 1999 05:03:08 PDT
From: "Jim Phillips" <jimphi...@hotmail.com>
To: idm...@iuassn.com
Subject: Re: [IDMS-L]Hot Backups , Quiesce etc
Message-ID: <1999080412030...@hotmail.com>

Nothing happened at the time, anyone interested now ?

Jim Phillips
ISP
(800) 295-7608

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

------------------------------

Date: Wed, 4 Aug 1999 09:33:44 -0400

From: "Hanley, Frank" <Frank....@gs.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: [IDMS-L]Hot Backups , Quiesce etc
Message-ID: <851279708234D3118C7...@gsny26e.et.gs.com>

A company called Enet has/had a journal splitter... it was/is part of
their RRDF package. We used it a while ago to shadow databases to a
remote site. They also had an program that would write the images of
an
incomplete run-unit (the RU spanned multiple journals) to a side file
and
merge them in with the next one. It worked well to do incremental
roll-forwards on the shadow database.

Frank Hanley
The Goldman Sachs Group, Inc.
New York, NY

...

> -----Original Message-----
> From: Jim Phillips [SMTP:jimphi...@hotmail.com]
> Sent: Wednesday, August 04, 1999 8:03 AM
> To: idm...@iuassn.com

> Subject: Re: [IDMS-L]Hot Backups , Quiesce etc
>
> Yonks ago one of our clients suggested that we write them a journal
> splitter i.e. a program which would take in a journal and sort out
> all the records related to an area, segment or group thereof. The idea

> being
> that recovery for a given application is faster if a journal set is
> available which contains only information for the areas to be
recovered. I
>
> believe that they already had such a program but wanted to export the
> support.
>
> Nothing happened at the time, anyone interested now ?
>
> Jim Phillips
> ISP
> (800) 295-7608
>
>
> >From: peter.g...@bt.com
> >Reply-To: idm...@iuassn.com
> >To: IDM...@IUASSN.COM
> >Subject: [IDMS-L]Hot Backups , Quiesce etc
> >Date: Wed, 4 Aug 1999 12:00:31 +0100
> >
> >The important issue with any back up strategy is of course to be sure

> that
> >you can recover. This means that you have to be CERTAIN that your
backups
> >and journals contain ALL the data required to get you back to the
point
> of
> >failure. Now if a quiesce point is not taken before the back up then
you
> >have the problem of guaranteeing that all the data you require is on
the
> >backup or journals.
> >
> >Lets take an extreme case.
> >
> >I have a very large buffer pool and a process that updates a record
then
> >does lots and lots of read only. The update causes the before and
after
> for
> >the update to be written to Journal 1. This fills and so does journal
2.
> >The
> >database page is not yet written to the database since my process has
not
> >yet issued a commit or finish. I now start my backup.
> >
> >In this scenario I need the offloads of J1 J2 and J3 to guarantee my
> >recovery. I for one do not want to go checking that I have all the
data I
> >need on my journals when my system is down and people are breathing
down
> my
> >neck to get it back ASAP. So by taking the quiesce point and then
varying
> >journals I have a known and guaranteed 'recovery set' consisting of
my
> >backup and all journals created after the vary journal.
> >
> >The above is an extreme case but I have known the occasional
production
> >program to go into a loop reading the same record again and again..
> >thus causing the situation described above.
> >
> >The problem with taking the quiesce point is that all update activity

> must
> >stop. This is becoming more and more difficult as batch work must be
> >scheduled round the quiecse. At the shop where I am a consultant this

> >became
> >a major issue. On many occasions the quiesce had problems due to
batch
> work
> >over running. These were 'well behaved' batch jobs that issued
commits
> but
> >still had areas in update. This meant operators had to figure out
what
> was
> >going on decide what action to take and quite often this meant they
had
> to
> >call the DBA.
> >
> >What was required was a process that enabled them to take the backup
> >without
> >the quiesce but also have a known and 100% reliable recovery set. To
> >achieve
> >this EZ-SoftQuiesce from Cogito was developed ( Gary-b has already
> posted
> >a
> >description of this ). In simple terms the process is to vary the
> journals
> >and start the SoftQuiesce. When the SoftQuiesce process ends the
backup
> is
> >started. All the time this is happening current updates continue to
run
> and
> >new updates are allowed to start. There is no vary to retrieval
required
> >and
> >hence no impact on batch scheduling. The process ensures that ALL
data
> >required for a recovery is either on the journals created since the
vary
> >journal or on the backup. The process is fully automated at this shop
and
> >does not require any human intervention. The process has been in
place
> for
> >several years and many recoveries performed. Most of these recoveries

> were
> >to get a static copy of the database for offline processes such as
DBAN,
> >unload reload testing etc.
> >
> >
> >Pete
> ><< attach3 >>
>
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

------------------------------

Date: Wed, 04 Aug 1999 08:46:46 -0500
From: bob.n...@edwardjones.com
To: IDM...@iuassn.com
Subject: Re: [IDMS-L]Hot Backups , Quiesce etc
Message-ID: <H00002640205ac55@MHS>

My shop is 24X7 with heavy batch and CICS. We utilize hot backups with a
hard quiesce. This process has been in place since before I started in
1990. The key to this process is a folded, spindled and mutilated
version of the #UCFBTCH macro, which issue it's own DCMT commands and
reacts to the results.

In a nutshell...

The first step issues a DCMT DIS AC TA to determine what programs are
running. Any batch UPD programs are cancelled via a DCMT VARY TASK
task-id TERMINATE. The batch programs and JCL contain restartability to
allow the program to restart itself, without operator intervention, in
the event of a timeout, cancel, deadlock or area unavailable. We also
enfore the use of frequent commits to ensure the rollback does not take
long.

The process then issues DCMT DIS AREA, tables the ones in UPD and issues
a DCMT VARY AREA RET for each one. If we encounter an AREA QUIESING, the
DCMT DIS AC TA is issued again and this time we cancel all UPD programs.

Once the VARY retrieval process is complete, we issue a DCMT VARY
JOURNAL and then VARY the areas back to UPDATE.

This process is done at the START and END of the backup process to
ensure that we have a solid begin and end point. The journal created at
the end is referred to as the quiesce journal and is used for the
recovery of the hot backups.

Our recovery procedure involves the restore of the backups, a SEQUENTIAL
ROLLFORWARD of the quiesce journal followed by a SORT EXIT ROLLFORWARD
of the journals created after the backups up to the point of failure. We
also use the COMPLETED option on the SORT EXIT recovery to recover any
inflight at the end of the tape.

This process has been tested in numerous D/R tests and has been used for
individual area/file recoveries for the testing of unload/reloads and
recoveries due to ID-10-T errors.

Since batch is fully restartable, the only drawback is the occassional
online abend. Typically, the only error is a 0966. To minimize online
abends, we are investigating code changes to allow programs to retry in
the event of certain abends, such as the 0966.

Bob Nardin
IS Database Systems
Edward Jones
201 Progress Parkway
Maryland Heights, MO 63043-3042
(314) 515-7886
bob.n...@edwardjones.com

------------------------------

Date: Wed, 4 Aug 1999 09:01:24 -0500
From: "Lorenzen, David C" <david.l...@eds.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: digest youself
Message-ID: <B9CB0C7E771ED2119FA400A02461EE240325E836@USPLM206>

What would be the selection if you do nothing? Is there a
default?

Dave.

> ----------
> From: hoel...@us.ibm.com
> Sent: Monday, August 02, 1999 1:53 PM
> To: idm...@iuassn.com
> Subject: digest youself
>
>
>
>
> a new release of the list software we are using (POSTOFFICE) has been
> installed.
> One significant change is that you can now place yourself in digest or

> immediate
> mode (or subscribe or unsubscribe for that matter).Go to:
>
> http://syncronicity.net:81/guest/RemoteListSummary/IDMS_L
>
> and follow the instructions there!
>
> Chris Hoelscher
>
>

------------------------------

Date: Wed, 04 Aug 1999 16:20:35 GMT
From: WIlliam...@blackdecker.com
To: <idm...@iuassn.com>
Subject: LE/370 and Storage
Message-ID: <9908049337....@blackdecker.com>

We have this week migrated our IDMS DC system to Cobol for MVS and
LE/370.

I have just started to review the performance of the system and have
noticed a
significant increase in the use of storage by any of these DC programs
ie
typically a 10 fold increase. This has caused us one or two problems
with going
SOS.

The problem seems to be from watching the PMRM monitor whilst
transactions are
running is that the programs now require a large amount of Private
Storage below
the line and this is the cause of our SOS in pool 0.

I think we have followed all the CA recommendations for implementing
LE/370 with
DC including LI29837 and LI23664. We have created a CEEDOPT module with
the
recommended values and relinked CEEPIPI and CEEBINIT as instructed but
this had
no effect on the storage usage. The programs have all been compiled with
the
COBOL compiler RENT option as recommended and linked AMODE 31.

Has anyone else out there noticed a similar problem when they
implemented LE/370
and is this a benefit of LE/370 (or an IBM hardware selling feature
sic.) or is
there something else that I may have overlooked.

By the way our largest storage spotted so far for a single task below
the line
is about 3Mb.

Thanks

Bill Martin

Black&Decker

------------------------------

Date: Wed, 4 Aug 1999 08:44:52 -0700
From: John....@teale.ca.gov
To: IDM...@IUASSN.COM
Subject: expand of multiple areas in a file
Message-ID: <882567C3.0...@teale.ca.gov>

I need to do a page expand for a file with multiple areas in the file.
The
expand is easy,
however when I try to change the area statements to reflect the new
sizes (and
the
original page size), OCF refuses to make the changes giving me a
message:

*+ Status = -4 SQLSTATE = 64000 Messages follow:
*+ DB004017 T222 C-4M6016: PAGE SIZE cannot be altered - maps to
mutiple-area
*+ FILE

Any suggestions ?

------------------------------

Date: Wed, 04 Aug 1999 11:07:48 -0500
From: bob.n...@edwardjones.com
To: idm...@iuassn.com
Subject: Re: RE: [IDMS-L]E-Net
Message-ID: <H00002640205ac5d@MHS>

I deliberately left E-Net out of my previous post to limit complexity.
We have incorporated RRDF as a part of our Advanced Recovery
procedures. RRDF sends journal images to an offsite facility in real
time which can be used to shadow databases. We use the shadow approach
for DB2 recovery. For IDMS, the journal images can be reformatted and
used in the same recovery scenario I described earlier.

The reformatted journals for the hot backup(quiesce tape) are applied
using a SEQUENTIAL ROLLFORWARD. The reformatted journals for the period
from the end of the hot backup thru the point of failure are recovered
using SORT EXIT.

To identify the start and end times for the backups, the quiesce program
calls a program which updates a shadowed DB2 table, with the point in
time that the VARY JOURNAL was done at the start and end of the process.

I gave a presentation at CA World 99 entitled "Advanced Recovery Using
the Remote Recovery Data Facility". If you can get access to the CD
with the proceedings and want more details, check it out.

> A company called Enet has/had a journal splitter... it was/is part
of
> their RRDF package. We used it a while ago to shadow databases to a

> remote site. They also had an program that would write the images
of an
> incomplete run-unit (the RU spanned multiple journals) to a side file
and
> merge them in with the next one. It worked well to do incremental
> roll-forwards on the shadow database.
>
> Frank Hanley
> The Goldman Sachs Group, Inc.
> New York, NY
>
> ...

> > -----Original Message-----
> > From: Jim Phillips [SMTP:jimphi...@hotmail.com]
> > Sent: Wednesday, August 04, 1999 8:03 AM
> > To: idm...@iuassn.com

> > Subject: Re: [IDMS-L]Hot Backups , Quiesce etc
> >
> > Yonks ago one of our clients suggested that we write them a journal
> > splitter i.e. a program which would take in a journal and sort out
> > all the records related to an area, segment or group thereof. The
idea
> > being
> > that recovery for a given application is faster if a journal set is
> > available which contains only information for the areas to be
recovered. I
> >
> > believe that they already had such a program but wanted to export
the
> > support.
> >
> > Nothing happened at the time, anyone interested now ?
> >
> > Jim Phillips
> > ISP
> > (800) 295-7608
> >
> >
> > >From: peter.g...@bt.com
> > >Reply-To: idm...@iuassn.com
> > >To: IDM...@IUASSN.COM
> > >Subject: [IDMS-L]Hot Backups , Quiesce etc
> > >Date: Wed, 4 Aug 1999 12:00:31 +0100
> > >
> > >The important issue with any back up strategy is of course to be
sure
> > that
> > >you can recover. This means that you have to be CERTAIN that your
backups
> > >and journals contain ALL the data required to get you back to the
point
> > of
> > >failure. Now if a quiesce point is not taken before the back up
then you
> > >have the problem of guaranteeing that all the data you require is
on the
> > >backup or journals.
> > >
> > >Lets take an extreme case.
> > >
> > >I have a very large buffer pool and a process that updates a record
then
> > >does lots and lots of read only. The update causes the before and
after
> > for
> > >the update to be written to Journal 1. This fills and so does
journal 2.
> > >The
> > >database page is not yet written to the database since my process
has not
> > >yet issued a commit or finish. I now start my backup.
> > >
> > >In this scenario I need the offloads of J1 J2 and J3 to guarantee
my
> > >recovery. I for one do not want to go checking that I have all the
data I
> > >need on my journals when my system is down and people are breathing
down
> > my
> > >neck to get it back ASAP. So by taking the quiesce point and then
varying
> > >journals I have a known and guaranteed 'recovery set' consisting of
my
> > >backup and all journals created after the vary journal.
> > >
> > >The above is an extreme case but I have known the occasional
production
> > >program to go into a loop reading the same record again and again..

> > >thus causing the situation described above.
> > >
> > >The problem with taking the quiesce point is that all update
activity
> > must
> > >stop. This is becoming more and more difficult as batch work must
be
> > >scheduled round the quiecse. At the shop where I am a consultant
this
> > >became
> > >a major issue. On many occasions the quiesce had problems due to
batch
> > work
> > >over running. These were 'well behaved' batch jobs that issued
commits
> > but
> > >still had areas in update. This meant operators had to figure out
what
> > was
> > >going on decide what action to take and quite often this meant they
had
> > to
> > >call the DBA.
> > >
> > >What was required was a process that enabled them to take the
backup
> > >without
> > >the quiesce but also have a known and 100% reliable recovery set.
To
> > >achieve
> > >this EZ-SoftQuiesce from Cogito was developed ( Gary-b has already

> > posted
> > >a
> > >description of this ). In simple terms the process is to vary the
> > journals
> > >and start the SoftQuiesce. When the SoftQuiesce process ends the
backup
> > is
> > >started. All the time this is happening current updates continue to
run
> > and
> > >new updates are allowed to start. There is no vary to retrieval
required
> > >and
> > >hence no impact on batch scheduling. The process ensures that ALL
data
> > >required for a recovery is either on the journals created since the
vary
> > >journal or on the backup. The process is fully automated at this
shop and
> > >does not require any human intervention. The process has been in
place
> > for
> > >several years and many recoveries performed. Most of these
recoveries
> > were
> > >to get a static copy of the database for offline processes such as
DBAN,
> > >unload reload testing etc.
> > >
> > >
> > >Pete
> > ><< attach3 >>
> >
> >
> > ______________________________________________________
> > Get Your Private, Free Email at http://www.hotmail.com

Bob Nardin
IS Database Systems
Edward Jones
201 Progress Parkway
Maryland Heights, MO 63043-3042
(314) 515-7886
bob.n...@edwardjones.com

------------------------------

Date: Wed, 4 Aug 1999 10:08:35 -0600
From: "Robock, Dennis" <Dennis...@gov.ab.ca>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]LE/370 and Storage
Message-ID:
<709658908B3FD311B3A...@eoaexc01.enr.gov.ab.ca>

Hello

We have been on LE/370 sense last October we found our storage below the

line increase. We still have a rare occasion when we SOS on pool 1
below
the line. Pool 1 is USER USER KEEP .For the most part we are back to
where
we were with VS Cobol II.

We had to relink special subroutines as AMODE 31 RMODE 31 and recompile
programs that used them. Compile all programs with compile option
DATA(31).
Increased our XA storage Pool for USER USER KEEP by 50%. We are a heavy

user of DC Cobol. We found that 2 programs were missed when we
recompiled
when we went to LE. When these 2 programs were called they had a
serious
impact on storage below the line. Make sure that all your DC COBOL is
defined in the system as storage protection is NO.

We have found this to be an ongoing process of trial and error.

Dennis Robock
Alberta Department of Resource Development
Edmonton, Alberta Canada

-----Original Message-----
From: WIlliam...@blackdecker.com
[mailto:WIlliam...@blackdecker.com]
Sent: August 4, 1999 10:21 AM
To: idms-l
Subject: [IDMS-L]LE/370 and Storage

We have this week migrated our IDMS DC system to Cobol for MVS and
LE/370.

I have just started to review the performance of the system and have
noticed
a
significant increase in the use of storage by any of these DC programs
ie
typically a 10 fold increase. This has caused us one or two problems
with
going
SOS.

The problem seems to be from watching the PMRM monitor whilst
transactions
are
running is that the programs now require a large amount of Private
Storage
below
the line and this is the cause of our SOS in pool 0.

I think we have followed all the CA recommendations for implementing
LE/370
with
DC including LI29837 and LI23664. We have created a CEEDOPT module with
the
recommended values and relinked CEEPIPI and CEEBINIT as instructed but
this
had
no effect on the storage usage. The programs have all been compiled with
the
COBOL compiler RENT option as recommended and linked AMODE 31.

Has anyone else out there noticed a similar problem when they
implemented
LE/370
and is this a benefit of LE/370 (or an IBM hardware selling feature
sic.) or
is
there something else that I may have overlooked.

By the way our largest storage spotted so far for a single task below
the
line
is about 3Mb.

Thanks

Bill Martin

Black&Decker

------------------------------

Date: Wed, 04 Aug 1999 12:07 -0500
From: "Steve Franzon" <Steve....@alltel.com>
To: "idm...@iuassn.com" <idm...@iuassn.com>
Subject: Re: [IDMS-L]expand of multiple areas in a file
Message-ID: <199908041110...@alltel.com>

This is one of the reasons to avoid multi area files!

Suggest you drop all areas in the file and add them back with the
new
page size (don't forget ORIGINAL PAGE SIZE clause). I believe you
even
have to be careful what order you do this. OCF does not like it if
you
drop an area that will leave a "hole" in the file. (I'm not sure -
it
either won't let you drop the area or will just give an error). You

might need to "strip" the areas off the end of the file as you drop

them and recreate the areas from the first area in the file.

OCF does a lot of it's validation on the fly (as you submit each
statement) which is good most of the time. However, sometimes you
need
to temporarily create a conflict, but OCF will not allow it - even
though your intention is to resolve the problem prior to generating

the DMCL. It can be real annoying at times!

Good luck.
Steve.

______________________________ Reply Separator
_________________________________
Subject: [IDMS-L]expand of multiple areas in a file
Author: idm...@iuassn.com at internet
Date: 08/04/1999 10:44 AM

*+ Status = -4 SQLSTATE = 64000 Messages follow:
*+ DB004017 T222 C-4M6016: PAGE SIZE cannot be altered - maps to
mutiple-area
*+ FILE

Any suggestions ?

------------------------------

Date: Wed, 4 Aug 1999 12:16:57 -0400
From: "Harrison, Robert" <robert....@TROLL.COM>
To: idm...@iuassn.com
Subject: RE: [IDMS-L]expand of multiple areas in a file

John: With respect to a page-expand for a file with multiple areas ---
I too have run into this problem with the "alter" command. The best way

around it is to do the following (the sequence is important) : 1.
Drop
all the areas in the file. 2. Drop the file. 3. Add the file with
the
new filename. 4. Add all the areas with the new page-size
specification
and the all-important "original page size" specification. 5. Generate
the
DMCL.
Regards,
Bob Harrison, Troll Book Clubs, Mahwah, NJ

> -----Original Message-----
> From: John....@teale.ca.gov [SMTP:John....@teale.ca.gov]
> Sent: Wednesday, August 04, 1999 11:45 AM
> To: IDM...@IUASSN.COM
> Subject: [IDMS-L]expand of multiple areas in a file
>
> I need to do a page expand for a file with multiple areas in the file.

> The
> expand is easy,
> however when I try to change the area statements to reflect the new
sizes
> (and
> the
> original page size), OCF refuses to make the changes giving me a
message:
>
> *+ Status = -4 SQLSTATE = 64000 Messages follow:
> *+ DB004017 T222 C-4M6016: PAGE SIZE cannot be altered - maps to
> mutiple-area
> *+ FILE
>
> Any suggestions ?
>

------------------------------

Date: Wed, 4 Aug 1999 11:23:50 -0500
From: "Runtsch, Steve" <Steve....@ecolab.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: updating CLISTIN datasets
Message-ID: <E994F67723A4D211B00C000083623DF00202405D@CORPHQ2>

You might avoid the problem by using a PDS instead of sequential data
set.
That is what I use and have no problem using ISPF to edit the member.
No
need for FREE=CLOSE or DCMT VARY commands.

Steve Runtsch
Ecolab Inc.

-----Original Message-----
From: hoel...@us.ibm.com [mailto:hoel...@us.ibm.com]
Sent: Thursday, July 29, 1999 10:56 AM
To: idm...@iuassn.com
Subject: updating CLISTIN datasets

is there any known way to update the contents of a CLIST line dsn while
the
region is up? If I vary the CLIST line off-line, I can browse the file,
but
if I
try to update I get
Data set in use
any thoughts? am I forced to create an alternative dsn and modify the
STC
JCL?

Chris Hoelscher
Sophisticated Business Systems
Dallas Texas
On Assignment to IBM Global Services
Outsourcers for GE Capital Cooporation

------------------------------

Date: Wed, 4 Aug 1999 12:26:28 -0400
From: Bruce Campbell <Bcam...@tact.com>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Message-ID:

<A12989FC177BD111A67...@ct.trapserver.tact.com>

Hi Gary, et al,
Let's talk for a minute about impact on business. I think that an
important
point to address is cost/overhead associated with scheduling and running

back ups. True 24x7 operations require just that......true 24x7
operation.
Having to move your business offline, even for just a short period of
time,
is a hit to the business, bottom line. Every response I have seen to
this
inquiry has talked about shutting the business down, the need to
implement
multi layered procedures and the scheduling of all this work.

It is my understanding (Gary, please correct me if I am wrong) that this

large CA-IDMS user running EZ-SQP not only has their business on line
without any interuption, but also saves about $140,000.00 per year due
to
the fact that they do not have to schedule and staff their batch work!
Who's upper management wouldn't want to know this? Pretty cool, I
think.

Thanks,
Bruce H. Campbell
TACT Software, Inc.

> -----Original Message-----
> From: gary-b [SMTP:gar...@email.msn.com]
> Sent: Tuesday, August 03, 1999 10:14 AM
> To: idm...@iuassn.com
> Subject: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
>
> Hello Listers,
>
> Some of the discussion thread about Hot-Backups identifies the
> requirement for a "quiesce point" to be taken before the backup
> is commenced. (That is, a period when there is no update
> activity against the areas being backed-up). Of course this
> Quiesce point itself is problematic for sites requiring true 24x7

------------------------------

Date: Wed, 4 Aug 1999 09:29:41 -0700
From: John....@teale.ca.gov
To: idm...@iuassn.com
Subject: RE: [IDMS-L]expand of multiple areas in a file
Message-ID: <882567C3.0...@teale.ca.gov>

Bob: If the intent is to use the old File characteristics, is there a
need to
do steps 2 and 3 ?

"Harrison, Robert" <robert....@TROLL.COM> on 08/04/99 09:16:57 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: John Kamuf/Teale)

Subject: RE: [IDMS-L]expand of multiple areas in a file

John: With respect to a page-expand for a file with multiple areas ---
I too have run into this problem with the "alter" command. The best way

------------------------------

Date: Wed, 4 Aug 1999 12:29:13 -0500
From: "Runtsch, Steve" <Steve....@ecolab.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Hot Backups
Message-ID: <E994F67723A4D211B00C000083623DF00202405E@CORPHQ2>

To provide a means to recover from total loss of our computer center, we

execute a hot backup process daily with the help of software that
originally
came from the IUA. (I'm currently trying to acquire Cogito's EZ-Soft
Quiesce (same as DB-SQP from TACT in the U.S.) which Pete Charles
already
mentioned.) Regardless of which method we use, our enterprise recovery
plan
dictates that we recover to an IDMS quiesce point that immediately
precedes
the IDMS backup. Very simplistically, our process is:
Stop scheduled production batch work
Full-volume backup non-IDMS production volumes
Quiesce IDMS
Vary IDMS Journals (sync point 1)
(This is the point to which we will recover in case of disaster. The
rest
of the Ecolab world and IDMS will be in sync.)
Reactivate IDMS
Start scheduled production work
Full-volume backup IDMS volumes
Vary journals (sync point 2)
Backup MVS catalogs

Obviously, to get back to our recovery point we will roll back IDMS work

from sync point 2 to sync point 1, but our customers have agreed that
this
is the way it must be since we have no other means to get IDMS and
everything else in sync. In the worst case, we will have lost 24 hours
of
work. To varying degrees, we successfully test our recovery procedures
once
or twice yearly.

-----Original Message-----
From: Govan Jr, Harold M. [mailto:Harold...@lexis-nexis.com]
Sent: Thursday, July 29, 1999 1:16 PM
To: 'IDMSL'
Subject: Hot Backups

I would like to solicit input from folks who are doing hot backups in 7
X
24 environments.

I know that "hot backup" is not a radical or new technique, but we have

avoided this approach to backups to simplify operations and database
recovery procedures - until now.

A few questions:
How long have you used this backup technique ?
How are you doing hot backups ?
What problems or pitfalls, if any, have you encountered using
this backup technique ?
How would you compare recovery using a hot backup to a recovery
using a conventional static backup ?

Thanks in advance.

------------------------------

Date: Wed, 4 Aug 1999 14:27:45 -0400

From: "David R Slocum" <drsl...@cmsenergy.com>
To: idm...@iuassn.com
Subject: RE: Hot Backups

Message-ID: <852567C3.0...@pr1lns45.cpco.com>

Steve,

If you're using the IUA's Hot Backup software, are you using sort exit
mode to
rollback the changes between sync point 2 and sync point 1? This was
okay for
releases of IDMS prior to 12.0, but since 12.0 this feature does NOT
work the
same. Specifically, BFOR images for aborted run units are not written
back to
the database. Therefore, you can end up with pages containing updates
from
aborted run units after the rollback is complete. I can't remember for
sure,
but it seems that this problem exists for the sequential mode rollback
as well.
In other words, using either form of the rollback utility between sync
point 2
and sync point 1 can result in a corrupted database. I found this out
about a
year ago. It was for this reason that I made my latest change to our
recovery
procedures to do a sequential mode rollforward between sync point 1 and
sync
point 2. The CA-IDMS Database Administration manual specifically
states: "In
order to use a backup file created while the database was being updated,
all
archive journal files produced during the process must be applied to the

restored database using the ROLLFORWARD utility statement." It also
states that
you must use the SEQUENTIAL option. The SORTED option of the
rollforward
utility can be used to restore updates that occurred after the backup
(i.e.,
after sync point 2). You might get away with using the sort exit mode
rollback
99% of the time, but there is still a chance that it could trash your
database
under the right set of circumstances. Hopefully this message will save
you the
pain of having to go through that experience.

DISCLAIMER: The views expressed in this note aren't necessarily those of
the
company.

David R. Slocum
Consumers Energy

"Runtsch, Steve" <Steve....@ecolab.com> on 08/04/99 01:29:13 PM

Please respond to idm...@iuassn.com

To: "'idm...@iuassn.com'" <idm...@iuassn.com>

cc: (bcc: David R Slocum/Pr/Consumers/CMS)

Subject: [IDMS-L]RE: Hot Backups

To provide a means to recover from total loss of our computer center, we

Obviously, to get back to our recovery point we will roll back IDMS work

-----Original Message-----
From: Govan Jr, Harold M. [mailto:Harold...@lexis-nexis.com]
Sent: Thursday, July 29, 1999 1:16 PM
To: 'IDMSL'
Subject: Hot Backups

I would like to solicit input from folks who are doing hot backups in 7
X
24 environments.

I know that "hot backup" is not a radical or new technique, but we have

avoided this approach to backups to simplify operations and database
recovery procedures - until now.

Thanks in advance.

------------------------------

Date: Wed, 4 Aug 1999 14:53:46 -0400
From: "Gardner, Michael" <Michael...@fns.usda.gov>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: unsubscribe
Message-ID:
<C1D845867A7ED211A0D...@199.136.154.fns.usda.gov>

To all:
I would like to apologize for the grammatical errors in this missive. I

didn't proof read it, like I should have.
Sincerely,
Michael

-----Original Message-----
From: Gardner, Michael [mailto:Michael...@fns.usda.gov]
Sent: Monday, August 02, 1999 9:48 AM
To: 'idm...@iuassn.com'

Subject: RE: unsubscribe

Hello to all in the group:

If the group will indulge me, I would like to take these points in
seriatim.

This is an old saw.

I, for one, like to hear from my peers and appreciate this professional
group in all of its manifestations. If some of its members go off on a
tangent upon occasion then so be it. I would like to here more about
the
history of IDMS any vignette that my compatriots care to share.

Hopefully Mr. James feels vindicated and thoroughly vented.

As for a consultants ability to "know" everything about IDMS, that is
ridiculous. I think that the architecture of IDMS is open enough that
there
is not always a clear cut solution to any given problem. Every DBA has
had
different experiences and opportunities. Part of being a consultant is
being able to honestly look at your skill set and bolster it when the
need
arises.
A consultants ego should, at best, place a close second behind the
interest
of his employer.

Well, I'm sated. Thank you all for your attention.

Sincerely,
Michael Gardner
ALTA Systems, Inc.

-----Original Message-----
From: STAN JAMES [mailto:SJA...@ATPCO.NET]
Sent: Friday, July 30, 1999 9:24 AM
To: idm...@iuassn.com
Subject: unsubscribe

UNSUBSCRIBE

Too much idiot talk on this list. At times I am ashamed of my peers,
especially the ones that work as consultants and should "know", or at
least
are
getting paid to know.

------------------------------

Date: Wed, 4 Aug 1999 14:55:15 -0400
From: David Kane <DK...@tact.com>

To: idm...@iuassn.com
Subject: RE: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point

Message-ID: <018AF8E92AA4D21183F90008C74C421B533FC7@TACTEX01>

Good Work, Gary. Keep plugging

-----Original Message-----
From: gary-b [SMTP:gar...@email.msn.com]
Sent: Tuesday, August 03, 1999 10:14 AM
To: idm...@iuassn.com
Subject: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point

Hello Listers,

For Further information contact

soft...@tact.com or
soft...@cogito.co.uk

Gary Bronziet
Cogito

------------------------------

Date: Wed, 4 Aug 1999 14:48:48 -0500
From: "Runtsch, Steve" <Steve....@ecolab.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]RE: Hot Backups
Message-ID: <E994F67723A4D211B00C000083623DF002024060@CORPHQ2>

In response to my comments about Hot Backups, David Slocum from
Consumers
Energy wrote, in summary:
If you're using the IUA's Hot Backup software, watch out when you use
ROLLBACK--is does not roll back aborted run units in release 12.0.

David is correct. In order to roll back successfully in 12.0 and above,
you
roll forward sequentially (cannot be sorted) first, then roll back.
That
was the only way to cause IDMS to roll back aborted run units. This was
all
discussed on the list 6 months or so ago. However, new SYSIDMS option
HOTROLLBACK (see IDMS problem 2086) will cause ROLLBACK to roll back
aborted
run units.

-----Original Message-----
From: Govan Jr, Harold M. [mailto:Harold...@lexis-nexis.com]
Sent: Thursday, July 29, 1999 1:16 PM
To: 'IDMSL'
Subject: Hot Backups

I would like to solicit input from folks who are doing hot backups in 7
X
24 environments.

I know that "hot backup" is not a radical or new technique, but we have

avoided this approach to backups to simplify operations and database
recovery procedures - until now.

Thanks in advance.

------------------------------

Date: Wed, 4 Aug 1999 13:08:58 -0700
From: to...@enet.com
To: bob.n...@edwardjones.com
Cc: idm...@iuassn.com
Subject: Hot Backups and E-Net Software
Message-ID: <TFSD...@enet.com>

Thanks to Frank Hanley and Bob Nardin for mentioning our software on
this=20=
thread=2E E-Net has two distinct products that relate to CA-IDMS=2E

RRDF (Remote Recovery Data Facility) provides a remote journaling
solution for=20=
CA-IDMS (plus DB2, IMS, ADABAS, etc=2E) - journal data is acquired
through the=20=
IDMSJNL2 exit and is sent asynchronously to a remote site in
real-time=2E When a=
=20=
remote site recovery is required, journal data is available to recover
the=20=
databases very close to the point of the outage=2E

E-NET2 is a database shadowing facility specifically for CA-IDMS=2E It
includes a=
=20=
journal splitting capability, plus the ability to simulate quiesce
points on=20=
the shadow database=2E The shadow databases can live at the primary site
or=20=
(using RRDF) at a remote location=2E You can have both local and remote
shadow=20=
databases=2E

In addition we provide database shadowing software for DB2 called "Log
Apply"=2E=20=

Further information about these products is available on our web site
at=20=
www=2Eenet=2Ecom=2E

Now enough of the shameless plugging=2E I had a few observations to
offer on the=20=
current discussion thread about the need for quiesce points when using
hot=20=
backups=2E

(1) You should do a straight backup (either "hot" or "cold") at least
once a=20=
week with a true IDMS quiesce=2E The disruption incurred is justified by
having a=
=20=
safe backup and recovery point that is independent of any vendor
software=2E In=20=
other words - what happens if you try to perform a recovery and the
resulting=20=
database is corrupt? You need to be able to perform the same recovery
with=20=
CA-approved procedures and straight set of journals and without any
vendor=20=
software=2E If the recovery is still bad, then you know there is a
problem with=20=
the journals themselves and not the vendor software=2E Almost every site
has a=20=
weekly bounce for one reason or another=2E=20=

(2) Customers who maintain shadow IDMS databases using our E-NET2
product have=20=
faster recoveries because the database is pre-recovered already up to
the most=20=
recent journal processed=2E

(3) You can backup the shadow database independently of the
production=20=
database=2E This results in no disruption to the end users=2E

(4) We recommend daily backups of the shadow database at simulated
quiesce=20=
points, together with weekly backups of the production database
(accompanied by=20=
a system-wide quiesce)=2E This is a good compromise that minimizes the
disruption=
=20=
introduced by the quiesce - plus providing the ability to do a
straight=20=
recovery to eliminate any finger-pointing over a database corruption=2E

Best regards=2E
Tom Flesher
E-Net Corporation
+1-415-835-8419
tomf@enet=2Ecom

------------------------------

Date: Wed, 04 Aug 1999 14:57:48 -0500
From: Chris Hoelscher <hoel...@flash.net>
To: idm...@iuassn.com
Subject: Re: [IDMS-L]LE/370 and Storage
Message-ID: <1999080420...@chupacabras.flash.net>

make sure you have LOC ANY specified on all your 31bit-eligible TASK
statements - it is possible even if they are linked 31-bit, the LOC
BELOW
will force them below!

chris

------------------------------

Date: Wed, 4 Aug 1999 13:22:53 -0700
From: Chrissy...@ual.com
To: IDM...@iuassn.com, DBA...@mbusa.com

Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point
Message-ID:

<79F54B5B*/DD.ID=u142766/PN=Chrissy.Howard/OU=sfoko/OU=sfo/O=UAL/PRMD=UAL/ADMD=IBMX400/C=US/@MHS>

Mark,
I would like to persue this but don't have the ADR documentation. It's
a political thing around here.
Chrissy
----------
From: IDMS-L(a)iuassn.com; DBAS06(a)mbusa.com
To: Idms-l(a)iuassn.com

Subject: Re: [IDMS-L]Re: RE: Hot Backups without a QUIESCE point

Date: Tuesday, August 03, 1999 2:34PM

Chrissy,
If you are using ADRDSSU, and taking a sync point (quiesce point), then

why don't you use the concurrent copy option?
Then you have a backup that is complete, and not "hot". You don't have

to worry about any of these issues.
Mark

>>> <Chrissy...@ual.com> 08/03 2:55 PM >>>

conclusion ? Thanks.

------------------------------

Date: Wed, 04 Aug 1999 18:58:47 -0700
From: JB Moore <conl...@ix.netcom.com>
To: idm...@iuassn.com
Subject: Re: [IDMS-L]LE/370 and Storage
Message-ID: <37A8EF...@ix.netcom.com>

WIlliam...@blackdecker.com wrote:
>
> We have this week migrated our IDMS DC system to Cobol for MVS and
LE/370.
>
> I have just started to review the performance of the system and have
>
> By the way our largest storage spotted so far for a single task below
the line
> is about 3Mb.
>
> Thanks
>
> Bill Martin
>
> Black&Decker

Bill,

Did you also link-edit them RENT? And change any SYSGEN definitions from

QUASIREENTRANT (if COBOL 74) to REENTRANT? And ensure that DATA(31) is
the default for DC COBOL?

You don't mention what version of COBOL you converted from: COBOL 74,
COBOL 85? How was the previous COBOL configured?

JB Moore

------------------------------

Date: Thu, 5 Aug 1999 09:33:24 +0100
From: "Shaw, Brock" <brock...@MBUK.Mercedes-Benz.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]expand of multiple areas in a file
Message-ID: <81C700BB8A25D3119EE50010E360DAC6087A53@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_01BEDF1C.C2CB2888
Content-Type: text/plain;
charset="iso-8859-1"

John,

The following is the *.nts (BookManager) note I have put into the
"Database
Administration" manual for section 25.5.1 "Increasing an area's page
size".
It is a cookbook procedure that I use for multi-area files.

"Multi-AREA files are a problem because OCF will not allow the area just
to
have the page size changed an area at a time.

Instead it is necessary to:
ALTER SEGMENT...
ALTER AREA ... DROP FILE... (all areas in file)
DROP FILE...
ADD FILE...
ALTER AREA ...(new and original page size)
WITHIN FILE ... (all areas in file)
ALTER DMCL...
GEN DMCL...

(Some updates return Status 1) "

Best regards,
Brock.

Brock Shaw, DBA (ISD)
Mercedes Benz (UK), England

-----Original Message-----
From: John....@teale.ca.gov [mailto:John....@teale.ca.gov]
Sent: 04 August 1999 16:45
To: IDM...@IUASSN.COM
Subject: [IDMS-L]expand of multiple areas in a file

I need to do a page expand for a file with multiple areas in the file.
The
expand is easy,
however when I try to change the area statements to reflect the new
sizes
(and
the
original page size), OCF refuses to make the changes giving me a
message:

*+ Status = -4 SQLSTATE = 64000 Messages follow:
*+ DB004017 T222 C-4M6016: PAGE SIZE cannot be altered - maps to
mutiple-area
*+ FILE

Any suggestions ?

------_=_NextPart_001_01BEDF1C.C2CB2888
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]expand of multiple areas in a file

John,

The following is the *.nts (BookManager) note I have = put into the
"Database Administration" manual for section = 25.5.1 "Increasing an
area's page size". It is a = cookbook procedure that I use for
multi-area files.

"Multi-AREA files are a problem because OCF will = not allow the area
just to have the page size changed an area at a = time.

Instead it is necessary to:
ALTER SEGMENT...
ALTER AREA ... DROP FILE... (all areas in = file)
DROP FILE...
ADD FILE...
ALTER AREA ...(new and original page size)
WITHIN FILE ... (all areas = in file)
ALTER DMCL...
GEN DMCL...

(Some updates return Status 1) "

Best regards,
Brock.

Brock Shaw, DBA (ISD)
Mercedes Benz (UK), England

-----Original Message-----
From: John....@teale.ca.gov [mailto:John....@teale.ca.gov]
Sent: 04 August 1999 16:45
To: IDM...@IUASSN.COM
Subject: [IDMS-L]expand of multiple areas in a = file

I need to do a page expand for a file with multiple = areas in the
file. The
expand is easy,
however when I try to change the area statements to = reflect the new
sizes (and
the
original page size), OCF refuses to make the = changes giving me a
message:

*+ Status =3D -4 = SQLSTATE =3D 64000 Messages = follow:
*+ DB004017 T222 C-4M6016: PAGE SIZE cannot be = altered - maps to
mutiple-area
*+ FILE

Any suggestions ?

------_=_NextPart_001_01BEDF1C.C2CB2888--

------------------------------

End of IDMS-L V1 #46
********************

Chris Hoelscher

unread,

Aug 13, 1999, 3:00:00 AM8/13/99

To: <IDM...@iuassn.com>
From: <IDM...@iuassn.com>
Reply-To: <IDM...@iuassn.com>
Subject: IDMS-L V1 #47
Date: Fri, 6 Aug 1999 02:56:24 -0600

IDMS-L Fri, 6 Aug 1999 Volume 1 :
Number 47

In this issue:

SOC4
Re: [IDMS-L]SOC4
RE: [IDMS-L]SOC4
RE: [IDMS-L]SOC4
UFF3 abend from DC Cobol
Re: [IDMS-L]SOC4
RE: [IDMS-L]SOC4
RE: [IDMS-L]SOC4
RE: [IDMS-L]UFF3 abend from DC Cobol
RE: [IDMS-L]SOC4
RE: [IDMS-L]UFF3 abend from DC Cobol
RE: [IDMS-L]SOC4
RE: [IDMS-L]SOC4
RE: [IDMS-L]UFF3 abend from DC Cobol
RE: [IDMS-L]SOC4
RE: [IDMS-L]UFF3 abend from DC Cobol
RE: [IDMS-L]SOC4
RE: [IDMS-L]SOC4
RE: [IDMS-L]SOC4
RE: [IDMS-L]UFF3 abend from DC Cobol
RE: [IDMS-L]SOC4
idms and emc dasd
Re: [IDMS-L]idms and emc dasd
RE: [IDMS-L]SOC4
Re: [IDMS-L]idms and emc dasd

RE: [IDMS-L]LE/370 and Storage

thoughts on SVCs
Re: [IDMS-L]idms and emc dasd
Re: [IDMS-L]idms and emc dasd
Re: [IDMS-L]idms and emc dasd
thanks to all
"SHADOW DIRECT" ( Neon Systems ) & IDMS

----------------------------------------------------------------------

Date: Thu, 5 Aug 1999 09:37:58 -0400

From: "Gene.McCormack" <Gene.Mc...@plpit.fishersci.com> To:
idm...@iuassn.com

Subject: SOC4
Message-ID:
<8BEC761BBB76D21196D9...@exchg-pdc-plpgh.fishersci.com>

This morning our production CV crashed with a SOC4. Around the same
time, we were reloading the SVC thru CAIRIMS. Does anybody know if this
could have caused the SOC4.

------------------------------

Date: Thu, 5 Aug 1999 10:12:57 -0400

From: "David R Slocum" <drsl...@cmsenergy.com> To: idm...@iuassn.com

Subject: Re: [IDMS-L]SOC4
Message-ID: <852567C4.0...@pr1lns45.cpco.com>

I ran into the same problem a couple of years back. At that time I was
told that the CVs had to be shut down prior to reloading the SVC.

"Gene.McCormack" <Gene.Mc...@plpit.fishersci.com> on 08/05/99
09:37:58 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: David R Slocum/Pr/Consumers/CMS) Subject: [IDMS-L]SOC4

This morning our production CV crashed with a SOC4. Around the same
time, we were reloading the SVC thru CAIRIMS. Does anybody know if this
could have caused the SOC4.

------------------------------

Date: Thu, 5 Aug 1999 10:31:19 -0400
From: "Lupico, Joe" <Joe.L...@AIG.com> To: "'idm...@iuassn.com'"
<idm...@iuassn.com> Subject: RE: [IDMS-L]SOC4
Message-ID: <4F1E68B5C708D11180860001FA372A6501CAFC98@XCS_LIV01>

I have never tried, nor do I think I ever will try, reloading the SVC
while it is being used. The REFRESH option of CAIRIM actually does a
delete and an add of the SVC being refreshed. This can't be good for a
running system.
I've loaded the SVC on numerous LPARs (both new and REFRESH) and never
had a problem - but as I stated, I made sure the SVC was inactive. This
meant no active IDMS regions and (optionally) no CICS programs trying to
communicate with IDMS via that SVC.
IBM reserved three SVCs for IDMS - 172, 173 and 174. I assemble and
install all three, usually using one for the test systems, one for prod
and the third is either for BETA regions, or for me to experiment with
(apply fixes, change options, etc.). When you have more than one SVC,
you can get all the systems off one of them, reassemble and reinstall
it, then point the systems back to it (this assumes you can cycle your
systems either daily or weekly). And if you maintain multiple releases
of IDMS, you'll probably need an SVC at each level.
Refreshing an SVC while the system is up seems real dangerous.

Joe

> ----------
> From: Gene.McCormack[SMTP:Gene.Mc...@plpit.fishersci.com]
> Reply To: idm...@iuassn.com
> Sent: Thursday, August 05, 1999 9:37 AM
> To: idm...@iuassn.com
> Subject: [IDMS-L]SOC4
>
> This morning our production CV crashed with a SOC4. Around the same
time,
> we
> were reloading the SVC thru CAIRIMS. Does anybody know if this could
have
> caused the SOC4.
>

------------------------------

Date: Thu, 5 Aug 1999 10:47:20 -0400

From: "David R Slocum" <drsl...@cmsenergy.com> To: idm...@iuassn.com

Subject: RE: [IDMS-L]SOC4
Message-ID: <852567C4.0...@pr1lns45.cpco.com>

I have a question about the three "reserved" SVC numbers - Are they
really reserved for CA's use? When I approached our MVS techie about
using these SVC numbers, he informed me that SVC numbers lower than 256
are reserved for use by IBM, and IBM only. When I showed him the
documentation that said it was okay for me to use them, he placed a call
with IBM tech support to get the straight scoop. The person at IBM
wasn't aware of these three SVCs being reserved for CA. Neither could
he find any documentation that said they were. He said that if we were
to use these SVCs, there was no guarantee that IBM wouldn't start using
them for something else some time in the future. Has anyone else
pursued this and got a different answer?

"Lupico, Joe" <Joe.L...@AIG.com> on 08/05/99 10:31:19 AM

Please respond to idm...@iuassn.com

To: "'idm...@iuassn.com'" <idm...@iuassn.com> cc: (bcc: David R
Slocum/Pr/Consumers/CMS) Subject: RE: [IDMS-L]SOC4

Joe

------------------------------

Date: Thu, 5 Aug 1999 10:09:13 -0500
From: "Irwin, Jim" <jir...@mail.sdc.state.mo.us> To: idm...@iuassn.com
Subject: UFF3 abend from DC Cobol
Message-ID:
<C18BE495D4DDD0118EA...@mail.sdc.state.mo.us>

We recently upgraded two of our test CVs to 14.01 (9811). The next day
one of our customer's applications began getting UFF3 abends in their DC
Cobol programs. This is an ADS/O application where dialog(s) call DC
Cobol programs. We've just begun investigating the problem but I
thought I would send something to the list in the hope that someone
might had experienced the same thing. I can't find the error code
referenced anywhere but I seem to remember SF is an abend involving the
svc but UF doesn't ring a bell with me. By the way, the reason code is
3. Any suggestions would be appreciated.

------------------------------

Date: Thu, 05 Aug 1999 10:12:13 -0500
From: bob.n...@edwardjones.com
To: idm...@iuassn.com
Subject: Re: [IDMS-L]SOC4
Message-ID: <H000026402083a4f@MHS>

> This morning our production CV crashed with a SOC4. Around the same
time, we
> were reloading the SVC thru CAIRIMS. Does anybody know if this could
have
> caused the SOC4.

I've never experienced a S0C4 when the SVC was refreshed, so I'd contact
CA. Any other messages? Doing this with an active CV will cause the
communication between external resources (CICS and batch) to quit
working. The old lights on and nobodys home.

Anytime we want to refresh the SVC we take the sytems down first.

Bob Nardin
IS Database Systems
Edward Jones
201 Progress Parkway
Maryland Heights, MO 63043-3042
(314) 515-7886
bob.n...@edwardjones.com

------------------------------

Date: Thu, 5 Aug 1999 10:14:33 -0500
From: "Perra, Dan J." <Dan.J...@ps.net> To: "'idm...@iuassn.com'"
<idm...@iuassn.com> Subject: RE: [IDMS-L]SOC4
Message-ID:
<D594BD79908CD211A91...@dalexch03.rmf.ps.net>

I doubt that IBM has reserved SVC numbers for use by any other vendor
product. IBM does reserve SVCs from 200 - 255 for user SVC numbers. The
only requirement for using a number any lower is that the number chosen
must not be in use by the operating system. If IBM chooses to use the
SVC you picked for IDMS then you use a new number for IDMS. The
statement regarding reserved SVCs is in the IDMS documentation as
follows form: CA-IDMS(R)

System Operations
Release 14.0
R005/&F0SOE
#SVCOPT parameters
..........................
SVCNO
Gives the number of the CA-IDMS SVC being generated. Svc-number
must
be an integer in the range 0 through 255.

Considerations:

Be sure to assign an SVC number that is higher than any SVC
interrupt numbers used by your operating system. Consult your
operating system documentation for SVC values that your
operating
system reserves.

SVC numbers 172, 173, and 174 are reserved SVC number for
CA-IDMS
for use by CAIRIM. Values 200 through 255 are standard user SVC

numbers.

Thanks
Daniel J. Perra
GlS - Interactive Systems
Office: 972-461-3696
Group Line: 972-461-3690
Email: Dan.J...@ps.net

-----Original Message-----
From: David R Slocum [mailto:drsl...@cmsenergy.com] Sent: Thursday,
August 05, 1999 9:47 AM To: idm...@iuassn.com
Subject: RE: [IDMS-L]SOC4

I have a question about the three "reserved" SVC numbers - Are they
really reserved for CA's use? When I approached our MVS techie about
using these SVC
numbers, he informed me that SVC numbers lower than 256 are reserved for
use by
IBM, and IBM only. When I showed him the documentation that said it was
okay
for me to use them, he placed a call with IBM tech support to get the
straight
scoop. The person at IBM wasn't aware of these three SVCs being
reserved for
CA. Neither could he find any documentation that said they were. He
said that
if we were to use these SVCs, there was no guarantee that IBM wouldn't
start using them for something else some time in the future. Has anyone
else pursued
this and got a different answer?

"Lupico, Joe" <Joe.L...@AIG.com> on 08/05/99 10:31:19 AM

Please respond to idm...@iuassn.com

To: "'idm...@iuassn.com'" <idm...@iuassn.com> cc: (bcc: David R
Slocum/Pr/Consumers/CMS) Subject: RE: [IDMS-L]SOC4

Joe

------------------------------

Date: Thu, 5 Aug 1999 11:18:47 -0400
From: Ale...@cpr.ca
To: idm...@iuassn.com
Subject: RE: [IDMS-L]SOC4
Message-ID: <872567C4.0...@mail1.cprailway.com>

As far as I know, SVCs less than 200 are reseved for IBM. 200 - 255 are
available for users. We are using SVC 250 for version 10 and SVC 252
for version 12.

Ale Eba

drsl...@cmsenergy.com on 08/05/99 09:47:20 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Ale Eba/eba0001/CPR)
Subject: RE: [IDMS-L]SOC4

"Lupico, Joe" <Joe.L...@AIG.com> on 08/05/99 10:31:19 AM

Please respond to idm...@iuassn.com

To: "'idm...@iuassn.com'" <idm...@iuassn.com> cc: (bcc: David R
Slocum/Pr/Consumers/CMS) Subject: RE: [IDMS-L]SOC4

Joe

------------------------------

Date: Thu, 5 Aug 1999 17:25:09 +0200
From: =?iso-8859-1?Q?Brandt_Ren=E9?= <r...@ubp.ch> To:
"'idm...@iuassn.com'" <idm...@iuassn.com> Subject: RE: [IDMS-L]UFF3
abend from DC Cobol Message-ID:
<693E4DC6C79FD211907...@mailgva.geneve.ubp.ch>

Hi Jim,
I have some UFFD and i just found they are LE (langage Environment =
abends)

> -----Message d'origine-----
> De: Irwin, Jim [SMTP:jir...@mail.sdc.state.mo.us]
> Date: Thursday, August 05, 1999 5:09 PM
> =C0: idm...@iuassn.com
> Objet: [IDMS-L]UFF3 abend from DC Cobol
>=20
> We recently upgraded two of our test CVs to 14.01 (9811). The next =
day
> one of our customer's applications began getting
> UFF3 abends in their DC Cobol programs. This is an ADS/O application
> where dialog(s) call DC Cobol programs. We've just begun =
investigating
> the problem but I thought I would send something to the list in the =
hope
> that someone might had experienced the same thing. I can't find the
> error code referenced anywhere but I seem to remember SF is an abend
> involving the svc but UF doesn't ring a bell with me. By the way, =
the
> reason code is 3. Any suggestions would be appreciated.

------------------------------

Date: Thu, 5 Aug 1999 16:34:13 +0100
From: peter.g...@bt.com
To: idm...@iuassn.com
Subject: RE: [IDMS-L]SOC4
Message-ID:
<5F54BE0116BCD2118C9...@mclmsent02.lon.bt.com>

IBM do not 'reserve' SVC numbers for third party software. It is
up to your MVS team to allocate these.
The only reserved SVC numbers I am aware of are the ones IBM use.
Looking at the documentation the current high number is decimal 139.

In order to issue a SVC the assembler code is X'0Ann' where nn is
the hex value of the SVC number. So how do you have a SVC number higher
than 255 ?.
There are many,many products in the MVS world ( non IDMS related )
that use SVCs and if IBM ever 'ran out of numbers' there would be
serious problems for many
users, suppliers and IBM. So I do not understand your MVS techie's
comment re IBM and IBM only. IBM provide the ability for users to write
their own SVCs.
We are fortunate at this shop as we have 8 SVC numbers reserved
for IDMS. This may seem a lot. But we are currently run 14.1 , 14.0
,12.0 and 10.2 plan is all at least 14.0 soon. Even then the SVC
numbers will still be allocated to 'us' for IDMS use.
The MVS team have no problems with this so I assume there is no
shortage of 'spare SVC numbers'.
Pete
.

> -----Original Message-----
> From: David R Slocum [SMTP:drsl...@cmsenergy.com]
> Sent: 05 August 1999 15:47
> To: idm...@iuassn.com

> Subject: RE: [IDMS-L]SOC4
>
> I have a question about the three "reserved" SVC numbers - Are they
really
> reserved for CA's use? When I approached our MVS techie about using
these
> SVC
> numbers, he informed me that SVC numbers lower than 256 are reserved
for
> use by
> IBM, and IBM only. When I showed him the documentation that said it
was
> okay
> for me to use them, he placed a call with IBM tech support to get the
> straight
> scoop. The person at IBM wasn't aware of these three SVCs being
reserved
> for
> CA. Neither could he find any documentation that said they were. He
said
> that
> if we were to use these SVCs, there was no guarantee that IBM wouldn't

> start
> using them for something else some time in the future. Has anyone
else
> pursued
> this and got a different answer?
>
>
>
>
>
> "Lupico, Joe" <Joe.L...@AIG.com> on 08/05/99 10:31:19 AM
>
> Please respond to idm...@iuassn.com
>

> To: "'idm...@iuassn.com'" <idm...@iuassn.com>
> cc: (bcc: David R Slocum/Pr/Consumers/CMS)

> Subject: RE: [IDMS-L]SOC4
>
>
>
>
> I have never tried, nor do I think I ever will try, reloading the
SVC
> while it is being used. The REFRESH option of CAIRIM actually does a
> delete
> and an add of the SVC being refreshed. This can't be good for a
running
> system.
> I've loaded the SVC on numerous LPARs (both new and REFRESH) and
never
> had
> a problem - but as I stated, I made sure the SVC was inactive. This
meant
> no active IDMS regions and (optionally) no CICS programs trying to
> communicate with IDMS via that SVC.
> IBM reserved three SVCs for IDMS - 172, 173 and 174. I assemble and

> install all three, usually using one for the test systems, one for
prod
> and
> the third is either for BETA regions, or for me to experiment with
(apply
> fixes, change options, etc.). When you have more than one SVC, you
can
> get
> all the systems off one of them, reassemble and reinstall it, then
point
> the
> systems back to it (this assumes you can cycle your systems either
daily
> or
> weekly). And if you maintain multiple releases of IDMS, you'll
probably
> need an SVC at each level.
> Refreshing an SVC while the system is up seems real dangerous.
>
> Joe
>
> > ----------
> > From: Gene.McCormack[SMTP:Gene.Mc...@plpit.fishersci.com]
> > Reply To: idm...@iuassn.com
> > Sent: Thursday, August 05, 1999 9:37 AM
> > To: idm...@iuassn.com
> > Subject: [IDMS-L]SOC4
> >
> > This morning our production CV crashed with a SOC4. Around the same
> time,
> > we
> > were reloading the SVC thru CAIRIMS. Does anybody know if this
could
> have
> > caused the SOC4.
> >
>
>
>
>
>

------------------------------

Date: Thu, 5 Aug 1999 09:39:51 -0600
From: "Wood, Chris" <Chris...@gov.ab.ca> To: "'idm...@iuassn.com'"
<idm...@iuassn.com> Subject: RE: [IDMS-L]UFF3 abend from DC Cobol
Message-ID:
<709658908B3FD311B3A...@eoaexc01.enr.gov.ab.ca>

Jim,

Are you running under LE/370? If so this is a 4083 abend in LE/370.

Chris Wood
Alberta Department of Resource Development CANADA

-----Original Message-----
From: Irwin, Jim [mailto:jir...@mail.sdc.state.mo.us] Sent: August 5,
1999 9:09 AM
To: idm...@iuassn.com

Subject: [IDMS-L]UFF3 abend from DC Cobol

------------------------------

Date: Thu, 5 Aug 1999 11:42:38 -0400
From: "Lupico, Joe" <Joe.L...@AIG.com> To: "'idm...@iuassn.com'"
<idm...@iuassn.com> Subject: RE: [IDMS-L]SOC4
Message-ID: <4F1E68B5C708D11180860001FA372A6501CAFC99@XCS_LIV01>

The MVS guys were also skepitcal about using any non-200 SVC for
non-IBM products, but we've been using them for about three years now
without a problem (both MVS 4.3 and OS/390).
However, we have the luxury of having a couple of LPARs (they breed
like rabbits here) which are used exclusivly for the initial
installation/testing of software and accessable only to systems
programming. If IBM were to use these SVCs, I would know before I ever
got to a "production" LPAR and could alter my stategy as needed.

Joe

> ----------
> From: David R Slocum[SMTP:drsl...@cmsenergy.com]
> Reply To: idm...@iuassn.com
> Sent: Thursday, August 05, 1999 10:47 AM
> To: idm...@iuassn.com
> Subject: RE: [IDMS-L]SOC4
>
> I have a question about the three "reserved" SVC numbers - Are they
really
> reserved for CA's use? When I approached our MVS techie about using
these
> SVC
> numbers, he informed me that SVC numbers lower than 256 are reserved
for
> use by
> IBM, and IBM only. When I showed him the documentation that said it
was
> okay
> for me to use them, he placed a call with IBM tech support to get the
> straight
> scoop. The person at IBM wasn't aware of these three SVCs being
reserved
> for
> CA. Neither could he find any documentation that said they were. He
said
> that
> if we were to use these SVCs, there was no guarantee that IBM wouldn't

> start
> using them for something else some time in the future. Has anyone
else
> pursued
> this and got a different answer?
>
>
>

------------------------------

Date: Thu, 5 Aug 1999 11:51:29 -0400

From: "David R Slocum" <drsl...@cmsenergy.com> To: idm...@iuassn.com

Subject: RE: [IDMS-L]SOC4
Message-ID: <852567C4.0...@pr1lns45.cpco.com>

First, I must admit that I made a mistake. I was talking SVCs, but my
mind was apparently thinking IDMS user exits, when I said that numbers
less than 256 were reserved. I know that SVC numbers can't be higher
than 255. My apologies.
Second, I should have said that our shop tries to stick to IBM's
recommendations as closely as possible. Therefore, all of our
home-grown and third-party SVCs are in the range 200-255. We would
rather do things this way than chance using an SVC number that IBM may
later use. Again, I'm sorry for any confusion I may have caused.

peter.g...@bt.com on 08/05/99 11:34:13 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: David R Slocum/Pr/Consumers/CMS) Subject: RE: [IDMS-L]SOC4

> -----Original Message-----
> From: David R Slocum [SMTP:drsl...@cmsenergy.com]
> Sent: 05 August 1999 15:47
> To: idm...@iuassn.com

> To: "'idm...@iuassn.com'" <idm...@iuassn.com>
> cc: (bcc: David R Slocum/Pr/Consumers/CMS)

------------------------------

Date: Thu, 5 Aug 1999 11:02:53 -0500
From: "Irwin, Jim" <jir...@mail.sdc.state.mo.us> To:
"'idm...@iuassn.com'" <idm...@iuassn.com> Subject: RE: [IDMS-L]UFF3
abend from DC Cobol Message-ID:
<C18BE495D4DDD0118EA...@mail.sdc.state.mo.us>

Thanks Chris. Yep, we are running under LE. The 4083 error seems to
indicate a storage overlay. We have had problems with this application
before walking off the end of a table. I'm going to try to run it under
debug when I get enough info to try to
Narrow things down a little.

-----Original Message-----
From: Wood, Chris [mailto:Chris...@gov.ab.ca]
Sent: Thursday, August 05, 1999 10:40 AM
To: 'idm...@iuassn.com'

Subject: RE: [IDMS-L]UFF3 abend from DC Cobol

Jim,

Are you running under LE/370? If so this is a 4083 abend in LE/370.

Chris Wood

Alberta Department of Resource Development

CANADA

-----Original Message-----
From: Irwin, Jim [mailto:jir...@mail.sdc.state.mo.us]
Sent: August 5, 1999 9:09 AM
To: idm...@iuassn.com

Subject: [IDMS-L]UFF3 abend from DC Cobol

We recently upgraded two of our test CVs to 14.01 (9811). The next
day
one of our customer's applications began getting
UFF3 abends in their DC Cobol programs. This is an ADS/O application
where dialog(s) call DC Cobol programs. We've just begun
investigating
the problem but I thought I would send something to the list in the
hope
that someone might had experienced the same thing. I can't find the
error code referenced anywhere but I seem to remember SF is an abend
involving the svc but UF doesn't ring a bell with me.
By the way, the
reason code is 3. Any suggestions would be appreciated.

------------------------------

Date: Thu, 5 Aug 1999 17:01:57 +0100
From: peter.g...@bt.com
To: idm...@iuassn.com
Subject: RE: [IDMS-L]SOC4
Message-ID:
<5F54BE0116BCD2118C9...@mclmsent02.lon.bt.com>

I agree. Even though we have 8 SVC numbers for IDMS they are all greater
than 200.

> -----Original Message-----
> From: David R Slocum [SMTP:drsl...@cmsenergy.com]
> Sent: 05 August 1999 16:51
> To: idm...@iuassn.com

> Subject: RE: [IDMS-L]SOC4
>
> First, I must admit that I made a mistake. I was talking SVCs, but my

> mind was
> apparently thinking IDMS user exits, when I said that numbers less
than
> 256 were
> reserved. I know that SVC numbers can't be higher than 255. My
> apologies.
> Second, I should have said that our shop tries to stick to IBM's
> recommendations
> as closely as possible. Therefore, all of our home-grown and
third-party
> SVCs
> are in the range 200-255. We would rather do things this way than
chance
> using
> an SVC number that IBM may later use. Again, I'm sorry for any
confusion
> I may
> have caused.
>
>
>
>
>
> peter.g...@bt.com on 08/05/99 11:34:13 AM

>
> Please respond to idm...@iuassn.com
>
> To: idm...@iuassn.com

> cc: (bcc: David R Slocum/Pr/Consumers/CMS)
> Subject: RE: [IDMS-L]SOC4
>
>
>
>
> IBM do not 'reserve' SVC numbers for third party software. It
is up
> to your MVS team to allocate these.
> The only reserved SVC numbers I am aware of are the ones IBM use.

> Looking at the documentation the current high number is decimal 139.
>
> In order to issue a SVC the assembler code is X'0Ann' where nn is
the
> hex value of the SVC number. So how do you have a SVC number higher
than
> 255
> ?.
> There are many,many products in the MVS world ( non IDMS related
)
> that use SVCs and if IBM ever 'ran out of numbers' there would be
serious
> problems for many
> users, suppliers and IBM. So I do not understand your MVS
techie's
> comment re IBM and IBM only. IBM provide the ability for users to
write
> their own SVCs.
> We are fortunate at this shop as we have 8 SVC numbers reserved
for
> IDMS. This may seem a lot. But we are currently run 14.1 , 14.0 ,12.0
and
> 10.2 plan is all at least 14.0 soon. Even then the SVC numbers
will
> still be allocated to 'us' for IDMS use.
> The MVS team have no problems with this so I assume there is no
> shortage of 'spare SVC numbers'.
> Pete
> .

>
> > -----Original Message-----
> > From: David R Slocum [SMTP:drsl...@cmsenergy.com]
> > Sent: 05 August 1999 15:47
> > To: idm...@iuassn.com

> > Subject: RE: [IDMS-L]SOC4
> >
> > I have a question about the three "reserved" SVC numbers - Are they
> really
> > reserved for CA's use? When I approached our MVS techie about using

> these
> > SVC
> > numbers, he informed me that SVC numbers lower than 256 are reserved
for
> > use by
> > IBM, and IBM only. When I showed him the documentation that said it
was
> > okay
> > for me to use them, he placed a call with IBM tech support to get
the
> > straight
> > scoop. The person at IBM wasn't aware of these three SVCs being
> reserved
> > for
> > CA. Neither could he find any documentation that said they were.
He
> said
> > that
> > if we were to use these SVCs, there was no guarantee that IBM
wouldn't
> > start
> > using them for something else some time in the future. Has anyone
else
> > pursued
> > this and got a different answer?
> >
> >
> >
> >
> >
> > "Lupico, Joe" <Joe.L...@AIG.com> on 08/05/99 10:31:19 AM
> >
> > Please respond to idm...@iuassn.com
> >

> > To: "'idm...@iuassn.com'" <idm...@iuassn.com>
> > cc: (bcc: David R Slocum/Pr/Consumers/CMS)

> > Subject: RE: [IDMS-L]SOC4
> >
> >
> >
> >
> > I have never tried, nor do I think I ever will try, reloading the
SVC
> > while it is being used. The REFRESH option of CAIRIM actually does
a
> > delete
> > and an add of the SVC being refreshed. This can't be good for a
running
> > system.
> > I've loaded the SVC on numerous LPARs (both new and REFRESH) and
never
> > had
> > a problem - but as I stated, I made sure the SVC was inactive. This

> meant
> > no active IDMS regions and (optionally) no CICS programs trying to
> > communicate with IDMS via that SVC.
> > IBM reserved three SVCs for IDMS - 172, 173 and 174. I assemble
and
> > install all three, usually using one for the test systems, one for
prod
> > and
> > the third is either for BETA regions, or for me to experiment with
> (apply
> > fixes, change options, etc.). When you have more than one SVC, you
can
> > get
> > all the systems off one of them, reassemble and reinstall it, then
point
> > the
> > systems back to it (this assumes you can cycle your systems either
daily
> > or
> > weekly). And if you maintain multiple releases of IDMS, you'll
probably
> > need an SVC at each level.
> > Refreshing an SVC while the system is up seems real dangerous.
> >
> > Joe
> >
> > > ----------
> > > From: Gene.McCormack[SMTP:Gene.Mc...@plpit.fishersci.com]
> > > Reply To: idm...@iuassn.com
> > > Sent: Thursday, August 05, 1999 9:37 AM
> > > To: idm...@iuassn.com
> > > Subject: [IDMS-L]SOC4
> > >
> > > This morning our production CV crashed with a SOC4. Around the
same
> > time,
> > > we
> > > were reloading the SVC thru CAIRIMS. Does anybody know if this
could
> > have
> > > caused the SOC4.
> > >
> >
> >
> >
> >
> >
>
>
>
>
>

------------------------------

Date: Thu, 5 Aug 1999 10:07:38 -0600
From: "Wood, Chris" <Chris...@gov.ab.ca> To: "'idm...@iuassn.com'"
<idm...@iuassn.com> Subject: RE: [IDMS-L]UFF3 abend from DC Cobol
Message-ID:
<709658908B3FD311B3A...@eoaexc01.enr.gov.ab.ca>

Jim,

What level of IDMS are you running? 12 or 14 and do you have all apars
applied?

Chris

-----Original Message-----
From: Irwin, Jim [mailto:jir...@mail.sdc.state.mo.us] Sent: August 5,
1999 10:03 AM
To: 'idm...@iuassn.com'

Subject: RE: [IDMS-L]UFF3 abend from DC Cobol

-----Original Message-----
From: Wood, Chris [mailto:Chris...@gov.ab.ca]
Sent: Thursday, August 05, 1999 10:40 AM
To: 'idm...@iuassn.com'

Subject: RE: [IDMS-L]UFF3 abend from DC Cobol

Jim,

Are you running under LE/370? If so this is a 4083 abend in LE/370.

Chris Wood

Alberta Department of Resource Development

CANADA

-----Original Message-----
From: Irwin, Jim [mailto:jir...@mail.sdc.state.mo.us]
Sent: August 5, 1999 9:09 AM
To: idm...@iuassn.com

Subject: [IDMS-L]UFF3 abend from DC Cobol

We recently upgraded two of our test CVs to 14.01 (9811). The next
day
one of our customer's applications began getting
UFF3 abends in their DC Cobol programs. This is an ADS/O application
where dialog(s) call DC Cobol programs. We've just begun
investigating
the problem but I thought I would send something to the list in the
hope
that someone might had experienced the same thing. I can't find the
error code referenced anywhere but I seem to remember SF is an abend
involving the svc but UF doesn't ring a bell with me.
By the way, the
reason code is 3. Any suggestions would be appreciated.

------------------------------

Date: Thu, 5 Aug 1999 12:08:04 -0400
From: "McPhee, Sid" <SMc...@hess.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com> Subject: RE: [IDMS-L]SOC4
Message-ID: <E048184A9C25D311B50600104BD011656DEAF1@WDB_EX_002>

The documentation on JOB07 of installation for Release 14.0 reads as
follows:
Valid numbers for the SVC are 172, 173, 174 OR between 200-255. My
client used SVC 212 in their Release 12.1 environment and I changed it
to SVC 202 when I upgraded to Release 14.0. SVC 202 was given to me by
tech support folks and I was told that this was just ONE of the
available numbers at the time.

> -----Original Message-----
> From: David R Slocum [SMTP:drsl...@cmsenergy.com]
> Sent: Thursday, August 05, 1999 10:47 AM
> To: idm...@iuassn.com

> To: "'idm...@iuassn.com'" <idm...@iuassn.com>
> cc: (bcc: David R Slocum/Pr/Consumers/CMS)

------------------------------

Date: Thu, 5 Aug 1999 12:10:44 -0400

From: "Harrison, Robert" <robert....@TROLL.COM> To:
idm...@iuassn.com

Subject: RE: [IDMS-L]SOC4

I recall reading several years ago that IBM and Computer Associates did
in fact reach an agreement to reserve some SVC numbers below 200
exclusively for IDMS. If this is indeed the case, the SVC numbers would
have been 172, 173, and 174. See the IDMS Release 14.0 Installation and
Maintenance Guide, page 2-16, which mentions the "CA-IDMS assigned SVC
numbers". The question of course becomes, "Assigned by whom? IBM?"
Depending on how you read it, the manual seems to imply such an
agreement is still in effect. Bob Harrison, Troll Book Clubs, Mahwah,
NJ

> -----Original Message-----
> From: Perra, Dan J. [SMTP:Dan.J...@ps.net]
> Sent: Thursday, August 05, 1999 11:15 AM
> To: 'idm...@iuassn.com'

> Subject: RE: [IDMS-L]SOC4
>
> I doubt that IBM has reserved SVC numbers for use by any other vendor
> product. IBM does reserve SVCs from 200 - 255 for user SVC numbers.
The
> only
> requirement for using a number any lower is that the number chosen
must
> not
> be in use by the operating system. If IBM chooses to use the SVC you
> picked
> for IDMS then you use a new number for IDMS. The statement regarding
> reserved SVCs is in the IDMS documentation as follows form:
> CA-IDMS(R)
>
> System Operations
> Release 14.0
> R005/&F0SOE
> #SVCOPT parameters
> ..........................
> SVCNO
> Gives the number of the CA-IDMS SVC being generated. Svc-number
must
> be an integer in the range 0 through 255.
>
> Considerations:
>
> Be sure to assign an SVC number that is higher than any SVC
> interrupt numbers used by your operating system. Consult your

> operating system documentation for SVC values that your
operating
> system reserves.
>
> SVC numbers 172, 173, and 174 are reserved SVC number for
CA-IDMS
> for use by CAIRIM. Values 200 through 255 are standard user
SVC
> numbers.
>
>
>
> Thanks
> Daniel J. Perra
> GlS - Interactive Systems
> Office: 972-461-3696
> Group Line: 972-461-3690
> Email: Dan.J...@ps.net

>
>
> -----Original Message-----
> From: David R Slocum [mailto:drsl...@cmsenergy.com]
> Sent: Thursday, August 05, 1999 9:47 AM
> To: idm...@iuassn.com

> Subject: RE: [IDMS-L]SOC4
>
>
> I have a question about the three "reserved" SVC numbers - Are they
really
> reserved for CA's use? When I approached our MVS techie about using
these
> SVC
> numbers, he informed me that SVC numbers lower than 256 are reserved
for
> use
> by
> IBM, and IBM only. When I showed him the documentation that said it
was
> okay
> for me to use them, he placed a call with IBM tech support to get the
> straight
> scoop. The person at IBM wasn't aware of these three SVCs being
reserved
> for
> CA. Neither could he find any documentation that said they were. He
said
> that
> if we were to use these SVCs, there was no guarantee that IBM wouldn't

> To: "'idm...@iuassn.com'" <idm...@iuassn.com>
> cc: (bcc: David R Slocum/Pr/Consumers/CMS)

------------------------------

Date: Thu, 5 Aug 1999 12:06:52 -0400
From: rcg...@statestreet.com
To: idm...@iuassn.com
Subject: RE: [IDMS-L]SOC4
Message-ID: <H000107a23c93185@MHS>

Unless I'm mistaken ..... The SVC is NOT reentrant.....and has tables
built within itself. It would be very dangerous to reload it while IDMS
and CICS and BATCH jobs run against it.
RCG
----------
From: Joe.Lupico / svo4shar (Joe.L...@AIG.com) To: idm...@iuassn.com
Subject: RE: [IDMS-L]SOC4
Date: Thursday, August 05, 1999 7:31AM

<<File Attachment: REIDMS-L.TXT>>
I have never tried, nor do I think I ever will try, reloading the SVC
while it is being used. The REFRESH option of CAIRIM actually does a
delete and an add of the SVC being refreshed. This can't be good for a
running system.
I've loaded the SVC on numerous LPARs (both new and REFRESH) and never
had a problem - but as I stated, I made sure the SVC was inactive. This
meant no active IDMS regions and (optionally) no CICS programs trying to
communicate with IDMS via that SVC.
IBM reserved three SVCs for IDMS - 172, 173 and 174. I assemble and
install all three, usually using one for the test systems, one for prod
and the third is either for BETA regions, or for me to experiment with
(apply fixes, change options, etc.). When you have more than one SVC,
you can get all the systems off one of them, reassemble and reinstall
it, then point the systems back to it (this assumes you can cycle your
systems either daily or weekly). And if you maintain multiple releases
of IDMS, you'll probably need an SVC at each level.
Refreshing an SVC while the system is up seems real dangerous.

Joe

.......................................................................

Item Subject: WINMAIL.DAT
Could not convert Microsoft Mail Message Data item to text.
Will attempt to 'shar' item as file '08fleh4' at end of msg.

# This is a shell archive. Remove anything before this line, # then
unpack it by saving it in a file and typing "sh file".
#
# Wrapped by openmail <openmail@svoa0020> on Thu Aug 5 12:13:01 1999 #
# This archive contains:
# 08fleh4
#
# Error checking via wc(1) will be performed.

LANG=""; export LANG
PATH=/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:$PATH; export PATH

rm -f /tmp/uud$$
(echo "begin 666 /tmp/uud$$\n#;VL*n#6%@x\n \nend" | uudecode) >/dev/null
2>&1 if [ X"`cat /tmp/uud$$ 2>&1`" = Xok ]
then
unpacker=uudecode
else
echo Compiling unpacker for non-ascii files
pwd=`pwd`; cd /tmp
cat >unpack$$.c <<'EOF'
#include <stdio.h>
#define C (*p++ - ' ' & 077)
main()
{
int n;
char buf[128], *p, a,b;

scanf("begin %o ", &n);
gets(buf);

if (freopen(buf, "w", stdout) == NULL) {
perror(buf);
exit(1);
}

while (gets(p=buf) && (n=C)) {
while (n>0) {
a = C;
if (n-- > 0) putchar(a << 2 | (b=C) >> 4);
if (n-- > 0) putchar(b << 4 | (a=C) >> 2);
if (n-- > 0) putchar(a << 6 | C);
}
}
exit(0);
}
EOF
cc -o unpack$$ unpack$$.c
rm unpack$$.c
cd $pwd
unpacker=/tmp/unpack$$
fi
rm -f /tmp/uud$$

echo x - 08fleh4 '[non-ascii]'
$unpacker <<'@eof'

Attachment Converted: "C:\PROGRAM FILES\QUALCOMM\EUDORA
MAIL\Attach\08fleh41" @eof
set `wc -lwc <08fleh4`
if test $1$2$3 != 0172
then
echo ERROR: wc results of 08fleh4 are $* should be 0 1 72 fi

chmod 660 08fleh4

rm -f /tmp/unpack$$
exit 0

------------------------------

Date: Thu, 5 Aug 1999 11:29:44 -0500
From: "Irwin, Jim" <jir...@mail.sdc.state.mo.us> To:
"'idm...@iuassn.com'" <idm...@iuassn.com> Subject: RE: [IDMS-L]UFF3
abend from DC Cobol Message-ID:
<C18BE495D4DDD0118EA...@mail.sdc.state.mo.us>

We are running 14.01 (9811) and I believe we have all apars applied. We
went through all of the LE/DC Cobol problems when we went to 12.01 and
thought we had things pretty much in line. It's possible that it may be
a coincidence that it is happening after the upgrade. We don't know for
certain what, if anything, has changed with the application. We're just
trying to cover all the bases.

-----Original Message-----
From: Wood, Chris [mailto:Chris...@gov.ab.ca]
Sent: Thursday, August 05, 1999 11:08 AM
To: 'idm...@iuassn.com'

Subject: RE: [IDMS-L]UFF3 abend from DC Cobol

Jim,

What level of IDMS are you running? 12 or 14 and do you have all apars

applied?

Chris

-----Original Message-----
From: Irwin, Jim [mailto:jir...@mail.sdc.state.mo.us]
Sent: August 5, 1999 10:03 AM
To: 'idm...@iuassn.com'

Subject: RE: [IDMS-L]UFF3 abend from DC Cobol

Thanks Chris. Yep, we are running under LE. The 4083 error seems to
indicate a storage overlay. We have had problems with this
application
before walking off the end of a table. I'm going to try to run it
under
debug when I get enough info to try to
Narrow things down a little.

-----Original Message-----
From: Wood, Chris
[mailto:Chris...@gov.ab.ca]
Sent: Thursday, August 05, 1999 10:40 AM
To: 'idm...@iuassn.com'

Subject: RE: [IDMS-L]UFF3 abend
from DC Cobol

Jim,

Are you running under LE/370? If so this is a 4083 abend
in LE/370.

Chris Wood

Alberta Department of Resource
Development

CANADA

-----Original Message-----
From: Irwin, Jim
[mailto:jir...@mail.sdc.state.mo.us]
Sent: August 5, 1999 9:09 AM
To: idm...@iuassn.com

Subject: [IDMS-L]UFF3 abend from DC Cobol

We recently upgraded two of our test CVs to 14.01
(9811). The next day
one of our customer's applications began getting
UFF3 abends in their DC Cobol programs.
This is an
ADS/O application
where dialog(s) call DC Cobol programs.
We've just
begun investigating
the problem but I thought I would send something to the
list in the hope
that someone might had experienced the same thing. I
can't find the
error code referenced anywhere but I seem to remember SF
is an abend
involving the svc but UF doesn't ring a bell with me.
By the way, the
reason code is 3. Any suggestions would be appreciated.

------------------------------

Date: Thu, 5 Aug 1999 12:40:20 -0500
From: "Hynes, Carol" <carol...@dwd.state.wi.us> To:
"'idm...@iuassn.com'" <idm...@iuassn.com> Subject: RE: [IDMS-L]SOC4
Message-ID:
<6929EAD56AF6D2118C7...@aspxchg4.DWD.STATE.WI.US>

This issue came up during our upgrade to 12.01 in 1996. We contacted
IBM and were told they have no such agreement with CA and that SVC
numbers under 200 should not be used. We also opened an issue with CA
at the time.
According to CA's Nancy Jones there is a "loose agreement" with CA to
use those SVC numbers. CA told us to open a DAR requesting
documentation changes. It wasn't worth the effort for us.

> -----Original Message-----
> From: David R Slocum [SMTP:drsl...@cmsenergy.com]
> Sent: Thursday, August 05, 1999 9:47 AM
> To: idm...@iuassn.com

> To: "'idm...@iuassn.com'" <idm...@iuassn.com>
> cc: (bcc: David R Slocum/Pr/Consumers/CMS)

------------------------------

Date: Thu, 05 Aug 1999 13:13:55 -0500
From: david_...@acs-inc.com
To: <IDM...@IUASSN.COM>
Subject: idms and emc dasd
Message-ID: <9908059338....@acs-inc.com>

We are currently running idms v14 for all but 1 region which is at
10.214. We are going to be moving in some EMC dasd, has anyone had

experience will EMC dasd and idms (good or bad). Thank you in
advance...

David Brenner
ACS
david_...@acs-inc.com
214-841-6492

------------------------------

Date: Thu, 05 Aug 1999 14:40:24 -0400
From: "Steve Wolff" <s...@ddpmi.com>
To: <idm...@iuassn.com>
Subject: Re: [IDMS-L]idms and emc dasd
Message-ID: <s7a9a2...@mail.ddpmi.com>

David,

We have had EMC dasd for 3 years now. Has been performing great and we =
have not had any problems up to this point.

Steve Wolff

Delta Dental Plan of Michigan
swo...@ddpmi.com=20
517-347-5820 Voice
517-347-5366 Fax

>>> <david_...@acs-inc.com> 08/05/99 02:13PM >>>
We are currently running idms v14 for all but 1 region which is
at=20
10.214. We are going to be moving in some EMC dasd, has anyone =
had=20
experience will EMC dasd and idms (good or bad). Thank you in=20
advance...
=20
David Brenner =20
ACS
david_...@acs-inc.com=20
214-841-6492

------------------------------

Date: Thu, 5 Aug 1999 14:06:37 -0400
From: rcg...@statestreet.com
To: idm...@iuassn.com
Subject: RE: [IDMS-L]SOC4
Message-ID: <H000107a23cbb333@MHS>

--openmail-part-10fe52f8-00000001
Content-Type: text/plain; charset=US-ASCII; name="RE:"
Content-Disposition: inline; filename="RE:" Content-Transfer-Encoding:
7bit

Dont get too hung up on the number.......There is no guarantee that the
number is "RESERVED" forever. There are other products that can also use
that same number.
RCG
----------
From: carol.hynes / INTERNET (carol...@dwd.state.wi.us) To:
idm...@iuassn.com
Subject: RE: [IDMS-L]SOC4
Date: Thursday, August 05, 1999 10:40AM

> -----Original Message-----
> From: David R Slocum [SMTP:drsl...@cmsenergy.com]
> Sent: Thursday, August 05, 1999 9:47 AM
> To: idm...@iuassn.com

> To: "'idm...@iuassn.com'" <idm...@iuassn.com>
> cc: (bcc: David R Slocum/Pr/Consumers/CMS)

--openmail-part-10fe52f8-00000001
Content-Type: application/ms-tnef; name="WINMAIL.DAT"
Content-Disposition: attachment; filename="WINMAIL.DAT"
Content-Transfer-Encoding: base64

eJ8+IgAAAQuAAQBBAAAANjkyOUVBRDU2QUY2RDIxMThDN0MwMDAwNUE0MjgwQkUwMzE1RDko
YSlhc3B4Y2hnNC5EV0QuU1RBVEUuV0kuVQBLEA==

--openmail-part-10fe52f8-00000001--

------------------------------

Date: Thu, 5 Aug 1999 16:37:49 -0400
From: "Al A Shuryan" <shur...@meritorauto.com> To: idm...@iuassn.com
Subject: Re: [IDMS-L]idms and emc dasd
Message-ID: <852567C4.0...@amerhub.meritorauto.com>

A client of mine saved a machine upgrade when they went IBM 3375's to
EMC 3380's.
We measured a 25% imporvement in I/O and decreased I/O wait time.
I think we had to change the DEVICE TYPE in our DMCL's and IDMSDUMP
everything from 3375 to go to EMC 3390's. I belive there is a option to
define the EMC devices to look like what ever you want at slack space
expense.
Al Shuryan

david_...@acs-inc.com on 08/05/99 02:13:55 PM

Please respond to idm...@iuassn.com

To: IDM...@IUASSN.COM
cc: (bcc: Al A Shuryan/Amer/Auto)

Subject: [IDMS-L]idms and emc dasd

We are currently running idms v14 for all but 1 region which is at
10.214. We are going to be moving in some EMC dasd, has anyone had

experience will EMC dasd and idms (good or bad). Thank you in
advance...

David Brenner
ACS
david_...@acs-inc.com
214-841-6492

------------------------------

Date: Thu, 5 Aug 1999 14:46:39 -0600
From: "Wood, Chris" <Chris...@gov.ab.ca> To: "'idm...@iuassn.com'"

<idm...@iuassn.com> Subject: RE: [IDMS-L]LE/370 and Storage Message-ID:
<709658908B3FD311B3A...@eoaexc01.enr.gov.ab.ca>

William,

My partner, Dennis robock, spoke about our issues here at Resource
Development when we went to LE/370. We have a below the line storage
pool for USER and USER-KEPT and find that it is this pool that has the
problem.
We also have an equivalent above the line storage pool for
USER/USER-KEPT.
We have recently increased this above the line storage pool and have not
seen the same requirements for below the line. Just about the same time
we had some of our application DC-COBOL programs changed, so we are
unsure which of these two events may have solved the problem.

I would suggest splitting up your below the line storage by at least
adding a pool for USER/USER-KEPT and having an equivalent above the line
pool. Then give the above the line pool plenty and see if the below the
line ones requirements reduce.

Chris Wood
Alberta Department of Resource Development CANADA

Thanks

Bill Martin

Black&Decker

------------------------------

Date: Thu, 05 Aug 1999 14:56:16 -0500

From: Chris Hoelscher <hoel...@flash.net> To: idm...@iuassn.com

Subject: thoughts on SVCs
Message-ID: <1999080520...@chupacabras.flash.net>

some time ago, i intentionally (thats my story and i'm stocking to it)
refreshed an SVC while CVs were up and they did indeed die a quick and
painless death! (12.01)

as far as reserved - depsite any "loose" agreements that IBM doesnt
acknowledge and CA says may exist - the real problem comes in a large
decentralized shop: the idms techies ask if svc 173 is used.. MVS
techies say no, so idms techies use it in CAIRIM, SYSGEN, and RHDCSRTT.
However, since it is not "genned" into the MVS system, MVS has no
official record of its existance )we use the SHOWMVS utility that was
floating around to look at all the SVCs, whether "genned" or dynamic.
But even if IBM honors CA in not assigning 172-173-174, nothing prevents
another software co from using those, nor prevents an ambitious person
from reserving one of those for his/her own needs (whatever those may
be). And, most likely, the person who registers the SVC to MVS will
probably win ....

chris

------------------------------

Date: Thu, 05 Aug 1999 15:17 -0600 (MDT) From: Will Hathcock
<Will.H...@wcom.com> To: IDM...@iuassn.com
Subject: Re: [IDMS-L]idms and emc dasd
Message-ID: <19990805212035.IGYY5062@localHost>

David,

You will like EMC dasd! I have been working with them for years and it's
some of the best dasd I've ever seen. We've had almost no problems since
using their dasd. They employ a "hot backup" system that works great and
automatically dials their home base and alerts them that the hardware
needs repair. The boxes can be configured in many ways to support
database systems like IDMS. For instance a 3390 mod-3 can be split up
three ways to make three mod-1s. Why would us use a mod-1, maybe to put
the journals or scratch area on them. Since each volume has a cache
associated with it, the write time are terrific. If you can, have the
EMC SE's work with you on configuring the box. In the end, you will need
to study their material and determine how to make the best use of it for
IDMS.

Will..

We are currently running idms v14 for all but 1 region which is at
10.214. We are going to be moving in some EMC dasd, has anyone had

experience will EMC dasd and idms (good or bad). Thank you in
advance...

David Brenner
ACS
david_...@acs-inc.com
214-841-6492

------------------------------

Date: Thu, 05 Aug 1999 14:41:14 PDT

From: "Jim Phillips" <jimphi...@hotmail.com> To: idm...@iuassn.com

Subject: Re: [IDMS-L]idms and emc dasd
Message-ID: <1999080521411...@hotmail.com>

I've heard good things about EMC but I thought write caching for
journals (and possibly database files) was a no-no regardless of the
hardware vendor.
Is it safe ?

>From: Will Hathcock <Will.H...@wcom.com>
>Reply-To: idm...@iuassn.com
>To: IDM...@iuassn.com

>Subject: Re: [IDMS-L]idms and emc dasd
>Date: Thu, 05 Aug 1999 15:17 -0600 (MDT)
>
>David,
>
>You will like EMC dasd! I have been working with them for years and
>it's some of the best dasd I've ever seen. We've had almost no problems

>since using their dasd. They employ a "hot backup" system that works
>great and automatically dials their home base and alerts them that
>the hardware needs repair. The boxes can be configured in many ways
>to support database systems like IDMS. For instance a 3390 mod-3 can be

>split
>up three ways to make three mod-1s. Why would us use a mod-1, maybe
>to put the journals or scratch area on them. Since each volume has
>a cache associated with it, the write time are terrific. If you can,
>have the EMC SE's work with you on configuring the box. In the end,
>you will need to study their material and determine how to make the
>best use of it for IDMS.
>
>Will..
>
>
>
> We are currently running idms v14 for all but 1 region which is
at
> 10.214. We are going to be moving in some EMC dasd, has anyone
had
> experience will EMC dasd and idms (good or bad). Thank you in
> advance...
>
> David Brenner
> ACS
> david_...@acs-inc.com
> 214-841-6492
>

______________________________________________________ Get Your Private,
Free Email at http://www.hotmail.com

------------------------------

Date: Thu, 05 Aug 1999 16:04 -0600 (MDT) From: Will Hathcock
<Will.H...@wcom.com> To: IDM...@iuassn.com
Subject: Re: [IDMS-L]idms and emc dasd
Message-ID: <19990805220738.IXIX5062@localHost>

For EMC boxes there is no option to turn it off. The EMC dasd uses
caching for all of it's I/O. This is not the old IBM option of turning
on caching to improve performance, this is internal caching. Without
getting into too much detail, the box comes with a predetermined amount
of cache. Every volume is then allocated a certain amount and the rest
is open for general use by all volumes. This is why breaking up a box
into mod-1s, mod-2s, and mod-3s can be advantageous. You can create
volumes that match the sizes of files because you can no longer turn on
caching at the dsn level. This might be very good for files that do not
grow, like the journals or scratch or other 'hot' files.
You have to do this up front because once the box is installed you will
not likely be able to go back and reconfigure it.

Will..

I've heard good things about EMC but I thought write caching for
journals (and possibly database files) was a no-no regardless of the
hardware vendor.
Is it safe ?

>
>
>
> We are currently running idms v14 for all but 1 region which is
at
> 10.214. We are going to be moving in some EMC dasd, has anyone
had
> experience will EMC dasd and idms (good or bad). Thank you in
> advance...
>
> David Brenner
> ACS
> david_...@acs-inc.com
> 214-841-6492
>

______________________________________________________ Get Your Private,
Free Email at http://www.hotmail.com

------------------------------

Date: Thu, 05 Aug 1999 20:56:24 -0500

From: Chris Hoelscher <hoel...@flash.net> To: idm...@iuassn.com

Subject: thanks to all
Message-ID: <1999080603...@chupacabras.flash.net>

the subscription count for idms-l is over 670 - all of whom joined from
scratch (no carry-overs from the "classic" idms-l). It is obvious that
IDMS is alive and well and that many of us are committed to idms for our
(and our employers') future. I personally want to thank everyone who
has and is contributing to and/or uning the information in IDMS-L,
ensuring that IDMS will remain TBDDITL (The Best Damn Database In The
Land)! Hopefully within the next month we will have some VERY GOOD NEWS
about the list.

Chris Hoelscher
IDMS-L

------------------------------

Date: Fri, 6 Aug 1999 09:19:30 +0100
From: "Stewart, Jeremy" <Stew...@AWA-CPO.COM> To: "'idm...@iuassn.com'"
<idm...@iuassn.com> Subject: "SHADOW DIRECT" ( Neon Systems ) & IDMS
Message-ID: <C8C547D6EBA3D111BBFF00805FA604547AD67F@BASEXCHANGE>

Does anyone else in the group have any experience of this product,
please, and would they be willing to share their experience with our
developers ?
Their current problem is that IDMS keeps going short on storage in
program pool 0 although the software is merely calling a "normal" COBOL
program to read sets of records. Obviously we can keep increasing this
program pool ( within limits ) but we are not happy about what might
take place in our on-line production system when this is thrown in as
well !

The error message in the IDMS log is:

DB347018 V71 T220 Not enough storage - size requested 476C

Original program pool 0 storage was 2600K, then 4000K, then 5600K.

Jeremy R.L. Stewart
Database Administrator
Carbonless European Operations
Arjo Wiggins Appleton Holdings Ltd

________________________________________________________________________________
This message has been checked for all known viruses by the Star
Screening System http://academy.star.co.uk/public/virustats.htm

------------------------------

End of IDMS-L V1 #47
********************

Chris Hoelscher

unread,

Aug 13, 1999, 3:00:00 AM8/13/99

To: <IDM...@iuassn.com>
Subject: IDMS-L V1 #48

IDMS-L Sat, 7 Aug 1999 Volume 1 :
Number 48

In this issue:

Re: [IDMS-L]"SHADOW DIRECT" ( Neon Systems ) & IDMS
RE: [IDMS-L]"SHADOW DIRECT" ( Neon Systems ) & IDMS
Release 14.1 on VSE/ESA
RE: [IDMS-L]thoughts on SVCs
RE: [IDMS-L]idms and emc dasd
RE: [IDMS-L]thoughts on SVCs
UFF3
RE: [IDMS-L]UFF3
RE: [IDMS-L]UFF3
Re: [IDMS-L]UFF3
Re: [IDMS-L]UFF3
RE: [IDMS-L]UFF3
RE: [IDMS-L]UFF3
Easytrieve
Re: [IDMS-L]Easytrieve
SQL Sample batch cobol and Compile JCL

----------------------------------------------------------------------

Date: Fri, 6 Aug 1999 08:53:02 -0400
From: lpet...@csc.com
To: idm...@iuassn.com
Subject: Re: [IDMS-L]"SHADOW DIRECT" ( Neon Systems ) & IDMS
Message-ID: <852567C5.0...@cscmail.csc.com>

I don't have experience with 'Shadow Direct' per se, but maybe the
following is
food for thought. If the system is going to the high water mark in the
below
the line program pool (not pool 0) then that's not a big deal. The
programs
within the pool will get overlayed and the space reused. The cost is
increasing number of loads, not normally a big deal. However, if it's
storage
pool 0 that's running out of storage, that is a big deal, usually
resulting in
system hangs. In this case I would push all Cobol programs and their
relocated
working storage/bll/stuff above the line by relinking. There's a
technote on
TCC how to do that exactly. You do not mention the version of COBOL, I
assume
it's VS. If it is, beware of compile options like DYNAM. When you
mention
shadow direct 'call's' the cobol programs, then it is not going thru the
regular
idms TRANSFER CONTROL processing, but using an IBM call without IDMS's
knowing
(unless it's COBOLII then it's svc screened). This is dangerous since
COBOLVS
runs in batch mode when it's called and when it comes to
acquiring/releasing
resources, that is, it relies on MVS to release resources on job
termination;
since IDMS cv is the job, the termination won't happen until shutdown
and
resources aren't freed. I would replace shadow direct's calls with idms

transfer cotrol verbs and let idms do the program loading and working
storage
allocations.

Lutz Petzold
CSC

Stew...@awa-cpo.com on 08/06/99 04:19:30 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Lutz H Petzold/TMG/CSC)
Subject: [IDMS-L]"SHADOW DIRECT" ( Neon Systems ) & IDMS

Does anyone else in the group have any experience of this product,
please,
and would they be willing to share their experience with our developers
?
Their current problem is that IDMS keeps going short on storage in
program
pool 0 although the software is merely calling a "normal" COBOL program
to read sets of records. Obviously we can keep increasing this program
pool
( within limits ) but we are not happy about what might take place in
our
on-line production system when this is thrown in as well !

The error message in the IDMS log is:

DB347018 V71 T220 Not enough storage - size requested 476C

Original program pool 0 storage was 2600K, then 4000K, then 5600K.

Jeremy R.L. Stewart
Database Administrator
Carbonless European Operations
Arjo Wiggins Appleton Holdings Ltd

________________________________________________________________________________

This message has been checked for all known viruses by the Star
Screening System
http://academy.star.co.uk/public/virustats.htm

------------------------------

Date: Fri, 6 Aug 1999 09:16:24 -0400
From: "Daniel begin" <dan...@aquisoft.com>
To: <idm...@iuassn.com>
Subject: RE: [IDMS-L]"SHADOW DIRECT" ( Neon Systems ) & IDMS
Message-ID: <NBBBLFPOMLDNHLGFP...@aquisoft.com>

Jeremy,

You have to wonder what will happen when you have multiple users
accessing
CA-IDMS concurrently. From the information you provide, you are running
short on storage for ONE get storage request.

I would contact the Neon Systems guys.

Bye,

Daniel
Aquisoft

____________________________________________________________________________

------------------------------

Date: Fri, 6 Aug 1999 09:22:25 -0400
From: Paul Pfeiffer <PPfe...@alside.com>
To: idm...@iuassn.com
Subject: Release 14.1 on VSE/ESA
Message-ID: <0D836C0C9BB0D1118A6700A0C963E1FB87D3C9@EXCHANGE>

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_01BEE00E.B9E30C02
Content-Type: text/plain

Hi, Are there any VSE sites that have successfully upgraded to Release
14.1
(9811). We are currently executing 12.1 (9707). We would like to hear
all
experiences, good or bad, from any VSE shops.

Thanks in advance for your help.

Regards,

Paul Pfeiffer
PPfe...@Alside.com

------_=_NextPart_001_01BEE00E.B9E30C02
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

Release 14.1 on VSE/ESA

Hi, Are there any VSE sites that = have successfully upgraded to
Release 14.1 (9811). We are = currently executing 12.1 (9707). We
would like to hear all = experiences, good or bad, from any VSE shops.

Thanks in advance for your = help.

Regards,

Paul Pfeiffer
PPfe...@Alside.com

------_=_NextPart_001_01BEE00E.B9E30C02--

------------------------------

Date: Fri, 6 Aug 1999 10:16:32 -0400

From: "Lupico, Joe" <Joe.L...@AIG.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: [IDMS-L]thoughts on SVCs
Message-ID: <4F1E68B5C708D11180860001FA372A6501CAFC9D@XCS_LIV01>

It seems to me that using SVCs 172, 173 and/or 174 should only be
dangerous if IBM decides to use them and not honor the "agreement" with
CA.
For me, that means testing on our "play" LPAR whenever the operating
system
is upgraded to make sure IDMS is still working. I just checked with our

senior MVS guy to insure that only the operating system uses any SVC
less
than 200 (even CICS is over 200), so there shouldn't be a problem with
third
party vendors. Also, nothing prevents a third party vendor (or someone
else) from trying to use a 201-255 SVC that IDMS is already using,
especially since SVCs are installed in different ways. There is no
getting
around the fact that SVC assignments need to be documented somewhere so
that
no conflicts occur.
So, you have a choice - have possible conflicts with IBM or third
party
vendors. Since changing an SVC assignment for an IDMS system is pretty
painless, I choose to keep my eyes on a single vendor (IBM) rather than
enter the battle for 200+ SVCs with many vendors.
Also, another point to make is for those of us who maintain IDMS on
many
LPARs for different clients. Because every LPAR is unique in terms of
what
products may be installed, and at what release level, the assignment of
SVCs
201-255 may be entirely different, especially if the LPAR was "copied"
from
a client site. However, you can always count on the sub-200 SVCs to be
in
the same place. Therefore, you can be sure that if SVCs 172, 173 and
174
are free on one LPAR, they will be free on the others (assuming they are
all
MVS systems). This makes it easy to keep track of IDMS SVCs - they are
172,
173 and 174 on all LPARs. When you start having 35-40 LPARs, you go for
all
the simplicity you can get.

Joe

> ----------
> From: Chris Hoelscher[SMTP:hoel...@flash.net]
> Reply To: idm...@iuassn.com
> Sent: Thursday, August 05, 1999 3:56 PM
> To: idm...@iuassn.com
> Subject: [IDMS-L]thoughts on SVCs

------------------------------

Date: Fri, 6 Aug 1999 10:43:37 -0400
From: =?iso-8859-1?Q?=22Fillion=2C_Andr=E9=22?= <AFil...@GazMet.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]idms and emc dasd
Message-ID: <8F7475AC87E5D011873A00A0C9A3CABEDC1AE8@MTLEXC01>

We have been using EMC for the last 5 years and i agree with Will =
Hathcock.
It is the best dasd i have seen. We have never experience a down time =

even
when disk failure occured. The technician came in to replace the disk =

live
and we never noticed a degradation in performance...

The dasd respond time is great (around 3 or 4 millisecond). Be ready =
for an
improvement in the general troughtput of the machine. If i remember
correctly we saw a 40% cut in the batch windows. I don't remember the
number for the online.

Since June 98 we have also concentrated the NT and Unix dasd on the =
same box
and it is also working great.

Andre Fillion
Technology Architect
Gaz Metropolitain

> -----Message d'origine-----
> De: Jim Phillips [SMTP:jimphi...@hotmail.com]
> Date: 5 ao=FBt, 1999 17:41
> =C0: idm...@iuassn.com
> Objet: Re: [IDMS-L]idms and emc dasd
>=20
> I've heard good things about EMC but I thought write caching for =
journals
>=20

> (and possibly database files) was a no-no regardless of the hardware

> vendor.=20
> Is it safe ?
>=20
>=20

> >From: Will Hathcock <Will.H...@wcom.com>
> >Reply-To: idm...@iuassn.com
> >To: IDM...@iuassn.com
> >Subject: Re: [IDMS-L]idms and emc dasd
> >Date: Thu, 05 Aug 1999 15:17 -0600 (MDT)
> >
> >David,
> >
> >You will like EMC dasd! I have been working with them for years and

> >it's some of the best dasd I've ever seen. We've had almost no =

problems
> >since using their dasd. They employ a "hot backup" system that works
> >great and automatically dials their home base and alerts them that
> >the hardware needs repair. The boxes can be configured in many ways
> >to support database systems like IDMS. For instance a 3390 mod-3 can

=
be=20

> >split
> >up three ways to make three mod-1s. Why would us use a mod-1, maybe
> >to put the journals or scratch area on them. Since each volume has
> >a cache associated with it, the write time are terrific. If you can,
> >have the EMC SE's work with you on configuring the box. In the end,
> >you will need to study their material and determine how to make the
> >best use of it for IDMS.
> >
> >Will..
> >
> >
> >

> > We are currently running idms v14 for all but 1 region which =
is at
> > 10.214. We are going to be moving in some EMC dasd, has =

anyone had
> > experience will EMC dasd and idms (good or bad). Thank you in
> > advance...
> >
> > David Brenner
> > ACS
> > david_...@acs-inc.com
> > 214-841-6492
> >

>=20
>=20

> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

------------------------------

Date: Fri, 6 Aug 1999 10:49:31 -0400
From: lpet...@csc.com
To: idm...@iuassn.com
Subject: RE: [IDMS-L]thoughts on SVCs
Message-ID: <852567C5.0...@cscmail.csc.com>

I have seen the MVS sysprog maintain a comment about svc numbers and
products in
the svc nucleus table, even though a dynamic svc isn't linked with the
nucleus.
Since so many vendors install their svc's dynamically, this is a good
reference
point. When you run CAIRIM without!!! the 'refresh' option it will
tell you
that the svc is already there and it didn't reload. So, it's like the
smpe
applycheck, run CAIRIM without the refresh option for a first time
install just
to make sure the 'bucket' is empty.
What happens if an svc is already there when CAIRIM with the refresh
option is
run? It will simply overlay the existing svc with the new one and the
other
product will hit the skids with some VERY unusual messages.
BTW, I don't recall IBM publishing that svcs 172,173,174 are CA
exclusives. If
true that would be interesting since there are so many vendors out there
who
could claim an exclusive themselves.
'Look before leap' never hurt me.

Lutz Petzold

Joe.L...@aig.com on 08/06/99 10:16:32 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Lutz H Petzold/TMG/CSC)
Subject: RE: [IDMS-L]thoughts on SVCs

Joe

> ----------
> From: Chris Hoelscher[SMTP:hoel...@flash.net]
> Reply To: idm...@iuassn.com
> Sent: Thursday, August 05, 1999 3:56 PM
> To: idm...@iuassn.com
> Subject: [IDMS-L]thoughts on SVCs

------------------------------

Date: Fri, 6 Aug 1999 11:33:20 -0500

From: "Irwin, Jim" <jir...@mail.sdc.state.mo.us>
To: idm...@iuassn.com
Subject: UFF3

Message-ID:
<C18BE495D4DDD0118EA...@mail.sdc.state.mo.us>

Thanks for the suggestions. Using the online debugger we have narrowed
it to the GET TIME DATE INTO command. I've been looking at the
documentation but I don't see any changes. We have been running under
Cobol for MVS for some time now and the problem just started after our
upgrade to 14.01. Any ideas?

------------------------------

Date: Fri, 6 Aug 1999 10:37:03 -0600

From: "Wood, Chris" <Chris...@gov.ab.ca>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]UFF3

Message-ID:
<709658908B3FD311B3A...@eoaexc01.enr.gov.ab.ca>

Jim,

Sounds like you had better report this one to CA. We will try out 14.1
soon
and we use GET TIME compiled under COBOL FOR MVS 1.2.

Chris Wood
Alberta Department of Resource Development
CANADA

-----Original Message-----
From: Irwin, Jim [mailto:jir...@mail.sdc.state.mo.us]
Sent: August 6, 1999 10:33 AM
To: idm...@iuassn.com
Subject: [IDMS-L]UFF3

------------------------------

Date: Fri, 6 Aug 1999 11:49:45 -0500

From: "Irwin, Jim" <jir...@mail.sdc.state.mo.us>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]UFF3

Message-ID:
<C18BE495D4DDD0118EA...@mail.sdc.state.mo.us>

Yeah, I think you're right. I'm going to spend today verifying a few
things on this end and will probably out in an issue this afternoon or
Monday morning if our side checks out.

-----Original Message-----
From: Wood, Chris [mailto:Chris...@gov.ab.ca]
Sent: Friday, August 06, 1999 11:37 AM
To: 'idm...@iuassn.com'

Subject: RE: [IDMS-L]UFF3

Jim,

Sounds like you had better report this one to CA. We
will try out 14.1 soon
and we use GET TIME compiled under COBOL FOR MVS 1.2.

Chris Wood
Alberta Department of Resource Development
CANADA

-----Original Message-----
From: Irwin, Jim [mailto:jir...@mail.sdc.state.mo.us]
Sent: August 6, 1999 10:33 AM
To: idm...@iuassn.com
Subject: [IDMS-L]UFF3

Thanks for the suggestions. Using the online debugger
we have narrowed
it to the GET TIME DATE INTO command. I've been looking
at the
documentation but I don't see any changes. We have been
running under
Cobol for MVS for some time now and the problem just
started after our
upgrade to 14.01. Any ideas?

------------------------------

Date: Fri, 06 Aug 1999 12:01:52 -0500
From: "Brian Potts" <Bdp...@comdisco.com>
To: <idm...@iuassn.com>
Subject: Re: [IDMS-L]UFF3
Message-ID: <s7aace...@groupwise.comdisco.com>

I know there has been one change to the GET TIME DATE INTO....

It has to do with the year 2000.

They modified the DATE INTO. This is off the top of my head, so you may
=
want to verify the details. I believe the receiving field for date into
=
was supposed to always be S9(7) PACKED DECIMAL. This meant your end =
result looked something like this 00YYDDD, where the Julian date was
the =
last five position and it was always preceded by zero zero .

The "new" feature is that starting in the base year (1998?) you would
get =
00YYDDD, but in subsequent years the first two positions would be =
incremented. Therefore the next year (1999?) would be '01YYDDD'
followed =
the next year by '02YYDDD'...I think you get the picture.

So, you may want to verify your receiving field or anything to do with
=
the "DATE INTO". By the way, the documentation, even in release 14,
does =
NOT reflect this change.

Any speculation as to why they didn't just put the century in the first
=
two positions? I've wondered this to myself many times.

Brian Potts

>>> "Irwin, Jim" <jir...@mail.sdc.state.mo.us> 08/06/99 11:33AM >>>
Thanks for the suggestions. Using the online debugger we have narrowed
it to the GET TIME DATE INTO command. I've been looking at the
documentation but I don't see any changes. We have been running under
Cobol for MVS for some time now and the problem just started after our
upgrade to 14.01. Any ideas?=20

------------------------------

Date: Fri, 6 Aug 1999 13:30:20 -0400
From: lpet...@csc.com
To: idm...@iuassn.com
Subject: Re: [IDMS-L]UFF3
Message-ID: <852567C5.0...@cscmail.csc.com>

Why didn't they put the century in the first two positions? Well, it
was
suggested to CA at a IDMS technical group meeting. Also the dates in
the
dictionary seem to have two extra positions for the century(pic x8),
which last
time I heard it discussed was going to be left alone. It seems that
IDMS
development has taken to the idea that if the year is less than 70 it
must be
2000, and higher it must be 1900, since IDMS wasn't marketed before
1970.
That makes it good for another 70 years. I'm with you, I think their
solution
is highly peculiar. What I would like to see is a utility that CA
writes which
will take the dates in the dictionary, take a 01/01/99 and make it a
19990101,
as well as the getdate modification you suggested. It's the only
lasting,
quality solution.

Bdp...@comdisco.com on 08/06/99 01:01:52 PM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Lutz H Petzold/TMG/CSC)
Subject: Re: [IDMS-L]UFF3

Any speculation as to why they didn't just put the century in the first
two
positions? I've wondered this to myself many times.

Brian Potts

------------------------------

Date: Fri, 6 Aug 1999 12:25:41 -0500
From: Michael Newman <Michae...@soph.com>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]UFF3

Message-ID: <014CEBE84B9BD2118FFB0008C74C5E3C292C@GRNSBORO>

Actuallly the date returned is 9(05) comp-3. The contents would be
0yyddd. The 0 represents the 20th century Ie 1900, It will be
incremented in the year 2000 to 1 for the (21st Century). This is
consistent with IBM's macros to return the date. I have seen it
documented, but cannot recall where off hand. Using this nibble to
represent the century, fills up the 3 bytes holding the julian date. It

has been this way for as long as I can remember. (and depending on who
you ask, that can be a long time, or not too long at all :-).

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: Brian Potts [mailto:Bdp...@comdisco.com]
Sent: Friday, August 06, 1999 1:02 PM
To: idm...@iuassn.com

Subject: Re: [IDMS-L]UFF3

I know there has been one change to the GET TIME DATE
INTO....

It has to do with the year 2000.

They modified the DATE INTO. This is off the top of my
head, so you may want to verify the details. I believe the receiving
field for date into was supposed to always be S9(7) PACKED DECIMAL.
This meant your end result looked something like this 00YYDDD, where
the Julian date was the last five position and it was always preceded by

zero zero .

The "new" feature is that starting in the base year
(1998?) you would get 00YYDDD, but in subsequent years the first two
positions would be incremented. Therefore the next year (1999?) would
be '01YYDDD' followed the next year by '02YYDDD'...I think you get the
picture.

So, you may want to verify your receiving field or
anything to do with the "DATE INTO". By the way, the documentation,
even in release 14, does NOT reflect this change.

Any speculation as to why they didn't just put the
century in the first two positions? I've wondered this to myself many
times.

Brian Potts

>>> "Irwin, Jim" <jir...@mail.sdc.state.mo.us> 08/06/99
11:33AM >>>
Thanks for the suggestions. Using the online debugger
we have narrowed
it to the GET TIME DATE INTO command. I've been looking
at the
documentation but I don't see any changes. We have been
running under
Cobol for MVS for some time now and the problem just
started after our
upgrade to 14.01. Any ideas?

------------------------------

Date: Fri, 06 Aug 1999 13:05:04 -0500
From: "Brian Potts" <Bdp...@comdisco.com>

To: <idm...@iuassn.com>
Subject: RE: [IDMS-L]UFF3

Message-ID: <s7aadd...@groupwise.comdisco.com>

Michael,

Of course, you are correct. I mentioned I was a little sketchy on the =

details, however I knew there was a change with the DATE INTO.

Thanks for setting me straight=20

Brian

>>> Michael Newman <Michae...@soph.com> 08/06/99 12:25PM >>>
Actuallly the date returned is 9(05) comp-3. The contents would be
0yyddd. The 0 represents the 20th century Ie 1900, It will be
incremented in the year 2000 to 1 for the (21st Century). This is
consistent with IBM's macros to return the date. I have seen it
documented, but cannot recall where off hand. Using this nibble to
represent the century, fills up the 3 bytes holding the julian date. It

has been this way for as long as I can remember. (and depending on who
you ask, that can be a long time, or not too long at all :-).

Michael A. Newman
Sophisticated Business Systems, Inc.
101 CentrePort Drive, Suite 310
Greensboro, NC 27409
E-Mail: Michae...@soph.com=20
Phone: 336.605.4771 Ext. 116
Fax: 336.605.4772

-----Original Message-----
From: Brian Potts [mailto:Bdp...@comdisco.com]=20
Sent: Friday, August 06, 1999 1:02 PM
To: idm...@iuassn.com=20
Subject: Re: [IDMS-L]UFF3

I know there has been one change to the GET TIME DATE
INTO....

It has to do with the year 2000.

zero zero .

So, you may want to verify your receiving field or
anything to do with the "DATE INTO". By the way, the documentation,
even in release 14, does NOT reflect this change.

Any speculation as to why they didn't just put the
century in the first two positions? I've wondered this to myself many
times.

Brian Potts

>>> "Irwin, Jim" <jir...@mail.sdc.state.mo.us> 08/06/99
11:33AM >>>
Thanks for the suggestions. Using the online debugger
we have narrowed
it to the GET TIME DATE INTO command. I've been looking
at the
documentation but I don't see any changes. We have been
running under
Cobol for MVS for some time now and the problem just
started after our
upgrade to 14.01. Any ideas?=20

------------------------------

Date: Fri, 6 Aug 1999 15:07:29 -0400
From: Robert...@VISITORS.VISITORS.fms.sprint.com
To: IDM...@IUASSN.COM (Non Receipt Notification Requested) (IPM Return
Requested)
Subject: Easytrieve
Message-ID:
<0014nzbvrlhr*/G=Robert/S=Gilmer/OU=VISITORS/O=VISITORS/PRMD=GOV+FMS/ADMD=TELEMAIL/C=US/@MHS>

Does anyone know the syntax for an OBTAIN of a network IDMS record via
an
index using Easytrieve?

------------------------------

Date: Fri, 06 Aug 1999 14:35:40 -0500
From: "Brian Potts" <Bdp...@comdisco.com>
To: <idm...@iuassn.com>
Subject: Re: [IDMS-L]Easytrieve
Message-ID: <s7aaf2...@groupwise.comdisco.com>

Robert,

I assume you're not using "automatic retrieval". If this is correct, =
here's the syntax

IDMS OBTAIN RECORD 'record-name' SET 'index name' +
USING your-index-key

Hope this helps

Brian

>>> <Robert...@VISITORS.VISITORS.fms.sprint.com> 08/06/99 02:07PM
>>>
Does anyone know the syntax for an OBTAIN of a network IDMS record via =

an=20
index using Easytrieve?

------------------------------

Date: Fri, 6 Aug 1999 17:38:40 EDT
From: ARCH...@aol.com
To: idm...@iuassn.com
Subject: SQL Sample batch cobol and Compile JCL
Message-ID: <fa5ed92b...@aol.com>

Hello Everyone:

Does anyone have a small sample batch COBOL program with embedded SQL?

I would also like to see the Compile JCL stream, especially dealing with
the
Access Module and RCM piece.

If you can help please send it as an attached text file and please send
it
directly to me and not the list. Thank You in Advance for your help.

------------------------------

End of IDMS-L V1 #48
********************

Chris Hoelscher

unread,

Aug 13, 1999, 3:00:00 AM8/13/99

To: <IDM...@iuassn.com>
Subject: IDMS-L V1 #49

IDMS-L Sun, 8 Aug 1999 Volume 1 :
Number 49

In this issue:

Re: [IDMS-L]Optimizer?

----------------------------------------------------------------------

Date: Sat, 7 Aug 1999 15:19:19 -0300
From: "geraldo.martins" <geraldo...@originet.com.br>
To: <idm...@iuassn.com>
Subject: Re: [IDMS-L]Optimizer?
Message-ID: <0c7f01bee11d$a050bea0$d6dbf6c8@martger>

First why don't you set ele-rec1 as index field.?
Cris I think the calc set of Rec1 is the worst choice, left
it
organise by Owned index, first sort record to add by sorted key, finally

unload/reload this area whitout any modifications, only to put group of
key
close, in the same block.
PS. The large block you have, best i/o will be.

----- Original Message -----
From: IESD <in1...@juliusbaer.com>
To: <IDM...@iuassn.com>
Sent: Tuesday, August 03, 1999 12:52 PM
Subject: [IDMS-L]Optimizer?

Has anyone gained any meaningful insights into the workings of the SQL

optimizer? Specifically with reference to accessing Network databases. I
got
the following..

same.

If I do ..

SELECT
ELE-REC1, ELE-REC2
FROM
REC1, REC2
WHERE

ELE-REC1 = 'X'
AND
"REC1-REC2"
;

Where ELE-REC1 does not exist in any CALC or Sort Key. You would expect
a

programmer and the optimizer to

1. Area sweep AREA1.
2. For every REC1 which has ELE-REC1 = 'X' to walk REC1-REC2.

This would give between 10K and 30K I/Os depending on the frequency of

'X'
and assuming no overflow..

But the optimiser doesn't do that. It does..

1.Read the REC2-Index.
2.Obtain owner for every REC2 in REC1-REC2.
3.See if REC1 has a value of 'X' in ELE-REC1.

This gives a mininum of 30K I/Os and in practice many more!

If I add OPTIMIZE for 500000 rows to the Select statement then it
chooses

the obvious route.

In reality the answer is around 30 rows.

I realise as a consultant that I should know the answer already so don't

waste my valuable time with silly talk.

Thanks

Chris Trayler

Bank Julius Baer
Database Administration
8001 Zuerich
Switzerland
Tel +41 1 4374608
Fax +41 1 4374475
http:\\www.juliusbaer.com
databas...@juliusbaer.com

------------------------------

End of IDMS-L V1 #49
********************

Chris Hoelscher

unread,

Aug 13, 1999, 3:00:00 AM8/13/99

To: <IDM...@iuassn.com>
Subject: IDMS-L V1 #50

IDMS-L Mon, 9 Aug 1999 Volume 1 :
Number 50

In this issue:

UNSUBSCRIBE
Multitasking vs Front-end/Back-end vs Sysplex

----------------------------------------------------------------------

Date: Mon, 9 Aug 1999 07:25:48 +0100
From: Beat....@BERN.CH
To: idm...@iuassn.com
Subject: UNSUBSCRIBE
Message-ID: <89F8812536C5D011AF180001FA370149F16339@EXCHG11>

Hello to all in the group:

UNSUBSCRIBE

Too much talk on this list my mail box is filled.

Abteilung Informatikdienste der Stadt Bern
Beat Oesch, Sektion Systemtechnik und Datenbanken Telefon: 321 74 23,
FAX: 321 77 20
e-mail: Beat....@Bern.CH <mailto:Beat....@BERN.CH>

------------------------------

Date: Sun, 8 Aug 1999 23:37:50 -0500
From: "Mowbray, Sam A" <sam.m...@eds.com>
To: "'IDM...@IUASSN.COM'" <IDM...@IUASSN.COM>
Subject: Multitasking vs Front-end/Back-end vs Sysplex
Message-ID: <FB42153F3C41D111A12500805F0D726E02173EB4@AUADM101>

Hi Listers,
We are considering the options of multi processing, particularly in
relation
to CPU performance.

Options we are looking at are :
1. Multitasking
2. Front-end/Back-end CV processing with the DB calls (and half the DC
calls) being done by the Front-end. The rest of the DC being on the
Back-end CV
3. Sysplex

I have queried CA and they suggest that in terms of Best CPU overhead
performance the order is Multitasking then FE/BE CVs then Sysplex.
Unfortunately they don't have any hard figures they can give me.
Therefore
has anyone done benchmarking in this area?

Many thanks
Sam Mowbray
Database Administrator
Asia-Pacific Technology
& Engineering Solution Centre, Adelaide

EDS Australia
Level 8, 108 North Tce,
ADELAIDE, South Australia 5000
email : sam.m...@eds.com
phone : +61 8 8464 1503
fax : +61 8 8464 2135

------------------------------

End of IDMS-L V1 #50
********************

Chris Hoelscher

unread,

Aug 13, 1999, 3:00:00 AM8/13/99

To: <IDM...@iuassn.com>
Subject: IDMS-L V1 #52

IDMS-L Wed, 11 Aug 1999 Volume 1 :
Number 52

In this issue:

DML Verb numbers
Re: [IDMS-L]DML Verb numbers
RE: [IDMS-L]DML Verb numbers
Fw: [IDMS-L]Multitasking vs Front-end/Back-end vs Sysplex
Re: [IDMS-L]DML Verb numbers
Re: [IDMS-L]S0C4 at Startup 12.01, 9707 Maintenance
RE: [IDMS-L]DML Verb numbers
Idms jounal block size?????
Assembler Options
RE: [IDMS-L]Multitasking vs Front-end/Back-end vs Sysplex
RE: [IDMS-L]S0C4 at Startup 12.01, 9707 Maintenance
RE: [IDMS-L]Assembler Options
RE: [IDMS-L]Idms jounal block size?????
RE: [IDMS-L]Idms jounal block size?????
RE: [IDMS-L]S0C4 at Startup 12.01, 9707 Maintenance
RE: [IDMS-L]Idms jounal block size?????
Re: [IDMS-L]Idms jounal block size?????
RE: [IDMS-L]Assembler Options
RE: [IDMS-L]DML Verb numbers

----------------------------------------------------------------------

Date: Tue, 10 Aug 1999 08:44:21 -0500
From: "Rice, James L. Jim" <JLR...@southernco.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: DML Verb numbers
Message-ID:
<F3E06C56DE75D211B3A...@gaxgpex23.southernco.com>

I know that I should know this, but I can't remember what manual has a
listing of all the DML verb codes. Can someone help this old brain?

Thanks.

Jim

Jim Rice
jlr...@southernco.com
ph (404) 506-4148
Fax (404) 506- 4870

------------------------------

Date: Tue, 10 Aug 1999 09:53:27 -0400
From: Alan_...@vfc.com
To: idm...@iuassn.com
Subject: Re: [IDMS-L]DML Verb numbers
Message-ID: <852567C9.0...@itxf2aln09.vfc.com>

Get the brain some exercise and check out the programming quick
reference. It's
got the full documentation of all the DML call formats.

Alan Fields
VF Jeanswear
Greensboro, NC
(336) 332-5631
Alan_...@vfc.com

"Rice, James L. Jim" <JLR...@southernco.com> on 08/10/99 09:44:21 AM

Please respond to idm...@iuassn.com

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
cc: (bcc: Alan Fields/Jeanswear/VF Corporation)
Subject: [IDMS-L]DML Verb numbers

I know that I should know this, but I can't remember what manual has a
listing of all the DML verb codes. Can someone help this old brain?

Thanks.

Jim

Jim Rice
jlr...@southernco.com
ph (404) 506-4148
Fax (404) 506- 4870

------------------------------

Date: Tue, 10 Aug 1999 10:02:44 -0400
From: "Locke, Don" <Loc...@simplexnet.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]DML Verb numbers
Message-ID: <C384780A25ECD211994B0060B0675B3F0E9A93@STR_MAIL3>

CA-IDMS(R)/DB

Programming Quick Reference
Release 14.0
RC05/&F0PQE

1.6.1 CA-IDMS/DB call formats
1.6.2 CA-IDMS/DC call formats

Have a Good day,

Don Locke
Simplex Time Recorder Co.
Phone: (978) 874-8678
Email: loc...@simplexnet.com

> ----------
> From: Rice, James L. Jim[SMTP:JLR...@southernco.com]
> Reply To: idm...@iuassn.com
> Sent: Tuesday, August 10, 1999 9:44 AM
> To: 'idm...@iuassn.com'
> Subject: [IDMS-L]DML Verb numbers
>
> I know that I should know this, but I can't remember what manual has a

> listing of all the DML verb codes. Can someone help this old brain?
>
> Thanks.
>
>
> Jim
>
>
> Jim Rice
> jlr...@southernco.com
> ph (404) 506-4148
> Fax (404) 506- 4870
>
>

------------------------------

Date: Tue, 10 Aug 1999 14:57:53 +0100
From: "Gary Bronziet" <gary.b...@cogito.co.uk>
To: "IDMS-L Users" <idm...@iuassn.com>
Subject: Fw: [IDMS-L]Multitasking vs Front-end/Back-end vs Sysplex
Message-ID: <00d701bee338$93638840$a5e72ac2@gary>

This is a multi-part message in MIME format.

------=_NextPart_000_00CE_01BEE340.B9362CA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A most interesting question. Over the years we have had a lot of =
experience in resolving problems of performance and CPU constraint =
through the implementation of multi-CV configurations. We gave a session
=
at an IDMS user week some years ago (San Diego I think). In brief....

1. DC/UCF multiple back-ends. This site dates back to 10.2 days, when =
multi-tasking was definitely a no-go area. The site was severely CPU =
constrained. The machine was a three engine IBM 3090. CV was driving one
=
engine at 100%, while there was plenty of unused MIPS available on other
=
engines. Solution was to split workload over three CVs with a front-end
=
CV. The front-end CV was just a transaction shipper using UCFDBDC. We =
wrote a simple ROUTER that shipped transactions based upon task code. =
Read-only transactions could run on any back-end. Performance thereafter
=
was phenomenal. Overall CPU utilization across machine dropped to about
=
40% (processing over 500,000 transactions in online day).
2. CICS->CV back-ends (with read only CVs). Another major site for many
=
years has used this implementation to solve the problem of a constrained
=
single CV. The applications execute in the CICS region. Some IDMSINTC =
logic decides which CV to use for the DB processing. This too is a good
=
solution, but note that there is an overhead in communication between =
the regions. The interface uses a "post-wait" mechanism and each DML =
requires no less than 4 SVC calls! In a different life (while working =
for Cullinet) I developed a PTF known as SUPABIND which reduced this =
overhead by avoiding the SVC communicating for BINDS RECORD requests. =
This became part of release 12.0, so overhead is reduced - but ERUS DML
=
is still more costly. Another "trick" was to convert some of the CICS =
code to execute under DC, and "ship" the transaction (so the DML is =
executed internally).
3. Release 12.0 also introduced the possibility of CV front-end backend
=
set-up like CICS-IDMS. That is, you can execute DC/UCF programs on a =
front-end CV and execute DB calls on a back-end CV(s). However, this =
set-up also incurs the communication overhead as described in 2 above. =

We know of some sites that have tried this set-up and found the overhead
=
too costly.
4. Multi-tasking in release 14.0 has been improved to permit multiple =
DBMODE threads. This is a major improvement as MT was not much benefit =

to sites executing ERUS requests only (for example, CICS-IDMS). One of =

our major sites (CICS-IDMS with update and read-only back-end CVS) has =

performed some bench-marks to compare the cost/benefit of switching on =

MT support (in the read-only CV) against the addition of a second =
read-only CV. Their conclusion is that a second read-only CV is more =
effective. (less CPU for same increase in workload).
5. Sysplex and other issues. Dynamic Routing - uses list structures in
=
the coupling facility to dynamically route run-units to the available =
CVs in the Sysplex. It will be up to the user to implement a pre-bind =
exit which identifies the particular CV or the group of CVs that can =
handle a particular request. Once the target CV is determined, the =
standard DDS mechanism is used to ship the DML requests from the client
=
to the back-end server CV that will process the run-unit. A typical =
implementation might have a front-end TOR (terminal handling) CV =
shipping all DML requests to appropriate back-ends. However, the design
=
would not preclude other approaches. For instance, all CVs could have =
terminal connections. The users may sign on to the update CV with =
retrieval run-units routed elsewhere or vice versa. Apart from the use =

of the coupling facility for work-load balancing, this again is no =
different to what may be achieved using existing facilities, i.e., DDS =

and or UCF function shipping Indeed, one of my major reservations about
=
the Sysplex run-unit routing mechanism is that is ships DML rather than
=
transactions. As a comparison, in the CICS/DB2 world, CICSPlex is =
responsible for balancing the work-load around the available CICS =
services in the SYSPLEX at a transaction level. The chosen CICS system =

communicates with its associated DB2 on the same MVS via cross-memory =
services. This is made simpler to implement in the DB2 world as DB2 =
already supports datasharing. Release 15.0 datasharing will introduce =
new opportunities and flexibility.
6. With some imagination, and a little effort, it is possible to put =
together IDMS configurations that will sustain a work-load you would not
=
have thought possible (and for a fraction of the hard-ware cost of other
=
well known database management systems!). As you can tell from above, we
=
are convinced that multiple CVs is the way to go giving better CPU =
utilization than multi-tasking even under release 14.0. Multiple CVs can
=
be implemented on same or different MVS systems using standard IDMS =
functionality (UCFDBDC, DDS etc) even in non-sysplex environments.=20
7. Don't expect all this without a product plug! DB-Synchro can be used
=
in all above environments to maintain buffer coherency between multiple
=
CVs on same or different MVS systems (even in non-sysplex environments).
=
There is also a white paper available (to those who ask) comparing =
DB-Synchro functionality with IDMS sysplex support.=20

Hope you found some of this useful and interesting.

Gary Bronziet
Cogito
email: gary.b...@cogito.co.uk
URL: www.cogito.co.uk

=20
=20
=20
=20
=20
=20
=20
----- Original Message -----=20

From: Mowbray, Sam A <sam.m...@eds.com>

To: 'IDM...@IUASSN.COM' <IDM...@iuassn.com>
Sent: 09 August 1999 05:37
Subject: [IDMS-L]Multitasking vs Front-end/Back-end vs Sysplex=20

> Hi Listers,
> We are considering the options of multi processing, particularly in =
relation
> to CPU performance.
>=20

> Options we are looking at are :
> 1. Multitasking
> 2. Front-end/Back-end CV processing with the DB calls (and half the DC

> calls) being done by the Front-end. The rest of the DC being on the
> Back-end CV

> 3. Sysplex=20
>=20

> I have queried CA and they suggest that in terms of Best CPU overhead
> performance the order is Multitasking then FE/BE CVs then Sysplex.

> Unfortunately they don't have any hard figures they can give me. =

Therefore
> has anyone done benchmarking in this area?

>=20

> Many thanks
> Sam Mowbray
> Database Administrator

> Asia-Pacific Technology=20

> & Engineering Solution Centre, Adelaide
> EDS Australia
> Level 8, 108 North Tce,
> ADELAIDE, South Australia 5000
> email : sam.m...@eds.com

> phone : +61 8 8464 1503 =20

> fax : +61 8 8464 2135

> =20
> =20
>=20

------=_NextPart_000_00CE_01BEE340.B9362CA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
A most interesting question. Over the years we have had a lot of =
experience=20 in resolving problems of performance and CPU constraint
through the=20 implementation of multi-CV configurations. We gave a
session at an IDMS = user=20 week some years ago (San Diego I think). In
brief....

1. DC/UCF multiple back-ends. This site dates back = to 10.2=20 days,
when multi-tasking was definitely a no-go area. The site was = severely
CPU=20 constrained. The machine was a three engine IBM 3090. CV was
driving one = engine=20 at 100%, while there was plenty of unused MIPS
available on other = engines.=20 Solution was to split workload over
three CVs with a front-end CV. The = front-end=20 CV was just a
transaction shipper using UCFDBDC. We wrote a simple = ROUTER that=20
shipped transactions based upon task code. Read-only transactions could
= run on=20 any back-end. Performance thereafter was phenomenal. Overall
CPU = utilization=20 across machine dropped to about 40% (processing
over 500,000 = transactions in=20 online day).
2. CICS->CV back-ends (with read only CVs). = Another=20 major site for
many years has used this implementation to solve the = problem of a=20
constrained single CV. The applications execute in the CICS region. Some
= IDMSINTC logic decides which CV to use for the DB processing. This too
= is a good=20 solution, but note that there is an overhead in
communication between = the=20 regions. The interface uses a "post-wait"
mechanism and each DML = requires no=20 less than 4 SVC calls! In a
different life (while working for Cullinet) = I=20 developed a PTF known
as SUPABIND which reduced this overhead by = avoiding the=20 SVC
communicating for BINDS RECORD requests. This became part of release =
12.0,=20 so overhead is reduced - but ERUS DML is still more costly.
Another = "trick" was=20 to convert some of the CICS code to execute
under DC, and "ship" the = transaction=20 (so the DML is executed
internally).
3. Release 12.0 also introduced the possibility of = CV=20 front-end
backend set-up like CICS-IDMS. That is, you can execute DC/UCF =
programs on a front-end CV and execute DB calls on a back-end CV(s). =
However,=20 this set-up also incurs the communication overhead as
described in 2 = above. We=20 know of some sites that have tried this
set-up and found the overhead = too=20 costly.
4. Multi-tasking in release 14.0 has been improved = to=20 permit
multiple DBMODE threads. This is a major improvement as MT = was not=20
much benefit to sites executing ERUS requests only (for example, =
CICS-IDMS). One=20 of our major sites (CICS-IDMS with update and
read-only back-end CVS) = has=20 performed some bench-marks to compare
the cost/benefit of switching on = MT=20 support (in the read-only CV)
against the addition of a second read-only = CV.=20 Their conclusion is
that a second read-only CV is more=20 effective. (less CPU for same
increase in = workload).
5. Sysplex and other issues. = Dynamic=20 Routing - uses list
structures in the coupling facility to = dynamically=20 route run-units
to the available CVs in the Sysplex. It will be up to = the user=20 to
implement a pre-bind exit which identifies the particular CV or the =
group of=20 CVs that can handle a particular request. Once the target CV
is = determined, the=20 standard DDS mechanism is used to ship the DML
requests from the client = to the=20 back-end server CV that will
process the run-unit. A typical = implementation=20 might have a
front-end TOR (terminal handling) CV shipping all DML = requests to=20
appropriate back-ends. However, the design would not preclude other =
approaches.=20 For instance, all CVs could have terminal connections.
The users may = sign on to=20 the update CV with retrieval run-units
routed elsewhere or vice versa. = Apart=20 from the use of the coupling
facility for work-load balancing, this = again is no=20 different to
what may be achieved using existing facilities, i.e., DDS = and or=20
UCF function shipping = Indeed, one=20 of my major reservations about
the Sysplex run-unit routing = mechanism is=20 that is ships DML rather
than transactions. As = a=20 comparison, in the CICS/DB2 world, CICSPlex
is responsible for balancing = the=20 work-load around the available
CICS services in the SYSPLEX at a = transaction=20 level. The chosen
CICS system communicates with its associated DB2 on = the=20 same MVS
via cross-memory services. This is made simpler to = implement in the=20
DB2 world as DB2 already supports datasharing.
With some imagination, and a little effort, it is possible to = put=20
together IDMS configurations that will sustain a work-load you would not
= have=20 thought possible (and for a fraction of the hard-ware cost of
other well = known=20 database management systems!). As you can tell
from above, we are = convinced that=20 multiple CVs is the way to go
giving better CPU utilization than = multi-tasking=20 even under release
14.0. Multiple CVs can be implemented on same or = different=20 MVS
systems using standard IDMS functionality (UCFDBDC, DDS etc) even in =
non-sysplex environments.
Don't expect all this without a product plug! DB-Synchro can be = used
in=20 all above environments to maintain buffer coherency between
multiple CVs = on same=20 or different MVS systems (even in non-sysplex
environments). There is = also a=20 white paper available (to those who
ask) comparing DB-Synchro = functionality with=20 IDMS sysplex support.

Hope you found some of this useful and interesting.

gary.b...@cogito.co.uk=
www.cogito.co.uk
----- Original Message -----=20

From: Mowbray, Sam A <sam.m...@eds.com>

To: 'IDM...@IUASSN.COM' = <IDM...@iuassn.com>
Sent: 09 August 1999 05:37
Subject: [IDMS-L]Multitasking vs Front-end/Back-end vs Sysplex =

> Hi Listers,
> We are considering the options = of multi=20 processing, particularly

in relation
> to CPU performance.

> =

> Options we are looking at are :
> 1. Multitasking

> = 2.=20 Front-end/Back-end CV processing with the DB calls (and half
the = DC
>=20 calls) being done by the Front-end. The rest of the DC being on=20

the
> Back-end CV
> 3. Sysplex
>

> I have = queried CA=20 and they suggest that in terms of Best CPU
overhead
> performance = the=20 order is Multitasking then FE/BE CVs then
Sysplex.
> Unfortunately = they=20 don't have any hard figures they can give me.
Therefore
> = has anyone=20 done benchmarking in this area?
>
> Many thanks
> Sam = Mowbray
> Database Administrator
> Asia-Pacific Technology =
>=20 & Engineering Solution Centre, Adelaide
> EDS=20 Australia

> Level 8, 108 North Tce,

> ADELAIDE, South = Australia=20 5000
> email : sam.m...@eds.com
> = phone : +61=20 8 8464 1503
> fax = : +61=20 8 8464 2135
>
>
> ------=_NextPart_000_00CE_01BEE340.B9362CA0--
------------------------------ Date: Tue, 10 Aug 1999 08:58:09 -0500
From: rpi...@mge.com To: idm...@iuassn.com Subject: Re: [IDMS-L]DML
Verb numbers Message-ID: <99Aug10.085...@dns.MGE.COM> Call
formats are in the db/dc quick reference manual. 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
***************************************************************************
***** ------------------------------ Date: Tue, 10 Aug 1999 10:17:47
-0400 From: Roger Lawrence To: idm...@iuassn.com Subject: Re:
[IDMS-L]S0C4 at Startup 12.01, 9707 Maintenance Message-ID:
<37B0348B...@seminole-electric.com> Harold, Chris, Yes, following
the instructions for 9707, I relinked my SVC; copied GJC0INIT, RHDCSSFM,
and my SVC to the authorized library used by CAIRIM; relinked my startup
module; regenerated RHDCSRTT with the SVCNUM parm; ran CAIRIM (with CV
shut down); then started up CV. That's when I get the S0C4. The
instructions also say to copy CAS9SEC; but, I can only find it in the
authorized library used by CAIRIM, so I didn't copy it (from where?).
Thanks for your ideas. Roger Lawrence "Govan Jr, Harold M." wrote: >
Roger, did you reassemble and link your IDMS startup module with the new
> maintenance ? > > You might also need to reassemble and link your
SRTT. > > > -----Original Message----- > > From: Roger Lawrence
[SMTP:rlaw...@seminole-electric.com] > > Sent: Monday, August 09, 1999
5:47 PM > > To: idm...@iuassn.com > > Subject: [IDMS-L]S0C4 at Startup
12.01, 9707 Maintenance > > > > Hey Y'all, > > > > I've just applied
9707 maintenance, set up a new SVC and installed it > > using CAIRIM.
Upon starting the CV, I get s0c4, reason code 10 just > > after +IDMS
DC390008 V80 STORAGE RETURNED TO OPSYS... 3,212K > > message. Have any
of you experienced this when applying the 9707 > > maintenance tape? I
can't find anything like it in TCC. Thanks for any > > and all help. > >
> > Roger Lawrence, DBA > > Seminole Electric Cooperative > >
------------------------------ Date: Tue, 10 Aug 1999 09:04:24 -0500
From: "Lorenzen, David C" To: "'idm...@iuassn.com'" Subject: RE:
[IDMS-L]DML Verb numbers Message-ID: James, The best source is the Quick
Reference to CA-IDMS/DB & DC programming guide. David Lorenzen EDS >
---------- > From: Rice, James L. Jim > Sent: Tuesday, August 10, 1999
8:44 AM > To: 'idm...@iuassn.com' > Subject: [IDMS-L]DML Verb numbers >
> I know that I should know this, but I can't remember what manual has a
> listing of all the DML verb codes. Can someone help this old brain? >
> Thanks. > > > Jim > > > Jim Rice > jlr...@southernco.com > ph (404)
506-4148 > Fax (404) 506- 4870 > > ------------------------------ Date:
Tue, 10 Aug 1999 08:33:26 +0000 From: Javier Sotela M To:
IDM...@IUASSN.COM Subject: Idms jounal block size????? Message-ID:
<37AFE3...@ns.ice.go.cr> I repeat my question, because there is not
anwer for my first one. Does anybody can help me with this question? We
have four journals with file size 64000 blocks and we are disussing
about the trade-off betwen more journals or more blocks for journals. We
are trying to duplicate the number of blocks but i'm not sure if there
is a good idea. Any comments or suggestions will be great. We are
running on VSE/ESA with idms rel 14 Javier Sotela
------------------------------ Date: Tue, 10 Aug 1999 09:18:53 -0500
From: "Lorenzen, David C" To: "'idm...@iuassn.com'" Subject: Assembler
Options Message-ID: During our recent upgrade to OS/390, and migrating
our recent R14 maintenance tape, we noticed something that I would like
further explanation. In restoring a few of our DBA usermods, we received
an error that the Version one of the program should be converted. It was
using an option called HOBSET (high order bit setting). We currently
ignored the warning and pressed on. I do not like warnings, and cannot
find this option. Our manuals are a little outdated. Any assembler gurus
able to shed some light on this? Should I be concerned, and if so, what
to do about it? Thanks David Lorenzen EDS ------------------------------
Date: Tue, 10 Aug 1999 15:45:02 +0100 From: "Jon Gray" To: "'Gary
Bronziet'" , Subject: RE: [IDMS-L]Multitasking vs Front-end/Back-end vs
Sysplex Message-ID: This is a multi-part message in MIME format.
------=_NextPart_000_0007_01BEE347.A0D8D2A0 Content-Type: text/plain;
charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, They should
appreciate all this. There is a change in point size at the end but I
guess that doesn't matter much. Jon -----Original Message----- From:
CA-IDMS Discussion [mailto:IDM...@iuassn.com]On Behalf Of Gary Bronziet
Sent: 10 August 1999 14:58 To: IDMS-L Users Subject: Fw:
[IDMS-L]Multitasking vs Front-end/Back-end vs Sysplex A most interesting
question. Over the years we have had a lot of experience in resolving
problems of performance and CPU constraint through the implementation of
multi-CV configurations. We gave a session at an IDMS user week some
years ago (San Diego I think). In brief.... 1. DC/UCF multiple
back-ends. This site dates back to 10.2 days, when multi-tasking was
definitely a no-go area. The site was severely CPU constrained. The
machine was a three engine IBM 3090. CV was driving one engine at 100%,
while there was plenty of unused MIPS available on other engines.
Solution was to split workload over three CVs with a front-end CV. The
front-end CV was just a transaction shipper using UCFDBDC. We wrote a
simple ROUTER that shipped transactions based upon task code. Read-only
transactions could run on any back-end. Performance thereafter was
phenomenal. Overall CPU utilization across machine dropped to about 40%
(processing over 500,000 transactions in online day). 2. CICS->CV
back-ends (with read only CVs). Another major site for many years has
used this implementation to solve the problem of a constrained single
CV. The applications execute in the CICS region. Some IDMSINTC logic
decides which CV to use for the DB processing. This too is a good
solution, but note that there is an overhead in communication between
the regions. The interface uses a "post-wait" mechanism and each DML
requires no less than 4 SVC calls! In a different life (while working
for Cullinet) I developed a PTF known as SUPABIND which reduced this
overhead by avoiding the SVC communicating for BINDS RECORD requests.
This became part of release 12.0, so overhead is reduced - but ERUS DML
is still more costly. Another "trick" was to convert some of the CICS
code to execute under DC, and "ship" the transaction (so the DML is
executed internally). 3. Release 12.0 also introduced the possibility of
CV front-end backend set-up like CICS-IDMS. That is, you can execute
DC/UCF programs on a front-end CV and execute DB calls on a back-end
CV(s). However, this set-up also incurs the communication overhead as
described in 2 above. We know of some sites that have tried this set-up
and found the overhead too costly. 4. Multi-tasking in release 14.0 has
been improved to permit multiple DBMODE threads. This is a major
improvement as MT was not much benefit to sites executing ERUS requests
only (for example, CICS-IDMS). One of our major sites (CICS-IDMS with
update and read-only back-end CVS) has performed some bench-marks to
compare the cost/benefit of switching on MT support (in the read-only
CV) against the addition of a second read-only CV. Their conclusion is
that a second read-only CV is more effective. (less CPU for same
increase in workload). 5. Sysplex and other issues. Dynamic Routing -
uses list structures in the coupling facility to dynamically route
run-units to the available CVs in the Sysplex. It will be up to the user
to implement a pre-bind exit which identifies the particular CV or the
group of CVs that can handle a particular request. Once the target CV is
determined, the standard DDS mechanism is used to ship the DML requests
from the client to the back-end server CV that will process the
run-unit. A typical implementation might have a front-end TOR (terminal
handling) CV shipping all DML requests to appropriate back-ends.
However, the design would not preclude other approaches. For instance,
all CVs could have terminal connections. The users may sign on to the
update CV with retrieval run-units routed elsewhere or vice versa. Apart
from the use of the coupling facility for work-load balancing, this
again is no different to what may be achieved using existing facilities,
i.e., DDS and or UCF function shipping Indeed, one of my major
reservations about the Sysplex run-unit routing mechanism is that is
ships DML rather than transactions. As a comparison, in the CICS/DB2
world, CICSPlex is responsible for balancing the work-load around the
available CICS services in the SYSPLEX at a transaction level. The
chosen CICS system communicates with its associated DB2 on the same MVS
via cross-memory services. This is made simpler to implement in the DB2
world as DB2 already supports datasharing. Release 15.0 datasharing will
introduce new opportunities and flexibility. 6. With some imagination,
and a little effort, it is possible to put together IDMS configurations
that will sustain a work-load you would not have thought possible (and
for a fraction of the hard-ware cost of other well known database
management systems!). As you can tell from above, we are convinced that
multiple CVs is the way to go giving better CPU utilization than
multi-tasking even under release 14.0. Multiple CVs can be implemented
on same or different MVS systems using standard IDMS functionality
(UCFDBDC, DDS etc) even in non-sysplex environments. 7. Don't expect all
this without a product plug! DB-Synchro can be used in all above
environments to maintain buffer coherency between multiple CVs on same
or different MVS systems (even in non-sysplex environments). There is
also a white paper available (to those who ask) comparing DB-Synchro
functionality with IDMS sysplex support. Hope you found some of this
useful and interesting. Gary Bronziet Cogito email:
gary.b...@cogito.co.uk URL: www.cogito.co.uk ----- Original Message
----- From: Mowbray, Sam A < sam.m...@eds.com> To:
'IDM...@IUASSN.COM' < IDM...@iuassn.com> Sent: 09 August 1999 05:37
Subject: [IDMS-L]Multitasking vs Front-end/Back-end vs Sysplex > Hi

Listers, > We are considering the options of multi processing,
particularly in relation > to CPU performance. > > Options we are
looking at are : > 1. Multitasking > 2. Front-end/Back-end CV processing
with the DB calls (and half the DC > calls) being done by the Front-end.
The rest of the DC being on the > Back-end CV > 3. Sysplex > > I have
queried CA and they suggest that in terms of Best CPU overhead >
performance the order is Multitasking then FE/BE CVs then Sysplex. >
Unfortunately they don't have any hard figures they can give me.
Therefore > has anyone done benchmarking in this area? > > Many thanks >
Sam Mowbray > Database Administrator > Asia-Pacific Technology > &
Engineering Solution Centre, Adelaide > EDS Australia > Level 8, 108
North Tce, > ADELAIDE, South Australia 5000 > email :
sam.m...@eds.com > phone : +61 8 8464 1503 > fax : +61 8 8464 2135 >

> > ------=_NextPart_000_0007_01BEE347.A0D8D2A0 Content-Type: text/html;
charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
They=20 should appreciate all this. There is a change in point size at
the end = but I=20 guess that doesn't matter much.
Jon
-----Original Message-----
From: CA-IDMS Discussion = [mailto:IDM...@iuassn.com]On Behalf Of Gary =
Bronziet
Sent: 10=20 August 1999 14:58
To: IDMS-L Users
Subject: Fw:=20 [IDMS-L]Multitasking vs Front-end/Back-end vs Sysplex =

A most interesting question. Over the years we have had a lot of=20
experience in resolving problems of performance and CPU constraint =
through the=20 implementation of multi-CV configurations. We gave a
session at an = IDMS user=20 week some years ago (San Diego I think). In
brief....

1. DC/UCF multiple back-ends. This site dates = back to=20 10.2 days,
when multi-tasking was definitely a no-go area. The site = was=20
severely CPU constrained. The machine was a three engine IBM 3090. CV =
was=20 driving one engine at 100%, while there was plenty of unused MIPS
= available on=20 other engines. Solution was to split workload over
three CVs with a = front-end=20 CV. The front-end CV was just a
transaction shipper using UCFDBDC. We = wrote a=20 simple ROUTER that
shipped transactions based upon task code. = Read-only=20 transactions
could run on any back-end. Performance thereafter was = phenomenal.=20
Overall CPU utilization across machine dropped to about 40% =
(processing over=20 500,000 transactions in online day).
2. CICS->CV back-ends (with read only CVs). = Another=20 major site for
many years has used this implementation to solve the problem of a=20
constrained single CV. The applications execute in the CICS region. =
Some=20 IDMSINTC logic decides which CV to use for the DB processing.
This too = is a=20 good solution, but note that there is an overhead in
communication = between the=20 regions. The interface uses a "post-wait"
mechanism and each DML = requires no=20 less than 4 SVC calls! In a
different life (while working for = Cullinet) I=20 developed a PTF known
as SUPABIND which reduced this overhead by = avoiding the=20 SVC
communicating for BINDS RECORD requests. This became part of = release
12.0,=20 so overhead is reduced - but ERUS DML is still more costly.
Another = "trick"=20 was to convert some of the CICS code to execute
under DC, and "ship" = the=20 transaction (so the DML is executed
internally).
3. Release 12.0 also introduced the possibility = of CV=20 front-end
backend set-up like CICS-IDMS. That is, you can execute = DC/UCF=20
programs on a front-end CV and execute DB calls on a back-end CV(s). =
However,=20 this set-up also incurs the communication overhead as
described in 2 = above. We=20 know of some sites that have tried this
set-up and found the overhead = too=20 costly.
4. Multi-tasking in release 14.0 has been = improved to=20 permit
multiple DBMODE threads. This is a major improvement as MT = was not=20
much benefit to sites executing ERUS requests only (for example, =
CICS-IDMS).=20 One of our major sites (CICS-IDMS with update and
read-only back-end = CVS) has=20 performed some bench-marks to compare
the cost/benefit of switching on = MT=20 support (in the read-only CV)
against the addition of a second = read-only CV.=20 Their conclusion is
that a second read-only CV is more=20 effective. (less CPU for same
increase in = workload).
5. Sysplex and other issues. = Dynamic=20 Routing - uses list
structures in the coupling facility to = dynamically=20 route run-units
to the available CVs in the Sysplex. It will be up to = the user=20 to
implement a pre-bind exit which identifies the particular CV or the =
group=20 of CVs that can handle a particular request. Once the target CV
is = determined,=20 the standard DDS mechanism is used to ship the DML
requests from the = client to=20 the back-end server CV that will
process the run-unit. A typical=20 implementation might have a front-end
TOR (terminal handling) CV = shipping all=20 DML requests to appropriate
back-ends. However, the design would not = preclude=20 other approaches.
For instance, all CVs could have terminal = connections. The=20 users
may sign on to the update CV with retrieval run-units routed =
elsewhere=20 or vice versa. Apart from the use of the coupling facility
for = work-load=20 balancing, this again is no different to what may be
achieved using = existing=20 facilities, i.e., DDS and or UCF function
shipping Indeed, one of my major = reservations=20 about the Sysplex
run-unit routing mechanism is that is ships DML = rather=20 than
transactions. on the=20 same MVS via cross-memory services. This is made
simpler to = implement in=20 the DB2 world as DB2 already supports
datasharing.
With some imagination, and a little effort, it is possible to = put=20
together IDMS configurations that will sustain a work-load you would =
not have=20 thought possible (and for a fraction of the hard-ware cost
of other = well known=20 database management systems!). As you can tell
from above, we are = convinced=20 that multiple CVs is the way to go
giving better CPU utilization than=20 multi-tasking even under release
14.0. Multiple CVs can be implemented = on same=20 or different MVS
systems using standard IDMS functionality (UCFDBDC, = DDS etc)=20 even
in non-sysplex environments.
Don't expect all this without a product plug! DB-Synchro can = be
used=20 in all above environments to maintain buffer coherency between =
multiple CVs on=20 same or different MVS systems (even in non-sysplex
environments). = There is=20 also a white paper available (to those who
ask) comparing DB-Synchro=20 functionality with IDMS sysplex support.

Hope you found some of this useful and interesting.

gary.b...@cogito.co.uk=
www.cogito.co.uk
----- Original Message -----=20

From: Mowbray, Sam A <sam.m...@eds.com>

To: 'IDM...@IUASSN.COM' <IDM...@iuassn.com>
Sent: 09 August 1999 05:37
Subject: [IDMS-L]Multitasking vs Front-end/Back-end vs Sysplex=20

> Hi Listers,
> We are considering the options = of=20 multi processing, particularly
in relation
> to CPU = performance.
>=20

> Options we are looking at are :

> 1. = Multitasking
> 2.=20 Front-end/Back-end CV processing with the DB calls (and half the
= DC
>=20 calls) being done by the Front-end. The rest of the DC being on=20

the
> Back-end CV
> 3. Sysplex
>

> I have = queried CA=20 and they suggest that in terms of Best CPU
overhead
> = performance the=20 order is Multitasking then FE/BE CVs then
Sysplex.
> = Unfortunately they=20 don't have any hard figures they can give me.
Therefore
> = has=20 anyone done benchmarking in this area?
>
> Many = thanks
>=20 Sam Mowbray
> Database Administrator
> Asia-Pacific = Technology=20
> & Engineering Solution Centre, = Adelaide
> EDS=20 Australia

> Level 8, 108 North Tce,

> ADELAIDE, South = Australia=20 5000
> email : sam.m...@eds.com
> = phone : +61=20 8 8464 1503
> fax = : +61=20 8 8464 2135
>
>
>=20

------=_NextPart_000_0007_01BEE347.A0D8D2A0--
------------------------------ Date: Tue, 10 Aug 1999 10:48:55 -0400
From: "Brennan, Bernie" To: "'idm...@iuassn.com'" Subject: RE:
[IDMS-L]S0C4 at Startup 12.01, 9707 Maintenance Message-ID:
<6730F8076A17D211815F00A024FC62995C2D90@exchange_riv1.bostongas.com>
Roger, try turning off security and see if it comes up (rename RHDCSRTT
and RHDCMT00) Use vanilla version This might help pinpoint it closer.
-----Original Message----- From:Roger Lawrence
[mailto:rlaw...@seminole-electric.com] Sent:Monday, August 09, 1999
5:47 PM To:idm...@iuassn.com Subject:[IDMS-L]S0C4 at Startup 12.01, 9707
Maintenance Hey Y'all, I've just applied 9707 maintenance, set up a new
SVC and installed it using CAIRIM. Upon starting the CV, I get s0c4,
reason code 10 just after +IDMS DC390008 V80 STORAGE RETURNED TO
OPSYS... 3,212K message. Have any of you experienced this when applying
the 9707 maintenance tape? I can't find anything like it in TCC. Thanks
for any and all help. Roger Lawrence, DBA Seminole Electric Cooperative
------------------------------ Date: Tue, 10 Aug 1999 09:54:21 -0500
From: "Hynes, Carol" To: "'idm...@iuassn.com'" Subject: RE:
[IDMS-L]Assembler Options Message-ID:
<6929EAD56AF6D2118C7...@aspxchg4.DWD.STATE.WI.US> I
found this in book manager. Not sure if it will help you. IEW2695W
OPTION SPECIFICATION FOR option name IS NOT VALID FOR VERSION 1 PROGRAM
OBJECT OR LOAD MODULE. Explanation: An option was specified that is
invalid for load modules or version 1 program objects. If the option is
HOBSET, it cannot be reversed or undone on a rebind for version 1
program objects or load modules. Source: Binder Detecting Module:
IEWBXCWL IEWBXCWR System Action: The option specification is invalid.
The module is created, however, any high-order bits in adcons set as a
result of HOBSET will remain on in subsequent rebinds. User Response:
Remove the option or allow the module to be saved as a version 2 program
object. > -----Original Message----- > From:Lorenzen, David C
[SMTP:david.l...@eds.com] > Sent:Tuesday, August 10, 1999 9:19 AM >
To:'idm...@iuassn.com' > Subject:[IDMS-L]Assembler Options > > During
our recent upgrade to OS/390, and migrating our recent > R14 maintenance
tape, we noticed something that I would like > further explanation. In
restoring a few of our DBA usermods, we > received an error that the
Version one of the program should be > converted. It was using an option
called HOBSET (high order bit > setting). We currently ignored the
warning and pressed on. I do > not like warnings, and cannot find this
option. Our manuals are > a little outdated. Any assembler gurus able to
shed some light > on this? Should I be concerned, and if so, what to do
about it? > > Thanks > David Lorenzen > EDS
------------------------------ Date: Tue, 10 Aug 1999 10:52:05 -0400
From: "Lorenzen, David C" To: IDM...@iuassn.com, "'jso...@ice.go.cr'"
Subject: RE: [IDMS-L]Idms jounal block size????? Message-ID: Javier, My
thoughts are, it depends on your recoverability. I like to insure that I
offload a journal every 30 minutes. Others may agree that an hourly
journal offload is sufficient, but I like 30 minutes. Guarantees
recoverability within the half hour. If you increase the number of
journal blocks, you will decrease the frequency. Increasing the number
of journals will not increase/decrease the frequency, but allows more
journals in case of offload problems, or a wayward program gone astray
in your production region. We use 8 journals and offload them to disk
prior to tape. This insures that our journals are offloaded if there are
tape problems, and we have many generations for the disk offload. David
Lorenzen EDS > ---------- > From: Javier Sotela M > Sent: Tuesday,
August 10, 1999 3:33 AM > To: IDM...@iuassn.com > Subject: [IDMS-L]Idms
jounal block size????? > > I repeat my question, because there is not
anwer for my first one. Does > anybody can help me with this question? >
We have four journals with file size 64000 blocks and we are disussing >
about the trade-off betwen more journals or more blocks for journals. We
> are trying to duplicate the number of blocks but i'm not sure if there
> is a good idea. Any comments or suggestions will be great. We are >
running on VSE/ESA with idms rel 14 > > Javier Sotela >
------------------------------ Date: Tue, 10 Aug 1999 09:57:59 -0500
From: Michael Newman To: IDM...@IUASSN.COM Subject: RE: [IDMS-L]Idms
jounal block size????? Message-ID:
<014CEBE84B9BD2118FFB0008C74C5E3C2930@GRNSBORO> Sorry for no response so
far. I am not VSE, but perhaps my thoughts will inspire others. First,
what is the problem you are trying to solve? I try to size my journal
block size so that most of them are filled when they get offloaded. The
journal offload report gives a histogram of percent full of the blocks
copied to tape. This can be tuned by the JOURNAL TRANSACTION LEVEL
parameter in the SYSGEN. This parameter will delay journal io until the
block is full, if a certain number of run-units are currently active. If
that number is not active, then journal io occurs as normal (when a
run-unit issues a check-point of some kind). Next, I try to size the
number of blocks, so that I fill 1 and only 1 tape on an offload. If my
CV is under stress, I don't want the offloads waiting for a second tape
mount. (of course if you offload to disk first, then this is not an
issue). I try to fill the tape, so as not to waste space on the tapes.
The more blocks in a journal, the longer warmstart can take to recover.
However, by using the JOURNAL FRAGMENT INTERVAL parameter in the SYSGEN,
you can speed the process, at the expense of a few journal blocks used
for the interval, and not for journaling. Not knowing the problem, or
what you are attempting to accomplish, makes it difficult to make any
recommendations. -----Original Message----- From:Javier Sotela M
[mailto:jso...@ice.go.cr] Sent:Tuesday, August 10, 1999 4:33 AM
To:IDM...@IUASSN.COM Subject:[IDMS-L]Idms jounal block size????? I
repeat my question, because there is not anwer for my first one. Does
anybody can help me with this question? We have four journals with file
size 64000 blocks and we are disussing about the trade-off betwen more
journals or more blocks for journals. We are trying to duplicate the
number of blocks but i'm not sure if there is a good idea. Any comments
or suggestions will be great. We are running on VSE/ESA with idms rel 14
Javier Sotela ------------------------------ Date: Tue, 10 Aug 1999
11:02:43 -0400 From: lpet...@csc.com To: idm...@iuassn.com Subject: RE:
[IDMS-L]S0C4 at Startup 12.01, 9707 Maintenance Message-ID:
<852567C9.0...@cscmail.csc.com> Try unauthorizing your steplib
concatination by adding an unauthorized library, any library, at the end
of the steplib concatination. The cdmslib concatination is probably
already breaking authorization by inclusion of an unauthorized lib.
------------------------------ Date: Tue, 10 Aug 1999 11:59:20 -0400
From: "Lupico, Joe" To: "'IDM...@IUASSN.COM'" Subject: RE: [IDMS-L]Idms
jounal block size????? Message-ID:
<4F1E68B5C708D11180860001FA372A6501CAFCA6@XCS_LIV01> Javier, I chose to
go the route of more journals rather than bigger journals. At first, I
needed to do this because release 10.x was limited to 10,000 blocks per
journal (at least it was at some point), but I have come to realize that
more is better. I always set up each CV with 8 journals. We have an
automated operator package and I have rules that watch the journal
offload jobs to be sure that they complete within 10 minutes and set off
alarms when a journal offload goes beyond this time. When you have 8
journals, if the above situation occurs, you still have 7/8 of your
journal capacity left to get the problem fixed rather than 3/4. The
journal offloads take half the time, but you have to do them twice as
often and may use twice as many tapes. However, if you consolidate the
offload data on a daily basis and give the offload tapes back to the
scratch pool, that is not a consideration since you'll use approximatly
the same number of tapes each day. Once you get the tapes for day one,
you've got just about all the tapes you'll ever need. Joe > ---------- >
From: Javier Sotela M[SMTP:jso...@ice.go.cr] > Reply To:
jso...@ice.go.cr > Sent: Tuesday, August 10, 1999 4:33 AM > To:
IDM...@IUASSN.COM > Subject: [IDMS-L]Idms jounal block size????? > > I
repeat my question, because there is not anwer for my first one. Does >
anybody can help me with this question? > We have four journals with
file size 64000 blocks and we are disussing > about the trade-off betwen
more journals or more blocks for journals. We > are trying to duplicate
the number of blocks but i'm not sure if there > is a good idea. Any
comments or suggestions will be great. We are > running on VSE/ESA with
idms rel 14 > > Javier Sotela > ------------------------------ Date:
Tue, 10 Aug 1999 15:47:57 -0700 From: Luis Henrique To:
jso...@ice.go.cr Cc: IDM...@iuassn.com Subject: Re: [IDMS-L]Idms jounal
block size????? Message-ID: <37B0AC1C...@lh.com.br> Hi Javier, We
need more details, please: 1- Each journal on different DASD ??? Very
important on VSE. 2- Your Log is on different DASD too ??? Very
important too. 3- When you condensing/offload one journal are there
other journal (or log) being used on the same dasd ?? 4- As big as your
journal, as longer is your condensing/offload time. 5- Do you have
longer tasks with no commits ??? If you have large journals, the
condensing process is very slow. (i.e. you have i/o's on two journal
files.) 6- How is the % of used journal block size . DCMT D STA SYS 7-
Do you already had experience with problems on Journals ???? ioerr=08
.... 8- Why do you need to increase journal ???? Very high
condensing/offload time ???? =============================== a) Your
journals is very big now. b) Try to adjust the Journal block size. Lock
at the used %. Try to use small values. Big % of Journal block used =
less journals I/O's and less journal blocks writed. c) Reduce the batch
tasks running in Central Version with no Commits. d) If you need to
increase, I think that is better more journals than bigger size because
you can distribute the journal activity on different dasd's (may be,
some times you have a active journal on the same dasd of a very accessed
DB) and is easyer to manage problems on journals. P.S. Some years ago, I
divide my CV on two CV's, only to increase the VSE I/O's capacity. I
don't work with VSE today. Regards Luis Henrique L&H Technology Sao
Paulo - Brazil ===================================== Javier Sotela M
wrote: > I repeat my question, because there is not anwer for my first
one. > Does > anybody can help me with this question? > We have four
journals with file size 64000 blocks and we are disussing > > about the
trade-off betwen more journals or more blocks for journals. > We > are
trying to duplicate the number of blocks but i'm not sure if there > >
is a good idea. Any comments or suggestions will be great. We are >
running on VSE/ESA with idms rel 14 > > Javier Sotela
------------------------------ Date: Tue, 10 Aug 1999 16:07:00 -0400
From: radu...@bkb.com To: idm...@iuassn.com Subject: RE:
[IDMS-L]Assembler Options Message-ID: <000B757...@bkb.com> The only
reference I've so far found to HOBSET is: CEEA202 OS/390 V1R3.0 Lang Env
for OS/390 & VM Prog Gde 2.6.4.4 VM/CMS Load Options
|---------------------|--------------------------------------------------|
| HOBSET | HOBSETSD | | Specifies if the high-order bit for V-type | |
NOHOBSET | constants (VCONs) of SD (CSECTs) or LD (ENTRYs) | | | types
is to be turned on or left unchanged. | | | This option only applies to
PL/I applications. |
|------------------------------------------------------------------------|
Richard A. Duffus -----Original Message----- From: idm...@iuassn.com at
INTERNET Sent: Tuesday, August 10, 1999 9:18 AM To:
"'idm...@iuassn.com'" at INTERNET Subject: [IDMS-L]Assembler Options
During our recent upgrade to OS/390, and migrating our recent R14
maintenance tape, we noticed something that I would like further
explanation. In restoring a few of our DBA usermods, we received an
error that the Version one of the program should be converted. It was
using an option called HOBSET (high order bit setting). We currently
ignored the warning and pressed on. I do not like warnings, and cannot
find this option. Our manuals are a little outdated. Any assembler gurus
able to shed some light on this? Should I be concerned, and if so, what
to do about it? Thanks David Lorenzen EDS ------------------------------
Date: Wed, 11 Aug 1999 09:50:48 +0100 From: "Shaw, Brock" To:
"'idm...@iuassn.com'" Subject: RE: [IDMS-L]DML Verb numbers Message-ID:
<81C700BB8A25D3119EE50010E360DAC6087A62@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_01BEE3D6.2BC5D226 Content-Type: text/plain;
charset="iso-8859-1" Jim, Quick Programming Reference is what I always
use. Also Programmers Reference COBOL Appendix D. (Alternatively search
"idbmscom" in BookManager.) Best regards, Brock. Brock Shaw, DBA (ISD)
Mercedes Benz (UK), England -----Original Message----- From: Rice, James
L. Jim [mailto:JLR...@southernco.com] Sent: 10 August 1999 14:44 To:
'idm...@iuassn.com' Subject: [IDMS-L]DML Verb numbers I know that I
should know this, but I can't remember what manual has a listing of all
the DML verb codes. Can someone help this old brain? Thanks. Jim Jim
Rice jlr...@southernco.com ph (404) 506-4148 Fax (404) 506- 4870
------_=_NextPart_001_01BEE3D6.2BC5D226 Content-Type: text/html;
charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE:
[IDMS-L]DML Verb numbers

Jim,

Quick Programming Reference is what I always = use. Also Programmers
Reference COBOL Appendix D. = (Alternatively search "idbmscom" in
BookManager.)

Best regards,
Brock.

Brock Shaw, DBA (ISD)
Mercedes Benz (UK), England

-----Original Message-----
From: Rice, James L. Jim [mailto:JLR...@southernco.com]<= /FONT>
Sent: 10 August 1999 14:44
To: 'idm...@iuassn.com'
Subject: [IDMS-L]DML Verb numbers

I know that I should know this, but I can't remember = what manual has a

listing of all the DML verb codes. Can someone = help this old brain?

Thanks.

Jim

Jim Rice
jlr...@southernco.com
ph (404) 506-4148
Fax (404) 506- 4870

------_=_NextPart_001_01BEE3D6.2BC5D226--

------------------------------

End of IDMS-L V1 #52
********************

Chris Hoelscher

unread,

Aug 13, 1999, 3:00:00 AM8/13/99

To: <IDM...@iuassn.com>
Subject: IDMS-L V1 #53

IDMS-L Thu, 12 Aug 1999 Volume 1 :
Number 53

In this issue:

RE: [IDMS-L]DML Verb numbers

DML Verb numbers
IDMS/SQL migration question
Re: IDMS-L V1 #52
[IDMS-L]Re: IDMS-L V1 #52
Re: [IDMS-L]IDMS/SQL migration question
RE: [IDMS-L]Re: IDMS-L V1 #52
RE: [IDMS-L]Re: IDMS-L V1 #52
RE: [IDMS-L]Re: IDMS-L V1 #52

RE: [IDMS-L]DML Verb numbers

14.1 Upgrade Issues/Problems
New area or sub-area
RE: [IDMS-L]New area or sub-area
RE: [IDMS-L]New area or sub-area
IDMS 14.1 and MVS/XA
RE: [IDMS-L]IDMS 14.1 and MVS/XA
RE: [IDMS-L]IDMS 14.1 and MVS/XA
Re: [IDMS-L]IDMS 14.1 and MVS/XA
Re: [IDMS-L]New area or sub-area
RE: [IDMS-L]Re: IDMS-L V1 #52

----------------------------------------------------------------------

Date: Wed, 11 Aug 1999 08:29:29 -0500

From: "Rice, James L. Jim" <JLR...@southernco.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: [IDMS-L]DML Verb numbers
Message-ID:

<F3E06C56DE75D211B3A...@gaxgpex23.southernco.com>

Thanks Brock.

> -----Original Message-----
> From: Shaw, Brock [SMTP:brock...@MBUK.Mercedes-Benz.com]
> Sent: Wednesday, August 11, 1999 4:51 AM
> To: 'idm...@iuassn.com'
> Subject: RE: [IDMS-L]DML Verb numbers
>

> Jim,
>
> Quick Programming Reference is what I always use. Also Programmers
> Reference COBOL Appendix D. (Alternatively search "idbmscom" in
> BookManager.)
>
> Best regards,
> Brock.
>
> Brock Shaw, DBA (ISD)
> Mercedes Benz (UK), England
>
>
> -----Original Message-----
> From: Rice, James L. Jim [ <mailto:JLR...@southernco.com>]
> Sent: 10 August 1999 14:44
> To: 'idm...@iuassn.com'
> Subject: [IDMS-L]DML Verb numbers
>
>
> I know that I should know this, but I can't remember what manual has a

> listing of all the DML verb codes. Can someone help this old brain?
>
> Thanks.
>
>
> Jim
>
>
> Jim Rice
> jlr...@southernco.com
> ph (404) 506-4148
> Fax (404) 506- 4870
>

------------------------------

Date: Wed, 11 Aug 1999 08:40:09 -0500

From: "Rice, James L. Jim" <JLR...@southernco.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: DML Verb numbers
Message-ID:
<F3E06C56DE75D211B3A...@gaxgpex23.southernco.com>

Thanks to all who replied to my query on this yesterday. While the
DB/DC
quick reference guide did have the DML verb numbers, we were looking
for
the information that is included in the DML for COBOL Appendix D., DB an
DC
call formats.

Thanks to Bill "Bilbo" Gaddy for pointing this out to us.

Regards,

Jim

Jim Rice
jlr...@southernco.com
ph (404) 506-4148
Fax (404) 506- 4870

------------------------------

Date: Wed, 11 Aug 1999 09:29:28 -0500
From: Rita Bruemmer <Rita.B...@its.state.ia.us>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: IDMS/SQL migration question
Message-ID:
<78DA1160F5BDD111BCC...@its-cn-exchange.its.state.ia.us>

A little information first. We use IDMS/Migrator for our migration
process. We migrate source to a QA environment and generate, and then
just migrate load modules to our production environment. My question
is: is there a way to migrate IDMS/SQL access modules doing migrations
in this way? Because the Migrator did not pick up anything for the
access module name.

Thanks.

Rita Bruemmer
Information Technology Services (ITS)
Phone: (515) 242-5174
e-mail: Rita.B...@its.state.ia.us

------------------------------

Date: Wed, 11 Aug 1999 08:53:17 -0600 (Mountain Daylight Time)
From: "bfr...@unm.edu" <bfr...@unm.edu>
To: IDMS-L <IDM...@iuassn.com>
Cc: bfr...@unm.edu
Subject: Re: IDMS-L V1 #52
Message-ID: <Pine.WNT.3.96.99081...@bfraser.unm.edu>

This is a question that pops up about every other year. Is there some
way
of getting the DBNAME within an ADS dialog(a process(DML) command)?
Every
time I am asked this question I go in search of it in vain. It is not
included with the ACCEPT or the ACCEPT STATISTICS, and I can't seem to
find it in the CSA either. Maybe someone out there has a nifty technique

for doing this.

The moment a man begins to talk about technique that's proof that he is
fresh out of ideas.
Raymond Chandler (1888-1959).

Bruce Fraser

------------------------------

Date: Wed, 11 Aug 1999 10:06:16 -0500

From: "Brian Potts" <Bdp...@comdisco.com>
To: <idm...@iuassn.com>

Subject: [IDMS-L]Re: IDMS-L V1 #52
Message-ID: <s7b14b...@groupwise.comdisco.com>

One technique for this would be to invoke the DCUF interface (RHDCUF00)
=
with a DCUF SHOW DBNAME and then interrogate to result. I'm not sure
how =
"nifty" this is, but it should work.

I'm not sure when RHDCUF00 became available. I know it is available in
=
release 14, but I'm not sure about 12.=20

good luck

Brian Potts

>>> "bfr...@unm.edu" <bfr...@unm.edu> 08/11/99 09:53AM >>>
This is a question that pops up about every other year. Is there some
way
of getting the DBNAME within an ADS dialog(a process(DML) command)?
Every
time I am asked this question I go in search of it in vain. It is not
included with the ACCEPT or the ACCEPT STATISTICS, and I can't seem to
find it in the CSA either. Maybe someone out there has a nifty technique

for doing this.

The moment a man begins to talk about technique that's proof that he is
fresh out of ideas.
Raymond Chandler (1888-1959).

Bruce Fraser

------------------------------

Date: Wed, 11 Aug 1999 11:05:46 -0400
From: lpet...@csc.com
To: idm...@iuassn.com
Subject: Re: [IDMS-L]IDMS/SQL migration question
Message-ID: <852567CA.0...@cscmail.csc.com>

One of the most difficult tasks I've found in maintaining sql is
predictable
performance of the access path determined by the optimizer. Since the
optimizer
looks at stats of the database to determine the access plan, the config
of the
database and stats reflecting it should match between qa and prod if
you're
going to migrate load modules. Also the date/time stamp enforcement of
sql
assumes that a query has actually been compiled against the catalog and
database
that it's running against. There are tricks that can be played, but I
would not
migrate load modules and acm's. Instead I would recommend migrating
source and
compiling/creating acms on the system that they run against. If this
requires
changing tradition, then that's preferrable to fooling with mother
sql. I
would keep it simple because to me support of a relational database and
its apps
is a little like the twilight zone; things can change without anyone
getting a
heads up. In those situations simplicity helps in building a stable
environment.

Lutz Petzold

Rita.B...@its.state.ia.us on 08/11/99 03:29:28 PM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com

cc: (bcc: Lutz H Petzold/TMG/CSC)

Subject: [IDMS-L]IDMS/SQL migration question

Thanks.

Rita Bruemmer
Information Technology Services (ITS)
Phone: (515) 242-5174
e-mail: Rita.B...@its.state.ia.us

------------------------------

Date: Wed, 11 Aug 1999 10:06:39 -0500
From: Michael Newman <Michae...@soph.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]Re: IDMS-L V1 #52
Message-ID: <014CEBE84B9BD2118FFB0008C74C5E3C2939@GRNSBORO>

You can make a call to IDMSIN01, specifying you wish to Retrieve session

profile information (GETPROF). This is documented in DML reference
manual for COBOL in appendix D. I know you asked about ADS, just make a

work record for each of the parms passed, and then link to program
IDMSIN01. If you would like sample source, I can get that for you
tomorrow, from a client where I have used calls to IDMSIN01 from ADS.

Snips from the manual:

Working storage contains:
01 RPB.
02 FILLER PIC X(36).

01 REQ-WK.
02 REQUEST-CODE PIC S9(8) COMP.
02 REQUEST-RETURN PIC S9(8) COMP.

01 WORK-FIELDS.
02 WK-DTS-FORMAT PIC S9(8) COMP VALUE 0.
02 WK-CDTS PIC X(26).
02 WK-KEYWD PIC X(8).
02 WK-VALUE PIC X(32).
02 WK-DBNAME PIC X(8).

01 USER-WORK-DATA.
02 WK-SCHEMA PIC X(18).
02 WK-CUSER PIC X(18).
02 WK-DTS PIC X(8).

Procedure code is:
*********************************************************
* Call IDMSIN01 to request a 'GETPROF' to get the user
* profile default DBNAME, which was established by the
* SYSIDMS parm DBNAME=xxxxxxxx when running 'Mini CV', or
* by the DCUF SET DBNAME xxxxxxxx when running under CV.
*
* Parm 1 is the address of the RPB.
* Parm 2 is the address of the REQUEST-CODE and RETURN-CODE.
* Parm 3 is the address of the 8-byte GETPROF keyword.
* Parm 4 is the address of the 32-byte GETPROF returned value.
*********************************************************

MOVE 2 TO REQUEST-CODE
MOVE 'DBNAME' TO WK-KEYWD
CALL 'IDMSIN01' USING RPB REQ-WK WK-KEYWD
WK-VALUE.
MOVE WK-VALUE TO WK-DBNAME.

There is additional info in the DML Reference for Assembler appendix H.

You can basically request any attribute about the users session,
including user defined ones set up in profiles in the catalog.
If you do a DCUF SHO PROFILE, you will see a list of attributes about
your terminal session. Any of these can be retrieved, or set by calls
to IDMSIN01.

Hope this helps.

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: bfr...@unm.edu [mailto:bfr...@unm.edu]
Sent: Wednesday, August 11, 1999 10:53 AM
To: IDMS-L
Cc: bfr...@unm.edu
Subject: [IDMS-L]Re: IDMS-L V1 #52

This is a question that pops up about every other year.
Is there some way
of getting the DBNAME within an ADS dialog(a
process(DML) command)? Every
time I am asked this question I go in search of it in
vain. It is not
included with the ACCEPT or the ACCEPT STATISTICS, and I
can't seem to
find it in the CSA either. Maybe someone out there has a
nifty technique
for doing this.

The moment a man begins to talk about technique that's
proof that he is
fresh out of ideas.
Raymond Chandler (1888-1959).

Bruce Fraser

------------------------------

Date: Wed, 11 Aug 1999 11:17:08 -0400
From: "McMahon, Rick" <Rick.M...@fns.usda.gov>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]Re: IDMS-L V1 #52
Message-ID:
<C1D845867A7ED211A0D...@199.136.154.fns.usda.gov>

Calling 'IDMSIN01' will do the trick. This is documented in the DML
Reference COBOL manual among others. It is not referenced in the ADS
documentation, however, but we use it in ADS dialogs to get DBNAME and
other
user profile parameters.

-----Original Message-----
From: bfr...@unm.edu [mailto:bfr...@unm.edu]
Sent: Wednesday, August 11, 1999 10:53 AM
To: IDMS-L
Cc: bfr...@unm.edu
Subject: [IDMS-L]Re: IDMS-L V1 #52

for doing this.

The moment a man begins to talk about technique that's proof that he is
fresh out of ideas.
Raymond Chandler (1888-1959).

Bruce Fraser

------------------------------

Date: Wed, 11 Aug 1999 10:26:40 -0500
From: "Patterson, Stephanie" <pat...@Jostens.com>
To: "'bfr...@unm.edu'" <bfr...@unm.edu>
Cc: idm...@iuassn.com
Subject: RE: [IDMS-L]Re: IDMS-L V1 #52
Message-ID:
<C52E5E9BE724D311980...@ndpswntx1.owbswntu1.jostens.com>

If I'm understanding your question correctly, all it takes is using a
system-supplied data field.=20

We just use an ADS move to display it on our maps -
ADD =20
PROCESS NAME IS SJUP099-PRE VERSION IS 1 =20
TEXT IS PREMAP =20
MODULE SOURCE FOLLOWS =20
INIT (SJUR099). =20
MOVE DB-NAME TO SJUR099-DB-NAME. (SJUR099 is the map record)
=
=20
IF SJUR099-DB-NAME MATCHES 'JORWK' THEN =20
DO. =20

From R14 CD - (we did this in 10.2, then upgrade to 14.0 without making
=
any
changes)

11.3 System-supplied data field names=20
=20
Purpose: System-supplied data field names specify variable data fields
supplied by the CA-ADS runtime system.
=20
Syntax:
=20
>>--------- + =1B------- DIRECT-DBKEY
-----------------------------------------><
+- - --+ +- DB-NAME -----------------=A6
+- NODE-NAME ---------------=A6
+- agr-data-field ----------=A6
+- amr-data-field ----------=A6
+- $RESPONSE ---------------=A6
+- $PAGE -------------------=A6
+- LENGTH (map-field-name) -=A6
+- CURSOR-ROW --------------=A6
+- CURSOR-COLUMN -----------=A6
+- ERROR-STATUS ------------=A6
+- JULIAN ------------------=A6
+- JULIANX -----------------=A6
+- DATE --------------------=A6
+- DATEX -------------------=A6
+- TIME --------------------=A6
+--- $ERROR-COUNT ----------=A6
=A6 +- $ERRCNT ------+ =A6
+--- $INPUT-COUNT ----------=A6
=A6 +- $INCNT -------+ =A6
+--- $OUTPUT-COUNT ---------+
+- $OUTCNT -------+
> -----Original Message-----
> From: bfr...@unm.edu [SMTP:bfr...@unm.edu]
> Sent: Wednesday, August 11, 1999 9:53 AM
> To: IDMS-L
> Cc: bfr...@unm.edu
> Subject: [IDMS-L]Re: IDMS-L V1 #52
>=20
> This is a question that pops up about every other year. Is there some
=
way
> of getting the DBNAME within an ADS dialog(a process(DML) command)? =
Every
> time I am asked this question I go in search of it in vain. It is not
> included with the ACCEPT or the ACCEPT STATISTICS, and I can't seem =
to
> find it in the CSA either. Maybe someone out there has a nifty =
technique
> for doing this.
>=20
> The moment a man begins to talk about technique that's proof that he =

is
> fresh out of ideas.
> Raymond Chandler (1888-1959).
>=20
> Bruce Fraser
>=20

------------------------------

Date: Wed, 11 Aug 1999 11:23:09 -0500

From: "Rice, James L. Jim" <JLR...@southernco.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: [IDMS-L]DML Verb numbers
Message-ID:

<F3E06C56DE75D211B3A...@gaxgpex23.southernco.com>

Hi Carol,

I think I may owe you a call. Do I? Or have you worked out everything
through Terry?

Jim

> -----Original Message-----
> From: Harris, Carol [SMTP:Carol....@CAI.COM]
> Sent: Wednesday, August 11, 1999 12:19 PM
> To: 'Rice, James L. Jim '
> Subject: RE: [IDMS-L]DML Verb numbers
>
>

> Jim,
> the information is also in the programmers quick reference guide.
> Carol

> Thanks to all who replied to my query on this yesterday. While the
> DB/DC
> quick reference guide did have the DML verb numbers, we were looking
> for
> the information that is included in the DML for COBOL Appendix D., DB
an
> DC
> call formats.
>
> Thanks to Bill "Bilbo" Gaddy for pointing this out to us.
>
> Regards,

>
> Jim
>
>
> Jim Rice
> jlr...@southernco.com
> ph (404) 506-4148
> Fax (404) 506- 4870

------------------------------

Date: Wed, 11 Aug 1999 11:45:35 -0500
From: "Angerer, Chris" <cang...@mail.sdc.state.mo.us>
To: IDMS-L <IDM...@IUASSN.COM>
Subject: 14.1 Upgrade Issues/Problems
Message-ID:
<C18BE495D4DDD0118EA...@mail.sdc.state.mo.us>

We are in the process of converting from IDMS 14.0 to IDMS 14.1 and have

come across some interesting issues that we thought you might find
interesting. I would like to here if anyone else has come across these
as well or other issues that we have not gotten to yet.

1) We applied optional APAR's CS91050 & LS30849 off of the 14.1
installation tape. This caused our regions to abend with a S0C4 at
startup. After opening an issue with CA it was determined that CS91050
& LS30849 were 14.0 APARs not 14.1. We restored off CS91050 & LS30849
and put on APAR TC82160 and all was well.

2) We upgraded 2 smaller regions and all was well until we tried to
upgrade 3 regions with very large DMCL's. We would come up ok, but
would get an S978 or 3964 at shutdown stating: IEA705I ERROR DURING
FREEMAIN SYS CODE = 978-04. Opened an issue with CA and they said the
problem was an incomplete sourced APAR. Applied Test APAR TE1E131 and
all was well.

3) DC Cobol program compiled and running under Cobol for MVS began
abending. It seems that it is failing on the LOAD TABLE. It looks like

the LOAD TABLE is not setting the address for the linkage field that the

table is being loaded into. Have a Open issue with CA and according to
them it sounds like a new bug and has been transferred to Level 2. CA
did state that one other customer seems to be having the same problem.
Will update IDMS-L when this issue has been resolved.

Chris W. Angerer
State of Missouri / OA / DIS
cang...@mail.state.mo.us

------------------------------

Date: Wed, 11 Aug 1999 13:05:41 -0500
From: rpi...@mge.com
To: IDM...@iuassn.com
Subject: New area or sub-area
Message-ID: <99Aug11.130...@dns.MGE.COM>

Hi all -

I have an area that needs to be split (segmented). Does anyone have any

"feelings" as to wether to split the area into 2 sub-areas (symbolics),
or
split the area into 2 physical areas.

The re-org to do the split should take ~ 6 hours.

Thanks in advance

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
************************************************************************

------------------------------

Date: Wed, 11 Aug 1999 12:13:26 -0600
From: "Wood, Chris" <Chris...@gov.ab.ca>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]New area or sub-area
Message-ID:
<709658908B3FD311B3A...@eoaexc01.enr.gov.ab.ca>

Dick,

If you are close to the max number of DD statements in your CV job then
sub-area is the only way to go. I believe that it makes looking after
your
database easier if you use new areas rather than split the area up. When
you
report space used on an area with sub-areas you may get confused. The
KISS
method is best.

Chris Wood
Alberta Department of Resource Development
CANADA

-----Original Message-----
From: rpi...@mge.com [mailto:rpi...@mge.com]
Sent: August 11, 1999 12:06 PM
To: IDM...@iuassn.com
Subject: [IDMS-L]New area or sub-area

Hi all -

I have an area that needs to be split (segmented). Does anyone have any

"feelings" as to wether to split the area into 2 sub-areas (symbolics),
or
split the area into 2 physical areas.

The re-org to do the split should take ~ 6 hours.

Thanks in advance

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
************************************************************************

------------------------------

Date: Wed, 11 Aug 1999 13:18:37 -0500
From: Michael Newman <Michae...@soph.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]New area or sub-area
Message-ID: <014CEBE84B9BD2118FFB0008C74C5E3C293B@GRNSBORO>

My "feelings" would be to split the area into 2 physical areas and
files.

Maintenance issues are much simpler. If you segment the area into
sub-areas, you won't know for sure how full each sub-area is by the
standard Print Space utility. It may say the area is 60% full, but 1
sub-area may be 99%, and the other only 10%. You would need to run
IDMSDBAN specifying the page range of each sub-area, then calculating
yourself the percent full (or available).

Maintenance would be needed on only the area (and file(s)) that had the
problem in all aspects (Expand page, Unload/Reload, etc.)

The drawback, is the applications may have to change code to ready the
new area.

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: rpi...@mge.com [mailto:rpi...@mge.com]
Sent: Wednesday, August 11, 1999 2:06 PM
To: IDM...@iuassn.com
Subject: [IDMS-L]New area or sub-area

Hi all -

I have an area that needs to be split (segmented). Does
anyone have any
"feelings" as to wether to split the area into 2
sub-areas (symbolics), or
split the area into 2 physical areas.

The re-org to do the split should take ~ 6 hours.

Thanks in advance

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

************************************************************************

------------------------------

Date: Wed, 11 Aug 1999 13:27:28 -0500
From: "Rick L. Garvin" <r...@ksu.edu>
To: IDM...@IUASSN.COM
Subject: IDMS 14.1 and MVS/XA
Message-ID: <37B1C090...@ksu.edu>

I am trying to bring up IDMS 14.1 in XA and during startup I get an
error
that makes reference to the SVC not being installed. I found on TCC
APAR LO48166 that solves the problem. Unfortunately it references
program RHDCOESA which is used in an ESA environment. I would think
that I should zap RHDCOMVS.

Does anyone know which APAR should be applied in XA to solve the SVC
issue?

Ps. I applied LO48166 in our ESA envirnoment and it does solve the
problem for that OS.

------------------------------

Date: Wed, 11 Aug 1999 14:19:51 -0500
From: "Runtsch, Steve" <Steve....@ecolab.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]IDMS 14.1 and MVS/XA
Message-ID: <E994F67723A4D211B00C000083623DF00202407F@CORPHQ2>

It doesn't look to me like CA has published the fix for RHDCOMVS (if
that is
in fact what you need). I did notice that a similar problem was fixed
in
14.0. See LO10480. I wonder if this is a repeat of a previous mistake?

Steve Runtsch
Ecolab Inc.
Saint Paul "Wild", Minnesota

-----Original Message-----
From: Rick L. Garvin [mailto:r...@ksu.edu]
Sent: Wednesday, August 11, 1999 01:27 pm
To: IDM...@iuassn.com
Subject: [IDMS-L]IDMS 14.1 and MVS/XA

Does anyone know which APAR should be applied in XA to solve the SVC
issue?

Ps. I applied LO48166 in our ESA envirnoment and it does solve the
problem for that OS.

------------------------------

Date: Wed, 11 Aug 1999 14:28:04 -0500
From: "Angerer, Chris" <cang...@mail.sdc.state.mo.us>
To: idm...@iuassn.com
Subject: RE: [IDMS-L]IDMS 14.1 and MVS/XA
Message-ID:
<C18BE495D4DDD0118EA...@mail.sdc.state.mo.us>

If you are on MVS release 4.3 or lower you need to zap RHDCOMVS if your
are at a MVS release of 4.3 or higher zap in RHDCOESA. We are on OS390
so we use RHDCOESA. (I think the 4.3 is right it maybe 4.1 but look in
the manuals and it will tell you.) I remember having a similar problem

just go against the RHDCOESA module and make sure you are linking it in
your startup module. Your startup module should have the following in
it:
INCLUDE USERLIB(RHDCOESA)
INCLUDE USERLIB(RHDCOMOC)
INCLUDE USERLIB(RHDCHPCS)
INCLUDE USERLIB(RHDCACHE)
INCLUDE OBJLIB(RHDCPARM)
INCLUDE WTOLIB(WTOEXIT)

Chris W. Angerer
State of Missouri / OA / DIS
cang...@mail.state.mo.us

-----Original Message-----
From: Rick L. Garvin [mailto:r...@ksu.edu]
Sent: Wednesday, August 11, 1999 1:27 PM
To: IDM...@IUASSN.COM
Subject: [IDMS-L]IDMS 14.1 and MVS/XA

Does anyone know which APAR should be applied in XA to solve the SVC
issue?

Ps. I applied LO48166 in our ESA envirnoment and it does solve the
problem for that OS.

------------------------------

Date: Wed, 11 Aug 1999 16:48:24 -0400
From: lpet...@csc.com
To: idm...@iuassn.com
Subject: Re: [IDMS-L]IDMS 14.1 and MVS/XA
Message-ID: <852567CA.0...@cscmail.csc.com>

You need to apply the RHDCOMVS flavor of the apar. RHDCOESA is for
idms's
running on os390. Look at your startup module with online smpe and it
will tell
qyou whether omvs or oesa got linked. It depended on the opsys parm you
coded
on the install.

r...@ksu.edu on 08/11/99 07:27:28 PM

Please respond to idm...@iuassn.com

To: IDM...@iuassn.com

cc: (bcc: Lutz H Petzold/TMG/CSC)

Subject: [IDMS-L]IDMS 14.1 and MVS/XA

Does anyone know which APAR should be applied in XA to solve the SVC
issue?

Ps. I applied LO48166 in our ESA envirnoment and it does solve the
problem for that OS.

------------------------------

Date: Wed, 11 Aug 1999 22:48:42 -0400
From: Laura Rochon <laura....@cloxt.com>
To: idm...@iuassn.com
Subject: Re: [IDMS-L]New area or sub-area
Message-ID: <0FGB008...@falla.videotron.net>

Dick,

I agree with Michael that you cannot rely on the PRINT SPACE utility =
for
the space utilisation when you have multiple subareas within the same=
area.
You can use IDMSDBAN with an AREA statement along with FROM page to =
page,
for the page range of the first subarea. The inconvience of using ID=
MSDBAN
is that it will only process the first AREA statement for a particula=
r
area. In other words, you can have multiple AREA statements within 1
execution of DBAN, and each area statement is processed as long as th=
ey are
for different areas. If you have multiple AREA statements with the s=
ame
area name, only the first one is processed; the others (with the same=
area
name) are ignored. All of this means that if you split an area into
multiple subareas, you will need to run as many DBAN jobs as you have
subareas in order to get a true picture of each subarea.

But splitting the area in subareas can require a tremendous amount of=
work
on your application staff. If your ADS dialogs have a READY statemen=
t with
the area name, then you will need to add a READY statement if the dia=
log
needs a ready mode different from the subschema's default. In your C=
OBOL
programs, if you are not using 1 READY statement for all areas in you=
r
subschema, you will need to change the program to add the READY state=
ment.=20
Depending on the size of the application, this could result in a lot =
of
work for your application staff. I would do an impact analysis to
determine the number of programs/dialogs that would need to be change=
d
before deciding one way or another.

I hope this helps,
Laura Rochon
Compuware Corporation of Canada

----------
> From: Michael Newman <Michae...@soph.com>
> To: 'idm...@iuassn.com'
> Subject: RE: [IDMS-L]New area or sub-area
> Date: 11 ao=FBt, 1999 14:18
>=20
> My "feelings" would be to split the area into 2 physical areas and
> files. =20
>=20
> Maintenance issues are much simpler. If you segment the area into
> sub-areas, you won't know for sure how full each sub-area is by the
> standard Print Space utility. It may say the area is 60% full, but=
1
> sub-area may be 99%, and the other only 10%. You would need to run
> IDMSDBAN specifying the page range of each sub-area, then calculati=
ng
> yourself the percent full (or available). =20
>=20
> Maintenance would be needed on only the area (and file(s)) that had=
the
> problem in all aspects (Expand page, Unload/Reload, etc.)
>=20
> The drawback, is the applications may have to change code to ready =
the
> new area.
>=20

> Michael A. Newman
> Sophisticated Business Systems, Inc.
> 101 CentrePort Drive, Suite 310
> Greensboro, NC 27409
> E-Mail: Michae...@soph.com

> Phone:=09336.605.4771 Ext. 116
> Fax:=09336.605.4772
>=20
>=20
> =09=09-----Original Message-----
> =09=09From:=09rp...@mge.com [mailto:rpi...@mge.com]
> =09=09Sent:=09Wednesday, August 11, 1999 2:06 PM
> =09=09To:=09ID...@iuassn.com
> =09=09Subject:=09[IDMS-L]New area or sub-area
>=20
> =09=09Hi all -
>=20
> =09=09I have an area that needs to be split (segmented). Does
> anyone have any
> =09=09"feelings" as to wether to split the area into 2
> sub-areas (symbolics), or
> =09=09split the area into 2 physical areas.
>=20
> =09=09The re-org to do the split should take ~ 6 hours.
>=20
> =09=09Thanks in advance
>=20
> =09=09Dick
>=20
> =09
> *******************************************************************=
*****
> =09=09Richard A. Pierce Madison Gas and Electric
> Company
> =09=09DBA P.O. Box 1231, Madison,
> Wisconsin 53701-1231
> =09=09e-mail:rpi...@mge.com Phone: 608-252-7205
> =09
> *******************************************************************=
*****
> =09=09

------------------------------

Date: Thu, 12 Aug 1999 08:36:04 +0200
From: J.A.van....@robeco.nl
To: idm...@iuassn.com
Subject: RE: [IDMS-L]Re: IDMS-L V1 #52
Message-ID: <C12567CB.00244DCF.00@ROTT_MTA_1B.Robeco.nl>

--0__=xxDA4c7zczBtBuyFa2kVRVQjI1acAemcCiUYNggVrAt1jvgE3yikmgMS
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

We do exactly the same. Very simple and works great.

pat...@jostens.com on 08/11/99 05:26:40 PM

Please respond to idm...@iuassn.com

To: bfr...@unm.edu
cc: idm...@iuassn.com (bcc: Jos=E9 van Kesteren/Robeco Group)
Subject: RE: [IDMS-L]Re: IDMS-L V1 #52

--0__=xxDA4c7zczBtBuyFa2kVRVQjI1acAemcCiUYNggVrAt1jvgE3yikmgMS
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

If I'm understanding your question correctly, all it takes is using a
system-supplied data field.

We just use an ADS move to display it on our maps -
ADD
PROCESS NAME IS SJUP099-PRE VERSION IS 1
TEXT IS PREMAP
MODULE SOURCE FOLLOWS
INIT (SJUR099).
MOVE DB-NAME TO SJUR099-DB-NAME. (SJUR099 is the map record)
IF SJUR099-DB-NAME MATCHES 'JORWK' THEN
DO.

From R14 CD - (we did this in 10.2, then upgrade to 14.0 without making
any
changes)

11.3 System-supplied data field names

Purpose: System-supplied data field names specify variable data fields
supplied by the CA-ADS runtime system.

Syntax:

>>--------- +
------- DIRECT-DBKEY
-----------------------------------------><
+- - --+ +- DB-NAME -----------------
--0__=xxDA4c7zczBtBuyFa2kVRVQjI1acAemcCiUYNggVrAt1jvgE3yikmgMS
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

=A6
+- NODE-NAME ---------------=A6
+- agr-data-field ----------=A6
+- amr-data-field ----------=A6
+- $RESPONSE ---------------=A6
+- $PAGE -------------------=A6
+- LENGTH (map-field-name) -=A6
+- CURSOR-ROW --------------=A6
+- CURSOR-COLUMN -----------=A6
+- ERROR-STATUS ------------=A6
+- JULIAN ------------------=A6
+- JULIANX -----------------=A6
+- DATE --------------------=A6
+- DATEX -------------------=A6
+- TIME --------------------=A6
+--- $ERROR-COUNT ----------=A6
=A6 +- $ERRCNT ------+ =A6
+--- $INPUT-COUNT ----------=A6
=A6 +- $INCNT -------+ =A6
+--- $OUTPUT-COUNT ---------+
+- $OUTCNT -------+
> -----Original Message-----
> From: bfr...@unm.edu [SMTP:bfr...@unm.edu]
> Sent: Wednesday, August 11, 1999 9:53 AM
> To: IDMS-L
> Cc: bfr...@unm.edu
> Subject: [IDMS-L]Re: IDMS-L V1 #52
>
> This is a question that pops up about every other year. Is there some=

way
> of getting the DBNAME within an ADS dialog(a process(DML) command)? E=

very
> time I am asked this question I go in search of it in vain. It is not=

> included with the ACCEPT or the ACCEPT STATISTICS, and I can't seem t=

o
> find it in the CSA either. Maybe someone out there has a nifty techni=

que
> for doing this.
>
> The moment a man begins to talk about technique that's proof that he =

is
> fresh out of ideas.
> Raymond Chandler (1888-1959).
>
> Bruce Fraser
>

----------------------------------------------------------------------=
--------=20
The information contained in this communication is confidential and ma=
y be =20
legally privileged. It is intended solely for the use of the individua=
l or =20
entity to whom it is addressed and others authorised to receive it. If=
you are=20
not the intended recipient you are hereby notified that any disclosure=
, =20
copying, distribution or taking any action in relation to the contents=
of this=20
information is strictly prohibited and may be unlawful. Neither the se=
nder nor=20
the represented institution are liable for the correct and complete =
=20
transmission of the contents of an e-mail, or for its timely receipt. =
=20
----------------------------------------------------------------------=
--------=20

--0__=xxDA4c7zczBtBuyFa2kVRVQjI1acAemcCiUYNggVrAt1jvgE3yikmgMS--

------------------------------

End of IDMS-L V1 #53
********************

Chris Hoelscher

unread,

Aug 13, 1999, 3:00:00 AM8/13/99

To: <IDM...@iuassn.com>
Subject: IDMS-L V1 #54

IDMS-L Fri, 13 Aug 1999 Volume 1 :
Number 54

In this issue:

rhdc0esa
FACTOTUM TASK
Re: [IDMS-L]rhdc0esa

Re: [IDMS-L]New area or sub-area

RE: [IDMS-L]FACTOTUM TASK
Re: [IDMS-L]FACTOTUM TASK
re: [IDMS-L]FACTOTUM TASK
Re: [IDMS-L]FACTOTUM TASK
Re: [IDMS-L]rhdc0esa
RE:[IDMS-L]FACTOTUM TASK
Re: [IDMS-L]rhdc0esa
RE: [IDMS-L]FACTOTUM TASK
RE: [IDMS-L]rhdc0esa
RE: [IDMS-L]FACTOTUM TASK
Obtaining DBNAME within ADSO
RE: [IDMS-L]FACTOTUM TASK
RE: FACTOTUM TASK
FW: [IDMS-L]Obtaining DBNAME within ADSO
Re: FW: [IDMS-L]Obtaining DBNAME within ADSO
SQL question

RE: [IDMS-L]New area or sub-area

RE: FW: [IDMS-L]Obtaining DBNAME within ADSO
Idms jounal block size?????
The future of IDMS !!!
Re: [IDMS-L]The future of IDMS !!!
RE: [IDMS-L]The future of IDMS !!!
RE: [IDMS-L]The future of IDMS !!!
RE: [IDMS-L]FACTOTUM TASK
Re: [IDMS-L]RE: FACTOTUM TASK
RE: [IDMS-L]The future of IDMS !!!
Smp/E question
Re: [IDMS-L]Smp/E question
Re: Re: [IDMS-L]The future of IDMS !!!

----------------------------------------------------------------------

Date: Thu, 12 Aug 1999 08:08:16 -0400

From: "Gene.McCormack" <Gene.Mc...@plpit.fishersci.com>
To: idm...@iuassn.com

Subject: rhdc0esa
Message-ID:
<8BEC761BBB76D21196D9...@exchg-pdc-plpgh.fishersci.com>

What are the benefits of using RHDC0ESA with OS390 in a 12.01 startup
module ?

------------------------------

Date: Thu, 12 Aug 1999 08:20:57 -0400

From: "Gene.McCormack" <Gene.Mc...@plpit.fishersci.com>
To: idm...@iuassn.com

Subject: FACTOTUM TASK
Message-ID:
<8BEC761BBB76D21196D9...@exchg-pdc-plpgh.fishersci.com>

Could someone explain the purpose of a FACTOTUM task and what to do if
one
stays online all day .

------------------------------

Date: Thu, 12 Aug 1999 08:36:33 -0400
From: lpet...@csc.com
To: idm...@iuassn.com
Subject: Re: [IDMS-L]rhdc0esa
Message-ID: <852567CB.0...@cscmail.csc.com>

>What are the benefits of using RHDCOESA with OS390?

It's required by CA to be fully supported. It's the operating system
dependent
module, meaning any operating system service calls are made from within
it.
Generally other IDMS internal programs don't make opsys calls on their
own.
Rhdcoesa assembles those against a 4.? (4.3?) sys1 macro library.
Given IBM's
habit of supplying backwards compatible software (try that in gui land!)
I
suspect all rhdcoesa provides is use of new sysplex services, maybe even

hyper/data space services. But to me the main consideration is that if
there's
ever a TCC call required, they will drop their efforts until the correct
opsys
dependent module is used...you'll get the line 'try it this way and see
if the
problem occurs again'. Plus it's embarassing to find out the wrong
opsys has
been defined to the install programs, opening the door to all kinds of
speculations from Phillistines.

Lutz Petzold

Gene.Mc...@plpit.fishersci.com on 08/12/99 08:08:16 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Lutz H Petzold/TMG/CSC)

Subject: [IDMS-L]rhdc0esa

What are the benefits of using RHDC0ESA with OS390 in a 12.01 startup
module ?

------------------------------

Date: Thu, 12 Aug 1999 05:43:35 PDT
From: "Jim Phillips" <jimphi...@hotmail.com>

To: idm...@iuassn.com
Subject: Re: [IDMS-L]New area or sub-area

Message-ID: <1999081212433...@hotmail.com>

If I'm following this thread correctly the argument against sub-areas is

that they are a bother to administer. One argument against new
areas/files
is that they require more DD statements, additions to the back up plan
(if
specific files referenced) and other operating system related stuff. The

other argument against new areas is the need to change dialogs with
explicit
READY's and programs with qualified READY's.

If you can live with changing the applications, or do not have to, this
may
be a case for multi area files. This approach would seem
to surmount the DBAN problem and the operating system issues. I think
the
arrrangement is ghastly but that was beaten to death in previous
correspondence.

That's my 15 cents worth and it didn't take a hour to write !

Jim Phillips
ISP
(800) 295-7608

>From: Laura Rochon <laura....@cloxt.com>
>Reply-To: idm...@iuassn.com
>To: idm...@iuassn.com
>Subject: Re: [IDMS-L]New area or sub-area
>Date: Wed, 11 Aug 1999 22:48:42 -0400
>

>Dick,
>
>I agree with Michael that you cannot rely on the PRINT SPACE utility

for
>the space utilisation when you have multiple subareas within the same

area.
> You can use IDMSDBAN with an AREA statement along with FROM page to

page,
>for the page range of the first subarea. The inconvience of using

IDMSDBAN
>is that it will only process the first AREA statement for a particular

>area. In other words, you can have multiple AREA statements within 1

>execution of DBAN, and each area statement is processed as long as they

are
>for different areas. If you have multiple AREA statements with the

same

>area name, only the first one is processed; the others (with the same

area
>name) are ignored. All of this means that if you split an area into
>multiple subareas, you will need to run as many DBAN jobs as you have
>subareas in order to get a true picture of each subarea.
>
>But splitting the area in subareas can require a tremendous amount of

work
>on your application staff. If your ADS dialogs have a READY statement

with
>the area name, then you will need to add a READY statement if the

dialog

>needs a ready mode different from the subschema's default. In your

COBOL
>programs, if you are not using 1 READY statement for all areas in your

>subschema, you will need to change the program to add the READY

statement.
>Depending on the size of the application, this could result in a lot of

>work for your application staff. I would do an impact analysis to

>determine the number of programs/dialogs that would need to be changed

>before deciding one way or another.
>
>I hope this helps,
>Laura Rochon
>Compuware Corporation of Canada
>
>
>
>----------
> > From: Michael Newman <Michae...@soph.com>
> > To: 'idm...@iuassn.com'
> > Subject: RE: [IDMS-L]New area or sub-area

> > Date: 11 août, 1999 14:18

> >
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

------------------------------

Date: Thu, 12 Aug 1999 07:41:56 -0500
From: "Lorenzen, David C" <david.l...@eds.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]FACTOTUM TASK
Message-ID: <B9CB0C7E771ED2119FA400A02461EE240325E86B@USPLM206>

Gene,

FACTOTUM and HELOT tasks are dispatched from MASTER (task 0) and
the Resource Controller DBRC (task 1). Master and DBRC will never wait
for
a
resource but rather will dispatch these slave drivers to perform a
serious of functions. When the slave drivers have completed their
tasks, they return to either Master or DBRC for completion. MASTER
dispatches FACTOTUM for online transactions, DBRC dispatches HELOT
tasks for batch functions. These cannot be cancelled (at least easily)
and
will not expire as their stall interval is set to "no stall". To remove
the
functions one must understand what the task was used for. For example,
if you attempt to vary the load area offline, and you did not vary the
run
unit
loader off, a HELOT task will be dispatched to vary the area. However
this
will not complete until you vary the run unit loader offline. Therefor,
the
HELOT task will continue to wait.

Hope this helps.
David Lorenzen
EDS

> ----------
> From: Gene.McCormack
> Sent: Thursday, August 12, 1999 7:20 AM
> To: idm...@iuassn.com
> Subject: [IDMS-L]FACTOTUM TASK
>
> Could someone explain the purpose of a FACTOTUM task and what to do if
one
> stays online all day .
>

------------------------------

Date: Thu, 12 Aug 1999 08:46:18 -0400

From: Laura Rochon <laura....@cloxt.com>
To: idm...@iuassn.com

Subject: Re: [IDMS-L]FACTOTUM TASK
Message-ID: <0FGC004...@field.videotron.net>

Gene,

FACTOTUM is latin for DO (fac) ALL (totum). It's the do-all (or goph=
er)
task for MASTER. Master will never wait on a resource or a terminal =
I/O.=20
In general, master controls the terminal environment. He's the one w=
ho
sends out the ENTC (Enter Next Task Code) message, or the Undefined t=
ask
code message, etc. But he mustn't wait on the terminal I/O, so maste=
r will
dispatch a FACTOTUM task who will actually do the write to the pterm.=
=20
Factotum task do not usually stay around very long as they just do th=
e
write to the terminal and nothing much else. If you have a factotum =
task
that is staying online all day, I suspect that you have an Exit 17 or=
18
(whichever one is for the write terminal) and something must be going=
on in
the exit. If you want to know what factotum was doing, look at the L=
TE
control block associated to the TCE of the running task. The field
LTEFACCD field in the LTE will specify what factotum was supposed to =
do. =20

Good luck,

Laura Rochon
Compuware Corporation of Canada

----------

> From: Gene.McCormack <Gene.Mc...@plpit.fishersci.com>
> To: idm...@iuassn.com

> Subject: [IDMS-L]FACTOTUM TASK
> Date: 12 ao=FBt, 1999 08:20
>=20
> Could someone explain the purpose of a FACTOTUM task and what to do=
if
one
> stays online all day . =20

------------------------------

Date: Thu, 12 Aug 99 8:52:59 EDT
From: "Tim Kupin" <tim....@occ.treas.gov>
To: <idm...@iuassn.com>
Subject: re: [IDMS-L]FACTOTUM TASK
Message-ID: <vines.bz...@b.occ.treas.gov>

FACTOTUM is greek for "doer of all". It is dispatched by MASTER to wait
for
resources as MASTER will not wait. HELOT is to DBDC what FACTOTUM is to
MASTER.

If you have a FACTOTUM executing all day long you need to figure out
what your
system is waiting for. Is the TASK ID the same all day or are numerous
FACTOTUM's dispatched throughout the day?
---------- Original Text ----------

From: "Gene.McCormack" <Gene.Mc...@plpit.fishersci.com>, on
8/12/1999 8:20
AM:

Could someone explain the purpose of a FACTOTUM task and what to do if
one
stays online all day .

------------------------------

Date: Thu, 12 Aug 1999 09:10:58 -0400
From: lpet...@csc.com
To: idm...@iuassn.com
Subject: Re: [IDMS-L]FACTOTUM TASK
Message-ID: <852567CB.0...@cscmail.csc.com>

>What's a factotum?

A factotum is the alterego of a helot. Factotum is an internal task
attached by
DC to perform some piece of work that may involve a wait state and that
can't be
done under a user's task thread. The helot does the same thing, except
for the
database side of IDMS. Besides, one is Greek, the other Latin.
Depending on
the type of factotum, these tasks have the no cancel flag on in the tce,
which
means timeouts are ignored for them and they will hang around, I
believe a
shutdown even waits on these. The best way to deal with them is to feed
them
what they need. The 'enter next task code' prompt is written by a
factotum type
2, IIRC, if this one's stuck on a terminal io wait doing various dcmt
vary's
may free it. DCMT vary area commands are serviced by helot's. I've
seen helots
stuck more often than factotums. The only way that I know of,
legitimately, to
get rid of these on an emergency basis is to MVS cancel IDMS than
restart. This
maybe dangerous though if it's a helot attached becuase of a new
file/dmcl and
there's something wrong. In that case I would not cancel IDMS, it may
not come
up with the new dmcl and or area lock conflicts. Instead investigate
the cause
of the helot hang and correct it.

Lutz Petzold

Gene.Mc...@plpit.fishersci.com on 08/12/99 08:20:57 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Lutz H Petzold/TMG/CSC)

Subject: [IDMS-L]FACTOTUM TASK

Could someone explain the purpose of a FACTOTUM task and what to do if
one
stays online all day .

------------------------------

Date: Thu, 12 Aug 1999 09:10:51 -0400
From: rcg...@statestreet.com
To: idm...@iuassn.com
Subject: Re: [IDMS-L]rhdc0esa
Message-ID: <H000107a24022cb5@MHS>

--openmail-part-114d0db6-00000001
Content-Type: text/plain; charset=US-ASCII; name="Re:"
Content-Disposition: inline; filename="Re:"
Content-Transfer-Encoding: 7bit

Ahh.......yes..........Theres nothing like that LHP wit before
9AM......sysplex and hyper/data space services were rolled into ESA
along with RHDCACHE.
RHDCOMOC is the open/close services module and RHDCHPCS has ...you
guessed it the hpcs routines.

Ron Gagne

PS ....Are the Phillistines forgiving folks ???
----------
From: lpetzold / INTERNET (lpet...@csc.com)
To: idm...@iuassn.com
Subject: Re: [IDMS-L]rhdc0esa
Date: Thursday, August 12, 1999 5:36AM

>What are the benefits of using RHDCOESA with OS390?

Lutz Petzold

Gene.Mc...@plpit.fishersci.com on 08/12/99 08:08:16 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Lutz H Petzold/TMG/CSC)

Subject: [IDMS-L]rhdc0esa

What are the benefits of using RHDC0ESA with OS390 in a 12.01 startup
module ?

--openmail-part-114d0db6-00000001

Content-Type: application/ms-tnef; name="WINMAIL.DAT"
Content-Disposition: attachment; filename="WINMAIL.DAT"
Content-Transfer-Encoding: base64

eJ8+IgAAAQuAAQAnAAAAODUyNTY3Q0IuMDA0NTM3MzYuMDAoYSljc2NtYWlsLmNzYy5jb20A

gAo=

--openmail-part-114d0db6-00000001--

------------------------------

Date: Thu, 12 Aug 1999 08:12:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: idm...@iuassn.com
Subject: RE:[IDMS-L]FACTOTUM TASK
Message-ID: <NY8c667c...@bfi.com>

Gene.McCormack:
> Could someone explain the purpose of a FACTOTUM task and what to do if

> one stays online all day .

Main Entry: fac to tum
Pronunciation: fak-'tO-t&m
Function: noun
Etymology: New Latin, literally, do everything, from Latin fac
(imperative of facere do) + totum everything
Date: 1566
1 : a person having many diverse activities or responsibilities
2 : a general servant

Factotum tasks are dispatched to handle routine system commands. For
example, when you issue a DCMT VARY AREA <name> OFFLINE command, a
factotum is dispatched to accomplish that.

The place where I see an ever-lasting factotum is when someone tries to
vary
the DDLDCLOD area offline/retrieval. The system can't complete this if
the
area is in-use, so the command quiesces, and the factotum task just sits
there
forever waiting for the area to become free so that it can complete its
function.
The DDLDCLOD area will cause this because the predefined run unit loader

owns it, for the life of the system. The only way to make the DCMT VARY
AREA
command complete is to do a DCMT VARY RUN UNIT LOADER OFF, to terminate
the predefined run unit for the loader. This will then allow the area
vary to
complete successfully, and the factotum task will disappear.

If you use PMRM, PF4 to display task info, you'll probably see the
factotum
task
with the "First ECB" value of something like "DC V TSK". This lets you
know
that the task is a DMCT VARY task, waiting on an event control block to
be
posted so that it can continue its function.

Another one you'll see like that sometimes is the HELOT task.

Main Entry: hel ot
Pronunciation: 'he-l&t
Function: noun
Etymology: Latin Helotes, plural, from Greek HeilOtes
Date: 1579
1 capitalized : a member of a class of serfs in ancient Sparta
2 : SERF, SLAVE
- hel ot ry /'he-l&-trE/ noun

Someone really liked these old Latin words that nobody understands when
they
wrote IDMS. <grin>

John Rich
Browning-Ferris Industries

------------------------------

Date: Thu, 12 Aug 1999 09:40:55 -0400
From: "Larry Yozwiak" <lyoz...@metlife.com>
To: <idm...@iuassn.com>
Subject: Re: [IDMS-L]rhdc0esa
Message-ID: <852567CB.0...@metlife.com>

Is this really a 12.01 module? I don't see it in my 9506 loadlib.

lpet...@csc.com on 08/12/99 08:36:33 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Larry Yozwiak/Bsg/MetLife/US)
Subject: Re: [IDMS-L]rhdc0esa

>What are the benefits of using RHDCOESA with OS390?

Lutz Petzold

Gene.Mc...@plpit.fishersci.com on 08/12/99 08:08:16 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Lutz H Petzold/TMG/CSC)

Subject: [IDMS-L]rhdc0esa

What are the benefits of using RHDC0ESA with OS390 in a 12.01 startup
module ?

------------------------------

Date: Thu, 12 Aug 1999 15:10:54 +0100
From: peter.g...@bt.com
To: idm...@iuassn.com
Subject: RE: [IDMS-L]FACTOTUM TASK
Message-ID:
<5F54BE0116BCD2118C9...@mclmsent02.lon.bt.com>

Gene , I wish to disagree. FACTOTUMs act for/are created by RHDCMSTR
task 0.
These perform DC functions. e,g write entc.
Helots act for/are created by RHDCDBRC task 1. So a DCMT VARY AREA will
cause a HELOT and not a FACTOTUM to be created.
Another differences bewtween FACTOTUMs and HELOTs is that when a
FACTOTUM
has 'done it's thing' it will terminate.
HELOTs wait 'for a bit'. This makes sense as if you DCMT VARY AREA it
possible that you may be doing many DCMT V AREA commands. RHDCDBRC
checks to
see if there a HELOT 'it can use' and if so does. This save some time in

task creation ( i.e a new task is not created just post the current
HELOT ).

Pete

> -----Original Message-----
> From: John.Rich [SMTP:John...@bfi.com]
> Sent: 12 August 1999 14:12
> To: idm...@iuassn.com

> Subject: RE:[IDMS-L]FACTOTUM TASK
>
> Gene.McCormack:
> > Could someone explain the purpose of a FACTOTUM task and what to do
if
> > one stays online all day .
>
> Main Entry: fac to tum
> Pronunciation: fak-'tO-t&m
> Function: noun
> Etymology: New Latin, literally, do everything, from Latin fac
> (imperative of facere do) + totum everything
> Date: 1566
> 1 : a person having many diverse activities or responsibilities
> 2 : a general servant
>
> Factotum tasks are dispatched to handle routine system commands. For
> example, when you issue a DCMT VARY AREA <name> OFFLINE command, a
> factotum is dispatched to accomplish that.
>
> The place where I see an ever-lasting factotum is when someone tries
to
> vary
> the DDLDCLOD area offline/retrieval. The system can't complete this
if
> the
> area is in-use, so the command quiesces, and the factotum task just
sits
> there
> forever waiting for the area to become free so that it can complete
its
> function.
> The DDLDCLOD area will cause this because the predefined run unit
loader
> owns it, for the life of the system. The only way to make the DCMT
VARY
> AREA
> command complete is to do a DCMT VARY RUN UNIT LOADER OFF, to
terminate
> the predefined run unit for the loader. This will then allow the area

> vary to
> complete successfully, and the factotum task will disappear.
>
> If you use PMRM, PF4 to display task info, you'll probably see the
> factotum
> task
> with the "First ECB" value of something like "DC V TSK". This lets
you
> know
> that the task is a DMCT VARY task, waiting on an event control block
to
> be
> posted so that it can continue its function.
>
> Another one you'll see like that sometimes is the HELOT task.
>
> Main Entry: hel ot
> Pronunciation: 'he-l&t
> Function: noun
> Etymology: Latin Helotes, plural, from Greek HeilOtes
> Date: 1579
> 1 capitalized : a member of a class of serfs in ancient Sparta
> 2 : SERF, SLAVE
> - hel ot ry /'he-l&-trE/ noun
>
> Someone really liked these old Latin words that nobody understands
when
> they
> wrote IDMS. <grin>
>
> John Rich
> Browning-Ferris Industries

------------------------------

Date: Thu, 12 Aug 1999 10:07:51 -0400
From: "Gene.McCormack" <Gene.Mc...@plpit.fishersci.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]rhdc0esa
Message-ID:
<8BEC761BBB76D21196D9...@exchg-pdc-plpgh.fishersci.com>

Larry, I don't see it either . It must be for 14.x. So I don't need to
worry
about it yet .

-----Original Message-----
From: Larry Yozwiak [SMTP:lyoz...@metlife.com]
Sent: Thursday, August 12, 1999 9:41 AM
To: idm...@iuassn.com

Subject: Re: [IDMS-L]rhdc0esa

Is this really a 12.01 module? I don't see it in my 9506 loadlib.

lpet...@csc.com <mailto:lpet...@csc.com> on 08/12/99 08:36:33 AM
Please respond to idm...@iuassn.com <mailto:idm...@iuassn.com>
To: idm...@iuassn.com <mailto:idm...@iuassn.com>
cc: (bcc: Larry Yozwiak/Bsg/MetLife/US)
Subject: Re: [IDMS-L]rhdc0esa

>What are the benefits of using RHDCOESA with OS390?

calls on their own. Rhdcoesa assembles those against a 4.? (4.3?) sys1

macro library. Given IBM's habit of supplying backwards compatible
software
(try that in gui land!) I suspect all rhdcoesa provides is use of new
sysplex services, maybe even hyper/data space services. But to me the
main
consideration is that if there's ever a TCC call required, they will
drop
their efforts until the correct opsys dependent module is used...you'll
get
the line 'try it this way and see if the problem occurs again'. Plus
it's
embarassing to find out the wrong opsys has been defined to the install
programs, opening the door to all kinds of speculations from
Phillistines.
Lutz Petzold

Gene.Mc...@plpit.fishersci.com
<mailto:Gene.Mc...@plpit.fishersci.com> on 08/12/99 08:08:16 AM
Please respond to idm...@iuassn.com <mailto:idm...@iuassn.com>
To: idm...@iuassn.com <mailto:idm...@iuassn.com>

cc: (bcc: Lutz H Petzold/TMG/CSC)

Subject: [IDMS-L]rhdc0esa

What are the benefits of using RHDC0ESA with OS390 in a 12.01
startup module ?

------------------------------

Date: Thu, 12 Aug 1999 15:32:26 +0100
From: peter.g...@bt.com
To: idm...@iuassn.com
Subject: RE: [IDMS-L]FACTOTUM TASK
Message-ID:
<5F54BE0116BCD2118C9...@mclmsent02.lon.bt.com>

Hi Gene, What is your set up.
What was the FACTOTUM waiting on ?
I ask because we have had FACTOTUMs ' hang around'. This was on the
UCFLINE.
The where waiting on a 'WRITE ABEND CODE OF PREVIOUS TASK' In one case
I
got round the problem by varing the UCF line offline and back on.
ALL our UCF is done using UDAS from CICS.
I do not know what online performance monitor you use. We use PMDC and
it
tells use the FACTOTUM action code' . There use to be documented in
10.2
LTEDS.
I cannot find them in 12.0 and above.
Pete

> -----Original Message-----
> From: Gene.McCormack [SMTP:Gene.Mc...@plpit.fishersci.com]
> Sent: 12 August 1999 13:21
> To: idm...@iuassn.com
> Subject: [IDMS-L]FACTOTUM TASK
>
> Could someone explain the purpose of a FACTOTUM task and what to do if
one
> stays online all day .

------------------------------

Date: Thu, 12 Aug 1999 09:01:01 -0600 (Mountain Daylight Time)
From: "bfr...@unm.edu" <bfr...@unm.edu>
To: idm...@iuassn.com
Subject: Obtaining DBNAME within ADSO
Message-ID: <Pine.WNT.3.96.9908...@bfraser.unm.edu>

Thank you all for your help. I think I have the answer. Obtaining
the DBNAME requires a CALL to either a supplied interface or a
hand written BAL CSECT.

R1 = A(passed parm data)
R8 = A(IB50)
164 = offset to VIBDBNAM
MVC 0(8,1),164(0,8)

Just kidding!

The preferred method would be a call to IDMSIN01.

------------------------------

Date: Thu, 12 Aug 1999 11:02:39 -0400
From: "Gene.McCormack" <Gene.Mc...@plpit.fishersci.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]FACTOTUM TASK
Message-ID:
<8BEC761BBB76D21196D9...@exchg-pdc-plpgh.fishersci.com>

Peter, The task was waiting on PTERM. We use CA's performance monitor .I

-----Original Message-----
From: peter.g...@bt.com [SMTP:peter.g...@bt.com]
Sent: Thursday, August 12, 1999 10:32 AM
To: idm...@iuassn.com

Subject: RE: [IDMS-L]FACTOTUM TASK

Hi Gene, What is your set up.
What was the FACTOTUM waiting on ?
I ask because we have had FACTOTUMs ' hang around'. This was on the
UCFLINE.
The where waiting on a 'WRITE ABEND CODE OF PREVIOUS TASK' In one
case I
got round the problem by varing the UCF line offline and back on.
ALL our UCF is done using UDAS from CICS.
I do not know what online performance monitor you use. We use PMDC
and it
tells use the FACTOTUM action code' . There use to be documented in
10.2
LTEDS.
I cannot find them in 12.0 and above.
Pete

------------------------------

Date: Thu, 12 Aug 1999 11:43:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: idm...@iuassn.com
Subject: RE: FACTOTUM TASK
Message-ID: <NZa71a42...@bfi.com>

Gene.McCormack:
> The (factotum) task was waiting on PTERM.

That's interesting. I've had a problem with those myself at 14.0 9810
genlevel, and have a problem open with CA about this right now. My
pterm factotum waits have been on the PTERECB, traced to IDMS querying
a 3279 terminal for extended attributes (LTE + FA = 54, LTEFAC21) and
it never gets a response back. So it just sits there, but eventually
the terminal time-out interval gets rid of it. Or you can use PMRM PF4
and overtype the "task status" field to "Cancel". I think this is an
IDMS-DC bug, but CA is not pursuing this until I can reproduce it, so
they can give me a trap to capture a dump.

The other things they had me verify on this problem was, if I had
optional PTF OPT00051 turned on, and Apar LO46070 applied. You might
check for those in your environment.

Mine look something like this when you try and research it:

DCMT DISPLAY ACTIVE TASKS

0000705863 *SYSTEM* FACTOTUM LTVT0132 251 WAIT NOST 0F03B260 PTERECB

DCMT DISPLAY LTERM LTVT0132 RESOURCES

LTERM LTVT0132 Associated with Taskid 00705863 - Request disallowed

PMRM, F7

02 Lterm Resource Usage Summary

Task Current Stor Shrd Shrd Priv Priv

Lterm_ID Code Program User_ID #RCE Below XA Below XA

LTVT0131 DBLCX14 10 0 4352 0 9984

LTVT0133 JS00050 10 0 5248 0 23kB

(No resources attached to LTVT0132)

DCMT DISPLAY LTERM LTVT0132

Physical Term Status Insrv

Logical Term Status Active

(Read and write counts do not increase - no activity)

DCMT DISPLAY TRANSACTION 705863

Transaction not found

PMRM, F4

02 Active User Task Detail

Task Task Current Link Task Ecblist
First

Number Code Program Level User_ID Lterm_ID Status Address ECB

705863 FACTOTUM FACTOTUM LTVT0132 WAIT 0F03B260
PTERM

02 Active User Task Detail < >

Task Task First Second Third Stor Shrd Shrd Priv

Number Code ECB ECB ECB #RCE Below XA Below

705863 FACTOTUM PTERM 0 0 0 0

02 Active User Task Detail <

Task Task Priv Priv Priv Pgm Pgm Pgm RU Oth

Number Code Below XA Aloc #RCE 24bit 31bit #RCE #RCE

705863 FACTOTUM 0 0 0 0 0 0 0 0

02 Active User Task Detail

Task Task Oth System User Waited_On Dbkey

Number Code #RCE Time Time Dbkey Holder

705863 FACTOTUM 0 .0001S .0000S

So the factotum references an Lterm that doesn't actually have anyone
signed on to it, and has no resources associated with it!

John Rich

------------------------------

Date: Thu, 12 Aug 1999 11:43:56 -0500
From: "Collins, John" <John.C...@ameriserve.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: FW: [IDMS-L]Obtaining DBNAME within ADSO
Message-ID: <C7C2EDD6CB94D211A0050000E866FE262DD516@dalhq50>

-----Original Message-----
From: Collins, John=20
Sent: Thursday, August 12, 1999 11:42 AM
To: 'bfr...@unm.edu'; ',idm...@iuassn.com'
Subject: RE: [IDMS-L]Obtaining DBNAME within ADSO

I thought I would resend this suggestion from yesterday. You really =
can get
the DBNAME after
dialog initiation from the ADS/O supplied reserved word DB-NAME. The =
value
can be changed with
a move statement at ADS/O runtime and interrogated at runtime. There =
is no
need to call a
system program that looks in the DSECT.

=20
Patterson, Stephanie [pat...@Jostens.com] wrote
=20

If I'm understanding your question correctly, all it takes is using a
system-supplied data field.=20

Patterson, Stephanie [pat...@Jostens.com] wrote

> -----Original Message-----
From: bfr...@unm.edu [mailto:bfr...@unm.edu]

Sent: Thursday, August 12, 1999 10:01 AM
To: idm...@iuassn.com

Subject: [IDMS-L]Obtaining DBNAME within ADSO

Thank you all for your help. I think I have the answer. Obtaining
the DBNAME requires a CALL to either a supplied interface or a
hand written BAL CSECT.

R1 =3D A(passed parm data)
R8 =3D A(IB50)
164 =3D offset to VIBDBNAM
MVC 0(8,1),164(0,8)

Just kidding!

The preferred method would be a call to IDMSIN01.=20

------------------------------

Date: Thu, 12 Aug 1999 14:07:44 -0400
From: lpet...@csc.com
To: idm...@iuassn.com
Subject: Re: FW: [IDMS-L]Obtaining DBNAME within ADSO
Message-ID: <852567CB.0...@cscmail.csc.com>

--0__=8hb3OjBxoJ4DLpD3Ck4o1KK5HBFZ68dW9XkyfleR92RlrW3Jt8ftBfSp

Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

That brings up a question in my mind. Where does ADSO get that db-name
from?
If it's from the subschema-control block, then I would take it with a
grain of
salt. I believe subschema-control shows the dbname used on the bind
statement,
but if the database name table mapping determines a name dynamically
then I
believe the new name is not stuffed into the subschema-control dbname
entry.
For ADSO that would be for dialogs generated with a dbname parameter.
However,
if that's left blank, or overriden with by dcuf set dbname then I think
it might
be incorrect. Has anyone looked into that in detail lately and have
fresh
recollections? The link to idmsin01 though obtains the dynamically
resolved
name.

Lutz Petzold

John.C...@ameriserve.com on 08/12/99 12:43:56 PM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Lutz H Petzold/TMG/CSC)

Subject: FW: [IDMS-L]Obtaining DBNAME within ADSO

-----Original Message-----
From: Collins, John
Sent: Thursday, August 12, 1999 11:42 AM
To: 'bfr...@unm.edu'; ',idm...@iuassn.com'
Subject: RE: [IDMS-L]Obtaining DBNAME within ADSO

I thought I would resend this suggestion from yesterday. You really can
get
the DBNAME after
dialog initiation from the ADS/O supplied reserved word DB-NAME. The
value
can be changed with
a move statement at ADS/O runtime and interrogated at runtime. There is
no
need to call a
system program that looks in the DSECT.

Patterson, Stephanie [pat...@Jostens.com] wrote

If I'm understanding your question correctly, all it takes is using a
system-supplied data field.

Patterson, Stephanie [pat...@Jostens.com] wrote

From R14 CD - (we did this in 10.2, then upgrade to 14.0 without making
any
changes)

11.3 System-supplied data field names

Purpose: System-supplied data field names specify variable data fields
supplied by the CA-ADS runtime system.

Syntax:

>>--------- + ------- DIRECT-DBKEY
-----------------------------------------><
+- - --+ +- DB-NAME -----------------

--0__=8hb3OjBxoJ4DLpD3Ck4o1KK5HBFZ68dW9XkyfleR92RlrW3Jt8ftBfSp

Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline

Content-transfer-encoding: quoted-printable

> -----Original Message-----
From: bfr...@unm.edu [mailto:bfr...@unm.edu]

Sent: Thursday, August 12, 1999 10:01 AM
To: idm...@iuassn.com

Subject: [IDMS-L]Obtaining DBNAME within ADSO

Thank you all for your help. I think I have the answer. Obtaining
the DBNAME requires a CALL to either a supplied interface or a
hand written BAL CSECT.

R1 =3D A(passed parm data)
R8 =3D A(IB50)
164 =3D offset to VIBDBNAM
MVC 0(8,1),164(0,8)

Just kidding!

The preferred method would be a call to IDMSIN01.

--0__=8hb3OjBxoJ4DLpD3Ck4o1KK5HBFZ68dW9XkyfleR92RlrW3Jt8ftBfSp--

------------------------------

Date: Thu, 12 Aug 1999 14:29:43 -0500
From: Kay Rozeboom <Kay.Ro...@its.state.ia.us>
To: 'IDMS-L Listserv' <idm...@iuassn.com>
Subject: SQL question
Message-ID: <78DA1160F5BDD111BCC900805F6F45A7938E04@ITS_CN_EXCHANGE>

Several weeks ago, I asked the following question:

>I have an SQL question I am hoping someone can help me with:
>For a network database, is there any way to use SQL to select records
>that do NOT belong to a set?
>
>Here is my problem: The path is REC1 -> REC2 -> REC3.
>Only REC1 has a calc key. REC2 is stored via set REC1-REC2, and REC3
is
>stored via set REC2-REC3.
>I am trying to select instances where REC1 has REC2 members, but no
REC3
>members.
>
>Search criteria WHERE "REC2-REC3" is valid syntax, but WHERE NOT
>"REC2-REC3" is not valid syntax.
>
>Has anyone else found a solution to this problem?
>

I have since worked with the CA support center on this problem. They
now agree that there currently is no solution to the problem, other than

using a table procedure. The tech rep has kindly opened a DAR for us,
requesting this functionality in a future release. Several IDMS-L'ers
responded to me that they had the same problem, but no one else has
opened a DAR on this subject. I would like to encourage anyone else who

needs a solution to this problem to open a DAR also. To make it easier,

you can refer them to ours - it is #7599871.

Strength through numbers!

------------------------------

Date: Thu, 12 Aug 1999 14:52:07 -0500
From: "Walters, NR Neal (8377)" <Walt...@gvl.esys.com>
To: "'rpi...@mge.com'" <rpi...@mge.com>,
"'IDM...@iuassn.com'"
<IDM...@iuassn.com>

Subject: RE: [IDMS-L]New area or sub-area
Message-ID:

<9D198A0A726AD211BD1...@gvlmail1.gvl.esys.com>

Last year, I split dozens of indexes out of data areas into separate
index areas, and in the process developed some COBOL code that reads
COBOL
source code from Panvalet and generates Panvalet update statements to
add
the new READY AREA statements to the existing programs. Then, with
management's approval, we handed that off to the production control
group,
and they applied it and did recompiles in place. This saved hundreds of

man-hours in manual fixes and testing! Email me directly if you need
something like that.

One of my future utilities of the month at my web site below will
show
how to read Panvalet members from a COBOL program and how to perform
more
sophisticated searches than what Panvalet alone provides. Signup for
free
subscription by sending
email:util...@itdoesmorestuff.com?subject=SUBSCRIBE UTILITIES

Neal Walters
http://ItDoesMoreStuff.com - Web site dedicated to IDMS and IDMS
Training

> ----------
> From: rpi...@mge.com[SMTP:rpi...@mge.com]
> Sent: Wednesday, August 11, 1999 1:05 PM

> To: IDM...@iuassn.com
> Subject: [IDMS-L]New area or sub-area
>
> Hi all -
>
> I have an area that needs to be split (segmented). Does anyone have
any
> "feelings" as to wether to split the area into 2 sub-areas
(symbolics), or
> split the area into 2 physical areas.
>
> The re-org to do the split should take ~ 6 hours.
>
> Thanks in advance
>
> 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
>
************************************************************************

>
>

------------------------------

Date: Thu, 12 Aug 1999 15:46:29 -0400
From: "Collins, John" <John.C...@ameriserve.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: FW: [IDMS-L]Obtaining DBNAME within ADSO
Message-ID: <C7C2EDD6CB94D211A0050000E866FE262DD518@dalhq50>

I just tested this on R12.01 tape 9506.

There is no explicit BIND RUN-UNIT coded in a dialog process. The BIND
RUN-UNIT occurs at ADS/O
run-time behind the scenes.

1) If the DBNAME is set by DCUF SET DBNAME dbn1234, the dialog has
dbn1234
as the value in field DB-NAME.

2) Also, if the DBNAME is set at run-time by entering ADS 'dialog name'
DBN=dbn1234, the dialog has dbn1234 as the value in field DB-NAME.

3) HOWEVER, if the DBNAME is set by the default database name table, the

value in DB-NAME is SPACES.

I had forgotten that the name is not moved in if the default database
name
table is used. I

-----Original Message-----
From: lpet...@csc.com [mailto:lpet...@csc.com]
Sent: Thursday, August 12, 1999 1:08 PM
To: idm...@iuassn.com

Subject: Re: FW: [IDMS-L]Obtaining DBNAME within ADSO

That brings up a question in my mind. Where does ADSO get that db-name
from?
If it's from the subschema-control block, then I would take it with a
grain
of
salt. I believe subschema-control shows the dbname used on the bind
statement,
but if the database name table mapping determines a name dynamically
then I
believe the new name is not stuffed into the subschema-control dbname
entry.
For ADSO that would be for dialogs generated with a dbname parameter.
However,
if that's left blank, or overriden with by dcuf set dbname then I think
it
might
be incorrect. Has anyone looked into that in detail lately and have
fresh
recollections? The link to idmsin01 though obtains the dynamically
resolved
name.

Lutz Petzold

John.C...@ameriserve.com on 08/12/99 12:43:56 PM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Lutz H Petzold/TMG/CSC)

Subject: FW: [IDMS-L]Obtaining DBNAME within ADSO

-----Original Message-----
From: Collins, John
Sent: Thursday, August 12, 1999 11:42 AM
To: 'bfr...@unm.edu'; ',idm...@iuassn.com'
Subject: RE: [IDMS-L]Obtaining DBNAME within ADSO

Patterson, Stephanie [pat...@Jostens.com] wrote

If I'm understanding your question correctly, all it takes is using a
system-supplied data field.

Patterson, Stephanie [pat...@Jostens.com] wrote

From R14 CD - (we did this in 10.2, then upgrade to 14.0 without making
any
changes)

11.3 System-supplied data field names

Purpose: System-supplied data field names specify variable data fields
supplied by the CA-ADS runtime system.

Syntax:

>>--------- + ------- DIRECT-DBKEY
-----------------------------------------><
+- - --+ +- DB-NAME -----------------

------------------------------

Date: Thu, 12 Aug 1999 14:32:58 +0000
From: Javier Sotela M <jso...@ice.go.cr>

To: IDM...@IUASSN.COM
Subject: Idms jounal block size?????

Message-ID: <37B2DB...@ns.ice.go.cr>

Thanks to all for the tips. My real problem is that I want to put the
maximum of information on every tape when offload the journal. The
trade-off its especifically focuns on risk on disk, warmstart time, time

for offload. Nevertheles there is not a magic response to my question
and depend of the installation. I will test where a big journals. Thanks

for the answers.

Javier Sotela

------------------------------

Date: Thu, 12 Aug 1999 14:42:21 +0000
From: Javier Sotela M <jso...@ice.go.cr>
To: IDM...@IUASSN.COM
Subject: The future of IDMS !!!
Message-ID: <37B2DD...@ns.ice.go.cr>

I know that is a difficult question, but I want to know what thew people

that work with IDMS think about the future with IDMS. More especific
question is how to respond to a managers who think that IDMS is dying?
What are the people doing, migrating, keep IDMS like a Database server,
using client/server solution combining different environment ?? Are the
companies happies with IDMS?
You can answer to the IDMS-L population or if you prefer you can send me

a email to Jso...@ice.go.cr

Javier Sotela

------------------------------

Date: Thu, 12 Aug 1999 17:07:17 -0400

From: "David R Slocum" <drsl...@cmsenergy.com>

To: jso...@ice.go.cr, idm...@iuassn.com
Subject: Re: [IDMS-L]The future of IDMS !!!
Message-ID: <852567CB.0...@pr1lns45.cpco.com>

As of a few years ago, DB2 is our corporate standard for mainframe
database
applications (it used to be IDMS). We have a number of large,
mission-critical
applications on IDMS. A couple of these applications are constantly
undergoing
changes, but the general trend is that IDMS applications are in a
"maintenance
only" mode. I have seen pieces of these applications replaced by newer
systems
running on DB2, Oracle, or some other platform. I wouldn't be at all
surprised
to see IDMS disappear from our shop completely in the next ten years or
so, but
it's not going to happen overnight. CA hasn't helped matters any with
their
steep upgrade fees for people that are looking to add just a few more
MIPS to
their mainframe. If it were doable, our management would have us
replace all CA
products with comparable products from other vendors so that we could
avoid more
than doubling our license fees in the next couple of years.
Unfortunately, CA
has their fingers in too many pieces of the pie (ACF2, CA-7, CA-1,
PANVALET,
IDMS, etc.). So, for now, we're stuck.

DISCLAIMER: The views expressed in this note aren't necessarily those of
the
company.

David R. Slocum
Consumers Energy

Javier Sotela M <jso...@ice.go.cr> on 08/12/99 10:42:21 AM

Please respond to jso...@ice.go.cr; Please respond to idm...@iuassn.com

To: IDM...@iuassn.com

cc: (bcc: David R Slocum/Pr/Consumers/CMS)

Subject: [IDMS-L]The future of IDMS !!!

I know that is a difficult question, but I want to know what thew people

a email to Jso...@ice.go.cr

Javier Sotela

------------------------------

Date: Thu, 12 Aug 1999 17:30:18 -0400
From: "Govan Jr, Harold M." <Harold...@lexis-nexis.com>
To: jso...@ice.go.cr, "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]The future of IDMS !!!
Message-ID:
<374D007526C7D111B42A...@lnxdayexch01.lexis-nexis.com>

Like David, our shop is in maintenance-only mode on IDMS. We are using

Oracle nad Micrsoft SQL Server for new applications.

Our management is also digusted with CA's money gouging and will replace

their products wherever possible.

> ----------
> From: David R Slocum[SMTP:drsl...@cmsenergy.com]

> Sent: Thursday, August 12, 1999 5:07 PM
> To: jso...@ice.go.cr; idm...@iuassn.com
> Subject: Re: [IDMS-L]The future of IDMS !!!
>
> As of a few years ago, DB2 is our corporate standard for mainframe
> database
> applications (it used to be IDMS). We have a number of large,
> mission-critical
> applications on IDMS. A couple of these applications are constantly
> undergoing
> changes, but the general trend is that IDMS applications are in a
> "maintenance
> only" mode. I have seen pieces of these applications replaced by
newer
> systems
> running on DB2, Oracle, or some other platform. I wouldn't be at all
> surprised
> to see IDMS disappear from our shop completely in the next ten years
or
> so, but
> it's not going to happen overnight. CA hasn't helped matters any with

> their
> steep upgrade fees for people that are looking to add just a few more
MIPS
> to
> their mainframe. If it were doable, our management would have us
replace
> all CA
> products with comparable products from other vendors so that we could
> avoid more
> than doubling our license fees in the next couple of years.
> Unfortunately, CA
> has their fingers in too many pieces of the pie (ACF2, CA-7, CA-1,
> PANVALET,
> IDMS, etc.). So, for now, we're stuck.

>
> DISCLAIMER: The views expressed in this note aren't necessarily those
of
> the
> company.
>
> David R. Slocum
> Consumers Energy
>
>
>
>
>

> Javier Sotela M <jso...@ice.go.cr> on 08/12/99 10:42:21 AM
>
> Please respond to jso...@ice.go.cr; Please respond to
idm...@iuassn.com
>
> To: IDM...@iuassn.com

> cc: (bcc: David R Slocum/Pr/Consumers/CMS)

> Subject: [IDMS-L]The future of IDMS !!!
>
>
>
>
> I know that is a difficult question, but I want to know what thew
people
> that work with IDMS think about the future with IDMS. More especific
> question is how to respond to a managers who think that IDMS is dying?

> What are the people doing, migrating, keep IDMS like a Database
server,
> using client/server solution combining different environment ?? Are
the
> companies happies with IDMS?
> You can answer to the IDMS-L population or if you prefer you can send
me
> a email to Jso...@ice.go.cr
>
> Javier Sotela
>
>
>
>
>
>

------------------------------

Date: Thu, 12 Aug 1999 14:31:08 -0700
From: "Otani, Janice R" <Otani....@PSS.Boeing.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: [IDMS-L]The future of IDMS !!!
Message-ID:
<E1B236602CA5D011B7CF...@xch-sea-08.ca.boeing.com>

After reading David Slocum's response ...
My company has a very similar outlook on CA's steep pricing policy. The
company has been on a campaign to replace CA products with anything else
that will provide the same or similar functionality. We have gotten
pressure in the last year (plus) to look into alternatives (DB2 has been
mentioned as well as Oracle). We have resisted so far but I'm not sure
how long we can hold out.

It's not that we are not open to new solutions. We have a complex data
structure and application software that have been in place for a number
of years. The performance of the system and application software have
years of tuning and the customers have gotten used to this level of
performance (and uptime). My group has also been extremely downsized so
a conversion effort would put us under. I predict that in the next 5-10
years we will move on to something else. Some part of the company will
buck up the money to get us out of the CA product arena.

These are my views, not the companies ... blah, blah, blah.

------------------------------

Date: Thu, 12 Aug 1999 09:15:37 -0400
From: "James Ritterbusch" <james.ri...@prudential.com>
To: idm...@iuassn.com
Subject: RE: [IDMS-L]FACTOTUM TASK
Message-ID: <852567CB.0...@njros1ngw09.metro.prudential.com>

David,

Thanks for your explanation.

While I agree that it's about impossible to cancel a HELOT, I had always
been
taught (perhaps incorrectly) that if a FACTOTUM is hanging around for
hours and
apparently not doing any useful work, that canceling it is the correct
action.
This can easily be done in the PMRM Active User Task Detail screen. Is
this not
correct? We get these maybe once or twice a month.

Jim Ritterbusch
Prudential Real Estate and Relocation Services

"Lorenzen, David C" <david.l...@eds.com>
Thursday August 12, 1999 08:41 AM

Please respond to idm...@iuassn.com
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
cc: (bcc: James Ritterbusch/DG/Prudential)
Subject: RE: [IDMS-L]FACTOTUM TASK

Gene,

Hope this helps.
David Lorenzen
EDS

------------------------------

Date: Thu, 12 Aug 1999 13:56:15 -0400
From: lpet...@csc.com
To: idm...@iuassn.com
Subject: Re: [IDMS-L]RE: FACTOTUM TASK
Message-ID: <852567CB.0...@cscmail.csc.com>

That's interesting to me also. One system is at 14.0 9711 and I've seen
like a
half dozen tasks wait on pterecb at a time, including some factotums.
That
system does have OPT0051 applied but not LO46070. This only happened on
one
afternoon though and I chalked it up to communications problems since
there was
a problem with a 317x cluster controller.

John...@bfi.com on 08/12/99 12:43:00 PM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Lutz H Petzold/TMG/CSC)

Subject: [IDMS-L]RE: FACTOTUM TASK

Gene.McCormack:
> The (factotum) task was waiting on PTERM.

The other things they had me verify on this problem was, if I had
optional PTF OPT00051 turned on, and Apar LO46070 applied. You might
check for those in your environment.

Mine look something like this when you try and research it:

DCMT DISPLAY ACTIVE TASKS

0000705863 *SYSTEM* FACTOTUM LTVT0132 251 WAIT NOST 0F03B260 PTERECB

DCMT DISPLAY LTERM LTVT0132 RESOURCES

LTERM LTVT0132 Associated with Taskid 00705863 - Request disallowed

PMRM, F7

02 Lterm Resource Usage Summary

Task Current Stor Shrd Shrd Priv Priv

Lterm_ID Code Program User_ID #RCE Below XA Below XA

LTVT0131 DBLCX14 10 0 4352 0 9984

LTVT0133 JS00050 10 0 5248 0 23kB

(No resources attached to LTVT0132)

DCMT DISPLAY LTERM LTVT0132

Physical Term Status Insrv

Logical Term Status Active

(Read and write counts do not increase - no activity)

DCMT DISPLAY TRANSACTION 705863

Transaction not found

PMRM, F4

02 Active User Task Detail

Task Task Current Link Task Ecblist
First

Number Code Program Level User_ID Lterm_ID Status Address ECB

705863 FACTOTUM FACTOTUM LTVT0132 WAIT 0F03B260
PTERM

02 Active User Task Detail < >

Task Task First Second Third Stor Shrd Shrd Priv

Number Code ECB ECB ECB #RCE Below XA Below

705863 FACTOTUM PTERM 0 0 0 0

02 Active User Task Detail <

Task Task Priv Priv Priv Pgm Pgm Pgm RU Oth

Number Code Below XA Aloc #RCE 24bit 31bit #RCE #RCE

705863 FACTOTUM 0 0 0 0 0 0 0 0

02 Active User Task Detail

Task Task Oth System User Waited_On Dbkey

Number Code #RCE Time Time Dbkey Holder

705863 FACTOTUM 0 .0001S .0000S

So the factotum references an Lterm that doesn't actually have anyone
signed on to it, and has no resources associated with it!

John Rich

------------------------------

Date: Thu, 12 Aug 1999 15:49:44 -0600
From: "Wood, Chris" <Chris...@gov.ab.ca>
To: IDM...@iuassn.com
Subject: RE: [IDMS-L]The future of IDMS !!!
Message-ID:
<709658908B3FD311B3A...@eoaexc01.enr.gov.ab.ca>

Hi,

We have been using IDMS for close to 18 years and should still be using
it
for another 5 or so. I am not involved with the pricing issue but I see
IDMS's biggest problem being the lack of people who can write ADS/O and
who
want to write ADS/O. Whenever we issue a new contract for a programmer
for
our IDMS system's it gets harder to find anyone. I attended the IUA
conference in Cleveland and saw mainly 40+ people there. We can keep
working
for another 20 years but who replaces us? Our systems will work for that

long but who will maintain them?

As with other responses this is my take on it and mine alone!

Chris Wood
Alberta Department of Resource Development
CANADA

PS Hope I didn't offend anybody

-----Original Message-----
From: Javier Sotela M [mailto:jso...@ice.go.cr]
Sent: August 12, 1999 8:42 AM
To: IDM...@iuassn.com

Subject: [IDMS-L]The future of IDMS !!!

I know that is a difficult question, but I want to know what thew people

a email to Jso...@ice.go.cr

Javier Sotela

------------------------------

Date: Thu, 12 Aug 1999 17:47:48 -0700
From: "Steven Bertrand" <Stev...@fox.com>
To: IDM...@iuassn.com
Subject: Smp/E question
Message-ID: <s7b308...@foxinc.com>

Hey group:=20
As you all probably noticed a few years ago=20
on the 9601 tape (12.01 maintenance) C.A quit giving=20
out their fixes as APARS and have gone to full module=20
replacement via relfiles. =20
This raises a question on the SMP/E accept function.=20
in the olde days you would never do a SMP/E accept on a=20
maintenance tape because it was mostly impossible to=20
restore a APAR once it was accepted and you could=20
never trust CA not to screw up something in SMP/E and=20
require that you restore some APAR you previously applied.
(of course a DBA would never be responsible for said screw-up)=20
How does this "new" technique effect the decision whether or not to =
execute the SMP/E accept function?=20
(I know, I know, I am one of the few people in the=20
world this is new to. If you recall from my last message I have not =
touched an IDMS system in the last 3 years). =20

Thanks in advance for you kind attention
Steven B.=20

P.S. Thanks to Kay Rozeboom for the tip on routing idmsl message to=20
a special folder, although I am using GroupWise not outlook, her message

gave me the clue I needed to figure out how to do it.

P.P.S.S.=20
Also thanks to all to responded to my last message about upgrading=20
to 14.0 versus applying maintenance to 12.01=20
We have decided to stay with 12.01 and I am in the process of=20
applying maintenance tapes 9506 thru 9707 =20
ergo the new question.=20

------------------------------

Date: Thu, 12 Aug 1999 20:33:20 -0500
From: Chris Hoelscher <hoel...@flash.net>
To: idm...@iuassn.com
Subject: Re: [IDMS-L]Smp/E question
Message-ID: <1999081301...@bunyip.flash.net>

At Thursday 1999/08/12 05:47 PM -0700, you wrote:
>How does this "new" technique effect the decision whether or not to
execute the SMP/E accept function?

the safest procedure is: immediately before you accept; backup EVERY
dataset remotely connected to SMP/E. that way, you can perform an ACCEPT

will full confidence; if you NEED to unaccept, you can do so with a
utility
RESTORE. one can NEVER have too many backups when dealing w/SMPE

(ps - for those in the southwest US, I will be presenting a class on
effective usage of SMP & IDMS at the IUA/DCUF Regional Education
Conference; Sep 15-16 in Dallas Texas!

chris hoelscher

------------------------------

Date: Fri, 13 Aug 1999 10:53:36 +0200 (MET DST)
From: Aaron Mortensen <aaro...@online.no>
To: idm...@iuassn.com
Subject: Re: Re: [IDMS-L]The future of IDMS !!!
Message-ID: <18362878.9345344151...@mail.online.no>

Future of IDMS! The question should be rephrased as "Why IDMS is still
alive even though the vendor has pulled the plug and the media had
predicted its demise long ago?"

The product has surived purely on its merit and strength. It's like some

old people living based on the strength of their younger days. They
simply don't get heart-attack! Part of the body can be dead. Still no
heart failure. IDMS is like an old man with a strong heart.

In the late eighties many were talking about Client-Server, UNIX etc.
and even said because of all these (besides DB2) IDMS has to fall. But
then how do you explain the fall of UNIX companies like Informix and
Sybase and even the VX vendor Digital? Many UNIX and PC products and
companies have also collapsed. Today we hear peple converting from DB2
to Oracle. And SAP is all over the picture.

One has to explain why substanardard products make it in the big
marketplace whereas the technically sound products fail.

The vendor (CA) believed that IDMS revenue would dry out by 1995. The
positioning was only up to then. Now they open their eyes and see that
product is not dead and even bringing them more revenue than before in
many cases. The product is positioned very badly with the management at
most sites. CA salespeople have tried to convert IDMS client base to
Ingres with no success. Now with DB2 tools in the pocket they will be
even happy to see the client go for DB2. CA is a company who wants to
make money by selling non-strategic housekeeping tools which need very
little support. Database is not one of them. Database needs maintenance,

continuity and 24 hours availability and so support. Application
Development needs even more.

Many European countries do not have a single IDMS technican in CA. Even
the very few left are doing marketing job. At many sites the product is
there only because the clients' attempt to convert to
DB2,Oracle,informix,you-name-it failed or was miserably delayed. As the
newsletters indicate courses are withdrawn even in Westwood! Let the
consulting companies and independent freelancers give the courses.

A client cannot depend on the expertise of independent ex-CA people
alone, however good they are. The technicans at the clients may be happy

with such bit level support such as the help coming through IDMS-L. But
the new young management who does not know the history of mainframe or
mainframe databases at the clients take decisions based on the vendors
positioning only. Today that is bad or even worse non-existent.

AS I said earlier the product would have been dead long back but for the

failure of conversions and migrations!

A.Mortenson,
Stavanger,
Norway

> Javier Sotela M <jso...@ice.go.cr> on 08/12/99 10:42:21 AM
>
> Please respond to jso...@ice.go.cr; Please respond to
idm...@iuassn.com
>
> To: IDM...@iuassn.com

> cc: (bcc: David R Slocum/Pr/Consumers/CMS)

------------------------------

End of IDMS-L V1 #54
********************

0 new messages