daily listing of IDMS-L

Chris Hoelscher

unread,

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

to

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

IDMS-L Sat, 10 Jul 1999 Volume 1 :
Number 21

In this issue:

Re: Area expansion ( R 14.0 / 9711 )
RE: Area expansion ( R 14.0 / 9711 )
RE:Area expansion ( R 14.0 / 9711 )
SQL Procedures
Enlarge Area - DB-EZREORG
RE:Area expansion ( R 14.0 / 9711 )
RE: Area expansion ( R 14.0 / 9711 )
RE: Area expansion ( R 14.0 / 9711 )
Maximum terminal sessions?
Re: Area expansion ( R 14.0 / 9711 )
Re: Area expansion ( R 14.0 / 9711 )
RE: Maximum terminal sessions?
Re: Area expansion ( R 14.0 / 9711 )
Re: SQL Procedures
Re: Y2K testing Hourglass IDMS 14.0 ADSBATCH DATEX
RE: SQL Procedures
unload/reload question
Re: SQL Procedures
SQL for IDMS
SQL question
RE: SQL for IDMS
Thanks
RE: You're invited to the IDMS CA-World '99 Meltdown Party!
RE: SQL question
RE: SQL question
load balancing techniques
Re: SQL question
download multiple fixes at one time in TCC!
Millinneum Watch Earling Warning

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

Date: Fri, 9 Jul 1999 11:57:21 +0100
From: j...@maerskdata.dk
To: idm...@iuassn.com
Subject: Re: Area expansion ( R 14.0 / 9711 )
Message-ID: <412567A9.0...@mdcsmtp.cph.dnk.maersknet.com>

Remember all the relevant buffers.

Jesper Sleth
SLETH IT

"bob harle" <bha...@epo.nl> on 09-07-99 11:49:17

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Jesper Sleth/Maersk Data/DK)
Subject: Re: Area expansion ( R 14.0 / 9711 )

I'll have a go at this, since most of our US colleagues are still
asleep...
Yes, you can extend the area's page range up to the MAX SPACE on your
segment,
but as you say, your CALC chains will grow to horrendous lengths.
PAGE EXPAND is easy, as long as you remember the ORIGINAL PAGE SIZE
clause.

I suppose you monitor area space utilisation, but the users suddenly
decided to add 600% of the normal number of records .....
happens all the time.

Good luck

Bob Harle

Stewart, Jeremy wrote:
>
> 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

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

Date: Fri, 9 Jul 1999 12:09:35 +0200
From: =?iso-8859-1?Q?Brandt_Ren=E9?= <r...@ubp.ch>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Area expansion ( R 14.0 / 9711 )
Message-ID:
<693E4DC6C79FD211907...@mailgva.geneve.ubp.ch>

if you increase the buffers the DMCL will be bigger so you have to =
check if
the cv has enough space for it.

> -----Message d'origine-----
> De: Stewart, Jeremy [SMTP:Stew...@BASINGSTOKE.AWA-CPO.com]
> Date: Friday, July 09, 1999 11:29 AM
> =C0: idm...@iuassn.com
> Objet: Area expansion ( R 14.0 / 9711 )
>=20
> We have an urgent need to enlarge an area ( 6000 trks ) which=20
> 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=20
> therefore must consider an alternative
>=20
> This seems to leave us with a choice of two:
>=20
> 1 Increase the area page size which is quick ( 5 minutes )
> 2 Extend the area's page range which is also quick ( ?? )=20
> and which the manual seems to indicate does not need=20
> an unload/reload but ...
>=20
> am I right in thinking that this second option will be very =
inefficient
> because the CALC's will start producing numerous overflows ?
>=20
> Could anyone with more technical know-how and experience of=20
> such utilities give me any advice on this, please ?
>=20
> Thanks.
>=20
> Jeremy R.L. Stewart
> Database Administrator
> Carbonless European Operations
> Arjo Wiggins Appleton Holdings Ltd
>=20
> =
________________________________________________________________________=

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

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

Date: Fri, 9 Jul 1999 06:27:00 +0100
From: ("leslie a jordan") <LCC/JOR...@aeilogis.com>
To: idm...@iuassn.com
Subject: RE:Area expansion ( R 14.0 / 9711 )
Message-ID: <NAc49375...@aeilogis.com>

We are a rel 12 vm shop and had occasion to expand two large areas
containing
calc and
via records at the beginning of the year. As you say, unload/reload
would
have taken
too long. Unfortunately we did not have the luxury of expanding the
page size
since we
are already at the max 4k under vm. We were also at the MAX SPACE on our

segment
so that also was not an option. What I did was to 'tack on' space to the
end
of the area
and ran a cobol area sweep in local mode backwards against the calc
records.
The area sweep modified the calc key of each record to a new value, then

modified it back to the old. This 'sorted out' the calc key with the new
page
range. In each area there was only one record type that was calc - the
rest
were via. Timings for these expansions were:
area 1 - 845961 pages old/998783 pages new/708,236 calc recs - 7:24
hours
(not including backup/testing afterwards)
area 2 - 258304 pages old/318982 pages new/410,673 calc recs - 4:04
hours
(again not
including backup/testing)
This method assumes that you have enough space between the end of your
current
area page ranges and the beginning of the next area's page ranges to add
on
the space.

Ms Leslie A Jordan - DBA

Air Express Intl

Staines, Middlesex UK

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

Date: Fri, 9 Jul 1999 11:38:29 +0100
From: "Shaw, Brock" <brock...@MBUK.Mercedes-Benz.com>
To: "IDMS-L (List) (E-mail)" <idm...@iuassn.com>
Subject: SQL Procedures
Message-ID: <81C700BB8A25D3119EE50010E360DAC6087A3B@S184EXC3>

This message is in MIME format. Since your mail reader does not
understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEC9F6.D8B97C48
Content-Type: text/plain;
charset="iso-8859-1"

A member of the UK IDMS User Association is looking for advice to the
new
user of IDMS SQL Option.

This is particularly in relation to setup, procedures, migration, etc.,
with
the object of avoiding some of the pitfalls by getting advice from
people
who have been there.

Please respond if you feel that you have something along these lines
that
you would like to share.

Thanks,
Brock.

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

------_=_NextPart_001_01BEC9F6.D8B97C48
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

A member of the UK IDMS User = Association is looking for advice to the
new user of IDMS SQL = Option.

This is particularly in relation to = setup, procedures, migration,
etc., with the object of avoiding some of = the pitfalls by getting
advice from people who have been = there.

Please respond if you feel that you = have something along these lines
that you would like to share.

Thanks,
Brock.

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

------_=_NextPart_001_01BEC9F6.D8B97C48--

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

Date: Fri, 9 Jul 1999 07:35:26 -0400
From: "Audrey A. Hunt" <Audrey_...@NEWYORKLIFE.COM>
To: IDM...@IUASSN.COM
Subject: Enlarge Area - DB-EZREORG
Message-ID: <852567A9.0...@Email.NewYorkLife.com>

To reduce downtime while performing an unload/reload we use a utility
from TACT
- DB-EZREORG. This allowed us to keep the database online while reorg
was
running (5 days) with only an hour of down time to perform a swap and
test. We
have had no problem with the utility.

Stewart, Jeremy wrote:
>
> 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
>

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

Date: Fri, 9 Jul 1999 08:41:27 -0400
From: "David R Slocum" <drsl...@cmsenergy.com>
To: idm...@iuassn.com
Subject: RE:Area expansion ( R 14.0 / 9711 )
Message-ID: <852567A9.0...@pr1lns45.cpco.com>

I see a couple of problems with the method that you're suggesting.
First of
all, when you modify the calc key and then change it back, there is no
guarantee
that it is going to "re-calc" to the same relative position in the
expanded
area. It may re-calc to an earlier page. Therefore, as you are
sweeping the
area from back to front, you will end up processing upwards of half of
your calc
records twice. Second, what about the via records? If they are via the
calc
records that you have just moved, then they will no longer be on the
target
page. You will incur an extra I/O whenever you walk the via set from
the calc
record.

I fail to see how this method can be any better than an unload/reload.
In fact,
for the two reasons stated above, I've got to believe it's worse. Maybe
there's
more to this than you've mentioned in your note. Anyway, for what it's
worth,
these are just my thoughts on the matter.

David R. Slocum
drsl...@cmsenergy.com
Consumers Energy

("leslie a jordan") "LCC/JORDAN"@aeilogis.com on 07/09/99 01:27:00 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: David R Slocum/Pr/Consumers/CMS)
Subject: RE:Area expansion ( R 14.0 / 9711 )

We are a rel 12 vm shop and had occasion to expand two large areas
containing
calc and
via records at the beginning of the year. As you say, unload/reload
would
have taken
too long. Unfortunately we did not have the luxury of expanding the
page size
since we
are already at the max 4k under vm. We were also at the MAX SPACE on our

segment
so that also was not an option. What I did was to 'tack on' space to the
end
of the area
and ran a cobol area sweep in local mode backwards against the calc
records.
The area sweep modified the calc key of each record to a new value, then

modified it back to the old. This 'sorted out' the calc key with the new
page
range. In each area there was only one record type that was calc - the
rest
were via. Timings for these expansions were:
area 1 - 845961 pages old/998783 pages new/708,236 calc recs - 7:24
hours
(not including backup/testing afterwards)
area 2 - 258304 pages old/318982 pages new/410,673 calc recs - 4:04
hours
(again not
including backup/testing)
This method assumes that you have enough space between the end of your
current
area page ranges and the beginning of the next area's page ranges to add
on
the space.

Ms Leslie A Jordan - DBA

Air Express Intl

Staines, Middlesex UK

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

Date: Fri, 9 Jul 1999 07:42:49 -0500
From: Michael Newman <Michae...@soph.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Area expansion ( R 14.0 / 9711 )
Message-ID: <014CEBE84B9BD2118FFB0008C74C5E3C28C7@GRNSBORO>

As I recall, once a db-key, always a db-key. Therefore the records are
not really "moving", only there target page. The Calc set must now
chain the records to the "new" targeted page. You now have Calc
overflow for all your existing records. Performance has got to be
worse, the only saving grace I can see, is that you can run the program
with the areas still available, without taking them away from the users.

The end result is more space, but at a cost of much poorer performance.

JM2Cs
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: David R Slocum [mailto:drsl...@cmsenergy.com]
Sent: Friday, July 09, 1999 8:41 AM
To: idm...@iuassn.com
Subject: RE:Area expansion ( R 14.0 / 9711 )

I see a couple of problems with the method that you're
suggesting. First of
all, when you modify the calc key and then change it
back, there is no guarantee
that it is going to "re-calc" to the same relative
position in the expanded
area. It may re-calc to an earlier page. Therefore, as
you are sweeping the
area from back to front, you will end up processing
upwards of half of your calc
records twice. Second, what about the via records? If
they are via the calc
records that you have just moved, then they will no
longer be on the target
page. You will incur an extra I/O whenever you walk the
via set from the calc
record.

I fail to see how this method can be any better than an
unload/reload. In fact,
for the two reasons stated above, I've got to believe
it's worse. Maybe there's
more to this than you've mentioned in your note.
Anyway, for what it's worth,
these are just my thoughts on the matter.

David R. Slocum
drsl...@cmsenergy.com
Consumers Energy

("leslie a jordan") "LCC/JORDAN"@aeilogis.com on
07/09/99 01:27:00 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: David R Slocum/Pr/Consumers/CMS)
Subject: RE:Area expansion ( R 14.0 / 9711 )

We are a rel 12 vm shop and had occasion to expand two
large areas containing
calc and
via records at the beginning of the year. As you say,
unload/reload would
have taken
too long. Unfortunately we did not have the luxury of
expanding the page size
since we
are already at the max 4k under vm. We were also at the
MAX SPACE on our
segment
so that also was not an option. What I did was to 'tack
on' space to the end
of the area
and ran a cobol area sweep in local mode backwards
against the calc records.
The area sweep modified the calc key of each record to a
new value, then
modified it back to the old. This 'sorted out' the calc
key with the new page
range. In each area there was only one record type that
was calc - the rest
were via. Timings for these expansions were:
area 1 - 845961 pages old/998783 pages new/708,236 calc
recs - 7:24 hours
(not including backup/testing
afterwards)
area 2 - 258304 pages old/318982 pages new/410,673 calc
recs - 4:04 hours
(again not
including backup/testing)
This method assumes that you have enough space between
the end of your current
area page ranges and the beginning of the next area's
page ranges to add on
the space.

Ms Leslie A Jordan - DBA

Air Express Intl

Staines, Middlesex UK

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

Date: Fri, 9 Jul 1999 09:23:00 +0100
From: ("leslie a jordan") <LCC/JOR...@aeilogis.com>
To: idm...@iuassn.com
Subject: RE: Area expansion ( R 14.0 / 9711 )
Message-ID: <NZc8772d...@aeilogis.com>

The records do not move - it is reflected in the calc chain. Yes, the
performance will
suffer, but in our case most of these calc records have a 6-month life
span
before
archiving and purging. (And of course most new calc records will store
to the
proper pages). In our case the differece was between an 8-hour outage
and
about a 20-hour
outage. DB-EZREOG was also mentioned but the last time l had information
on
that
product it was not available for VM.

Ms. Leslie A Jordan - DBA

Air Express Intl

Staines, Middlesex UK

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

Date: Fri, 9 Jul 1999 09:28:11 -0400
From: "James Ritterbusch" <james.ri...@prudential.com>
To: idm...@iuassn.com
Subject: Maximum terminal sessions?
Message-ID: <852567A9.0...@njros1ngw09.metro.prudential.com>

Does anybody know the absolute theoretical maximum number of terminal
sessions
(concurrent users) that CV under release 12 can handle? I found that
UCF has a
limit of 32767, but cannot find a similar reference for VTAM.

Jim Ritterbusch
Prudential Relocation

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

Date: Fri, 09 Jul 1999 07:59:14 -0700
From: JB Moore <conl...@ix.netcom.com>
To: idm...@iuassn.com
Subject: Re: Area expansion ( R 14.0 / 9711 )
Message-ID: <37860E...@ix.netcom.com>

Stewart, Jeremy wrote:
>
> 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

Jeremy,

This is a slam-dunk cinch if the following is true:

"In the Area that needs to be enlarged, there are no logically full
pages and the logical records (CALC and VIA) are fairly long."

The EXPAND PAGE will solve your problem pronto.

Of course, you will have to determine if the buffering has to be
altered. PRINT SPACE and LOOK DMCL will tell you everything you need to
know.

BTW, you didn't mention the page size. Is it already "up there" in terms

of 3390 geometry? Something like 13680 or 18452 or even the 1/2 TRK
27996? If this is the case, monitor the Area carefully after any EXPAND
PAGE for logically full pages. If you are already at 27996, forget about

the EXPAND PAGE.

Ever since the "single DMCL" has come into play in Release 12, I have
become more and more of a believer in EXPAND PAGE. In older releases,
the proliferation of DMCL load modules would burn DBAs time and again
when they did page expands. It is far less common now that CA-IDMS
generally uses the rule of "one CV, one DMCL".

Jim Moore
Concentrated Logic Inc.
"Working Smarter"

P.S. If you eventually do an unload/reload on the area, the ORIGINAL
PAGE SIZE is removed from the segment by changing it's numerical value
to the current page size.

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

Date: Fri, 09 Jul 1999 08:02:26 -0700
From: JB Moore <conl...@ix.netcom.com>
To: idm...@iuassn.com
Subject: Re: Area expansion ( R 14.0 / 9711 )
Message-ID: <37860F...@ix.netcom.com>

Stewart, Jeremy wrote:
>
> 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

Jeremy,

This is a slam-dunk cinch if the following is true:

"In the Area that needs to be enlarged, there are no logically full
pages and the logical records (CALC and VIA) are fairly long."

The EXPAND PAGE will solve your problem pronto.

Of course, you will have to determine if the buffering has to be
altered. PRINT SPACE and LOOK DMCL will tell you everything you need to
know.

BTW, you didn't mention the page size. Is it already "up there" in terms

of 3390 geometry? Something like 13680 or 18452 or even the 1/2 TRK
27996? If this is the case, monitor the Area carefully after any EXPAND
PAGE for logically full pages. If you are already at 27996, forget about

the EXPAND PAGE.

Ever since the "single DMCL" has come into play in Release 12, I have
become more and more of a believer in EXPAND PAGE. In older releases,
the proliferation of DMCL load modules would burn DBAs time and again
when they did page expands. It is far less common now that CA-IDMS
generally uses the rule of "one CV, one DMCL".

Jim Moore
Concentrated Logic Inc.
"Working Smarter"

P.S. If you eventually do an unload/reload on the area, the ORIGINAL
PAGE SIZE is removed from the segment by changing it's numerical value
to the current page size.

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

Date: Fri, 09 Jul 1999 10:03:09 -0400
From: "Canon, Hartman" <hartma...@lmco.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Maximum terminal sessions?
Message-ID:
<60875A437C39D211BE86...@emss03m03.orl.lmco.com>

Looking at the #PLEDS I see a field 'PLENTERM DS H Number of
terminals on
LINE.' Since the MAX number that this can hold is +32767, I would
imagine
that this would apply for VTAM also, unless the actual number is further

limited by the code.
HBCanon
Lockheed-Martin
-----Original Message-----
From: James Ritterbusch [mailto:james.ri...@prudential.com]
Sent: Friday, July 09, 1999 9:28 AM
To: idm...@iuassn.com
Subject: Maximum terminal sessions?

Does anybody know the absolute theoretical maximum number of terminal
sessions
(concurrent users) that CV under release 12 can handle? I found that
UCF
has a
limit of 32767, but cannot find a similar reference for VTAM.

Jim Ritterbusch
Prudential Relocation

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

Date: Fri, 9 Jul 1999 11:26:55 -0400
From: "Denise Basore" <DEN...@worldnet.att.net>
To: <idm...@iuassn.com>
Subject: Re: Area expansion ( R 14.0 / 9711 )
Message-ID: <19990709153...@basde01.cai.com>

Jeremy - I just wondered - Have you attempted an unload/reload since you

converted beyond 10.2? The whole procedure is much less painfull than
it
used to be and it runs much faster if you use things like signon
retention
and idmsqsam.

Denise Basore
Eagle Consulting

----------
> From: Stewart, Jeremy <Stew...@BASINGSTOKE.AWA-CPO.com>
> To: idm...@iuassn.com
> Subject: Area expansion ( R 14.0 / 9711 )
> Date: Friday, July 09, 1999 05:29
>
> 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

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

Date: Fri, 9 Jul 1999 11:49:41 -0400
From: "Denise Basore" <DEN...@worldnet.att.net>
To: <idm...@iuassn.com>
Subject: Re: SQL Procedures
Message-ID: <19990709155...@basde01.cai.com>

The pitfalls inherent to turning on SQL are few. If IDMS R12 or R14 was

installed without SQL initially and SQL is purchased later, it is much
cleaner to "pretend" one is installing from scratch (ie create a new CSI

and a new loadlib) than to install SQL as an add-on product. The only
other "gotcha" that I have seen is using SQL code in the same program
along
with navigational DML code. The program can deadlock itself.

Beyond that, implementing SQL is simple and can be done a program at a
time. To access your old data using SQL ensure the SQL catalog is
online
and open for update.
Do a DCUF SET DICTNAME old-dictname so you can find your old
subschemas.
Then from OCF just enter:
CREATE SCHEMA new-sql-schema-name FOR NONSQL SCHEMA old-schema-name;

At this point, all of your old records can now be accessed as tables and

all of your sets have become referential constraints. You can now run
selects, and you can display the table and constraint definitions to use
as
template for actual conversions.

What else do you need?

Denise Basore
Eagle Consulting

----------
From: Shaw, Brock <brock...@MBUK.Mercedes-Benz.com>
To: IDMS-L (List) (E-mail) <idm...@iuassn.com>
Subject: SQL Procedures
Date: Friday, July 09, 1999 06:38

A member of the UK IDMS User Association is looking for advice to the
new
user of IDMS SQL Option.

This is particularly in relation to setup, procedures, migration, etc.,
with
the object of avoiding some of the pitfalls by getting advice from
people
who have been there.

Please respond if you feel that you have something along these lines
that
you would like to share.

Thanks,
Brock.

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

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

Date: Fri, 09 Jul 1999 08:56:14 -0700
From: "Rick Krause"<rkr...@halw.com>
To: <idm...@iuassn.com>
Subject: Re: Y2K testing Hourglass IDMS 14.0 ADSBATCH DATEX
Message-ID: <9907099315....@halw.com>

We didn't notice the problem with DATEX, but we did find that
DATEOFFX
didn't recognize 2/29/00 (in our testing), and raised the issue
with
CA. We haven't heard back yet, but only brought it up a couple of
days ago.

______________________________ Reply Separator
_________________________________
Subject: Y2K testing Hourglass IDMS 14.0 ADSBATCH DATEX
Author: <idm...@iuassn.com> at smtpmail
Date: 7/9/99 10:22 AM

I have a problem with DATEX when i test ADSBATCH in the range
2000-01-01
-- 2000-09-30.

Have anybody out there test datex in adsbatch with the specific range

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

Date: Fri, 9 Jul 1999 10:04:44 -0600
From: "Wood, Chris" <Chris...@gov.ab.ca>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: SQL Procedures
Message-ID:
<71390C47E6E8D111B36B...@eoaexc01.enr.gov.ab.ca>

It may be easy to make the SQL schema from the NON-SQL schema if you
have a
well defined NON-SQL schema with no group elements, redefined element
definitions and no multi-member sets. Also there are problems if you
have
VIA chains owning VIA chains. It is possible to tailor the SQL
definition
after you have created it from the NON-SQL schema but it will probably
be a
problem once you change the original NON-SQL schema definition as IDMS
will
try to dynamically change the SQL definition. As Denise said don't try
mixing DML in a program.

Chris Wood
Alberta Department of Resource Development
CANADA

-----Original Message-----
From: Denise Basore [mailto:DEN...@worldnet.att.net]
Sent: July 9, 1999 9:50 AM
To: idms-l
Subject: Re: SQL Procedures

The pitfalls inherent to turning on SQL are few. If IDMS R12 or R14 was

installed without SQL initially and SQL is purchased later, it is much
cleaner to "pretend" one is installing from scratch (ie create a new CSI

and a new loadlib) than to install SQL as an add-on product. The only
other "gotcha" that I have seen is using SQL code in the same program
along
with navigational DML code. The program can deadlock itself.

Beyond that, implementing SQL is simple and can be done a program at a
time. To access your old data using SQL ensure the SQL catalog is
online
and open for update.
Do a DCUF SET DICTNAME old-dictname so you can find your old
subschemas.
Then from OCF just enter:
CREATE SCHEMA new-sql-schema-name FOR NONSQL SCHEMA old-schema-name;

At this point, all of your old records can now be accessed as tables and

all of your sets have become referential constraints. You can now run
selects, and you can display the table and constraint definitions to use
as
template for actual conversions.

What else do you need?

Denise Basore
Eagle Consulting

----------
From: Shaw, Brock <brock...@MBUK.Mercedes-Benz.com>
To: IDMS-L (List) (E-mail) <idm...@iuassn.com>
Subject: SQL Procedures
Date: Friday, July 09, 1999 06:38

A member of the UK IDMS User Association is looking for advice to the
new
user of IDMS SQL Option.

This is particularly in relation to setup, procedures, migration, etc.,
with
the object of avoiding some of the pitfalls by getting advice from
people
who have been there.

Please respond if you feel that you have something along these lines
that
you would like to share.

Thanks,
Brock.

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

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

Date: Fri, 9 Jul 1999 12:15:51 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: unload/reload question
Message-ID: <852567A9.0...@d54mta03.raleigh.ibm.com>

in the discussion concerning making an area bigger, another alternative
(my
apologies if this has been discussed) is the EXTENR SPACE option within
the DMCL
- i have used this MANY times to get me past a full (or almost full)
problem -
the greatest feature is that the area need NEVER go offline other than
the time
needed to newcopy the DMCL. You must have contiguous pages available
after (or
before?????) the full area - the book documents well how to do this - as
is well
known, the CALC algorythm does not change its parameters with this
change - so
records with a storage mode of CALC will continue to attempt to be
stored in the
old page range; when they cannot, they will be stored in the new file AS

OVERFLOW RECORDS!

so the extend space is a great tool for emergencies, but i would
recommend
scheduling a unload/reload as soon as possible if CALC records are
involved!

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

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

Date: Fri, 9 Jul 1999 12:19:10 -0400
From: "Denise Basore" <DEN...@worldnet.att.net>
To: <idm...@iuassn.com>
Subject: Re: SQL Procedures
Message-ID: <19990709162...@basde01.cai.com>

Chris has a point - When in doubt, copy the original schema and global
subschema to a new name (they can be the same) and use this new name to
do
the SQL create. Then, if necessary, you can change the original nonsql
schema without further complications.

Denise Basore
Eagle Consulting

----------
> From: Wood, Chris <Chris...@gov.ab.ca>
> To: 'idm...@iuassn.com'
> Subject: RE: SQL Procedures
> Date: Friday, July 09, 1999 12:04
>
> It may be easy to make the SQL schema from the NON-SQL schema if you
have
a
> well defined NON-SQL schema with no group elements, redefined element
> definitions and no multi-member sets. Also there are problems if you
have
> VIA chains owning VIA chains. It is possible to tailor the SQL
definition
> after you have created it from the NON-SQL schema but it will probably
be
a
> problem once you change the original NON-SQL schema definition as IDMS

will
> try to dynamically change the SQL definition. As Denise said don't try

> mixing DML in a program.
>
> Chris Wood
> Alberta Department of Resource Development
> CANADA
>
> -----Original Message-----
> From: Denise Basore [mailto:DEN...@worldnet.att.net]
> Sent: July 9, 1999 9:50 AM
> To: idms-l
> Subject: Re: SQL Procedures
>
>
> The pitfalls inherent to turning on SQL are few. If IDMS R12 or R14
was
> installed without SQL initially and SQL is purchased later, it is much

> cleaner to "pretend" one is installing from scratch (ie create a new
CSI
> and a new loadlib) than to install SQL as an add-on product. The only

> other "gotcha" that I have seen is using SQL code in the same program
along
> with navigational DML code. The program can deadlock itself.
>
> Beyond that, implementing SQL is simple and can be done a program at a

> time. To access your old data using SQL ensure the SQL catalog is
online
> and open for update.
> Do a DCUF SET DICTNAME old-dictname so you can find your old
subschemas.

> Then from OCF just enter:
> CREATE SCHEMA new-sql-schema-name FOR NONSQL SCHEMA old-schema-name;
>
> At this point, all of your old records can now be accessed as tables
and
> all of your sets have become referential constraints. You can now run

> selects, and you can display the table and constraint definitions to
use
as
> template for actual conversions.
>
> What else do you need?
>
> Denise Basore
> Eagle Consulting
>
> ----------
> From: Shaw, Brock <brock...@MBUK.Mercedes-Benz.com>
> To: IDMS-L (List) (E-mail) <idm...@iuassn.com>
> Subject: SQL Procedures
> Date: Friday, July 09, 1999 06:38
>
> A member of the UK IDMS User Association is looking for advice to the
new
> user of IDMS SQL Option.
>
> This is particularly in relation to setup, procedures, migration,
etc.,
> with
> the object of avoiding some of the pitfalls by getting advice from
people
> who have been there.
>
> Please respond if you feel that you have something along these lines
that
> you would like to share.
>
> Thanks,
> Brock.
>
> Brock Shaw, DBA (ISD)
> Mercedes Benz (UK), England

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

Date: Fri, 09 Jul 1999 12:26:27 -0500
From: Cindy Hassler <chas...@mail.state.mo.us>
To: IDM...@IUASSN.COM
Subject: SQL for IDMS
Message-ID: <378630C2...@mail.state.mo.us>

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

Our shop recently started trying to use the SQL option in IDMS. The
schema is created and SQL statements execute clean in OCF. The problem
is when we include the SQL statements in a COBOL program. The program
issues a SOC-6 and the SQL error message says the program module cannot
be found although it compiles successfully. Does anyone know where IDMS

is looking for the module at or what could be our problem?

Cindy Hassler
MO. Dept of Social Services

--------------5920367E269C47F9AC6EA6E2
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Cynthia A. Hassler
Content-Disposition: attachment; filename="vcard.vcf"

begin: vcard
fn: Cynthia A. Hassler
n: Hassler;Cynthia A.
org: MO DSS/Division of Data Processing
adr: ;;;;MO;;USA
email;internet: chas...@mail.state.mo.us
title: Database Administrator
tel;work: 573-526-5404
tel;fax: 573-751-6706
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard

--------------5920367E269C47F9AC6EA6E2--

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

Date: Fri, 9 Jul 1999 12:33:33 -0500
From: Kay Rozeboom <Kay.Ro...@its.state.ia.us>
To: IDM...@iuassn.com
Subject: SQL question
Message-ID:
<78DA1160F5BDD111BCC...@its-cn-exchange.its.state.ia.us>

I have an SQL question I am hoping someone can help me with:
For a network database, is there any way to use SQL to select records
that do NOT belong to a set?

Here is my problem: The path is REC1 -> REC2 -> REC3.
Only REC1 has a calc key. REC2 is stored via set REC1-REC2, and REC3 is

stored via set REC2-REC3.
I am trying to select instances where REC1 has REC2 members, but no REC3

members.

Search criteria where "REC2-REC3" is valid syntax, but where not
"REC2-REC3" is not valid syntax.

Has anyone else found a solution to this problem?

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

Date: Fri, 9 Jul 1999 12:35:52 -0500
From: Kay Rozeboom <Kay.Ro...@its.state.ia.us>
To: "'chas...@bigfoot.com'" <chas...@bigfoot.com>,
"'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: SQL for IDMS
Message-ID:
<78DA1160F5BDD111BCC...@its-cn-exchange.its.state.ia.us>

Cindy, does the SQL error message perhaps say that the access module (as

opposed to the program module) cannot be found? When you compile a
COBOL program using SQL, you must add an extra step to create an access
module.

> -----Original Message-----
> From: Cindy Hassler [SMTP:chas...@mail.state.mo.us]
> Sent: Friday, July 09, 1999 12:26 PM
> To: IDM...@iuassn.com
> Subject: SQL for IDMS
>
> Our shop recently started trying to use the SQL option in IDMS. The
> schema is created and SQL statements execute clean in OCF. The
> problem
> is when we include the SQL statements in a COBOL program. The program

> issues a SOC-6 and the SQL error message says the program module
> cannot
> be found although it compiles successfully. Does anyone know where
> IDMS
> is looking for the module at or what could be our problem?
>
> Cindy Hassler
> MO. Dept of Social Services << File: Card for Cynthia A. Hassler >>

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

Date: Fri, 09 Jul 1999 12:55:49 -0500
From: Cindy Hassler <chas...@mail.state.mo.us>
To: IDM...@IUASSN.COM
Subject: Thanks
Message-ID: <378637A4...@mail.state.mo.us>

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

My problem was not in the program. Thanks for everyones help. After
compiling the COBOL program an access module must be created. We missed

this step.

Thanks again,
Cindy

--------------D7D75D9F57DFB8F1EFBE339F
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Cynthia A. Hassler
Content-Disposition: attachment; filename="vcard.vcf"

begin: vcard
fn: Cynthia A. Hassler
n: Hassler;Cynthia A.
org: MO DSS/Division of Data Processing
adr: ;;;;MO;;USA
email;internet: chas...@mail.state.mo.us
title: Database Administrator
tel;work: 573-526-5404
tel;fax: 573-751-6706
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard

--------------D7D75D9F57DFB8F1EFBE339F--

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

Date: Fri, 9 Jul 1999 12:53:01 -0500
From: "Schwartz, Terry" <Terry.S...@ps.net>
To: "'idm...@iuassn.com%smtp'" <idm...@iuassn.com> (IPM Return
Requested)
Subject: RE: You're invited to the IDMS CA-World '99 Meltdown Party!
Message-ID: <DALEXCH01-990709175301Z-74680*/PRMD=PSC/ADMD=MCI/C=US/@MHS>

Need a DJ ????

-----Original Message-----
From: Irene McCann
Sent: Thursday, July 08, 1999 4:05 PM
To: idm...@iuassn.com%smtp
Subject: You're invited to the IDMS CA-World '99 Meltdown Party!

"Party Like It's 1999"
at the IDMS CA-World Meltdown Party

Chris Hoelscher

unread,

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

to

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

IDMS-L Sun, 11 Jul 1999 Volume 1 :
Number 22

In this issue:

IDMS/DC & USSTAB

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

Date: Sun, 11 Jul 1999 07:10:54 -0600
From: "John R. Schafluetzel" <j...@UnivNorthCo.edu>
To: <idm...@iuassn.com>
Subject: IDMS/DC & USSTAB
Message-ID: <000b01becb9e$cee8ff00$2143...@jrs.UnivNorthCo.edu>

Greetings,

We have recently installed IDMS/DC to replace a very old version of
CICS. Is
it possible to code the VTAM USSTAB to have a specific IDMS transaction
be
invoked? SPecifically we would like to be able to invoke an ADS/A
application. We were able to do this under UCF/CICS, and would like to
keep
similar functionality.

THanks

C'JRS' X'D1D9E2'

John R. Schafluetzel, Assistant Director
University Northern Colorado
Information Services
Greeley, Colorado 80639
Voice: (970) 351-1457 Fax: (970) 351-1650
E-Mail: j...@UnivNorthCo.edu

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Mon, 12 Jul 1999 Volume 1 :
Number 23

In this issue:

RE: Area expansion ( R 14.0 / 9711 )

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

Date: Mon, 12 Jul 1999 09:31:15 +0100
From: steve....@bt.com
To: IDM...@IUASSN.COM

Subject: RE: Area expansion ( R 14.0 / 9711 )
Message-ID:

<36980CF17F08D311A1BB...@mcmlsent05.lon.bt.com>

Jeremy

Don't forget the possibility of logically full pages.

The PRINT SPACE FULL output will tell you the size and quantity of the
records in the area, and by simple calcuation against the most prolific

record.
(Ie the one you have most of) you can work out the maximum page size
which
is practical.

By multiplying the record size by 255 (assuming you have the standard
dbkey-radix), that is the maximum page size.

I mention this because the page size you currently have was probably (?)

calculated as being the optimum size at DB design stage .
So It's quite possible that the page size is already the largest
possible.

I hope this isn't like teaching grandma to suck eggs!!

Steve Rundle
BT DBA
Tel- (0171) 843 7481
Intl- +44 171 843 7481
Email- mailto:steve....@bt.com

PS: We also have used DB-EZ Reorg from TACT, although not often enough
to
pass comment.

> -----Original Message-----
> From: JB Moore [SMTP:conl...@ix.netcom.com]
> Sent: Friday, July 09, 1999 4:02 PM
> To: idm...@iuassn.com
> Subject: Re: Area expansion ( R 14.0 / 9711 )
>

> Stewart, Jeremy wrote:
> >
> > 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

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

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Tue, 13 Jul 1999 Volume 1 :
Number 24

In this issue:

14.0 Apar LO50372

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

Date: Mon, 12 Jul 1999 08:34:38 -0600
From: "Wood, Chris" <Chris...@gov.ab.ca>
To: 'Chris Hoelscher' <hoel...@flash.net>
Cc: IDM...@iuassn.com
Subject: 14.0 Apar LO50372
Message-ID:
<71390C47E6E8D111B36B...@eoaexc01.enr.gov.ab.ca>

Chris,

This apar mentions MT. We have not applied because we are not using MT.
Do
you know if it only fixes an MT problem? Should we apply even though we
have
seen no problems?

Thanks

Chris Wood

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Wed, 14 Jul 1999 Volume 1 :
Number 25

In this issue:

LO51408 - warning
Re : LO51408

Re: Area expansion ( R 14.0 / 9711 )

re: LO51408 - warning
Re: load balancing techniques
RE: LO51408 - warning
IDMS 14.0 Corruption Problem - Fixed?
problems I am encountering
Re: IDMS 14.0 Corruption Problem - Fixed?
RE: problems I am encountering
IDMS to Web Workshops
list problems

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

Date: Tue, 13 Jul 1999 08:04:15 -0400
From: "Scott Schieber" <sasc...@blue-bird.com>
To: "IDMS - L" <idm...@iuassn.com>
Subject: LO51408 - warning
Message-ID: <000001becd27$d3eb89c0$8901...@saschieb.blue-bird.com>

Hyper apar LO51408 should come with a warning. This APAR fixes a problem
we
incurred when converting to 14.0 from 12.0 and were given the test
version
of this apar. However, it is still not the same as in 12.0 and could
cause
problems with some programs. In 12.0, when the IF NOT ANY-STATUS was
true
it PERFORMED IDMS-STATUS now it does a NEXT SENTENCE. In a COBOL II
program
or a new COBOL with nested IF/ELSE/END-IF combinations this code will
cause
programmers much grief. A NEXT SENTENCE statement will skip all
statements
until the next "." (period)is found, which could be after some
IF/ELSE/END-IF statements that should be executed. Granted a PERFORM
IDMS-STATUS is unnecessary when NOT ANY-STATUS is true, but I don't
believe
NEXT SENTENCE is the right answer.

I informed the support person of this but apparently they decided this
fix
was what they wanted. Just thought a warning may save some of you some
grief.

Scott Schieber
DBA
Blue Bird Corporation
Ft Valley GA

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

Date: Tue, 13 Jul 1999 13:55:00 +0100
From: "Nithyanandan (CSC FORD)" <NIT...@Genisys.co.uk>
To: 'IDMS-L' <IDM...@iuassn.com>
Subject: Re : LO51408
Message-ID: <B0000...@post.genisys.co.uk>

Hi,
Scott Schieber had written about LO51408 causing control to be
passed outside a (nested) IF command.( v14 only)

When I was being trained, two surefire ways to irritate my master
was to

a) Nesting cobol IF's and IDMS IF's ( like set-name member or
set-empty)

b) Not putting each DML in a separate paragraph.

He was set in his ways even after seeing the expanded listing. These
habits have become so ingrained in me - that I have started insisting
the
same now among team members.

I know it might not be practical to have paragraphs with just one
lines in them. But, they do help while debugging.

- Nyd
Nithyanandan V
Genisys Integrating systems India
Email-id : n...@pobox.com
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager (postm...@genisys.co.uk).

**********************************************************************

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

Date: Tue, 13 Jul 1999 14:14:23 +0100
From: "Gary Bronziet" <gar...@email.msn.com>

To: <idm...@iuassn.com>
Subject: Re: Area expansion ( R 14.0 / 9711 )

Message-ID: <1999071313...@camelot.netcom.net.uk>

Hello Leslie and all,

Just to clarify - EZReorg has been available for VM for some
time. Not sure how long ago you last had information from us.

best regards

Gary Bronziet
Cogito

-----Original Message-----
From: "leslie a jordan" <LCC/JOR...@aeilogis.com>
To: idm...@iuassn.com <idm...@iuassn.com>
Date: 09 July 1999 14:26
Subject: RE: Area expansion ( R 14.0 / 9711 )

>The records do not move - it is reflected in the calc chain.
Yes, the
>performance will
>suffer, but in our case most of these calc records have a
6-month life span
>before
>archiving and purging. (And of course most new calc records will
store to the
>proper pages). In our case the differece was between an 8-hour
outage and
>about a 20-hour
>outage. DB-EZREOG was also mentioned but the last time l had
information on
>that
>product it was not available for VM.
>
> Ms. Leslie A Jordan - DBA
>
> Air Express Intl
>
> Staines, Middlesex UK

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

Date: Tue, 13 Jul 1999 10:36:36 -0400 (EDT)
From: therese ganster <tgan...@ets.org>
To: IDMS - L <idm...@iuassn.com>
Subject: re: LO51408 - warning
Message-ID: <vines.Oh...@cips06.ets.org>

Please note that the DML pre-processor problem fixed by LO51408 was
introduced in Rel 12.0 with tape 9809. Tape 9707did not have this
problem.
Do not assume that if you have Rel 12.0, any tape, you do not have this

problem.

Our site found this problem 2 weeks after we had installed the 9809
tape.
Programs were failing because they were taking an incorrect logic path
caused by this problem. We requested that the apar be made hyper
because
the last thing you want is for a program to take the wrong logic path,
end
up creating or destroying data in error, and never even knowing it. We
found the problem because programs produced results that were
unexpected.

Terri Ganster
-----------------------------------------
Educational Testing Service, Princeton NJ
(609)734-5950
<tgan...@ets.org>
-------------
Original Text
From: "Scott Schieber" <sasc...@blue-bird.com>, on 7/13/99 8:04 AM:
To: SMTP@CIPS06@Servers["IDMS - L" <idm...@iuassn.com>]

Hyper apar LO51408 should come with a warning. This APAR fixes a problem
we
incurred when converting to 14.0 from 12.0 and were given the test
version
of this apar. However, it is still not the same as in 12.0 and could
cause
problems with some programs. In 12.0, when the IF NOT ANY-STATUS was
true
it PERFORMED IDMS-STATUS now it does a NEXT SENTENCE. In a COBOL II
program
or a new COBOL with nested IF/ELSE/END-IF combinations this code will
cause
programmers much grief. A NEXT SENTENCE statement will skip all
statements
until the next "." (period)is found, which could be after some
IF/ELSE/END-IF statements that should be executed. Granted a PERFORM
IDMS-STATUS is unnecessary when NOT ANY-STATUS is true, but I don't
believe
NEXT SENTENCE is the right answer.

I informed the support person of this but apparently they decided this
fix
was what they wanted. Just thought a warning may save some of you some
grief.

Scott Schieber
DBA
Blue Bird Corporation
Ft Valley GA

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

Date: Tue, 13 Jul 1999 10:56:16 -0400
From: "Daniel Begin" <dan...@aquisoft.com>
To: <idm...@iuassn.com>
Subject: Re: load balancing techniques
Message-ID: <004201becd3f$dbf8c520$14c4...@aquisoft.com>

Chris,

Aquisoft has a product called OCA-Syslink that would allow you to
implement
a Frontend/Backend architecture without any modification to the
application.
It works in the same machine or across multiple machines if all machines
are
in a Sysplex. Overhead is minimal. Also works for CICS: CICS frontend
and
CA-IDMS backend can be in different boxes.

If you want more, give me a buzz.

Bye,

Daniel Begin
Aquisoft
http://www.aquisoft.com

----- Original Message -----
From: <hoel...@us.ibm.com>
To: <idm...@iuassn.com>
Sent: Friday, July 09, 1999 4:02 pm
Subject: load balancing techniques

>
>
>
> for a client running 12.01, what Computer Associate or 3rd party
software
> solutions exist to implement load balancing? (we can go to
FrontEnd/BackEnd idms
> regions with LU62, but this client would like other alternates. And i
need
a
> refresher: what load balancing does 14.0 + 14.1 provide?
>
>
> thanks,
>
> Chris Hoelscher
> Sophisticated Business Systems
> Dallas Texas
> On Assignment to IBM Global Services
> Outsourcers for GE Capital Cooporation
>
>
>

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

Date: Tue, 13 Jul 1999 11:52:58 -0400
From: "Jackson, Jeff" <Jeff.J...@fmr.com>
To: "'IDMS List'" <IDM...@iuassn.com>
Subject: RE: LO51408 - warning
Message-ID:
<1FF70DACAF51D2118FBD...@MSGDAL527NTS.fmr.com>

I just checked TCC and LO51408 is listed as a 14.0 only APAR. Is there
a
12.0 version available anywhere?

Jeff Jackson
FPI&BG Dataabase Services
Fidelity Investments
400 E. Las Colinas Blvd., MZ CC2T
Irving, TX 75039
* - 972-584-5276
* Pager: http://www.skytel.com/Paging/pageme.cgi?pin=4197550,1
*mailto:Jeff.J...@fmr.com

> -----Original Message-----
> From: therese ganster [SMTP:tgan...@ets.org]
> Sent: Tuesday, July 13, 1999 9:37 AM
> To: IDMS - L
> Subject: re: LO51408 - warning
>
> Please note that the DML pre-processor problem fixed by LO51408 was
> introduced in Rel 12.0 with tape 9809. Tape 9707did not have this
> problem.
> Do not assume that if you have Rel 12.0, any tape, you do not have
this
> problem.
>
> Our site found this problem 2 weeks after we had installed the 9809
tape.
>
> Programs were failing because they were taking an incorrect logic path

> caused by this problem. We requested that the apar be made hyper
because
> the last thing you want is for a program to take the wrong logic path,
end
>
> up creating or destroying data in error, and never even knowing it.
We
> found the problem because programs produced results that were
unexpected.
>
>
>
> Terri Ganster
> -----------------------------------------
> Educational Testing Service, Princeton NJ
> (609)734-5950
> <tgan...@ets.org>
> -------------
> Original Text
> From: "Scott Schieber" <sasc...@blue-bird.com>, on 7/13/99 8:04 AM:
> To: SMTP@CIPS06@Servers["IDMS - L" <idm...@iuassn.com>]
>
> Hyper apar LO51408 should come with a warning. This APAR fixes a
problem
> we
> incurred when converting to 14.0 from 12.0 and were given the test
version
> of this apar. However, it is still not the same as in 12.0 and could
cause
> problems with some programs. In 12.0, when the IF NOT ANY-STATUS was
true
> it PERFORMED IDMS-STATUS now it does a NEXT SENTENCE. In a COBOL II
> program
> or a new COBOL with nested IF/ELSE/END-IF combinations this code will
> cause
> programmers much grief. A NEXT SENTENCE statement will skip all
> statements
> until the next "." (period)is found, which could be after some
> IF/ELSE/END-IF statements that should be executed. Granted a PERFORM
> IDMS-STATUS is unnecessary when NOT ANY-STATUS is true, but I don't
> believe
> NEXT SENTENCE is the right answer.
>
> I informed the support person of this but apparently they decided this
fix
> was what they wanted. Just thought a warning may save some of you
some
> grief.
>
>
> Scott Schieber
> DBA
> Blue Bird Corporation
> Ft Valley GA
>

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

Date: Tue, 13 Jul 1999 13:15:09 -0400
From: glenn....@ac.com
To: idm...@iuassn.com
Subject: IDMS 14.0 Corruption Problem - Fixed?
Message-ID: <862567AD.0...@amrhm1101.ac.com>

Chris had included an update in the "Above the Line" paper indicating
that the
IDMS 14.0 corruption problem had been fixed by upgrading to 9810 and
installing
some additional PTFs (according to one subscriber). There has since been
a
number of IDMS-L notices regarding the application of specific PTFs
relating to
the problem.

The following is a copy of the note I sent to Chris questioning the
"fixed"
claim ....

Glenn Scott

Glenn A. Scott
07/12/99 09:52 AM EDT

To: Chris Hoelscher <hoel...@flash.net>
cc:
Subject: IDMS 14.0 Corruption Problem

Chris,

I noticed the following in your Above the Line paper ....

CA-IDMS Release 14.0 Corruption Issues FIXED!

I have been informed (by an IDMS-L contributor) that release 14.0
corruption
issues documented in the last issue of ABOVE THE LINE have been fixed
with
application of maintenance tape 9810 and a few addition fixes: LO50372,
TD67302,
LO46421, LO46430, LO46420

=====================================================================================================

Why do you assume that the problem has now been fixed? Based on one
contributor?

CA has NEVER been able to isolate the problem (replicate it) or suggest
a fix.
All that is currently known is that applying certain PTFs and turning
pre-fetch
off appears to help (as in the problem does not occur again but there is
NOTHING
to suggest that it won't occur again since it is not known if applying
the fixes
helps at all!).

I asked if TD67302 would help and I was told it was NOT our problem. The

following is from Dick Weiland ...

I spoke to the apar's author and he feels that it has nothing to do
with your symptoms. The problem addressed by this apar is usually seen
as
unusual abends during recovery and not records being stored into the
wrong areas. If you'll recall, in one of your journals we saw where the

DBMS actually stored the record into the wrong area and then followed
that
with a store of the same record type into the correct area. It had
nothing
to do with an actual recovery operation.
Dick Weiland

As for the other "fixes":

LO50372 - fixes a queue record problem ..... not our issue
LO46421 - already applied
LO46430 - already applied
LO46420 - already applied

Again, we are now at 9810 in development (production is at 9711) and
will not be
upgraded until September. It is POSSIBLE that 9810 with the patches
applied
FIXES the problem, but CA has NEVER said this (as far as I know,
otherwise, they
would recommend we upgrade!).

Glenn Scott

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

Date: Tue, 13 Jul 1999 13:58:20 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: problems I am encountering
Message-ID: <852567AD.0...@d54mta03.raleigh.ibm.com>

just thought I would throw out a few problems that my largest client is
experiencing, and see if anyone is also having (or has solved) these:
(12.01
9809)

1) regions abending with recursive abend & S130?

2) regions, when warmstarting, indicate x number of run units to roll
out, 1 of
the x has a transaction number way out of sync with the others; the
others
successfully roll-out, the warmstart then dies saying it cannot find a
BGIN/CKPT
for the 1 rununit (the one we think really isnt a run unit - or is it a
real run
unit with a corrupted transaction number?

3) problems w/LMGR after applying LO42854?

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

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

Date: Tue, 13 Jul 1999 14:05:05 EDT
From: ARCH...@aol.com
To: idm...@iuassn.com
Subject: Re: IDMS 14.0 Corruption Problem - Fixed?
Message-ID: <bae45935...@aol.com>

Hello Glen:

I also questioned Chris regarding the "Fixed" statement.

I know the problem is related to PREFETCH, we have turned it off 4 weeks
ago
and have not had one single broken chain since. We are running 14.0
Genlevel
9810, we also run multitasking and each buffer has 600 pages in it.

We had over 150 broken chains that we had to fix manually, and we can't
even
get CA to acknowledge that there is a problem/

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

Date: Tue, 13 Jul 1999 13:34:07 -0500
From: "Verinder, Gene" <GVER...@alldata.net>
To: idm...@iuassn.com
Subject: RE: problems I am encountering
Message-ID:
<05B56B254C18D2119EF...@sdadmail1.alldata.net>

Chris,
An old apar (GO19335) says that if you are "USING MVS CHECKPOINT RESTART

FACILITY" you can get S130 abends. I wonder if the fix to RHDCOMVS was
regressed? Can't help with the other problems.
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: Tuesday, July 13, 1999 12:58 PM
To: idm...@iuassn.com
Subject: problems I am encountering

just thought I would throw out a few problems that my largest client is
experiencing, and see if anyone is also having (or has solved) these:
(12.01
9809)

1) regions abending with recursive abend & S130?

2) regions, when warmstarting, indicate x number of run units to roll
out, 1
of
the x has a transaction number way out of sync with the others; the
others
successfully roll-out, the warmstart then dies saying it cannot find a
BGIN/CKPT
for the 1 rununit (the one we think really isnt a run unit - or is it a
real
run
unit with a corrupted transaction number?

3) problems w/LMGR after applying LO42854?

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

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

Date: Tue, 13 Jul 1999 15:11:41 -0400
From: Liza Brady <Br...@tiburontech.com>
To: idm...@iuassn.com
Subject: IDMS to Web Workshops
Message-ID: <378B8F6D...@tiburontech.com>

Tiburon Technologies will be hosting IDMS to Web Workshops during CA
World on July 19, 20 and 21. The workshops will take place daily at
3.30pm and 8pm in booth 665 in the WRC.

Space is limited, so if you would like to attend please e-mail
br...@tiburontech.com specifying the day and time of the workshop you
would like to attend.

Don't forget to register for the car sweepstakes at
http://www.tiburontech.com

See you in New Orleans!

--
Liza Brady
Tiburon Technologies
Phone (216) 520-3100
Fax (216) 520-3101
http://www.tiburontech.com

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

Date: Tue, 13 Jul 1999 16:56:27 -0400
From: "McPhee, Sid" <SMc...@hess.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Message-ID: <E048184A9C25D311B50600104BD011656DEAC4@WDB_EX_002>

this is a test....

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

Date: Tue, 13 Jul 1999 20:58:41 -0500
From: Chris Hoelscher <hoel...@flash.net>
To: idm...@iuassn.com
Subject: list problems
Message-ID: <1999071401...@ares.flash.net>

for those who have experienced mail failures due to MX errors (reverse
DNS
lookups), our ISP has assured me that this problem been resolved on
their
end, and as soon as each local mail server refreshed its copy of the ip
address table, all will be well with receiving mail!

chris hoelscher

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Thu, 15 Jul 1999 Volume 1 :
Number 26

In this issue:

COBOL DML fixes LO51407 and LO51408
Re:
RE:COBOL DML fixes LO51407 and LO51408
SQL question
the Culprit
CA-World

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

Date: Wed, 14 Jul 1999 08:06:55 -0400
From: "Sussmann, K Kay" <KKay.S...@CAI.COM>
To: "'IDM...@iuassn.com'" <IDM...@iuassn.com>
Subject: COBOL DML fixes LO51407 and LO51408
Message-ID: <4C094419B0E6D2119FF...@usilmse1.cai.com>

The code generated by a DML call which specified ON ANY-STATUS was
revised
to avoid LE370 COBOL IGYOP309 warning messages within the IDMS-STATUS
code
on the ROLLBACK command:

IF NOT ANY-STATUS PERFORM IDMS-STATUS;
ELSE <action>.

After some thought, since the PERFORM IDMS-STATUS could never be
executed,
we decided that generating

IF ANY-STATUS <action>.

Would effectively produce the desired results without an objection from
LE370 COBOL. Problem COMPLR/405 published the fix as LO38984 (12.0) and

LO38990 (14.0).

Unfortunately, we didn't think hard enough and as a result numerous
problems
have been reported. We re-thought the solution and have addressed it in

problem COMPLR/414 with published HYPER fixes LO51407 (12.0) and LO51408

(14.0) to generate the following:

IF NOT ANY-STATUS NEXT SENTENCE
ELSE <action>.

Which should address both the problems reported by COMPLR/405 and the
problems which COMPLR/405 attempted to address. A 14.1 version of the
COMPLR/414 fix will be available soon.

My apologies to all who have been "bitten" by the COMPLR/405 fix.

K Kay Sussmann
CA-IDMS/DB Level II Support

Computer Associates Tel: 703-708-3726
575 Herndon Pkwy #2W412 Fax: 703-708-3683
Herndon, Va 20170 eMail: susk$0...@mail.cai.com

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

Date: Wed, 14 Jul 1999 07:49:20 -0500
From: Bill....@ipaper.com
To: " - *idm...@iuassn.com" <idm...@iuassn.com>
Subject: Re:
Message-ID: <0057390007557159000002L992*@MHS>

your test worked!

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

Date: Wed, 14 Jul 1999 08:04:00 -0700
From: Linda....@bergenbrunswig.com
To: idm...@iuassn.com
Subject: RE:COBOL DML fixes LO51407 and LO51408
Message-ID: <NZ3dc637...@bergenbrunswig.com>

How about IDMS Release 14.1 (tape 9811)? Will there be similar problem
and
need a fix?

Linda Kinnard
Bergen Brunswig Corporation
EMAIL:linda....@bergenbrunswig.com

------------------( Forwarded letter 1 follows )--------------------
Date: Wed, 14 Jul 1999 08:06:55 -0400
To: IDM...@iuassn.com
From: KKay.S...@CAI.COM
Sender: list...@iuassn.com
Reply-To: idm...@iuassn.com
Subject: COBOL DML fixes LO51407 and LO51408

The code generated by a DML call which specified ON ANY-STATUS was
revised
to avoid LE370 COBOL IGYOP309 warning messages within the IDMS-STATUS
code
on the ROLLBACK command:

IF NOT ANY-STATUS PERFORM IDMS-STATUS;
ELSE <action>.

After some thought, since the PERFORM IDMS-STATUS could never be
executed,
we decided that generating

IF ANY-STATUS <action>.

Would effectively produce the desired results without an objection from
LE370 COBOL. Problem COMPLR/405 published the fix as LO38984 (12.0) and

LO38990 (14.0).

Unfortunately, we didn't think hard enough and as a result numerous
problems
have been reported. We re-thought the solution and have addressed it in

problem COMPLR/414 with published HYPER fixes LO51407 (12.0) and LO51408

(14.0) to generate the following:

IF NOT ANY-STATUS NEXT SENTENCE
ELSE <action>.

Which should address both the problems reported by COMPLR/405 and the
problems which COMPLR/405 attempted to address. A 14.1 version of the
COMPLR/414 fix will be available soon.

My apologies to all who have been "bitten" by the COMPLR/405 fix.

K Kay Sussmann
CA-IDMS/DB Level II Support

Computer Associates Tel: 703-708-3726
575 Herndon Pkwy #2W412 Fax: 703-708-3683
Herndon, Va 20170 eMail: susk$0...@mail.cai.com

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

Date: Wed, 14 Jul 1999 12:22:54 -0500
From: Kay Rozeboom <Kay.Ro...@its.state.ia.us>
To: "'IDM...@iuassn.com'" <IDM...@iuassn.com>

Subject: SQL question
Message-ID:
<78DA1160F5BDD111BCC...@its-cn-exchange.its.state.ia.us>

Thanks to everyone who replied to me about this question.
I received a number of suggestions that I thought would work,
but sadly, none of them were able to solve my problem when
tested. This problem is more difficult than it appears!

I now believe that the only way to test for records that do NOT
have members in the second (or greater) set of a via chain, is to
use standard DML via a table procedure.

My users on this project are opposed to the use of table procedures.
The web developers do not know COBOL, and vice versa.
Since there appears to be no alternative, they may just have to
work together on this one!

Again, thanks to all who tried to help.

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

--------------------
p.s. I think this problem could be solved if CA added one of the
following extensions of ANSI-standard SQL:

1) A test for non-set membership: WHERE NOT "REC2-REC3"

or

2) A method of retrieving and using the DB-key:
SELECT DBKEY FROM REC2
SELECT * FROM REC2 WHERE DBKEY = 99999999
This would allow selection (or rejection) of specific via records.

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

Date: Wed, 14 Jul 1999 14:54:13 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: the Culprit
Message-ID: <852567AE.0...@d54mta03.raleigh.ibm.com>

the following question was asked of me: in a culprit DB run, the entry
record is
defined as CALC (supposedly no index on any field), but a concatenated
key.

when running a keyfile, the user is unable to get ANY matches when using
both
key fields in the KEYFILE dataset (with the appropriate KF=)

when running the keyfile with only the first filed specified in the KF=,
records
are returned, but the user was unclear as to whether unwanted records
were
returned as well.

has anyone been successful in getting a keyfile to work with CALC
records when
multiple fields comprise the CALC key? (and apparently no single element
defines
the CALC key)

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

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

Date: Wed, 14 Jul 1999 18:06:11 -0400
From: fr...@allensysgroup.com (Fred Goodwin)
To: IDM...@IUASSN.COM
Subject: CA-World
Message-ID: <F49ECC7F92F5D21185C60000F4A254392B6662@ASGMAIL>

Subject Line: ASG Reception Party at CA-World

Are you planning to attend CA World? If you are, please plan to stop and

visit the world's largest provider of Enterprise Productivity Software
and the second largest vendor in CA-IDMS tools, Allen Systems Group
(ASG), at booth #539.
The latest ASG products and demonstrations will be displayed and ASG
sales and technology experts will be available to answer your questions.

ASG will also host a reception at the Hyatt Regency New Orleans. There
will be beverages, food, fellow CA World guests, and ASG team members.
It will take place from 10:00 PM-1:00 AM on July 19th in the Poydras
Room. So please stop by and network, learn and have fun.

Frederick Goodwin
Director, Customer Support
Allen Systems Group
1333 Third Avenue South
Naples, Florida 34102
(800) 932-5536 x2260
e-mail: fr...@asg.com
web page: www.asg.com

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Fri, 16 Jul 1999 Volume 1 :
Number 27

In this issue:

RE: the Culprit

RE: Area expansion ( R 14.0 / 9711 )

RE:Buffer Prefetch

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

Date: Thu, 15 Jul 1999 08:09:22 -0500
From: "Lorenzen, David C" <david.l...@eds.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: the Culprit
Message-ID: <B9CB0C7E771ED2119FA400A02461EE240325E7BB@USPLM206>

Chris,

In a Culprit DB run with the entry record defined as CALC and having
multiple fields as the key; the KF= must reflect the starting position
and
total length of the key (length of all fields). This assumes that the
multiple fields in the CALCKEY are contiguous. I have had and continue
to
have success running this type of Culprit DB access.

David Lorenzen
EDS

> ----------
> From: hoel...@us.ibm.com
> Sent: Wednesday, July 14, 1999 1:54 PM

> To: idm...@iuassn.com
> Subject: the Culprit
>
>
>
>

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

Date: Thu, 15 Jul 1999 14:25:51 +0100
From: "Stewart, Jeremy" <Stew...@BASINGSTOKE.AWA-CPO.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: Area expansion ( R 14.0 / 9711 )

Message-ID: <C8C547D6EBA3D111BBFF00805FA604547AD608@BASEXCHANGE>

Is this okay also ? Stephen is concerned about this.

> -----Original Message-----
> From: steve....@bt.com [SMTP:steve....@bt.com]
> Sent: 12 July 1999 09:31
> To: IDM...@IUASSN.COM
> Subject: RE: Area expansion ( R 14.0 / 9711 )
>

> > Sent: Friday, July 09, 1999 4:02 PM
> > To: idm...@iuassn.com
> > Subject: Re: Area expansion ( R 14.0 / 9711 )
> >

> ______________________________________________________________________

> __________

> 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: Thu, 15 Jul 1999 14:27:11 +0100
From: "Stewart, Jeremy" <Stew...@BASINGSTOKE.AWA-CPO.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject:
Message-ID: <C8C547D6EBA3D111BBFF00805FA604547AD609@BASEXCHANGE>

Please ignore previous message Re: Area expansion.
I apologise for sending this in error.

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, 15 Jul 1999 10:08:00 -0500
From: ("John Rich RR") <John...@bfi.com>
To: idm...@iuassn.com
Subject: RE:Buffer Prefetch
Message-ID: <NYb05403...@bfi.com>

I have an update on an issue I raised about a week ago. You may recall
the
following:

"The DCMT VARY BUFFER <name> PREFETCH OFF command shows a buffer
display indicating that prefetch is now "not allowed". However,
when I
do a
PMRM PF8 buffer display, the count of "prefetch hits" continues
to
increase
as if prefetch is still active for that buffer. These two things
would
seem to be
mutually exclusive; if prefetch is off, there shouldn't be any
prefetch
hits... So
it seems as if prefetch really isn't disabled at all, thus, the
DCMT
command
doesn't really work."

I have a resolution on this issue from CA. I kept pestering them long
enough
that
they finally acknowledged that this is indeed a discrepancy. They
confirmed
that the
prefetch feature is truly disabled from the DCMT command for the buffer,
but
that
the prefetch statistics continued to be accumulated in error.

They have come up with an unconfirmed patch called TD67342 which I have
tested
in my systems, and it successfully resolves the discrepancy. With this
patch
installed,
as soon as a buffer prefetch is disabled, the accumulation of
prefetch-hit
statistics are
also turned-off.

Since this is an "unconfirmed" patch at this point, and affects only
statistical displays,
there is no need to rush right out, grab it, and apply it. You might
want to
wait for
official release as a regular confirmed Apar. It modifies the IDMSDBIO
module, which
is a rather important one.

I knew I was correct on this one. (It had to happen sooner or later.
<grin>)

John Rich
Browning-Ferris Industries

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Sat, 17 Jul 1999 Volume 1 :
Number 28

In this issue:

Managing IDMS
RE: Managing IDMS
LO51408 results when compiling VS cobol batch
RE: Managing IDMS
0326 on Hotel
RE: Managing IDMS
RE: Managing IDMS
RE: Managing IDMS

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

Date: Fri, 16 Jul 1999 08:41 -0600 (MDT)
From: Will Hathcock <Will.H...@wcom.com>
To: IDMS Group list <idm...@iuassn.com>
Subject: Managing IDMS
Message-ID: <19990716144436.WEAJ3540@localHost>

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..

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

Date: Fri, 16 Jul 1999 11:42:27 -0400
From: bo...@asg.com (Bob Lowe)
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Managing IDMS
Message-ID: <01BECF80.48...@asg.com>

Hi Will:My name is Bob Lowe with Allen Systems Group in the CA-IDMS
division. ASG offers several suites and tools for CA-IDMS. I would be
happy to send you the brochures that illustrates each one, or you can
check
them out on our web site, http://www.allensysgroup.com.
or we can do both. Let me know what I can do to help,Thanks
-----Original Message-----
From: Will Hathcock [SMTP:Will.H...@wcom.com]
Sent: Friday, July 16, 1999 10:41 AM
To: IDMS Group list
Subject: Managing IDMS

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..

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

Date: Fri, 16 Jul 1999 11:27:29 -0500
From: "Kaufmann, Raymond Jr." <kau...@Jostens.com>
To: "'IDM...@iuassn.com'" <IDM...@iuassn.com>
Subject: LO51408 results when compiling VS cobol batch
Message-ID:
<C52E5E9BE724D311980...@ndpswntx1.owbswntu1.jostens.com>

Applied LO51408 and now have warning messages appearing in the compile.
This is VS cobol batch compile. 9610 didn't
flag any statments on the ROLLBACK. Genlvl 9810 now flags the 'IF NOT

ANY-STATUS" statement.

9610 Compile

05399 * ROLLBACK ON ANY-STATUS
DMLC0235
05400 MOVE 235 TO DML-SEQUENCE
00F93E
05401 CALL 'IDMS' USING SUBSCHEMA-CTRL
00F944
05402 IDBMSCOM (67)

05403 IF NOT ANY-STATUS PERFORM IDMS-STATUS;
00F98E

PERFORM 00F9A2
05404 ELSE

05405 NEXT SENTENCE.

05406 CALL 'ABORT'.
00F9BE
05407 ISABEX. EXIT.
00F9F2

EXIT 00F9F2
***EXIT FROM PERFORMED
PARAGRAPH(S). 00F9F2
05408 192400 IDMS-ABORT.
19240000
SARPAGE 112

9810 Compile

04990 DISPLAY 'DML SEQUENCE ------ ' DML-SEQUENCE.
00CB64
04991 * ROLLBACK ON ANY-STATUS
DMLC0242
04992 MOVE 242 TO DML-SEQUENCE
00CB88
04993 CALL 'IDMS' USING SUBSCHEMA-CTRL
00CB8E
04994 IDBMSCOM (67);

04995 IF NOT ANY-STATUS NEXT SENTENCE ELSE
-UNCOND-
04996 NEXT SENTENCE.

04997 CALL 'ABORT'.
00CBE2
04998 ISABEX. EXIT.
00CC16

*** WARNING *** THE FOLLOWING CONDITIONAL STATEMENT IS
UNCONDITIONALLY
TRUE OR FALSE.
ITS 1 HEX LOCATION PRINTS AS
-UNCOND-
004995

Thank You,
Ray Kaufmann
JOSTENS INC.
kau...@jostens.com
612.946.5510

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

Date: Fri, 16 Jul 1999 11:40:52 -0500
From: "Collins, John" <John.C...@ameriserve.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Managing IDMS
Message-ID: <C7C2EDD6CB94D211A0050000E866FE262DD4E5@dalhq50>

Will,

These are my experiences/thoughts:

A) Concerning a performance monitor -

Pre-Alert from Allen Systems runs outside the address space of IDMS; and

therefore, will allow
changing values of control blocks when the CV is 'hung' and cannot be
addressed directly. It
also allow thresholds to be set to warn the DBA staff of potential
bottle
necks/runtime problems. The Performance Monitor from CA (PERFMON) runs
inside the address space, and does not
have these features. However, PERFMON has a great many batch reports
for
monitoring runtime
and searching for problems, that Pre-Alert does not have. There is
another
monitor from the
Vendor ISP (acronym for International Software Programming; guessing)
that
also runs outside the
address space. I have never worked with this product, but is probably
worth
the investigation.

If your budget allows, two monitors I would purchase PERFMON & one the
others that runs outside
the address space. Just my opinion.

B) Concerning REORG Software -

I have personally completed countless DB expansions using the
UNLOAD/RELOAD
utilities supplied
by CA. Expanding small areas taking 5 minutes, and huge areas taking 24

hours. If Online
update availability is required 24/7 (or really 23 or 23.5 by 7), DB/EZ

Reorg from TACT (the
A Consulting team in NY) is a very solid product. I have not used it
personally, but a shop
where I was formerly on assignment has and does use it extensively.

John Collins

W: 972-364-2743
H: 214-368-1714
Home/Pemanent Email: jhcol...@aol.com

Fom: Will Hathcock [mailto:Will.H...@wcom.com]
Sent: Friday, July 16, 1999 9:41 AM
To: IDMS Group list
Subject: Managing IDMS

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..

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

Date: Fri, 16 Jul 1999 14:34:23 -0500

From: "Lorenzen, David C" <david.l...@eds.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: 0326 on Hotel
Message-ID: <B9CB0C7E771ED2119FA400A02461EE240325E7C7@USPLM206>

For all those going to CA-World, return with lots of information
for the rest of us....

Just be sure you do not receive an 0326 on your Hotel reservations
or more importantly a 1211.

David Lorenzen
EDS

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

Date: Fri, 16 Jul 1999 13:21:14 PDT
From: "Jim Phillips" <jimphi...@hotmail.com>
To: idm...@iuassn.com
Subject: RE: Managing IDMS
Message-ID: <1999071620211...@hotmail.com>

I work in a technical capacity for the vendor PMDC in North America,
International Software Products. All opinions expressed are therefore a
bit
dodgy.

PMDC can indeed run outside of CA-IDMS. It also comes with numerous SAS
reports and an MXG component. We therefore see PMDC as a complete
alternative to the combination of Pre-Alert and Perfmon.

There is also a web enabled version of PMDC which can be seen running
against one of our test CV's at www.intnlsoftwareproducts.com General
information is available at www.ispinfo.com or from our booth at
CA-World.

I hope that a real user of PMDC will post some unbiased comments !

Jim Phillips
ISP
(800) 295-7608

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

>Subject: RE: Managing IDMS
>Date: Fri, 16 Jul 1999 11:40:52 -0500
>
>Will,
>
>These are my experiences/thoughts:
>
>A) Concerning a performance monitor -
>
>Pre-Alert from Allen Systems runs outside the address space of IDMS;
and
>therefore, will allow
>changing values of control blocks when the CV is 'hung' and cannot be
>addressed directly. It
>also allow thresholds to be set to warn the DBA staff of potential
bottle
>necks/runtime problems. The Performance Monitor from CA (PERFMON) runs

>inside the address space, and does not
>have these features. However, PERFMON has a great many batch reports
for
>monitoring runtime
>and searching for problems, that Pre-Alert does not have. There is
another
>monitor from the
>Vendor ISP (acronym for International Software Programming; guessing)
that
>also runs outside the
>address space. I have never worked with this product, but is probably
>worth
>the investigation.
>
>If your budget allows, two monitors I would purchase PERFMON & one the
>others that runs outside
>the address space. Just my opinion.
>
>B) Concerning REORG Software -
>
>I have personally completed countless DB expansions using the
UNLOAD/RELOAD
>utilities supplied
>by CA. Expanding small areas taking 5 minutes, and huge areas taking
24
>hours. If Online
>update availability is required 24/7 (or really 23 or 23.5 by 7),
DB/EZ
>Reorg from TACT (the
>A Consulting team in NY) is a very solid product. I have not used it
>personally, but a shop
>where I was formerly on assignment has and does use it extensively.
>
>John Collins
>
>W: 972-364-2743
>H: 214-368-1714
>Home/Pemanent Email: jhcol...@aol.com
>
>Fom: Will Hathcock [mailto:Will.H...@wcom.com]
>Sent: Friday, July 16, 1999 9:41 AM
>To: IDMS Group list
>Subject: Managing IDMS
>
>
>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: Fri, 16 Jul 1999 15:45:20 -0500
From: "Davis, Mark" <mard...@csw.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Managing IDMS
Message-ID: <1999071620...@interlock.csw.com>

We have PMDC up and running now for some time. It is a solid product
and it
does indeed run outside of the CV just fine with no problems. We have 6

production CV'S, 4 non-production CV's that we are currently using PMDC
with. We have had them in house now for about 4 years. We started with

Perfmon then moved to Pre-Alert and now we are on PMDC.

-----Original Message-----
From: Jim Phillips [mailto:jimphi...@hotmail.com]
Sent: Friday, July 16, 1999 3:21 PM
To: idm...@iuassn.com

Subject: RE: Managing IDMS

I work in a technical capacity for the vendor PMDC in North America,
International Software Products. All opinions expressed are therefore a
bit
dodgy.

PMDC can indeed run outside of CA-IDMS. It also comes with numerous SAS
reports and an MXG component. We therefore see PMDC as a complete
alternative to the combination of Pre-Alert and Perfmon.

There is also a web enabled version of PMDC which can be seen running
against one of our test CV's at www.intnlsoftwareproducts.com General
information is available at www.ispinfo.com or from our booth at
CA-World.

I hope that a real user of PMDC will post some unbiased comments !

Jim Phillips
ISP
(800) 295-7608

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

>Subject: RE: Managing IDMS
>Date: Fri, 16 Jul 1999 11:40:52 -0500
>
>Will,
>
>These are my experiences/thoughts:
>
>A) Concerning a performance monitor -
>
>Pre-Alert from Allen Systems runs outside the address space of IDMS;
and
>therefore, will allow
>changing values of control blocks when the CV is 'hung' and cannot be
>addressed directly. It
>also allow thresholds to be set to warn the DBA staff of potential
bottle
>necks/runtime problems. The Performance Monitor from CA (PERFMON) runs

>inside the address space, and does not
>have these features. However, PERFMON has a great many batch reports
for
>monitoring runtime
>and searching for problems, that Pre-Alert does not have. There is
another
>monitor from the
>Vendor ISP (acronym for International Software Programming; guessing)
that
>also runs outside the
>address space. I have never worked with this product, but is probably
>worth
>the investigation.
>
>If your budget allows, two monitors I would purchase PERFMON & one the
>others that runs outside
>the address space. Just my opinion.
>
>B) Concerning REORG Software -
>
>I have personally completed countless DB expansions using the
UNLOAD/RELOAD
>utilities supplied
>by CA. Expanding small areas taking 5 minutes, and huge areas taking
24
>hours. If Online
>update availability is required 24/7 (or really 23 or 23.5 by 7),
DB/EZ
>Reorg from TACT (the
>A Consulting team in NY) is a very solid product. I have not used it
>personally, but a shop
>where I was formerly on assignment has and does use it extensively.
>
>John Collins
>
>W: 972-364-2743
>H: 214-368-1714
>Home/Pemanent Email: jhcol...@aol.com
>
>Fom: Will Hathcock [mailto:Will.H...@wcom.com]
>Sent: Friday, July 16, 1999 9:41 AM
>To: IDMS Group list
>Subject: Managing IDMS
>
>
>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: Fri, 16 Jul 1999 15:16:33 -0700
From: Keith Vogler <keith....@NAU.EDU>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Managing IDMS
Message-ID: <01BECF9E.3239BE...@nau.edu>

PMDC has been useful for us for a number of years. Call or e-mail me
directly and I'll provide additional information.
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

-----Original Message-----
From: Jim Phillips [SMTP:jimphi...@hotmail.com]
Sent: Friday, July 16, 1999 1:21 PM
To: idm...@iuassn.com
Subject: RE: Managing IDMS

I work in a technical capacity for the vendor PMDC in North America,
International Software Products. All opinions expressed are therefore a
bit
dodgy.

PMDC can indeed run outside of CA-IDMS. It also comes with numerous SAS
reports and an MXG component. We therefore see PMDC as a complete
alternative to the combination of Pre-Alert and Perfmon.

There is also a web enabled version of PMDC which can be seen running
against one of our test CV's at www.intnlsoftwareproducts.com General
information is available at www.ispinfo.com or from our booth at
CA-World.

I hope that a real user of PMDC will post some unbiased comments !

Jim Phillips
ISP
(800) 295-7608

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

>Subject: RE: Managing IDMS
>Date: Fri, 16 Jul 1999 11:40:52 -0500
>
>Will,
>
>These are my experiences/thoughts:
>
>A) Concerning a performance monitor -
>
>Pre-Alert from Allen Systems runs outside the address space of IDMS;
and
>therefore, will allow
>changing values of control blocks when the CV is 'hung' and cannot be
>addressed directly. It
>also allow thresholds to be set to warn the DBA staff of potential
bottle
>necks/runtime problems. The Performance Monitor from CA (PERFMON) runs

>inside the address space, and does not
>have these features. However, PERFMON has a great many batch reports
for
>monitoring runtime
>and searching for problems, that Pre-Alert does not have. There is
another
>monitor from the
>Vendor ISP (acronym for International Software Programming; guessing)
that
>also runs outside the
>address space. I have never worked with this product, but is probably
>worth
>the investigation.
>
>If your budget allows, two monitors I would purchase PERFMON & one the
>others that runs outside
>the address space. Just my opinion.
>
>B) Concerning REORG Software -
>
>I have personally completed countless DB expansions using the
UNLOAD/RELOAD
>utilities supplied
>by CA. Expanding small areas taking 5 minutes, and huge areas taking
24
>hours. If Online
>update availability is required 24/7 (or really 23 or 23.5 by 7),
DB/EZ
>Reorg from TACT (the
>A Consulting team in NY) is a very solid product. I have not used it
>personally, but a shop
>where I was formerly on assignment has and does use it extensively.
>
>John Collins
>
>W: 972-364-2743
>H: 214-368-1714
>Home/Pemanent Email: jhcol...@aol.com
>
>Fom: Will Hathcock [mailto:Will.H...@wcom.com]
>Sent: Friday, July 16, 1999 9:41 AM
>To: IDMS Group list
>Subject: Managing IDMS
>
>
>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

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Sun, 18 Jul 1999 Volume 1 :
Number 29

In this issue:

Perfromance monitors for IDMS
Database management software

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

Date: Sat, 17 Jul 1999 14:38:14 -0400
From: "John M. Fisher" <jmfi...@sherwin.com>
To: IDM...@iuassn.com
Subject: Perfromance monitors for IDMS
Message-ID: <1999071718...@host68.sherwin.com>

I've seen a number of posts, but no mention of I what I think is hands
down
the best monitor out there - CMMT (Cross Memory Master Terminal) from
Aquifir. I haven't been lucky enough to use it for years now, and I
sure do
miss it. It came with a companion XOMT that ran from inside of DC and
if
the names of the products have changed, I'm sure Daniel Begin will jump
in
to correct me. This product blows the doors off all the competition in
usefullness and flexibility and for me operates intuitively like I wish
other
software on all platforms would.

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

Date: Sat, 17 Jul 1999 14:41:15 -0400
From: "John M. Fisher" <jmfi...@sherwin.com>
To: IDM...@iuassn.com
Subject: Database management software
Message-ID: <1999071718...@host68.sherwin.com>

I've found DB-Reorg to be very useful in a lot of situations, and if you
have
any direct records with vias clustered around them, it's a necessity
unless
you can always maintain the same page range or you want to write your
own
unload/reload programs.

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Mon, 19 Jul 1999 Volume 1 :
Number 30

In this issue:

LE370 Dumps and their usefullness

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

Date: Mon, 19 Jul 1999 13:49:41 GMT
From: WIlliam...@blackdecker.com
To: <idm...@iuassn.com>
Subject: LE370 Dumps and their usefullness
Message-ID: <9907199323....@blackdecker.com>

Sorry if this is a little bit away from IDMS but it is slightly related.

We are in the middle of migrating all our IDMS Cobol programs from OS/VS
Cobol
to Cobol for MVS using LE370. I have had several of our applications
staff come
and ask me about the dumps produced from LE.

They are saying that under OS/VS Cobol the dump included an easily
identifiable
offset which when compared the listing produced the failing instruction.
What
they are saying is despite most of the LE dumps being 500000 lines long
they can
see no obvious offset or the like to indicate to them the point of
failure.

This then means that when they have a failure they have to resort to
placing
DISPLAY statements in the code to try and determine where the abend is
occurring.

I am sure there must be something to indicate where the abend has
occurred but I
am similarly in the dark. I would be grateful if anyone has any insight
or
experience they are willing to share regarding LE370 dumps and any
useful
indicators contained therein.

Thanks once again

Bill Martin
DBA Black & Decker

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Tue, 20 Jul 1999 Volume 1 :
Number 31

In this issue:

Re: LE370 Dumps and their usefullness
Fwd: Fw: LE370 Dumps and their usefullness
Re: LE370 Dumps and their usefullness
CA-Server & CA-CAS
Dynam / NoDynam w/Call Identifier/Literal
Re: Dynam / NoDynam w/Call Identifier/Literal
CA WORLD - Education Roundtable - I9040S 7/2/99 3:15 pm. in St.
C
harles C
Re: Dynam / NoDynam w/Call Identifier/Literal
Implementing IDMSINTL
=?iso-8859-1?Q?R=E9f.[2]:_LE370_Dumps_and_their_usefullness?=

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

Date: Mon, 19 Jul 1999 15:20:37 +0200
From: J.A.van....@robeco.nl
To: idm...@iuassn.com
Subject: Re: LE370 Dumps and their usefullness
Message-ID: <C12567B3.004951A9.00@ROTT_MTA_1B.Robeco.nl>

--0__=NpwckAW8QzaS928n86R3D99n04vz14HChsPrifXdtYTbkpWtmngQ8wNa
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

We had some dump problems also. We created a CEEDOPT module which gener=

ates a
CEEPIPI and CEEBINIT loadmodule, and put these loadmodules in our batch=

loadlib.
In this CEEDOPT we put runtime options ABTERMENC=3DABEND and TERMTHDACT=

=3DUADUMP or
DUMP. Sorry for this last one, but I'm not sure anymore what it was. B=

ut don't
leave TRACE on. That's the wrong one.

Hope this helps.

Regards,
Jos=E9 van Kesteren
Robeco Groep

WIlliam...@blackdecker.com on 07/19/99 03:49:41 PM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Jos=E9 van Kesteren/Robeco Group)

Subject: LE370 Dumps and their usefullness

=

--0__=NpwckAW8QzaS928n86R3D99n04vz14HChsPrifXdtYTbkpWtmngQ8wNa
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Thanks once again

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

The information contained in this communication is confidential and may
be
legally privileged. It is intended solely for the use of the individual
or
entity to whom it is addressed and others authorised to receive it. If
you are
not the intended recipient you are hereby notified that any disclosure,
copying, distribution or taking any action in relation to the contents
of this
information is strictly prohibited and may be unlawful. Neither the
sender nor
the represented institution are liable for the correct and complete
transmission of the contents of an e-mail, or for its timely receipt.
------------------------------------------------------------------------------

--0__=NpwckAW8QzaS928n86R3D99n04vz14HChsPrifXdtYTbkpWtmngQ8wNa--

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

Date: Mon, 19 Jul 1999 09:01:56 PDT

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

Subject: Fwd: Fw: LE370 Dumps and their usefullness
Message-ID: <1999071916015...@hotmail.com>

This is a multi-part message in MIME format.

------=_NextPart_000_1d35d7cd_3bda2a63$2645f402
Content-Type: text/plain; format=flowed

>
> > When I want to have a big dump I use the attached.
> >
> > Note that I created this option module solely to get dumps,
> > I don't know what all the options do or what other effect they
> > might have.

> >
> > Jim Phillips
> > ISP
> > (800) 295-7608
> >

> > ----- Original Message -----
> > From: <J.A.van....@robeco.nl>
> > To: <idm...@iuassn.com>
> > Sent: Monday, July 19, 1999 9:20 AM
> > Subject: Re: LE370 Dumps and their usefullness
> >
> >
> >
> >
> > We had some dump problems also. We created a CEEDOPT module which
>generates
> > a
> > CEEPIPI and CEEBINIT loadmodule, and put these loadmodules in our
batch
> > loadlib.
> > In this CEEDOPT we put runtime options ABTERMENC=ABEND and
>TERMTHDACT=UADUMP
> > or
> > DUMP. Sorry for this last one, but I'm not sure anymore what it
was.
>But
> > don't
> > leave TRACE on. That's the wrong one.
> >
> > Hope this helps.
> >
> > Regards,
> > José van Kesteren
> > Robeco Groep
> >
> >
> >
> >
> > WIlliam...@blackdecker.com on 07/19/99 03:49:41 PM

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

> > cc: (bcc: José van Kesteren/Robeco Group)

> > Subject: LE370 Dumps and their usefullness
> >
> >
> >
> >
> >
> >

>--------------------------------------------------------------------------

>--
> > ----

>-------------------------------------------------------------------------

> > -----
> > > The information contained in this communication is confidential
and
>may
> > be
> > > legally privileged. It is intended solely for the use of the
>individual
> > or
> > > entity to whom it is addressed and others authorised to receive
it.
>If
> > you are
> > > not the intended recipient you are hereby notified that any
>disclosure,
> > > copying, distribution or taking any action in relation to the
>contents
>of
> > this
> > > information is strictly prohibited and may be unlawful. Neither
the
> > sender nor
> > > the represented institution are liable for the correct and
complete
> > > transmission of the contents of an e-mail, or for its timely
receipt.
> >
>
>-------------------------------------------------------------------------

> > -----
> > >
> > >
> > >
> > >
> >

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

------=_NextPart_000_1d35d7cd_3bda2a63$2645f402
Content-Type: text/plain;
name="ceeuopt.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="ceeuopt.txt"

CEEUOPT CSECT
CEEUOPT AMODE ANY
CEEUOPT RMODE ANY
CEEXOPT ABPERC=3D(NONE),
=
X
ABTERMENC=3D(ABEND),
=
X
AIXBLD=3D(OFF),
=
X
ALL31=3D(OFF),
=
X
ANYHEAP=3D(16K,8K,BELOW,FREE),
=
X
BELOWHEAP=3D(8K,4K,FREE),
=
X
CBLOPTS=3D(ON),
=
X
CBLPSHPOP=3D(ON),
=
X
CBLQDA=3D(OFF),
=
X
CHECK=3D(ON),
=
X
COUNTRY=3D(US),
=
X
DEBUG=3D(ON),
=
X
DEPTHCONDLMT=3D(10),
=
X
ENVAR=3D(''),
=
X
ERRCOUNT=3D(20),
=
X
ERRUNIT=3D(6),
=
X
FILEHIST=3D(ON),
=
X
HEAP=3D(32K,32K,BELOW,KEEP,8K,4K),
=
X
INQPCOPN=3D(ON),
=
X
INTERRUPT=3D(OFF),
=
X
LIBSTACK=3D(8K,4K,FREE),
=
X
MSGFILE=3D(LEOOUT,FBA,121,0),
=
X
MSGQ=3D(15),
=
X
NATLANG=3D(ENU),
=
X
NOAUTOTASK=3D,
=
X
NONONIPTSTACK=3D(4K,4K,BELOW,KEEP),
=
X
NOTEST=3D(ALL,*,PROMPT,INSPPREF),
=
X
NOUSRHDLR=3D(),
=
X
OCSTATUS=3D(ON),
=
X
PC=3D(OFF),
=
X
PLITASKCOUNT=3D(20),
=
X
POSIX=3D(OFF),
=
X
PRTUNIT=3D(6),
=
X
PUNUNIT=3D(7),
=
X
RDRUNIT=3D(5),
=
X
RECPAD=3D(OFF),
=
X
RPTOPTS=3D(ON),
=
X
RPTSTG=3D(OFF),
=
X
RTEREUS=3D(OFF),
=
X
SIMVRD=3D(OFF),
=
X
STACK=3D(,,BELOW),
=
X
STORAGE=3D(NONE,NONE,NONE,8K),
=
X
TERMTHDACT=3D(UADUMP),
=
X
THREADHEAP=3D(4K,4K,BELOW,KEEP),
=
X
TRACE=3D(OFF,4K,DUMP,LE=3D0),
=
X
TRAP=3D(OFF),
=
X
UPSI=3D(00000000),
=
X
VCTRSAVE=3D(OFF),
=
X
XUFLOW=3D(AUTO)
DC C'5688-198 (C) COPYRIGHT IBM CORP. 1991, 1995. '
DC C'LICENSED MATERIALS - PROPERTY OF IBM'
END
=1A
------=_NextPart_000_1d35d7cd_3bda2a63$2645f402--

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

Date: Mon, 19 Jul 1999 12:52:09 -0400
From: "William Mitzmacher" <William_M...@NEWYORKLIFE.COM>
To: idm...@iuassn.com
Subject: Re: LE370 Dumps and their usefullness
Message-ID: <852567B3.0...@Email.NewYorkLife.com>

Bill,

What IDMS are you on R12 or R14.

Since migrating to IDMS R14 we had lost some of our simple but useful
abend
information that IDMS-DC provides.

For example
PREVIOUS TASK ABENDED WITH ABEND CODE D003
IDMS DC027001 V7 T1184 D003 PROGRAM CHECK IN CCMD161 AT OFFSET 25BC
PSW WAS 078D1000 8C96E3BC DUMP OF TASK FOLLOWS

This was replaced by a D002 message that stated LEAID module could not
be
loaded. No offset was provided.

I have since learned that abend and SPIE processing have changed ever so

slightly in IDMS R14 to cause this side
effect.

After much negotiation with 3 software vendors IBM, Compuware, and of
course CA
the condition has finally reverted
back to a D003 with an offset. This was due to the fact that with the
latest
maint to OS/390 V2R4 LE REL 1.8
put level PUT9904 there is a new option on CEEDOPT.

TRAP=SPIE/NOSPIE

When NOSPIE is selected we get the full functionality back that is
preferred in
this shop.
D003 with an offset.

Bill Mitzmacher
New York Life

WIlliam...@blackdecker.com on 07/19/99 09:49:41 AM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: William Mitzmacher/NYLIC)

Subject: LE370 Dumps and their usefullness

Thanks once again

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

Date: Mon, 19 Jul 1999 14:59:43 -0500
From: "Verinder, Gene" <GVER...@alldata.net>
To: 'idms-l' <idm...@iuassn.com>
Subject: CA-Server & CA-CAS
Message-ID:
<05B56B254C18D2119EF...@sdadmail1.alldata.net>

To those not at CA World, for one reason or another (and to those who
return
with their sanity):

I have a user that is interested in any user experiences with accessing
CA-CAS Manufacturing for both retrieval and update through CA-Server.
The
client is an existing ODBC SQL application that will need tweaking. If
you
would be willing to discuss any experiences privately, send e-mail to me

directly or call.

TIA for any assistance,

Gene Verinder
Systems Programming
Alliance Data Systems

ph: 972.643.1441
fx: 972.643.1580
gver...@alldata.net

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

Date: Mon, 19 Jul 1999 16:31:57 -0400
From: Bruce_...@fmso.navy.mil
To: IDM...@IUASSN.COM
Subject: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <000D222...@fmso.navy.mil>

All DC programs here use "CALL literal" and the NODYNAM parm. It would
be
beneficial for us to use DYNAM in our DC environment but it does seem to
be
against the rules.

The R12.1 and R14 COBOL manual (CD) contains a description (found below)
for
use of DYNAM/NODYNAM in calling other COBOL programs.

********************************************************************************

******************************
Static and dynamic calls -- CA-IDMS supports the following types of
calls provided by VS COBOL II:

- CALL literal with NODYNAM, static (more storage, less CPU)

- CALL identifier, dynamic (less storage, more CPU)

To call a program dynamically you must use the call identifier
format.

A VS COBOL II program can use the COBOL CALL verb to invoke an
assembler or COBOL II subprogram. The CA-IDMS TRANSFER CONTROL
(LINK
or XCTL) must be used for invoking VS COBOL subprograms. The
subprogram must be defined to the system either at SYSGEN or by
using
a DCMT VARY DYNAMIC PROGRAM command. The correct language must be
specified, and the NONOVERLAYABLE attribute must also be specified.

A COBOL II program and all the COBOL II subprograms that it calls
dynamically must be compiled with the same RES/NORES compiler
option.
********************************************************************************

*****************************

So, could anyone explain why DYNAM can be used with a variable
(identifier) as
the program name but not the plain old everyday hard-coded literal? Is
it just
a pre-compiler/compiler thing, that it was coded that way (which I
doubt) or is
it some internal aspect that has escaped me.

Your help is appreciated,
Take Care,
Bruce

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

Date: Mon, 19 Jul 1999 16:51:33 -0500
From: "Brian Potts" <Bdp...@comdisco.com>
To: <idm...@iuassn.com>
Subject: Re: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <s79357...@groupwise.comdisco.com>

Bruce,

Anytime you code a CALL with an identifier (i.e. a variable) the code =

generated is for a DYNAMIC CALL even if the compile option is NODYNAM.
=
The reason for this is very simple, the compiler cannot guarantee the =
value in the variable field at run time, it must assume a changing value
=
is possible and generate a DYNAMIC style CALL>

The only way to get the compiler to generate a static call is to use the
=
CALL literal format and compile with NODYNAM.

I would be very cautious using CALL within a DC program. As you
correctly =
state, the TRANSFER CONTROL is used for this purpose. Ultimately the =
TRANSFER CONTROL produces the same result. The difference is that the =

storage for the program is retrieved from the appropriate storage pool
in =
the DC region with the TRANSFER CONTROL. A dynamic CALL will attempt to
=
get storage from the operating system (MVS GETMAIN) rather than from =
within the region. If too much space is requested in this manner it
could =
bring down the CV.

Brian

>>> <Bruce_...@fmso.navy.mil> 07/19/99 03:31PM >>>
All DC programs here use "CALL literal" and the NODYNAM parm. It would
=
be=20
beneficial for us to use DYNAM in our DC environment but it does seem to
=
be=20
against the rules. =20

The R12.1 and R14 COBOL manual (CD) contains a description (found below)
=
for=20
use of DYNAM/NODYNAM in calling other COBOL programs.

***************************************************************************=

*****
******************************
Static and dynamic calls -- CA-IDMS supports the following types of
calls provided by VS COBOL II:
=20
- CALL literal with NODYNAM, static (more storage, less CPU)
=20
- CALL identifier, dynamic (less storage, more CPU)
=20
To call a program dynamically you must use the call identifier
format.
=20
A VS COBOL II program can use the COBOL CALL verb to invoke an
assembler or COBOL II subprogram. The CA-IDMS TRANSFER CONTROL
(LINK
or XCTL) must be used for invoking VS COBOL subprograms. The
subprogram must be defined to the system either at SYSGEN or by
using
a DCMT VARY DYNAMIC PROGRAM command. The correct language must be
specified, and the NONOVERLAYABLE attribute must also be specified.
=20
A COBOL II program and all the COBOL II subprograms that it calls
dynamically must be compiled with the same RES/NORES compiler
option.
***************************************************************************=

*****
*****************************

So, could anyone explain why DYNAM can be used with a variable
(identifier)=
as=20
the program name but not the plain old everyday hard-coded literal? Is
it =
just=20
a pre-compiler/compiler thing, that it was coded that way (which I
doubt) =
or is=20
it some internal aspect that has escaped me.

Your help is appreciated,
Take Care,
Bruce

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

Date: Mon, 19 Jul 1999 18:07:40 -0400
From: "Harris, Carol" <Carol....@CAI.COM>
To: "'idm...@IUASSN.COM'" <idm...@IUASSN.COM>
Subject: CA WORLD - Education Roundtable - I9040S 7/2/99 3:15 pm. in St.
C
harles C
Message-ID: <4C094419B0E6D2119FF...@usilmse1.cai.com>

Over the past three years, I have met many new DBA's as well as
experienced
IDMS DBA's and you have raised concerns about where you can find
training,can it be customized for your site, enhancements you believe
are
needed to the current classes, and new classes. Your comments have not
fallen on deaf ears.

Education is such a hot topic (and not just in 'Nawlins), the IUA
formally
adopted a new standing committee just for education!

Also, the IMC is holding its first Education Roundtable. Participants
include CA Education personnel, IUA representatives, and our IDMS
Partners.
This roundtable provides you with the opportunity to provide feedback to
CA
and its education partners. We'll also provide an overview of CA's
future
direction in client education. Please your opinion is very important to
us.
This is your opportunity to have a say!

For IDMS'ers holding down the fort back home, please feel free to email
me
with your comments and concerns. I will pass them along to others on
the
education committee.

Thanks in advance
Carol L. Harris
Computer Associates
Client Education Services
Carol....@CAI.COM

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

Date: Mon, 19 Jul 1999 21:52:35 -0400
From: "Mark CONS:Caffrey" <DBA...@mbusa.com>
To: Bruce_...@fmso.navy.mil, Idm...@iuassn.com
Subject: Re: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <s7939e...@mbusa.com>

Bruce,
If you use CALL IDENTIFIER, no matter what DYNAM/NODYNAM parameter you =

use, I believe it will be a dynamic call. There is no way for the
linkage =
editor to resolve a reference to a variable name, so it cannot be
static.
I hope this helps.
Mark

>>> <Bruce_...@fmso.navy.mil> 07/19 4:31 PM >>>
All DC programs here use "CALL literal" and the NODYNAM parm. It would
=
be=20
beneficial for us to use DYNAM in our DC environment but it does seem to
=
be=20
against the rules. =20

The R12.1 and R14 COBOL manual (CD) contains a description (found below)
=
for=20
use of DYNAM/NODYNAM in calling other COBOL programs.

***************************************************************************=

*****
******************************
Static and dynamic calls -- CA-IDMS supports the following types of
calls provided by VS COBOL II:
=20
- CALL literal with NODYNAM, static (more storage, less CPU)
=20
- CALL identifier, dynamic (less storage, more CPU)
=20
To call a program dynamically you must use the call identifier
format.
=20
A VS COBOL II program can use the COBOL CALL verb to invoke an
assembler or COBOL II subprogram. The CA-IDMS TRANSFER CONTROL
(LINK
or XCTL) must be used for invoking VS COBOL subprograms. The
subprogram must be defined to the system either at SYSGEN or by
using
a DCMT VARY DYNAMIC PROGRAM command. The correct language must be
specified, and the NONOVERLAYABLE attribute must also be specified.
=20
A COBOL II program and all the COBOL II subprograms that it calls
dynamically must be compiled with the same RES/NORES compiler
option.
***************************************************************************=

*****
*****************************

So, could anyone explain why DYNAM can be used with a variable
(identifier)=
as=20
the program name but not the plain old everyday hard-coded literal? Is
it =
just=20
a pre-compiler/compiler thing, that it was coded that way (which I
doubt) =
or is=20
it some internal aspect that has escaped me.

Your help is appreciated,
Take Care,
Bruce

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

Date: Tue, 20 Jul 1999 8:27:37 +0100
From: <E.Dij...@rf.rabobank.nl> (Dijkerman E.)
To: <IDM...@IUASSN.COM>
Subject: Implementing IDMSINTL
Message-ID: <vines.CR...@aster.rabobank.nl>

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: Tue, 20 Jul 1999 09:56:48 +0200
From: Jacques_P...@paribas.com
To: idm...@iuassn.com,
J.A.van....@robeco.nl,
WIlliam...@blackdecker.com
Subject: =?iso-8859-1?Q?R=E9f.[2]:_LE370_Dumps_and_their_usefullness?=
Message-ID: <802567B4.0...@lonn000101.uk.paribas.com>

--0__=WC9QRMhcXLSFkEDTFrrQ2G7LfD8umxDA03N6SsrvPiX2grGjIJ9TqpNi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Bonjour,
If you use the 'TEST' option when you compile your program in Cobol,
you'll
find in the CEEDUMP file in the Traceback paragraph under the statement
column
the exact number of failing instruction. I hope I was clear !
Regards .
Jacques.

Internet

De : J.A.van....@robeco.nl le 19/07/99 13:20 GMT

Pour : idms-l

cc :

ccc: Jacques POINSIGNON

Objet : Re: LE370 Dumps and their usefullness

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

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.
--0__=WC9QRMhcXLSFkEDTFrrQ2G7LfD8umxDA03N6SsrvPiX2grGjIJ9TqpNi
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

We had some dump problems also. We created a CEEDOPT module which gener=

ates a
CEEPIPI and CEEBINIT loadmodule, and put these loadmodules in our batch=

loadlib.
In this CEEDOPT we put runtime options ABTERMENC=3DABEND and TERMTHDACT=

=3DUADUMP or
DUMP. Sorry for this last one, but I'm not sure anymore what it was. B=

ut don't
leave TRACE on. That's the wrong one.

Hope this helps.

Regards,
Jos=E9 van Kesteren
Robeco Groep

WIlliam...@blackdecker.com on 07/19/99 03:49:41 PM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com
cc: (bcc: Jos=E9 van Kesteren/Robeco Group)

Subject: LE370 Dumps and their usefullness

=

--0__=WC9QRMhcXLSFkEDTFrrQ2G7LfD8umxDA03N6SsrvPiX2grGjIJ9TqpNi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Thanks once again

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

The information contained in this communication is confidential and may
be
legally privileged. It is intended solely for the use of the individual
or
entity to whom it is addressed and others authorised to receive it. If
you are
not the intended recipient you are hereby notified that any disclosure,
copying, distribution or taking any action in relation to the contents
of this
information is strictly prohibited and may be unlawful. Neither the
sender nor
the represented institution are liable for the correct and complete
transmission of the contents of an e-mail, or for its timely receipt.
------------------------------------------------------------------------------

--0__=WC9QRMhcXLSFkEDTFrrQ2G7LfD8umxDA03N6SsrvPiX2grGjIJ9TqpNi--

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Wed, 21 Jul 1999 Volume 1 :
Number 32

In this issue:

RE: LE370 Dumps and their usefullness

Dynam / NoDynam w/Call Identifier/Literal

Re: Implementing IDMSINTL
RE: Dynam / NoDynam w/Call Identifier/Literal
RE: Dynam / NoDynam w/Call Identifier/Literal
Re[2]: Dynam / NoDynam w/Call Identifier/Literal
RE: Dynam / NoDynam w/Call Identifier/Literal
IDMS-L / Outlook question
RE: Dynam / NoDynam w/Call Identifier/Literal
Re[2]: Dynam / NoDynam w/Call Identifier/Literal
Re: IDMS-L / Outlook question
Re: IDMS-L / Outlook question
SYSMSG
Re: RE: Dynam / NoDynam w/Call Identifier/Literal
CA-CAS on DC?
the change!
RE: CA-CAS on DC?
RE:CA-CAS on DC?
RE: Implementing IDMSINTL Getting AEIP
Re: SYSMSG
Re: Re[2]: Dynam / NoDynam w/Call Identifier/Literal

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

Date: Tue, 20 Jul 1999 14:00:59 -0000
From: Bruce Chris <chris...@hyder.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: LE370 Dumps and their usefullness
Message-ID: <0488C2686254D111A5C70000F847E8C5035D8DAA@LUSIS_EXCH_1>

Hi,

If I want to solve a dump from an LE program I just use
PARM='/TRAP(OFF)' on
the exec statement for the LE program. A "conventional" dump is written
to
sysudump. (I have worked thru an LE dump using the FM but find it easier

(old dog/new tricks syndrome) to use TRAP(OFF).)

Try SC26-4829, LE Debug Guide and Run-Time Messages.

Health warning: Various sources I've read caution the use of TRAP(OFF)
routinely as it suspends the LE environment's error trapping/handling.

Good luck. . .

CB

> ----------

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

> Sent: 19 July 1999 16:01

> To: idm...@iuassn.com
> Subject: Fwd: Fw: LE370 Dumps and their usefullness
>

> <<File: ceeuopt.txt>>

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

Date: Tue, 20 Jul 1999 09:15:21 -0400

From: Bruce_...@fmso.navy.mil
To: IDM...@IUASSN.COM
Subject: Dynam / NoDynam w/Call Identifier/Literal

Message-ID: <000D2D6...@fmso.navy.mil>

Hi All,

I'm sending this question again because I believe, from the answers
received,
that my question wasn't coherent. My question, stated in the last
paragraph,
was meant to ask - Why am I not allowed to compile a program with a
literal
using DYNAM. According to the IDMS COBOL manual it is not allowed? It
would
seem to me that even if I decide to hard code a literal, I should still
have
the flexibility of loading the module at run time. This will allow
changes to
a program that may be called by many other programs and avoid the need
to
separately re-link the changed module with all the other calling
modules.

Bruce

Here's the original question...

********************************************************************************

*****************************

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

Date: Tue, 20 Jul 1999 10:46:52 -0400

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

To: IDM...@IUASSN.COM
Subject: Re: Implementing IDMSINTL
Message-ID: <852567B4.0...@pr1lns45.cpco.com>

Hi Erik,

When we first installed IDMS 12.0 we decided to use IDMSINTL wherever
possible.
The UCFCICS module still needs to use IDMSINTC, and there are one or two
other
modules (UDAS, etc.) that need to use it. Other than this, I believe
you can
get away with using IDMSINTL every place else, as long as you're not
using the
SQL option. In order to make things easier for our programmers, we
renamed
IDMSINTC and IDMSCINT to IDMSINTX and IDMSCINX, and we renamed IDMSINTL
and
IDMSLINT to IDMSINTC and IDMSCINT. This way, the programmers didn't
have to
change the IDMSCINT literal in their CICS programs.

When we installed IDMS 14.0, we decided to use the SYSCTL parameter
instead of
SVC and CVNUM. This has worked well for us. We can now use the same
UCFCICS
modules in our test, QA, and production CICS regions. We also followed
CA's
recommendation and specified a different TPNAME for each CICS front
end. We
still have to maintain unique UCFCICS definitions for our CICS regions
that
"own" the UCF printers because we use different printer definitions
between our
test and production onlines.

We also have Omegamon/CICS, but I didn't do anything special for that
product
when I made these changes.

DISCLAIMER: The views expressed in this note are not necessarily those
of the
company.

David R. Slocum
Consumers Energy Company

E.Dij...@rf.rabobank.nl (Dijkerman E.) on 07/20/99 03:27:37 AM

Please respond to E.Dij...@rf.rabobank.nl; Please respond to
idm...@iuassn.com

To: IDM...@iuassn.com

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

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: Tue, 20 Jul 1999 10:21:12 -0500
From: Tim Gortner <TimGo...@soph.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Cc: "'Bruce_...@fmso.navy.mil'" <Bruce_...@fmso.navy.mil>
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <8D8E2D0FA8FFD111960A0060B068A8E6304D7F@DALLAS>

Bruce: Is it the pre-compiler that doesn't allow a CALL literal with
the DYNAM option?

The IBM COBOL manual explicitly states: "A dynamic call occurs when you
use the CALL literal statement in a program
that is compiled using the DYNAM compiler option, or when you use the

CALL
identifier statement."
There doesn't appear to be a restriction on using a CALL literal, vs. a
CALL identifier, other than using DYNAM with a literal. Here is the
URL of the manual section I referred to.

http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IGYPG202/4%2e1%2e2

?SHELF=IGYSH204

In addition, IBM concurs with your ease of maintenance desire:

Use a dynamic call statement when any of the following are true:

o You are concerned about ease of maintenance. Applications do not

have
to be link-edited again when dynamically called subprograms are
changed.

Tim Gortner
Sophisticated Business Systems Inc.
303.300.3577 x111
TimGo...@soph.com

-----Original Message-----
From: Bruce_...@fmso.navy.mil [mailto:Bruce_...@fmso.navy.mil]
Sent: Tuesday, July 20, 1999 7:15 AM
To: IDM...@IUASSN.COM
Subject: Dynam / NoDynam w/Call Identifier/Literal

Hi All,

I'm sending this question again because I believe, from the answers
received,
that my question wasn't coherent. My question, stated in the last
paragraph,
was meant to ask - Why am I not allowed to compile a program with a
literal
using DYNAM. According to the IDMS COBOL manual it is not allowed? It
would
seem to me that even if I decide to hard code a literal, I should still
have
the flexibility of loading the module at run time. This will allow
changes to
a program that may be called by many other programs and avoid the need
to
separately re-link the changed module with all the other calling
modules.

Bruce

Here's the original question...

be
against the rules.

************************************************************************

********
*****************************

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

Date: Tue, 20 Jul 1999 11:30:20 -0400
From: Bruce_...@fmso.navy.mil (Bruce S Swist/FMSO/NAVSUP)
To: Tim Gortner <TimGo...@soph.com>
Cc: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <001E849...@navsup.navy.mil>

--IMA.Boundary.0864842390
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

OK -

I do understand that IBM allows it. My question is - why is
it stated in the IDMS manual that it is not allowed. (See
below for my original message) Well, that's my interpretation
anyway.

Thanks,
Bruce

From: Tim Gortner <TimGo...@soph.com> AT internet-emh2 on
07/20/99 10:21 AM

To: "'idm...@iuassn.com'" <idm...@iuassn.com> AT
internet-emh2@ccnavsup
cc: Bruce S Swist/FMSO/NAVSUP
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal

--IMA.Boundary.0864842390
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

Bruce: Is it the pre-compiler that doesn't allow a CALL
literal with the DYNAM option?

The IBM COBOL manual explicitly states: "A dynamic call occurs
when you
use the CALL literal statement in a program
that is compiled using the DYNAM compiler option, or when
you use the
CALL
identifier statement."
There doesn't appear to be a restriction on using a CALL
literal, vs. a CALL identifier, other than using DYNAM with a
literal. Here is the URL of the manual section I referred to.

http:
//www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IGYPG202/4%2e1
%2e2
?SHELF=IGYSH204

In addition, IBM concurs with your ease of maintenance desire:

Use a dynamic call statement when any of the following are
true:

o You are concerned about ease of maintenance.
Applications do not
have
to be link-edited again when dynamically called
subprograms are changed.

Tim Gortner
Sophisticated Business Systems Inc.
303.300.3577 x111
TimGo...@soph.com

-----Original Message-----
From: Bruce_...@fmso.navy.mil
[mailto:Bruce_...@fmso.navy.mil]
Sent: Tuesday, July 20, 1999 7:15 AM
To: IDM...@IUASSN.COM
Subject: Dynam / NoDynam w/Call Identifier/Literal

Hi All,

I'm sending this question again because I believe, from the
answers
received,
that my question wasn't coherent. My question, stated in the
last
paragraph,
was meant to ask - Why am I not allowed to compile a program
with a
literal
using DYNAM. According to the IDMS COBOL manual it is not
allowed? It
would
seem to me that even if I decide to hard code a literal, I
should still
have
the flexibility of loading the module at run time. This will
allow
changes to
a program that may be called by many other programs and avoid
the need
to
separately re-link the changed module with all the other
calling modules.

Bruce

Here's the original question...

--IMA.Boundary.0864842390--

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

Date: Tue, 20 Jul 1999 12:09 -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: <199907201110...@alltel.com>

I don't have the definitive answer, but here's some ideas...

DML verbs in your program expand to CALL 'IDMSCOBI' statements.
Compiling with
DYNAM would make these dynamic calls. Maybe calls to the interface must
be
static?

Another possibility is that there may be some subtle difference between
the two
types of dynamic calls. Possibly IDMS can trap the CALL identifier and
load the
program using IDMS conventions, but cannot trap a DYNAM CALL literal.

Note that this has nothing to do with the precompiler, it has no idea
nor does
it care what cobol compile options you intend to use. It is purely a run
time
thing. I'm not sure about 12.0 - but 14.0 won't even load a COBOL
program
compiled with DYNAM.

One final note - IBM place the same restriction on CICS COBOL programs.
So
whatever the reason, I suspect that it's a good one.

Steve Franzon

______________________________ Reply Separator
_________________________________
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
Author: idm...@iuassn.com at internet
Date: 07/20/1999 10:30 AM

OK -

I do understand that IBM allows it. My question is - why is
it stated in the IDMS manual that it is not allowed. (See
below for my original message) Well, that's my interpretation
anyway.

Thanks,
Bruce

From: Tim Gortner <TimGo...@soph.com> AT internet-emh2 on
07/20/99 10:21 AM

To: "'idm...@iuassn.com'" <idm...@iuassn.com> AT
internet-emh2@ccnavsup
cc: Bruce S Swist/FMSO/NAVSUP
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal

Bruce: Is it the pre-compiler that doesn't allow a CALL
literal with the DYNAM option?

The IBM COBOL manual explicitly states: "A dynamic call occurs
when you
use the CALL literal statement in a program
that is compiled using the DYNAM compiler option, or when
you use the
CALL
identifier statement."
There doesn't appear to be a restriction on using a CALL
literal, vs. a CALL identifier, other than using DYNAM with a
literal. Here is the URL of the manual section I referred to.

http:
//www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IGYPG202/4%2e1
%2e2
?SHELF=IGYSH204

In addition, IBM concurs with your ease of maintenance desire:

Use a dynamic call statement when any of the following are
true:

o You are concerned about ease of maintenance.
Applications do not
have
to be link-edited again when dynamically called
subprograms are changed.

Tim Gortner
Sophisticated Business Systems Inc.
303.300.3577 x111
TimGo...@soph.com

-----Original Message-----
From: Bruce_...@fmso.navy.mil
[mailto:Bruce_...@fmso.navy.mil]
Sent: Tuesday, July 20, 1999 7:15 AM
To: IDM...@IUASSN.COM
Subject: Dynam / NoDynam w/Call Identifier/Literal

Hi All,

I'm sending this question again because I believe, from the
answers
received,
that my question wasn't coherent. My question, stated in the
last
paragraph,
was meant to ask - Why am I not allowed to compile a program
with a
literal
using DYNAM. According to the IDMS COBOL manual it is not
allowed? It
would
seem to me that even if I decide to hard code a literal, I
should still
have
the flexibility of loading the module at run time. This will
allow
changes to
a program that may be called by many other programs and avoid
the need
to
separately re-link the changed module with all the other
calling modules.

Bruce

Here's the original question...

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

Date: Tue, 20 Jul 1999 11:17:57 -0500
From: Tim Gortner <TimGo...@soph.com>
To: "'Bruce_...@fmso.navy.mil'" <Bruce_...@fmso.navy.mil>
Cc: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <8D8E2D0FA8FFD111960A0060B068A8E6304D81@DALLAS>

Bruce:

The IDMS manual states 2 things: 1) that it's not allowed in an online
environment; and 2) That it's not allowed at all (without any
explanation), however Steve Franzons comment about that expanded
IDMSCOBI calls makes the most sense of all:

1) The following COBOL features are not used in programs running in an
online
environment under CA-IDMS:

=04=A0=A0 The COBOL compiler DEBUG option; the COUNT, FLOW, STATE, =
ENDJOB,
TEST,
=A0=A0=A0 RESIDENT, DYNAM, and SYMDMP commands (OS only); or the COUNT,
=
FLOW,
=A0=A0=A0 STATE, STXIT, and SYMDMP commands (VSE only)

These features lead to a supervisor call (SVC), which will inhibit
system
performance and can also crash the DC system.

2) H.3 Features not supported by CA-IDMS
=A0
The following COBOL II features are not supported by CA-IDMS:
=A0
=04=A0=A0 ENVIRONMENT and DATA DIVISION entries normally associated=A0 =

with file
=A0=A0=A0 management (for example, INPUT-OUTPUT SECTION, FILE SECTION)
=A0
=04=A0=A0 I/O statements, including ACCEPT, CLOSE, DELETE, DISPLAY, =
OPEN,
READ,
=A0=A0=A0 REWRITE, and WRITE
=A0
=04=A0=A0 The debugging features FDUMP and TEST
=A0
=04=A0=A0 The sorting features SORT and MERGE
=A0
=04=A0=A0 The compiler options ADV, DYNAM, FASTSRT, GRAPHIC, and OUTDD

Tim Gortner=20
Sophisticated Business Systems Inc.=20
303.300.3577 x111=20
TimGo...@soph.com=20

=A0

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

Date: Tue, 20 Jul 1999 11:23:47 -0500
From: Kay Rozeboom <Kay.Ro...@its.state.ia.us>
To: idm...@iuassn.com
Subject: IDMS-L / Outlook question
Message-ID:
<78DA1160F5BDD111BCC...@its-cn-exchange.its.state.ia.us>

This is a list question, rather than an IDMS question. I receive my
e-mail through Microsoft Outlook, and I would like for the IDMS-L
messages to go to a special folder other than the default in-box. I set

up a special folder called IDMS-L (how original) and directed mail to
and from idm...@iuassn.com to the new folder. But all list messages
continue to go to the default in-box. Can anybody tell me what I am
doing wrong?

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

Date: Tue, 20 Jul 1999 12:36:07 -0400
From: Bruce_...@fmso.navy.mil (Bruce S Swist/FMSO/NAVSUP)
To: Tim Gortner <TimGo...@soph.com>
Cc: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <001E893...@navsup.navy.mil>

--IMA.Boundary.1368842390
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

Tom,

But I believe the exerpts are restrictions when running DC
programs in CV because of the SVC calls. I am interested why
the DYNAM restriction exists on CALL "literals" in batch
programs.

Thanks,
Bruce

From: Tim Gortner <TimGo...@soph.com> AT internet-emh2 on
07/20/99 11:17 AM

To: Bruce S Swist/FMSO/NAVSUP
cc: "'idm...@iuassn.com'" <idm...@iuassn.com> AT
internet-emh2@ccnavsup
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal

--IMA.Boundary.1368842390
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Description: cc:Mail note part

Bruce:

The IDMS manual states 2 things: 1) that it's not allowed in an
online environment; and 2) That it's not allowed at all
(without any explanation), however Steve Franzons comment about
that expanded IDMSCOBI calls makes the most sense of all:

1) The following COBOL features are not used in programs
running in an
online
environment under CA-IDMS:

=04=A0=A0 The COBOL compiler DEBUG option; the COUNT, FLOW,
STATE,=

ENDJOB,
TEST,
RESIDENT, DYNAM, and SYMDMP commands (OS only); or the
COUNT, FLOW, STATE, STXIT, and SYMDMP commands (VSE only)

These features lead to a supervisor call (SVC), which will
inhibit
system
performance and can also crash the DC system.

2) H.3 Features not supported by CA-IDMS

The following COBOL II features are not supported by CA-IDMS:

=04=A0=A0 ENVIRONMENT and DATA DIVISION entries normally
associate=
d
with file
management (for example, INPUT-OUTPUT SECTION, FILE
SECTION)

=04=A0=A0 I/O statements, including ACCEPT, CLOSE, DELETE,
DISPLAY=
,
OPEN,
READ,
REWRITE, and WRITE

=04=A0=A0 The debugging features FDUMP and TEST

=04=A0=A0 The sorting features SORT and MERGE

=04=A0=A0 The compiler options ADV, DYNAM, FASTSRT, GRAPHIC, and
OUTDD

Tim Gortner
Sophisticated Business Systems Inc.
303.300.3577 x111
TimGo...@soph.com

--IMA.Boundary.1368842390--

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

Date: Tue, 20 Jul 1999 12:53 -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: <1999072011533...@alltel.com>

Bruce, same goes for the DYNAM restriction - it applies only to
online=
=20
DC programs. There is NO restriction on the use of DYNAM in batch.
We=
=20
compile most of our batch programs DYNAM and don't have any
problems.
=20
Steve Franzon

______________________________ Reply Separator
____________________________=
_____
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
Author: idm...@iuassn.com at internet
Date: 07/20/1999 11:36 AM

Tom,
=20
But I believe the exerpts are restrictions when running DC=20
programs in CV because of the SVC calls. I am interested why=20
the DYNAM restriction exists on CALL "literals" in batch=20
programs.
=20
Thanks,
Bruce
=20
=20
=20
=20
From: Tim Gortner <TimGo...@soph.com> AT internet-emh2 on
07/20/99 11:17 AM
=20
To: Bruce S Swist/FMSO/NAVSUP
cc: "'idm...@iuassn.com'" <idm...@iuassn.com> AT
internet-emh2@ccnavsup
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
=20
=20
=20
Bruce:
=20
The IDMS manual states 2 things: 1) that it's not allowed in
an=20
online environment; and 2) That it's not allowed at all=20
(without any explanation), however Steve Franzons comment
about=20
that expanded IDMSCOBI calls makes the most sense of all:
=20
1) The following COBOL features are not used in programs=20
running in an
online
environment under CA-IDMS:
=20
=04=E1=E1 The COBOL compiler DEBUG option; the COUNT, FLOW,
STATE,=
=20
ENDJOB,
TEST,
RESIDENT, DYNAM, and SYMDMP commands (OS only); or the=20
COUNT, FLOW, STATE, STXIT, and SYMDMP commands (VSE only)
=20
These features lead to a supervisor call (SVC), which will=20
inhibit
system
performance and can also crash the DC system.
=20
2) H.3 Features not supported by CA-IDMS
=20
The following COBOL II features are not supported by CA-IDMS:
=20
=04=E1=E1 ENVIRONMENT and DATA DIVISION entries normally
associated
with file
management (for example, INPUT-OUTPUT SECTION, FILE=20
SECTION)
=20
=04=E1=E1 I/O statements, including ACCEPT, CLOSE, DELETE,
DISPLAY,=
=20
OPEN,
READ,
REWRITE, and WRITE
=20
=04=E1=E1 The debugging features FDUMP and TEST
=20
=04=E1=E1 The sorting features SORT and MERGE
=20
=04=E1=E1 The compiler options ADV, DYNAM, FASTSRT, GRAPHIC,
and=20
OUTDD
=20
=20
Tim Gortner
Sophisticated Business Systems Inc.
303.300.3577 x111
TimGo...@soph.com

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

Date: Tue, 20 Jul 1999 12:52:56 -0400
From: "Hugh Laderman" <hu...@laderman.com>
To: <idm...@iuassn.com>
Subject: Re: IDMS-L / Outlook question
Message-ID: <000d01bed2d0$51eefd40$3ed07ad1@oemcomputer>

Kay

That should work (as I have the same original name for my IDMS-L
mailbox),
but you probably want to add when cc: is also.

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

-----Original Message-----
From: Kay Rozeboom <Kay.Ro...@its.state.ia.us>

To: idm...@iuassn.com <idm...@iuassn.com>
Date: Tuesday, July 20, 1999 12:31 PM
Subject: IDMS-L / Outlook question

>This is a list question, rather than an IDMS question. I receive my
>e-mail through Microsoft Outlook, and I would like for the IDMS-L
>messages to go to a special folder other than the default in-box. I
set
>up a special folder called IDMS-L (how original) and directed mail to
>and from idm...@iuassn.com to the new folder. But all list messages
>continue to go to the default in-box. Can anybody tell me what I am
>doing wrong?
>

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

Date: Tue, 20 Jul 1999 12:56:32 -0400
From: "Al A Shuryan" <shur...@meritorauto.com>
To: idm...@iuassn.com
Subject: Re: IDMS-L / Outlook question
Message-ID: <852567B4.0...@amerhub.meritorauto.com>

It's nothing wrong on your end. Because the FROM and SENDER are always
different
you can't set the smart send to folder rule up with this newgroup any
more in
OUTLOOK the way we used to. If one of them were always the same it would
work
wonderfully, like before. I know how you have it. I too had it that way.
ALL
IDMS-L mail would go to one single email folder and read at our
convienence and
not intermingle with all the other mail. The newest Beta version of
Outlook has
more powerful Rules wizards the solution might be in there.

PS. BTW be careful using OUTLOOK for IDMS-L the TO: can be hidden (since
it's
usually not applicable) and only the SENDER and FROM is visable.
you don't realize it's from the group until you Reply and only then see
the TO:
, You may unknowingly email the whole group. That was part of the first
few days
problems with the IDMS-l and accidental replies that escalated to all
the policy
problems.

Al S.

Kay Rozeboom <Kay.Ro...@its.state.ia.us> on 07/20/99 12:23:47 PM

Please respond to idm...@iuassn.com

To: idm...@iuassn.com

cc: (bcc: Al A Shuryan/Amer/Auto)

Subject: IDMS-L / Outlook question

This is a list question, rather than an IDMS question. I receive my
e-mail through Microsoft Outlook, and I would like for the IDMS-L
messages to go to a special folder other than the default in-box. I set

up a special folder called IDMS-L (how original) and directed mail to
and from idm...@iuassn.com to the new folder. But all list messages
continue to go to the default in-box. Can anybody tell me what I am
doing wrong?

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

Date: Tue, 20 Jul 1999 14:29:00 -0500
From: "Scott, Mika F." <mika....@mail.va.gov>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: SYSMSG
Message-ID: <5D88BE4FFA43D211BB1...@mail.va.gov>

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: Tue, 20 Jul 1999 15:26:46 -0400

From: "Mark CONS:Caffrey" <DBA...@mbusa.com>
To: Bruce_...@fmso.navy.mil, Idm...@iuassn.com

Subject: Re: RE: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <s79495...@mbusa.com>

Bruce,
I am using, extensively, CALL literal with DYNAM in IDMS Batch programs
=
without any problems. The restriction is only for DC programs. To
clarify =
further, I am VS/COBOL with IDMS rel 12.1. I do not know if there are =
implications with COBOL II or not.
Mark

>>> Bruce S Swist/FMSO/NAVSUP <Bruce_...@fmso.navy.mil> 07/20 12:36
PM =
>>>

Tom,

But I believe the exerpts are restrictions when running DC
programs in CV because of the SVC calls. I am interested why
the DYNAM restriction exists on CALL "literals" in batch
programs.

Thanks,
Bruce

From: Tim Gortner <TimGo...@soph.com> AT internet-emh2 on
07/20/99 11:17 AM

To: Bruce S Swist/FMSO/NAVSUP
cc: "'idm...@iuassn.com'" <idm...@iuassn.com> AT
internet-emh2@ccnavsup=20
Subject: RE: Dynam / NoDynam w/Call Identifier/Literal

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

Date: Thu, 8 Jul 1999 10:54:14 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: CA-CAS on DC?
Message-ID: <852567A8.0...@d54mta03.raleigh.ibm.com>

My employer has a question - is ANY release of CA-CAS available in the
bookmanager format on CD? thanks

Chris Hoelscher

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

Date: Thu, 8 Jul 1999 10:12:31 -0400
From: hoel...@us.ibm.com
To: idm...@iuassn.com
Subject: the change!
Message-ID: <852567A8.0...@d54mta03.raleigh.ibm.com>

forgivr me if this the third message from me with this subject - I never
got the
emails from the list so you may not have either - effective today - all
replies
to list-distributed messages will be directed, BY DEFAULT, back to the
list. IF
a reply is more appropriately addressed to an individual, please do so!

thank you,
Becky Robinson
Chris Hoelscher

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

Date: Tue, 20 Jul 1999 13:54:15 -0700
From: "Johnson, Sara" <Sara.J...@hexcel.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: CA-CAS on DC?
Message-ID:
<2BCA09803339D211AE04...@unknown-68-47.hexcel.com>

Chris, CAS Release 3.0 is available on CD but in Internet Browser
format. As
far as I know, there is no Bookmanager format available for CAS as there
is
for the IDMS documentation.

Sara Johnson

-----Original Message-----
From: hoel...@us.ibm.com [mailto:hoel...@us.ibm.com]
Sent: Thursday, July 08, 1999 7:54 AM
To: idm...@iuassn.com
Subject: CA-CAS on DC?

My employer has a question - is ANY release of CA-CAS
available in the
bookmanager format on CD? thanks

Chris Hoelscher

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

Date: Tue, 20 Jul 1999 15:59:00 -0500
From: al.ho...@bat.AgcoCorp.Com
To: idm...@iuassn.com
Subject: RE:CA-CAS on DC?
Message-ID: <NZ74fa73...@bat.AgcoCorp.Com>

If only CA would do that. It would be very helpful for debugging user
problems.

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

Date: Tue, 20 Jul 1999 16:10:46 -0500
From: "Walters, NR Neal (8377)" <Walt...@gvl.esys.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Cc: "'E.Dij...@rf.rabobank.nl'" <E.Dij...@rf.rabobank.nl>
Subject: RE: Implementing IDMSINTL Getting AEIP
Message-ID:
<9D198A0A726AD211BD1...@gvlmail1.gvl.esys.com>

I spent a couple of weeks trying to get IDMSINTL working. We are
running
IDMS 14.0 at 9711, with CICS 4.1 with storage protect, and are getting
AEIP
abend (see explanation of error below ). All programs running with
IDMSINTC run fine with storage protect on. I've had a problem open with
CA
on this since May 13th. Apparently it's confusing them too. It went to

Level-2, Michael Mickelson. We also use VDB from Allen Systems Group,
but
have disabled that until we get the AEIP resolved in an isolated
environment. With storage protect OFF, then IDMSINTL seems to run
fine.

I had written an itsy-bitsy CICS/COBOL/IDMS program that simply Binds a
Run
Unit, Binds a Record, Readies an Area, and retrieves the OOAK-012 record

from the DDLDML dictionary area, does some CICS displays along the way,
then
does the IDMS Finish. Same program with IDMSINTC works fine.

Mic sent me an assembler CICS program to try, rather than the COBOL that
I
was using, hoping that perhaps this was an LE370 related error, but
still
getting the AEIP in assembler.

Also, from when we have major problems with IDMS, CICS starts displaying

"under stress" messages, and often abends with S0C4 (if I recall). It
can't
seem to keep up with all the abends in rapid succession. CA suggested
that
IDMSINTL might solve this problem.

According to QuickRef, AEIP means:

CICS ABEND : AEIP

Explanation: A command level CICS application program encountered an

error, but no EXEC CICS HANDLE CONDITION had been
previously

issued, nor had the RESP or NOHANDLE options been chosen

either. The INVREQ error condition was raised, causing
this

abend.

User Action: To prevent this abend in the future, the application
program

should be changed to handle this type of error with the
EXEC

CICS HANDLE CONDITION command or the RESP option. The
EXEC

Interface Block (EIB) has the error return code in it in

fields EIBRCODE, EIBRESP, and EIBRESP2, and these fields
can

be checked by the application program and appropriate
action

taken.

The EIB is addressable by finding the EXEC Interface
Storage

(EIS) pointed to be the TCA+X'7C' and scanning for the

string 'DFHEIB' that appears immediately prior to the
EIB.

Neal Walters
Sophisticated Business Systems (Dallas)
at Raytheon E-Systems for Dept. of Education

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

Date: Tue, 20 Jul 1999 17:18:23 -0400

From: "Mark CONS:Caffrey" <DBA...@mbusa.com>

To: Idm...@iuassn.com, mika....@mail.va.gov
Subject: Re: SYSMSG
Message-ID: <s794af...@mbusa.com>

Mika,
I have looked at 2 different message areas that I have in 2 different
CVs. =
It appears if the severity level of the message is 1, or maybe even =
greater, then the message will print to the JES log. That is the only =
difference I can see between the 2 message definitions. The one with the
=
severity of 1 prints to the JES log, and the one with severity 0 does
not, =
as far as I can see.=20

It's something to check and test out, anyway.
Mark=20

>>> "Scott, Mika F." <mika....@mail.va.gov> 07/20 3:29 PM >>>
I am a newbee to the group (and to IDMS), so if I make any "procedural"
mistakes, please forgive.

My question: =20

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: Wed, 21 Jul 1999 10:20:56 +0300
From: "Onni Kukkonen" <Onni.K...@vegasoft.com>
To: <idm...@iuassn.com>
Subject: Re: Re[2]: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <04c301bed349$a86de400$6608e2d4@Yvegas-2>

This is a multi-part message in MIME format.

------=_NextPart_000_04C0_01BED362.B87CE080
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

From: Steve Franzon <Steve....@alltel.com>
To: idm...@iuassn.com <idm...@iuassn.com>
Date: 20. hein=E4kuuta 1999 19:11
Subject: Re[2]: Dynam / NoDynam w/Call Identifier/Literal

>I don't have the definitive answer, but here's some ideas...
>
>DML verbs in your program expand to CALL 'IDMSCOBI' statements. =
Compiling with=20
>DYNAM would make these dynamic calls. Maybe calls to the interface must
=
be=20
>static?
>

Steve

You can have a DC COBOL II program without any CALL 'IDMSCOBI' calls. =

Therefore this does not apply.

>Another possibility is that there may be some subtle difference between
=
the two=20
>types of dynamic calls. Possibly IDMS can trap the CALL identifier and
=
load the=20
>program using IDMS conventions, but cannot trap a DYNAM CALL literal.

Attached is the expanded code for the two types of calls compiled with =

DYNAM option. IGZCLNK is called in both calls to load&execute the
subprogram. Because both types generate basically the same code, this =
does not explain the restriction with call 'literal' & DYNAM.

*********************************************************
* CALL WITH IDENTIFIER =20
*********************************************************
CALL PGM. =20
29A D207 D150 9000 MVC 336(8,13),0(9) TS2=3D0
=
=20
2A0 DC07 D150 A024 TR 336(8,13),36(10) TS2=3D0
=
=20
2A6 5820 D05C L 2,92(0,13) TGTFIXD+92
=
=20
2AA 58F0 205C L 15,92(0,2) V(IGZCLNK )
=
=20
2AE 4110 A166 LA 1,358(0,10) PGMLIT AT =
+354=20
2B2 05EF BALR 14,15
=
=20
2B4 BF38 D089 ICM 3,8,137(13) TGTFIXD+137
=
=20
2B8 0430 SPM 3,0
=
=20
*********************************************************
* CALL WITH LITERAL =20
*********************************************************
CALL 'PGM'. =20
2BA 58F0 205C L 15,92(0,2) V(IGZCLNK )
=
=20
2BE 4110 A157 LA 1,343(0,10) PGMLIT AT =
+339=20
2C2 05EF BALR 14,15
=
=20
2C4 BF38 D089 ICM 3,8,137(13) TGTFIXD+137
=
=20
2C8 0430 SPM 3,0
=
=20

Maybe the difference is in the program initialization phase?

Onni Kukkonen
Vegasoft
Onni.K...@vegasoft.com
-----Original Message-----

From: Steve Franzon <Steve....@alltel.com>
To: idm...@iuassn.com <idm...@iuassn.com>
Date: 20. hein=E4kuuta 1999 19:11
Subject: Re[2]: Dynam / NoDynam w/Call Identifier/Literal
>Note that this has nothing to do with the precompiler, it has no idea =

nor does=20
>it care what cobol compile options you intend to use. It is purely a =
run time=20
>thing. I'm not sure about 12.0 - but 14.0 won't even load a COBOL =
program=20
>compiled with DYNAM.
>
>One final note - IBM place the same restriction on CICS COBOL programs.
=
So=20
>whatever the reason, I suspect that it's a good one.
>
>Steve Franzon=20
>
>______________________________ Reply Separator =
_________________________________
>Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
>Author: idm...@iuassn.com at internet
>Date: 07/20/1999 10:30 AM
>
>
> OK -
> =20
> I do understand that IBM allows it. My question is - why is=20

> it stated in the IDMS manual that it is not allowed. (See=20
> below for my original message) Well, that's my
interpretation=20
> anyway.
> =20
> Thanks,
> Bruce
> =20
> =20
> =20
> =20
> From: Tim Gortner <TimGo...@soph.com> AT internet-emh2 on
> 07/20/99 10:21 AM
> =20
> To: "'idm...@iuassn.com'" <idm...@iuassn.com> AT
> internet-emh2@ccnavsup
> cc: Bruce S Swist/FMSO/NAVSUP
> Subject: RE: Dynam / NoDynam w/Call Identifier/Literal
> =20
> =20
> =20
> Bruce: Is it the pre-compiler that doesn't allow a CALL=20
> literal with the DYNAM option?
> =20
> The IBM COBOL manual explicitly states: "A dynamic call
occurs=20
> when you
> use the CALL literal statement in a program
> that is compiled using the DYNAM compiler option, or when
> you use the
> CALL
> identifier statement."
> There doesn't appear to be a restriction on using a CALL=20
> literal, vs. a CALL identifier, other than using DYNAM with a=20

> literal. Here is the URL of the manual section I referred to.
> =20
> http:
>
//www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IGYPG202/4%2e1=20
> %2e2
> ?SHELF=3DIGYSH204
> =20
> In addition, IBM concurs with your ease of maintenance desire:
> =20
> Use a dynamic call statement when any of the following are=20
> true:
> =20
> o You are concerned about ease of maintenance.
> Applications do not
> have
> to be link-edited again when dynamically called=20
> subprograms are changed.
> =20
> Tim Gortner
> Sophisticated Business Systems Inc.
> 303.300.3577 x111
> TimGo...@soph.com
> =20

> -----Original Message-----
> From: Bruce_...@fmso.navy.mil
> [mailto:Bruce_...@fmso.navy.mil]=20
> Sent: Tuesday, July 20, 1999 7:15 AM=20
> To: IDM...@IUASSN.COM
> Subject: Dynam / NoDynam w/Call Identifier/Literal

> =20
> =20
> Hi All,
> =20
> I'm sending this question again because I believe, from the=20
> answers
> received,
> that my question wasn't coherent. My question, stated in the=20

> last
> paragraph,
> was meant to ask - Why am I not allowed to compile a program=20
> with a
> literal
> using DYNAM. According to the IDMS COBOL manual it is not=20
> allowed? It
> would
> seem to me that even if I decide to hard code a literal, I=20
> should still
> have
> the flexibility of loading the module at run time. This will=20

> allow
> changes to
> a program that may be called by many other programs and avoid=20

> the need
> to
> separately re-link the changed module with all the other=20
> calling modules.
> =20
> Bruce
> =20
> =20
> =20
> Here's the original question...
> =20

> All DC programs here use "CALL literal" and the NODYNAM parm.
> It would
> be

> beneficial for us to use DYNAM in our DC environment but it=20

> does seem to
> be
> against the rules.

> =20
> =20
> The R12.1 and R14 COBOL manual (CD) contains a description=20

> (found below)
> for
> use of DYNAM/NODYNAM in calling other COBOL programs.

> =20
>
***************************************************************=20
> *********
> ********

> ******************************
> Static and dynamic calls -- CA-IDMS supports the following
> types of calls provided by VS COBOL II:
> =20

> - CALL literal with NODYNAM, static (more storage, less=20

> CPU)
> =20
> - CALL identifier, dynamic (less storage, more CPU)
> =20
> To call a program dynamically you must use the call
> identifier format.
> =20
> A VS COBOL II program can use the COBOL CALL verb to

invoke=20

> an assembler or COBOL II subprogram. The CA-IDMS

TRANSFER=20
> CONTROL
> (LINK
> or XCTL) must be used for invoking VS COBOL subprograms.=20
> The subprogram must be defined to the system either at=20

> SYSGEN or by
> using
> a DCMT VARY DYNAMIC PROGRAM command. The correct

language=20
> must be specified, and the NONOVERLAYABLE attribute must=20

> also be specified.
> =20
> A COBOL II program and all the COBOL II subprograms that

it=20

> calls dynamically must be compiled with the same

RES/NORES=20
> compiler
> option.
>
***************************************************************=20
> *********
> ********
> *****************************
> =20
> =20

> So, could anyone explain why DYNAM can be used with a

variable=20
> (identifier) as
> the program name but not the plain old everyday hard-coded=20
> literal? Is
> it just
> a pre-compiler/compiler thing, that it was coded that way=20

> (which I
> doubt) or is
> it some internal aspect that has escaped me.

> =20

> Your help is appreciated,
> Take Care,
> Bruce

------=_NextPart_000_04C0_01BED362.B87CE080

Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
From: Steve Franzon <Steve....@alltel.com>=
To:=20 idm...@iuassn.com <idm...@iuassn.com>
Date: 20. = heinäkuuta 1999 19:11
Subject: Re[2]: Dynam / NoDynam w/Call=20 Identifier/Literal

>I don't have the definitive answer, but here's some=20 ideas...
>
>DML verbs in your program expand to CALL = 'IDMSCOBI'=20 statements.
Compiling with
>DYNAM would make these dynamic calls. = Maybe=20 calls to the interface
must be
>static?
>
Steve

You can have a DC COBOL II program without any CALL = 'IDMSCOBI'
calls.=20 Therefore this does not apply.

>Another possibility is that there may be some subtle difference =
between=20 the two
>types of dynamic calls. Possibly IDMS can trap the CALL=20 identifier
and load the
>program using IDMS conventions, but = cannot trap=20 a DYNAM CALL
literal.

Attached is the expanded code for the two types of calls compiled =
with=20 DYNAM option. IGZCLNK is called in both calls to load&execute =
the
subprogram. Because both types generate basically the same code, = this
does=20 not explain the restriction with call 'literal' & DYNAM.

*********************************************************<= BR>* =20
CALL WITH=20 IDENTIFIER &nb=
sp; &nbs=
p; =20
*********************************************************
&n=
bsp; =20 CALL=20 PGM. &nb=
sp; =20
29A D207 D150=20 9000 MVC =20 336(8,13),0(9) =20
TS2=3D0 =
2A0 =20 DC07 D150 A024 =20 TR = 336(8,13),36(10) =20
TS2=3D0 =
2A6 =20 5820=20 D05C &nb=
sp; =20 L =20 2,92(0,13) &nb=
sp; =20 TGTFIXD+92
2AA 58F0=20 205C &nb=
sp; =20 L =20 15,92(0,2) &nb=
sp; =20 V(IGZCLNK )
2AE 4110=20 A166 &nb=
sp; =20 LA =20 1,358(0,10) &n=
bsp; =20 PGMLIT AT +354
2B2 =20 05EF &nb=
sp; =20 BALR=20 14,15 &n=
bsp; &nb=
sp; =20
2B4 BF38=20 D089 &nb=
sp; =20 ICM =20 3,8,137(13) &n=
bsp; =20 TGTFIXD+137
2B8 =20 0430 &nb=
sp; =20 SPM =20 3,0 &nbs=
p; &nbsp=
; =20
*********************************************************
* &=
nbsp; =20 CALL WITH=20 LITERAL = &=
nbsp; =20
*********************************************************
&n=
bsp; =20 CALL=20 'PGM'. &=
nbsp; &n=
bsp; &nb=
sp; =20
2BA 58F0=20 205C &nb=
sp; =20 L =20 15,92(0,2) &nb=
sp; =20 V(IGZCLNK )
2BE 4110=20 A157 &nb=
sp; =20 LA =20 1,343(0,10) &n=
bsp; =20 PGMLIT AT +339
2C2 =20 05EF &nb=
sp; =20 BALR=20 14,15 &n=
bsp; &nb=
sp; =20
2C4 BF38=20 D089 &nb=
sp; =20 ICM =20 3,8,137(13) &n=
bsp; =20 TGTFIXD+137
2C8 =20 0430 &nb=
sp; =20 SPM =20 3,0 &nbs=
p; &nbsp=
; =20
Maybe the difference is in the program initialization = phase?

Onni Kukkonen
Vegasoft
Onni.K...@vegasoft.com=
-----Original=20 Message-----

From: Steve Franzon <Steve....@alltel.com>=
To:=20 idm...@iuassn.com <idm...@iuassn.com>
Date: 20. = heinäkuuta 1999 19:11
Subject: Re[2]: Dynam / NoDynam w/Call=20 Identifier/Literal
>Note that this has nothing to do with the = precompiler,=20 it has no
idea nor does
>it care what cobol compile options you = intend to=20 use. It is purely
a run time
>thing. I'm not sure about 12.0 - = but 14.0=20 won't even load a COBOL
program
>compiled with = DYNAM.
>
>One=20 final note - IBM place the same restriction on CICS COBOL
programs. So=20
>whatever the reason, I suspect that it's a good=20 one.
>
>Steve Franzon =
>
>______________________________=20 Reply Separator
_________________________________
>Subject: RE: = Dynam /=20 NoDynam w/Call Identifier/Literal
>Author: idm...@iuassn.com at=20 internet
>Date: 07/20/1999 10:30=20 AM
>
>
> OK=20 -
> =
> I=20 do understand that IBM allows it. My question is - why
is=20
> it stated in the IDMS = manual that=20 it is not allowed. (See
=
> below=20 for my original message) Well, that's my
interpretation=20
> =20 anyway.
> =20
> =20 Thanks,
> =20 Bruce
>
> =20
>
> =20
> From: Tim Gortner <TimGo...@soph.com> AT = internet-emh2=20 on

> &nb=
sp; =20 07/20/99 10:21 AM
> =20
> To: "'idm...@iuassn.com'" <idm...@iuassn.com>=20 AT
> &nb=
sp; =20 internet-emh2@ccnavsup
> =20 cc: Bruce S=20 Swist/FMSO/NAVSUP
> = Subject: RE:=20 Dynam / NoDynam w/Call = Identifier/Literal
> =20
>
> =20
> Bruce: Is it the = pre-compiler=20 that doesn't allow a CALL
> = literal=20 with the DYNAM option?
> =20
> The IBM COBOL manual = explicitly=20 states: "A dynamic call
occurs =
> =20 when you
> use the CALL = literal=20 statement in a=20 program
> = that is=20 compiled using the DYNAM compiler option, or=20
when
> you use=20 the
> =20 CALL
> = identifier=20 statement."
> There = doesn't=20 appear to be a restriction on using a CALL=20

> literal, vs. a CALL = identifier,=20 other than using DYNAM with
a =
> =20 literal. Here is the URL of the manual section I
referred=20 to.
> =
> =20 http:
> //> =20 %2e2
> =20 ?SHELF=3DIGYSH204
> =20
> In addition, IBM concurs = with your=20 ease of maintenance
desire:
> =20
> Use a dynamic call = statement when=20 any of the following are
> =20 true:
> =20
> = o You=20 are concerned about ease of=20 maintenance.
> Applications do = not
> =20 have
> &=
nbsp; =20 to be link-edited again when dynamically called=20
> &nbsp=
; =20 subprograms are changed.
> =20
> Tim=20 Gortner
> Sophisticated = Business=20 Systems Inc.
> 303.300.3577=20 x111
> TimGo...@soph.com
> = =20
> -----Original=20 Message-----
> From: Bruce_...@fmso.navy.mil
> =20 [mailto:Bruce_...@fmso.nav= y.mil]=20
> Sent: Tuesday, July 20, = 1999 7:15=20 AM
> To: IDM...@IUASSN.COM
> &nbs=
p; =20 Subject: Dynam / NoDynam w/Call=20 Identifier/Literal
> =20
> =
> Hi=20 All,
> =20
> I'm sending this question = again=20 because I believe, from the

> = answers
> =20 received,
> that my question = wasn't=20 coherent. My question, stated in
the=20
> =20 last
> =20 paragraph,
> was meant to ask = - Why am=20 I not allowed to compile a
program =
> =20 with a
> =20 literal
> using DYNAM. = According=20 to the IDMS COBOL manual it is not
=
> =20 allowed? It
> =20 would
> seem to me that even = if I=20 decide to hard code a literal, I
=
> =20 should still
> =20 have
> the flexibility of = loading the=20 module at run time. This
will =
> =20 allow
> changes=20 to
> a program that may be = called by=20 many other programs and
avoid =
> the=20 need
> =20 to
> separately re-link the = changed=20 module with all the other
> = calling=20 modules.
> =20
> =20 Bruce
>
> =20
> =
> =20 Here's the original question...
> =20
> All DC programs here use = "CALL=20 literal" and the NODYNAM=20
parm.
> It=20 would
> =20 be
> beneficial for us to use = DYNAM in=20 our DC environment but it

> = does seem=20 to
> =20 be
> against the=20 rules.
>
> =20
> The R12.1 and R14 COBOL = manual (CD)=20 contains a description
> = (found=20 below)
> =20 for
> use of DYNAM/NODYNAM in = calling=20 other COBOL programs.
> =20
> =20
***************************************************************=20
> =20 *********
> =20 ********
> =20 ******************************
> &nbsp=
;=20 Static and dynamic calls -- CA-IDMS supports the=20 following
> &n=
bsp;=20 types of calls provided by VS COBOL II:

> =20
> =20 - CALL literal with NODYNAM, static (more storage,

less=20
> =20 CPU)
> =20
> =20 - CALL identifier, dynamic (less storage, more=20 CPU)
> =20
> To = call a=20 program dynamically you must use the=20 call
> identifier=20 format.
> =20
> A = VS COBOL=20 II program can use the COBOL CALL verb to
invoke=20
> an=20 assembler or COBOL II subprogram. The CA-IDMS
TRANSFER=20
> =20 CONTROL
> =20 (LINK
> = or=20 XCTL) must be used for invoking VS COBOL
subprograms.=20
> The = subprogram must be defined to the system either at=20
> = SYSGEN or=20 by
> =20 using
> = a DCMT=20 VARY DYNAMIC PROGRAM command. The correct
language=20
> = must be=20 specified, and the NONOVERLAYABLE attribute
must=20
> = also be=20 specified.
> =20
> A = COBOL II=20 program and all the COBOL II subprograms
that it=20
> = calls=20 dynamically must be compiled with the same
RES/NORES=20
> =20 compiler
> =20 option.
> =20
***************************************************************=20
> =20 *********
> =20 ********
> =20 *****************************
> =20
> =
> =20 So, could anyone explain why DYNAM can be used with a
variable=20
> (identifier)=20 as
> the program name but not = the=20 plain old everyday hard-coded
=
> =20 literal? Is
> it=20 just
> a pre-compiler/compiler = thing,=20 that it was coded that way
> = (which=20 I
> doubt) or=20 is
> it some internal aspect = that has=20 escaped me.
> =20
> Your help is=20 appreciated,
> Take=20 Care,
> Bruce ------=_NextPart_000_04C0_01BED362.B87CE080--
------------------------------ End of IDMS-L V1 #32 ********************

Chris Hoelscher

unread,

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

to

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

IDMS-L Thu, 22 Jul 1999 Volume 1 :
Number 33

In this issue:

Re[4]: Dynam / NoDynam w/Call Identifier/Literal
RE: LE370 Dumps and their usefulness

Dynam / NoDynam w/Call Identifier/Literal

RE: Area expansion ( R 14.0 / 9711 )

help needed on database expansion.

RE: Area expansion ( R 14.0 / 9711 )
RE: Area expansion ( R 14.0 / 9711 )
RE: Area expansion ( R 14.0 / 9711 )
RE: Area expansion ( R 14.0 / 9711 )
RE: Area expansion ( R 14.0 / 9711 )
RE: Area expansion ( R 14.0 / 9711 )

RE: help needed on database expansion.

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

Date: Wed, 21 Jul 1999 11:01 -0500

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

Subject: Re[4]: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <199907211043...@alltel.com>

Onni,

> You can have a DC COBOL II program without any CALL 'IDMSCOBI'

> calls. Therefore this does not apply.

You may well be right, but I don't think you can assume that the
reason we can't use DYNAM applies to EVERY single DC COBOL program.
It
might be that there are a few situations where IDMS could allow
DYNAM
programs, but rather than document and handle these situations (and

have to deal with issues when we get it wrong), CA simply choose
not
to support it at all.
Your findings on the way the CALL PGM and (DYNAM) CALL 'PGM'
statements expand, suggests that it's not the call itself - so this

very well could be true.

CICS cobol and DC cobol have many, if not all of the same
restrictions
(include DYNAM). IBM state: "The NODYNAM compiler option must be
used
if the COBOL program has been translated by the CICS translator."
This
statement is what led me think about the precompiler and hence
speculate that it could be the calls to IDMSCOBI that need to be
static.

Yes, I could be way off the mark. It could be as simple as a
performance issue. Whatever the reason, IBM also don't allow it in
their online environment, so I have to believe it's a good one.

Steve Franzon

______________________________ Reply Separator
_________________________________
Subject: Re: Re[2]: Dynam / NoDynam w/Call Identifier/Literal
Author: idm...@iuassn.com at internet
Date: 07/21/1999 2:20 AM

From: Steve Franzon <Steve....@alltel.com> To: idm...@iuassn.com
<idm...@iuassn.com> Date: 20. hein?kuuta 1999 19:11
Subject: Re[2]: Dynam / NoDynam w/Call Identifier/Literal

>I don't have the definitive answer, but here's some ideas... >
>DML verbs in your program expand to CALL 'IDMSCOBI' statements.

Compiling with

>DYNAM would make these dynamic calls. Maybe calls to the interface must
be
>static?
>

Steve

You can have a DC COBOL II program without any CALL 'IDMSCOBI' calls.

Therefore
this does not apply.

>Another possibility is that there may be some subtle difference between

the two
>types of dynamic calls. Possibly IDMS can trap the CALL identifier and
load the
>program using IDMS conventions, but cannot trap a DYNAM CALL literal.

Attached is the expanded code for the two types of calls compiled with

DYNAM opt

ion. IGZCLNK is called in both calls to load&execute the
subprogram. Because both types generate basically the same code, this

does not e

xplain the restriction with call 'literal' & DYNAM.

********************************************************* * CALL WITH

IDENTIFIER
*********************************************************
CALL PGM.
29A D207 D150 9000 MVC 336(8,13),0(9) TS2=0
2A0 DC07 D150 A024 TR 336(8,13),36(10) TS2=0

2A6 5820 D05C L 2,92(0,13) TGTFIXD+92

2AA 58F0 205C L 15,92(0,2) V(IGZCLNK )

2AE 4110 A166 LA 1,358(0,10) PGMLIT AT +354

2B2 05EF BALR 14,15

2B4 BF38 D089 ICM 3,8,137(13) TGTFIXD+137

2B8 0430 SPM 3,0

*********************************************************
* CALL WITH LITERAL

*********************************************************
CALL 'PGM'.

2BA 58F0 205C L 15,92(0,2) V(IGZCLNK )

2BE 4110 A157 LA 1,343(0,10) PGMLIT AT +339

2C2 05EF BALR 14,15

2C4 BF38 D089 ICM 3,8,137(13) TGTFIXD+137

2C8 0430 SPM 3,0

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

Date: Wed, 21 Jul 1999 09:18:51 -0700
From: John....@teale.ca.gov
To: idm...@iuassn.com
Subject: RE: LE370 Dumps and their usefulness
Message-ID: <882567B5.0...@teale.ca.gov>

From IBM's manual OS/390: Language Environment for OS/390 Customization

( CEEA504 SC28-1941-04 ) section: A.2.50.1 Usage Notes

Running with TRAP(OFF) (for exception diagnosis purposes) can cause
many side
effects,
because LE uses condition handling internally and requires TRAP(ON).
When you
run with
TRAP(OFF), you can get side effects even if you do not encounter a
software-raised condition, program check, or abend. If you do encounter
a
program check or an abend with TRAP(OFF) in effect, the following side
effects
can occur:
(11 bullets are shown .. the one that stands out is this one)
- Files opened by HLLs are not closed by LE, so records might be
lost.

I'm not certain what it is saying ... but the "records might be lost"
part looks
like a condition
that I would prefer to stay away from.

John Kamuf
Teale Data Center, State of California

Bruce Chris <chris...@hyder.com> on 07/20/99 07:00:59 AM

Please respond to idm...@iuassn.com

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

Subject: RE: LE370 Dumps and their usefullness

Hi,

Good luck. . .

CB

> > > Jos? van Kesteren

> > > Robeco Groep
> > >
> > >
> > >
> > >
> > > WIlliam...@blackdecker.com on 07/19/99 03:49:41 PM
> > >
> > > Please respond to idm...@iuassn.com
> > >
> > > To: idm...@iuassn.com

> > > cc: (bcc: Jos? van Kesteren/Robeco Group)

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

Date: Wed, 21 Jul 1999 12:28:18 -0700
From: JB Moore <conl...@ix.netcom.com>
To: idms-l <idm...@iuassn.com>

Subject: Dynam / NoDynam w/Call Identifier/Literal

Message-ID: <37961F...@ix.netcom.com>

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: Wed, 21 Jul 1999 16:33:18 -0400
From: "Robertson, Francine" <frob...@harris.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: Area expansion ( R 14.0 / 9711 )

Message-ID: <C01E7037C8FBD1119F8B00805F6F0BB779A3BF@CORPMX7>

Hi all,
I am very new to the DBA field(I'm actually a DBA backup) and
right now
I have to do
a space expansion. I had a 2252 on formatting the file. The area
is in
retrieval but I think I forgot
an area that is attached to the file that is extended. Can someone
tell me
if that's what a DB002252 error is.
Also if I have to include both areas on the format do I also need to
SYSpnch
both area to a file or
only the one that need expanding??

Appreciated any help I can get.

Francine Robertson

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

Date: Wed, 21 Jul 1999 16:09:58 -0400
From: "Robertson, Francine" <frob...@harris.com>
To: idms-l <idm...@iuassn.com>
Subject: help needed on database expansion.
Message-ID: <C01E7037C8FBD1119F8B00805F6F0BB779A3BD@CORPMX7>

Hi all,
I am very new to the DBA field and right now I'm doing a space
expansion.
I had a 2252 on formatting the file. The area is in retrieval but I
think I
forgot
a connected area. Can someone tell me if that's what a DB002252
error is.
Also if I have to include both areas on the format do I also need to
SYSpnch
both area or
only the one that is expanding??

Appreciated any help I can get.

Francine Robertson

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

Date: Wed, 21 Jul 1999 16:40:32 -0400
From: "McPhee, Sid" <SMc...@hess.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: Area expansion ( R 14.0 / 9711 )

Message-ID: <E048184A9C25D311B50600104BD011656DEAE2@WDB_EX_002>

Are you doing an expand page or an unld/reld?

> -----Original Message-----
> From: Robertson, Francine [SMTP:frob...@harris.com]
> Sent: Wednesday, July 21, 1999 4:33 PM
> To: 'idm...@iuassn.com'

> Subject: RE: Area expansion ( R 14.0 / 9711 )
>
>
> Hi all,
> I am very new to the DBA field(I'm actually a DBA backup) and

> right now
> I have to do
> a space expansion. I had a 2252 on formatting the file. The
area is
> in
> retrieval but I think I forgot
> an area that is attached to the file that is extended. Can
someone
> tell me
> if that's what a DB002252 error is.
> Also if I have to include both areas on the format do I also need
to
> SYSpnch
> both area to a file or
> only the one that need expanding??
>
> Appreciated any help I can get.
>
> Francine Robertson

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

Date: Wed, 21 Jul 1999 15:44:58 -0500
From: "Messerschmidt, Janie" <Janie.Mes...@ecolab.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: Area expansion ( R 14.0 / 9711 )

Message-ID: <E994F67723A4D211B00C000083623DF0651BD7@CORPHQ2>

are you planning an idmsxpag or an unload/reload

-----Original Message-----
From: Robertson, Francine [mailto:frob...@harris.com]
Sent: Wednesday, July 21, 1999 3:33 PM
To: 'idm...@iuassn.com'

Subject: RE: Area expansion ( R 14.0 / 9711 )

Hi all,
I am very new to the DBA field(I'm actually a DBA backup) and
right
now
I have to do
a space expansion. I had a 2252 on formatting the file. The area
is
in
retrieval but I think I forgot
an area that is attached to the file that is extended. Can someone
tell
me
if that's what a DB002252 error is.
Also if I have to include both areas on the format do I also need to

SYSpnch
both area to a file or
only the one that need expanding??

Appreciated any help I can get.

Francine Robertson

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

Date: Wed, 21 Jul 1999 17:03:37 -0400
From: "Robertson, Francine" <frob...@harris.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: Area expansion ( R 14.0 / 9711 )

Message-ID: <C01E7037C8FBD1119F8B00805F6F0BB779A3C1@CORPMX7>

I'm doing a page expansion to increase space on a db file.

-----Original Message-----
From: McPhee, Sid [SMTP:SMc...@hess.com]
Sent: Wednesday, July 21, 1999 4:41 PM
To: 'idm...@iuassn.com'

Subject: RE: Area expansion ( R 14.0 / 9711 )

Are you doing an expand page or an unld/reld?

> -----Original Message-----
> From: Robertson, Francine [SMTP:frob...@harris.com]
> Sent: Wednesday, July 21, 1999 4:33 PM
> To: 'idm...@iuassn.com'

> Subject: RE: Area expansion ( R 14.0 / 9711 )
>
>
> Hi all,
> I am very new to the DBA field(I'm actually a DBA backup)
and
> right now
> I have to do
> a space expansion. I had a 2252 on formatting the file. The
area is
> in
> retrieval but I think I forgot
> an area that is attached to the file that is extended. Can
someone
> tell me
> if that's what a DB002252 error is.
> Also if I have to include both areas on the format do I also need

to
> SYSpnch
> both area to a file or
> only the one that need expanding??
>
> Appreciated any help I can get.
>
> Francine Robertson

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

Date: Wed, 21 Jul 1999 16:25:40 -0500
From: "Messerschmidt, Janie" <Janie.Mes...@ecolab.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: Area expansion ( R 14.0 / 9711 )

Message-ID: <E994F67723A4D211B00C000083623DF0651BDD@CORPHQ2>

an initialize is not required
you can pre-allocate the file.

000007 //*
000008 //* IDMSXPAGE
000009 //*
000010 //IDMSBCF EXEC PGM=IDMSBCF,REGION=0M
000011 //STEPLIB DD DISP=SHR,DSN=IDDBMS.ID17.DBDCLIB
000012 // DD DSN=IDMS.ID17.LOADLIB4,DISP=SHR
000013 //SYSOUT DD SYSOUT=*
000014 //SYSLST DD SYSOUT=*
000015 //SYSIDMS DD DISP=SHR,DSN=IDDBMS.ID17.PARMLIB(SYSIDMS)
000016 //CSTOVRDB DD DSN=IDTECH.IN.CSTOVRDB,DISP=OLD
000017 //CSTOVRDN DD DSN=IDTECH.IN.CSTOVRDB.NEW,
000018 // DISP=OLD
000019 //SYSIPT DD *
000020 EXPAND PAGE FOR FILE ECL.CSTOVRDB
000021 INTO CSTOVRDN NEWSIZE 18452

you need to change the specific file names to match your own
but....this may help

-----Original Message-----
From: Robertson, Francine [mailto:frob...@harris.com]
Sent: Wednesday, July 21, 1999 4:04 PM
To: 'idm...@iuassn.com'

Subject: RE: Area expansion ( R 14.0 / 9711 )

I'm doing a page expansion to increase space on a db file.

-----Original Message-----
From: McPhee, Sid [SMTP:SMc...@hess.com]
Sent: Wednesday, July 21, 1999 4:41 PM
To: 'idm...@iuassn.com'

Subject: RE: Area expansion ( R 14.0 / 9711 )

Are you doing an expand page or an unld/reld?

> -----Original Message-----
> From: Robertson, Francine [SMTP:frob...@harris.com]
> Sent: Wednesday, July 21, 1999 4:33 PM
> To: 'idm...@iuassn.com'

> Subject: RE: Area expansion ( R 14.0 / 9711 )
>
>
> Hi all,
> I am very new to the DBA field(I'm actually a DBA backup)
and
> right now
> I have to do
> a space expansion. I had a 2252 on formatting the file. The
area is
> in
> retrieval but I think I forgot
> an area that is attached to the file that is extended. Can
someone
> tell me
> if that's what a DB002252 error is.
> Also if I have to include both areas on the format do I also
need
to
> SYSpnch
> both area to a file or
> only the one that need expanding??
>
> Appreciated any help I can get.
>
> Francine Robertson

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

Date: Wed, 21 Jul 1999 17:39:20 -0400
From: "McPhee, Sid" <SMc...@hess.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: Area expansion ( R 14.0 / 9711 )

Message-ID: <E048184A9C25D311B50600104BD011656DEAE4@WDB_EX_002>

initialization of the new file is not required.
- Create a new file with the new size.
- Run a BCF, include the current file and the new file in the jcl.
- Use the following as sysipt:
expand file aaa.bbb into xpage newsize 13682 ;
"xpage" is the ddname of the new file in your jcl.
good luck.

> -----Original Message-----
> From: Robertson, Francine [SMTP:frob...@harris.com]
> Sent: Wednesday, July 21, 1999 5:04 PM
> To: 'idm...@iuassn.com'

> Subject: RE: Area expansion ( R 14.0 / 9711 )
>
>
> I'm doing a page expansion to increase space on a db file.

>
> -----Original Message-----
> From: McPhee, Sid [SMTP:SMc...@hess.com]
> Sent: Wednesday, July 21, 1999 4:41 PM
> To: 'idm...@iuassn.com'

> Subject: RE: Area expansion ( R 14.0 / 9711 )
>
> Are you doing an expand page or an unld/reld?

>
> > -----Original Message-----
> > From: Robertson, Francine [SMTP:frob...@harris.com]
> > Sent: Wednesday, July 21, 1999 4:33 PM
> > To: 'idm...@iuassn.com'

> > Subject: RE: Area expansion ( R 14.0 / 9711 )
> >
> >
> > Hi all,
> > I am very new to the DBA field(I'm actually a DBA backup)
> and
> > right now
> > I have to do
> > a space expansion. I had a 2252 on formatting the file. The
> area is
> > in
> > retrieval but I think I forgot
> > an area that is attached to the file that is extended. Can
> someone
> > tell me
> > if that's what a DB002252 error is.
> > Also if I have to include both areas on the format do I also
> need
> to
> > SYSpnch
> > both area to a file or
> > only the one that need expanding??
> >
> > Appreciated any help I can get.
> >
> > Francine Robertson

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

Date: Wed, 21 Jul 1999 15:33:29 -0700

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

Subject: RE: Area expansion ( R 14.0 / 9711 )
Message-ID:

<2BCA09803339D211AE04...@unknown-68-47.hexcel.com>

Concerning your page expand, do not, repeat do not forget about the
'original page size' parameter in the area syntax when you modify the
segment that defines this area. This is a common mistake and one I am
sure
most of us have made at least once. This can cause you no end of
problems
if you do forget. Are you planning to do this with system up? If so
there
are several other pointers you will need to be aware of - things such as

file deallocates, vary new copy on the dmcl, etc.

-----Original Message-----
From: Robertson, Francine [mailto:frob...@harris.com]
Sent: Wednesday, July 21, 1999 1:33 PM
To: 'idm...@iuassn.com'

Subject: RE: Area expansion ( R 14.0 / 9711 )

Hi all,
I am very new to the DBA field(I'm actually a DBA
backup) and right now
I have to do
a space expansion. I had a 2252 on formatting the
file. The area is in
retrieval but I think I forgot
an area that is attached to the file that is extended.
Can someone tell me
if that's what a DB002252 error is.
Also if I have to include both areas on the format do I
also need to SYSpnch
both area to a file or
only the one that need expanding??

Appreciated any help I can get.

Francine Robertson

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

Date: Thu, 22 Jul 1999 10:04:34 +0200
From: "Jan Lenders" <J.Le...@ohra.nl>
To: idm...@iuassn.com
Subject: RE: help needed on database expansion.
Message-ID: <s796ec...@ohra.nl>

Francine,
The DB002252 probably means the SPACE of the file-DD in your JCL is not
=
enough to hold the desired file-size (as defined in the segment/DCML).

Besides the IDMSBCF-messages there may be some other messages in the =
joblog which indicate what happened.

Jan Lenders,
OHRA SO Service Center - A2-05
Tel. +31 26 400 9608

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Fri, 23 Jul 1999 Volume 1 :
Number 34

In this issue:

RE: help needed on database expansion.

RE: Perfromance monitors for IDMS
RE: Perfromance monitors for IDMS
RE: Perfromance monitors for IDMS
PMDC and ISP's Telephone Number

RE: Area expansion ( R 14.0 / 9711 )

Re: Dynam / NoDynam w/Call Identifier/Literal
Y2K question
Re: Y2K question
Re: Y2K question

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

Date: Thu, 22 Jul 1999 08:12:29 -0400

From: "Robertson, Francine" <frob...@harris.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>

Subject: RE: help needed on database expansion.
Message-ID: <C01E7037C8FBD1119F8B00805F6F0BB779A3C3@CORPMX7>

Yes you're right, thank you very much for all the notes I
received.

Francine

-----Original Message-----
From: Jan Lenders [SMTP:J.Le...@ohra.nl]
Sent: Thursday, July 22, 1999 4:05 AM
To: idm...@iuassn.com
Subject: RE: help needed on database expansion.

Francine,
The DB002252 probably means the SPACE of the file-DD in your JCL is not

enough to hold the desired file-size (as defined in the segment/DCML).

Besides the IDMSBCF-messages there may be some other messages in the

joblog which indicate what happened.

Jan Lenders,
OHRA SO Service Center - A2-05
Tel. +31 26 400 9608

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

Date: Thu, 22 Jul 1999 11:00:00 -0400
From: radu...@bkb.com
To: idm...@iuassn.com
Subject: RE: Perfromance monitors for IDMS
Message-ID: <00069EC...@bkb.com>

I haven't been able to find out anything about this product or vendor.
Does
anyone have a website url or contact person?

Thanks
Richard A. Duffus RADu...@bkb.com

-----Original Message-----
From: idm...@iuassn.com at INTERNET
Sent: Saturday, July 17, 1999 2:38 PM
To: IDM...@iuassn.com at INTERNET
Subject: Perfromance monitors for IDMS

I've seen a number of posts, but no mention of I what I think is hands
down
the best monitor out there - CMMT (Cross Memory Master Terminal) from
Aquifir. I haven't been lucky enough to use it for years now, and I
sure do
miss it. It came with a companion XOMT that ran from inside of DC and
if
the names of the products have changed, I'm sure Daniel Begin will jump
in
to correct me. This product blows the doors off all the competition in
usefullness and flexibility and for me operates intuitively like I wish
other
software on all platforms would.

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

Date: Thu, 22 Jul 1999 09:32:16 -0700
From: "Lee, Brian" <bl...@pac.bluecross.ca>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Perfromance monitors for IDMS
Message-ID: <FF09222003FAD211A07900A024B261F08EC9@PACEXCH>

Richard,

You might want to check with the folks at International Software
Products
(Jim Phillips or John Abell). Phone number is (414) 778-7798. Website:

http://www.ispinfo.com/

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: radu...@bkb.com [SMTP:radu...@bkb.com]
> Sent: Thursday, July 22, 1999 8:00 AM
> To: idm...@iuassn.com

> Subject: RE: Perfromance monitors for IDMS
>
> I haven't been able to find out anything about this product or vendor.

> Does
> anyone have a website url or contact person?
>
> Thanks
> Richard A. Duffus RADu...@bkb.com

>
> -----Original Message-----
> From: idm...@iuassn.com at INTERNET
> Sent: Saturday, July 17, 1999 2:38 PM
> To: IDM...@iuassn.com at INTERNET
> Subject: Perfromance monitors for IDMS
>

> I've seen a number of posts, but no mention of I what I think is hands

> down
> the best monitor out there - CMMT (Cross Memory Master Terminal) from
> Aquifir. I haven't been lucky enough to use it for years now, and I
sure
> do
> miss it. It came with a companion XOMT that ran from inside of DC and
if
> the names of the products have changed, I'm sure Daniel Begin will
jump in
> to correct me. This product blows the doors off all the competition
in
> usefullness and flexibility and for me operates intuitively like I
wish
> other
> software on all platforms would.

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

Date: Thu, 22 Jul 1999 11:12:17 -0700
From: John....@teale.ca.gov
To: idm...@iuassn.com
Subject: RE: Perfromance monitors for IDMS
Message-ID: <882567B6.0...@teale.ca.gov>

I just called the phone number and got that it 'has been
disconnected'. We
have been
using CMMT for years. If Aquasoft has sold the product to another
vendor,
they have not
notified us ! I did notice that there was no mention of it on their

(Aquasoft) website.
I'm trying to find out about the current status myself.

"Lee, Brian" <bl...@pac.bluecross.ca> on 07/22/99 09:32:16 AM

Please respond to idm...@iuassn.com

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

Subject: RE: Perfromance monitors for IDMS

Richard,

You might want to check with the folks at International Software
Products
(Jim Phillips or John Abell). Phone number is (414) 778-7798. Website:

http://www.ispinfo.com/

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: radu...@bkb.com [SMTP:radu...@bkb.com]
> Sent: Thursday, July 22, 1999 8:00 AM
> To: idm...@iuassn.com

> Subject: RE: Perfromance monitors for IDMS
>
> I haven't been able to find out anything about this product or vendor.

> Does
> anyone have a website url or contact person?
>
> Thanks
> Richard A. Duffus RADu...@bkb.com

>
> -----Original Message-----
> From: idm...@iuassn.com at INTERNET
> Sent: Saturday, July 17, 1999 2:38 PM
> To: IDM...@iuassn.com at INTERNET
> Subject: Perfromance monitors for IDMS
>

> I've seen a number of posts, but no mention of I what I think is hands

> down
> the best monitor out there - CMMT (Cross Memory Master Terminal) from
> Aquifir. I haven't been lucky enough to use it for years now, and I
sure
> do
> miss it. It came with a companion XOMT that ran from inside of DC and
if
> the names of the products have changed, I'm sure Daniel Begin will
jump in
> to correct me. This product blows the doors off all the competition
in
> usefullness and flexibility and for me operates intuitively like I
wish
> other
> software on all platforms would.

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

Date: Thu, 22 Jul 1999 14:33:44 -0400
From: "isp.worldchat" <i...@ispinfo.com>
To: <idm...@iuassn.com>
Subject: PMDC and ISP's Telephone Number
Message-ID: <009601bed470$bb214ce0$0518a8c0@DEVELOPMENT>

The phone number shown fo PMDC (International Software Products) was
extremely old!!

The real number is 1-800-295-7608.

Yours truly,
John Abell

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

Date: Thu, 22 Jul 1999 15:14:00 -0500

From: "Lorenzen, David C" <david.l...@eds.com>

To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Area expansion ( R 14.0 / 9711 )

Message-ID: <B9CB0C7E771ED2119FA400A02461EE240325E7EE@USPLM206>

Francine,
I have a checklist for my DBA staff for whenever a page expand is
needed.
We just pull it out, and about an hour later, the project is done.
I could send this to you in text format if you would like.
Checklists are nice when doing an IDMS project that requires thought,
but you do not accomplish them often enough for the to rely on memory.

David Lorenzen
EDS
> ----------
> From: Robertson, Francine

> Sent: Wednesday, July 21, 1999 3:33 PM
> To: 'idm...@iuassn.com'
> Subject: RE: Area expansion ( R 14.0 / 9711 )
>
>
> Hi all,
> I am very new to the DBA field(I'm actually a DBA backup) and

> right now
> I have to do
> a space expansion. I had a 2252 on formatting the file. The
area is
> in
> retrieval but I think I forgot
> an area that is attached to the file that is extended. Can
someone
> tell me
> if that's what a DB002252 error is.
> Also if I have to include both areas on the format do I also need
to
> SYSpnch
> both area to a file or
> only the one that need expanding??
>
> Appreciated any help I can get.
>
> Francine Robertson
>

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

Date: Thu, 22 Jul 1999 16:37:47 -0400
From: "Dave J. Miller" <djmi...@sherwin.com>
To: conl...@ix.netcom.com, idm...@iuassn.com
Subject: Re: Dynam / NoDynam w/Call Identifier/Literal
Message-ID: <1999072220...@host68.sherwin.com>

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,

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

Date: Thu, 22 Jul 1999 14:41:34 -0700
From: "Lyon, Terence" <Terry...@ARZ.Boeing.com>
To: "'IDM...@IUASSN.COM'" <IDM...@IUASSN.COM>
Subject: Y2K question
Message-ID:
<11979B984D76D111A7A1...@xch-mes-01.msc.az.boeing.com>

We are running R14.0 on an LPAR with a Y2K date. Per GI93360, we can no

longer substring DATE, but have to move it to a x(6) field first. Has
anyone else encountered this situation and if so, is the ONLY solution
to
move DATE to an X(6) field??

thanks in advance!

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

Date: Thu, 22 Jul 1999 17:26:39 -0500

From: "Brian Potts" <Bdp...@comdisco.com>
To: <idm...@iuassn.com>

Subject: Re: Y2K question
Message-ID: <s79754...@groupwise.comdisco.com>

Terry,

This has always been a problem, only the last two digits of the year
have =
never been zero before.

DATE is numeric. SUBSTRING is a function performed on an alphanumeric =

field (a string). The first thing ADS does is convert the numeric to an
=
alphanumeric. In someone's infinite wisdom, when they were creating
ADS, =
they decided to zero suppress leading zeroes automatically when you =
convert from numeric to alphanumeric.

The end result is that instead of taking the date, lets say January 1st,
=
2000 is converted to ' 101' (that's 3 blanks and the number one zero
=
one) instead of '000101'

I believe this "automatic" conversion will automatically remove spaces =

from the new string as well, leaving you with a 3 character string of =
'101'. Chances are your substring will die if you try to substring =
anything past 3 characters.

As a side note, moving DATE to a X(06) field is not enough. It will
still =
zero suppress leading zeroes.

You can try this

SUBSTRING(REPLACE(DATE,' ','0'),x,y)

where x is your starting position in your current substring and y is the
=
length in your current substring.

This will take the date and convert it to a string, replace the leading
=
suppressed zeroes (blanks) with zeroes again and allow your substring to
=
work.

You may accomplish the same thing by moving the REPLACE(DATE,' ','0') to
=
your new X(06) field.

I hope this helps

Brian Potts

>>> "Lyon, Terence" <Terry...@ARZ.Boeing.com> 07/22/99 04:41PM >>>
We are running R14.0 on an LPAR with a Y2K date. Per GI93360, we can no

longer substring DATE, but have to move it to a x(6) field first. Has
anyone else encountered this situation and if so, is the ONLY solution
to
move DATE to an X(6) field??

thanks in advance!

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

Date: Fri, 23 Jul 1999 11:24:45 +1000
From: Willem Oudyk <Wil...@pangaea.nu>
To: idm...@iuassn.com
Subject: Re: Y2K question
Message-ID: <4.2.0.58.1999072...@pangaea.nu>

Indeed,
We had to search-and-fix as well. This is how we changed ours;
(given the source field was yymmdd and the destination was to be
dd.mm.yy)

OLD
------
! IF DATEFLD (IDX1) NE ZERO
! MOVE CON(SUBSTR(DATEFLD (IDX1) 5 2) '.'
! SUBSTR(DATEFLD (IDX1) 3 2) '.'
! SUBSTR(DATEFLD (IDX1) 1 2))
! TO DATEFLDM (IDX1).

NEW
-------
IF DATEFLD (IDX1) NE ZERO
MOVE REPLACE (CON(SUBSTR(DATEFLD (IDX1) 5 2) '.'
SUBSTR(DATEFLD (IDX1) 3 2) '.'
SUBSTR(DATEFLD (IDX1) 1 2)) ' ','0' )
TO DATEFLDM (IDX1).

At 17:26 22/07/99 Thursday -0500, you wrote:
>Terry,
>
>This has always been a problem, only the last two digits of the year
have
>never been zero before.
>
>DATE is numeric. SUBSTRING is a function performed on an alphanumeric
>field (a string). The first thing ADS does is convert the numeric to
an
>alphanumeric. In someone's infinite wisdom, when they were creating
ADS,
>they decided to zero suppress leading zeroes automatically when you
>convert from numeric to alphanumeric.
>
>The end result is that instead of taking the date, lets say January
1st,
>2000 is converted to ' 101' (that's 3 blanks and the number one
zero
>one) instead of '000101'
>
>I believe this "automatic" conversion will automatically remove spaces
>from the new string as well, leaving you with a 3 character string of
>'101'. Chances are your substring will die if you try to substring
>anything past 3 characters.
>
>As a side note, moving DATE to a X(06) field is not enough. It will
still
>zero suppress leading zeroes.
>
>You can try this
>
>SUBSTRING(REPLACE(DATE,' ','0'),x,y)
>
>where x is your starting position in your current substring and y is
the
>length in your current substring.
>
>This will take the date and convert it to a string, replace the leading

>suppressed zeroes (blanks) with zeroes again and allow your substring
to work.
>
>You may accomplish the same thing by moving the REPLACE(DATE,' ','0')
to
>your new X(06) field.
>
>I hope this helps
>
>Brian Potts
>
> >>> "Lyon, Terence" <Terry...@ARZ.Boeing.com> 07/22/99 04:41PM >>>
>We are running R14.0 on an LPAR with a Y2K date. Per GI93360, we can
no
>longer substring DATE, but have to move it to a x(6) field first. Has
>anyone else encountered this situation and if so, is the ONLY solution
to
>move DATE to an X(6) field??
>
>thanks in advance!

-------------------------------------------------
Willem Oudyk
14 Fortescue Grove
Vermont Sth. Victoria 3133
Australia Ph/Fax: +61 (3) 9887 9121
Email:wil...@pangaea.nu
Web:www.pangaea.nu
-------------------------------------------------

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Sat, 24 Jul 1999 Volume 1 :
Number 35

In this issue:

Audrey A. Hunt/NYLIC is out of the office.
Re: Perfromance monitors for IDMS
RE: Y2K question
Re: Perfromance monitors for IDMS
Re: Perfromance monitors for IDMS

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

Date: Fri, 23 Jul 1999 04:06:36 -0400

From: "Audrey A. Hunt" <Audrey_...@NEWYORKLIFE.COM>

To: IDM...@iuassn.com (IDMS-L)
Subject: Audrey A. Hunt/NYLIC is out of the office.
Message-ID: <852567B7.0...@Email.NewYorkLife.com>

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

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

Date: Fri, 23 Jul 1999 08:03:44 -0500
From: nfu...@appletonpapers.com (Nancy Fuller)
To: idm...@iuassn.com
Subject: Re: Perfromance monitors for IDMS
Message-ID: <379868...@appletonpapers.com>

We just purchased CMMT/XOMT at the beginning of this year.
The number I have is 1-888-518-9111 (I checked, it works).
Regent Gravel (I believe) still handles the product. His number
is 727-515-8515.
By the way, this is a really nice product.
Nancy Fuller

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

Date: Fri, 23 Jul 1999 10:05:12 -0500
From: Tim Gortner <TimGo...@soph.com>
To: "'idm...@iuassn.com'" <idm...@iuassn.com>
Subject: RE: Y2K question
Message-ID: <8D8E2D0FA8FFD111960A0060B068A8E6304DA5@DALLAS>

All:

FYI, this also happens in CLISTs. If the year is 2000, SET DATE =
&SYSDATE will abort on a non numeric error. The fix is SET DATE =
&STR(&SYSDATE) which doesn't zero suppress. REXX works OK because the
date function returns CCYYMMDD.

Tim Gortner
Sophisticated Business Systems Inc.
303.300.3577 x111
TimGo...@soph.com

-----Original Message-----
From: Brian Potts [mailto:Bdp...@comdisco.com]
Sent: Thursday, July 22, 1999 4:27 PM
To: idm...@iuassn.com
Subject: Re: Y2K question

Terry,

one) instead of '000101'

You can try this

SUBSTRING(REPLACE(DATE,' ','0'),x,y)

work.

your new X(06) field.

I hope this helps

Brian Potts

thanks in advance!

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

Date: Fri, 23 Jul 1999 08:16:40 -0700
From: John....@teale.ca.gov
To: nfu...@appletonpapers.com, idm...@iuassn.com
Subject: Re: Perfromance monitors for IDMS
Message-ID: <882567B7.0...@teale.ca.gov>

Good to hear Nancy. We've used it (CMMT/XOMT) and liked it for years.
And the
staff at Aquasoft (Regent,Daniel, and Andre) have always had that "We
Care"
attitude
when we've needed support.

nfu...@appletonpapers.com (Nancy Fuller) on 07/23/99 06:03:44 AM

Please respond to nfu...@appletonpapers.com; Please respond to
idm...@iuassn.com

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

Subject: Re: Perfromance monitors for IDMS

We just purchased CMMT/XOMT at the beginning of this year.
The number I have is 1-888-518-9111 (I checked, it works).
Regent Gravel (I believe) still handles the product. His number
is 727-515-8515.
By the way, this is a really nice product.
Nancy Fuller

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

Date: Fri, 23 Jul 1999 11:32:15 -0400

From: "Daniel Begin" <dan...@aquisoft.com>
To: <idm...@iuassn.com>

Subject: Re: Perfromance monitors for IDMS
Message-ID: <007e01bed520$8bd340a0$14c4...@aquisoft.com>

Hi there,

I would like to clarify the situation on our CMMT/XOMT products. It was
distributed by a company called Aquifer, out of Boca Raton. They are
still
allowed to sell the product.

We also sell the product directly now, so you are welcome to contact us
directly.

Support is done directly by us for all customers.

Daniel Begin
Aquisoft

----- Original Message -----
From: <John....@teale.ca.gov>
To: <idm...@iuassn.com>
Sent: Thursday, July 22, 1999 2:12 pm
Subject: RE: Perfromance monitors for IDMS

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

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

Chris Hoelscher

unread,

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

to

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

IDMS-L Mon, 26 Jul 1999 Volume 1 :
Number 36

In this issue:

RE: New DBA needs help with maintaining and optimizing indexes
RE: New DBA needs help with maintaining and optimizing indexes

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

Date: Mon, 26 Jul 1999 10:33:10 EDT
From: "Michael Gardner" <mhga...@hotmail.com>
To: idm...@iuassn.com
Subject: RE: New DBA needs help with maintaining and optimizing indexes
Message-ID: <1999072614331...@hotmail.com>

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 09:42:11 -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: <B9CB0C7E771ED2119FA400A02461EE240325E7FD@USPLM206>

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
>

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

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