CONTACTS 
0201 - Boeing                                                                                                                                                             O-00000816 0505
020101 - Mr. Garold L. Johnson
020103 - Modeling and Simulation                                                                                                                                          O-00000816 0505

SUBJECTS
Contacts Save Failing in Aerospace company Record
Save Contact Record, F2 0705051

0704 -
0704 -    ..
0705 - Summary/Objective
0706 -
070601 - Follow up ref SDS 3 0900,
070602 -
070603 - Gary reports a problem today with the function that "saves" a contact
070604 - record.  Investigation showed that the feature for listing individuals
070605 - separately in organization contact summaries, which is executed with
070606 - the "save" function (F2), exceeded the capacity of the list originally
070607 - allocated. ref SDS 0 HV67  Solution was to change the location of the
070608 - stack to increase the number of alternate listings from 12 to 50.
070609 - ref SDS 0 YH4F
070611 -  ..
070612 - Submitted email to Gary notifying of correction, and that updated code
070613 - and SDS records, including this record explaining what was done, can
070614 - be downloaded from the Internet to supplement the SDS program transfer
070615 - on 030408. ref SDS 4 NE6M
070616 -
070617 -     Made note of review and our telecon last night on a few format
070618 -     issues using SDS. ref SDS 5 RP9L
070619 -
070620 -
070621 -
070622 -
070624 -  ..
0707 -
0708 -
0709 - Problem
0710 -
071001 - Gary called and said the Aerospace company contact record crashed when he tried
071002 - to add another name and then save it.
071004 -  ..
071005 - We did some work online together.
071007 -  ..
071008 - When F2 is used in the Aerospace company contact record, the record process
071009 - counter runs, which updates the diagnostics and saves the record, but
071010 - the save op does not restore the screen and the alphabetical listing
071011 - loses entries for the record.
071012 -
071013 -
071014 -
071016 -  ..
0711 -
0712 -
0713 - Progress
0714 -
071401 - 0705051  F2 Save Contact Record
071402 - 0705051  Provide multiple alphabetical listings for Contacts
071403 -
071404 - Follow up ref SDS 3 0900, ref SDS 2 4Y7M.
071405 -
071406 - On 910317 general discussion of system. ref SDS 1 0001
071408 -  ..
071409 - I think the problem might be a memory issue arising from the multiple
071410 - listings we are using for Aerospace company.  On 980601 developed feature for
071411 - alternate listings in the alphabetical lists. ref SDS 3 5376  This
071412 - seems to be what is failing.  After talking to Gary, I opened the same
071413 - record using the numerical listing, which is constructed each pass,
071414 - and so always lists something.  I deleted the multiple listings.  Then
071415 - verified the structure is the same as for the same record on the
071416 - notebook computer, c12.  The record on c12 saves correctly.  Got the
071417 - record to save also on c13.
071419 -  ..
071420 - Read back the record with the alternate name listings and tried F2.
071422 -  ..
071423 - This save correctly.
071425 -  ..
071426 - Tried F2 again, and it crashed.
071428 -  ..
071429 - This suggests that a memory problem may occur from multiple passes, or
071430 - that something is amiss when the code replaces multiple listings, but
071431 - it works on the first pass when the multiple listings are created on
071432 - the first pass.
071433 -
071435 -  ..
071436 - Line 40, ref OF 1 3340, -label lpsnl in 0705051
071438 -  ..
071439 - Line 290, ref OF 1 5623, -label lpa in 0705051
071440 -
071441 -    This is the loop that gets each user identified with an asterisk
071442 -    for display in the alphabetical summary under the primary
071443 -    organization name.
071445 -  ..
071446 - Line 670, ref OF 1 2284, -label dKaAaz in 0705051
071447 -
071448 -    After names of contacts to be listed for an organization in an
071449 -    alphabetical summary are extracted, update the alphabetical summary
071450 -    files.
071452 -  ..
071453 - Line 690, ref OF 1 9T4M, -label macsl2 in 0705051
071454 -
071455 -    Repetitive dates process.
071457 -  ..
071458 - Line 770, ref OF 1 UY7N, -label tjF
071459 -
071460 -    Repetitive dates process over,
071461 -
071462 -    There is a note here that says...
071463 -
071464 -         Get value for alphabetical Summary file
071466 -          ..
071467 -         These values are captured in 000009 under -entry 1808 that
071468 -         opens a record and they are stored in counters 161+
071470 -          ..
071471 -         Counter 172 is set to 160 at the beginning of this 0705051 op
071472 -
071474 -  ..
071475 - Line 800, ref OF 1 V44N, -label jmpv3 in 0705051
071476 -
071477 -    Open 0705051 processor and load params to update alphabetical
071478 -    summary files.
071479 -
071480 -    This is where the thing crashes.
071482 -     ..
071483 -    The problem is that the code is creating a stack in memory using
071484 -    counters 160+, per above, that save the file id correlated to the
071485 -    alphabetical summary lists 1 - 26.  So, for example if there are 8
071486 -    alternate listings, then, if, say, the first one begins with the
071487 -    letter C, counter 161 will have the value 3, and counter 168 will
071488 -    have counter 5 if the 8th alternate listing begins with letter E,
071489 -    and so forth.
071491 -     ..
071492 -    In this case, there 14 or 15 alternate listings, which is something
071493 -    we have never done before.  We have tested the code for 3 or 4
071494 -    alternate listings, typically, they are different ways of thinking
071495 -    of the organization, and not the names of individuals in the
071496 -    organization, since they are listed under the primary heading.  But
071497 -    in this case, we decided to be fancy.  So, it turns out that
071498 -    counter 172 is used elsewhere in the code as a processing element,
071499 -    so when the stack gets to this level, it crashes the party.
071501 -     ..
071502 -    The solution is to change the code for macro 1808 in 000009 to
071503 -    start the stack from counter 161 to counter 231, since counters
071504 -    above 220 are not assigned to this operation.
071505 -
071507 -  ..
071508 - Line 40, ref OF 1 YG5H, in 0705051
071509 -
071510 -    setcnt 172 230
071511 -
071512 -        Per above, changed this from setcnt 172 160, ref SDS 0 HV67, so
071513 -        that counter 172 will increment values beginning at counter
071514 -        230, which is also changed today in macro 1808 in 000009.
071516 -         ..
071517 -        Counter 230 is clear until about counter 270.  This expands the
071518 -        number of people in a contact record that can listed for
071519 -        individual lookup in a contact record from 10 to 40.  Since
071520 -        these are globals, when the number exceeds 40, counter 271 is
071521 -        affected which is where the SDS user ID is stored.
071522 -
071524 -  ..
071525 - Line 4110, ref OF 2 5L6J, -label modrec in 000009
071526 -
071527 -    setcnt 2 231
071528 -
071529 -        Change this from setcnt 2 161, per above. ref SDS 0 YH4F
071530 -
071531 -
071533 -  ..
071534 - Line 2420, ref OF 2 5040, -label mnLtrd in 000009 about 110 lines
071535 - below.
071536 -
071537 -    z 10 20
071538 -    fr /Title/
071539 -    -if @0 = 0 -if @47 = 1 -goto aQd1
071540 -
071541 -        Code has entered the contact person's name, and has looked for
071542 -        a title.  This last line was failing because counter 47 lost
071543 -        the assigment to the profile level, in this case 1.
071544 -
071546 -  ..
071547 - Line 1480, ref OF 2 S29F, -label edlA in 000009 about 50 lines below
071548 -
071549 -    loc_cur 3 4
071550 -      -if @74 > 32 loc_cur 0 6
071551 -    strcnt 103 1
071552 -    -if @74 = 32 -if @103 = 4 -goto suefA
071553 -      -if @103 = 0 -goto suefA
071555 -        ..
071556 -       This code was causing the problem with the counter 47 getting
071557 -       messed up.  It is only legacy support for the prior format of
071558 -       putting the address on a 4 place number based on "0103" being
071559 -       the end of the date field.   This has been changed, but today we
071560 -       caught up in a situation with the cursor on a number "0000103"
071561 -       and this was read as the end of the date field, and so caused
071562 -       double processing of this line to caputre the state and zip
071563 -       field, and it started the counter at the end of the prior string
071564 -       which was counter 47.
071566 -        ..
071567 -       We should bite the bullet and change the old contact foramts
071568 -       over, then we can eliminate the legacy code and pick up some
071569 -       compiler space.
071570 -
071571 -
071572 -
071573 -
071574 -
071575 -
071576 -
071577 -
071578 -
071579 -
071580 -
071581 -
071582 -
071583 -
0716 -