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.

 

[SiouxCityElvis]

And the way the two strings will work...
"1 AMARILLO" will be the only criteria to match if put on the first input string.

If the user decides to use String 1 "1 AMARILLO" AND string 2 "ELVIS" then both criteria will have to met for a valid match.
The issue here is, that my sources of data for building my 5000 rec file have only 1 field name.

So, records with "1 AMARILLO" and "ELVIS" in them will match. I know this is insane sounding, but these Name fields are populated by very potentially vague data. So, names can be company names and there is no knowledge of when a first name or last name would start and end. The only knowledge is that the name field can have up to 200 alphanumeric chars.

-Amarillo

 

[SiouxCityElvis]

Tom, Glen, and Devesh:

Thanks a lot. It worked!

 

[k5tm]

Amarillo,

Good.

Questions:

What approach did you implement?

How is performance?

Tom Morrison

 

[SiouxCityElvis]

Tom,

The approach to build the extra job step by making an XREF Index File with all possible name strings(2 bytes or greater) did the trick. Yes, it did create a XREF file with over 200K records, but the efforts were worth it.
When I specify an input string at the prompt, less than 1 second later my results come up. Pretty much as soon as I press ENTER the results come up. So, this was definitely a great solution! Beats the heck out of coding an INSPECT while reading through every rec on the 5000 rec index file.
That took 14 seconds - way too long.

Also your suggestion to manipulate the UNSTRING code to get my 1 in "1 AMARILLO" worked.

Next step for me is to research/work with a Named-Pipe tool to connect to the programs written in Java. My application was simply a test to query the name data. The java programmers will actually submitting the queries through a NamedPipe, I'll catch it, and throw them back the results.

They're programming the Java in JDeveloper. They mentioned using SOAP to connect to by COBOL; don't know if that's possible - but I think I've heard of the NamedPipe working with RMCOBOL 85 before.

Thanks again for all the help! You guys rock.
-David

 

[k5tm]

David,

Great!

RM/COBOL does support named pipes -- at least in current versions (I don't have manuals for v5.xx readily available). Look up "named pipes" in the User's Guide index to see if it's in your version.

Regarding SOAP -- please contact me directly for more information. I might have other suggestions depending on the architecture of your application. My email is t.morrison at the domain that should be obvious from my profile information.

Tom Morrison

 

[SiouxCityElvis]

Tom,
I sent an email at t.morrison(domain per your profile).

Thanks.
-David

 

[slade]

Tom did a lot of work on this thread. He deserves this, catch, Tom ~~*.

Jack

 

[SiouxCityElvis]

Tom,

One more thing.

When I type in a string "CIO" I get "NACIO" as a match, but not "NACIONAL".
I think what is happening is that the xref for NACIONAL
has
NACIONAL
NACION
NACIO
NACI
NAC
NA
and I also wrote another block to take care of
NACIONAL
ACIONAL
CIONAL
IONAL
ONAL
NAL
AL
but for some reason when I type in "CIO" it doesn't bring this record up as a valid match. Shouldn't CIONAL yield the record as a match for me per your comment above with reference modification? NAME-KEY SIZE CTR-1 below would take care that right?

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

Thanks.
-David

 

[k5tm]

Slade - Thanks, I appreciate it!

David -

Here are two questions that should lead us to a solution:

1. Are you finding one record that contains CIO, but not this one? If true, then the START is not the problem. Are you using reference modification correctly in the subsequent READ NEXT loop that finds all the records? (My guess is the answer is Yes, or you would have had earlier symptoms.)

2. Are you finding some records that contain CIO, but not this one? Is it possible that NACIONAL is really NACÍONAL, and therefore doesn't match?

Your block that produces:
NACIONAL
NACION
NACIO
NACI
NAC
NA
is not serving the purpose you intend. You need only the block that produces:
NACIONAL
ACIONAL
CIONAL
IONAL
ONAL
NAL
AL

Tom Morrison

 

[SiouxCityElvis]

Tom or Glen or anyone:

I don't think the START XREF-FILE KEY = NAME-KEY SIZE CTR-I
is working on my search program.

I'm doing a search with "CION" as the string input.
I have verified that my XREF-FILE index file has the two following records among many others.
NACIONAL and COMERCIALIZACION are two records in my file.
They are broken down as:
NACIONAL
ACIONAL
CIONAL ===> DOES NOT GET FOUND WITH START STATEMENT ABOVE!
IONAL
ONAL
NAL
AL

COMERCIALIZACION
OMERCIALIZACION
MERCIALIZACION
ERCIALIZACION
RCIALIZACION
CIALIZACION
IALIZACION
ALIZACION
LIZACION
IZACION
ZACION
ACION
CION==> FOUND - NOTICE IT IS EXACT LENGTH/MATCH TO INPUT
ION
ON

Per discussions above between Glenn and Tom, I understand that the START XREF-FILE KEY = NAME-KEY SIZE CTR-I should really find "JON" in "JONATHAN" if "JON" is the input is "JON". But it is not!

code 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

I tried using START XREF-FILE KEY = NAME-KEY(1:CTR-1) but that is invalid syntax.

If you have a chance please submit suggestions.
Thanks.
-David

 

[k5tm]

David,

Is the START statement executing the INVALID KEY clause?

Tom Morrison

 

[SiouxCityElvis]

Tom:
Sorry about that.

I did change my code back so that it only produces the original block:
NACIONAL
ACIONAL
CIONAL ===> DOES NOT GET FOUND WITH START STATEMENT ABOVE!
IONAL
ONAL
NAL
AL

COMERCIALIZACION
OMERCIALIZACION
MERCIALIZACION
ERCIALIZACION
RCIALIZACION
CIALIZACION
IALIZACION
ALIZACION
LIZACION
IZACION
ZACION
ACION
CION==> FOUND - NOTICE IT IS EXACT LENGTH/MATCH TO INPUT
ION
ON
Regarding your 2 questions. I have changed my code back to the original code that produces only records as mentioned right above.NACIONAL, ACIONAL, etc. But as I mentioned, the COMERCIALIZACION produces a CION record - it IS found. NACIONAL produces CIONAL - it is not found in my search.
Regarding the "tilde" or also known as an accent mark, which would be used in the Spanish language, they will not be included as characters in my data. So, the tilde should not be an issue and I have verified that they do not exist in my database.

My start statement block is as follows:

INSPECT INPUT-STRING REPLACING ALL SPACES BY "@".
INSPECT INPUT-STRING TALLYING CTR-I FOR CHARACTERS BEFORE INITIAL "@@@@". -- this is giving a valid count for me.
MOVE INPUT-STRING(1:CTR-I) TO NAME-KEY.
DISPLAY CTR-I LINE 1 POSITION 1.(debugging to verify CTR-I)
DISPLAY NAME-KEY LINE 2 POSITION 1.(again for debugging)
ACCEPT MENU-PROMPT LINE 3 POSITION1.

START XREF-FILE KEY = NAME-KEY SIZE CTR-I
INVALID KEY
DISPLAY "NAME DOES NOT EXIST"
ACCEPT MENU-PROMPT
NOT INVALID KEY
PERFORM PROCESS-ALL-XREF-FILES UNTIL EOF-XREF
END-START

PROCESS-ALL-XREF-FILES.
.....

READ XREF-FILE NEXT RECORD
IF NAME-KEY(1:CTR-I) NOT = INPUT-STRING(1:CTR-I)
MOVE YES TO SW-EOF-XREF
.......
.....

 

[SiouxCityElvis]

Tom,

No, the START statement does not execute the INVALID KEY clause in this example.
I have verified that it will use the INVALID KEY clause when I type in a junk string such as "asljfldsjfl" that won't be found.

Just to let you know. My search string "CION" is finding 70 some odd records, but there are plenty more than that to be found - trust me I researched it.

The example I'm using with NACIONAL and COMERCIALIZACION
finds CION in COMERCIALIZACION but doesn't find CION in CIONAL(which is one of the xref records for NACIONAL).

When I've written out my sequential file version of my xref files to view them, NACIONAL is in the datafile before COMERCIALIZACION. So, my START statement goes beyond NACIONAL and finds COMERCIALIZACION as the first matching record in my query. Forgot to mention that by the way, that my first rec found is COMERCIALIZACION.

-David

 

[k5tm]

David,

Despite how the START statement is coded, the index values in NAME-KEY will be in the correct order and will be presented in that order by the READ...NEXT. In other words, it would be an error if the order of NAME-KEY values was not something like:
CION
CION
CION
CION
CIONA
CIONAL

It is for this reason that the test for match in the READ...NEXT loop must use reference modification to constrain the test to the first four (in this example)characters of the key value.

Tom Morrison

 

[k5tm]

David and I have taken this offline for a few exchanges.

There was a minor logic flaw in the READ...NEXT that was causing some of the valid key values to be skipped. I think David will return here to report, but both of us are on deadline...

Tom Morrison

 

[deveshjogal]

Hey Tom and David

Dont forget to update us on the final solution!!!!

All the Best

Devesh

 

[k5tm]

Devesh,

I'll do a lot for STARS! B-)

Tom Morrison

 

[SiouxCityElvis]

All:

Tom is definitely a person to be thanked. As well as the rest of you that have submitted input on this challenge.

BTW, I'm using "Mark this post as a helpful/expert" in attempt to give Tom a star. Hope I'm doing that properly...

Anyway, the latest challenge was to ensure that I was not getting multiple matches on a name field in the master file while entering one INPUT-STRING.

To outline the an example of a duplicate issue I was having:

1)A master file record with the name field value of
"DAVID DAVENPORT SMITH"
and XREF file records created as
DAVID
AVID
VID
ID
DAVENPORT
AVENPORT
VENPORT
ENPORT
NPORT
PORT
ORT
RT
SMITH
MITH
ITH
TH

2)I would input "DAV" for my INPUT-STRING to fetch record matches.

3)It would result with 2 matches - even though there is really only 1 record with that string "DAV" in it. It would count it 2 times as it appeared in the NAME-FIELD two times and consequently was written to my XREF idx file two times.

4)Tom suggested the following code to prevent this duplicate count in one record...
adding to WS...
01 DUPLICATE-DETECTION-TABLE.
02 FOUND-KEY-VALUE PIC 9(4) OCCURS 5000
INDEXED BY FOUND-IX.
01 PIC X.
88 IS-NEW-KEY VALUE "N" FALSE "O".
...

The following as initializiation of the new WS var at the beginning of my NAME-SRCH subroutine...

MOVE ALL "9" TO DUPLICATE-DETECTION-TABLE

And the following near the top of the 'NOT AT END' leg of the looping READ NEXT(on XREF file)...

SET FOUND-IX to 1.
SEARCH FOUND-KEY-VALUE VARYING FOUND-IX
AT END
SET IS-NEW-KEY TO TRUE
WHEN FOUND-KEY-VALUE (FOUND-IX) =
RECORD-CONTAINING-NAME
SET IS-NEW-KEY TO FALSE
WHEN FOUND-KEY-VALUE (FOUND-IX) = 9999
SET IS-NEW-KEY TO TRUE
MOVE RECORD-CONTAINING-NAME TO FOUND-KEY-VALUE (FOUND-IX)
END-SEARCH.
IF IS-NEW-KEY
and my original code here...........
END-IF
END-READ.

Tom and you all have been very helpful on this. I have learned quite a bit in the process(don't know how much more I can squeeze into my brain)!

Thanks and star to Tom(if I entered the star correctly).
-David

 

[SiouxCityElvis]

Tom and others:

The actual solution to the READ-NEXT part of my search was that I was incorrectly checking for duplicates.
I was doing a check stating:

IF RECORD-CONTAINING-NAME > SAVE-KEY
...continue to count the xref record as a match and populate fields accordingly.

This was adverse to what I was trying to accomplish. As Tom mentioned offline to me:

David,

I think you will find that the logic error is in this:

ELSE
IF RECORD-CONTAINING-NAME > SAVE-KEY

There should be no reason that RECORD-CONTAINING-NAME values will be in ascending order; you are reading the xref-file in order by *word fragment* value, which is not in the order you inserted records. Therefore, this IF statement will 'skip' processing any xref record(s) for which the RECORD-CONTAINING-NAME value is less than the highest value previously established.

Sorry I didn't give you a better explanation of my original problem yesterday. The ELSE IF snippet above was the cause of me not getting all the records I should have been getting to match my INPUT-STRING.

The SEARCH snippet of code was the means to prevent the duplicates within one master record's name field.(that was what I was trying to accomplish originally with the ELSE IF RECORD-CONTAINING-NAME > SAVE-KEY above).

Thanks Tom!
And again, thanks to you others Devesh, Glenn, Jack and anyone else I may have forgotten to mention here.
-David

 

[deveshjogal]

Hey Tom

I suppose everybody benefited from this post. And this time I gave u the deserved star and not just a asterisk.


Devesh