Exiting a Perform Statement 3

[anet]

I am working on a project for college that is supposed to do the following:
take screen input for a payroll record
validate each field
if invalid allow the user to either correct or clear the screen to enter the next record
if valid write the record to a file
when no more records exit

I am having problems exiting my validate loop if the user does not want to correct the error. Here is the short version of what I have done.
PROCEDURE DIVISION.
CREATE-VALID-PAYROLL-FILE.
OPEN OUTPUT PAYROLL-FILE.
PERFORM INPUT-RECORDS UNTIL NO-MORE-RECORDS.
CLOSE PAYROLL-FILE.
STOP RUN. (THIS SECTION WORKS FINE)

INPUT-RECORDS
INITIALIZE PAYROLL-RECORD.
DISPLAY OPENING-SCREEN.
PERFORM VALIDATE-PAYROLL-RECORD.
MOVE ENTER-ANOTHER-MESSAGE TO CONFIRM-MESSAGE.
PERFORM INPUT-SCREEN-CONFIRM.
PERFORM WRITE-VALID-RECORD.
(THE VALIDATE-PAYROLL-RECORD PARAGRAPH CONTAINS A SERIES OF PERFORM STATEMENTS TO CHECK EACH FIELD INDIVIDUALLY I.E. PERFORM VALIDATE SOC-SEC-NUM, ETC. - IF THE VALIDATE PARAGRAPH ENCOUNTERS AN ERROR IT CALLS - PERFORM DISPLAY ERROR)
DISPLAY-ERROR
MOVE 'NO' TO VALID-FIELD-SWITCH.
DISPLAY ERROR-LINE.
ACCEPT ERROR-LINE.
IF QUIT (IF THE USER SAYS NO THEY DON'T WANT TO FIX THE ERROR -- QUIT is an 88 level switch)
PERFORM CLEAR-ERROR (just takes away the message)
MOVE ENTER-ANOTHER-MESSAGE TO CONFIRM-MESSAGE
DISPLAY CONFIRM-SCREEN
ACCEPT CONFIRM-SCREEN
PERFORM INPUT-RECORD (GO BACK TO BEGINNING)
END-IF.
The CONFIRM-SCREEN paragraph just displays "enter another record" and sets the switch accordingly.

This program works as long as all the records are correct or the user chooses to fix the error. However it does not work if the user encounters an error that they don't want to fix. Then the program clears the screen and goes back to the first field, however, it is not actually exiting the loop because when I get to the next correct record the program will display the "enter another" message the same number of times as there were previous errors and also save the valid record the same number of times. So, if the user had three incorrect records the next valid record saves 4 times, once for each error and once for the valid record.

What am I doing wrong. Is there some kind of 'exit perform' construct in COBOL.

Thanks.

 

[StephenJSpiro]

Your problem is in your INPUT-RECORDS paragraph. Your statement PERFORM WRITE-VALID-RECORD is executed even if you do NOT have a valid record. Make it
IF VALID-FIELD-SWITCH IS EQUAL TO 'NO'
PERFORM WRITE-VALID-RECORD.
And remember to clear the VALID-FIELD-SWITCH if it IS a good record!
There is no EXIT PERFORM statement now, but there will be one in the next standard unless I can stop it. It is EXTREMELY non-structured. Structured modules have one entry and one exit. ONLY!

Stephen J Spiro
Member, J4 COBOL Standards Committee
check it out at

http://people.ne.mediaone.net/doncobol/

stephenjspiro@mail.com

 

[slade]

Hi Anet,

You could try this:

Set VALID-FIELD-SWITCH to 'Y'

In the validate pgraph:

VALID-FIELD-SWITCH
IF VALID-FIELD-SWITCH = 'Y'
   PERFORM TEST-1
END-IF
IF VALID-FIELD-SWITCH = 'Y'
   PERFORM TEST-2
END-IF

etc.

In the TEST-x pgraphs, if the test fails, DISPLAY
error msg, set VALID-FIELD-SWITCH to 'N'.

Jack

 

[slade]

Hi Anet,

You could try this:

Set VALID-FIELD-SWITCH to 'Y'
In the validate pgraph:

VALID-FIELD-SWITCH
IF VALID-FIELD-SWITCH = 'Y'
   PERFORM TEST-1
END-IF
IF VALID-FIELD-SWITCH = 'Y'
   PERFORM TEST-2
END-IF
etc.

In the TEST-x pgraphs, if the test fails, DISPLAY
error msg, set VALID-FIELD-SWITCH to 'N'.

Jack

 

[Crox]

Hi,

There is nothing wrong in using a GO TO to the end of a section.

In your case you can define something like:


INPUT-RECORDS SECTION.
INP-01.
.....
GO TO INP-99.

INP-99.
EXIT.

Nothing is wrong with goto's. People suggest often that using a GO TO has anything to do with your design. It doesn't.

If you use - for example - Jackson's way of implementing a Jackson Structured Programming design, you don't use even nested code because you want to have the possibility to stop and restart your program on every position in the source.

Whom would dare to accuse the father of structured programming of creating Espaghetes Bolognese? Not in his programming-kitchen! LOL

Have fun!

 

[StephenJSpiro]

Jackson's idea of structured programming isn't. Calling a snowflake a cat does not give whiskers to the snowflake.


Stephen J Spiro

 

[Crox]

I have the feeling Stephen that you don't know a thing about Jackson Structured Programming. Ever heard of nest-free COBOL, recognition difficulties, program inversion, boundary clashes, ordering clashes, interleaving clashes, etc. etc. ?????

Also the way big companies are used to implement back-tracking? Or error handling, screening, etc. etc.????

Ever heard of Cap Gemini?

Probably not.

Top quality training, also for COBOL.

Most important is that the way you code things has nothing to do with the design. The same story when you look at the assembler source generated by your COBOL compiler. That you doesn't code GO TO's does not mean that the assembler generated by your compiler does not contain JUMPS. In fact nobody feels that the assembler has anything to do with the COBOL source.

Nor has a JSP design anything to do with the low-level implementation in COBOL. Only if you 'think COBOL' ... yeah, probably you are right, but on this side of the ocean we make a real design. The implementation is less important. COBOL is not our favorite documentation tool. We have other tools for that. And we also not start sitting behind the screen and write whatever application has to be written without a design. We at the bigger financial institutes, we cannot afford to make the same mistakes as some companies do by creating software with so many bugs in it.... and every time prefer to release new versions with new features without solving the old problems.... Here we don't like that and also we know the difference between design and code.

Regards,

Crox

 

[BigMag]

Crox,

Exactly.

Last month a progammer said to me "Why should we solve the bugs in the software?" "We can tell the customer not to use some futures or push some buttons."
I looked him in the eyes and... He really meant it!

The real problem is a the shortcomming of the programmer who did not beforehand made a decent design.

In the end, the lack of a good design will also result in higher costs of testing, bugfixing and implementing new functionality.

Greetings,

M.

Nog 3 dagen.
BigMag, The Netherlands.
someone@euronet.nl (no kidding!)

 

[RonaldB]

Crox,

I'm on the same side of the big pond, and i believe even in the same country as you are; i also was trained in structured programming by the same guys (Cap), but i was trained in the GOTO-less version of their implementation VSP (Volmac Structured Programming; the company designing it was originally called Volmac, hence the name). Goes to show that structured programming has nothing to do with using GOTO's or not.

I've read various people on this thread using the term "design"; i wonder in relation to what this was used. I get the feeling there is a confusion going on between the design of a business function that needs to be implemented and the design of the program that is supposed to implement it. Although these can't be separated entirely, they do refer to very different designs, so much is true.

Making a solid design of the business functions to be implemented is unavoidable if you want to be sure a system implements the functions desired by the future user(s), a solid program design will greatly aid in future correction and maintenance.

In the end, it is as shortsighted to state that using GOTO's can't produce structured code, as it is to deny that using them incorporates a real risk of creating spaghetti code. I was tought not to, and prefer not to. To each his own.

Regards,
Ronald.

 

[Crox]

Hi,

In the original VSP they teached a standard loop implemented with GO TO's. It were some big clients whom want them to teach the people writing gotoless programs.

I got from them the VDP and VSP and VSP gotoless course. Later on I studied JSP at RAET and also the standard implementation of it. I was a JSP coach for 3 years. JSP is much more advanced. Using the standard implementation techniques you can implement recursive designs in COBOL (even in OSVS COBOL).

In many applications the VSP approach is ok. When you have to do a lot of screening, the use of a GO TO to jump to the end of some screening section creates much better maintainable source than heavy nested coding or the continous repeat of some condition.

But my clients are always getting what they want. So if they want gotoless it is ok with me and even if they leave it up to me I usually conform me to the local standards. But in some cases it is very difficult to implement a design without go to's. That is the case if you implement a recursive design in COBOL without recursive support from the compiler or in cases that the program has to be called to get the data it has to process. In JSP there is an easy implementation for it, but you use GO TO's then. If you are not allowed to use GO TO's in these cases, the gotoless source is difficult to understand and not so maintainable. Worse if you combine several functions inside one program and you want to manage the processing of those functions at the same time, dynamically changing priorities, I am not sure if I can do this without using goto's like I do now. But fortunately this functionality is not often asked to implement in COBOL without using goto's.

The usage of GO TO's is an old discussion.

I don't like it when people think that the written source is also the design. Not in my head... I usually think in my native language - Dutch - not COBOL...

Regards,

Crox

 

[slade]

Structured code, GOTOless code, etc. I would guess the intent of all of these is to produce readable/maintainable code. If the abandonment of these on some occasion results in r/m code, why not?

I just don't get the zeal of the adherents. I can almost see the uplifted nose and hear the sniff when I read some of those postings.

Jack

 

[RonaldB]

Crox,

the case you mentioned (multiple tests) is a great example where using GOTO's can be a great advantage. However, doesn't this require the use of SECTIONs as well as paragraphs? Although i have seen many examples of such constructs (just look at any source generated by Telon), i personally find them a bit confusing. But, that's just my opinion.

Jack,

it seems that when a discussion starts on programming techniques and habits, nearly every programmer feels he / she has to defend his / her way of it, uplifted nose and sniffs or not. Call it pride... ?

Regards,
Ronald.

 

[Crox]

Hi Ronald,

The way Volmac implements GO TO's is by using sections and paragraphs indeed.

The structure of such sources is that you define sections for the mainline and main routines and paragraphs only to use within the sections. The Volmac deal is conditional jumps forward and - when necessary - unconditional jumps backward but always within a section.

In the standard Jackson code only paragraphs are used unless you use bottom-up components. The standard Jackson code is not ment to use as documentation. Jackon users use a JSP-precompiler in which you will never see any GO TO. The generated source contains lots of them but that source is not ment to be looked at or maintained. People whom don't use a JSP-precompiler develop their own code style. I use Jackson standard code for typical Jackson solutions like inversion or recursion, things like that.

So to answer Jack the source is not always used to look at! JSP users use other documentation or JSP precompiler input.

Regards,

Crox

 

[slade]

Hi Crox,

I guess my sparkling prose blinded you. Believe it or not, I was agreeing w/you. Well, back to my "Writing for Dummies".

Regards, Jack.