Cobol - Selecting common records from two files.

Author

Selecting common records from two files.

ashu

2006-02-22, 3:55 am

Hi,
I have two files. I need to select those records from file 'A'
whose first 10 bytes match the first 10 bytes of file 'B'. Rest of
the layout may be different in files A and B.
I need to prepare a third file which contains these qualified records
from file 'A'.
Anyone have used this functionality, please reply to my id.

thanks

2006-02-22, 7:55 am

In article <1140599370.807157.180590@o13g2000cwo.googlegroups.com>,
ashu <ashutosh_priyadarshi@infosys.com> wrote:
>Hi,
>I have two files. I need to select those records from file 'A'
>whose first 10 bytes match the first 10 bytes of file 'B'.

Please do your own homework.

DD

Howard Brazee

2006-02-22, 6:55 pm

On 22 Feb 2006 01:09:30 -0800, "ashu"
<ashutosh_priyadarshi@infosys.com> wrote:

>I have two files. I need to select those records from file 'A'
>whose first 10 bytes match the first 10 bytes of file 'B'. Rest of
>the layout may be different in files A and B.
>I need to prepare a third file which contains these qualified records
>from file 'A'.

Please show us what you have done so far, and what problems you have
come up against. Include your compiler and operating system in your
post.

>Anyone have used this functionality, please reply to my id.

No thanks. This is a public forum. While it's hard to imagine what
problem you could be having in such an elementary requirement -
someone else might find the same problem and could learn by how it
gets resolved.

James J. Gavan

2006-02-22, 6:55 pm

LX-i

2006-02-22, 9:55 pm

ashu wrote:
> Hi,
> I have two files. I need to select those records from file 'A'
> whose first 10 bytes match the first 10 bytes of file 'B'. Rest of
> the layout may be different in files A and B.
> I need to prepare a third file which contains these qualified records
> from file 'A'.
> Anyone have used this functionality, please reply to my id.

Something like this might work...

IDENTIFICATION DIVISION.
PROGRAM-ID. THIS-IS-HARD.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT MASTER-FILE ASSIGN TO "FILE1.TXT".
SELECT ANOTHER-FILE ASSIGN TO "FILE2.TXT".
SELECT A-THIRD-FILE ASSIGN TO "FILE3.TXT".
DATA DIVISION.
FILE SECTION.
FD MASTER-FILE.
01 MASTER-FILE-RECORD PICTURE IS X(500).
FD ANOTHER-FILE.
01 ANOTHER-FILE-RECORD PICTURE IS X(500).
FD A-THIRD-FILE.
01 A-THIRD-FILE-RECORD PICTURE IS X(500).
WORKING-STORAGE SECTION.
01 MASTER-FILE-RECORD-X VALUE IS SPACES.
02 MASTER-FILE-CHAR OCCURS 500 TIMES
INDEXED BY MASTER-FILE-IDX PICTURE IS X.
01 ANOTHER-FILE-RECORD-X VALUE IS SPACES.
02 ANOTHER-FILE-CHAR OCCURS 500 TIMES
INDEXED BY ANOTHER-FILE-IDX PICTURE IS X.
01 A-THIRD-FILE-RECORD-X VALUE IS SPACES.
02 A-THIRD-FILE-CHAR OCCURS 500 TIMES
INDEXED BY A-THIRD-FILE-IDX PICTURE IS X.
77 FILE-1-EOF-SW PICTURE IS X VALUE IS "N".
88 FILE-1-EOF VALUE IS "Y".
77 FILE-2-EOF-SW PICTURE IS X VALUE IS "N".
88 FILE-2-EOF VALUE IS "Y".
77 RECORDS-MATCH-SW PICTURE IS X VALUE IS "N".
88 RECORDS-DONT-MATCH VALUE IS "N".
88 RECORDS-MATCH VALUE IS "Y".
PROCEDURE DIVISION.
I-DIDNT-WRITE-THIS.
OPEN INPUT MASTER-FILE. OPEN OUTPUT A-THIRD-FILE. PERFORM
UNTIL FILE-1-EOF READ MASTER-FILE NOT AT END MOVE "N" TO
FILE-2-EOF-SW OPEN INPUT ANOTHER-FILE PERFORM UNTIL
FILE-2-EOF READ ANOTHER-FILE NOT AT END MOVE
MASTER-FILE-RECORD TO MASTER-FILE-RECORD-X MOVE
ANOTHER-FILE-RECORD TO ANOTHER-FILE-RECORD-X SET
RECORDS-MATCH TO TRUE PERFORM VARYING MASTER-FILE-IDX FROM
1 BY 1 UNTIL MASTER-FILE-IDX > 10 OR RECORDS-MATCH SET
ANOTHER-FILE-IDX TO MASTER-FILE-IDX IF MASTER-FILE-CHAR
(MASTER-FILE-IDX) IS NOT EQUAL TO ANOTHER-FILE-CHAR
(ANOTHER-FILE-IDX) THEN SET RECORDS-DONT-MATCH TO TRUE
END-IF END-PERFORM IF RECORDS-MATCH THEN MOVE SPACES TO
A-THIRD-FILE-RECORD-X PERFORM VARYING MASTER-FILE-IDX FROM
1 BY 1 UNTIL MASTER-FILE-IDX > 500 SET A-THIRD-FILE-IDX TO
MASTER-FILE-IDX MOVE MASTER-FILE-CHAR (MASTER-FILE-IDX) TO
A-THIRD-FILE-CHAR (A-THIRD-FILE-IDX) END-PERFORM MOVE
A-THIRD-FILE-RECORD-X TO A-THIRD-FILE-RECORD WRITE
A-THIRD-FILE-RECORD SET FILE-2-EOF TO TRUE END-IF AT END
SET FILE-2-EOF TO TRUE END-READ END-PERFORM CLOSE
ANOTHER-FILE AT END SET FILE-1-EOF TO TRUE END-READ
END-PERFORM. CLOSE MASTER-FILE. CLOSE A-THIRD-FILE. STOP
RUN.

Once you turn in the assignment, post what you turned in. I'll have a
different version of this program that is written the way I'd write it
for my job that I'll post - probably in a couple of w

s.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

PradeepR

2006-02-23, 7:55 am

>I have two files. I need to select those records from file 'A'
>whose first 10 bytes match the first 10 bytes of file 'B'.

This seems to be a beginner kind of question. I suppose this is the
first time you are working on a COBOL program. Here is the algorithm,
hope you can work out the syntax
for doing it.

A-Section.
A-010.
Start on File A

A-020.
Read next on File A
Start on File B

A-030.
Read next on File B
If EOF, go to A020.
If First 10 bytes of A = First 10 bytes of B
Write C (Third file)
go to A-020
Endif
Go to A-030.

A-999
Exit.

This is my understanding, may be others can come out with better
solution.

PNR

docdwarf@panix.com wrote:
> In article <1140599370.807157.180590@o13g2000cwo.googlegroups.com>,
> ashu <ashutosh_priyadarshi@infosys.com> wrote:
>
> Please do your own homework.
>
> DD

Pete Dashwood

2006-02-23, 7:55 am

Well done, Jimmy!

This is sound advice and an imaginative solution.

Pete.
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:e_4Lf.62637$B94.47236@pd7tw3no...
> ashu wrote:
> You could be just dead lazy. I'll give you the benefit of the doubt and
> assume, new to programming you have hit a BLANK !
>
> Work out the logic for yourself with a pack of playing cards. Take a pack
> and just use Hearts and Spades. Shuffle them and put them into two decks,
> (Files A and B). Let your 10 bytes be the card identifier, either Hearts
> or Spades. Cards face down, now figure out manually what your moves are as
> you pick each one up and check what it is.
>
> Jimmy, Calgary AB

HeyBub

2006-02-23, 6:55 pm

PradeepR wrote:
>
> This seems to be a beginner kind of question. I suppose this is the
> first time you are working on a COBOL program. Here is the algorithm,
> hope you can work out the syntax
> for doing it.
>
> A-Section.
> A-010.
> Start on File A
>
> A-020.
> Read next on File A
> Start on File B
>
> A-030.
> Read next on File B
> If EOF, go to A020.
> If First 10 bytes of A = First 10 bytes of B
> Write C (Third file)
> go to A-020
> Endif
> Go to A-030.
>
> A-999
> Exit.
>
> This is my understanding, may be others can come out with better
> solution.
>
> PNR
>

Better program skeleton:

CALL 'GET'.
CALL 'MULL'.
CALL 'PUT'.
STOP RUN.

SkippyPB

2006-02-23, 6:55 pm

On Wed, 22 Feb 2006 21:47:54 GMT, "James J. Gavan"
<jgavandeletethis@shaw.ca> enlightened us:

>ashu wrote:
>You could be just dead lazy. I'll give you the benefit of the doubt and
>assume, new to programming you have hit a BLANK !
>
>Work out the logic for yourself with a pack of playing cards. Take a
>pack and just use Hearts and Spades. Shuffle them and put them into two
>decks, (Files A and B). Let your 10 bytes be the card identifier, either
>Hearts or Spades. Cards face down, now figure out manually what your
>moves are as you pick each one up and check what it is.
>
>Jimmy, Calgary AB

Been watching too much Texas Holdem' Jimmy?

Cheers,
////
(o o)
-oOO--(_)--OOo-

WOODY: "Hey Mr. Peterson, there's a cold one waiting for you."
NORM: "I know, if she calls, I'm not here."
From the American TV Show, "Cheers"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

Kelly Bert Manning

2006-02-23, 6:55 pm

"ashu" (ashutosh_priyadarshi@infosys.com) writes:
> Hi,
> I have two files. I need to select those records from file 'A'
> whose first 10 bytes match the first 10 bytes of file 'B'. Rest of
> the layout may be different in files A and B.
> I need to prepare a third file which contains these qualified records
> from file 'A'.
> Anyone have used this functionality, please reply to my id.
>
> thanks
>
Didn't your instructor cover the Balance Line Algorithim?

http://www.cs.uni.edu/~east/teachin..._algorithm.html

When my wife was taking COBOL course at Simon Fraser University in the early
1980s she found that she had to wait till after the deadline to recycle
them. A number of students hung around the recycling boxes to mine the code
written by students who didn't need to plagarize.

epc8@juno.com

2006-02-23, 6:55 pm

PradeepR wrote:
>
> This seems to be a beginner kind of question. I suppose this is the
> first time you are working on a COBOL program. Here is the algorithm,
> hope you can work out the syntax
> for doing it.
>
> A-Section.
> A-010.
> Start on File A
>
> A-020.
> Read next on File A
> Start on File B
>
> A-030.
> Read next on File B
> If EOF, go to A020.
> If First 10 bytes of A = First 10 bytes of B
> Write C (Third file)
> go to A-020
> Endif
> Go to A-030.
>
> A-999
> Exit.
>
> This is my understanding, may be others can come out with better
> solution.
>

Well, I would write this up in pseudo-code as

while not (eof(a) or eof(b)) {
read(a,rec_a)
read(b,rec_b)
if (left$(rec_a,10) .EQ. left$(rec_b,10)) then
write(c,rec_a)
}

Now I do find it hard to imagine how such a program would serve a
useful business D.P. function. :-).

-- Elliot

James J. Gavan

2006-02-23, 6:55 pm

SkippyPB wrote:
> On Wed, 22 Feb 2006 21:47:54 GMT, "James J. Gavan"
> <jgavandeletethis@shaw.ca> enlightened us:
>
>
>
> Been watching too much Texas Holdem' Jimmy?

Steve,

Your message was absolutely lost on me. I went googling - Poker. I hate
cards, other than the very simple family games where you played with
pennies.

Thing that stands out most in my mind was the days in the RAF at
Northolt. I had two *really* good friends - and I mean *friends* not
acquaintances. One was a civilian meteorologist who worked in the Air
Traffic Tower and the other was a flight sergeant in charge of the Fire
Brigade, (should we have aircraft crash landings etc. - which never
occurred in my time there).

Visiting aircrew comes into sergeants' mess and ask, "Who wants to play
some cards ?" Presumably Poker. Gist of story, my two buddies, one lost
a real bundle of money while the other won big time. The loser concluded
the "winner" had gone home with his money - and the friendship between
them

ed for a while. Totally illogical - but it put me off cards
forever.

They were both guests at my wedding subsequently and *entertained* our
respective families around the bar, when we had gone. Naturally their
interest in booze appealed to the male Irish members of my family and
they all got pissed out of their minds :-)

Jimmy

James J. Gavan

2006-02-23, 6:55 pm

Kelly Bert Manning wrote:
> "ashu" (ashutosh_priyadarshi@infosys.com) writes:

> Didn't your instructor cover the Balance Line Algorithim?
>
> http://www.cs.uni.edu/~east/teachin..._algorithm.html
>
Sez to meself, "What's he talking about ?". Checked out your link. Just
great ! One of the most elementary and *very useful* concepts in
programming has a name coined for it :-)

Jimmy

James J. Gavan

2006-02-23, 6:55 pm

epc8@juno.com wrote:
> PradeepR wrote:
>
>
>
> Well, I would write this up in pseudo-code as
>
> while not (eof(a) or eof(b)) {
> read(a,rec_a)
> read(b,rec_b)
> if (left$(rec_a,10) .EQ. left$(rec_b,10)) then
> write(c,rec_a)
> }
>
> Now I do find it hard to imagine how such a program would serve a
> useful business D.P. function. :-).
>
> -- Elliot
>
Hope you were only joking Elliot. In ye Olden Dayes ('63) - and I wasn't
programming back then, but with mag tapes it was necessary to understand
the concept of updating files, (from more than one source), or three-way
mag tape sorts, regardless of whether or not you were a systems analyst
or a programmer. (Disks started getting common, roughly mid-sixties).

Where are you Pete Dashwood ? Your personal experiences back then.

Jimmy

epc8@juno.com

2006-02-23, 6:55 pm

James J. Gavan wrote:
> epc8@juno.com wrote:
> Hope you were only joking Elliot.

Mixing C, Pascal, BASIC and Fortran was definitely for comic effect.
:-). Of couse I do think the program would be more structured with
PERFORM UNTIL instead of GO TO.

> In ye Olden Dayes ('63) - and I wasn't
> programming back then, but with mag tapes it was necessary to understand
> the concept of updating files, (from more than one source), or three-way
> mag tape sorts, regardless of whether or not you were a systems analyst
> or a programmer. (Disks started getting common, roughly mid-sixties).

Amen. There's a whole bunch of stuff in Knuth on multiple tape
sort/merge, etc. that I'm happy I will *never* have to learn.

Arnold Trembley

2006-02-24, 3:55 am

James J. Gavan wrote:
> Kelly Bert Manning wrote:
>
>
>
> Sez to meself, "What's he talking about ?". Checked out your link. Just
> great ! One of the most elementary and *very useful* concepts in
> programming has a name coined for it :-)
>
> Jimmy

Back when I was taught this in second semester COBOL (in 1979) it was
called "Sequential Match/Merge" or just "Match/Merge". It is still a
useful technique for batch processing of transactions. It is faster
to unload KSDS VSAM files to sequential, run match/merge, and reload
than to perform the same updates directly to the VSAM file by key.

--
http://arnold.trembley.home.att.net/

Howard Brazee

2006-02-24, 6:55 pm

On Thu, 23 Feb 2006 21:27:55 GMT, "James J. Gavan"
<jgavandeletethis@shaw.ca> wrote:

>Hope you were only joking Elliot. In ye Olden Dayes ('63) - and I wasn't
>programming back then, but with mag tapes it was necessary to understand
>the concept of updating files, (from more than one source), or three-way
>mag tape sorts, regardless of whether or not you were a systems analyst
>or a programmer. (Disks started getting common, roughly mid-sixties).
>
>Where are you Pete Dashwood ? Your personal experiences back then.

I've done sorts that required sorting into 5-6 tapes before being
merged. The data files were much bigger than what our systems could
handle any other way.

Howard Brazee

2006-02-24, 6:55 pm

On Thu, 23 Feb 2006 21:06:48 GMT, "James J. Gavan"
<jgavandeletethis@shaw.ca> wrote:

>Sez to meself, "What's he talking about ?". Checked out your link. Just
>great ! One of the most elementary and *very useful* concepts in
>programming has a name coined for it :-)

So elementary that I never really thought of it as an algorithm.

Howard Brazee

2006-02-24, 6:55 pm

On Thu, 23 Feb 2006 21:00:26 GMT, "James J. Gavan"
<jgavandeletethis@shaw.ca> wrote:

>Your message was absolutely lost on me. I went googling - Poker. I hate
>cards, other than the very simple family games where you played with
>pennies.

I love card games such as Contract Bridge. What I don't like is
gambling, which only means that poker isn't a game for me, and that I
miss the best feature of backgammon.

For some people, golf can't be enjoyed without gambling.

I am irritated that "gaming" has two very different meanings. The
gambling industry uses it, and so do people who play board games.
Usually fans of one are not fans of the other. I have every issue
of Gaming Magazine.

2006-02-24, 6:55 pm

In article <o27uv11n5ass749l8k7re234bma53r0cnu@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:

[snip]

>I am irritated that "gaming" has two very different meanings.

Leaving aside the relationship between meaning and interpretation... are
you likewise irked about the different definitions of 'cleave'?

DD

HeyBub

2006-02-24, 6:55 pm

Howard Brazee wrote:
> On Thu, 23 Feb 2006 21:27:55 GMT, "James J. Gavan"
> <jgavandeletethis@shaw.ca> wrote:
>
>
> I've done sorts that required sorting into 5-6 tapes before being
> merged. The data files were much bigger than what our systems could
> handle any other way.

One of the early "rules" was "Never sort the master." As an example of why,
it was pointed out that the Reader's Digest subscription file comprised some
200+ tapes...

HeyBub

2006-02-24, 6:55 pm

docdwarf@panix.com wrote:
> In article <o27uv11n5ass749l8k7re234bma53r0cnu@4ax.com>,
> Howard Brazee <howard@brazee.net> wrote:
>
> [snip]
>
>
> Leaving aside the relationship between meaning and interpretation...
> are you likewise irked about the different definitions of 'cleave'?

If that's part of "cleavage," I'm all for all possible definitions.

2006-02-24, 6:55 pm

In article <11vu9jukh2boc7@news.supernews.com>,
HeyBub <heybubNOSPAM@gmail.com> wrote:
>docdwarf@panix.com wrote:
>
>If that's part of "cleavage," I'm all for all possible definitions.

Hmmmmm... that might make for difficulties; a possible definition might be
'to be against all possible definitions'.

DD

Howard Brazee

2006-02-24, 6:55 pm

On Fri, 24 Feb 2006 09:30:27 -0600, "HeyBub" <heybubNOSPAM@gmail.com>
wrote:

>
>If that's part of "cleavage," I'm all for all possible definitions.

Some of the impossible definitions are intriguing as well.

SkippyPB

2006-02-24, 6:55 pm

On Thu, 23 Feb 2006 21:00:26 GMT, "James J. Gavan"
<jgavandeletethis@shaw.ca> enlightened us:

>SkippyPB wrote:
>
>Steve,
>
>Your message was absolutely lost on me. I went googling - Poker. I hate
>cards, other than the very simple family games where you played with
>pennies.
>
>Thing that stands out most in my mind was the days in the RAF at
>Northolt. I had two *really* good friends - and I mean *friends* not
>acquaintances. One was a civilian meteorologist who worked in the Air
>Traffic Tower and the other was a flight sergeant in charge of the Fire
>Brigade, (should we have aircraft crash landings etc. - which never
>occurred in my time there).
>
>Visiting aircrew comes into sergeants' mess and ask, "Who wants to play
>some cards ?" Presumably Poker. Gist of story, my two buddies, one lost
>a real bundle of money while the other won big time. The loser concluded
>the "winner" had gone home with his money - and the friendship between
>them

ed for a while. Totally illogical - but it put me off cards
>forever.
>
>They were both guests at my wedding subsequently and *entertained* our
>respective families around the bar, when we had gone. Naturally their
>interest in booze appealed to the male Irish members of my family and
>they all got pissed out of their minds :-)
>
>Jimmy

Understand your dislike of Poker/gambling. When I was in the U.S.
Army in Vietnam, on a rare division camp assignment that had me
sitting in a semi-underground bunker from 7 pm to 6 am along with 4 or
5 other guys, four of us struck up a regular game of hearts. Really
liked playing that. Played Euchre from a very young age (only someone
from the Midwest U.S. knows that game); learned Pinochle from an old
black guy whilst sitting out a 7 day jail sentence for civil
disobedience.

When I lived in Phoenix, Arizona some of my fellow employees engaged
in a regular Friday night poker game. We did that for a couple of
years. Now the only gambling I do is lottery tickets and the
occasional trip to Las Vegas to play blackjack.

Regards,
////
(o o)
-oOO--(_)--OOo-

WOODY: "Hey Mr. Peterson, there's a cold one waiting for you."
NORM: "I know, if she calls, I'm not here."
From the American TV Show, "Cheers"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

Michael Wojcik

2006-02-24, 6:55 pm

In article <ru6uv1l2ap8qb6n9kmd6njvtj270e3o7g9@4ax.com>, Howard Brazee <howard@brazee.net> writes:
>
> I've done sorts that required sorting into 5-6 tapes before being
> merged. The data files were much bigger than what our systems could
> handle any other way.

Even when they *can* be handled by modern machines, it's often worth
partitioning very large data sets before sorting them and then merging
the results, so that the partitions can be sorted in parallel on SMP
machines or other parallel-processing equipment.

--
Michael Wojcik michael.wojcik@microfocus.com

Auden often writes like Disney. Like Disney, he knows the shape of beasts --
(& incidently he, too, might have a company of artists producing his lines) --
unlike Lawrence, he does not know what shapes or motivates these beasts.
-- Dylan Thomas

Pete Dashwood

2006-02-24, 9:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:vNpLf.64696$sa3.21757@pd7tw1no...
> epc8@juno.com wrote:
> Hope you were only joking Elliot. In ye Olden Dayes ('63) - and I wasn't
> programming back then, but with mag tapes it was necessary to understand
> the concept of updating files, (from more than one source), or three-way
> mag tape sorts, regardless of whether or not you were a systems analyst or
> a programmer. (Disks started getting common, roughly mid-sixties).
>
> Where are you Pete Dashwood ? Your personal experiences back then.
>
I'm trying to forget my personal experiences back then...:-)

Certainly disks arrived by the late 60s (although they were huge and of
laughable capacity by today's standards.)

I wrote an article for an Australian computer magazine which covered a lot
of this and it was updated and republished on the Progeni website
("aboutlegacycoding" ) which seems to have become defunct now. If anyone
here is interested, you can read the original article (minus the
illustrations,

ly - some of these were done by the staff cartoonist at
the magazine and were really excellent) on this link:
http://www.enternet.co.nz/users/dashwood/BITBUC01.DOC

Discuss the proposition: "Repetition of war stories simply glorifies and
perpetuates war. " :-)

Pete.

Pete Dashwood

2006-02-24, 9:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:ItpLf.65776$B94.52647@pd7tw3no...
> Kelly Bert Manning wrote:
>
> Sez to meself, "What's he talking about ?". Checked out your link. Just
> great ! One of the most elementary and *very useful* concepts in
> programming has a name coined for it :-)
>
When I learned it, it was called a "Three way split". I like pictures better
than code so I've posted one here:
http://www.enternet.co.nz/users/dashwood/3waysplit.doc

And, mindful this is a COBOL forum, here's a sample COBOL program...(Notice
I said 'sample' not 'example'... some of the code is not exemplary :-)...)

000010 identification division.
000020 program-id. TWSPLIT.
000030 installation. Prima Computing.
000040 author. Peter E. C. Dashwood.
000050 date-written. Feb 98.
000060*
000070*remarks.
000080*
000090* This program is an example of the use of "3 way split"
000100* logic in COBOL.
000110*
000120* It has been "cloned" from a real program which actually does
000130* a 3 way split to create a database from two input files.
000140*
000150* ****************************************
***************
000160 environment division.
000170 configuration section.
000180 source-computer. IBM-PC.
000190 object-computer. IBM-PC.
000200 special-names.
000210 console is CONSOLE
000220 .
000230 input-output section.
000240 file-control.
000250 select MASTER assign MASTER-path
000260 access mode is sequential.
000270
000280 select detailz assign DETAIL-path
000290 access mode is sequential.
000300
000310*------------------------ DATA DIVISION ---------------------
000320 data division.
000330 file section.
000340 fd MASTER
000350 DATA RECORD IS CUSTREC.
000360 01 CUSTREC.
000370 12 CUSTNO pic x(8).
000380 12 filler pic x(248).
000390
000400 fd DETAIL
000410 DATA RECORD IS ACCTREC.
000420 01 ACCTREC.
000430 12 ACCTNO pic x(8).
000440 12 filler pic x(248).
000450
000460 working-storage section.
000470
000480 01 MASTER-path pic x(50) value
000490 'h:\elle\source\mfisam01.fxd '.
000500
000510
000520 01 DETAIL-path pic x(50) value
000530 'h:\elle\source\mfisam02.fxd '.
000540
000550 01 input-path pic x(50) value spaces.
000560
000570
000580 01 control-counts usage comp value low-values.
000590 12 ws-MASTER-count pic s9(9).
000600 12 ws-DETAIL-count pic s9(9).
000610 12 ws-MATCH-count pic s9(9).
000620 12 ws-UNMATCH-count pic s9(9).
000630
000640 01 display-count pic z(6)9.
000650
000660
000670*
000680 01 finish-flag pic x value zero.
000690 88 finished value '1'.
000700*
000710*
000720/
000730 procedure division.
000740 main section.
000750 main-start.
000760 perform a-initialise
000770 perform b-file-processing until finished
000780 perform c-close-down
000790 stop run.
000800 main-exit.
000810 exit.
000820*-----------------------------------------------------------------
000830 a-initialise section.
000840 a-0100.
000850 display "3 WAY SPLIT is running..."
000860 .
000870 a-0150.
000880* Allow users to specify where the MASTER file is...
000890 display space
000900 display "MASTER FILE data path = " MASTER-path
000910 display space
000920 display "Input new path if desired.."
000930 accept input-path from console
000940 display space
000950 display space
000960 if input-path (1:5) NOT = space
000970 move input-path to MASTER-path
000980 move spaces to input-path
000990 go to a-0150
001000 end-if
001010 .
001020 a-0160.
001030 display space
001040 display "DETAIL FILE data path = " DETAIL-path
001050 display space
001060 display "Input new path if desired.."
001070 accept input-path from console
001080 display space
001090 display space
001100 if input-path (1:5) NOT = space
001110 move input-path to DETAIL-path
001120 move spaces to input-path
001130 go to a-0160
001140 end-if
001150 open input MASTER
001160 DETAIL
001170 move zero to finish-flag
001180
001190* Do the "priming reads" [initial fetches...]
001200 perform s000-get-MASTER
001210 perform s010-get-DETAIL
001220 .
001230 a-9999.
001240 exit.
001250*-----------------------------------------------------------------
001260 b-file-processing section.
001270 b000.
001280*
001290* 3-way-split logic....
001300*
001310*
001320 if ACCTNO < CUSTNO
001330* detailz is low so can never match...
001340 display "unmatched detailz =" ACCTNO
001350 add 1 to ws-UNMATCH-count
001360 perform s010-get-DETAIL
001370 if finished
001380 go to b999-exit
001390 else
001400 go to b000
001410 end-if
001420 else
001430 if ACCTNO = CUSTNO
001440 display "matched detailz =" ACCTNO
001450 add 1 to ws-MATCH-count
001460*
001470* If MULTIPLE DETAILS can be processed against the same MASTER
001480* comment out the fetch on the MASTER below.
001490*
001500*
001510 perform s000-get-MASTER
001520 perform s010-get-DETAIL
001530 if finished
001540 go to b999-exit
001550 else
001560 go to b000
001570 end-if
001580 else
001590* detailz is high so fetch master and re-compare...
001600 perform s000-get-MASTER
001610 go to b000
001620 end-if
001630 end-if
001640 .
001650 b999.
001660 exit.
001670*----------------------------------------------------------------
001680 s000-get-MASTER section.
001690 s000.
001700 read MASTER
001710 at end
001720 move 99999999 to CUSTNO
001730 end-read
001740 if CUSTNO NOT = 99999999
001750 add 1 to ws-CUST-count
001760 end-if
001770 .
001780 s000-exit.
001790 exit.
001800*----------------------------------------------------------------
001810 s010-get-DETAIL section.
001820 s010.
001830 read DETAIL
001840 at end
001850 set finished to true
001860 end-read
001870 if NOT finished
001880 add 1 to ws-ACCT-count
001890 end-if
001900 .
001910 s010-exit.
001920 exit.
001930*-----------------------------------------------------------------
001940 c-close-down section.
001950 c0100.
001960
001970 close MASTER
001980 DETAIL
001990 display space
002000 display ' input record counts'
002010 move ws-MASTER-count to display-count
002020 display ' input CUSTOMER count =' display-count
002030 move ws-DETAIL-count to display-count
002040 display ' input ACCOUNT count =' display-count
002050 display space
002060 display ' output counts'
002070 move ws-MATCH-count to display-count
002080 display ' number of matches =' display-count
002090 move ws-UNMATCH-count to display-count
002100 display ' number of unmatched =' display-count
002110 display space
002120 DISPLAY "Program TWSPLIT has terminated..."
002130 .
002140
002150 c0900.
002160
002170 exit.
002180*----------- end of program ------------------------------------

Pete.

James J. Gavan

2006-02-24, 9:55 pm

Pete Dashwood wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:ItpLf.65776$B94.52647@pd7tw3no...
>
>
> When I learned it, it was called a "Three way split". I like pictures better
> than code so I've posted one here:
> http://www.enternet.co.nz/users/dashwood/3waysplit.doc
>
Yep. The phrase 'Three Way Split' rings a bell with me.
>
> And, mindful this is a COBOL forum, here's a sample COBOL program...(Notice
> I said 'sample' not 'example'... some of the code is not exemplary :-)...)
<snip>

You *really* are brave posting that - you know fully well what is going
to happen now :-)

Jimmy

Pete Dashwood

2006-02-24, 9:55 pm

Sorry, I gave an incorrect link.

Try: http://www.enternet.co.nz/users/das...bitbucket01.DOC

Pete.

TOP POST no more from me below...

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:469qkoF976j0U1@individual.net...
>
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:vNpLf.64696$sa3.21757@pd7tw1no...
> I'm trying to forget my personal experiences back then...:-)
>
> Certainly disks arrived by the late 60s (although they were huge and of
> laughable capacity by today's standards.)
>
> I wrote an article for an Australian computer magazine which covered a lot
> of this and it was updated and republished on the Progeni website
> ("aboutlegacycoding" ) which seems to have become defunct now. If anyone
> here is interested, you can read the original article (minus the
> illustrations,

ly - some of these were done by the staff cartoonist at
> the magazine and were really excellent) on this link:
> http://www.enternet.co.nz/users/dashwood/BITBUC01.DOC
>
> Discuss the proposition: "Repetition of war stories simply glorifies and
> perpetuates war. " :-)
>
> Pete.
>
>
>

epc8@juno.com

2006-02-25, 7:55 am

Pete Dashwood wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:ItpLf.65776$B94.52647@pd7tw3no...
> When I learned it, it was called a "Three way split". I like pictures better
> than code so I've posted one here:
> http://www.enternet.co.nz/users/dashwood/3waysplit.doc
>

Very nice. Your diagram cut right through it! Perhaps if the
instructors went back to calling it a "three way split" the students
would catch on more.

-- Elliot

Kevin M

2006-02-25, 7:55 am

<docdwarf@panix.com> wrote in message news:dthdss$ppa$1@reader2.panix.com...
> In article <1140599370.807157.180590@o13g2000cwo.googlegroups.com>,
> ashu <ashutosh_priyadarshi@infosys.com> wrote:
>
> Please do your own homework.
>
> DD
>
Ignore DocDickhead. He is just an old gereatric fart.

2006-02-25, 7:55 am

In article <469qkoF976j0U1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:

[snip]

>Discuss the proposition: "Repetition of war stories simply glorifies and
>perpetuates war. " :-)

On the other hand, 'that which is forbidden commands attention'; perhaps
you've offered a variant of Aeschylus' 'Great hardships make for later
entertainments'.

DD

Pete Dashwood

2006-02-25, 7:55 am

<epc8@juno.com> wrote in message
news:1140840647.364004.151120@e56g2000cwe.googlegroups.com...
>
> Pete Dashwood wrote:
>
> Very nice. Your diagram cut right through it! Perhaps if the
> instructors went back to calling it a "three way split" the students
> would catch on more.
>
> -- Elliot
>
Thank you, Elliot. It's nice to know someone found it useful.

Pete.

Michael Mattias

2006-02-25, 7:55 am

Merge 'em to a temp file or memory. (SORT and/or MERGE verb with/without
INPUT PROCEDURE )

Read 'em back sorted (sequentially from temp file, or RETURN 'em).

If you get a record where the key (first ten bytes) is the same as the last
key, that record must have been present in both inputs. Write that one to
the 'real' output.

MCM

Alistair

2006-02-25, 6:55 pm

Kevin M wrote:
> <docdwarf@panix.com> wrote in message news:dthdss$ppa$1@reader2.panix.com...
> Ignore DocDickhead. He is just an old gereatric fart.

You might care to consider him to be a geriatric and an old fart but I
warrant that he can, at least, spell correctly.

Kelly Bert Manning

2006-02-27, 3:55 am

Arnold Trembley (arnold.trembley@worldnet.att.net) writes:
>
> Back when I was taught this in second semester COBOL (in 1979) it was
> called "Sequential Match/Merge" or just "Match/Merge". It is still a
> useful technique for batch processing of transactions. It is faster
> to unload KSDS VSAM files to sequential, run match/merge, and reload
> than to perform the same updates directly to the VSAM file by key.

Say what?

Did you mean direct application of unsorted updates or Skip Sequential
processing of sorted updates. I'd look for some analysis and tuning if
I got Skip Sequential VSAM performance as slow as you seem to get.

Arnold Trembley

2006-02-27, 3:55 am

Kelly Bert Manning wrote:
> Arnold Trembley (arnold.trembley@worldnet.att.net) writes:
>
>
>
> Say what?
>
> Did you mean direct application of unsorted updates or Skip Sequential
> processing of sorted updates. I'd look for some analysis and tuning if
> I got Skip Sequential VSAM performance as slow as you seem to get.

Results might vary depending upon your application, but this KSDS file
with 16 million records normally received 100,000 to 400,000 updates
in each night's batch processing. Besides being faster to process
against the sequential backup of the file, the sequential file batch
processing was easier to recover from in the event of any problems.

But I admit it's been many years since this was benchmarked, and it is
possible that VSAM performance has improved since the late 1980's.
The sequential process runs in less than 15 minutes and the reload
file also serves as a backup. It has been very fast and reliable.

During online processing this particular file is mirrored, so it is
available for online update 24x7.

--
http://arnold.trembley.home.att.net/

2006-02-27, 7:55 am

In article <kUwMf.468892$qk4.302374@bgtnsc05-news.ops.worldnet.att.net>,
Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:
>
>
>Kelly Bert Manning wrote:

[snip]
[color=darkred]
>
>Results might vary depending upon your application, but this KSDS file
>with 16 million records normally received 100,000 to 400,000 updates
>in each night's batch processing. Besides being faster to process
>against the sequential backup of the file, the sequential file batch
>processing was easier to recover from in the event of any problems.
>
>But I admit it's been many years since this was benchmarked, and it is
>possible that VSAM performance has improved since the late 1980's.

Bingo... it might be, Mr Trembley, that what was true about hardware nigh
two decades ago is no longer the case now. Perhaps, for laffs, a set of
benchmarks might be run to determine if this is still the case.

DD

Howard Brazee

2006-02-27, 6:55 pm

On Sat, 25 Feb 2006 14:36:20 +1300, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>Discuss the proposition: "Repetition of war stories simply glorifies and
>perpetuates war. " :-)

It is interesting to watch little boys play who are from households
that don't allow toy guns. At least watching them when their parents
aren't around.

HeyBub

2006-02-27, 6:55 pm

docdwarf@panix.com wrote:
>
> Bingo... it might be, Mr Trembley, that what was true about hardware
> nigh two decades ago is no longer the case now. Perhaps, for laffs,
> a set of benchmarks might be run to determine if this is still the
> case.

I don't think the hardware could speed up enough! As I remember ISAM/VSAM
internals, once the cylinder overflow area fills, the IO routine has to
chase all the records added sequentially to find a spot to dump the new
record. That is, in the case where a huge number of records have to be added
having similar keys, the number of I/O operations per add jumps
astronomically.

2006-02-27, 6:55 pm

In article <12066iekfscgnae@news.supernews.com>,
HeyBub <heybubNOSPAM@gmail.com> wrote:
>docdwarf@panix.com wrote:
>
>I don't think the hardware could speed up enough! As I remember ISAM/VSAM
>internals, once the cylinder overflow area fills, the IO routine has to
>chase all the records added sequentially to find a spot to dump the new
>record.

.... and as I remember being taught CICS one should avoid INSPECT and
STRING like the plague... but times have changed since then and every once
in a while re-examining such stuff might be in order.

DD

Kelly Bert Manning

2006-02-28, 7:55 am

"HeyBub" (heybubNOSPAM@gmail.com) writes:
> docdwarf@panix.com wrote:
>
> I don't think the hardware could speed up enough! As I remember ISAM/VSAM
> internals, once the cylinder overflow area fills, the IO routine has to
> chase all the records added sequentially to find a spot to dump the new
> record. That is, in the case where a huge number of records have to be added
> having similar keys, the number of I/O operations per add jumps
> astronomically.
>
ISAM and VSAM are very different beasts, not just because ISAM is dead.

I've been told that I shouldn't mention ISAM or IEBISAM, etc. because it
dates me.

The guy from Seattle who taught us our VSAM for system programmers course
when we converted to Integrate Catalog Facility used a case study of a
VSAM KSDS with several insertion hot spots. The bottom line was that Control
Area Splits occurring after %CA and %CI freespace were used up were adding
freespace exactly where it was needed to improve performance, so don't sweat.

In any case I still wonder whether the original pathological performance
problem involved a sorted input file and true SKIP SEQUENTIAL processing.

With random update you could be reading and each Data CI repeatedly,
along with Index CIs. With Skip Sequential Update you only read and write
each Data CI of interest once, bypassing ones that aren't updated. The
metaphor for Index CI processing was a pendulum swinging through the
Index hierarchy once, from low to High keys. Each Index CI is only retrieved
once, at most.

I saw one circa 1981 conversion from tape master files to IMS and VSAM
which was motivated by adding up the costs of sorts in the tape application
and promising that converting to Direct Update would "save" those costs.

After all, one random read or update to an IMS DB or VSAM KSDS involves
the same CPU and I/O overhead as your average read or write to a 32K
blocked Tape record, doesn't it?

The had other issues, with the PL/I analog of Occurs Depending On, but
kept sneering at the advice to sort their input. "Everybody knows" that
sorting became obsolete with VSAM and databases, so we obviously didn't
know anything about MVS I/O and performance.

After a year or so of whining about processing costs they were told to go
away and stop bothering us until they had:
sorted their input to physical sequence of the highest I/O dataset
replaced the PL/I analog of ODO in tables with fixed maximum lengths
trimed their VSAM AMP allocation, since we were billing for Virtual
storage occupancy and didn't have nearly enough memory to buffer
entire datasets at that time. It simply cost them money to have
CIs sit in buffers for a longer time before being reused for a
different CI.
Note that none of this involved major changes to their processing logic.

They went away in a huff, apaprently planning to return with the proof
that we didn't know what we were talking about. We never heard from them
again about that, not even to thank us for advice which reduced their
processing costs by about $1000/day in early 1980s dollars.

Processing smarter can make a huge difference in VSAM performance.

Arnold Trembley

2006-02-28, 7:55 am

docdwarf@panix.com wrote:

> In article <kUwMf.468892$qk4.302374@bgtnsc05-news.ops.worldnet.att.net>,
> Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:
> (snip)
>
>
> Bingo... it might be, Mr Trembley, that what was true about hardware nigh
> two decades ago is no longer the case now. Perhaps, for laffs, a set of
> benchmarks might be run to determine if this is still the case.
>
> DD
>

I certainly cannot disagree with this advice, but I'm sure you're
aware of how difficult it can be to budget for this kind of research.

I looked at this application again, and realized this particular large
VSAM file was converted to DB2 last year. But it is still unloaded to
sequential file for large batch processing updates, which primarily
fall into two categories:

1) Aging off records based on an expiration date, and
2) Applying large numbers of inserts, updates, and deletes received
from external customers as file transfers. Of course, each external
customer must receive a file transfer back containing only the results
for their updates.

Obviously, when it was still a VSAM file, aging off the out of date
records required examing every record in order to determine if it
needed to be deleted.

Performance is very good, under five minutes for this batch process.
The entire batch maintenance window for the online system typically
runs in less than 75 minutes. In the late 1980's it was 4 to 8 hours.

Given the nature of the business, the bosses won't want to spend any
money to make it go faster when it already runs fast enough.

But you point is well taken. If you want to know which way is faster,
you have to test both ways.

--
http://arnold.trembley.home.att.net/

2006-02-28, 7:55 am

In article <tnSMf.475292$qk4.306072@bgtnsc05-news.ops.worldnet.att.net>,
Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:
>
>
>docdwarf@panix.com wrote:
>
>
>I certainly cannot disagree with this advice, but I'm sure you're
>aware of how difficult it can be to budget for this kind of research.

I've worked in enough organisations, Mr Trembley, to have seen the
equivalent of something I posted over a half-decade back, aye. From

<http://groups.google.com/group/comp...de=source&hl=en>

--begin quoted text:

A Story:

A gang of carpenters are working on a house; the Foreman (this story is
old enough to have originated in the days when Foremen were Foremen, not
Forefolk), as is the Forman's wont, is wandering about, keeping an eye on
things. He notices one particular carpenter laboring *mightily* with his
saw and the following dialogue ensues:

F: 'Hey, Joe... what'cha doin'?'

J: 'Sawin' these planks, Boss, just like ya tol' me to.'

F: 'Yup, that ya are... y'know, I can't really tell from this angle but it
looks, to me, like your saw's kinda dull.'

J: 'You sure got a good eye, Boss... I guess that's why you're the
Boss. Saw sure is dull, duller'n a butterknife.'

F: 'Oh... ummmm, Joe, why don't you sharpen your saw?'

J: 'Sharpen my saw? I'm too busy cuttin' these planks to sharpen my saw!'

EOS

Now I have told that tale many times, in many places... and many folks
have laughed and nodded while intoning 'Yup, it's *just* that way here,
too'...

.... while *my* response, when I first heard it, was to think 'All
right... and now the Foreman says 'Joe, lissen'a me. I am your
Boss... Direct Order, stop cuttin' the planks and sharpen your saw, *now*,
please?''

--end quoted text

>
>I looked at this application again, and realized this particular large
>VSAM file was converted to DB2 last year. But it is still unloaded to
>sequential file for large batch processing updates, which primarily
>fall into two categories:
>
>1) Aging off records based on an expiration date, and
>2) Applying large numbers of inserts, updates, and deletes received
>from external customers as file transfers. Of course, each external
>customer must receive a file transfer back containing only the results
>for their updates.
>
>Obviously, when it was still a VSAM file, aging off the out of date
>records required examing every record in order to determine if it
>needed to be deleted.

.... as opposed to, say, a DELETE FROM TBLNAM WHERE... now *that* might be
interesting. How much faster/cheaper is it to do the SQL versus an unload
to a flatfile, a SORT INCLUDE/OMIT COND, a DROP, a CREATE and a reload?

At any rate... this brings back something earlier, when folks were
discussing what reasons might be found for treating a database as one
would treat a VSAM file.

>
>Performance is very good, under five minutes for this batch process.
>The entire batch maintenance window for the online system typically
>runs in less than 75 minutes. In the late 1980's it was 4 to 8 hours.

As mentioned someplace else... the late 1980s were twenty years ago, it
might be that things have changed in the World of Computing enough since
then to warrant another look.

>
>Given the nature of the business, the bosses won't want to spend any
>money to make it go faster when it already runs fast enough.

If the results were known in advance they wouldn't call them
'experiments'... those who do not budget for them deserve the results they
don't get.

'I have an idea that might save some money... but it's gonna cost a few
buck up front, first.'

'Sorry... we only want ideas that'll save money that cost nothing.'

>
>But you point is well taken. If you want to know which way is faster,
>you have to test both ways.

It is a good thing, at times, to address the assumptions one brings to
bear on a task, Mr Trenbley.

DD

Pete Dashwood

2006-02-28, 7:55 am

"Howard Brazee" <howard@brazee.net> wrote in message
news:5j16021jjc3iv2mpgk71lshsr0vnvls38v@
4ax.com...
> On Sat, 25 Feb 2006 14:36:20 +1300, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
> It is interesting to watch little boys play who are from households
> that don't allow toy guns. At least watching them when their parents
> aren't around.
>
I remember when I was around 8 years old I lost my toy gun and had to go to
school without it. My father was deeply sympathetic and totally understood
it was nearly impossible to go to school without a gun at that age. He
actually made me a new one from wood while I was at school. For a whole day
I was virtually excluded from "cowboys and indians" and "cops and robbers"
and took it pretty hard...My mother was delighted and did not approve at all
of my Dad replacing it immediately.

Yes, we played with guns, we had sword fights, enacted "King Arthur" and
"Horatius holds the Bridge" (there was a plantation adjacent to my school
with vines on the trees you could swing on, and a stream running through it
with a small bridge that was ideal for our own Roman epics and for playng
Tarzan). We re-enacted the deeds of bygone days and invented new glories of
our own.

There were scratches and bruises and the odd torn shirt or ravelled
pullover. There were wrestles and the occasional fist fight (scrupulously
fair and no one ever got bullied or beaten by bigger kids; it just wasn't
decent. One on one in fair fight until one withdrew, or it was declared a
draw.). It's a boy thing. Never did us any harm. Some of the alliances and
friendships formed at that time have lasted through the years until the
present. We learned respect for each other, even when we won the fight.

Some years later when an automatic weapon was placed in my hands and I was
told I should face the prospect of going to Viet Nam and killing people I
had never met, because our government believed it was necessary, my somewhat
hawkish childhood did not affect my judgement, any more than if I had played
with dolls instead... OK, I guess that is hypothetical, but I don't believe
it did :-). Certainly I had a sense of duty, and a sense of survival, and a
certain thrill of adventure at putting myself in harm's way (at 20, unless
you have had a VERY sheltered upbringing, that is pretty normal) but I
resolved then and there not to shoot anyone who wasn't threatening me, or to
kill people just for wearing black pyjamas. Fair play. Duty and honour. Good
concepts that have served me well throughout my life.

I'm not saying you can't grasp these principles unless you have a
belliferous childhood. What I'm saying is that playing with guns doesn't
make you a killer. Kids DO understand the difference between being shot in
play and being shot for real. (If they don't then there is a serious screw
loose somewhere and they would come to a sticky end anyhow.)

And little boys (and some little girls too) will play violent games that
involve death and mayhem. There is no reason for parents to be alarmed by
this or to attempt to stifle it. Instead, channel it. Make sure they use
their ""weapons" in defence of the weak and oppressed. Let them be heroes.

I don't personally believe that repetition of war stories is a bad thing...
and I think that is true of IT war stories as well as real war stories. :-)

Pete.

Howard Brazee

2006-02-28, 6:55 pm

On 28 Feb 2006 05:04:58 GMT, bo774@FreeNet.Carleton.CA (Kelly Bert
Manning) wrote:

>ISAM and VSAM are very different beasts, not just because ISAM is dead.

Not to mention that VSAM comes in 3 flavors, flat, relative, and
keyed. Still they are IBM ways of doing what everybody else does
without the word VSAM.

Kelly Bert Manning

2006-02-28, 6:55 pm

Howard Brazee (howard@brazee.net) writes:
> On 28 Feb 2006 05:04:58 GMT, bo774@FreeNet.Carleton.CA (Kelly Bert
> Manning) wrote:
>
>
> Not to mention that VSAM comes in 3 flavors, flat, relative, and
> keyed.

So you regard LINEAR datasets as a special case of ESDS with very long
records?

The discussion was about VSAM performance. I suppose dataset performance
in the non-IBM sphere is so automatically good that it never comes up for
discussion.

I worked with COBOL on HIS series 60 processors from GCOS 2H thru 4Js,
including CODASYL DB DC applications.

HIS GCOS had a recurring problem with not writing the last block of a tape
dataset at end of program. We had to impose a peer reviewed standard of
including code to write trailer records enough times to ensure that
a block was actually filled and written to tape.

I have a copy of a "STAR" from their tech support group in Phoenix confirming
that their analog of specifying non-default buffer numers croaked when you
tried to specify more than the default number of buffers for very large
buffer sizes.

Despite that, the console operators could always tell when my batch programs
were running, because I was the only person who could peg the "applause
meter", doing enough sequential Tape and DB I/O to keep the CPU fully
occupied during overnight batch runs.

Sponsored Links