CALC modify
John Shivley
program to change my CALC key? I had heard that I will double my I/Os
because my new CALC key will reference a different DBKey that will
then point back to my original DBKey where the data still resides.
Will this pointer be a SR2 or SR4????
Thanks in advance,
John
Brian Potts
True about the I/O if your doing CALC reads. It doesn't increase I/O's for area sweeps or index reads. I don't remember the system record number, but here's what happens.
Whatever page the new key calcs to gets this system record. The record simply points to the DB-KEY that the record had when stored with this Original CALC key (the original DB-KEY).
Calc I/O's go to the new page, find the system record that points to the original key and goes to the original page to retrieve the record.
It's more overhead up front (but better in the long run), if you delete the record and store it again with the new key. This would place the record in the "correct" spot with a new DB-KEY. Sometimes this is not possible because of set connections. In this case an unload/reload should happen at some point to re-locate the records to their "correct" page.
Brian
>>> John Shivley <John.S...@ALLTEL.COM> 09/29/00 03:36PM >>>
Wood, Chris
It is an SR2/SR3 combination.
Chris Wood
Alberta Department of Resource Development
CANADA
Miley, Dan L , N-Dan Miley & Associates, Inc.
overflow because in order to maintain CALC and DBKEY integrity it is
necessary to connect the SR1 Calc set on the new target page to the actual
location as records are not relocated on CALC key modifies. SR2/3 records
occur after database restructures if there is insufficient space. SR4
records are fragment records store if there is insufficient space for a
variable length record.
Obviously Calc key modifies should be avoided if possible, but one or two
should not cause much trouble.
Dan Miley
Consultant to Lockheed-Martin
dan.l...@lmco.com
Miley, Dan L , N-Dan Miley & Associates, Inc.
my earlier reply.
Dan Miley
-----Original Message-----
From: Wood, Chris [mailto:Chris...@GOV.AB.CA]
Sent: Friday, September 29, 2000 5:21 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: CALC modify
Brian,
It is an SR2/SR3 combination.
Chris Wood
Alberta Department of Resource Development
CANADA
SEA...@pillsbury.com
the "new" dbkey?
Stephen Earle
Brian Potts <Bdp...@COMDISCO.COM> on 09/29/2000 04:12:26 PM
Please respond to IDMS Public Discussion Forum <IDM...@LISTSERV.IUASSN.COM>
To: IDM...@LISTSERV.IUASSN.COM
cc: (bcc: Stephen V Earle/USA/Pillsbury)
Subject: Re: CALC modify
John,
True about the I/O if your doing CALC reads. It doesn't increase I/O's for area
sweeps or index reads. I don't remember the system record number, but here's
what happens.
Whatever page the new key calcs to gets this system record. The record simply
points to the DB-KEY that the record had when stored with this Original CALC key
(the original DB-KEY).
Calc I/O's go to the new page, find the system record that points to the
original key and goes to the original page to retrieve the record.
It's more overhead up front (but better in the long run), if you delete the
record and store it again with the new key. This would place the record in the
"correct" spot with a new DB-KEY. Sometimes this is not possible because of set
connections. In this case an unload/reload should happen at some point to
re-locate the records to their "correct" page.
Brian
>>> John Shivley <John.S...@ALLTEL.COM> 09/29/00 03:36PM >>>
What happens to the I/Os and reference to the DBKey if I use a COBOL
program to change my CALC key? I had heard that I will double my I/Os
because my new CALC key will reference a different DBKey that will
then point back to my original DBKey where the data still resides.
Will this pointer be a SR2 or SR4????
Thanks in advance,
John
______________________________________________________________________
The information contained in this message is private and confidential
information which may also be subject to the attorney-client privilege and work
product doctrine. This information is intended only for the individual or
entity named above. If the reader of this message is not the intended
recipient, you are hereby notified that any use, dissemination, distribution or
copy of this message is strictly prohibited. If you have received this message
in error, please notify the sender by return e-mail and destroy all copies of
the message. Thank you.
Lupico, Joe
I believe the only thing that happens is your user record will get
disconnected from the SR1 record chain on the page it currently resides on,
and attached to the SR1 record chain on its new target page. This will
cause at least two page reads to get your record. The first read will be to
get the SR1 record on the new target page, and the second read will be to
the page containing your user record once it gets to that point in the SR1
chain. It would act like a CALC overflow.
Joe
Michael Newman
The calc chain on a page is treated just like a sorted set, and is "rooted"
off of the SR1 in the page header. All records defined as calc will have a
next and prior pointer for the calc set.
What happens when you change the calc key is it gets disconnected from its
original page's calc set, and connected (inserted) into the new calc page
set. The record never moves, but now the new calc key will point to a
different page, and by walking the calc set, it will "bounce" back to the
original page to pick up the intended record, and then return back. So, not
only does the I/O increase for this record, but for every calc record later
in the chain.
Example: Lets use pages 100 and 200 for our demonstration
Old key value "MMMMM" dbkey 100:5
Page 100 calc set looks like this:
100:1 calc value "AAAAA"
100:4 calc value "EEEEE"
100:2 calc value "JJJJJ"
100:5 calc value "MMMMM" (our record)
100:8 calc value "RRRRR"
Page 200 calc set looks like this:
200:1 calc value "BBBBB"
200:6 calc value "GGGGG"
200:3 calc value "PPPPP"
You change the value to be "DDDDD" dbkey is still 100:5, but the calc
algorithm will target page 200
Page 100 calc set now looks like this:
100:1 calc value "AAAAA"
100:4 calc value "EEEEE"
100:2 calc value "JJJJJ"
100:8 calc value "RRRRR" (notice our record is now
missing in the chain)
Page 200 calc set now looks like this:
200:1 calc value "BBBBB"
200:6 calc value "GGGGG"
100:5 calc value "MMMMM" (our record)
200:3 calc value "PPPPP"
Now when calcing to key value "MMMMM" our record, it will read page 200,
walk its calc set, which will jump back to page 100 to pick up our record,
and then return.
Think of it as working just like disconnect a via record from a set it is
clustered around, and reconneting it to another set on another page. The
record did not move, only access via the sets have changed. Same with the
calc set.
> Michael A. Newman
> 101 CentrePort Drive, Suite 310
> Greensboro, North Carolina 27409-9436
> Phone (336) 605-4771 x116
> Fax (336) 605-4772
> e-mail: Michae...@soph.com
> Please visit our website at: www.soph.com
-----Original Message-----
From: Brian Potts [mailto:Bdp...@COMDISCO.COM]
Sent: Friday, September 29, 2000 5:12 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: CALC modify
John,
True about the I/O if your doing CALC reads. It doesn't increase I/O's for
area sweeps or index reads. I don't remember the system record number, but
here's what happens.
Whatever page the new key calcs to gets this system record. The record
simply points to the DB-KEY that the record had when stored with this
Original CALC key (the original DB-KEY).
Calc I/O's go to the new page, find the system record that points to the
original key and goes to the original page to retrieve the record.
It's more overhead up front (but better in the long run), if you delete the
record and store it again with the new key. This would place the record in
the "correct" spot with a new DB-KEY. Sometimes this is not possible
because of set connections. In this case an unload/reload should happen at
some point to re-locate the records to their "correct" page.
Brian
>>> John Shivley <John.S...@ALLTEL.COM> 09/29/00 03:36PM >>>
Miley, Dan L , N-Dan Miley & Associates, Inc.
Lupico's note for the real scoop.
Dan Miley
-----Original Message-----
From: SEA...@PILLSBURY.COM [mailto:SEA...@PILLSBURY.COM]
Sent: Friday, September 29, 2000 5:32 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: CALC modify
Bryan, I would think that the index down pointer would be modified to point
to
the "new" dbkey?
Stephen Earle
Brian Potts <Bdp...@COMDISCO.COM> on 09/29/2000 04:12:26 PM
Please respond to IDMS Public Discussion Forum <IDM...@LISTSERV.IUASSN.COM>
To: IDM...@LISTSERV.IUASSN.COM
cc: (bcc: Stephen V Earle/USA/Pillsbury)
Subject: Re: CALC modify
John,
Brian
Thanks in advance,
John
Brian Potts
The point was, there isn't a "new" DB-KEY, just a new calc key. The index would still point to the same DB-KEY.
The index would be updated if the symbolic key of the index changed as well, but it would still just point to the DB-KEY of the record.
>>> <SEA...@PILLSBURY.COM> 09/29/00 04:31PM >>>
Bob_W...@tiburontech.com
I/Os as IDMS treats the CALC set as any sorted set and generally starts at
the first of set and accesses each record comparing keys til it hits the
correct one. If you do a lot of calc-key modifications there is potential
for a lot of I/Os.
Bob
Steve Cannon
that had its calc key changed be affected - but anything else that may
target calc to that page. All in all - not a wise idea except for the very
ODD occurrence.
Steve
Griffiths, Mark , M.E.
multiple languages with IDMS. We are a CICS shop, so we do not use products,
such as ADS/O or Online Mapping.
> The primary concern is how the software will handle the data itself. At
this point we are currently looking at supporting French and English at the
same time.
As you have had no replies I will just throw in my opinion (this is not
based on experience)...
There are a number of techniques in IDMS to handle multi-lingual maps but
you are not asking IDMS to do this - I assume that you are a straight
CICS/IDMS and batch site with IDMS simply serving the data you request.
Well data is data and so far as I am aware the language used is completely
irrelevant - if you are concerned with accents and currency symbols then
there is certainly no translation being done by IDMS.
In short I fail to understand either your question or alternately your
concerns.
Mark
Miley, Dan L , N-Dan Miley & Associates, Inc.
I worked on an application many years ago that supported two
languages: English and Spanish. There were no literals on the maps: every
field was data field to the map compiler. We then used a switch in the
database to set a subscript which indicated which language to use when
displaying the map. It was somewhat development intensive but it generally
worked well. One issue that we encountered was the length of Spanish words
(when they were longer than the English equalivalent). Anyway, not sure if
the above is what is you were looking for but it may be a start.
Dan Miley
Consultant to Lockheed-Martin
dan.l...@lmco.com
-----Original Message-----
From: Bob Nardin [mailto:bob.n...@EDWARDJONES.COM]
Sent: Wednesday, October 04, 2000 10:44 AM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Multi Language Support
I have been asked to find out if there are any issues with supporting
multiple languages with IDMS. We are a CICS shop, so we do not use products,
such as ADS/O or Online Mapping.
The primary concern is how the software will handle the data itself. At this
point we are currently looking at supporting French and English at the same
time.
TIA
Bob Nardin
IS Database Systems
Edward Jones
201 Progress Parkway
Maryland Heights, MO 63043-3042
(314) 515-7886
bob.n...@edwardjones.com
Dumouchel, Jacques
of its type or hex value.
We have 2 sites one using CICS/IDMS and the other one using IDMSDC.
On the IDMSDC side of the world we have french and english maps called by
ADS/O applications. The application will select one or the other depending
on the language of choice of the operator.
On the CICS side we have french and english SDFII maps and again we will
display either one to the operator depending on his/her language of choice.
For both the IDMSDC and CICS, some applications have to save and retrieve
text data. The text data can be either french or english. For example
preformated form letters where the operators only fill in the blanks. Those
preformated form letters can be in either language and IDMS has absolutely
no problems.
Hope this answers your question.
Jacques Dumouchel
CCRA-ADRC