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

Dismiss

Daily Listing of IDMS-L

628 views

Skip to first unread message

Chris Hoelscher

unread,

Jul 30, 1999, 3:00:00 AM7/30/99

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

IDMS-L Tue, 27 Jul 1999 Volume 1 :
Number 37

In this issue:

RE: New DBA needs help with maintaining and optimizing indexes
FW: Managing IDMS
IDMS/CICS cobol pgms abend with 1477 on 1st dml statement
DBAN on dict files
Re: DBAN on dict files
Re: IDMS/CICS cobol pgms abend with 1477 on 1st dml statement
RE: DBAN on dict files
RE: New DBA needs help with maintaining and optimizing indexes
RE: DBAN on dict files
RE: SYSMSG
FW: Implementing IDMSINTL
RE: DBAN on dict files
Re: IDMS/CICS cobol pgms abend with 1477 on 1st dml statemen
Maintain Index
RE: SYSMSG
1477
Re: Maintain Index
os/390 ZEKE scheduler
os/390 ZEKE scheduler (A)

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

Date: Mon, 26 Jul 1999 10:49:08 -0400
From: "Gardner, Michael" <Michael...@fns.usda.gov>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: New DBA needs help with maintaining and optimizing indexes
Message-ID:
<C1D845867A7ED211A0D...@199.136.154.fns.usda.gov>

Mr. Lorenzen;

I would appreciate it very much.

Sincerely,
Michael

-----Original Message-----
From: Lorenzen, David C [mailto:david.l...@eds.com]
Sent: Monday, July 26, 1999 10:42 AM
To: 'idm...@iuassn.com'
Subject: RE: New DBA needs help with maintaining and optimizing indexes

Michael,

The current process we use includes an assembler module to
extract the output of the BCR Index report. This could be converted
to COBOL, or I can include the assembler program. Some shops
do not like assembler. The process is a three step process.

Step 1: BCF index report
Step 2: Assembler extract
Step 3: Culprit to report the index levels

Would you still like this process?

Dave.

> ----------
> From: Michael Gardner
> Sent: Monday, July 26, 1999 9:33 AM
> To: idm...@iuassn.com
> Subject: RE: New DBA needs help with maintaining and optimizing
> indexes
>
> Mr. Lorenzen;
>
> I would be very interested in receiving the source and jobflow, if the

> offer
> is still open. Thank you in advance.
>
> Sincerely,
> Michael Gardner
>
>
> >From: "Lorenzen, David C" <david.l...@eds.com>
> >Reply-To: idm...@iuassn.com
> >To: "'idm...@iuassn.com'" <idm...@iuassn.com>
> >Subject: RE: New DBA needs help with maintaining and optimizing
indexes
> >Date: Tue, 22 Jun 1999 11:49:11 -0500
> >
> >IUA - The CA-IDMS Database and Applications User Association
> >Michael,
> >
> > There are a few ways. I have written several programs,
> >in Cobol, SAS Culprit and Dyl/280 (my gosh, I'm giving my age away
here),
> >to interrogate the output of Print Index and report the orphans in
> >a format that was conducive to us. In fact currently we use Culprit.
> >I could send you the source and jobflow if your interested.
> >
> >David Lorenzen
> >EDS
> >
> > > ----------
> > > From: Michael Gardner
> > > Sent: Tuesday, June 22, 1999 10:20 AM
> > > To: idm...@iuassn.com
> > > Subject: New DBA needs help with maintaining and optimizing
indexes
> > >
> > > IUA - The CA-IDMS Database and Applications User Association
> > > Hello to all,
> > >
> > > I am a new IDMS DBA and would appreciate any help the group can
give.
> > >
> > > I need to evaluate all indexed sets in a particular dictionary to
> > > determine
> > > the percentage of orphans and the number of levels in the sets.
> > >
> > > I have used DBAN report 5, which didn't yield the results that I
> wanted.
> > > I have also used PRINT INDEX which produces voluminous output,
> > > 2,956,803 lines to be precise.
> > >
> > > If anyone has advice on how to use either of these utilities more
> > > efficiently
> > > or have in their possession some software, preferable free, that
can
> > > reduce
> > > the mountains of output into something a novice can more easily
> >understand
> > > I would be grateful.
> > >
> > > Thank you in advance for your assistance.
> > >
> > > Michael Gardner
> > >
> > >
> > > _______________________________________________________________
> > > Get Free Email and Do More On The Web. Visit http://www.msn.com
> > > Visit the IUA at IMC at CA-WORLD 1999 - see us outside the TECH
> >CAMPGROUND
> > >
> >Visit the IUA at IMC at CA-WORLD 1999 - see us outside the TECH
> CAMPGROUND
>
>
> _______________________________________________________________
> Get Free Email and Do More On The Web. Visit http://www.msn.com
>

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

Date: Mon, 26 Jul 1999 11:24:58 -0500
From: "Hynes, Carol" <HYN...@dwd.state.wi.us>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: FW: Managing IDMS
Message-ID:
<6929EAD56AF6D2118C7...@aspxchg4.DWD.STATE.WI.US>

My name is Carol Hynes, I'm the lead DBA with the Department of
Workforce Development for the State of Wisconsin. We have been an IDMS
shop
since the late 70s. We evaluated IDMS performance monitors, in 1992.
We
looked at PMDC, CA-Perfmon and Pre-Alert. We selected PMDC from
International Software Products. This tool has been wonderful. We use
the
alert feature to trap programs with excessive locks and abend the
rununit
before the CV is completely locked up. Before PMDC, we'd loose a CV
about
once a month to programs with no commit logic. We also abend CICS
transactions for excessive CPU usage. I especially like being able to
view
my systems from outside the CV address space and cancel run units
causing a
problem. We enter UCF thru a CICS front-end. We've had occasions when
the
CICS region has gotten so backed up by an IDMS problem, that we would
not
have been able to get into the IDMS address space. Using the external
capabilities, we were able to go in and cancel the rununits causing the
problem and free up both IDMS and CICS. Another great feature of PMDC
is
that in the event the CV does crash, PMDC takes a snap shot of all the
control blocks and puts it in a vsam file. You can then run a batch
job
that points to the VSAM file and use a VTAM applid to access your
abended CV
as if it were still active. This lets you step thru the monitor screens
and
do things like: check what tasks were active; what the last 8 verbs for
those tasks were; what your storage pools look like; and, basically
examine
any part of the storage you'd like to look at. PMDC will write your
statistics to SMF and provides a multitude of easy to run SAS reports.

If you have any questions and would like to contact me, you can email me
at
carol...@dwd.state.wi.us or phone me at 608-266-3526.

> -----Original Message-----
> From: Jim Phillips [SMTP:jimphi...@hotmail.com]
> Sent: Wednesday, July 21, 1999 1:32 PM
> To: carol...@dwd.state.wi.us
> Subject: Fwd: Managing IDMS
>
>
>
>
> >From: Will Hathcock <Will.H...@wcom.com>
> >Reply-To: idm...@iuassn.com
> >To: IDMS Group list <idm...@iuassn.com>
> >Subject: Managing IDMS
> >Date: Fri, 16 Jul 1999 08:41 -0600 (MDT)
> >
> >I have recently returned to the IDMS environment and have inherited
> >an IDMS system. It has been a few years and I would like to get some
> >opinions
> >on software to manage IDMS. Specifically I am looking for
recommendations
> >on Performance Monitor, Reorg software, managing data and structures.

> >I am interested in any other IDMS software to help a small group do
> >more with less people. You can reply directly if you wish and I will
> >put together a list with the products and number of responses. I
there
> >is interest, I will send this back out to the IDMS community.
> >No names will be attached, so it will be totally anonymous. I would
like
> >responses soon as I need to make some decisions next week.
> >
> >Thanks,
> >
> >Will..
>
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

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

Date: Mon, 26 Jul 1999 13:16:31 -0400
From: "Locke, Don" <Loc...@simplexnet.com>
To: 'IDMS-L' <IDM...@IUASSN.COM>
Subject: IDMS/CICS cobol pgms abend with 1477 on 1st dml statement
Message-ID: <C384780A25ECD211994B0060B0675B3F0E9A4C@STR_MAIL3>

Our IDMS/CICS cobol pgms abend with 1477 on 1st dml statement (bind
rununit).
We are trying to upgrade from S10213 to 14.0 (B9711), also CICS 2.3 to
4.1.
We are using the regular CICS interface (IDMSCINT/IDMSINTC).
The cics front-end works ok with UCFCICS for the ADSO.
The cics cobol pgms have been recompiled (vscobol), using the new
libraries
(IDMS 14.0 & CICS 4.1).
Any suggestions will be greatly appreciated. (apologies if duplicate
msg,
had a netwwork problem)

Thanks,

Don

Don Locke
Simplex Time Recorder Co.
Tel. (978) 874-8678
Email: loc...@simplexnet.com

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

Date: Mon, 26 Jul 1999 11:16:15 -0600
From: "Wood, Chris" <Chris...@gov.ab.ca>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: DBAN on dict files
Message-ID:
<709658908B3FD311B3A...@eoaexc01.enr.gov.ab.ca>

Hi,

We may have a corrupt IDD due to a series of power failures with no UPS
on
our system. What subschema or subschemas should we be using in the dban
or
dban's?

Thanks

Chris Wood
Alberta Department of Resource Development
CANADA

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

Date: Mon, 26 Jul 1999 13:36:12 -0400
From: Alan_...@vfc.com
To: idm...@iuassn.com
Subject: Re: DBAN on dict files
Message-ID: <852567BA.0...@itxf2aln09.vfc.com>

For DBAN's on your dictionary, use subschema IDMSNWKG and specifiy areas
DDLDML,
DDLDCLOD, and DDLDCMSG.

Alan Fields
VF Jeanswear
Greensboro, NC
336-332-5631
Alan_...@vfc.com

P.S. Dumb question: Why were you updating your dictionaries in local
mode??

Hi,

We may have a corrupt IDD due to a series of power failures with no UPS
on
our system. What subschema or subschemas should we be using in the dban
or
dban's?

Thanks

Chris Wood
Alberta Department of Resource Development
CANADA

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

Date: Mon, 26 Jul 1999 13:46:27 -0400
From: Alan_...@vfc.com
To: idm...@iuassn.com
Subject: Re: IDMS/CICS cobol pgms abend with 1477 on 1st dml statement
Message-ID: <852567BA.0...@itxf2aln09.vfc.com>

Don --

You get a 1477 anytime you try to do a DML call when you're not yet
bound or a
BIND when you already are bound. Perhaps these programs have been
bound, didn't
FINISH and are trying to BIND for the second time?? The one other
possibility
(remote) is that the subschema as represented in storage has been
trashed.

Hope this helps.

Alan Fields
VF Jeanswear
Greensboro, NC
336-332-5631
Alan_...@vfc.com
___________________________________________________________

Thanks,

Don

Don Locke
Simplex Time Recorder Co.
Tel. (978) 874-8678
Email: loc...@simplexnet.com

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

Date: Mon, 26 Jul 1999 13:50:50 -0400
From: "Stritzinger, David" <Stritz...@nabisco.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: DBAN on dict files
Message-ID:
<D06CFFEA1840D211BF0300805F9A23250108FB1D@NS_MSG_WB.nabisco.com>

I would start with running an IDMSLOOK with the subschema options
for the IDMSNWK* subschemas. This output will tell you which areas are
in
which subschema. I assume that you are on 12 or 14. Then with the DBAN's
you
can tell which DBNAME to use so that you can check the "primary" and all
the
secondary dicts. Looking at my output, looks like IDMSNWKG has the
DDLCat,
DDLCatx, DDLLOD,DDLMSG, and DDLDML. IDMSNWK7 has the DDDDCRUN and
IDMSNWK*
has the DDLDCLOG, IDMSCATL has the DDLCATLOD area. I think you can get
all
of your areas with these four. Of course if you have the SQL option, I
am
not sure if there is any other areas or not.

Dave S.
PS Your milage may vary...

> -----Original Message-----
> From: Wood, Chris [SMTP:Chris...@gov.ab.ca]
> Sent: Monday, July 26, 1999 1:16 PM
> To: 'idm...@iuassn.com'
> Subject: DBAN on dict files
>
> Hi,
>
> We may have a corrupt IDD due to a series of power failures with no
UPS on
> our system. What subschema or subschemas should we be using in the
dban or
> dban's?
>
> Thanks
>
> Chris Wood
> Alberta Department of Resource Development
> CANADA

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

Date: Mon, 26 Jul 1999 12:53:16 -0500
From: "Lorenzen, David C" <david.l...@eds.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: New DBA needs help with maintaining and optimizing indexes
Message-ID: <B9CB0C7E771ED2119FA400A02461EE240325E802@USPLM206>

Michael,
Please e-mail me directly and not through the list so I can send
you the information.

Dave.

> ----------
> From: Gardner, Michael
> Sent: Monday, July 26, 1999 9:49 AM
> To: 'idm...@iuassn.com'
> Subject: RE: New DBA needs help with maintaining and optimizing
> indexes
>
> Mr. Lorenzen;
>
> I would appreciate it very much.
>
> Sincerely,
> Michael
>
> -----Original Message-----
> From: Lorenzen, David C [mailto:david.l...@eds.com]
> Sent: Monday, July 26, 1999 10:42 AM
> To: 'idm...@iuassn.com'
> Subject: RE: New DBA needs help with maintaining and optimizing
indexes
>
>
> Michael,
>
> The current process we use includes an assembler module to
> extract the output of the BCR Index report. This could be converted
> to COBOL, or I can include the assembler program. Some shops
> do not like assembler. The process is a three step process.
>
> Step 1: BCF index report
> Step 2: Assembler extract
> Step 3: Culprit to report the index levels
>
> Would you still like this process?
>
> Dave.
>
>
> > ----------
> > From: Michael Gardner
> > Sent: Monday, July 26, 1999 9:33 AM
> > To: idm...@iuassn.com
> > Subject: RE: New DBA needs help with maintaining and optimizing
> > indexes
> >
> > Mr. Lorenzen;
> >
> > I would be very interested in receiving the source and jobflow, if
the
> > offer
> > is still open. Thank you in advance.
> >
> > Sincerely,
> > Michael Gardner
> >
> >
> > >From: "Lorenzen, David C" <david.l...@eds.com>
> > >Reply-To: idm...@iuassn.com
> > >To: "'idm...@iuassn.com'" <idm...@iuassn.com>
> > >Subject: RE: New DBA needs help with maintaining and optimizing
indexes
> > >Date: Tue, 22 Jun 1999 11:49:11 -0500
> > >
> > >IUA - The CA-IDMS Database and Applications User Association
> > >Michael,
> > >
> > > There are a few ways. I have written several programs,
> > >in Cobol, SAS Culprit and Dyl/280 (my gosh, I'm giving my age away
> here),
> > >to interrogate the output of Print Index and report the orphans in
> > >a format that was conducive to us. In fact currently we use
Culprit.
> > >I could send you the source and jobflow if your interested.
> > >
> > >David Lorenzen
> > >EDS
> > >
> > > > ----------
> > > > From: Michael Gardner
> > > > Sent: Tuesday, June 22, 1999 10:20 AM
> > > > To: idm...@iuassn.com
> > > > Subject: New DBA needs help with maintaining and optimizing
> indexes
> > > >
> > > > IUA - The CA-IDMS Database and Applications User Association
> > > > Hello to all,
> > > >
> > > > I am a new IDMS DBA and would appreciate any help the group can
> give.
> > > >
> > > > I need to evaluate all indexed sets in a particular dictionary
to
> > > > determine
> > > > the percentage of orphans and the number of levels in the sets.
> > > >
> > > > I have used DBAN report 5, which didn't yield the results that I

> > wanted.
> > > > I have also used PRINT INDEX which produces voluminous output,
> > > > 2,956,803 lines to be precise.
> > > >
> > > > If anyone has advice on how to use either of these utilities
more
> > > > efficiently
> > > > or have in their possession some software, preferable free, that
can
> > > > reduce
> > > > the mountains of output into something a novice can more easily
> > >understand
> > > > I would be grateful.
> > > >
> > > > Thank you in advance for your assistance.
> > > >
> > > > Michael Gardner
> > > >
> > > >
> > > > _______________________________________________________________
> > > > Get Free Email and Do More On The Web. Visit http://www.msn.com
> > > > Visit the IUA at IMC at CA-WORLD 1999 - see us outside the TECH
> > >CAMPGROUND
> > > >
> > >Visit the IUA at IMC at CA-WORLD 1999 - see us outside the TECH
> > CAMPGROUND
> >
> >
> > _______________________________________________________________
> > Get Free Email and Do More On The Web. Visit http://www.msn.com
> >
>

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

Date: Mon, 26 Jul 1999 13:02:26 -0500
From: "Lorenzen, David C" <david.l...@eds.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: DBAN on dict files
Message-ID: <B9CB0C7E771ED2119FA400A02461EE240325E806@USPLM206>

Chris,

Use IDMSNWKU for the DDLDML and DDLDCLOD. You could use
IDMSNWKG for all (DDLDML, DDLDCLOD, DDLDCMSG).

If you need to analyze the catalog, use IDMSCATZ for the DDLCAT,
DDLCATX, and IDMSCATL for the DDLCATLOD.

Hope this was helpful.

David Lorenzen
EDS

> ----------
> From: Wood, Chris
> Sent: Monday, July 26, 1999 12:16 PM
> To: 'idm...@iuassn.com'
> Subject: DBAN on dict files
>
> Hi,
>
> We may have a corrupt IDD due to a series of power failures with no
UPS on
> our system. What subschema or subschemas should we be using in the
dban or
> dban's?
>
> Thanks
>
> Chris Wood
> Alberta Department of Resource Development
> CANADA
>

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

Date: Mon, 26 Jul 1999 14:14:23 -0400
From: "Lupico, Joe" <Joe.L...@AIG.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: SYSMSG
Message-ID: <4F1E68B5C708D11180860001FA372A6501CAFC74@XCS_LIV01>

Messages can easily be suppressed from the console by modifing WTOEXIT
and
relinking your startup program. If you feel comfortable modifing this
exit,
it really is easy. Just check for the message codes that you want to
suppress from the console and when you get a match, just move 4 to
register
15 before returning from the exit.

A simple sample from my WTOEXIT:

CLC WTOMTEXT+5(3),=C'DC8' HUMAN RESOURCES MESSAGES
BE RTNCODE4
CLC WTOMTEXT+5(3),=C'DC9' APPLICATION MESSAGES
BE RTNCODE4
*
* SET R15 TO CODE 0 (DISPLAY MESSAGE)
*
RTNCODE0 EQU *

LA R15,0 R15 TO 0 TO DISPLAY
MESSAGES
B RETURN

*
* SET R15 TO CODE 4 (SUPPRESS MESSAGE)
*
RTNCODE4 EQU *
LA R15,4 R15 TO 4 TO SUPPRESS
MESSAGES
B RETURN

Hope this helps...Joe

> ----------
> From: Scott, Mika F.[SMTP:mika....@mail.va.gov]
> Reply To: idm...@iuassn.com
> Sent: Tuesday, July 20, 1999 3:29 PM
> To: 'idm...@iuassn.com'
> Subject: SYSMSG
>
> I am a newbee to the group (and to IDMS), so if I make any
"procedural"
> mistakes, please forgive.
>
> My question:
>
> I have a guy who runs a job and clogs up the operators console with
his
> messages (DB347011 DB347004). I have checked the SYSMSG definition
in
> the
> dictionary he goes to under <IDDM> and the destination is set to LOG
only
> which tells me those messages should be diverted to the internal IDMS
log
> and / or his job spool not the CVs. This is a problem for us because
the
> operator console has a number threshold on console message per job and
I
> don't want his job bringing down the CV. Any advice is welcome.
>
> Thanks
> "Mika"
> Michaelene F. Scott
> Database Support (313)
>

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

Date: Mon, 26 Jul 1999 14:24:42 -0400
From: "Lupico, Joe" <Joe.L...@AIG.com>
To: "'IDM...@IUASSN.COM'" <IDM...@IUASSN.COM>
Subject: FW: Implementing IDMSINTL
Message-ID: <4F1E68B5C708D11180860001FA372A6501CAFC75@XCS_LIV01>

I did this without a problem using the premium support tape for S10214

(which doesn't support application calls to IDMSINTC). Just remember
that
UCFCICS still needs IDMSINTC, so you'll have two active interface
programs
(IDMSINTC and IDMSINTL) in the CICS region, each of which will need its
own
unique CWADISP.
The application programs will need to link with IDMSCINL, which will
need
to have been set up with the same CWADISP as IDMSINTL.
If you need to access multiple IDMS regions from a single CICS, you'll

need to have multiple pairs of INTC/INTL, each with unique CWADISP
values.
That's always fun(?).

Joe

> ----------
> From: E.Dij...@rf.rabobank.nl[SMTP:E.Dij...@rf.rabobank.nl]
> Reply To: E.Dij...@rf.rabobank.nl
> Sent: Tuesday, July 20, 1999 3:27 AM
> To: IDM...@IUASSN.COM
> Subject: Implementing IDMSINTL
>
> Dear Listr-members,
>
> We're starting up a project to replace IDMSINTC by IDMSINTL where ever

> possible.
> Are there any experiences on this.
> We are considering replacing the SVC and CVNUM parameter in these
modules
> by the SYSCTL parameter.
> Any reason why we should or should not??
> Did someone adjust OMEGAMON/CICS on this????
>
> Regards,
> Erik Dijkerman
> Rabofacet NEderland
>

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

Date: Mon, 26 Jul 1999 11:43:29 -0700
From: "Lee, Brian" <bl...@pac.bluecross.ca>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: DBAN on dict files
Message-ID: <FF09222003FAD211A07900A024B261F08ED0@PACEXCH>

Hi Chris,

Use subschema IDMSNWKA of schema IDMSNTWK from the SYSDIRL dictionary
against the problem dictionary.

Brian Lee
Database Administrator - Technical Services

[ Pacific Blue Cross
PO Box 7000, Vancouver, BC. V6B 4E1
Telephone: (604) 419-2532
Fax: (604) 419-2990

> -----Original Message-----
> From: Wood, Chris [SMTP:Chris...@gov.ab.ca]
> Sent: Monday, July 26, 1999 10:16 AM
> To: 'idm...@iuassn.com'
> Subject: DBAN on dict files
>
> Hi,
>
> We may have a corrupt IDD due to a series of power failures with no
UPS on
> our system. What subschema or subschemas should we be using in the
dban or
> dban's?
>
> Thanks
>
> Chris Wood
> Alberta Department of Resource Development
> CANADA

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

Date: Mon, 26 Jul 1999 14:17:29 -0500
From: Bill....@ipaper.com
To: " - *idm...@iuassn.com" <idm...@iuassn.com>
Subject: Re: IDMS/CICS cobol pgms abend with 1477 on 1st dml statemen
Message-ID: <0057390007924058000002L982*@MHS>

Had similar problem . You might want to check on your cics if you have
changed
to see
if storage protect is on, has to be off in some cases for idms and mvs
folks
said that
was problem.

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

Date: Mon, 26 Jul 1999 12:53:59 -0700
From: Keith Vogler <keith....@NAU.EDU>
To: IDM...@IUASSN.COM
Subject: Maintain Index
Message-ID: <4.1.199907261...@jan.ucc.nau.edu>

--Boundary_(ID_nAAwxcCVT+tQ7zBxujpAIw)
Content-type: text/plain; charset=us-ascii

beginning to impact the batch window. I tried a test where I broke the
job
into two separate jobs, each of the jobs vary both the index area and
the data
area to offline and then execute 'maintain index'. The job that started
first
was able to execute and the second job abended with an 0966 on the data
area.
Did the abort happen because two local mode jobs are running against the
same
area, the data area, at the same time? This is the only reason that
makes any
sense to me.

Thanks.
Keith Vogler
Northern Arizona University
Information Technology Services
P.O. Box 5100 Flagstaff, AZ 86011-5100
E-mail: Keith....@nau.edu
Website: http://jan.ucc.nau.edu/~kev/
Phone: 520/523-2978
FAX: 520/523-7407

--Boundary_(ID_nAAwxcCVT+tQ7zBxujpAIw)
Content-type: text/html; charset=us-ascii

I have a large area with two system-owned indices, each of the indices
reside in their own area. So I have three areas, a data area and two
index areas. The current maintain index job contains both indices but
the run time is beginning to impact the batch window. I tried a test
where I broke the job into two separate jobs, each of the jobs vary both
the index area and the data area to offline and then execute 'maintain
index'. The job that started first was able to execute and the second
job abended with an 0966 on the data area. Did the abort happen because
two local mode jobs are running against the same area, the data area, at
the same time? This is the only reason that makes any sense to me.

From: "Jim Phillips" To: idm...@iuassn.com Subject: RE: SYSMSG
Message-ID: <1999072619595...@hotmail.com> PMDC can also
handle re-routing of messages. The feature is usually used to send
specific messages to specific users or to widen message distribution but
it can also be used for suppression. An expensive solution but a
solution nonetheless. >From: "Lupico, Joe" >Reply-To: idm...@iuassn.com
>To: "'idm...@iuassn.com'" >Subject: RE: SYSMSG >Date: Mon, 26 Jul 1999
14:14:23 -0400 > > Messages can easily be suppressed from the console by
modifing WTOEXIT >and >relinking your startup program. If you feel
comfortable modifing this >exit, >it really is easy. Just check for the
message codes that you want to >suppress from the console and when you
get a match, just move 4 to register >15 before returning from the exit.
> > A simple sample from my WTOEXIT: > > CLC WTOMTEXT+5(3),=C'DC8' HUMAN
RESOURCES MESSAGES > BE RTNCODE4 > CLC WTOMTEXT+5(3),=C'DC9' APPLICATION
MESSAGES > BE RTNCODE4 >* >* SET R15 TO CODE 0 (DISPLAY MESSAGE) >*
>RTNCODE0 EQU * > > LA R15,0 R15 TO 0 TO DISPLAY >MESSAGES > B RETURN >
>* >* SET R15 TO CODE 4 (SUPPRESS MESSAGE) >* >RTNCODE4EQU * > LA R15,4
R15 TO 4 TO SUPPRESS >MESSAGES > B RETURN > > > > Hope this helps...Joe
> > > ---------- > > From: Scott, Mika F.[SMTP:mika....@mail.va.gov] >
> Reply To: idm...@iuassn.com > > Sent: Tuesday, July 20, 1999 3:29 PM >
> To: 'idm...@iuassn.com' > > Subject: SYSMSG > > > > I am a newbee to
the group (and to IDMS), so if I make any "procedural" > > mistakes,
please forgive. > > > > My question: > > > > I have a guy who runs a job
and clogs up the operators console with his > > messages (DB347011
DB347004). I have checked the SYSMSG definition in > > the > >
dictionary he goes to under and the destination is set to LOG >only > >
which tells me those messages should be diverted to the internal IDMS
>log > > and / or his job spool not the CVs. This is a problem for us
because >the > > operator console has a number threshold on console
message per job and I > > don't want his job bringing down the CV. Any
advice is welcome. > > > > Thanks > > "Mika" > > Michaelene F. Scott > >
Database Support (313) > > > >
______________________________________________________ Get Your Private,
Free Email at http://www.hotmail.com ------------------------------
Date: Mon, 26 Jul 1999 16:18:56 -0400 From: "Hayden Weathersbee" To:
IDM...@IUASSN.COM Subject: 1477 Message-ID: Check in your IDMS log for a
security violation. I recieved a 1477 on a batch job which the userid
did not have access to the data files preventing the bind. Hayden
Weathersbee, DBA State of SC Budget & Control Board Office of
Information Resources 300 Gervais Street Columbia, SC (803) 737-9601
(803) 737-9559 FAX hay...@oir.state.sc.us ------------------------------
Date: Mon, 26 Jul 1999 14:42:08 -0700 From: JB Moore To:
idm...@iuassn.com Subject: Re: Maintain Index Message-ID:
<379CD6...@ix.netcom.com> Keith Vogler wrote: > > I have a large
area with two system-owned indices, each of the indices > reside in
their own area. So I have three areas, a data area and two > > > Thanks.
> Keith Vogler Keith, That is exactly correct. These two index sets must
be linked index sets. When DBL4 attempts to ready the data area in the
second job, the 0966 results. Some things to consider... 1) If possible,
experiment with making the index sets unlinked. Are they both MA? Are
the keys modified or erased frequently? To be unlinked, the system-owned
index set must be MA. If the underlying data records are frequently
having their keys modified (and/or erased), the unlinked index may
result in somewhat worse performance. Frequent inserts are OK. Having
the index sets unlinked will speed your Maintain Index *AND* allow you
to "do two in parallel" as you described. 2) How are you doing the
Maintain Index? From ALLROWS, MEMBERS or INDEX? If you use FROM INDEX,
you will certainly speed up the TABX step. 3) Are you using any special
buffering or software? For example, are you using PREFETCH or
Fast-Access from ASG as part of your Maintain Index? You may want to
consider doing so if you are not using anything special. 4) Finally, a
properly built (rebuilt) index should be able go for quite a while
without a Maintain Index. With what frequency is your Maintain Index
run? Daily, weekly, monthly? Jim Moore ------------------------------
Date: Mon, 26 Jul 1999 17:00:56 -0500 From: "Rogers, Marsha [ALCO/STL]"
To: IDMSL Subject: os/390 ZEKE scheduler Message-ID: We have recently
converted to IDMS r14 and os390 1.3. Currently we do manual (dcmt or
oper w )commands in our database to ensure no task are running before
shutting down our database. Now we are going to use ZEKE to run our
nightly batch processing, but there is no way to script these commands
in ZEKE. (at least that's what systems is telling us). We can run a bcf
job to issue these commands, but that still requires a human to look at
the results. I'm looking for someone else that might be doing this
already. Any input would be appreciated. Thanks Marsha
mailto:marsha...@alcocontrols.com Alco Controls Division Emerson
Electric ------------------------------ Date: Tue, 27 Jul 1999 09:19:51
+0200 From: "Jan Lenders" To: idm...@iuassn.com Subject: os/390 ZEKE
scheduler (A) Message-ID: Marsha, We're a ZEKE, IDMS R14 and OS/390 shop
as well and we had the same = problems like anybody else (since there
has been a discussion on "Checking = RHDCUCFB-results" in this group
last february). Several members sent me their home-grown programs to
check the results of = DCMT commands. I stole code from some of these
(COBOL) programs and added = our site-specific checks which resulted in
a program that; - checks the result of a DCMT V SEG, V AREA and V FILE
command - sets the return-code to 08 and generates DISPLAY LOCK commands
when the = command has failed and if so, after using the DISPLAY LOCK
commands; - checks the result of the DISPLAY LOCK command=20 - generates
DCMT V LTERM commands to end the task that hold locks on = area's It may
not be quuite what you are looking for, but I'm afraid this is the =
general idea how to deal with databases through ZEKE (or any other =
scheduler). Regards, Jan Lenders, OHRA SO Service Center - A2-05 Tel.
+31 26 400 9608 >>> "Rogers, Marsha [ALCO/STL]" 1999/07/27= 0:00 >>> We
have recently converted to IDMS r14 and os390 1.3. Currently we do
manual (dcmt or oper w )commands in our database to ensure no task are
running before shutting down our database.=20 Now we are going to use
ZEKE to run our nightly batch processing, but = there is no way to
script these commands in ZEKE. (at least that's what systems = is
telling us).=20 We can run a bcf job to issue these commands, but that
still requires a human to look at the results.=20 I'm looking for
someone else that might be doing this already. Any input would be
appreciated.=20 Thanks Marsha mailto:marsha...@alcocontrols.com Alco
Controls Division Emerson Electric ------------------------------ End of
IDMS-L V1 #37 ********************

Chris Hoelscher

unread,

Jul 30, 1999, 3:00:00 AM7/30/99

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

IDMS-L Wed, 28 Jul 1999 Volume 1 :
Number 38

In this issue:

William Mitzmacher/NYLIC is out of the office.
RE: Dynam / NoDynam w/Call Identifier/Literal
Re: Dynam / NoDynam w/Call Identifier/Literal
RE: Dynam / NoDynam w/Call Identifier/Literal
cloning is for sheep, not for IDMS-L messages .....
Re[2]: Dynam / NoDynam w/Call Identifier/Literal

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

Date: Tue, 27 Jul 1999 05:17:24 -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: <852567BB.0...@Email.NewYorkLife.com>

I will be out of the office from 07/27/99 until 07/28/99.

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

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

Date: Tue, 27 Jul 1999 16:01:34 +0100
From: peter.g...@bt.com
To: idm...@iuassn.com, conl...@ix.netcom.com
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
Message-ID:
<5F54BE0116BCD2118C9...@mclmsent02.lon.bt.com>

Hi All,
I have read all the IDMS-L exchanges on this subject and wish to
add
my comments
Since COBOL II IDMSDC has had to allow for a COBOL program requesting
'operating system functions' .
I know of no MVS operating system function that is not a SVC.
COBOL II issues a MVS GETMAIN to get it's working storage but you see
storage for your COBOL II programs allocated in the IDMS STORAGE POOL.
I have used call identifer in IDMSDC. This causes COBOL to issue the MVS

LOAD MACRO ( ends up in an SVC ) I see the called program in my program
pool.
How does this happen ?
There is a feature in MVS called SVC SCREENING. This allows the active
MVS
task to 'trap' any SVC issued in the address space.
IDMSDC activates SVC SCREENING whenever it is giving control to a COBOL
program. So when the COBOL progarm issues an SVC it will get control.
It will convert a GETMAIN to a DC #GETSTG, a MVS LOAD to a #LOAD etc.
Some things it will not convert and the DC task will be abended. Not
tried
STAE but this is not only generates a GETMAIN but also the MVS STAE
which
IDMSDC CANNOT allow has he has one active to trap all program check any
where in the address space.
I learnt a few months back that in IDMSDC a COBOL program can now use
the
DISPLAY VERB. The dispalyed data appears on the IDMS LOG. Not sure if
this
is 12.0 or 14.0 I am on 14.0.
If you write your IDMS programs in assembler then you can ' do what you
like' and all the MVS LOADS, GETMAINS will NOT be converted
to DC calls.
IDMS does use LOTS AND LOTS of MVS SVCs including 99 for dynamic
allocation..

> -----Original Message-----
> From: Dave J. Miller [SMTP:djmi...@sherwin.com]
> Sent: 22 July 1999 21:38
> To: conl...@ix.netcom.com; idm...@iuassn.com
> Subject: Re: Dynam / NoDynam w/Call Identifier/Literal
>
>
>
> The reason that IDMS does not want you executing certain instructions
is
> not
> necessarily because they execute SVC's, but because they invoke
operating
> system
> services that the CV has assumed. The majority of these have to do
with
> storage
> management. If you ask the operating system to load a program, it is
> outside
> the control of the CV. The CV does not have any knowledge of the
program
> and it
> is loaded 'outside' of the CV (it's in the address space, but in
memory
> that was
> released by the CV). The same for doing getmains, and the good ol'
FLOW
> and
> STATE (which get their own memory) compile options in COBOL programs.
>
> The CV (especially a DC environment) is really a somewhat specialized
> operating
> system running under your operating system. This is what makes it
almost
> entirely OS-independent. This is also why you don't
open/close/read/write
> files, obtain your own storage, place enqueues, etc. directly but
through
> calls
> to IDMS. IDMS owns and manages the resources, and needs to have
control
> of
> them. While you can go directly to the operating system for
resources,
> results
> can, as IBM likes to say, unpredictable, especially if you're not the
only
> one
> breaking the rules. And the fact that the CV is managing multiple
threads
> concurrently and allowing different users to simultaneously access the

> same set
> of databases and resolving deadlocks and managing other resources is
why
> you
> want to be careful about breaking the "rules".
>
> BTW, I would be very surprised if I were to learn that IDMS doesn't
use
> IBM's
> SVC 99 to allocate/deallocate files.
>
>
>
>
> JB Moore <conl...@ix.netcom.com> on 07/21/99 03:28:18 PM
>
> Please respond to conl...@ix.netcom.com; Please respond to
> idm...@iuassn.com
>
> To: idms-l <idm...@iuassn.com>
> cc: (bcc: Dave J. Miller/CLE/Sherwin-Williams)
>
> Subject: Dynam / NoDynam w/Call Identifier/Literal
>
>
>
>
> Bruce,
>
> You raise an excellent question. It is one that I have wondered about
> myself. (The DYNAM compile-time versus the CALL identifier-1 format
> which is always dynamic).
>
> As another lister replied, CICS doesn't allow it either, although that

> may be changing.
>
> When DYNAM is active at compile-time, no ESD V-CONS are generated in
the
> output object code. These are "external references" that must be
> resolved by the binder. Essentially, after calling IGZ run-times, an
SVC
> 06 (Load) is issued, followed by a branch to the entry point address.
> There's your SVC call.
>
> Is CDMSLIB truly an MVS tasklib? I think it is. In earlier releases of

> CA-IDMS (10.2), I saw CVs brought down with an S806 by programs
compiled
> with DYNAM. This may have something to do with the DYNAM restriction:
> Where the sub-programs are loaded from. That is, which DD name:
CDMSLIB,
> STEPLIB or, who knows, maybe LPA or LinkList.
>
> I am in total agreement with the use of DYNAM. The extra storage
> required by NODYNAM can be excessive and re-linking the application
can
> be a real pain.
>
> As to SVC usage within a closed DC region, I wonder what SVC that
> CA-IDMS uses to do dynamic allocation of database files?
>
> It would seem to me that if the program pools were adequately sized,
> once dynamically loaded sub-program were in memory, that would be it:
No
> more loads. Heavily called sub-programs could even be made RESIDENT
(in
> the SYSGEN sense, not the COBOL RES option).
>
> Excellent post. I hope someone can truly answer this question.
>
> Jim Moore
> Concentrated Logic Inc
> "Working Smarter"
>
>
>
>
>

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

Date: Tue, 27 Jul 1999 10:19:16 -0700
From: JB Moore <conl...@ix.netcom.com>
To: idm...@iuassn.com
Subject: Re: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <379DEA...@ix.netcom.com>

> I have used call identifer in IDMSDC. This causes COBOL to issue the
MVS
> LOAD MACRO ( ends up in an SVC ) I see the called program in my
program
> pool.
> How does this happen ?
> There is a feature in MVS called SVC SCREENING. This allows the active
MVS
> task to 'trap' any SVC issued in the address space.
> IDMSDC activates SVC SCREENING whenever it is giving control to a
COBOL
> program. So when the COBOL progarm issues an SVC it will get control.
> It will convert a GETMAIN to a DC #GETSTG, a MVS LOAD to a #LOAD etc.
> Some things it will not convert and the DC task will be abended. Not
tried
> STAE but this is not only generates a GETMAIN but also the MVS STAE
which
> IDMSDC CANNOT allow has he has one active to trap all program check
any
> where in the address space.
> I learnt a few months back that in IDMSDC a COBOL program can now use
the
> DISPLAY VERB. The dispalyed data appears on the IDMS LOG. Not sure if
this
> is 12.0 or 14.0 I am on 14.0.
> If you write your IDMS programs in assembler then you can ' do what
you
> like' and all the MVS LOADS, GETMAINS will NOT be converted
> to DC calls.
> IDMS does use LOTS AND LOTS of MVS SVCs including 99 for dynamic
> allocation..
>
> > -----Original Message-----
> > From: Dave J. Miller [SMTP:djmi...@sherwin.com]
> > Sent: 22 July 1999 21:38
> > To: conl...@ix.netcom.com; idm...@iuassn.com
> > Subject: Re: Dynam / NoDynam w/Call Identifier/Literal
> >
> >
> >
> > The reason that IDMS does not want you executing certain
instructions is
> > not
> > necessarily because they execute SVC's, but because they invoke
operating
> > system
> > services that the CV has assumed. The majority of these have to do
with
> > storage
> > management. If you ask the operating system to load a program, it
is
> > outside
> > the control of the CV. The CV does not have any knowledge of the
program
> > and it
> > is loaded 'outside' of the CV (it's in the address space, but in
memory
> > that was
> > released by the CV). The same for doing getmains, and the good ol'
FLOW
> > and
> > STATE (which get their own memory) compile options in COBOL
programs.
> >
> > The CV (especially a DC environment) is really a somewhat
specialized
> > operating
> > system running under your operating system. This is what makes it
almost
> > entirely OS-independent. This is also why you don't
open/close/read/write
> > files, obtain your own storage, place enqueues, etc. directly but
through
> > calls
> > to IDMS. IDMS owns and manages the resources, and needs to have
control
> > of
> > them. While you can go directly to the operating system for
resources,
> > results
> > can, as IBM likes to say, unpredictable, especially if you're not
the only
> > one
> > breaking the rules. And the fact that the CV is managing multiple
threads
> > concurrently and allowing different users to simultaneously access
the
> > same set
> > of databases and resolving deadlocks and managing other resources is
why
> > you
> > want to be careful about breaking the "rules".
> >
> > BTW, I would be very surprised if I were to learn that IDMS doesn't
use
> > IBM's
> > SVC 99 to allocate/deallocate files.
> >
> >
> >
> >
> > JB Moore <conl...@ix.netcom.com> on 07/21/99 03:28:18 PM
> >
> > Please respond to conl...@ix.netcom.com; Please respond to
> > idm...@iuassn.com
> >
> > To: idms-l <idm...@iuassn.com>
> > cc: (bcc: Dave J. Miller/CLE/Sherwin-Williams)
> >
> > Subject: Dynam / NoDynam w/Call Identifier/Literal
> >
> >
> >
> >
> > Bruce,
> >
> > You raise an excellent question. It is one that I have wondered
about
> > myself. (The DYNAM compile-time versus the CALL identifier-1 format
> > which is always dynamic).
> >
> > As another lister replied, CICS doesn't allow it either, although
that
> > may be changing.
> >
> > When DYNAM is active at compile-time, no ESD V-CONS are generated in
the
> > output object code. These are "external references" that must be
> > resolved by the binder. Essentially, after calling IGZ run-times, an
SVC
> > 06 (Load) is issued, followed by a branch to the entry point
address.
> > There's your SVC call.
> >
> > Is CDMSLIB truly an MVS tasklib? I think it is. In earlier releases
of
> > CA-IDMS (10.2), I saw CVs brought down with an S806 by programs
compiled
> > with DYNAM. This may have something to do with the DYNAM
restriction:
> > Where the sub-programs are loaded from. That is, which DD name:
CDMSLIB,
> > STEPLIB or, who knows, maybe LPA or LinkList.
> >
> > I am in total agreement with the use of DYNAM. The extra storage
> > required by NODYNAM can be excessive and re-linking the application
can
> > be a real pain.
> >
> > As to SVC usage within a closed DC region, I wonder what SVC that
> > CA-IDMS uses to do dynamic allocation of database files?
> >
> > It would seem to me that if the program pools were adequately sized,

> > once dynamically loaded sub-program were in memory, that would be
it: No
> > more loads. Heavily called sub-programs could even be made RESIDENT
(in
> > the SYSGEN sense, not the COBOL RES option).
> >
> > Excellent post. I hope someone can truly answer this question.
> >
> > Jim Moore
> > Concentrated Logic Inc
> > "Working Smarter"
> >
> >
> >
> >
> >
Peter and Dave,

Thanks so much for the excellent technical information. I knew that IDMS

DC was somehow "trapping and converting" but was not exactly sure how it

was doing it.

To Dave, your point is well taken: The specialized nature of IDMS DC as
opposed to pure batch operating environments with their contents
management CDEs and LLEs on dynamic links, loads and xctls.

But still, can anyone answer the question:

Within the closed IDMS DC environment, why is the CALL identifier-1
format supported (and I assume "trapped") when the CALL 'literal' with
the DYNAM compile-time option is not supported (and NOT "trapped")?

Jim Moore

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

Date: Tue, 27 Jul 1999 14:15:04 -0500
From: Michael Newman <Michae...@soph.com>
To: idm...@iuassn.com
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <014CEBE84B9BD2118FFB0008C74C5E3C28FA@GRNSBORO>

One thing to keep in mind with the dynam option, is that ALL calls are
now dynamic, not just the call literal type.
All the cobol interface routines are not linked into the composite load
module, and these services must be loaded at runtime. Now all the
ILBO's, or IGZ's will be dynamically loaded and executed, I don't know
if these calls will be trapped by svc screening or not. I'm not sure
what environmental issues these routines will create if not linked in
statically with the cobol program. I believe this is more the issue,
that the simple calls that the application itself may be making. With
cobol II, it brings in the res/nores considerations of the runtime
modules as well.

JM2CW

-----Original Message-----
From: JB Moore [mailto:conl...@ix.netcom.com]
Sent: Tuesday, July 27, 1999 1:19 PM
To: idm...@iuassn.com
Subject: Re: Dynam / NoDynam w/Call
Identifier/Literal

peter.g...@bt.com wrote:
>
> Hi All,
> I have read all the IDMS-L exchanges on this
subject and wish to add
> my comments
> Since COBOL II IDMSDC has had to allow for a COBOL
program requesting
> 'operating system functions' .
> I know of no MVS operating system function that is
not a SVC.
> COBOL II issues a MVS GETMAIN to get it's working
storage but you see
> storage for your COBOL II programs allocated in the
IDMS STORAGE POOL.
> I have used call identifer in IDMSDC. This causes
COBOL to issue the MVS
> LOAD MACRO ( ends up in an SVC ) I see the called
program in my program
> pool.
> How does this happen ?
> There is a feature in MVS called SVC SCREENING. This
allows the active MVS
> task to 'trap' any SVC issued in the address space.
> IDMSDC activates SVC SCREENING whenever it is giving
control to a COBOL
> program. So when the COBOL progarm issues an SVC it
will get control.
> It will convert a GETMAIN to a DC #GETSTG, a MVS LOAD
to a #LOAD etc.
> Some things it will not convert and the DC task will
be abended. Not tried
> STAE but this is not only generates a GETMAIN but also
the MVS STAE which
> IDMSDC CANNOT allow has he has one active to trap all
program check any
> where in the address space.
> I learnt a few months back that in IDMSDC a COBOL
program can now use the
> DISPLAY VERB. The dispalyed data appears on the IDMS
LOG. Not sure if this
> is 12.0 or 14.0 I am on 14.0.
> If you write your IDMS programs in assembler then you
can ' do what you
> like' and all the MVS LOADS, GETMAINS will NOT be
converted
> to DC calls.
> IDMS does use LOTS AND LOTS of MVS SVCs including 99
for dynamic
> allocation..
>
> > -----Original Message-----
> > From: Dave J. Miller [SMTP:djmi...@sherwin.com]
> > Sent: 22 July 1999 21:38
> > To: conl...@ix.netcom.com; idm...@iuassn.com
> > Subject: Re: Dynam / NoDynam w/Call
Identifier/Literal
> >
> >
> >
> > The reason that IDMS does not want you executing
certain instructions is
> > not
> > necessarily because they execute SVC's, but because
they invoke operating
> > system
> > services that the CV has assumed. The majority of
these have to do with
> > storage
> > management. If you ask the operating system to load
a program, it is
> > outside
> > the control of the CV. The CV does not have any
knowledge of the program
> > and it
> > is loaded 'outside' of the CV (it's in the address
space, but in memory
> > that was
> > released by the CV). The same for doing getmains,
and the good ol' FLOW
> > and
> > STATE (which get their own memory) compile options
in COBOL programs.
> >
> > The CV (especially a DC environment) is really a
somewhat specialized
> > operating
> > system running under your operating system. This is
what makes it almost
> > entirely OS-independent. This is also why you don't
open/close/read/write
> > files, obtain your own storage, place enqueues, etc.
directly but through
> > calls
> > to IDMS. IDMS owns and manages the resources, and
needs to have control
> > of
> > them. While you can go directly to the operating
system for resources,
> > results
> > can, as IBM likes to say, unpredictable, especially
if you're not the only
> > one
> > breaking the rules. And the fact that the CV is
managing multiple threads
> > concurrently and allowing different users to
simultaneously access the
> > same set
> > of databases and resolving deadlocks and managing
other resources is why
> > you
> > want to be careful about breaking the "rules".
> >
> > BTW, I would be very surprised if I were to learn
that IDMS doesn't use
> > IBM's
> > SVC 99 to allocate/deallocate files.
> >
> >
> >
> >
> > JB Moore <conl...@ix.netcom.com> on 07/21/99
03:28:18 PM
> >
> > Please respond to conl...@ix.netcom.com; Please
respond to
> > idm...@iuassn.com
> >
> > To: idms-l <idm...@iuassn.com>
> > cc: (bcc: Dave J. Miller/CLE/Sherwin-Williams)
> >
> > Subject: Dynam / NoDynam w/Call Identifier/Literal
> >
> >
> >
> >
> > Bruce,
> >
> > You raise an excellent question. It is one that I
have wondered about
> > myself. (The DYNAM compile-time versus the CALL
identifier-1 format
> > which is always dynamic).
> >
> > As another lister replied, CICS doesn't allow it
either, although that
> > may be changing.
> >
> > When DYNAM is active at compile-time, no ESD V-CONS
are generated in the
> > output object code. These are "external references"
that must be
> > resolved by the binder. Essentially, after calling
IGZ run-times, an SVC
> > 06 (Load) is issued, followed by a branch to the
entry point address.
> > There's your SVC call.
> >
> > Is CDMSLIB truly an MVS tasklib? I think it is. In
earlier releases of
> > CA-IDMS (10.2), I saw CVs brought down with an S806
by programs compiled
> > with DYNAM. This may have something to do with the
DYNAM restriction:
> > Where the sub-programs are loaded from. That is,
which DD name: CDMSLIB,
> > STEPLIB or, who knows, maybe LPA or LinkList.
> >
> > I am in total agreement with the use of DYNAM. The
extra storage
> > required by NODYNAM can be excessive and re-linking
the application can
> > be a real pain.
> >
> > As to SVC usage within a closed DC region, I wonder
what SVC that
> > CA-IDMS uses to do dynamic allocation of database
files?
> >
> > It would seem to me that if the program pools were
adequately sized,
> > once dynamically loaded sub-program were in memory,
that would be it: No
> > more loads. Heavily called sub-programs could even
be made RESIDENT (in
> > the SYSGEN sense, not the COBOL RES option).
> >
> > Excellent post. I hope someone can truly answer this
question.
> >
> > Jim Moore
> > Concentrated Logic Inc
> > "Working Smarter"
> >
> >
> >
> >
> >
Peter and Dave,

Thanks so much for the excellent technical information.
I knew that IDMS
DC was somehow "trapping and converting" but was not
exactly sure how it
was doing it.

To Dave, your point is well taken: The specialized
nature of IDMS DC as
opposed to pure batch operating environments with their
contents
management CDEs and LLEs on dynamic links, loads and
xctls.

But still, can anyone answer the question:

Within the closed IDMS DC environment, why is the CALL
identifier-1
format supported (and I assume "trapped") when the CALL
'literal' with
the DYNAM compile-time option is not supported (and NOT
"trapped")?

Jim Moore

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

Date: Tue, 27 Jul 1999 15:37:24 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: cloning is for sheep, not for IDMS-L messages .....
Message-ID: <852567BB.0...@d54mta03.raleigh.ibm.com>

when replying to an IDMS-L post, PLEASE verify that you message includes
your
reply and the the text of the person who POSTED the message; please try
to avoid
cloning x levels of posts. While this is not a list policy, it certainly
is a
courtesy to those who have been following the thread and do not
want/need to see
the previous x number of posts in the thread

thanks,
Chris Hoelscher
IDMS-L co-listadmin

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

Date: Tue, 27 Jul 1999 16:21 -0500
From: "Steve Franzon" <Steve....@alltel.com>
To: "idm...@iuassn.com" <idm...@iuassn.com>
Subject: Re[2]: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <199907271527...@alltel.com>

It is the RESIDENT/NORESIDENT compile option that controls whether the
COBOL run time modules are dynamically called (RES) or if they are
link-edited with the program (NORES). The only impact DYNAM has on this
is
that DYNAM forces the RESIDENT option to be in effect.

IDMS fully supports RESIDENT compiled programs. To be reentrant or to do

dynamic calls with the CALL identifier verb, both require that the
program
be compiled with the RESIDENT option. So this is not the reason IDMS
doesn't support DYNAM.

Note also that the latest generation of COBOL compilers don't even
support
NORES.

Steve Franzon

P.S. just to avoid confusion, in this discussion I am talking about the
RESIDENT
COBOL compiler option - not the RESIDENT option on IDMS PROGRAM
definitions
(I.E. SYSGEN/DCMT).

______________________________ Reply Separator
_________________________________
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
Author: idm...@iuassn.com at internet
Date: 07/27/1999 2:15 PM

JM2CW

-----Original Message-----
From: JB Moore [mailto:conl...@ix.netcom.com]
Sent: Tuesday, July 27, 1999 1:19 PM
To: idm...@iuassn.com
Subject: Re: Dynam / NoDynam w/Call
Identifier/Literal

Thanks so much for the excellent technical information.
I knew that IDMS
DC was somehow "trapping and converting" but was not
exactly sure how it
was doing it.

To Dave, your point is well taken: The specialized
nature of IDMS DC as
opposed to pure batch operating environments with their
contents
management CDEs and LLEs on dynamic links, loads and
xctls.

But still, can anyone answer the question:

Within the closed IDMS DC environment, why is the CALL
identifier-1
format supported (and I assume "trapped") when the CALL
'literal' with
the DYNAM compile-time option is not supported (and NOT
"trapped")?

Jim Moore

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

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

Chris Hoelscher

unread,

Jul 30, 1999, 3:00:00 AM7/30/99

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

IDMS-L Thu, 29 Jul 1999 Volume 1 :
Number 39

In this issue:

RE: Responses to "Area expansion ( R 14.0 / 9711 )" of 9th July
1
999
Re: Responses to "Area expansion ( R 14.0 / 9711 )" of 9th July
1999
AREA UNLOCK
RE: AREA UNLOCK
RE: AREA UNLOCK
Re: AREA UNLOCK
Re: AREA UNLOCK
Re: AREA UNLOCK
RHDCPARM assembly in 14.1
Re: RHDCPARM assembly in 14.1
RE: RHDCPARM assembly in 14.1
RE: AREA UNLOCK / "Re-Lock"
RE: IDMSINTL Solved!
RE: Maintain Index
RE: AREA UNLOCK
RACF Groups
RE: AREA UNLOCK / "Re-Lock"
Re: RHDCPARM assembly in 14.1
RE: RHDCPARM assembly in 14.1
RE: AREA UNLOCK / "Re-Lock"
RE: RHDCPARM assembly in 14.1
RE: RHDCPARM assembly in 14.1
Re: RE: AREA UNLOCK / "Re-Lock"
Not IDD Owned
RE: Not IDD Owned
RE: Not IDD Owned
RE: Not IDD Owned
RE: Not IDD Owned
Re: Not IDD Owned
Looking for David Murry
Another possible upgrade site
Re: Another possible upgrade site
RE: Another possible upgrade site

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

Date: Wed, 28 Jul 1999 09:36:00 +0100
From: "Stewart, Jeremy" <Stew...@AWA-CPO.COM>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Responses to "Area expansion ( R 14.0 / 9711 )" of 9th July
1
999
Message-ID: <C8C547D6EBA3D111BBFF00805FA604547AD64C@BASEXCHANGE>

Many thanks to all who contributed so helpfully in reply to this and
pointed out many important aspects which should not be overlooked.
As always the expertise from this group is most welcome - I only
wish we had been able to gain from it years ago !

We have proceeded successfully with the increase of the area's page
size and applied this also to another area which through new business
requirements had also become critically full. No doubt the method will
come in useful again before too long.

> -----Original Message-----
> From: Stewart, Jeremy [SMTP:Stew...@BASINGSTOKE.AWA-CPO.com]
> Sent: 09 July 1999 10:29
> To: idm...@iuassn.com
> Subject: Area expansion ( R 14.0 / 9711 )
>
> We have an urgent need to enlarge an area ( 6000 trks ) which
> has heavy CALC usage as well as substantial overnight batch
> area sweeps. We cannot perform an unload/reload ( which is
> our only previous experience of dealing with such problems )
> because an 8-hour outage is unacceptable to our users so
> therefore must consider an alternative
>
> This seems to leave us with a choice of two:
>
> 1 Increase the area page size which is quick ( 5 minutes )
> 2 Extend the area's page range which is also quick ( ?? )
> and which the manual seems to indicate does not need
> an unload/reload but ...
>
> am I right in thinking that this second option will be very
> inefficient
> because the CALC's will start producing numerous overflows ?
>
> Could anyone with more technical know-how and experience of
> such utilities give me any advice on this, please ?
>
> Thanks.
>
> 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
________________________________________________________________________________

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

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

Date: Wed, 28 Jul 1999 14:49:55 -0400
From: "Suresh Panchedhri" <sur...@wiphyd.ge.com>
To: <idm...@iuassn.com>
Subject: Re: Responses to "Area expansion ( R 14.0 / 9711 )" of 9th July
1999
Message-ID: <026d01bed929$fcc7ed80$f30d...@wiphyd.ge.com>

I think you are right, the second option is inefficient but that should
not
create any problems.... since the overflows caused by CALC are minor.

Suresh Panchedhri,
GE-Power systems,
COPICS Module,
III Floor Lakshmi Buildings,
Ph : 091-040-7822113 (R),
: 091-040-786006 ext 4333.

----- Original Message -----
From: Stewart, Jeremy <Stew...@AWA-CPO.COM>
To: <idm...@iuassn.com>
Sent: Wednesday, July 28, 1999 4:36 AM
Subject: RE: Responses to "Area expansion ( R 14.0 / 9711 )" of 9th July

1999

> Many thanks to all who contributed so helpfully in reply to this and
> pointed out many important aspects which should not be overlooked.
> As always the expertise from this group is most welcome - I only
> wish we had been able to gain from it years ago !
>
> We have proceeded successfully with the increase of the area's page
> size and applied this also to another area which through new business
> requirements had also become critically full. No doubt the method will

> come in useful again before too long.
>
> > -----Original Message-----
> > From: Stewart, Jeremy [SMTP:Stew...@BASINGSTOKE.AWA-CPO.com]
> > Sent: 09 July 1999 10:29
> > To: idm...@iuassn.com
> > Subject: Area expansion ( R 14.0 / 9711 )
> >
> > We have an urgent need to enlarge an area ( 6000 trks ) which
> > has heavy CALC usage as well as substantial overnight batch
> > area sweeps. We cannot perform an unload/reload ( which is
> > our only previous experience of dealing with such problems )
> > because an 8-hour outage is unacceptable to our users so
> > therefore must consider an alternative
> >
> > This seems to leave us with a choice of two:
> >
> > 1 Increase the area page size which is quick ( 5 minutes )
> > 2 Extend the area's page range which is also quick ( ?? )
> > and which the manual seems to indicate does not need
> > an unload/reload but ...
> >
> > am I right in thinking that this second option will be very
> > inefficient
> > because the CALC's will start producing numerous overflows ?
> >
> > Could anyone with more technical know-how and experience of
> > such utilities give me any advice on this, please ?
> >
> > Thanks.
> >
> > 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
>
____________________________________________________________________________

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

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

Date: Wed, 28 Jul 1999 10:56:51 -0500
From: "Lancelot, Jim" <jim.la...@mail.va.gov>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: AREA UNLOCK
Message-ID: <5D88BE4FFA43D211BB1...@mail.va.gov>

Here's an easy one, I hope. An over zealous programmer ran a batch
unlock
job against two Areas held in update by the CV. I need to format one of
the
two Areas but I'm getting a 3018 whenever I try to Vary the Area
Offline.
As a DBA, I can't ever remember doing this and short of cycling the CV
(which I can't), I don't how to begin to undo the mistake? Thanks for
any
suggestions.

Jim Lancelot
U. S. Department of Veterans Affairs
Database Support Services
(313)(512) 326-6471
fax: (512) 326-6731
email: jim.la...@mail.va.gov <mailto:jim.la...@mail.va.gov>

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

Date: Wed, 28 Jul 1999 10:59:42 -0500
From: "Norris, Greg" <Greg_...@mail.dor.state.mo.us>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: AREA UNLOCK
Message-ID:
<27E9B6F4DA4CD211BB68...@mail.dor.state.mo.us>

"DCMT VARY FILE segment.XXXX ACTIVE", where XXXX is the name of the
first
file which makes up the area. This resets the update-lock indicator,
which
should allow you to vary the area.

> -----Original Message-----
> From: Lancelot, Jim [mailto:jim.la...@mail.va.gov]
> Sent: 28 July, 1999 10:57 AM
> To: 'idm...@iuassn.com'
> Subject: AREA UNLOCK
>
>
> Here's an easy one, I hope. An over zealous programmer ran a
> batch unlock
> job against two Areas held in update by the CV. I need to
> format one of the
> two Areas but I'm getting a 3018 whenever I try to Vary the
> Area Offline.
> As a DBA, I can't ever remember doing this and short of cycling the CV

> (which I can't), I don't how to begin to undo the mistake?
> Thanks for any
> suggestions.
>
> Jim Lancelot
> U. S. Department of Veterans Affairs
> Database Support Services
> (313)(512) 326-6471
> fax: (512) 326-6731
> email: jim.la...@mail.va.gov <mailto:jim.la...@mail.va.gov>
>

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

Date: Wed, 28 Jul 1999 11:04:19 -0500
From: "Cunningham, Bud" <Bud_Cun...@mail.dor.state.mo.us>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: AREA UNLOCK
Message-ID:
<27E9B6F4DA4CD211BB6...@mail.dor.state.mo.us>

Vary your file(s) active; then you will be able to vary the
area offline.

-----Original Message-----
From: Lancelot, Jim [mailto:jim.la...@mail.va.gov]
Sent: Wednesday, July 28, 1999 10:57 AM
To: 'idm...@iuassn.com'
Subject: AREA UNLOCK

Jim Lancelot
U. S. Department of Veterans Affairs
Database Support Services
(313)(512) 326-6471
fax: (512) 326-6731
email: jim.la...@mail.va.gov <mailto:jim.la...@mail.va.gov>

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

Date: Wed, 28 Jul 1999 12:07:35 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: Re: AREA UNLOCK
Message-ID: <852567BC.0...@d54mta03.raleigh.ibm.com>

i would try to take the area offline (if possible), issue a dcmt v file
segment.file ACTIVE (for all files to which the area maps), and then try
to vary
the area update

ps - if you tried to bring down the region you would still get the 3018.
If you
can believe this - years ago appl programmers coded PFIXs and now
UNLOCKs as
part of NORMAL processing
(when they got 0966) - the current CLIENT DBA staff has cracked down on
this
severely!

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

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

Date: Wed, 28 Jul 1999 09:04:57 -0700
From: John....@teale.ca.gov
To: idm...@iuassn.com
Subject: Re: AREA UNLOCK
Message-ID: <882567BC.0...@teale.ca.gov>

Had the same problem. Do this:

3018 will occur when DBMS tries to remove an area lock, but the area is
NOT
locked.
DCMT VARY FILE file-name ACTIVE will resolve the 3018 message and
replace the
lock.

"Lancelot, Jim" <jim.la...@mail.va.gov> on 07/28/99 08:56:51 AM

Please respond to idm...@iuassn.com

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
cc: (bcc: John Kamuf/Teale)

Subject: AREA UNLOCK

Jim Lancelot
U. S. Department of Veterans Affairs
Database Support Services
(313)(512) 326-6471
fax: (512) 326-6731
email: jim.la...@mail.va.gov <mailto:jim.la...@mail.va.gov>

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

Date: Wed, 28 Jul 1999 12:06:53 -0400
From: "Laura Rochon" <laura....@cloxt.com>
To: <idm...@iuassn.com>
Subject: Re: AREA UNLOCK
Message-ID: <1999072816...@franz.videotron.net>

Jim,

Run the format against your area, then do a DCMT V FILE xxx ACTIVE, and
that should fix your problem.

Laura Rochon
Compuware Corporation of Canada

----------
> From: Lancelot, Jim <jim.la...@mail.va.gov>
> To: 'idm...@iuassn.com'
> Subject: AREA UNLOCK
> Date: 28 juillet, 1999 11:56
>
> Here's an easy one, I hope. An over zealous programmer ran a batch
unlock
> job against two Areas held in update by the CV. I need to format one
of
the
> two Areas but I'm getting a 3018 whenever I try to Vary the Area
Offline.
> As a DBA, I can't ever remember doing this and short of cycling the CV

> (which I can't), I don't how to begin to undo the mistake? Thanks for

any
> suggestions.
>
> Jim Lancelot
> U. S. Department of Veterans Affairs
> Database Support Services
> (313)(512) 326-6471
> fax: (512) 326-6731
> email: jim.la...@mail.va.gov <mailto:jim.la...@mail.va.gov>

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

Date: Wed, 28 Jul 1999 12:17:12 -0500
From: "Angerer, Chris" <cang...@mail.sdc.state.mo.us>
To: IDMS-L <IDM...@IUASSN.COM>
Subject: RHDCPARM assembly in 14.1
Message-ID:
<C18BE495D4DDD0118EA...@mail.sdc.state.mo.us>

Has anyone experience any problems assembling a startup module outside
of SMPE at release 14.1 9811 and OS390 2.5 ???
We are getting an error in #MOPT saying:

ASMA057E *** ERROR *** Undefined operation code - #MOPT/SPLEVEL
ASMA435I ** WARNING ** Record 121 in SDDIF.SMPE.DISTMAC(#MOPT)

Thanks in advance.

Chris W. Angerer
State of Missouri, OA, DIS
cang...@mail.state.mo.us

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

Date: Wed, 28 Jul 1999 13:20:58 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: Re: RHDCPARM assembly in 14.1
Message-ID: <852567BC.0...@d54mta03.raleigh.ibm.com>

the only trouble I remember having (when going to OS390) was that
sys1.amodgen
was no more - it was replaced by sys1.modgen - perhaps there is an empty

sys1.amodgen that you are looking to - just a thought

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

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

Date: Wed, 28 Jul 1999 19:24:15 +0200
From: =?iso-8859-1?Q?Brandt_Ren=E9?= <r...@ubp.ch>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: RHDCPARM assembly in 14.1
Message-ID:
<693E4DC6C79FD211907...@mailgva.geneve.ubp.ch>

That means the IDMS.xxxx.DISTMAC is missing in your assembly

> -----Message d'origine-----
> De: Angerer, Chris [SMTP:cang...@mail.sdc.state.mo.us]
> Date: Wednesday, July 28, 1999 7:17 PM
> =C0: IDMS-L
> Objet: RHDCPARM assembly in 14.1
>=20
> Has anyone experience any problems assembling a startup module =
outside
> of SMPE at release 14.1 9811 and OS390 2.5 ???
> We are getting an error in #MOPT saying:
>=20
> ASMA057E *** ERROR *** Undefined operation code - #MOPT/SPLEVEL
> ASMA435I ** WARNING ** Record 121 in SDDIF.SMPE.DISTMAC(#MOPT)=20
>=20
>=20
> Thanks in advance.
>=20
> Chris W. Angerer
> State of Missouri, OA, DIS
> cang...@mail.state.mo.us

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

Date: Wed, 28 Jul 1999 12:41:33 -0500
From: "Walters, NR Neal (8377)" <Walt...@gvl.esys.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: AREA UNLOCK / "Re-Lock"
Message-ID:
<9D198A0A726AD211BD1...@gvlmail1.gvl.esys.com>

I made a similar mistake today, and it was so timely that your email
appeared.

We use ASG's VDB to shadow our production system on several other
systems
(QA, Maintenance, and Y2K). I had a problem on the Y2K system, and had
to init the journals and unlock all the files. Not thinking, I ran the
unlock for CV60 files,
but of course, there really are no CV60 files. Each file actually
points to
production files.
So I unlocked every area on my production CV.

So, the point is VDB users should beware of this problem and the
recommended
fixes.

Neal Walters
http://ItDoesMoreStuff.com - Web Site dedicated to IDMS and IDMS
Training

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

Date: Wed, 28 Jul 1999 12:59:20 -0500
From: "Walters, NR Neal (8377)" <Walt...@gvl.esys.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: IDMSINTL Solved!
Message-ID:
<9D198A0A726AD211BD1...@gvlmail1.gvl.esys.com>

After 7 weeks, and many headaches, I finally got the answer from CA.
They
do not support CICS Transaction Isolation, which was set to ACTIVE in
the
CICS region in which I was testing.

Storage Protection and Transaction Isolation are two different but
similar
functions. As I just learned, Storage Protection keeps CICS User
Programs
from stepping on CICS system areas, but not from stepping on each other.

Transaction Isolation keeps CICS User Programs from stepping on each
other.

A simple switch of this flag could have saved me about 40 man-hours of
testing.
The next step is to now see if I can get IDMSINTL to work with VDB
(ASG's
Virtual Database)

Neal Walters
http://ItDoesMoreStuff.com - Web Site dedicated to IDMS and IDMS
Training

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

Date: Wed, 28 Jul 1999 13:06:58 -0500
From: "Walters, NR Neal (8377)" <Walt...@gvl.esys.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Cc: "'Keith....@nau.edu'" <Keith....@nau.edu>
Subject: RE: Maintain Index
Message-ID:
<9D198A0A726AD211BD1...@gvlmail1.gvl.esys.com>

One more point. I have three Mandatory Automatic (unlinked) indexes on
the
same record which has 3.3 million occurrences. The rebuild normally
takes
about 8 or 9 hours. I once tried just doing a rebuild index of one of
the
three, thinking it would take 1/3 of the time. But not so. I think it

still had to process all 3 million members. It may have had less sort
time,
but it seems like the rebuild time was only 10 to 20% of doing all three
at
once. So, if your indexes are on the same record, you might question
if
running in parallel would be the fastest way to go.

Neal Walters
http://ItDoesMoreStuff.com - website dedicated to IDMS and IDMS Training

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

Date: Wed, 28 Jul 1999 14:13:05 -0400
From: "Boyce, Bill (CAP, CARD)" <Bill....@gecapital.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: AREA UNLOCK
Message-ID: <D524764C2842D311888400805FBE6C1308F9A2@STA01XBMAILGE>

Jim;
You just need to issue a 'DCMT V FILE filename ACTIVE' then vary it
offline.

Bill Boyce
GE Card Services

-----Original Message-----
From: Lancelot, Jim [mailto:jim.la...@mail.va.gov]
Sent: Wednesday, July 28, 1999 11:57 AM
To: 'idm...@iuassn.com'
Subject: AREA UNLOCK

Jim Lancelot
U. S. Department of Veterans Affairs
Database Support Services
(313)(512) 326-6471
fax: (512) 326-6731
email: jim.la...@mail.va.gov <mailto:jim.la...@mail.va.gov>

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

Date: Wed, 28 Jul 1999 11:19:35 -0700
From: Richard Phelps <Richard...@asu.edu>
To: 'IDMS-L' <IDM...@IUASSN.com>
Subject: RACF Groups
Message-ID: <8093ABAD9B81D211878...@mainex3.asu.edu>

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

thanks for your help

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

Date: Wed, 28 Jul 1999 14:19:29 -0500
From: Michael Newman <Michae...@soph.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: AREA UNLOCK / "Re-Lock"
Message-ID: <014CEBE84B9BD2118FFB0008C74C5E3C2903@GRNSBORO>

Just a side note. When formatting by area, the area lock bit is
honored. The area will not be formatted if the lock is on,
additionally, the area will be locked for the duration of the format.
Formatting by file or segment does not set, or honor the area lock.
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: Walters, NR Neal (8377)
[mailto:Walt...@gvl.esys.com]
Sent: Wednesday, July 28, 1999 1:42 PM
To: 'idm...@iuassn.com'
Subject: RE: AREA UNLOCK / "Re-Lock"

I made a similar mistake today, and it was so timely
that your email
appeared.

We use ASG's VDB to shadow our production system on
several other systems
(QA, Maintenance, and Y2K). I had a problem on the Y2K
system, and had
to init the journals and unlock all the files. Not
thinking, I ran the
unlock for CV60 files,
but of course, there really are no CV60 files. Each
file actually points to
production files.
So I unlocked every area on my production CV.

So, the point is VDB users should beware of this problem
and the recommended
fixes.

Neal Walters
http://ItDoesMoreStuff.com - Web Site dedicated to IDMS
and IDMS Training

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

Date: Wed, 28 Jul 1999 15:34:26 -0400
From: Ale...@cpr.ca
To: idm...@iuassn.com
Subject: Re: RHDCPARM assembly in 14.1
Message-ID: <872567BC.0...@mail1.cprailway.com>

The only reason I can think of either #MOPT is missing from IDMS maco
library or
your assembly step
does not refer to IDMS marco library. The macro library must be in the
//SYSLIB
concatenation of assembly
step.

Ale Eba
IDMS System Support
CPR, Toronto
Email: ale...@cpr.ca

cang...@mail.sdc.state.mo.us on 07/28/99 12:17:12 PM

Please respond to idm...@iuassn.com

To: IDM...@iuassn.com
cc: (bcc: Ale Eba/eba0001/CPR)
Subject: RHDCPARM assembly in 14.1

Has anyone experience any problems assembling a startup module outside
of SMPE at release 14.1 9811 and OS390 2.5 ???
We are getting an error in #MOPT saying:

ASMA057E *** ERROR *** Undefined operation code - #MOPT/SPLEVEL
ASMA435I ** WARNING ** Record 121 in SDDIF.SMPE.DISTMAC(#MOPT)

Thanks in advance.

Chris W. Angerer
State of Missouri, OA, DIS
cang...@mail.state.mo.us

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

Date: Wed, 28 Jul 1999 14:39:38 -0500
From: Michael Newman <Michae...@soph.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: RHDCPARM assembly in 14.1
Message-ID: <014CEBE84B9BD2118FFB0008C74C5E3C2906@GRNSBORO>

I don't have access to a r14 maclib today, but within the 12.01 #mopt
macro, there is a SPLEVEL macro that I assume returns a code of what
level the operating system is running, CA provides one so that if you
did not pick up the SPLEVEL macro form the sys1.maclib or sys1.modgen,
then it would assume you are not an XA (or higher site). Perhaps the
SPLEVEL macro is missing in both the IDMS.DISTMAC, and the sys1.*
libraries.
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: Angerer, Chris
[mailto:cang...@mail.sdc.state.mo.us]
Sent: Wednesday, July 28, 1999 1:17 PM
To: IDMS-L
Subject: RHDCPARM assembly in 14.1

Has anyone experience any problems assembling a startup
module outside
of SMPE at release 14.1 9811 and OS390 2.5 ???
We are getting an error in #MOPT saying:

ASMA057E *** ERROR *** Undefined operation code -
#MOPT/SPLEVEL
ASMA435I ** WARNING ** Record 121 in
SDDIF.SMPE.DISTMAC(#MOPT)

Thanks in advance.

Chris W. Angerer
State of Missouri, OA, DIS
cang...@mail.state.mo.us

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

Date: Wed, 28 Jul 1999 12:48:39 -0700
From: "Johnson, Sara" <Sara.J...@hexcel.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: AREA UNLOCK / "Re-Lock"
Message-ID:
<2BCA09803339D211AE04...@unknown-68-47.hexcel.com>

Another side note re AREA UNLOCK - when formatting in preparation for
UNLD/RELD, for instance, I always insist on using a DMCL that does not
contain the data set name. This way I prevent mistakenly formatting a
file
that is allocated to a CV, especially if the DDNAMES are somewhat
confusing.
Before each maintenance project I will take the time to create a fresh
'project' dmcl using the global dmcl syntax as input and removing the
dsn
parameter. This only takes a short time and is well worth it.

-----Original Message-----
From: Michael Newman [mailto:Michae...@soph.com]
Sent: Wednesday, July 28, 1999 12:19 PM
To: 'idm...@iuassn.com'

Subject: RE: AREA UNLOCK / "Re-Lock"

Just a side note. When formatting by area, the area lock
bit is
honored. The area will not be formatted if the lock is on,
additionally, the area will be locked for the duration of
the format.
Formatting by file or segment does not set, or honor the
area lock.
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: Walters, NR Neal (8377)
[mailto:Walt...@gvl.esys.com]
Sent: Wednesday, July 28, 1999 1:42 PM
To: 'idm...@iuassn.com'
Subject: RE: AREA UNLOCK / "Re-Lock"

I made a similar mistake today, and it was
so timely
that your email
appeared.

We use ASG's VDB to shadow our production
system on
several other systems
(QA, Maintenance, and Y2K). I had a problem
on the Y2K
system, and had
to init the journals and unlock all the
files. Not
thinking, I ran the
unlock for CV60 files,
but of course, there really are no CV60
files. Each
file actually points to
production files.
So I unlocked every area on my production
CV.

So, the point is VDB users should beware of
this problem
and the recommended
fixes.

Neal Walters
http://ItDoesMoreStuff.com - Web Site
dedicated to IDMS
and IDMS Training

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

Date: Wed, 28 Jul 1999 14:53:32 -0500
From: "Angerer, Chris" <cang...@mail.sdc.state.mo.us>
To: idm...@iuassn.com
Subject: RE: RHDCPARM assembly in 14.1
Message-ID:
<C18BE495D4DDD0118EA...@mail.sdc.state.mo.us>

The problem is not that the #MOPT is missing or that we are not pointing

to the IDMS macro library. It seems that on line 121 of the #MOPT macro

there is an error with the following line of code:

SPLEVEL TEST GET SP LEVEL +

Beats me we have an issue opened up with CA and waiting a response.

Chris Angerer
cang...@mail.state.mo.us
State of Missouri/OA/DIS

-----Original Message-----
From: Ale...@cpr.ca [mailto:Ale...@cpr.ca]
Sent: Wednesday, July 28, 1999 2:34 PM
To: idm...@iuassn.com

Subject: Re: RHDCPARM assembly in 14.1

Ale Eba
IDMS System Support
CPR, Toronto
Email: ale...@cpr.ca

cang...@mail.sdc.state.mo.us on 07/28/99 12:17:12 PM

Please respond to idm...@iuassn.com

To: IDM...@iuassn.com
cc: (bcc: Ale Eba/eba0001/CPR)
Subject: RHDCPARM assembly in 14.1

Has anyone experience any problems assembling a startup module outside
of SMPE at release 14.1 9811 and OS390 2.5 ???
We are getting an error in #MOPT saying:

ASMA057E *** ERROR *** Undefined operation code - #MOPT/SPLEVEL
ASMA435I ** WARNING ** Record 121 in SDDIF.SMPE.DISTMAC(#MOPT)

Thanks in advance.

Chris W. Angerer
State of Missouri, OA, DIS
cang...@mail.state.mo.us

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

Date: Wed, 28 Jul 1999 14:59:07 -0500
From: "Angerer, Chris" <cang...@mail.sdc.state.mo.us>
To: idm...@iuassn.com
Subject: RE: RHDCPARM assembly in 14.1
Message-ID:
<C18BE495D4DDD0118EA...@mail.sdc.state.mo.us>

Thanks a million that was it we needed the SYS1.MACLIB. In the past we
have not had to use the SYS1.MACLIB in our concatenation. Must have
something with being at OS390 2.6 or some other change....

Again thanks

-----Original Message-----
From: Michael Newman [mailto:Michae...@soph.com]
Sent: Wednesday, July 28, 1999 2:40 PM
To: 'idm...@iuassn.com'
Subject: RE: RHDCPARM assembly in 14.1

-----Original Message-----
From: Angerer, Chris
[mailto:cang...@mail.sdc.state.mo.us]
Sent: Wednesday, July 28, 1999 1:17 PM
To: IDMS-L
Subject: RHDCPARM assembly in 14.1

Has anyone experience any problems assembling a startup
module outside
of SMPE at release 14.1 9811 and OS390 2.5 ???
We are getting an error in #MOPT saying:

ASMA057E *** ERROR *** Undefined operation code -
#MOPT/SPLEVEL
ASMA435I ** WARNING ** Record 121 in
SDDIF.SMPE.DISTMAC(#MOPT)

Thanks in advance.

Chris W. Angerer
State of Missouri, OA, DIS
cang...@mail.state.mo.us

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

Date: Wed, 28 Jul 1999 16:52:40 -0400
From: "Hayden Weathersbee" <hay...@oir.state.sc.us>
To: idm...@iuassn.com
Subject: Re: RE: AREA UNLOCK / "Re-Lock"
Message-ID: <s79f46...@gw.state.sc.us>

I create a new dmcl also and use a disposition of old on the dd
statement.

Hayden Weathersbee, DBA
State of SC Budget & Control Board
Office of Information Resources
300 Gervais Street
Columbia, SC
(803) 737-9601
(803) 737-9559 FAX
hay...@oir.state.sc.us

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

Date: Wed, 28 Jul 1999 17:22:29 -0500

From: Bill....@ipaper.com
To: " - *idm...@iuassn.com" <idm...@iuassn.com>

Subject: Not IDD Owned
Message-ID: <0057390008022379000002L992*@MHS>

Does anyone know What causes this error when you are modifying a record.

I have the same element in two different records and one will modify and
the
other gives not idd owned. below is the history and detail of each
record. Sorry
for length. but thought it might be helpful to answer this question.
Thanks in advance.
Bill
MOD RECORD EBRA-PAY-CODE.
REPLACE RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
LINE IS 000100
*+ E DC601045 NOT IDD OWNED - ANY CHANGE IS INVALID
*+ W DC601017 FORWARD SPACING TO NEXT PERIOD
.
MOD RECORD EBRA-INPUT
.
REPLACE RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
LINE IS 001000
.
*+ RECORD NAME IS EBRA-PAY-CODE VERSION IS 1
*+ RECORD LENGTH IS 57
*+ PUBLIC ACCESS IS ALLOWED FOR ALL
*+ RECORD NAME SYNONYM IS EBRA-PAY-CODE VERSION 1
*+ PREFIX IS EPC-
*+ COPIED INTO SUBSCHEMA SSPPEI99 SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO SUBSCHEMA SSPPEI98 SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO MAP EBM0004 VERSION 1 WITHIN PANEL
EBM0004-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0006 VERSION 1 WITHIN PANEL
EBM0006-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0002 VERSION 1 WITHIN PANEL
EBM0002-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0009 VERSION 1 WITHIN PANEL
EBM0009-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0011 VERSION 1 WITHIN PANEL
EBM0011-OLMPANEL
*+ VERSION 1
*+ COPIED INTO PROGRAM EBD0001 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0007 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0008 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0010 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0012 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0006 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0002 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0003 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0009 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0011 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM HRD0035 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0005 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0004 VERSION 1
*+ TEXT IS ' M S'
*+ .
*+ RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
*+ LINE IS 000100
*+ LEVEL NUMBER IS 02
*+ PICTURE IS 9(3)
*+ USAGE IS DISPLAY
*+ ELEMENT LENGTH IS 3
*+ POSITION IS 1
*+ .
*+ RECORD NAME IS EBRA-INPUT VERSION IS 1
*+ RECORD LENGTH IS 83
*+ PUBLIC ACCESS IS ALLOWED FOR ALL
*+ RECORD NAME SYNONYM IS EBRA-INPUT VERSION 1
*+ PREFIX IS EI-
*+ COPIED INTO SUBSCHEMA SSPPEI99 SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO SUBSCHEMA SSPPEI98 SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO MAP EBM0004 VERSION 1 WITHIN PANEL
EBM0004-OLMPANEL
*+ VERSION 1
*+ COPIED INTO PROGRAM EBD0007 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0006 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0002 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0003 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0009 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0011 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0005 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0004 VERSION 1
*+ TEXT IS ' M S'
*+ .
*+ RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
*+ LINE IS 001000
*+ LEVEL NUMBER IS 02
*+ PICTURE IS X(3)
*+ USAGE IS DISPLAY
*+ ELEMENT LENGTH IS 3
*+ POSITION IS 53
*+ .

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

Date: Wed, 28 Jul 1999 17:30:22 -0500
From: Tim Gortner <TimGo...@soph.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Cc: "'Bill....@ipaper.com'" <Bill....@ipaper.com>
Subject: RE: Not IDD Owned
Message-ID: <8D8E2D0FA8FFD111960A0060B068A8E6304DD9@DALLAS>

It usually means the element is referenced by a map. This usually means
de-compiling the map to source code, deleting the map, then modifying
the element, re-generating the record, then re-compiling the map in
batch.

-----Original Message-----
From: Bill....@ipaper.com [mailto:Bill....@ipaper.com]
Sent: Wednesday, July 28, 1999 4:22 PM
To: - *idm...@iuassn.com
Subject: Not IDD Owned

Does anyone know What causes this error when you are modifying a record.

I have the same element in two different records and one will modify and

the
other gives not idd owned. below is the history and detail of each
record. Sorry
for length. but thought it might be helpful to answer this question.
Thanks in advance.
Bill
MOD RECORD EBRA-PAY-CODE.
REPLACE RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
LINE IS 000100
*+ E DC601045 NOT IDD OWNED - ANY CHANGE IS INVALID
*+ W DC601017 FORWARD SPACING TO NEXT PERIOD
.
MOD RECORD EBRA-INPUT
.
REPLACE RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
LINE IS 001000
.
*+ RECORD NAME IS EBRA-PAY-CODE VERSION IS 1
*+ RECORD LENGTH IS 57
*+ PUBLIC ACCESS IS ALLOWED FOR ALL
*+ RECORD NAME SYNONYM IS EBRA-PAY-CODE VERSION 1
*+ PREFIX IS EPC-
*+ COPIED INTO SUBSCHEMA SSPPEI99 SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO SUBSCHEMA SSPPEI98 SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO MAP EBM0004 VERSION 1 WITHIN PANEL
EBM0004-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0006 VERSION 1 WITHIN PANEL
EBM0006-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0002 VERSION 1 WITHIN PANEL
EBM0002-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0009 VERSION 1 WITHIN PANEL
EBM0009-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0011 VERSION 1 WITHIN PANEL
EBM0011-OLMPANEL
*+ VERSION 1
*+ COPIED INTO PROGRAM EBD0001 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0007 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0008 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0010 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0012 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0006 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0002 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0003 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0009 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0011 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM HRD0035 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0005 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0004 VERSION 1
*+ TEXT IS ' M S'
*+ .
*+ RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
*+ LINE IS 000100
*+ LEVEL NUMBER IS 02
*+ PICTURE IS 9(3)
*+ USAGE IS DISPLAY
*+ ELEMENT LENGTH IS 3
*+ POSITION IS 1
*+ .
*+ RECORD NAME IS EBRA-INPUT VERSION IS 1
*+ RECORD LENGTH IS 83
*+ PUBLIC ACCESS IS ALLOWED FOR ALL
*+ RECORD NAME SYNONYM IS EBRA-INPUT VERSION 1
*+ PREFIX IS EI-
*+ COPIED INTO SUBSCHEMA SSPPEI99 SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO SUBSCHEMA SSPPEI98 SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO MAP EBM0004 VERSION 1 WITHIN PANEL
EBM0004-OLMPANEL
*+ VERSION 1
*+ COPIED INTO PROGRAM EBD0007 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0006 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0002 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0003 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0009 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0011 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0005 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0004 VERSION 1
*+ TEXT IS ' M S'
*+ .
*+ RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
*+ LINE IS 001000
*+ LEVEL NUMBER IS 02
*+ PICTURE IS X(3)
*+ USAGE IS DISPLAY
*+ ELEMENT LENGTH IS 3
*+ POSITION IS 53
*+ .

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

Date: Wed, 28 Jul 1999 18:28:00 -0400
From: "Collins, John" <John.C...@ameriserve.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Not IDD Owned
Message-ID: <C7C2EDD6CB94D211A0050000E866FE262DD4FE@dalhq50>

Another alternative would be to remove the element from the maps it is
attached, regen the
maps, mod the element/record and add the element back.

Also, the record could be cloned to a new version, and the maps pointed
to
the new version
and regened temporarily. The original element/record modified, and then
the
maps pointed back to the original record.

-----Original Message-----
From: Tim Gortner [mailto:TimGo...@soph.com]
Sent: Wednesday, July 28, 1999 5:30 PM
To: 'idm...@iuassn.com'
Cc: 'Bill....@ipaper.com'
Subject: RE: Not IDD Owned

-----Original Message-----
From: Bill....@ipaper.com [mailto:Bill....@ipaper.com]
Sent: Wednesday, July 28, 1999 4:22 PM
To: - *idm...@iuassn.com
Subject: Not IDD Owned

Does anyone know What causes this error when you are modifying a record.

I have the same element in two different records and one will modify and

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

Date: Thu, 29 Jul 1999 08:19:25 +0930
From: "Cherlet, Gary (JISS)" <Cherle...@saugov.sa.gov.au>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Not IDD Owned

I usually create a new version of the record - and then beat it into
shape
making all the changes I want to. Then - if MAP owned I just type the
new
version number on the RECORDS screen in MAPC. Make sure you don't lose
suffix/prefix on the record synonym - as this changes the field names
and if
MAPC can't find the old field name on the new record it drops the field
from
the map.

Then, if schema owned, just change the version number of the SHARES
STRUCTURE specification and regenerate the subschemas.

All the Cobol and ADS programs that reference the record (either for
mapping
purposes and/or database access) will need to be re-compiled.

You can stop there, or if you like all of your records to be always VER
1 -
then delete the version 1 record and in IDD do:
MOD REC record-name Ver N NEW VER 1. All of the places where VER N is
referenced will now reference VER 1.

Cheers - Gary

-----Original Message-----
From: Bill....@ipaper.com [SMTP:Bill....@ipaper.com]
Sent: Thursday, 29 July 1999 7:52
To: - *idm...@iuassn.com
Subject: Not IDD Owned

Does anyone know What causes this error when you are modifying a record.

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

Date: Wed, 28 Jul 1999 15:47:49 -0700
From: "Johnson, Sara" <Sara.J...@hexcel.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Not IDD Owned
Message-ID:
<2BCA09803339D211AE04...@unknown-68-47.hexcel.com>

This record could be included in a schema, also. If you display the
record
without any restrictions, IDD will display as a comment any other entity

that 'owns' the record. You can also signon to OLQ and walk the
dictionary
using subschema IDMSNWKA and view the record (SR-036) to see the builder

code: 'get SR-036 where calc = (record name)'. The list of builder codes
is
in the Dictionary Structure Reference manual. For schema-owned records,
it
is not necessary to delete the schema, merely to disconnect the record
from
the schema temporarily while you make your changes. Some changes can
even be
made while the record is still connected. Hope this helps.

-----Original Message-----
From: Bill....@ipaper.com [mailto:Bill....@ipaper.com]
Sent: Wednesday, July 28, 1999 3:22 PM
To: - *idm...@iuassn.com
Subject: Not IDD Owned

Does anyone know What causes this error when you are
modifying a record.
I have the same element in two different records and one
will modify and the
other gives not idd owned. below is the history and detail
of each record. Sorry
for length. but thought it might be helpful to answer this
question.
Thanks in advance.
Bill
MOD RECORD EBRA-PAY-CODE.
REPLACE RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
LINE IS 000100
*+ E DC601045 NOT IDD OWNED - ANY CHANGE IS INVALID
*+ W DC601017 FORWARD SPACING TO NEXT PERIOD
.
MOD RECORD EBRA-INPUT
.
REPLACE RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
LINE IS 001000
.
*+ RECORD NAME IS EBRA-PAY-CODE VERSION IS 1
*+ RECORD LENGTH IS 57
*+ PUBLIC ACCESS IS ALLOWED FOR ALL
*+ RECORD NAME SYNONYM IS EBRA-PAY-CODE VERSION 1
*+ PREFIX IS EPC-
*+ COPIED INTO SUBSCHEMA SSPPEI99 SCHEMA HRSCHMT2
VERSION 99
*+ COPIED INTO SUBSCHEMA SSPPEI98 SCHEMA HRSCHMT2
VERSION 99
*+ COPIED INTO SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO MAP EBM0004 VERSION 1 WITHIN PANEL
EBM0004-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0006 VERSION 1 WITHIN PANEL
EBM0006-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0002 VERSION 1 WITHIN PANEL
EBM0002-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0009 VERSION 1 WITHIN PANEL
EBM0009-OLMPANEL
*+ VERSION 1
*+ COPIED INTO MAP EBM0011 VERSION 1 WITHIN PANEL
EBM0011-OLMPANEL
*+ VERSION 1
*+ COPIED INTO PROGRAM EBD0001 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0007 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0008 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0010 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0012 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0006 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0002 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0003 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0009 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0011 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM HRD0035 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0005 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0004 VERSION 1
*+ TEXT IS ' M S'
*+ .
*+ RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
*+ LINE IS 000100
*+ LEVEL NUMBER IS 02
*+ PICTURE IS 9(3)
*+ USAGE IS DISPLAY
*+ ELEMENT LENGTH IS 3
*+ POSITION IS 1
*+ .
*+ RECORD NAME IS EBRA-INPUT VERSION IS 1
*+ RECORD LENGTH IS 83
*+ PUBLIC ACCESS IS ALLOWED FOR ALL
*+ RECORD NAME SYNONYM IS EBRA-INPUT VERSION 1
*+ PREFIX IS EI-
*+ COPIED INTO SUBSCHEMA SSPPEI99 SCHEMA HRSCHMT2
VERSION 99
*+ COPIED INTO SUBSCHEMA SSPPEI98 SCHEMA HRSCHMT2
VERSION 99
*+ COPIED INTO SCHEMA HRSCHMT2 VERSION 99
*+ COPIED INTO MAP EBM0004 VERSION 1 WITHIN PANEL
EBM0004-OLMPANEL
*+ VERSION 1
*+ COPIED INTO PROGRAM EBD0007 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0006 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0002 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0003 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0009 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0011 VERSION 1
*+ TEXT IS ' S'
*+ COPIED INTO PROGRAM EBD0005 VERSION 1
*+ TEXT IS ' M S'
*+ COPIED INTO PROGRAM EBD0004 VERSION 1
*+ TEXT IS ' M S'
*+ .
*+ RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
*+ LINE IS 001000
*+ LEVEL NUMBER IS 02
*+ PICTURE IS X(3)
*+ USAGE IS DISPLAY
*+ ELEMENT LENGTH IS 3
*+ POSITION IS 53
*+ .

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

Date: Wed, 28 Jul 1999 18:48:54 -0400
From: "Hugh Laderman" <hu...@laderman.com>
To: <idm...@iuassn.com>
Subject: Re: Not IDD Owned
Message-ID: <004f01bed94b$5fdac520$27faa4d8@oemcomputer>

Hi Bill

Because both records are "schema-owned" and "map-owned", you should get
the
exact same result (NOT IDD OWNED) when you try to REPLACE REC EL (which
is
an implicit delete and add). On the other hand, you should be able to
simply
modify the record/record element syntax without deleting fields, and not

receive the error message.

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

-----Original Message-----
From: Bill....@ipaper.com <Bill....@ipaper.com>
To: - *idm...@iuassn.com <idm...@iuassn.com>

Date: Wednesday, July 28, 1999 6:26 PM
Subject: Not IDD Owned

>Does anyone know What causes this error when you are modifying a
record.
>I have the same element in two different records and one will modify
and
the
>other gives not idd owned. below is the history and detail of each
record.
Sorry
>for length. but thought it might be helpful to answer this question.
>Thanks in advance.
>Bill
>MOD RECORD EBRA-PAY-CODE.
>REPLACE RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
> LINE IS 000100
>*+ E DC601045 NOT IDD OWNED - ANY CHANGE IS INVALID
>*+ W DC601017 FORWARD SPACING TO NEXT PERIOD
> .
>MOD RECORD EBRA-INPUT
> .
>REPLACE RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
> LINE IS 001000
> .
>*+ RECORD NAME IS EBRA-PAY-CODE VERSION IS 1
>*+ RECORD LENGTH IS 57
>*+ PUBLIC ACCESS IS ALLOWED FOR ALL
>*+ RECORD NAME SYNONYM IS EBRA-PAY-CODE VERSION 1
>*+ PREFIX IS EPC-
>*+ COPIED INTO SUBSCHEMA SSPPEI99 SCHEMA HRSCHMT2 VERSION 99
>*+ COPIED INTO SUBSCHEMA SSPPEI98 SCHEMA HRSCHMT2 VERSION 99
>*+ COPIED INTO SCHEMA HRSCHMT2 VERSION 99
>*+ COPIED INTO MAP EBM0004 VERSION 1 WITHIN PANEL
EBM0004-OLMPANEL
>*+ VERSION 1
>*+ COPIED INTO MAP EBM0006 VERSION 1 WITHIN PANEL
EBM0006-OLMPANEL
>*+ VERSION 1
>*+ COPIED INTO MAP EBM0002 VERSION 1 WITHIN PANEL
EBM0002-OLMPANEL
>*+ VERSION 1
>*+ COPIED INTO MAP EBM0009 VERSION 1 WITHIN PANEL
EBM0009-OLMPANEL
>*+ VERSION 1
>*+ COPIED INTO MAP EBM0011 VERSION 1 WITHIN PANEL
EBM0011-OLMPANEL
>*+ VERSION 1
>*+ COPIED INTO PROGRAM EBD0001 VERSION 1
>*+ TEXT IS ' S'
>*+ COPIED INTO PROGRAM EBD0007 VERSION 1
>*+ TEXT IS ' M S'
>*+ COPIED INTO PROGRAM EBD0008 VERSION 1
>*+ TEXT IS ' S'
>*+ COPIED INTO PROGRAM EBD0010 VERSION 1
>*+ TEXT IS ' S'
>*+ COPIED INTO PROGRAM EBD0012 VERSION 1
>*+ TEXT IS ' S'
>*+ COPIED INTO PROGRAM EBD0006 VERSION 1
>*+ TEXT IS ' M S'
>*+ COPIED INTO PROGRAM EBD0002 VERSION 1
>*+ TEXT IS ' M S'
>*+ COPIED INTO PROGRAM EBD0003 VERSION 1
>*+ TEXT IS ' M S'
>*+ COPIED INTO PROGRAM EBD0009 VERSION 1
>*+ TEXT IS ' M S'
>*+ COPIED INTO PROGRAM EBD0011 VERSION 1
>*+ TEXT IS ' M S'
>*+ COPIED INTO PROGRAM HRD0035 VERSION 1
>*+ TEXT IS ' S'
>*+ COPIED INTO PROGRAM EBD0005 VERSION 1
>*+ TEXT IS ' M S'
>*+ COPIED INTO PROGRAM EBD0004 VERSION 1
>*+ TEXT IS ' M S'
>*+ .
>*+ RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
>*+ LINE IS 000100
>*+ LEVEL NUMBER IS 02
>*+ PICTURE IS 9(3)
>*+ USAGE IS DISPLAY
>*+ ELEMENT LENGTH IS 3
>*+ POSITION IS 1
>*+ .
>*+ RECORD NAME IS EBRA-INPUT VERSION IS 1
>*+ RECORD LENGTH IS 83
>*+ PUBLIC ACCESS IS ALLOWED FOR ALL
>*+ RECORD NAME SYNONYM IS EBRA-INPUT VERSION 1
>*+ PREFIX IS EI-
>*+ COPIED INTO SUBSCHEMA SSPPEI99 SCHEMA HRSCHMT2 VERSION 99
>*+ COPIED INTO SUBSCHEMA SSPPEI98 SCHEMA HRSCHMT2 VERSION 99
>*+ COPIED INTO SCHEMA HRSCHMT2 VERSION 99
>*+ COPIED INTO MAP EBM0004 VERSION 1 WITHIN PANEL
EBM0004-OLMPANEL
>*+ VERSION 1
>*+ COPIED INTO PROGRAM EBD0007 VERSION 1
>*+ TEXT IS ' S'
>*+ COPIED INTO PROGRAM EBD0006 VERSION 1
>*+ TEXT IS ' S'
>*+ COPIED INTO PROGRAM EBD0002 VERSION 1
>*+ TEXT IS ' S'
>*+ COPIED INTO PROGRAM EBD0003 VERSION 1
>*+ TEXT IS ' S'
>*+ COPIED INTO PROGRAM EBD0009 VERSION 1
>*+ TEXT IS ' S'
>*+ COPIED INTO PROGRAM EBD0011 VERSION 1
>*+ TEXT IS ' S'
>*+ COPIED INTO PROGRAM EBD0005 VERSION 1
>*+ TEXT IS ' M S'
>*+ COPIED INTO PROGRAM EBD0004 VERSION 1
>*+ TEXT IS ' M S'
>*+ .
>*+ RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1
>*+ LINE IS 001000
>*+ LEVEL NUMBER IS 02
>*+ PICTURE IS X(3)
>*+ USAGE IS DISPLAY
>*+ ELEMENT LENGTH IS 3
>*+ POSITION IS 53
>*+ .

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

Date: Wed, 28 Jul 1999 19:47:04 EDT
From: ARCH...@aol.com
To: idm...@iuassn.com
Subject: Looking for David Murry
Message-ID: <8da9ec23...@aol.com>

Hello Everyone:

I am trying to locate a David Murray, he used to work for DANA
Corporation
and then I believe that he went to Tultex.

David if you Monitor this list please Contact me Bill Allen at
ARCH...@aol.com or Donald Martin at DANA at 765-973-6106 or E-mail him
at
Donald...@dana.com.

It is very important that we get in touch with you as soon as possible.

If anyone knows where David is or how to contact him it would be greatly

appreciated.

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

Date: Wed, 28 Jul 1999 17:10:41 -0700
From: "Steven Bertrand" <Stev...@fox.com>
To: idm...@iuassn.com
Subject: Another possible upgrade site
Message-ID: <s79f39...@foxinc.com>

By way of an introduction:
My name is Steven Bertrand=20
I have just been brought into 20Th Century Fox studios to=20
evaluate the best way to get them Y2K compatible on their=20
IDMS system. They are currently running 12.01 at the=20
9503 maint level. It is most likely I will recommend an upgrade to=20
14.01. I would be interested in communicating with any other=20
sites that are currently or have recently upgraded 12.01 to
14.0/14.01=20
I have just subscribed to this list and will be monitoring it from now
=
on.=20
Please feel free to e-mail me directly if you so choose=20
Stev...@fox.com=20
If this message is not be quite within the guidelines for=20
acceptable messages to the list server please forgive me=20
this one transgression. I will not do it again. =20
Thanks
Steven B.=20

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

Date: Wed, 28 Jul 1999 21:13:36 -0500
From: Chris Hoelscher <hoel...@flash.net>
To: idm...@iuassn.com
Subject: Re: Another possible upgrade site
Message-ID: <1999072903...@ares.flash.net>

Steve - there IS something to be said for staying within the same
release.
If Y2K compliance is all the client is looking for, you MIGHT suggest
9809
of 12.01. What is their longterm goal for idms? if they are comfortable
with the funtionality of 12.01 and do not want at this late date to
begin
testing an entire new release, then perhaps GJ9809 of 12.01 is the
answer.
My biggest client (56 prod regions, 20M trans/day) is satisfied as to
9809's Y2K compliancy, and is in NO hurry to repeat the 10.21->12.01
migration (although, admittedly, a 12->14.x would be trivial, but say
the
word migrate to the client and looks of panic enter their faces,
especially
when the outsources has put a oct 1 freeze on software upgrades, and the

clirnt themselves have an internal nov 1 <?> freeze date.

Having said this, the folks who HAVE installed 14.1 are very happy with
the
results. it was easy to install, and seems to be meeting the needs of
the
sites who specifically requested the features that 14.1 addresses.

but, you asked for opinions, so here is mine. At this late date, i would

apply 9506 maint, 9601, 9607, 9707, 9809 maint to the 9503 apar tape you

installed (or, base install 9506 and work from there). I believe it
will
be a quicker path to Y2K compliancy since you are working within the
same
release. Had you asked the question 3 months ago, I would have opted for

14.0 / 14.1

chris hoelscher
sophisticated business systems

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

Date: Thu, 29 Jul 1999 01:18:12 -0500
From: "Mowbray, Sam A" <sam.m...@eds.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Another possible upgrade site
Message-ID: <FB42153F3C41D111A12500805F0D726E02173E4F@AUADM101>

Steve/Chris,

We transferred a number of sites a number of years ago from MSP to MVS
and
for one site this included upgrading from 10.214 to 12.01 9506. Due to
the
time involved in testing and upgrading the clients don't wish to
re-visit
the IDMS upgrade path for a while. We have applied Year 2000
maintenance
for 9506 and the sites have successfully tested IDMS and their
applications
(twice) on a year 2000 IPL'd machine with no problems. Besides having
to
put up with CA complaining about "that old release", 12.01 will be
supported
until 2001. We will look at upgrading to 14.1 by then.

Just a differing opinion...

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

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

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

Chris Hoelscher

unread,

Jul 30, 1999, 3:00:00 AM7/30/99

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

IDMS-L Fri, 30 Jul 1999 Volume 1 :
Number 40

In this issue:

Re: Another possible upgrade site

RE: AREA UNLOCK

Re: Another possible upgrade site

Is anyone successfully running OPAL over low-speed WAN links,
ple
ase ?
PREFETCH experience

Re: Another possible upgrade site
RE: Another possible upgrade site

RE: AREA UNLOCK
Old releases and Y2K (Again)
Re[2]: AREA UNLOCK
Re: Not IDD Owned

Re: Not IDD Owned
RE: Not IDD Owned
Re: Not IDD Owned

Re: Not IDD Owned
Re: Not IDD Owned

RE: Another possible upgrade site

RE: Not IDD Owned
Re: PREFETCH experience
RE: Not IDD Owned
ASG's Replication Suite
updating CLISTIN datasets
RE: Not IDD Owned
RE: ASG's Replication Suite
Re: updating CLISTIN datasets
DARS replication software (ISP)
RE: updating CLISTIN datasets

RE:DBAN on dict files

Hot Backups

RE: DBAN on dict files

RE:DBAN on dict files
S019 abends
RE: AREA UNLOCK - multi-area-files
Re: S019 abends
RE: S019 abends
RE: S019 abends
RE: AREA UNLOCK - multi-area-files
RE: Hot Backups - We decided against.
Re: S019 abends
RE: AREA UNLOCK - multi-area-files

RE: DBAN on dict files

Re: S019 abends
0360
RE: AREA UNLOCK - multi-area-files

RE:DBAN on dict files

RE: 0360
Re: 0360

RE: DBAN on dict files

RE: Hot Backups - We decided against.
Re: updating CLISTIN datasets
RE: Not IDD Owned
Re: 0360

Re: DBAN on dict files

Re: updating CLISTIN datasets
RE: Hot Backups

Re: DBAN on dict files

NO OR52 FOR THIS INDEX SET IX-RESOURCE...BUT STILL ALIVE

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

Date: Thu, 29 Jul 1999 04:11:00 +0100
From: ("leslie a jordan") <LCC/JOR...@aeilogis.com>

To: idm...@iuassn.com
Subject: Re: Another possible upgrade site

Message-ID: <NAd70e98...@aeilogis.com>

Stephen - I am currently going through the rel 12.01 upgrade suggested
by
Chris. We are
a VM site currently on 9601, with 9809 in test. I have applied 9607,
9707, and
9809. The
only major problem I hit was a couple of bad ptfs on 9707 that gave me
problems when i brought the system up, but they were sorted on 9809 (and
I
believe one was specific to vm). Other than that, it has been pretty
smooth
and I hope to have the production cv on 9809 by the end of August (long
delay
due to holiday time..).

Leslie
A. Jordan (DBA)

Air
Express Intl

Staines, UK

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

Date: Thu, 29 Jul 1999 09:37:58 +0100
From: brian.wig...@bt.com

To: idm...@iuassn.com
Subject: RE: AREA UNLOCK

Message-ID:
<DBE5DC3EE4EDD211986...@mclmsent09.lon.bt.com>

Does this trick work for multi-area files? Will it reset the indicator
for
all the areas in the file?
Brian Wigglesworth
BT

> -----Original Message-----
> From: Norris, Greg [SMTP:Greg_...@mail.dor.state.mo.us]
> Sent: 28 July 1999 17:00
> To: 'idm...@iuassn.com'
> Subject: RE: AREA UNLOCK
>

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

Date: Thu, 29 Jul 1999 10:54:31 +0100
From: <Martijn...@mail.ing.nl>

To: idm...@iuassn.com
Subject: Re: Another possible upgrade site

Message-ID: <00044A8...@mail.ing.nl>

Hi Steven,

As a systems programmer upgrading from 12.01 (genlevel 9503) to
14.0
(genlevel 9711) I already sympathize with you.
It depends a bit on what you are running. IDMS 12.01 Base can be
made
compliant (see TCC APAR# GI93360) can be made compliant, but Tools
like ADS/Alive & DML/O (in our case) can not (if I am still
correctly
informed).
We had no choice when we started this, but if you have, considering

the time left, I would strongly consider staying on R12.01.

Al of our CV's have been running 14.0 now for a long time, except
one:
the production CV, which runs about 1 million rununits per day,
Multitasking. Workload comes 80% from CICS ERUS, 20% DC/ADS. Until
now, I have had to backout R14 on that system twice after serious
problems. So beware.

Regards, Martijn Schouw
ING Bank, The Netherlands

____________________________ Antwoord-separator
________________________________
Onderwerp: Another possible upgrade site
Auteur: idm...@iuassn.com in INET-1
Datum: 7/28/99 5:10 PM

By way of an introduction:
My name is Steven Bertrand

I have just been brought into 20Th Century Fox studios to

evaluate the best way to get them Y2K compatible on their

IDMS system. They are currently running 12.01 at the

9503 maint level. It is most likely I will recommend an upgrade to

14.01. I would be interested in communicating with any other

sites that are currently or have recently upgraded 12.01 to 14.0/14.01

I have just subscribed to this list and will be monitoring it from now

on.

Please feel free to e-mail me directly if you so choose

Stev...@fox.com

If this message is not be quite within the guidelines for

acceptable messages to the list server please forgive me

this one transgression. I will not do it again.

Thanks
Steven B.

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

Date: Thu, 29 Jul 1999 09:57:36 +0100

From: "Stewart, Jeremy" <Stew...@AWA-CPO.COM>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: Is anyone successfully running OPAL over low-speed WAN links,
ple
ase ?
Message-ID: <C8C547D6EBA3D111BBFF00805FA604547AD656@BASEXCHANGE>

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: Thu, 29 Jul 1999 13:15:44 +0200
From: Luc_De...@amsinc.com
To: idm...@iuassn.com
Subject: PREFETCH experience
Message-ID: <852567BD.0...@ams-central-gate-5a.amsinc.com>

Dear all,

recently there have been messages floating around regarding PREFETCH.
We
are planning on implementing and so far our test looks promising. We
are
on Rel 14.0 Genlevel 9711.

My questions :

What is your experience, are your running with it , have you been
running
with it (and why did you disabled it, is (will) there a solution (be)
available and in what time frame ?)

Shared Cache & PREFETCH looks like there not designed to work together,
but
I could not find this back saying so explicitly. any confirmation ?

Regards,
Luc De Peuter, AMS
E-mail : Luc_De...@mail.amsinc.com

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

Date: Thu, 29 Jul 1999 07:53:54 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: Re: Another possible upgrade site
Message-ID: <852567BD.0...@d54mta03.raleigh.ibm.com>

it is my understanding that maint tape 9712 for idms-tools *is* Y2K
compliant
and will run with 9707+ (if not all) releases of 12.01 (9407+)

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

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

Date: Thu, 29 Jul 1999 08:24:08 -0400
From: "Parker, Lawrence" <lawrenc...@lmco.com>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Another possible upgrade site
Message-ID:

<60875A437C39D211BE86...@emss03m03.orl.lmco.com>

I will verify this as a correct statement. We currently have a customer

running 9712 of IDMS Tools (the CA specified Y2K version) with IDMS
9707.
We have not experienced any problems.

Larry Parker
Lockheed Martin Corp.

-----Original Message-----
From: hoel...@us.ibm.com [mailto:hoel...@us.ibm.com]
Sent: Thursday, July 29, 1999 07:54
To: idm...@iuassn.com
Subject: Re: Another possible upgrade site

it is my understanding that maint tape 9712 for idms-tools *is* Y2K
compliant
and will run with 9707+ (if not all) releases of 12.01 (9407+)

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

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

Date: Thu, 29 Jul 1999 07:28:51 -0500

From: "Norris, Greg" <Greg_...@mail.dor.state.mo.us>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: AREA UNLOCK
Message-ID:
<27E9B6F4DA4CD211BB68...@mail.dor.state.mo.us>

Unfortunately, I don't know the answer in this instance... we aren't
using
multi-area files, so I've never had had the opportunity to try it. I
suspect it won't (I'm assuming that file operations occur "underneath"
area
operations), but that's really just a guess.

> -----Original Message-----
> From: brian.wig...@bt.com [mailto:brian.wig...@bt.com]
> Sent: 29 July, 1999 3:38 AM
> To: idm...@iuassn.com
> Subject: RE: AREA UNLOCK
>
>

> Does this trick work for multi-area files? Will it reset the
> indicator for
> all the areas in the file?
> Brian Wigglesworth
> BT

>
> > -----Original Message-----
> > From: Norris, Greg [SMTP:Greg_...@mail.dor.state.mo.us]
> > Sent: 28 July 1999 17:00
> > To: 'idm...@iuassn.com'
> > Subject: RE: AREA UNLOCK
> >

> > "DCMT VARY FILE segment.XXXX ACTIVE", where XXXX is the
> name of the first
> > file which makes up the area. This resets the update-lock
> indicator,
> > which
> > should allow you to vary the area.

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

Date: Thu, 29 Jul 1999 15:12:33 +0100
From: j...@maerskdata.dk
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: Old releases and Y2K (Again)
Message-ID: <412567BD.0...@mdcsmtp.cph.dnk.maersknet.com>

I just returned to the IDMS-society.

I have got a new client, and have discovered that they are running
12.0/9607 on VSE.

According to the official CA-Y2K it should be sufficient to put on
all the APAR's that will make it a 9712-installation.

Is this information still valid ??

Due to some future projects it might be of interest to go to Rel. 14.

What is the steps in going from 12.0 to 14 ??
(In general terms).

I know this has been discussed from time to time, but it hasn't had
my interest until last week, so I haven't paid much attention to it.

Thanks

Jesper Sleth

SLETH IT

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

Date: Thu, 29 Jul 1999 8:54 -0500

From: "Steve Franzon" <Steve....@alltel.com>
To: "idm...@iuassn.com" <idm...@iuassn.com>

Subject: Re[2]: AREA UNLOCK
Message-ID: <199907290758...@alltel.com>

Yes - it will work for a multi-area file. (14.0 - 9810 anyway).

Steve Franzon

______________________________ Reply Separator
_________________________________
Subject: RE: AREA UNLOCK
Author: idm...@iuassn.com at internet
Date: 07/29/1999 3:37 AM

Does this trick work for multi-area files? Will it reset the indicator
for
all the areas in the file?
Brian Wigglesworth
BT

> -----Original Message-----
> From: Norris, Greg [SMTP:Greg_...@mail.dor.state.mo.us]
> Sent: 28 July 1999 17:00
> To: 'idm...@iuassn.com'
> Subject: RE: AREA UNLOCK
>

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

Date: Thu, 29 Jul 1999 07:47:04 -0600
From: Bob Wiklund <wik...@tiburontech.com>
To: IDM...@iuassn.com, Bill....@ipaper.com

Subject: Re: Not IDD Owned

Message-ID: <37A05B58...@tiburontech.com>

This is a multi-part message in MIME format.
--------------68C320982E23114B03DF046B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bill,

Have you verified that you are replacing the correct line number? To
replace like named record elements, the line numbers must be identical.

On the Replace that fails, it seems the line number is different from
the Replace that works (Line 000100 vs 001000).

Bob

--------------68C320982E23114B03DF046B
Content-Type: text/x-vcard; charset=us-ascii;
name="wiklund.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Bob Wiklund
Content-Disposition: attachment;
filename="wiklund.vcf"

begin:vcard
n:Wiklund;Bob
tel;fax:303 984-8569
tel;work:303 984-8569
x-mozilla-html:TRUE
org:Tiburon Technologies
adr:;;;;;;
version:2.1
email;internet:wik...@tiburontech.com
title:Senior Consultant
x-mozilla-cpt:;-1
fn:Bob Wiklund
end:vcard

--------------68C320982E23114B03DF046B--

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

Date: Thu, 29 Jul 1999 09:52:16 -0500

From: Bill....@ipaper.com
To: " - *idm...@iuassn.com" <idm...@iuassn.com>

Subject: Re: Not IDD Owned

Message-ID: <0057390008044849000002L992*@MHS>

Line numbers are correct. verified!

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

Date: Thu, 29 Jul 1999 11:01:26 -0400
From: "Harris, Carol" <Carol....@CAI.COM>
To: idm...@iuassn.com

Subject: RE: Not IDD Owned

Message-ID: <4C094419B0E6D2119FF...@usilmse1.cai.com>

Bill,
Do I understand correctly --- EBRA-PAY-CODE is an element and a record?
This could get nasty.

The reason for the different messages: The rec element EBRA-PAY-CODE in

ERBA-PAY-CODE record is actually used on the map - therefore it cannot
be
modified. IDD won't allow you to change the description of an element
in
use on a map - because the map's view of the record and field would
differ
from the record definition in the IDD - and that would create
inconsistent
results at runtime. If the field is used in a map record, but not on
the
map itself - you can change the element description -but you should
recompile the map and all programs using the map. (In fact, IDD warns
you
to recompile the map and programs.)

Bill, but I usually recommend against attaching a schema record to a map
-
for the reasons you have encountered - it. Progammers like it, because
they
don't have to move the data from the database record to the map record
fields. But then, the DBA's must decompile the map or create a new
version
of the record and tie it to the map to change the schema record. DO
NOT
delete the record from the map, or you lose the all field definitions
associated with the record's elements on the map. (In 10.2, you could

drop a record from the map and the fields definitions would remain -
this is
not true in 12.0!)

Carol L. Harris
Computer Associates
Client Education Services
har...@cai.com
Voice :407-661-5989
Fax :407-660-8853

Visit CA Education Services at:
http://www.cai.com/profserv/educate.htm

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

Date: Thu, 29 Jul 1999 09:26:50 -0500

From: Bill....@ipaper.com
To: " - *idm...@iuassn.com" <idm...@iuassn.com>

Subject: Re: Not IDD Owned

Message-ID: <0057390008043390000002L902*@MHS>

Thanks for all the possible solutions. I have checked the SR-flag-2-042
fields
all are
binary zeros. I'm still confused because I have discovered this occurs
in the
same record
with no changes to the length of the element. (no changes at all). Yet
it works
on some
and others it don't.( as you can see below. ) There are work around's
as all
of you have
suggested, and thanks to all who responded!
I was just curious as to what was the difference between these elements
and
records that
causes this error?
MODIFY

RECORD NAME IS EBRA-PAY-CODE VERSION IS 1

.
REPLACE RECORD ELEMENT IS EBRA-PAY-CODE VERSION 1

LINE IS 000100
*+ E DC601045 NOT IDD OWNED - ANY CHANGE IS INVALID

WORD 3

*+ W DC601017 FORWARD SPACING TO NEXT PERIOD

WORD 3
.
REPLACE RECORD ELEMENT IS EBRA-PAY-CODE-DESC VERSION 1
LINE IS 000200

*+ E DC601045 NOT IDD OWNED - ANY CHANGE IS INVALID

WORD 3

*+ W DC601017 FORWARD SPACING TO NEXT PERIOD

WORD 3
.
REPLACE RECORD ELEMENT IS ICC-CODE VERSION 1
LINE IS 000300
.
REPLACE RECORD ELEMENT IS JV-TRANS-NBR VERSION 1
LINE IS 000400
.
REPLACE RECORD ELEMENT IS SORT-SEQUENCE VERSION 1
LINE IS 000500
.

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

Date: Thu, 29 Jul 1999 11:03 -0500
From: "Steve Franzon" <Steve....@alltel.com>
To: "idm...@iuassn.com" <idm...@iuassn.com>

Subject: Re: Not IDD Owned

Message-ID: <199907291007...@alltel.com>

Is the element a control field (CALC key, set/index sort key) in
the
schema for the record that failed? IDD will not allow you to
replace a
record element that is a control field.

Steve Franzon

______________________________ Reply Separator
_________________________________
Subject: Not IDD Owned
Author: idm...@iuassn.com at internet
Date: 07/28/1999 5:22 PM

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

Date: Thu, 29 Jul 1999 17:09:14 +0200
From: IESD <in1...@juliusbaer.com>

To: idm...@iuassn.com
Subject: Re: Not IDD Owned

Message-ID: <1999072915...@mailhost.ip-plus.net>

Why is one element X(3) and the other 9(3)? Or is that the change you
are trying to make?.
Is the element in EBRA-PAY-CODE part of a CALC or Sortkey?

Chris Trayler

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

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

Date: Thu, 29 Jul 1999 08:12:10 -0700
From: "Lee, Brian" <bl...@pac.bluecross.ca>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Another possible upgrade site

Message-ID: <FF09222003FAD211A07900A024B261F08ED7@PACEXCH>

Hi Steven,

We've upgraded from a 12.0 system (9308) to 14.0 (9711). The upgrade
was
relatively smooth. The only thing we were worried about was the security

system, but with proper testing this was not a issue. For you coming
from
9503, the upgrade should be even smoother.

Brian Lee
Database Administrator - Technical Services

[ Pacific Blue Cross
PO Box 7000, Vancouver, BC. V6B 4E1
Telephone: (604) 419-2532
Fax: (604) 419-2990

> -----Original Message-----
> From: Steven Bertrand [SMTP:Stev...@fox.com]
> Sent: Wednesday, July 28, 1999 5:11 PM
> To: idm...@iuassn.com
> Subject: Another possible upgrade site
>

> By way of an introduction:
> My name is Steven Bertrand

> I have just been brought into 20Th Century Fox studios to

> evaluate the best way to get them Y2K compatible on their

> IDMS system. They are currently running 12.01 at the

> 9503 maint level. It is most likely I will recommend an upgrade to

> 14.01. I would be interested in communicating with any other

> sites that are currently or have recently upgraded 12.01 to 14.0/14.01

> I have just subscribed to this list and will be monitoring it from
now
> on.

> Please feel free to e-mail me directly if you so choose

> Stev...@fox.com

> If this message is not be quite within the guidelines for

> acceptable messages to the list server please forgive me

> this one transgression. I will not do it again.

> Thanks
> Steven B.

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

Date: Thu, 29 Jul 1999 10:31:33 -0500

From: Bill....@ipaper.com
To: " - *idm...@iuassn.com" <idm...@iuassn.com>

Subject: RE: Not IDD Owned

Message-ID: <0057390008047418000002L982*@MHS>

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

Date: Thu, 29 Jul 1999 11:39:08 -0400
From: "Mark CONS:Caffrey" <DBA...@mbusa.com>
To: <Luc_De...@amsinc.com>, <Idm...@iuassn.com>
Subject: Re: PREFETCH experience
Message-ID: <s7a03d...@mbna.com>

Luc,
We did some benchmarking a few years back. I was not directly involved,
=
but the results were that Cache, by itself, was faster than PREFETCH. It
=
was also true that they did not work well together. I do not have any
more =
specifics than that, though...sorry.
Mark

>>> <Luc_De...@amsinc.com> 07/29 7:15 AM >>>

Dear all,

recently there have been messages floating around regarding PREFETCH.
We
are planning on implementing and so far our test looks promising. We
are
on Rel 14.0 Genlevel 9711.

My questions :

What is your experience, are your running with it , have you been
running
with it (and why did you disabled it, is (will) there a solution (be)
available and in what time frame ?)

Shared Cache & PREFETCH looks like there not designed to work together,
=
but
I could not find this back saying so explicitly. any confirmation ?

Regards,
Luc De Peuter, AMS
E-mail : Luc_De...@mail.amsinc.com=20

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

Date: Thu, 29 Jul 1999 10:44:21 -0500

From: Bill....@ipaper.com
To: " - *idm...@iuassn.com" <idm...@iuassn.com>

Subject: RE: Not IDD Owned

Message-ID: <0057390008048199000002L992*@MHS>

drop a record from the map and the fields definitions would remain -
this is
not true in 12.0!)

Carol L. Harris
Computer Associates
Client Education Services
har...@cai.com
Voice :407-661-5989
Fax :407-660-8853

Visit CA Education Services at:
http://www.cai.com/profserv/educate.htm

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

Date: Thu, 29 Jul 1999 11:45:07 -0400
From: "Mark CONS:Caffrey" <DBA...@mbusa.com>
To: <Idm...@iuassn.com>
Subject: ASG's Replication Suite
Message-ID: <s7a03e...@mbna.com>

Is there anyone that is using Allen Systems Group's Replication Suite
that =
can give us information about its benefits, pitfalls, pros and cons,
etc.?
We would greatly appreciate any info. We are basically looking to use it
=
for Change Data Capture to move data from operational systems to a Data
=
Warehouse.
Thanks in advance....
Mark Caffrey

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

Date: Thu, 29 Jul 1999 11:56:02 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: updating CLISTIN datasets
Message-ID: <852567BD.0...@d54mta03.raleigh.ibm.com>

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: Thu, 29 Jul 1999 12:04:34 -0400
From: "Harris, Carol" <Carol....@CAI.COM>
To: idm...@iuassn.com

Subject: RE: Not IDD Owned

Message-ID: <4C094419B0E6D2119FF...@usilmse1.cai.com>

Bill,
If you use the IDD and display the element, it will tell you which maps
utilize the element - then you could play the version number game with
only
those maps that display the element. This would save you some work.

Carol L. Harris
Computer Associates
Client Education Services
har...@cai.com
Voice :407-661-5989
Fax :407-660-8853

Visit CA Education Services at:
http://www.cai.com/profserv/educate.htm

-----Original Message-----
From: Bill....@ipaper.com [SMTP:Bill....@ipaper.com]
Sent: Thursday, July 29, 1999 11:44 AM
To: - *idm...@iuassn.com
Subject: RE: Not IDD Owned

I think Carol has the answer! Thanks! (below) Thanks to all that
responded.
For clarification Yes I have a request to change a calc key from
9(3) to x(3).
CA has
verified that all that needs to be done is to change element and all
records
and maps
it occurs in. Of course all applications referencing this will have
to be
fixed. I Thought
maybe I could avoid the hassle of either (batch)punching maps and
deleting
them, make
changes, add them back, or (online) creating new version of record
and
recompiling map.
But it appears that is the only way!
Thanks again for all the responses!
The reason for the different messages: The rec element
EBRA-PAY-CODE in
ERBA-PAY-CODE record is actually used on the map - therefore it
cannot be
modified. IDD won't allow you to change the description of an
element in
use on a map - because the map's view of the record and field would
differ
from the record definition in the IDD - and that would create
inconsistent
results at runtime. If the field is used in a map record, but not
on the
map itself - you can change the element description -but you should
recompile the map and all programs using the map. (In fact, IDD
warns you
to recompile the map and programs.)

Bill, but I usually recommend against attaching a schema record to a
map -
for the reasons you have encountered - it. Progammers like it,
because they
don't have to move the data from the database record to the map
record
fields. But then, the DBA's must decompile the map or create a new
version
of the record and tie it to the map to change the schema record.
DO NOT
delete the record from the map, or you lose the all field
definitions
associated with the record's elements on the map. (In 10.2, you
could
drop a record from the map and the fields definitions would remain -
this is
not true in 12.0!)

Carol L. Harris
Computer Associates
Client Education Services
har...@cai.com
Voice :407-661-5989
Fax :407-660-8853

Visit CA Education Services at:
http://www.cai.com/profserv/educate.htm

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

Date: Thu, 29 Jul 1999 12:18:39 -0400
From: "McMahon, Rick" <Rick.M...@fns.usda.gov>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: ASG's Replication Suite
Message-ID:
<C1D845867A7ED211A0D...@199.136.154.fns.usda.gov>

Mark,

We just finished an evaluation of the product and have found it to be
quite
useful in creating an Oracle data warehouse. If your mapping from IDMS
to
the data warehouse tables is one-to-one, there is no coding involved.
In
our instance, the mappings were not one-to-one, so I had to write Oracle

triggers to create another set of tables in the desired format from the
ones
created by Replication Suite.

One of the main reasons we are considering it is because of how it uses
the
journals to replicate IDMS data. Our application unfortunately does not

capture deletes and modifies to certain records, and so any home grown
application for creating the data warehouse must constantly do a compare
of
the data warehouse data to IDMS data in order to see what has changed.
Replication Suite, since it works with the journals, captures this
information.

Another issue to consider is when you want replication to run. If you
want
it to run while the CV is up, you will need another ASG product Virtual
DB
to ensure data integrity on the replicated DB.

Rick McMahon

-----Original Message-----
From: Mark CONS:Caffrey [mailto:DBA...@mbusa.com]
Sent: Thursday, July 29, 1999 11:45 AM
To: Idm...@iuassn.com
Subject: ASG's Replication Suite

Is there anyone that is using Allen Systems Group's Replication Suite
that
can give us information about its benefits, pitfalls, pros and cons,
etc.?
We would greatly appreciate any info. We are basically looking to use it
for
Change Data Capture to move data from operational systems to a Data
Warehouse.
Thanks in advance....
Mark Caffrey

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

Date: Thu, 29 Jul 1999 12:49:24 -0500
From: "EDWARD TIMM" <ET...@usagroup.com>
To: idm...@iuassn.com
Subject: Re: updating CLISTIN datasets
Message-ID: <s7a04d...@usagroup.com>

Chris, We have similar problems updating the SIMIN file. We IEBGENER an
=
image including changes back into the dataset while the SIMIN file is =
closed. Perhaps the IEBGENER will work, since the CLIST line is
off-line, =
for this situation as well.

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

>>> <hoel...@us.ibm.com> 99/07/29 10:56 AM >>>

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: Thu, 29 Jul 1999 13:57:39 -0400
From: "Mark CONS:Caffrey" <DBA...@mbusa.com>
To: <Idm...@iuassn.com>
Subject: DARS replication software (ISP)
Message-ID: <s7a05d...@mbna.com>

Is there anyone that is using ISP's Replication Software that can give
us =
information about its benefits, pitfalls, pros and cons, etc.?
We would greatly appreciate any info. We are basically looking to use it
=
for Change Data Capture to move data from operational systems to a Data
=
Warehouse.
Thanks in advance....
Mark Caffrey

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

Date: Thu, 29 Jul 1999 13:11:03 -0500
From: "Verinder, Gene" <GVER...@alldata.net>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: updating CLISTIN datasets
Message-ID:
<05B56B254C18D2119EF...@sdadmail1.alldata.net>

Chris - is the CLISTIN allocated to the CV as SHR? If so, you should be

able to update it with any batch utility (IEBGENER, etc.) as long as you

also specify it as SHR. This also applies to IDPF EDIT, maybe?
However, if
you use ISPF 3.3 copy, ISPF tries to allocate the target as OLD and you
get
your "in use" message.
If the CLISTIN is allocated to the CV as OLD, you are out of luck. You
have
an exclusive enqueue and have to drop the CV to make changes.
Hope this helps (and hope it's right!)
Gene Verinder
Systems Programming
Alliance Data Systems
mailto:gver...@alldata.net
Ph: 972-643-1441
Fx: 972-643-1419

----------
From: hoel...@us.ibm.com [SMTP: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: Thu, 29 Jul 1999 12:13:50 -0600

From: "Wood, Chris" <Chris...@gov.ab.ca>
To: idm...@iuassn.com

Subject: RE:DBAN on dict files
Message-ID:

<709658908B3FD311B3A...@eoaexc01.enr.gov.ab.ca>

Hi,

I was able to run the DBAN's on my Prod dict and have found a few CALC
chain
problems. Also I found a number of DC598714 NO OR52 FOR THIS INDEX SET
messages. How do I fix these OR52 errors please?

Thanks

Chris Wood
Alberta Department of resource Development
CANADA

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

Date: Thu, 29 Jul 1999 14:15:56 -0400
From: "Govan Jr, Harold M." <Harold...@lexis-nexis.com>
To: "'IDMSL'" <idm...@iuassn.com>
Subject: Hot Backups
Message-ID:
<374D007526C7D111B42A...@lnxdayexch01.lexis-nexis.com>

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: Thu, 29 Jul 1999 13:15:08 -0500

From: "Collins, John" <John.C...@ameriserve.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: DBAN on dict files
Message-ID: <C7C2EDD6CB94D211A0050000E866FE262DD500@dalhq50>

Chris,

Be sure the subschema you used contained all the areas/sets, i.e all
area/sets with cross
area pointers. The error could be a phantom if it did not.

John Collins

w: 972-364-2743

-----Original Message-----
From: Wood, Chris [mailto:Chris...@gov.ab.ca]
Sent: Thursday, July 29, 1999 1:14 PM
To: idm...@iuassn.com

Subject: RE:DBAN on dict files

Hi,

I was able to run the DBAN's on my Prod dict and have found a few CALC
chain
problems. Also I found a number of DC598714 NO OR52 FOR THIS INDEX SET
messages. How do I fix these OR52 errors please?

Thanks

Chris Wood
Alberta Department of resource Development
CANADA

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

Date: Thu, 29 Jul 1999 14:23:26 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com

Subject: RE:DBAN on dict files

Message-ID: <852567BD.0...@d54mta03.raleigh.ibm.com>

but if you received 25 OR624 errors, would that mean you have listened
to too
many Chicago albums??

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

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

Date: Thu, 29 Jul 1999 14:49:57 -0400
From: "Larry Yozwiak" <lyoz...@metlife.com>
To: <Idm...@iuassn.com>
Subject: S019 abends
Message-ID: <852567BD.0...@metlife.com>

I sent the following question to CA and they said that they would
provide a more
informational message in a future release - no date or time frame.
Does anyone have a solution for this today?

We currently have the MULTIPLE SIGNONS in the sysgen set to 'NO'. This
then
causes a CICS ABEND of S019, if the user attempts to get into the
application

from a second 3270 session (Everything working as advertised). However,
the
application development group would prefer that the transaction not
abend and

a message be sent to the user informing them that they are already
signed on on
another session. Is there someway to accomplish this?

P.S. I realize there are other reasons for the S019 error and do not
want to
prevent the S019 from causing abends in those situations.

TIA

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

Date: Thu, 29 Jul 1999 13:49:45 -0500

From: "Walters, NR Neal (8377)" <Walt...@gvl.esys.com>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>,
"'brian.wig...@bt.com'" <brian.wig...@bt.com>
Subject: RE: AREA UNLOCK - multi-area-files
Message-ID:
<9D198A0A726AD211BD1...@gvlmail1.gvl.esys.com>

Although I knew it was possible, I've never worked anywhere where they
use
multi-area files.
Seems like this would be a big DBA head-ache. What is your experience?
Good,
bad, indifferent?

Why would you do it in the first place? (Guess: Maybe have a bunch of
little areas - maybe indexes - under 100 pages, and you want to only
have
one data set?) But why not just go ahead and catalog separate data
sets?
Is it a backup/recovery issue?

On the other hand, I have one area that is 25 files!

Neal Walters
http://ItDoesMoreStuff.com - web set dedicated to IDMS and IDMS training

> ----------
> From: brian.wig...@bt.com[SMTP:brian.wig...@bt.com]
> Sent: Thursday, July 29, 1999 3:37 AM

> To: idm...@iuassn.com
> Subject: RE: AREA UNLOCK
>

> Does this trick work for multi-area files? Will it reset the indicator
for
> all the areas in the file?
> Brian Wigglesworth
> BT
>

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

Date: Thu, 29 Jul 1999 14:54:36 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: Re: S019 abends
Message-ID: <852567BD.0...@d54mta03.raleigh.ibm.com>

perhaps a manual call to #segsnon and interrogate the return code?

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

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

Date: Thu, 29 Jul 1999 15:06:16 -0400
From: "Miley, Dan L" <dan.l...@lmco.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: S019 abends
Message-ID:
<28165E37102DD2118895...@emss04m03.ems.lmco.com>

I would consider using the external security option or maybe an ESTAE in

either the application program or in CICS. But I'm not sure whether
security abends are overridable for obvious reasons. Something to try,
anyway.

Dan Miley

-----Original Message-----
From: Larry Yozwiak [mailto:lyoz...@metlife.com]
Sent: Thursday, July 29, 1999 2:50 PM
To: Idm...@iuassn.com
Subject: S019 abends

I sent the following question to CA and they said that they would
provide a
more
informational message in a future release - no date or time frame.
Does anyone have a solution for this today?

We currently have the MULTIPLE SIGNONS in the sysgen set to 'NO'. This

then
causes a CICS ABEND of S019, if the user attempts to get into the
application

from a second 3270 session (Everything working as advertised). However,
the
application development group would prefer that the transaction not
abend
and

a message be sent to the user informing them that they are already
signed on
on
another session. Is there someway to accomplish this?

P.S. I realize there are other reasons for the S019 error and do not
want to
prevent the S019 from causing abends in those situations.

TIA

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

Date: Thu, 29 Jul 1999 15:08:59 -0400
From: "Hanley, Frank" <Frank....@gs.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: S019 abends
Message-ID: <851279708234D3118C7...@gsny26e.et.gs.com>

You may need to look for, and update the code in UCF to return a more
'user-friendly' message. In any case, the
second signon would fail..

> -----Original Message-----
> From: Larry Yozwiak [SMTP:lyoz...@metlife.com]
> Sent: Thursday, July 29, 1999 2:50 PM
> To: Idm...@iuassn.com
> Subject: S019 abends
>
>
>
> I sent the following question to CA and they said that they would
provide
> a more
> informational message in a future release - no date or time frame.
> Does anyone have a solution for this today?
>
> We currently have the MULTIPLE SIGNONS in the sysgen set to 'NO'.
This
> then
> causes a CICS ABEND of S019, if the user attempts to get into the
> application
>
> from a second 3270 session (Everything working as advertised).
However,
> the
> application development group would prefer that the transaction not
abend
> and
>
> a message be sent to the user informing them that they are already
signed
> on on
> another session. Is there someway to accomplish this?
>
>
>
> P.S. I realize there are other reasons for the S019 error and do not
want
> to
> prevent the S019 from causing abends in those situations.
>
> TIA
>
>
>

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

Date: Thu, 29 Jul 1999 15:02:44 -0400
From: "Miley, Dan L" <dan.l...@lmco.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: AREA UNLOCK - multi-area-files
Message-ID:
<28165E37102DD2118895...@emss04m03.ems.lmco.com>

Neal:

We use multi-area files in our test environment. Much easier to
keep track of, back-up, etc. In production, we do the opposite for
efficency and space allocation reasons. It would be a big headache in
production but in test it works just fine.

Dan Miley

-----Original Message-----
From: Walters, NR Neal (8377) [mailto:Walt...@gvl.esys.com]

Sent: Thursday, July 29, 1999 2:50 PM
To: 'idm...@iuassn.com'; 'brian.wig...@bt.com'
Subject: RE: AREA UNLOCK - multi-area-files

Although I knew it was possible, I've never worked anywhere where they
use
multi-area files.
Seems like this would be a big DBA head-ache. What is your experience?
Good,
bad, indifferent?

On the other hand, I have one area that is 25 files!

Neal Walters
http://ItDoesMoreStuff.com - web set dedicated to IDMS and IDMS training

> ----------
> From: brian.wig...@bt.com[SMTP:brian.wig...@bt.com]
> Sent: Thursday, July 29, 1999 3:37 AM

> To: idm...@iuassn.com
> Subject: RE: AREA UNLOCK
>

> Does this trick work for multi-area files? Will it reset the indicator
for
> all the areas in the file?
> Brian Wigglesworth
> BT
>

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

Date: Thu, 29 Jul 1999 14:14:50 -0500

From: "Walters, NR Neal (8377)" <Walt...@gvl.esys.com>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>,
"'Harold...@lexis-nexis.com'" <Harold...@lexis-nexis.com>
Subject: RE: Hot Backups - We decided against.
Message-ID:
<9D198A0A726AD211BD1...@gvlmail1.gvl.esys.com>

We currently use Allen Systems VDB so that we can shadow huge production

databases on our various test, maintenance, and Y2K systems. VDB has a
hot
backup feature which I recently investigated. We eventually decided not
to
implement, but the decision had nothing to do with VDB features.

To us, the ultimate problem was how to synchronize the database backups
with
the rest of the world, i.e. VSAM files, sequential disk files, and the
timing of when tapes were created. If you shutdown the whole production

process and IDMS, you get a perfect sync-point. If you do some type of
hot
backup, then what do you do if an IDMS batch job is writing a sequential

disk file and an IDMS database? The database backup is good, but when
do
you back up the sequential file, and is the sequential file ever in sync

with the database if you do any type of restore? I suppose there are
some
environments where there is not so much coordination needed. As per ASG

verbal recommendations (see further down in this email), the best time
to do
the backup is during the day when there is CICS use but no batch jobs.
So if
you can find such a time where your batch world can be quiesced, hot
backups
may still be worthwhile.

Here are a list of issues that I came up with during the investigation:

> 1) We might have to consider putting databases in different
"segments"
> (based on sub-system functionality). VDB shadows an entire segment at
a
> time. We currently define the entire system as one segment (named
VDB0,
> which has about 180 areas). For example, PAYTRX could become a
segment,
> ACCOUNT/DEBT could become a segment, (etc... for top 5 or 10
areas-groups)
> and OTHER could be a final segment. We could then create a DBNAME of
VDB0
> which would include all of the segments. This is because existing
> programs point to a DBNAME=VDB0. In the past, if VDB0 was defined as
a
> segment, it did not also need to be defined as a DBNAME (in other
words, a
> segment can act as a DBNAME).
>
> 2) We might have to consider "segment" or "file" backups instead of
> volume backups. Until now, we have always done volume backups. This
> would require some or all new JCL for backup jobs, and a
reorganization of
> our backup structure and naming conventions, and new documentation on
how
> to restore a database.
>
> 3) There are also implications that backups themselves may run
longer
> because another job or jobs are running concurrently using system
> resources and possible tape drives. This will effect that procedures
that
> operations follows for taking down CV, draining initiators, running
> backups, bring CV up, etc...
>
> 4) Might need one entire volume (or more) for the VDB production
shadow
> file. Would need to do analysis to see how many pages-writes would
occur
> during the "hot backup" time period. The shadow data set should be
placed
> where it has no contention with the database files themselves.
>
> 5) We will need to study the job schedule and job times to see how
> effective the hot-backups will be - and whether there will typically
be a
> natural quiesce point. If hot backups are run on Friday night, and
there
> is no quiesce point, then all Saturday's update might have to go into
the
> shadow, until Saturday night or Sunday, when the shadow can be applied
to
> the real database. This further increases the required size of the
shadow
> file.
>
> 6) Another consideration would be if the batch job was accessing or
> writing to non-IDMS files such as sequential or VSAM files. How is
backup
> protected for these files? What preventions contention or lockout
between
> the FDR backup jobs and the production jobs.
>
----------------------------------------------------------------------------

-----------------------------
I just talked to Art Walker from ASG about using VDB for Hot Backups.

He mentioned a few things that weren't in the manual.
----------------------------------------------------------------------------

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

1) The best time to do the backup is during the day when there is CICS
use
but no batch jobs.
Batch jobs still present a problem to VDB Hot Backup. VDB looks for a
quiesce point and puts everyone in a wait until the quiesce is reached.
Thus if there were a batch job running, all the CICS transactions would
go
in a wait until the batch job finished. If only CICS transactions are
running, then VDB can usually obtain the quiesce point in less than one
minute (or whatever the response time of our longest running CICS
transactions) - so the maximum anyone waits is usually under a minute.
Many sites find that Friday afternoon at 4 pm is a good time to do
backups using VDB hot backup.
The batch jobs have finished earlier in the day, and many of the CICS
users
are logging off and going home.

2) "ROLL ON" is the name of the procedure that takes the data from the
shadow file and applies it back onto the database. The database areas
can
remain in update mode while this job is running.

3) I also found out that there are certain areas that you cannot
Quiesce in
order to do the backup. They include dictionaries because the RHDCRUAL
tasks keep them "in use" at all times.

Neal Walters
http://ItDoesMoreStuff.com - Web site dedicated to IDMS and IDMS
Training

> ----------
> From: Govan Jr, Harold M.[SMTP:Harold...@lexis-nexis.com]
> Sent: Thursday, July 29, 1999 1:15 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: Thu, 29 Jul 1999 15:20:53 -0400
From: Alan_...@vfc.com
To: idm...@iuassn.com
Subject: Re: S019 abends
Message-ID: <852567BD.0...@itxf2aln09.vfc.com>

From any UCF front-end (CICS, TSO), the S019 (security violation) is
issued by
the line driver from the implied signon. You get the same error if the
user
signing on doesn't have SIGNON priveleges for the CV. No LTERM is
established,
and no application task inside CV ever gets control to deal with it.

You might want to play with IDMSINTC to catch the abend and produce
something
informative, but you still have to live with the CV task abend (so it
can clean
up the UCF session) and you have to release any resources being held in
the CICS
region.

Alan Fields
VF Jeanswear
Greensboro, NC
336-332-5631
Alan_...@vfc.com

_________________________________________________________________

I sent the following question to CA and they said that they would
provide a more
informational message in a future release - no date or time frame.
Does anyone have a solution for this today?

We currently have the MULTIPLE SIGNONS in the sysgen set to 'NO'. This
then
causes a CICS ABEND of S019, if the user attempts to get into the
application

from a second 3270 session (Everything working as advertised). However,
the
application development group would prefer that the transaction not
abend and

a message be sent to the user informing them that they are already
signed on on
another session. Is there someway to accomplish this?

P.S. I realize there are other reasons for the S019 error and do not
want to
prevent the S019 from causing abends in those situations.

TIA

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

Date: Thu, 29 Jul 1999 12:24:16 PDT
From: "Jim Phillips" <jimphi...@hotmail.com>
To: idm...@iuassn.com
Subject: RE: AREA UNLOCK - multi-area-files
Message-ID: <1999072919241...@hotmail.com>

I have worked with this horrible arrangement. It was in a VM CAS shop.
VM
was/is constrained in the number of files which could be allocated to a
job
meaning that there were only a very few files to contain all the
database
areas. Multi-area files were hence a necessity. In that shop the area
page
ranges were contiguous (dunno if this was/is a rule). The disk devices
only
supported certain block sizes. So, when an area ran out of room it had
to be
unloaded and reloaded and all the other areas in the file had also to be

unloaded and reloaded so as to move all their page ranges.

I remember having to move all the page ranges quite distinctly as I took
on
the job of a 'simple unload/reload' one weekend for a fixed price
forgetting
that the shop was VM. My fee came out to about fifteen cents an hour.

Jim Phillips
ISP
(800) 295-7608

>From: "Walters, NR Neal (8377)" <Walt...@gvl.esys.com>

>Reply-To: idm...@iuassn.com
>To: "'idm...@iuassn.com'" <idm...@iuassn.com>,
>"'brian.wig...@bt.com'" <brian.wig...@bt.com>
>Subject: RE: AREA UNLOCK - multi-area-files
>Date: Thu, 29 Jul 1999 13:49:45 -0500
>
>Although I knew it was possible, I've never worked anywhere where they
use
>multi-area files.
>Seems like this would be a big DBA head-ache. What is your experience?
>Good,
>bad, indifferent?
>
>Why would you do it in the first place? (Guess: Maybe have a bunch of
>little areas - maybe indexes - under 100 pages, and you want to only
have
>one data set?) But why not just go ahead and catalog separate data
sets?
>Is it a backup/recovery issue?
>
>On the other hand, I have one area that is 25 files!
>
>Neal Walters
>http://ItDoesMoreStuff.com - web set dedicated to IDMS and IDMS
training
>
> > ----------
> > From: brian.wig...@bt.com[SMTP:brian.wig...@bt.com]
> > Sent: Thursday, July 29, 1999 3:37 AM

> > To: idm...@iuassn.com
> > Subject: RE: AREA UNLOCK
> >

> > Does this trick work for multi-area files? Will it reset the
indicator
>for
> > all the areas in the file?
> > Brian Wigglesworth
> > BT
> >
>

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

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

Date: Thu, 29 Jul 1999 12:40:18 -0700

From: "Johnson, Sara" <Sara.J...@hexcel.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: DBAN on dict files
Message-ID:
<2BCA09803339D211AE04...@unknown-68-47.hexcel.com>

Chris, are you specifying 'sets all' in your DBAN sysin? Also, make sure
you
are using IDMSNWKA and that you do not have an old copy of the subschema

lurking somewhere in your library concatenation. Another thing I have
run
into is having someone in whatever shop I was working in compiling one
of
the other subschemas and calling it IDMSNWKA. NWKA is the subschema that
all
the 'dictionary' type compilers use and it should have everything you
need
to walk every set.

-----Original Message-----
From: Wood, Chris [mailto:Chris...@gov.ab.ca]
Sent: Thursday, July 29, 1999 11:14 AM
To: idm...@iuassn.com
Subject: RE:DBAN on dict files

Hi,

I was able to run the DBAN's on my Prod dict and have found
a few CALC chain
problems. Also I found a number of DC598714 NO OR52 FOR THIS
INDEX SET
messages. How do I fix these OR52 errors please?

Thanks

Chris Wood
Alberta Department of resource Development
CANADA

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

Date: Thu, 29 Jul 1999 15:43:34 -0400
From: "Larry Yozwiak" <lyoz...@metlife.com>
To: <idm...@iuassn.com>
Subject: Re: S019 abends
Message-ID: <852567BD.0...@metlife.com>

I don't see a return code for already signed on for the #SECSGON macro.
It does have a return code to indicate that the user is valid but not
that they
are already signed on therefore I can't change multiple signons to yes.

hoel...@us.ibm.com on 07/29/99 02:54:36 PM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Larry Yozwiak/Bsg/MetLife/US)
Subject: Re: S019 abends

perhaps a manual call to #segsnon and interrogate the return code?

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

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

Date: Thu, 29 Jul 1999 15:50:26 -0400
From: "Migliaccio, Ray (Contractor)" <rmig...@harris.com>
To: 'IDMS-L' <idm...@iuassn.com>
Subject: 0360
Message-ID: <C01E7037C8FBD1119F8B00805F6F0BB703F2AC91@CORPMX7>

Ok IDMS GURU's here's my challenge.....

I have 2 schemas A and B each contain common areas, records and sets.
However when a request came in to add a record and set to an existing
subschema
of schema A all generated clean. But when subschema A is used to obtain
the
owner of a set member (which crosses areas) the return code is a 0360,
this can
be reproduced in DMLO so I can rule out a program error. I feel this to
be a
misleading error, because a subschema defined to schema B will allow the
same
calls without error. DBAN also indicates no pointer errors. I have
checked each
schema several times, I have an issue open with CA but no results yet.
CA did
indicate that a bug did exist but was resolved with 12.01 9707 which is
our
current maintenance level. I have attempted to regen the schema A with
auto on
the pointer positions for the set, but still no change.
Any suggestions would be greatly appreciated.

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

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

Date: Thu, 29 Jul 1999 14:20:47 -0600
From: Patricia Rathbone <pat...@unm.edu>
To: idm...@iuassn.com
Subject: RE: AREA UNLOCK - multi-area-files
Message-ID: <3.0.5.32.1999072...@qmail.unm.edu>

At 13:49 07/29/1999 -0500, Neal Walters wrote:
>Although I knew it was possible, I've never worked anywhere where they
use
>multi-area files.
>Seems like this would be a big DBA head-ache. What is your experience?
Good,
>bad, indifferent?
>
>Why would you do it in the first place? ...

We have a few. Our reason: third party database definitions containing
areas we do not use. Related areas are sized small and put into one
file. They never require maintenance.

<*> Patricia Rathbone http://www.unm.edu/~patric
<*> University of New Mexico pat...@unm.edu
<*> Albuquerque, NM, USA (505) 277-0171

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

Date: Thu, 29 Jul 1999 17:00:51 -0400
From: Alan_...@vfc.com
To: idm...@iuassn.com

Subject: RE:DBAN on dict files

Message-ID: <852567BD.0...@itxf2aln09.vfc.com>

Hi,

I was able to run the DBAN's on my Prod dict and have found a few CALC
chain
problems. Also I found a number of DC598714 NO OR52 FOR THIS INDEX SET
messages. How do I fix these OR52 errors please?

Thanks

Chris Wood
Alberta Department of resource Development
CANADA

_____________________________________________________________________________

Sounds like you're using IDMSNWKG and asking for all areas. Specify
only areas
DDLDML, DDLDCLOD, and DDLDCMSG. NWKG includes DDLCAT which has indexes
in
DDLCATX which is not in the subschema.

Alan Fields
VF Jeanswear
Greensboro, NC
336-332-5631
Alan_...@vfc.com

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

Date: Thu, 29 Jul 1999 14:21:28 -0700

From: "Johnson, Sara" <Sara.J...@hexcel.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: 0360
Message-ID:
<2BCA09803339D211AE04...@unknown-68-47.hexcel.com>

When you run your IDMSDBAN, are you using the same subschema that gets
the
0360? Also the same dmcl?

-----Original Message-----
From: Migliaccio, Ray (Contractor)
[mailto:rmig...@harris.com]
Sent: Thursday, July 29, 1999 12:50 PM
To: 'IDMS-L'
Subject: 0360

Ok IDMS GURU's here's my challenge.....

I have 2 schemas A and B each contain common areas,
records and sets.
However when a request came in to add a record and set to an
existing subschema
of schema A all generated clean. But when subschema A is
used to obtain the
owner of a set member (which crosses areas) the return code
is a 0360, this can
be reproduced in DMLO so I can rule out a program error. I
feel this to be a
misleading error, because a subschema defined to schema B
will allow the same
calls without error. DBAN also indicates no pointer errors.
I have checked each
schema several times, I have an issue open with CA but no
results yet. CA did
indicate that a bug did exist but was resolved with 12.01
9707 which is our
current maintenance level. I have attempted to regen the
schema A with auto on
the pointer positions for the set, but still no change.
Any suggestions would be greatly appreciated.

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

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

Date: Thu, 29 Jul 1999 17:33:28 -0400
From: "Mark CONS:Caffrey" <DBA...@mbusa.com>
To: <rmig...@harris.com>, <Idm...@iuassn.com>
Subject: Re: 0360
Message-ID: <s7a090...@mbna.com>

Ray,
At first glance it seems as though the pointer positions are
mis-aligned. =
You mentioned that you added a record and a set. This means that another
=
existing record had to be involved in the new set as well, but you did
not =
mention a restructure to add the new pointer positions.

You also mentioned that schema B works, but it was not changed. That
seems =
to indicate that the data still matches B, and A is mis-aligned. The =
"rerun" with AUTO for the pointer positions, I believe, will not work =
unless you are "adding" them. However, this is all meaningless if you =
added pointers to an existing record but did not do a restructure.

My guess is that the DBAN that showed no problems was run from schema
(or =
ss) B.=20
I hope this helps.
Mark

>>> "Migliaccio, Ray (Contractor)" <rmig...@harris.com> 07/29 3:50 PM
>>>
Ok IDMS GURU's here's my challenge.....

I have 2 schemas A and B each contain common areas, records and =
sets.
However when a request came in to add a record and set to an existing =
subschema
of schema A all generated clean. But when subschema A is used to obtain
=
the
owner of a set member (which crosses areas) the return code is a 0360, =

this can
be reproduced in DMLO so I can rule out a program error. I feel this to
be =
a
misleading error, because a subschema defined to schema B will allow the
=
same
calls without error. DBAN also indicates no pointer errors. I have
checked =
each
schema several times, I have an issue open with CA but no results yet.
CA =
did
indicate that a bug did exist but was resolved with 12.01 9707 which is
=
our
current maintenance level. I have attempted to regen the schema A with =

auto on
the pointer positions for the set, but still no change.
Any suggestions would be greatly appreciated.

Regards,
Ray Migliaccio=09
HARRIS Semiconductor=09
email rmig...@harris.com=20
phone (407) 729-5178

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

Date: Thu, 29 Jul 1999 16:11:26 -0600

From: "Wood, Chris" <Chris...@gov.ab.ca>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Cc: "'Alan_...@vfc.com'" <Alan_...@vfc.com>

Subject: RE: DBAN on dict files
Message-ID:

<709658908B3FD311B3A...@eoaexc01.enr.gov.ab.ca>

No Alan. I used NWKA and looked at areas DDLDML, DDLDCLOD and DDLDCMSG.
It
mentioned set IX-RESOURCE as the problem.

Chris

-----Original Message-----
From: Alan_...@vfc.com [mailto:Alan_...@vfc.com]
Sent: July 29, 1999 3:01 PM
To: idm...@iuassn.com

Subject: RE:DBAN on dict files

Hi,

I was able to run the DBAN's on my Prod dict and have found a few CALC
chain
problems. Also I found a number of DC598714 NO OR52 FOR THIS INDEX SET
messages. How do I fix these OR52 errors please?

Thanks

Chris Wood
Alberta Department of resource Development
CANADA

____________________________________________________________________________

Sounds like you're using IDMSNWKG and asking for all areas. Specify
only
areas
DDLDML, DDLDCLOD, and DDLDCMSG. NWKG includes DDLCAT which has indexes
in
DDLCATX which is not in the subschema.

Alan Fields
VF Jeanswear
Greensboro, NC
336-332-5631
Alan_...@vfc.com

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

Date: Thu, 29 Jul 1999 18:14:47 -0400
From: "Govan Jr, Harold M." <Harold...@lexis-nexis.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Hot Backups - We decided against.
Message-ID:
<374D007526C7D111B42A...@lnxdayexch01.lexis-nexis.com>

Neal, thanks for you input. I would concur with you conclusion not to
use
VDB.

> -----Original Message-----
> From: Walters, NR Neal (8377) [SMTP:Walt...@gvl.esys.com]
> Sent: Thursday, July 29, 1999 3:15 PM
> To: 'idm...@iuassn.com'; 'Harold...@lexis-nexis.com'
> Subject: RE: Hot Backups - We decided against.
>
> We currently use Allen Systems VDB so that we can shadow huge
production
> databases on our various test, maintenance, and Y2K systems. VDB has
a
> hot
> backup feature which I recently investigated. We eventually decided
not
> to
> implement, but the decision had nothing to do with VDB features.
>
> To us, the ultimate problem was how to synchronize the database
backups
> with
> the rest of the world, i.e. VSAM files, sequential disk files, and the

> timing of when tapes were created. If you shutdown the whole
production
> process and IDMS, you get a perfect sync-point. If you do some type
of
> hot
> backup, then what do you do if an IDMS batch job is writing a
sequential
> disk file and an IDMS database? The database backup is good, but when
do
> you back up the sequential file, and is the sequential file ever in
sync
> with the database if you do any type of restore? I suppose there are

> some
> environments where there is not so much coordination needed. As per
ASG
> verbal recommendations (see further down in this email), the best time
to
> do
> the backup is during the day when there is CICS use but no batch jobs.
So
> if
> you can find such a time where your batch world can be quiesced, hot
> backups
> may still be worthwhile.
>
> Here are a list of issues that I came up with during the
investigation:
>
> > 1) We might have to consider putting databases in different
"segments"
> > (based on sub-system functionality). VDB shadows an entire segment
at a
> > time. We currently define the entire system as one segment (named
VDB0,
> > which has about 180 areas). For example, PAYTRX could become a
segment,
> > ACCOUNT/DEBT could become a segment, (etc... for top 5 or 10
> areas-groups)
> > and OTHER could be a final segment. We could then create a DBNAME
of
> VDB0
> > which would include all of the segments. This is because existing
> > programs point to a DBNAME=VDB0. In the past, if VDB0 was defined
as a
> > segment, it did not also need to be defined as a DBNAME (in other
words,
> a
> > segment can act as a DBNAME).
> >
> > 2) We might have to consider "segment" or "file" backups instead
of
> > volume backups. Until now, we have always done volume backups.
This
> > would require some or all new JCL for backup jobs, and a
reorganization
> of
> > our backup structure and naming conventions, and new documentation
on
> how
> > to restore a database.
> >
> > 3) There are also implications that backups themselves may run
longer
> > because another job or jobs are running concurrently using system
> > resources and possible tape drives. This will effect that procedures

> that
> > operations follows for taking down CV, draining initiators, running
> > backups, bring CV up, etc...
> >
> > 4) Might need one entire volume (or more) for the VDB production
> shadow
> > file. Would need to do analysis to see how many pages-writes would

> occur
> > during the "hot backup" time period. The shadow data set should be
> placed
> > where it has no contention with the database files themselves.
> >
> > 5) We will need to study the job schedule and job times to see how

> > effective the hot-backups will be - and whether there will typically
be
> a
> > natural quiesce point. If hot backups are run on Friday night, and
> there
> > is no quiesce point, then all Saturday's update might have to go
into
> the
> > shadow, until Saturday night or Sunday, when the shadow can be
applied
> to
> > the real database. This further increases the required size of the
> shadow
> > file.
> >
> > 6) Another consideration would be if the batch job was accessing
or
> > writing to non-IDMS files such as sequential or VSAM files. How is
> backup
> > protected for these files? What preventions contention or lockout
> between
> > the FDR backup jobs and the production jobs.
> >
>
--------------------------------------------------------------------------

> --
> -----------------------------
> I just talked to Art Walker from ASG about using VDB for Hot
Backups.
> He mentioned a few things that weren't in the manual.
>
--------------------------------------------------------------------------

> --
> -----------------------------
>
> 1) The best time to do the backup is during the day when there is CICS
use
> but no batch jobs.
> Batch jobs still present a problem to VDB Hot Backup. VDB looks for a

> quiesce point and puts everyone in a wait until the quiesce is
reached.
> Thus if there were a batch job running, all the CICS transactions
would go
> in a wait until the batch job finished. If only CICS transactions are

> running, then VDB can usually obtain the quiesce point in less than
one
> minute (or whatever the response time of our longest running CICS
> transactions) - so the maximum anyone waits is usually under a minute.

> Many sites find that Friday afternoon at 4 pm is a good time to do
> backups using VDB hot backup.
> The batch jobs have finished earlier in the day, and many of the CICS
> users
> are logging off and going home.
>
> 2) "ROLL ON" is the name of the procedure that takes the data from
the
> shadow file and applies it back onto the database. The database areas
can
> remain in update mode while this job is running.
>
> 3) I also found out that there are certain areas that you cannot
Quiesce
> in
> order to do the backup. They include dictionaries because the
RHDCRUAL
> tasks keep them "in use" at all times.
>
> Neal Walters
> http://ItDoesMoreStuff.com - Web site dedicated to IDMS and IDMS
Training
>
>
> > ----------
> > From: Govan Jr, Harold M.[SMTP:Harold...@lexis-nexis.com]
> > Sent: Thursday, July 29, 1999 1:15 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: Thu, 29 Jul 1999 16:27:49 -0600
From: John.E...@Jeppesen.com
To: idm...@iuassn.com
Subject: Re: updating CLISTIN datasets
Message-ID: <872567BD.0...@jeppdensmtp01.jeppesen.com>

Chris -

Good old IEBGENER works - DISP=SHR on the output dataset.

John Emanuel
Jeppesen

hoel...@us.ibm.com on 07/29/99 09:56:02 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: John Emanuel/Jeppesen/TMC)

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: Thu, 29 Jul 1999 23:22:52 +0100
From: Steve Cannon <can...@globalnet.co.uk>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Not IDD Owned

Message-ID: <01BEDA19.484...@globalnet.co.uk>

Bill

The not IDD owned msg means either the record has been included in a
schema
or a map. The recommended path for changing is to create recprd reca V 2

same as V1. Make the changes to V2 that are needed ( it is IDD owned so
any
change is valid ). Once happy - go to all of the maps & schemas that
reference the record and modify them to reference V 2 (not V 1) . ( For
maps you may need to go to the layout & delete reference to fields which

are being removed). Once done - validate the schema & compile the maps.
When all have been done, & when the Schema version that references V 1
has
been deleted you can then go to IDD & having first deleted V 1 then say
the
magic words:
Mod Record reca version 2 new version 1.

Hey presto everything is pointing to V1 again.

Hope this helps

Steve Cannon
UK

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

Date: Thu, 29 Jul 1999 17:54:30 -0500

From: Bill....@ipaper.com
To: " - *idm...@iuassn.com" <idm...@iuassn.com>

Subject: Re: 0360
Message-ID: <0057390008065796000002L962*@MHS>

If i remember correctly, there was a program problem that caused this
error, it
occurred
because of the update program not working properly, and it had to do
with
manuel set
options. the update program was using one schema and inquiry was using
other
one.
been a long time.
also i found this an old abend document:
0360 IN THIS CASE, THE PROGRAM WAS EXPECTING TO FIND AN REV-OTHER-INFO
RECORD
(5456) AND FOUND A REV-SWITCHING RECORD (350) BECAUSE THEY
BOTH USED THE SAME POINTERS IN A MUTI-MEMBER SET. THE PROGRAM
HAD TO BE CHANGED TO CHECK FOR THE KIND OF RECORD IN THE SET.
Hope this helps!

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

Date: Thu, 29 Jul 1999 18:51:44 -0700

From: JB Moore <conl...@ix.netcom.com>
To: idm...@iuassn.com

Subject: Re: DBAN on dict files
Message-ID: <37A105...@ix.netcom.com>

Chris,

I would be much more concerned with the broken CALC chains than the
missing OR52 message. There are no index sets in the "traditional"
CA-IDMS dictionary (DML, DLOD, DMSG etc). The IX-RESOURCE in in the
CATLX area I think. I didn't think that this area was in IDMSNWKA.

Try this:

Run an IDMSLOOK in batch using BIND SUBSCHEMA=IDMSNWKA. Make certain
that you are using the correct copy of IDMSNWKA (LOADAREA=ON or OFF?,
loadlib resident).

Browse SYSLST and issue a find for IX-RESOURCE. Is it in there?

BTW, the OR52 is a subschema control block that is owned by the SR51.
For system-owned index sets in a subschema, there is usually a chain of
OR52s off of the single SR7 SR51.

Just guessing, but it sounds like DBAN found an index (IX-RESOURCE) and
then couldn't locate the OR52 in IDMSNWKA. This would make sense to me.
The real question seems to be: Why was DBAN looking in AREAs that you
didn't tell it to?

Jim Moore

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

Date: Thu, 29 Jul 1999 21:05:21 -0400
From: ClaudeF <jec...@worldnet.att.net>
To: idm...@iuassn.com
Subject: Re: updating CLISTIN datasets
Message-ID: <37A0FA51...@worldnet.att.net>

Chris,

If what you want is to update the input dataset of a batch simulator
line, you can add a FREE=CLOSE on the JCL statement that defines the
dataset in question. The effect is to free the dataset from the IDMS
region when it is closed (at EOF). It is similar to a TSO FREE
command. After the file is freed from the CV, you can edit the file,
rename it, delete it. Of course, it has to be there for the next CV
start up.

A word of caution: you cannot reopen the batch simulator line (some
people do) to re-execute the commands contained in the batch sim line
because the dataset is no longer allocated to the IDMS CV.

I hope this helps.

Claude Ferland
Independant Consultant

hoel...@us.ibm.com wrote:
>
> 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: Fri, 30 Jul 1999 00:05:14 -0500

From: "Mowbray, Sam A" <sam.m...@eds.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: Hot Backups
Message-ID: <FB42153F3C41D111A12500805F0D726E02173E57@AUADM101>

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: Fri, 30 Jul 1999 10:13:06 +0200
From: IESD <in1...@juliusbaer.com>
To: IDM...@IUASSN.COM

Subject: Re: DBAN on dict files

Message-ID: <1999073008...@mailhost.ip-plus.net>

Chris

It is to be expected that RESOURCE and RESOURCEAUTH records are to be
foun=
d in DDLDML areas throghout your R12 or R14 system. Security definitions
f=
or resources which are DB related reside in the dictionary where they
are =
defined. Which ones are stored where is fully documented in Appendix B
of =
the Security Administrtaion guide. You can use IDMSSECS with OLQ or DMLO
t=
o check exactly what you have got where. You must use IDMSNWKG to do
your =
DBAN. IDMSNWKA no longer contains all records possible on the DDLDML
area =
but is retained because the various compilers still use them. Security
cal=
ls made by compilers using IDMSNWKA are routed through System Run Units
wh=
ich use IDMSSECS or not if you use external security for those
resources.
The Database Administration manual contains a chapter on Maintaining and
D=
efining dictionaries. There is listed the various CA subschemas and what
t=
hey should be used for including DBAN and more importantly
Unload/Reload =
of IDD and Catalog Areas.

Chris Trayler

> Chris,

> I would be much more concerned with the broken CALC chains than the
> missing OR52 message. There are no index sets in the "traditional"
> CA-IDMS dictionary (DML, DLOD, DMSG etc). The IX-RESOURCE in in the
> CATLX area I think. I didn't think that this area was in IDMSNWKA.

> Try this:

> Run an IDMSLOOK in batch using BIND SUBSCHEMA=3DIDMSNWKA. Make certain

> that you are using the correct copy of IDMSNWKA (LOADAREA=3DON or
OFF?,
> loadlib resident).

> Browse SYSLST and issue a find for IX-RESOURCE. Is it in there?

> BTW, the OR52 is a subschema control block that is owned by the SR51.
> For system-owned index sets in a subschema, there is usually a chain
of
> OR52s off of the single SR7 SR51.

> Just guessing, but it sounds like DBAN found an index (IX-RESOURCE)
and
> then couldn't locate the OR52 in IDMSNWKA. This would make sense to
me.
> The real question seems to be: Why was DBAN looking in AREAs that you
> didn't tell it to?

> Jim Moore

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

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

Date: Fri, 30 Jul 1999 10:41:51 +0200
From: Jacques_P...@paribas.com
To: idm...@iuassn.com
Subject: NO OR52 FOR THIS INDEX SET IX-RESOURCE...BUT STILL ALIVE
Message-ID: <802567BE.0...@lonn000101.uk.paribas.com>

Bonjour
I think the IX-RESOURCE is owned by the IDMSSECS SCHEMA. You can use for
your
IDMSDBAN the IDMSNWKU SSC instead of IDMSNWKA but if you will get a
clean
IDMSDBAN Report 1 you will get a Report 2 (step DBN2) with problems on
IX-RESOURCE like :
599701 - DUPLICATE TO-DBKEY SET=CALC
599703 - PRIOR LINK NOT FOUND SET=CALC
UT016024 Unmatched Prior pointer found
SR8 Dbkey=4,122:15 Prior=4,122:16 Owner=4,122:15 Level=0...

UT016022 Unmatched NEXT pointer found - Bad next pointer
NEXT Dbkey=4,122:16 SR8 Dbkey=4,122:15 Owner=4,122:15 Level=0...
UT016034 Unmatched UP pointer found

If you use PROCESS SUBSCHEMA IDMSNWKA DBNAME ABDD UNLOCKED INC
(Incomplete)
than Report 2 is OK but in your Report 1 you'll again get - DBKEY
4122:15
NO OR52 FOR THIS INDEX SET IX-RESOURCE

Someone advice us to do a MAINTAIN INDEX on IX-RESOURCE but we choose to
live
with this little anomaly and we are still alive.
Regards.
Jacques.

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

Hi,

I was able to run the DBAN's on my Prod dict and have found a few CALC
chain
problems. Also I found a number of DC598714 NO OR52 FOR THIS INDEX SET
messages. How do I fix these OR52 errors please?

Thanks

Chris Wood
Alberta Department of resource Development
CANADA

_____________________________________________________________________________

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

This message is confidential; its contents do not constitute a
commitment by Paribas except where provided for in a written agreement
between you and Paribas. Any unauthorised disclosure, use or
dissemination, either whole or partial, is prohibited. If you are not
the intended recipient of the message, please notify the sender
immediately.

Ce message est confidentiel ; son contenu ne représente en aucun cas un
engagement de la part de Paribas sous réserve de tout accord conclu par
écrit entre vous et Paribas. Toute publication, utilisation ou
diffusion, même partielle, doit être autorisée préalablement. Si vous
n'êtes pas destinataire de ce message, merci d'en avertir immédiatement
l'expéditeur.

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

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

Chris Hoelscher

unread,

Jul 31, 1999, 3:00:00 AM7/31/99

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

IDMS-L Sat, 31 Jul 1999 Volume 1 :
Number 41

In this issue:

RE: AREA UNLOCK - multi-area-files

RE: AREA UNLOCK - multi-area-files
0360
unsubscribe
RE: S019 abends
CDMSLOGA/B
Multi-area files: Why?
RE: unsubscribe
RE: CDMSLOGA/B
Program Check in XASTGPL
RE: Program Check in XASTGPL

RE: DBAN on dict files

RE: Program Check in XASTGPL
Re: RE: Hot Backups
Re: RE: Hot Backups
14.0 Apar LO44807 and 12.0 equivalent
Re: 14.0 Apar LO44807 and 12.0 equivalent
Routing IDMS-L mail to a special Outlook folder
Index Reorg(unload/reload)
RE: Index Reorg(unload/reload)
RE: Index Reorg(unload/reload)
Re: Index Reorg(unload/reload)
Re: Index Reorg(unload/reload)

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

Date: Fri, 30 Jul 1999 11:31:49 +0100
From: brian.wig...@bt.com
To: idm...@iuassn.com
Subject: RE: AREA UNLOCK - multi-area-files
Message-ID:
<DBE5DC3EE4EDD211986...@mclmsent09.lon.bt.com>

Neal,
We use multi-area files in our development and test CVs, where we have
about
100 databases in each.
With 133 areas per database that would mean a lot of files if we were to
use
1 file per area - I think we would break MVS/JES/JCL limits?
We do group logically related areas into 7 segments (files).
Resizes are a headache, but they would be anyway because our users are
constantly restoring their databases from favourite backups, sometimes
to
the same database sometimes to different one. So we have to find out
when
the backup was taken, what the size of the databse was then and what
size
the target database is now in order to work out if we need to
unload/reload
or just do physical file copies.
To a certain extent we have automated this using ISPF panels and
dialogues,
but it is still a problem to us.
Consequently we resist requests to resize an area until we absolutely
have
to!
Brian

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

Date: Fri, 30 Jul 1999 05:39:12 -0500
From: "Rice, James L. Jim" <JLR...@southernco.com>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: AREA UNLOCK - multi-area-files
Message-ID:

<F3E06C56DE75D211B3A...@gaxgpex23.southernco.com>

While not horrible as Jim indicates, it is a fact of life in VM. And
you
can only go up to 4K block size unless you have an add on product.
The restriction Jim mentions has to do with the File Mode in VM.
Similar to
the fildef in MVS. Obviously, you are limited to 26 letters. With
overhead
files and system disks, you end up with only about 15- 20 files
available.
Sooooo, you cram all of your small areas i.e. indexes together.
Maintenance
as Jim indicates can be a bit more restricted than MVS. In the VM shops
I
have worked at, we used the WOS product from Adessa to simulate OS
disks.
This allowed us to have more than the 26 files and 4k block size
restriction.

This was all prior to 12.0. This release has offered relief with
dynamic
file allocation. We don't have to worry about the file mode problem.
You
just learn to live with a max of 4k block size.

Jim, if we need help in the future, I can offer you 20 cents and hour!
:-)

> -----Original Message-----
> From: Jim Phillips [SMTP:jimphi...@hotmail.com]

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

Date: Fri, 30 Jul 1999 08:15:26 -0400

From: "Migliaccio, Ray (Contractor)" <rmig...@harris.com>
To: 'IDMS-L' <idm...@iuassn.com>
Subject: 0360

Message-ID: <C01E7037C8FBD1119F8B00805F6F0BB703F2AC93@CORPMX7>

All,
Thanks for your assistance with resolving my 0360 schema / subschema
problem. As it turns out the member pointer positions were not aligned
correctly. I was hoping that when I attempted the auto option on the set
the
dictionary was smart enough to resolve the pointer but not so. Anyhow I
have
identified the problem and we're ok now.

Thanks for all the support!

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

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

Date: Fri, 30 Jul 1999 09:24 -0400
From: STAN JAMES <SJA...@ATPCO.NET>
To: idm...@iuassn.com
Subject: unsubscribe
Message-ID: <19990730...@mail.atpco.net>

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
le=
ast are
getting paid to know.

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

Date: Fri, 30 Jul 1999 08:39:27 -0400
From: "Canon, Hartman" <hartma...@lmco.com>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: S019 abends
Message-ID:

<60875A437C39D211BE86...@emss03m03.orl.lmco.com>

This and other problems caused by the lack of appropriate return codes
using
#SECSGON (and RHDCSNON also for that matter) have caused us to begin to
change over to extracting the actual ACF2 messages issued and processing

them instead. This is done by recinding GS20620 (for those who have
applied
it and from RHDCOPTF in 14.x) and issuing a #GETQUE
QUEID='RHDCLTRMltename'
just AFTER the macro call. The actual entire ACF2 message is acquired.
This
may also require to write your own passwaor change pgm and capture the
message here also to prevent the messages being blasted to the screen at

task completion. Of course this can't be implemented with RHDCSNON.
This work is not yet completed but does look promising.

Hartman B. Canon
Lockheed-Martin

-----Original Message-----
From: Larry Yozwiak [mailto:lyoz...@metlife.com]
Sent: July 29, 1999 15:44
To: idm...@iuassn.com
Subject: Re: S019 abends

I don't see a return code for already signed on for the #SECSGON macro.
It does have a return code to indicate that the user is valid but not
that
they
are already signed on therefore I can't change multiple signons to yes.

hoel...@us.ibm.com on 07/29/99 02:54:36 PM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Larry Yozwiak/Bsg/MetLife/US)
Subject: Re: S019 abends

perhaps a manual call to #segsnon and interrogate the return code?

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

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

Date: Fri, 30 Jul 1999 09:38:45 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: CDMSLOGA/B
Message-ID: <852567BE.0...@d54mta03.raleigh.ibm.com>

due to some special tracing we are doing that will create TONS of
output, I am
creating
DMCSLOGA/B - since i try to be lazy whenever possilble, i am asking you
folks:
what is the
correct DCB for these files? (i have a whole volume for CDMSLOGA/B)

thanks,
Chris "silly talk" Hoelscher

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

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

Date: Fri, 30 Jul 1999 08:44:55 -0500
From: Kay Rozeboom <Kay.Ro...@its.state.ia.us>
To: idm...@iuassn.com
Subject: Multi-area files: Why?
Message-ID:
<78DA1160F5BDD111BCC...@its-cn-exchange.its.state.ia.us>

Here is why we do it: Release 12/14 provides the capability of creating

multiple sets of test files, that can be used with a single
schema/subschema. You switch from one set to another with the 'DCUF SET

DBNAME' command. Our users love this and have taken full advantage of
it. However our largest system has 156 areas. If each area had its own

file, we would have to add 156 files with each additional set of test
data. You can see how the number of files would grow very fast.

The problem we ran into is that each file allocation requires a piece of

below-the-line storage, and we quickly ran out. You can deal with this
up to a point by reducing (not increasing) your CV region size. But we
could only make the CV region so small. Then we were forced to combine
areas into shared files. For the 156-area system mentioned above, we
now have a file for each segment, instead of one for each area. With 12

sets of test data, this reduced the number of files required from 1872
to 444.

On production, this system still has one (or more) files for each area.

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

Date: Fri, 30 Jul 1999 15:56:40 +0200

From: =?iso-8859-1?Q?Brandt_Ren=E9?= <r...@ubp.ch>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Cc: "'SJA...@ATPCO.NET'" <SJA...@ATPCO.NET>
Subject: RE: unsubscribe
Message-ID:
<693E4DC6C79FD211907...@mailgva.geneve.ubp.ch>

You who are a so clever man you ought to read that to unsubsribe the =
message
had to be sent to LIST...@IUASSN.COM
Next time you will have a problem stay in your sh...

> -----Message d'origine-----
> De: STAN JAMES [SMTP:SJA...@ATPCO.NET]
> Date: Friday, July 30, 1999 3:24 PM
> =C0: idm...@iuassn.com
> Objet: unsubscribe
>=20
> UNSUBSCRIBE
>=20
>=20
> 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: Fri, 30 Jul 1999 15:00:37 +0100
From: iain.dk....@bt.com
To: idm...@iuassn.com
Subject: RE: CDMSLOGA/B
Message-ID:
<5F54BE0116BCD2118C9...@mclmsent02.lon.bt.com>

=On Friday, July 30, 1999 2:39 PM, hoel...@us.ibm.com [] wrote:
>
>
>
> due to some special tracing we are doing that will create TONS of
> output, I am creating CDMSLOGA/B - since I try to be lazy
> whenever possilble, i am asking you folks:
> what is the correct DCB for these files?
>
> (i have a whole volume for CDMSLOGA/B)thanks,

RECFM=FBA,LRECL=133,BLKSIZE=27930,DSORG=PS

I
Iain Robertson British Telecom
* 0207 843 8723 * 0207 843 7310
* iain.dk....@bt.com
* pp3B30, Angel Centre, 403 St John Street, London EC1V 4PL

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

Date: Fri, 30 Jul 1999 10:35:14 -0400

From: "Lupico, Joe" <Joe.L...@AIG.com>
To: "'IDM...@IUASSN.COM'" <IDM...@IUASSN.COM>

Subject: Program Check in XASTGPL
Message-ID: <4F1E68B5C708D11180860001FA372A6501CAFC8A@XCS_LIV01>

All of a sudden, one of my production CVs is getting a lot (a LOT) of
program checks near module XASTGPL (for which I cannot find either a
module,
or even a CSECT within a module, but our guess is this stands for XA
SToraGe
PooL). Once this starts happening, the CV stays up (and you can log
onto
it) but CICS programs accessing this region are getting a 1469. If we
cycle
the system, the problem doesn't appear again until the next day at
almost
the same time (the CV is brought down again at night for backups,
compresses, etc). This has gone on for the last three days, but never
happended before.

Some details: this system is running on S10214 with premium support
(which
includes a reworked release 12 CICS interface). The CICS region is
release
4.1. I have included the optional PTFs for XA buffer support and XA
scratch
buffers. This CV is used for retrieval purposes only (all DBs in RET
status), and is only accessed by CICS programs - therefore there are no
programs running inside the region which can corrupt storage. The one
thing
that has changed - they added the LE runtime library within CICS on
Saturday, although they still using either VS or Cobol II programs. Why

this would cause problems within IDMS is a mystery to me. It also
appears
that a secong CICS region which accesses this IDMS region (and has not
be
upgraded to LE) does not have a problem, even once the programs in the
other
CICS start getting the 1469s.

We have opened up a problem with CA, but I thought I'd throw this out
fr
comments or experiance.

Thanks...Joe

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

Date: Fri, 30 Jul 1999 11:03:22 -0400
From: "Lupico, Joe" <Joe.L...@AIG.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Program Check in XASTGPL
Message-ID: <4F1E68B5C708D11180860001FA372A6501CAFC8B@XCS_LIV01>

Correction - both CICS regions are using the LE runtime environment
with
old Cobol programs.

Joe

> ----------
> From: Lupico, Joe[SMTP:Joe.L...@AIG.com]
> Reply To: idm...@iuassn.com
> Sent: Friday, July 30, 1999 10:35 AM
> To: 'IDM...@IUASSN.COM'
> Subject: Program Check in XASTGPL
>
> All of a sudden, one of my production CVs is getting a lot (a LOT)
of
> program checks near module XASTGPL (for which I cannot find either a
> module,
> or even a CSECT within a module, but our guess is this stands for XA
> SToraGe
> PooL). Once this starts happening, the CV stays up (and you can log
onto
> it) but CICS programs accessing this region are getting a 1469. If we

> cycle
> the system, the problem doesn't appear again until the next day at
almost
> the same time (the CV is brought down again at night for backups,
> compresses, etc). This has gone on for the last three days, but never

> happended before.
>
> Some details: this system is running on S10214 with premium support
> (which
> includes a reworked release 12 CICS interface). The CICS region is
> release
> 4.1. I have included the optional PTFs for XA buffer support and XA
> scratch
> buffers. This CV is used for retrieval purposes only (all DBs in RET
> status), and is only accessed by CICS programs - therefore there are
no
> programs running inside the region which can corrupt storage. The one

> thing
> that has changed - they added the LE runtime library within CICS on
> Saturday, although they still using either VS or Cobol II programs.
Why
> this would cause problems within IDMS is a mystery to me. It also
appears
> that a secong CICS region which accesses this IDMS region (and has not
be
> upgraded to LE) does not have a problem, even once the programs in the

> other
> CICS start getting the 1469s.
>
> We have opened up a problem with CA, but I thought I'd throw this
out fr
> comments or experiance.
>
> Thanks...Joe
>
>

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

Date: Fri, 30 Jul 1999 12:43:00 +1000
From: "Hannigan, Peter [IBM GSA]" <PHan...@nitgitd1.telstra.com.au>
To: "IDMS-L mailing list (IUASSN)" <idm...@iuassn.com>

Subject: RE: DBAN on dict files

Message-ID: <1999073007...@mail.cdn.telstra.com.au>

Try sub IDMSNWKU.

----------
From: Wood, Chris
To: 'idm...@iuassn.com'
Cc: 'Alan_...@vfc.com'

Subject: RE: DBAN on dict files

Date: Friday, 30 July 1999 8:11pm

Chris

Hi,

Thanks

____________________________________________________________________________

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

Date: Fri, 30 Jul 1999 11:21:45 -0500

From: Bill....@ipaper.com
To: " - *idm...@iuassn.com" <idm...@iuassn.com>

Subject: RE: Program Check in XASTGPL
Message-ID: <0057390008090212000002L922*@MHS>

Joe
Check you cobol libraries, you are probably getting some new le modules.

don't know if it applys to 10.2 but look at li23664 and li29837and
li18624.
One other possibility you may want to try putting old cobol libraries in

front of le libraries in search chain.
just some ideas.

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

Date: Fri, 30 Jul 1999 13:24:09 -0400

From: "Mark CONS:Caffrey" <DBA...@mbusa.com>
To: <Idm...@iuassn.com>

Subject: Re: RE: Hot Backups
Message-ID: <s7a1a7...@mbna.com>

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.=20

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=20

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.=20
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=20
phone : +61 8 8464 1503 =20

fax : +61 8 8464 2135

=20

> A few questions:
> How long have you used this backup technique ? =20
> How are you doing hot backups ? =20

> What problems or pitfalls, if any, have you encountered using

> this backup technique ? =20

> How would you compare recovery using a hot backup to a recovery
> using a conventional static backup ?

>=20
>=20
> Thanks in advance.
> =20

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

Date: Fri, 30 Jul 1999 14:12:02 -0400
From: hol...@royalsunalliance.ca
To: idm...@iuassn.com
Subject: Re: RE: Hot Backups
Message-ID: <852567BE.0...@mail.royalsunalliance.ca>

I too have been watching this discussion thread and will throw in my 2
cents
worth.

We also use DFDSS from IBM with the "Concurrent Copy" option. It has
been
successfully used for our IDMS (and DB2)
backups for a number of years. There is one hardware requirement. You
need IBM
3990 Mod. 6 controllers or equivalent or better. This utility backs up
most if
not all the mainframe DASD in our shop.

Ed Holman
Royal&SunAlliance Insurance
Toronto,Ontario
Canada
hol...@royalsunalliance.ca

>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 >>>

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

Date: Fri, 30 Jul 1999 14:00:10 -0500
From: bob.n...@edwardjones.com
To: idm...@iuassn.com
Subject: 14.0 Apar LO44807 and 12.0 equivalent
Message-ID: <H000026401ff0c89@MHS>

FYI for anyone planning to use the mixed page group support.

During the CA-IDMS R14.0/R14.1 Features presentation at CA-World 99 last
week, they mentioned the LO44807 apar which was designed to identify
programs which are executing an unqualified FIND/OBTAIN DB-KEY.

Since we are planning to go from 12.01 (9607) to 14.1, I requested a
12.01 version. L2 developed the TC03437 test apar. I applied it to my
test lpar and executed an unqualified OBTAIN DB-KEY in DML/O and
received DB007000 UNQUALIFIED FIND DBKEY ISSUED. PGM=USDMAIN0
SSC=SSPMF02 SEQ=00000000 in the IDMS sysout, so it appears to work.

I would assume that the test apar will get published at a later date.
Depenidng on which version you want, you may need to open an issue.

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

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

Date: Fri, 30 Jul 1999 15:05:42 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: Re: 14.0 Apar LO44807 and 12.0 equivalent
Message-ID: <852567BE.0...@d54mta03.raleigh.ibm.com>

maybe they WONT publish it as an LOxxxxx - if they did - it would be on
the next
maint tape (if one occurs), and then everyone would be getting that
message in
12.0 even if they NEVER planeed to use mixed page group. Maybe as an
OPTIONAL
fix......

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

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

Date: Fri, 30 Jul 1999 14:15:21 -0500
From: Kay Rozeboom <Kay.Ro...@its.state.ia.us>
To: idm...@iuassn.com
Subject: Routing IDMS-L mail to a special Outlook folder
Message-ID:
<78DA1160F5BDD111BCC...@its-cn-exchange.its.state.ia.us>

Thanks to all who answered my question. It appears that there are many
different answers, depending on the version of Outlook one is using. I
did finally get it to work, so here is the answer for Outlook 97:

1) Create a folder called "IDMS-L" under the "Inbox" directory
2) Click "Tools"
3) Click "Inbox Assistant"
4) Click "Add Rule"
5) Leave the "From" box blank
6) In the "Sent to" box, type "idm...@iuassn.com"
7) Click the "Move to" checkbox
8) Click the "Move to" "Folder" button, then select the "IDMS-L" folder

you created in step (1)
9) Click "OK"
10) Click "OK" again

Now all your IDMS-L mail should go directly to the "IDMS-L" folder.

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

Date: Fri, 30 Jul 1999 14:11:29 -0600 (Mountain Daylight Time)
From: "bfr...@unm.edu" <bfr...@unm.edu>
To: idm...@iuassn.com
Subject: Index Reorg(unload/reload)
Message-ID: <Pine.WNT.3.96.99073...@bfraser.unm.edu>

Hi all;

This is my first time.

I am going to reorg an index that points to a very large number of
duplicate member records. I noticed that out of 600,000 members that
only about 20,000 are unique. I also noticed that even though the
set relationship is mandatory automatic on the index, that there are
only about 20,000 entries. It looks as if each duplicate record does
NOT have its own entry, but rather shares the first unique entry.

My question is, may I base my area size and number of keys per SR8
on 20,000 rather then 600,000 members? Otherwise, there will be a
lot of wasted space in an oversized page.

Thank you for any help

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

Date: Fri, 30 Jul 1999 16:14:36 -0400

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

Subject: RE: Index Reorg(unload/reload)
Message-ID: <851279708234D3118C7...@gsny26e.et.gs.com>

Not sure about your size question, but a reminder that you should
rebuild
from the index if you want to
preserve the duplicate order.

> -----Original Message-----
> From: bfr...@unm.edu [SMTP:bfr...@unm.edu]
> Sent: Friday, July 30, 1999 4:11 PM
> To: idm...@iuassn.com

> Subject: Index Reorg(unload/reload)
>
> Hi all;
>
> This is my first time.
>
> I am going to reorg an index that points to a very large number of
> duplicate member records. I noticed that out of 600,000 members that
> only about 20,000 are unique. I also noticed that even though the
> set relationship is mandatory automatic on the index, that there are
> only about 20,000 entries. It looks as if each duplicate record does
> NOT have its own entry, but rather shares the first unique entry.
>
> My question is, may I base my area size and number of keys per SR8
> on 20,000 rather then 600,000 members? Otherwise, there will be a
> lot of wasted space in an oversized page.
>
> Thank you for any help

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

Date: Fri, 30 Jul 1999 16:22:13 -0400

From: "Miley, Dan L" <dan.l...@lmco.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: Index Reorg(unload/reload)
Message-ID:
<28165E37102DD2118895...@emss04m03.ems.lmco.com>

Since you are going to reload the index and there are so many
duplicates,
why not add a field to make the index unique? I don't know how much
code is
dependent on that of course but a different index key would be the ideal

solution.

Dan Miley

-----Original Message-----
From: Hanley, Frank [mailto:Frank....@gs.com]
Sent: Friday, July 30, 1999 4:15 PM
To: 'idm...@iuassn.com'

Subject: RE: Index Reorg(unload/reload)

Not sure about your size question, but a reminder that you should
rebuild
from the index if you want to
preserve the duplicate order.

> -----Original Message-----
> From: bfr...@unm.edu [SMTP:bfr...@unm.edu]
> Sent: Friday, July 30, 1999 4:11 PM
> To: idm...@iuassn.com

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

Date: Fri, 30 Jul 1999 17:33 -0500

From: "Steve Franzon" <Steve....@alltel.com>
To: "idm...@iuassn.com" <idm...@iuassn.com>

Subject: Re: Index Reorg(unload/reload)
Message-ID: <199907301802...@alltel.com>

How did you determine there are only 20K entries? That really
doesn't
sound right for a MA set.

If your MA set has 600,000 members records, then there should be
600,000 level zero entries. In the bottom level of the index there
should be one down pointer per member, duplicate or not - it
doesn't
matter. EVERY member MUST be in the index.

Now, IDMS is smart enough to reuse key literals in the SR8 for
duplicate keys. This will make your SR8s smaller than you
calculated,
because the SR8s don't utilize the maximum literal space. (Note
that
this applies only to bottom level SR8s - intermediate level SR8s
are
always full size). You might end up with more SR8s per page than
you
calculated and the index might not take up as much space as you
anticipated. But the total number of SR8's, entries per SR8 and
number
of levels should be as expected.

You must calculate using 600K, otherwise your keys per SR8 will be
way
too low and/or your index will end up with additional levels.
Personally, I'd also stick with the area size the calculations come
up
with and "enjoy" the extra free space. But if you are worried about

wasting space, do a test run and "guesstimate" a better area size.

Hope this helps,
Steve Franzon

______________________________ Reply Separator
_________________________________
Subject: Index Reorg(unload/reload)
Author: idm...@iuassn.com at internet
Date: 07/30/1999 3:11 PM

Hi all;

This is my first time.

My question is, may I base my area size and number of keys per SR8
on 20,000 rather then 600,000 members? Otherwise, there will be a
lot of wasted space in an oversized page.

Thank you for any help

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

Date: Fri, 30 Jul 1999 20:56:42 -0700

From: JB Moore <conl...@ix.netcom.com>
To: idm...@iuassn.com

Subject: Re: Index Reorg(unload/reload)
Message-ID: <37A273...@ix.netcom.com>

Steve Franzon wrote:
>
> How did you determine there are only 20K entries? That really
doesn't
> sound right for a MA set.
>
>
> Personally, I'd also stick with the area size the calculations
come up
> with and "enjoy" the extra free space. But if you are worried
about
> wasting space, do a test run and "guesstimate" a better area
size.
>
> Hope this helps,

> Steve Franzon
>
>
> ______________________________ Reply Separator
_________________________________

> Subject: Index Reorg(unload/reload)
> Author: idm...@iuassn.com at internet
> Date: 07/30/1999 3:11 PM
>
> Hi all;
>
> This is my first time.
>
> I am going to reorg an index that points to a very large number of
> duplicate member records. I noticed that out of 600,000 members that
> only about 20,000 are unique. I also noticed that even though the

Here's some bloomin' idiot talk...

Steve Franzon is correct. When an index set allows duplicates, the
duplicate instances of the symbolic key are *NOT* repeated within the
sequence set SR8s (L0). This makes them far smaller than anticipated.

If the bfaser means that he has 600,000 members but only 20,000 unique
key values, I must say that this is a heavily duplicated index. What,
pray tell, is the key?

I like to say: "It's not how many symbolic keys that are in an SR8 that
determines its 'fullness' it's how many dbkeys (down pointers) it
contains."

If an index set is defined as BLOCK CONTAINS 50, and all 50 members that

encompass the keys stored within a L0 SR8 are of equal value, there will

be a single instance of the symbolic key but 50 dbkeys: This SR8 is full

even though it is far smaller than a "DUPLICATES NOT ALLOWED" type of
index.

I also agree with Steve about sizing for the "maximum". If the index is
truly as heavily duplicated as bfaser says, a downsizing of the page
range should be done once a rebuild determines exactly the amount of
space that the index consumes.

Finally, I have seen many, many index sets that were coded as DL or DF,
but didn't have a single duplicate key within them. My point? DL or DF
alone is no indication of how heavily duplicated a sequence set will be.

Jim Moore

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

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

0 new messages