The method was encouraged at the shop where I worked. It only generates one 6 byte MVC instruction to get the table initialized. I worked with IBM COBOL and never had a problem with this method in 35 years that I programmed. The only thing I saw in recent compiler versions was a warning...
You may want to look at this a little closer webrabbit.
At the beginning ....
If A-KEY < B-KEY
If A-KEY < c-KEY
If A-KEY < D-KEY
Merge-A
Else
Merge-D
End-If
You're making a big assumption in the ELSE. You don't know how D-KEY relates to B-KEY and...
You have an ASCENDING KEY clause in your table definition. The key that you are using must be defined as one of the table elements. I don't see WT-CDFILIAC defined in the table anywhere. I assume you really want WT-CODE to be the key.
Also, if you are using the SEARCH ALL, you must be sure...
I assume when you want to use the length of field A you actually mean how many characters of field A are being used - not the length as defined in the PIC clause.
You need to set up a loop to calculate the number of characters being used in field A. You could start at pos 1 of field A and add...
You cannot use 9999.99 as the PIC. That is still an edited numeric field with a decimal point. You need an implied decimal point such as 9999V99. You cannot use a REDEFINES and expect it to work correctly all the time. If you have a field defined as ZZZZVZZ and you move a numeric value to...
Can't you do a little debugging to see how your switch is being reset if in fact it is. Seems to me when you reenter the program, if the open switch is off you'll try to open the file again. Should get an error unless you closed it when you left the time before.
Why not display the value of...
You never said if this is a subprogram. The INITIAL clause only applies to a subprogram. If you're dealing with a main program, there is some sort of logic error that is causing your switch to be reset.
If I recall correctly, INIT goes on the
PROGRAM-ID. prog-name INITIAL.
I think it only applies to sub-programs. It indicates that each time the program is called, it will be rest to its initial state which resets all VALUE clauses.
How about something like the following?
It doesn't look like you really need to know how long the field is because when you move a shorter field to a longer one it pads the receiving field with spaces. How about if we first left justify the WORK-FIELD to get rid of leading spaces? Doesn't...
You can't MOVE an INDEX, but you can use the SET statement. Define a numeric field (it can be zoned decimal or packed). Use the SET statement this way:
SET num-field TO index-field
This will convert the index value to a numeric value.
pacc-street-name will end up with one word only with the way you have coded the second UNSTRING. Is that what you want?
In your samples, "952A north land" will have "north" in pacc-street-name. Wouldn't you want "north land"? If so, Jack's second UNSTRING or MOVE would do the trick.
As far as I remember, when we converted to Enterprise COBOL, we did not have any changes for writing report lines. The code worked fine when recompiled. I'm guessing there has to be something unorthodox happening in the code when you try to get the line printed. In other words, a logic error.
You have reserved the first byte for carriage control. That's what the FILLER of 1 byte is for. If the code moves the filled out report line to the 01 entry (FLR-VOTES-UPDT-REPORT), then the first byte is in the FILLER and is used as a carriage control character.
You should move the filled...
Try what Glenn9999 said but be sure to increment the index before you search the next time. If you leave the index where the last hit was, you'll find a match at that entry again.
The key here is what papadi and Tom have said. THe internal SORT is not restricted to having a sort file that matches either an input or output file in layout.
You can define the SORT file to be any group of data fields you like. Then in the input PROCEDURE, you create each of those records...
While the COBOL SORT may not be designed to sort a WS table, you could make it work. Create an INPUT PROCEDURE to cycle thru the table and RELEASE a record to the SORT. The OUTPUT PROCEDURE could clear out the table and then RETURN the sorted records and fill the table in sequence.
One other thing you should be aware of. In IBM mainframe, you cannot validly reference the FD after AT END has been reached. You have an 88 condition you are setting when AT END is reached and you are also using that in your PERFORM UNTIL. The IBM manual says the results are unpredictable...
Jack:
Your 01 level entry "UNPRTS" cannot use the THRU option of the VALUE clause. That's only allowed on an 88 level entry. You need to list all of the values that you want the 01 to contain. Example:
VALUE X'010203040506...'
It could get rather long.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.