IBM Mainframe Forum

Hi, greetings to all,

I'm new on this forum (basically my first post ever on any professional forum).
Anyway, lets get to it and i'm hoping that someone might be able to help.

This is my 5th week of learning COBOL. I'm using a NetExpress IDE (I know this forum is for mainframe help so not sure if this disqualifies me but we have not yet gotten to "that part" of the course).

Basically i'm writing a game which should:

A) Generate 4 random numbers between 1 and 10 (without duplicates).
B) The user/player should then guess what these numbers are.
C) If the user has all his digits in the correct spots it's a match.(whenever a match is found , the game should display BBBB)
D) If the user guessed the correct digits but not in the correct spot (the game should display them a "C" for "change" in that particular spot)
E) when wrong display an X.
ex. random computer generated num = 4510
user entered num = 7120
computer display = XCXB

The user gets five tries.

Okay that's what is required.
So far im able to generate random numbers , with a different sequence every time the program is run.
I store those numbers in an array. I accept the users numbers I store them in a separate array. and then I have another "display" array that will be giving the clues.
I know I have to use IF's to compare the arrays , but don't really want to "check" these arrays 1 by 1.(it seems so tacky).
So I want to use a mixture of IF's and perform varying loops.

All i'm looking for is some advice on how I can tackle my problem.
TIA.

Kind of disqualifies you... but if you are getting onto Mainframes soon

Well, there's the Computer Science approach to a project. Chose the current fashionable languages (and frameworks, and all the other five "technologies" you'll likely need) and Immediately start looking for libraries, or instructions which happen to do exactly what you want. Slap some code together. Run it. Fix-up the places in the code which seem to cause the errors, then fix-up the next iteration which has occurred from the latest code (there will be fewer problems each time, so it'll only likely take four or five iterations of this process). Remember, if there are things you can't fix, give some thought to calling them "edge cases" or even "corner cases". If you can do that successfully, you don't need to bother about it.

There you go, job done. By this time, you'll wish never to see that code again, and you probably won't need to, and no-one but you marker will ever have to look at it, and no-one will ever have to change it. After a few weeks, it'll never even be run again.

OK, can't go that route because you are forced to do it in tacky old COBOL. Since you can't go the CS route - abandon everything associated with that.

What that means is, you design the program before wondering how to write the actual code. Use pseudo-code to set out how you think the processes will work. The great thing about pseudo-code is that you can write anything you like. And then, with your specification, you go through the code to make sure you are doing everything in the specification and doing everything correctly.

You can start at a high level, and once happy with that, get a bit lower. Once you are happy with the pseudo-code, then you start to think about writing the COBOL.

If, when testing your program, you find you missed something in the design, don't just patch it up, but step back to the design and fix that.

You'll end up with a program you are happy with, that you don't mind people looking at, that other people will be able to change, and which could happily be used for 20 years.

OK, don't expect it all at once, but you'll get there much quicker this way

but don't really want to "check" these arrays 1 by 1.(it seems so tacky).

pretty inconsiderate remark ...

remember that for personal use You can write code of any complexity You like

when working You will be forced to write code

easily understandable
easily mantainable

and most probably tacky

if You feel that writing tacky code is not up to Your expectations You should consider a career shift

Thanks for your reply Billy.
I agree with almost everything you said. Just need to remind myself every now and then that eloquent coding does not mean "short and sweet" and that a "structured well defined" program is always better.
Since posting , I've done a few Nassi-Schneiderman charts and have most of the "outer control" sorted. I've opted to test the user-input 1 by 1 against all the elements in the random number/game array.

Still "breaks" at times so don't think I have thought of all scenarios as yet (back to the drawing board).

enrico-sorichetti wrote:

but don't really want to "check" these arrays 1 by 1.(it seems so tacky).

pretty inconsiderate remark ...

remember that for personal use You can write code of any complexity You like

when working You will be forced to write code

easily understandable
easily mantainable

and most probably tacky

if You feel that writing tacky code is not up to Your expectations You should consider a career shift

Noted, just thought there might have been a better way of doing it.

Nassi-Schneiderman charts

probably are the reason that Your neurons got obfuscated,
never use complicated tools/techniques just because the name is fashionable

two DO loops, two IFs and one ELSE
is all You need to do the check