My reqt is as follows:
In the Description field, if the state code or state name comes, change the wordings as RESIDING STATE =<state code>
Eg: If Desc field has values like
RESIDING IN MISSOURI
RESIDING: LOS ANGELES, CA
RESIDING IN NORTH DAKOTA
RESIDING: KANSAS CITY
RESIDENT FLORIDA, FL
RESIDENT OF TAMPA
I need to have the formatted output field as
RESIDENT OF TAMPA (No formatting necessary since State code or state name is not there)
1. With INSPECT, I will find any occurance of 'RESID' and if YES, then extract that value to be formatted.
2. I had COBOL internal table which has State ID and State Name stored
3. UNSTRING Desc field delimitted by ' ,' and then compare the extracted field after ' ,' with COBOL internal table which will handle case (2) and (5).
However I am not sure how to handle Case(3) and Case (4). Because if I am using UNSTRING delimited by 'RESIDING IN', it will do good for NORTH DAKOTA but can't handle KANSAS
Is there any other better approach for this requirement or this is the only way that can be modified?
Thanks Dick for the reply.
Sorry.I mean DELIMITED BY ', ' to handle Case (2) and (5).
The State Code or State Name can come in any way
Eg: RESIDENT OF WA
RESIDING IN WA
RESIDENT OF NEW YORK IN LOC
RESIDING IN LOC# 234 IN NJ
The DELIMITED BY 'RESIDING IN' or 'RESIDING:' will handle some cases.
Thanks for that.
The other way that I thought is like puting INSPECT for all the 50 states in US (around searching for occurance of State ID or State name for each INSPECT and if Count is greater than 0, will hardcode
RESIDING STATE=<corresponding State ID>
So 50 INSPECT will come...sounds bad logic, right.
Joined: 20 Oct 2006 Posts: 6968 Location: porcelain throne
INSPECT is one of those really powerful instructions/commands,
but it comes at a price - performance.
If I was doing this I would start by:
WHEN DESCRIPTIONFIELD(1:11) = 'RESIDING IN'
WHEN DESCRIPTIONFIELD(1:11) = 'RESIDENT OF'
WHEN DESCRIPTIONFIELD(1:09) = 'RESIDING:'
generic routines have less code,
but burn up a lot of cycles schlepping thru finding things.
using the evaluate, each performed paragraph knows exactly where things are (position, length) and can parse exactly what you need.
obviously, paragraph D400-HAVE-NOT-FIGURED-IT-OUT is where
you could code your UNSTRINGS, etc..
If enough of your expected input is handled by one of the earlier performs, then D400 handles exceptions.
should improve your thru-put.
if you get caught in a situation where you need to determine
if your 'state' variable is 'translatable', I would use a LEVEL 88,
unless your table is setup for a Binary Search.
reference modification with variables [field(var1:var2)] is slow,
compiler generates code to substitute, convert, etc..
reference modification with literal values [field(1:8)] is fast as lighting,
compiler generates a direct instruction as if you had assigned a field in working-storage.
If I am able to extract the State ID or State name from the line regardless of where it is occuring, I can compare that with the hardcoded COBOL internal table (having State ID mapped with State name).
If it is matching, I will write RESIDING STATE=<State ID>.
The above example that you have posted tells me whether the line starts with RESIDING IN or RESIDENT: or ... and what you had told is the real problem for me (extracting the State ID or State name).
I am thinking around this
INSPECT WS-DESC TALLYING Z-COUNT FOR ALL 'NEW YORK' OR 'NY'
IF Z-COUNT > 0
MOVE 'RESIDING STATE=' TO WS-DESC(1:15)
MOVE 'NY' TO WS-DESC(16:2)
The problem here is that it is NOT a generalized code for all states. If this can be generalized for all states, I dont have to worry about the position of State ID or State name.