Is there a maximum size for working storage? 5

[slb0423]

We just ran into a problem where it seems that working storage section is too big, causing strange abends. Can someone tell me what the max size for working storage is? Is this a setting we can modify on our system? Thanks in advance.

 

[3gm]

Tom:

Thanks for the note about the length. I thought the limitation was just on file record length, not WORKING-STORAGE items.

As for not meeting Elvis' needs, I didn't look too closely at your algorithm. It didn't seem to extract all possible subsets (the statement "move name-field (K to name-key" would not seem to allow for subsets that didn't include the last letter).

The approach you and Devesh have outlined is a good one. I am concerned about the size of the cross reference file. The ratio of cross-reference records to a base record is n(n-1)/2 where n is the length of the name. With long "names", the actual number of cross-reference records might grow to be unworkable. With short names, I'm sure it's just fine. It's also very dependent on the vendor's implementation of indexed files with alternate keys.

Glenn

 

[SiouxCityElvis]

Thanks Glenn, Tom and Devesh.
I think that separate job of looking at all the names in my 5000 file and writing out all the possible combinations to another Dynamic Indexed file storing those different string combinations(minimum 2 bytes in length on string length) will work.

I'll give that a shot using Tom and Devesh's examples.
Thanks experts.
-Amarillo

 

[SiouxCityElvis]

Glenn:

I can use alternate keys. but on the old version of RMCOBOL 85 I'm on I cannot use Duplicates for my primary keys. For some reason it lets me use Duplicates on my alternate keys though.

-AmarilloElvis

 

[k5tm]

Glenn:



First, WRT length limitation, this is not a limit on WORKING-STORAGE, but rather on what you can do to a group level item and/or elementary items that exceed 65280 (a curious number determined by me to achieve certain performance goals on the 8086 architecture!). INSPECT is not among the thangs that can be done.

Okay...that out of the way...

My algorithm has an error that I found whilst doing an example! Change

       move name-field (K:) to name-key

to

       move a-word (K:) to name-key

Here is a working example:

identification division.
program-id.  wordxref.
data division.
working-storage section.
01  name-field  pic x(100).
01  a-word      pic x(50).
01  I           pic 9(5) BINARY.
01  J           pic 9(5) BINARY.
01  K           pic 9(5) BINARY.

procedure division.
a.
    move "JONATHAN" to name-field.
    perform xref.
    move "NATHANIEL" to name-field.
    perform xref.
    move "JOHN JON ANDERSAN" to name-field.
    perform xref.
    stop run.

xref.
    move 1 to I
    perform until I > 100
        unstring NAME-FIELD delimited by all spaces
            into a-word count in J
            pointer I
        end-unstring
        if J > 1
            subtract 1 from J
            perform varying K from 1 by 1 until K > J
                display a-word (K:)
            end-perform
        end-if
     end-perform.

Here is the output:

JONATHAN
ONATHAN
NATHAN
ATHAN  
THAN  
HAN  
AN  
NATHANIEL 
ATHANIEL 
THANIEL 
HANIEL 
ANIEL 
NIEL 
IEL 
EL 
JOHN      
OHN      
HN      
JON       
ON       
ANDERSAN  
NDERSAN  
DERSAN  
ERSAN  
RSAN  
SAN  
AN

It stops with two character names, due to Amarillo's previous input.

Now, regarding the vendor's implementation of indexed files, alternate keys. RM/COBOL compresses both keys and data. Key compression includes both trailing spaces and duplicate characters at the beginning of the key value. In a case that has a lot of duplicates, and near duplicates that begin with identical strings, key compression is very good.

P.S. Amarillo, sure wish you had email notification turned on. I hope you find this correction!

Tom Morrison

 

[deveshjogal]

AmarilloElvis:

I am not sure if any of the COBOL version/dialets allows duplicate on primary keys. But alternate keys always allow duplicates.

Would definately like to know about the turnaround time if u implement the solution


Devesh

 

[k5tm]

Devesh:

Duplicate primary keys are fairly widespread among the "nonproprietary" COBOL vendors, and are useful for some situations, including this one that has no use for the unique key in the xref file.

For applications that require unique record identification (which probably includes most applications) duplicate primary keys are not typical.

Tom Morrison

 

[3gm]

I believe alternate keys have always(?) allowed duplicates.

Tom -

I still don't think your example meets Amarillo's needs. E.g. Shouldn't Nathaniel create a record for Nathan?

Here's what I think is needed:

         if J > 1                        
             subtract 1 from J
             perform varying K from 1 by 1 until K > J
                 perform varying L from 2 by 1 until L > J + 2 - K
                     display a-word (K:L)
                 end-perform
             end-perform
         end-if
      end-perform.
[\code]

Glenn

 

[k5tm]

Glenn:

No! That is the beauty/utility of the SIZE clause on the START verb, and reference modification.

To review:

MOVE INPUT-STRING(1:CTR-1) TO NAME-KEY.
START xref-file KEY = NAME-KEY SIZE CTR-1
   INVALID KEY 
      display "name does not exist"
END-START

The START, constrained by SIZE derived from the name or name fragment being sought, rather than the entire length of NAME-KEY, positions to the first record in xref that begins with that name. As a side benefit, INVALID KEY will immediately inform you if no record exists that meets the = condition, which implies that the name being sought exists in no record.

Tom Morrison

 

[deveshjogal]

What Tom is saying really make sense. When 2 unequal size data items are compared in SATRT clause the longer item gets truncated towards right size. So there is no need to add Jon when Jonathan is there.

Thats really good because it will reduce the lookup file size considerably. (may be average 50 records in new file per record)

Here is a * for Tom

Devesh

 

[SiouxCityElvis]

Thanks, Tom and others.

I will implement that correction. Am working on it now. Had to kill the job.
-Elvis

 

[SiouxCityElvis]

Tom,

It was running until I made changes to my ctrs being BINARY and I am getting an execution error for the line:

MOVE A-WORD(CTR-K TO NAME-KEY.

It was running w/out any errors (who knows how long it would've ran for all 5000 records) for 10 minutes before I killed it. This was when it was MOVE NAME-FIELD(CTR-K TO NAME-KEY.

I'm getting "107" error which in my manual states:
"E Input CD entry has wrong format. The indicated item is incrrect in syntax in the context of Format 1 of the communication description entry in the source program.

I might go ahead and change my CTR-K and other ctrs back to PIC 9(4) and see if that has any good results. I can't figure out why I would be getting that error.

BTW, does NAME-FIELD(CTR-K mean NAME-FIELD(value of CTR-K for position:???????), what does the empty parameter after ":" mean?

Elvis

 

[k5tm]

107 is illegal refernce modification. See Appendix A of the RM/COBOL User's Guide. You are managing to get a value in CTR-K which is either less than 1 or greater than the length of NAME-FIELD. (BINARY vs nonbinary is really false economy in this case, since you will spend far more time waiting for the disk to position the read/write head).

Tom Morrison

 

[SiouxCityElvis]

Tom,
"duh" on my part. Foolish of me.

My equivalent variable I'm using for NAME-FIELD IS PIC X(200). So, my A-WORD should've been 200 instead of 100.
Program running again.

I have a feeling it's going to be a long while.

Thanks. I'll keep you posted on results as soon as I receive them.
You guys have been a great help.
-Amarillo

 

[k5tm]

You might improve performance using:

OPEN OUTPUT XREF-FILE WITH LOCK

which will obviate the need for the file system to keep updating disk structures to allow the xref file to be shared while it is being populated.

Tom Morrison

 

[SiouxCityElvis]

Alright, Tom, you da man!

Since I wanted to write this out to an XREF indexed file but also a sequential file so I can easily view the results, I ran it as

PEFORM UNTIL I > 200
OR LOOP-CTR > 5

ADD 1 TO LOOP-CTR
....

END-PERFORM

So I could just see the first 5. But, For some reason only my first 3 names are shown.

Anyway, the only problem I'm getting is that for a name like "1 AMARILLO" my results are:

AMARILLO
MARILLO
ARILLO
RILLO
ILLO
LLO
LO

Why wouldn't 1 AMARILLO be the first one? It doesn't act like "1 " is seen in the beginning of my string.

I tried doing an INSPECT DB-NAME-FIELD REPLACING ALL SPACES BY "@" and then running it. In that scenario it takes way longer but does show the "1 AMARILLO". My DB-NAME-FIELDS are derived from various delimited files that I built my 5000 file with my names might be a First Name value, followed by 50 spaces, a Last Name value followed by 100 spaces until the 200 limit.
My DB-NAME-FIELD is PIC X(200), but "1 " in the "1 AMARILLO" DB-NAME-FIELD should still be showing, right?

Thanks.
Elvis

 

[k5tm]

Amarillo,

Previously you wrote: it'll probably be a minimum of 2 characters referring to the size of name (fragments) you would be seeking. Therefore, it makes no sense to clutter the xref file with single character. I would presume, without further input from you, that when I see "1 AMARILLO" I would conclude that there are two words: 1 and AMARILLO. So you have different rules for words -- like words may contain one, but not two, contiguous spaces? What is your rule? This will be reflected in the complexity of the coding of the UNSTRING.

Tom Morrison

 

[3gm]

Tom -

Silly of me. I hadn't considered using the START to handle the substrings that way. Very nice! You get a star from me too!

BTW, the size option on the START is a vendor extension, isn't it? It's not something I've seen before. I would normally have to do a START NOT LESS THAN and a READ to accomplish the same thing.

Glenn

 

[k5tm]

Glenn,

Well I didn't get a star before, just an asterisk. No problem. Thanks for yours.

Yes, a vendor extension (at least IBM doesn't have it and definitely not in the 1985 standard), probably picked up from a minicomputer COBOL dialect, which was the heart of RM's business before UNIX and PC DOS/Windows came along.

Your equivalent is correct, with a possible far-out exception. If you have any characters collating between LOW-VALUES and SPACES in the key field, you would have to initialize the key field to LOW-VALUES, then STRING the partial value into the key field (STRING does not pad with spaces). then START ... NOT LESS THAN.


Tom Morrison

 

[SiouxCityElvis]

Tom,
Sorry about that.
There can be a space or spaces between characters on the input string.

Basically, eventually I'm going to have up to two strings to search for.

So I could use "string 1" and search for that, or
"string 1" and "string 2".
on both strings...
there can be spaces included in the string, such as

"1 AMARILLO" and even multiple spaces between characters.

-AmarilloElvis

 

[k5tm]

AmarilloElvis,

So....

Hmmm....

Well, I can see accommodating single spaces (using you @ substitution), and dealing with an arbitrary number of spaces (as looking up multiple words.

You can also use the xref-file to determine a set of possible records (remember you already have to be concerned about xref finding the same record multiple times), which you then process with your previous method. To do so, you would use the longest word (delimited by spaces) in the input request on the presumption that it would most constrain the set of records to investigate.


Tom Morrison