Page 2 of 4

Re: 2-file match/merge sample code

PostPosted: Thu Apr 01, 2010 9:11 am
by dick scherrer
Hi Chuck,

Very good catch :)

I got too frisky with this version of the code when stripping out all but the match/merge logic :oops:

A "real" implementation should surely abend/terminate with a proper message if either file is out of sequence. . .

Re: 2-file match/merge sample code

PostPosted: Wed Jun 30, 2010 8:03 pm
by amdamar@gmail.com
how to see attached file

Re: 2-file match/merge sample code

PostPosted: Wed Jun 30, 2010 10:56 pm
by dick scherrer
Hello and welcome to the forum,

Right-click SaveTargetAs onto your pc. Then upload to the mainframe.

Re: 2-file match/merge sample code

PostPosted: Fri Sep 10, 2010 9:06 pm
by thulasi ram
what is the difference between files and db2

i need real time answers

Re: 2-file match/merge sample code

PostPosted: Fri Sep 10, 2010 9:18 pm
by Robert Sample
And your post is related to the subject topic how?

Asking for real time answers on a forum is not likely to get you much response. Forums don't do fast and they definitely don't do real time.

And you need to clarify your question -- what are you looking for? Things like files have records and DB2 has rows? Physical differences? Programmatic differences? Philosophical differences? Sequential files? Indexed files? Direct access files? Tape files? etc, etc, etc

Re: 2-file match/merge sample code

PostPosted: Fri Sep 10, 2010 9:54 pm
by dick scherrer
Hello and welcome to the forum,

I'm sure you have something you want to receive information about. . .

From your question, we don't really know what you are asking. You believe your question is clear, but it is extremely vague. If you can re-word your question, we can probably provide some info.

As Robert mentioned - we don't do "real time" (or urgent, or fast, etc).

Why did you believe your question had anything to do with a "match/merge"?

Re: 2-file match/merge sample code

PostPosted: Thu Nov 04, 2010 5:30 am
by mickeywhite
I agree about the GOTO statement. We do not use perform thru exit, so we do not need GO TO . Also we do period less programs. I did not like it at first, but it makes you structure your code much better without all the periods. also use the scope terminators.

Re: 2-file match/merge sample code

PostPosted: Thu Nov 04, 2010 10:55 am
by enrico-sorichetti
A larger issue for me is that the program does NOT appear to do SEQUENCE CHECKING on the two input files.


the larger issue is people understanding the objective of the snippets posted here

the code snippets posted here are not meant to be a full solution to somebody' s problem
they intend to show a specific aspect of the problem

the two file match was intended to show only the compare logic, what file read after a compare, how to manage files with different record count
and clearly states that for it to work asis the files should be sorted

Re: 2-file match/merge sample code

PostPosted: Wed Dec 29, 2010 11:03 pm
by DOS/VS COBOL Guy
Hi, Dick! :)

What version of COBOL is this? It looks like it would run on my DOS/VS system with only a minimum of modification needed e.g. in the ASSIGN clause of the SELECT statemsnts I would have to change e.g. the SYSTEM-NAME for COMP-CAP to something like SYS010-UT-2400-S-CAP. for a labeled tape file, which I saaume this is.

I am not going to debate the merits of GO TO-less programming, but I employ a hierarchal structure (an 0000-MAINLINE, 1000-HOUSEKEEPING, 2000-PROCESS, 3000-EOJ, ect. plus the EXIT paragraphs). I think it makes the program easier to read and follow, but that's me...

Re: 2-file match/merge sample code

PostPosted: Thu Dec 30, 2010 3:39 am
by dick scherrer
Hello,

It looks like it would run on my DOS/VS system with only a minimum of modification needed

This code once ran on several 360/40 machines as well as some Burroughs 3500/5500 machines. On the 360, it ran on the pre-VSE DOS.

I've been dragging it around for 40 years. . .

The biggest reason most of the things i post are not goto-less was due to performance (once was involved with performance measurement and we made the discovery that the 70's interpretation of structures would eat entire 370's). If the entire program runs in nested performs, the paging inflicted on the old systems was worse than the i/o to run the job.

What i've been able to influence in several organizations is the concept that "structured code" need not be "goto-less". Properly used goto's are not a problem for readability/maintenance. Actually, the very worst case of spaghetti code was in a quite large goto-less program that employed many, many switches to keep track of "where it was" at the moment.

One thing i'd fall on my sword over today is that the local standards be followed :)
As i've been a migrant data worker (consultant/contractor) since '78 i have seen many sets of standards and most are not the same. . .

Otherwise, i believe that all code has 3 requirements:
1. works right every time.
2. uses a reasonable amount of resource.
3. is easily maintainable.

d