ca.portal.admin

Re:Re: DC205011 No Journals are AVAILABLE

Discussion created by ca.portal.admin on May 25, 2005
Do not have an exit but you have several alternatives. 1. Would be to
increase the size of the journals 2. Would be to increase the number of
journals 3. Would be to put the journals to a disk pool setup for them
exclusively.

There are advantages and disadvantages to each solution but the exit =
would
not be a solution at all for me.

I am assume that you have a special job class for the tape offload jobs =
(
journal jobs) so that there is no delay in starting the offloads and the
offload jobs should be set a notch above other batch jobs as well if
possible.

Dick

Richard C Borman/GIS/CSC
CSC/GIS Idms System Support
9305 Lightwave Ave
San Diego, Ca 92193-9011
office 858-573-3265
rborman@csc.com



-------------------------------------------------------------------------=
---------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit =
written
agreement or government initiative expressly permitting the use of =
e-mail
for such purpose.
-------------------------------------------------------------------------=
---------------





""Klan, Robert
(Corporate)"" To: =
IDMS-L@LISTSERV.IUASSN.COM
<Robert.Klan cc:
@CORPORATE.GE.CO Subject: DC205011 No =
Journals are AVAILABLE
M>
Sent by: IDMS
Public
Discussion Forum
<IDMS-L


05/25/2005 05:17
AM
Please respond
to IDMS Public
Discussion Forum






Has anyone come up with an automated or exit solution for those times in
which a run unit fills up the journals which requires a manual cancel =
run
unit to resolve?

Limits is active, however they are set high for legitimate run units.

SYSLOG Example.....

+IDMS DC205013 All Disk Journals are UNAVAILABLE; Reasons below.
+IDMS DC205004 Disk Journal is OFFLOADING/CONDENSING. Waiting for J1JRNL
+IDMS DC205014 ARCHIVE JOURNAL NOT yet RUN against full Journal J2JRNL
+IDMS DC205014 ARCHIVE JOURNAL NOT yet RUN against full Journal J3JRNL
+IDMS DC205011 NO Journals are AVAILABLE.   IDMS Waiting

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: DC205011 No Journals are AVAILABLE
"Some databases are king size, and there aren't enough journals you can
define to handle an update program in a loop. Limits and an exit is the
only solution. Unless you're working on sunset systems with no new
development/activity. Of course finding a systems programmer with
assembler skills to write an exit only the lucky sites are fortunate to
have.

Lutz Petzold



Do not have an exit but you have several alternatives. 1. Would be to
increase the size of the journals 2. Would be to increase the number of
journals 3. Would be to put the journals to a disk pool setup for them
exclusively.

There are advantages and disadvantages to each solution but the exit =
would not be a solution at all for me.

I am assume that you have a special job class for the tape offload jobs
= ( journal jobs) so that there is no delay in starting the offloads and
the offload jobs should be set a notch above other batch jobs as well if
possible.

Dick


-----------------------------------------
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender by
reply e-mail and then delete this e-mail immediately. Thank you. Aetna


"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Release 16.0 & HSL
"Greetings from Southwest Airlines.

We are wondering if anyone on the list uses HSL and has installed release
16.0?

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Order of members in an unsorted via set
"Richard,

It sounds to me that your load program is resetting set currency on the
owner record (Record1) each time you store a member record (Record2).
That might be occurring if you do something like ""Find current Record1""
or ""Obtain Calc Record1"" before you store. To maintain the order of the
via records, the currency for the set must be on the last stored member
record. I would suggest that you examine the load program code to see
what it's doing with set currencies.

Good luck,

Roger C. Lawrence
Database Administrator
Seminole Electric Cooperative, Inc.
Tampa, Fl.
813.739.1518
reveritt@DIS.UMSMED.EDU 05/25/05 5:33 PM >>>
Hello all

We have a set relationship that is not acting the way I expect it to.

Record1 is the owner and is calc. Record2 is via an unsorted set with
""ORDER IS NEXT"" specified in the set. In normal online situations,
when
we add new entries of Record2, they show up at the end of the set as I
expect. Last in last out. We have a batch COBOL load program to
re-load
Record2 after a format change. We try to keep the order of Record2
entries by unloading using an area sweep on Record1 and reading
Record2
through the set until reaching the end of set for each occurance of
Record1. When we load Record2 records back, they end up in the reverse
order that they were unloaded in. That's not what I expected it to do,
nor what I remembered it doing. Any ideas why it's doing this?

Thanks
Richard

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Order of members in an unsorted via set
"Richard,

This sounds like a currency problem in the reload program. Check it to
make sure it's not getting current on the owner each time a member record
is being stored.

Bob Wiklund
Tiburon Technologies
wiklund@tiburontech.com
623 594-6022

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Order of members in an unsorted via set
"Hello all

We have a set relationship that is not acting the way I expect it to.

Record1 is the owner and is calc. Record2 is via an unsorted set with
""ORDER IS NEXT"" specified in the set. In normal online situations, when
we add new entries of Record2, they show up at the end of the set as I
expect. Last in last out. We have a batch COBOL load program to re-load
Record2 after a format change. We try to keep the order of Record2
entries by unloading using an area sweep on Record1 and reading Record2
through the set until reaching the end of set for each occurance of
Record1. When we load Record2 records back, they end up in the reverse
order that they were unloaded in. That's not what I expected it to do,
nor what I remembered it doing. Any ideas why it's doing this?

Thanks
Richard

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Order of members in an unsorted via set
"Sounds like it is doing exactly what I would expect. Put your thinking
cap on.

When order is next you have an entry-sequenced dataset and ""last (or
most recent stored) in is the first one retrieved when one does an
'obtain next' so last in is first out not last.

If you want to preserve the order, then you need to read the set
backwards during the unload so the member record occurrence that was
first stored in the set is the first one unloaded and the first one
presented to the program doing the reload.

John Wheeler

Outcomes