View previous topic :: View next topic
|
Author |
Message |
Elixir
Active User
Joined: 08 Feb 2009 Posts: 116 Location: CHENNAI/NEW JERSEY - INDIA/USA
|
|
|
|
Hello,
How many Cylinders or Tracks of space would be required to write 400000000 records to a flat file each record having LRECL 133 FB? |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Didn't this help when it was mentioned before? |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
most probably the TS wants us to provide the number without doing any work |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
|
|
|
|
Bill Woodger wrote: |
Didn't this help when it was mentioned before? |
Of course not; the TS doesn't even know that specifying LRECL is useless. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
Use the formula for half-track blocking:
1. Divide 27998 by 133 (the record length). Discard any fractional part. This gives records per block.
2. Multiply the integer derived in #1 by 30 (2 blocks / track times 15 tracks / cylinder). This gives records per cylinder.
3. Divide your record count by the result of #2. If there is a fraction, add 1 to the integer part and drop the fraction (do this even if .001 -- you're not rounding). This gives total cylinders required.
You can then adjust, if needed, by the maximum number of cylinders per volume (which will depend upon your site and which release of z/OS your site is running and whether or not the maximum 65,535 tracks per volume cylinder is in effect). |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
I have to say, it sure is a lot.
133? Print? Who's going to read all that? That's somewhere around, give or take a few, eighty million pages. Archival? Going off-site for preparation? Why not whack it straight to tape?
If it is for something local, cut the stuff down in some way. If you can reduce the length by 20% you get a couple of drives freed-up. Got any blank lines in that lot?
OK, tell us what it is for, maybe split the savings with us? |
|
Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011 Posts: 556 Location: USA
|
|
|
|
Fire up your old QuickBasic from MSDos and run this program:
Code: |
INPUT "What LRECL do you want? "; lrecl
CLS
halftrack = 27998
tapetrack = 32000
PRINT "Half Track Size:"; halftrack
PRINT "Tape Track Size:"; tapetrack
rpht = INT(halftrack / lrecl)
rptt = INT(tapetrack / lrecl)
blksize = rpht * lrecl
tblksize = rptt * lrecl
PRINT "Lrecl:"; lrecl; "Blksize:"; blksize; "(Tape:"; tblksize; ")"
rpt = rpht * 2
PRINT "Records per halftrack (records per block):"; rpht
DATA 1000, 5000, 10000, 30000, 50000, 100000, 0
PRINT
PRINT "Records"; TAB(10); "Tracks"; TAB(20); "Cylinders"; TAB(30); "Blocks"
RESTORE
loopit:
READ x
IF x = 0 THEN GOTO endloop
tpx = INT(x / rpt + .999)
PRINT x; TAB(10); tpx; TAB(20); INT(tpx / 15 + .999); TAB(30); INT(x / rpht + .999)
GOTO loopit
endloop:
loop2:
INPUT "Calc for how many recs? (enter 0 to exit)"; recnum
IF recnum = 0 THEN GOTO endloop2
tpx = INT(recnum / rpt + .999)
PRINT
PRINT recnum; TAB(10); tpx; TAB(20); INT(tpx / 15 + .999); TAB(30); INT(recnum / rpht + .999)
PRINT
GOTO loop2
endloop2:
INPUT "Do another LRECL? (Y/N) [Y]"; yn$
IF UCASE$(yn$) <> "N" THEN GOTO progstart
|
|
|
Back to top |
|
|
Elixir
Active User
Joined: 08 Feb 2009 Posts: 116 Location: CHENNAI/NEW JERSEY - INDIA/USA
|
|
|
|
I am planning for a single time execution. This file will help me in debugging the code if there is any issue with it. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
This file will help me in debugging the code if there is any issue with it. |
Trying to work with this file will probably be more trouble than it is worth. . .
400 million records is simply not managable. . .
Definitely there are better ways to debug some code. . . |
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2593 Location: Silicon Valley
|
|
|
|
How did you come up with the 400 million records? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hi Pedro,
Quote: |
How did you come up with the 400 million records? |
From the initial post.
Unless i'm addlepated again. . .
Which happens all too often. . .
Quote: |
How many Cylinders or Tracks of space would be required to write 400000000 records to a flat file |
|
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2593 Location: Silicon Valley
|
|
|
|
Dick, sorry for my improper forum etiquette...
I was wondering how the original poster came to that number. It seems unusually high. I agree that a large number of files is un-managable. If there are really that many records, he will probably not even be able to browse the file.
I suspect is it is just a lack of experience in debugging.
Actually, it is not always straightforward to determine what kind of information to 'log' for problem determination. You probably need to re-create the problem several times. Each time you test, you narrow the area of testing and may introduce additional log records as needed. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hi Pedro,
Quote: |
Dick, sorry for my improper forum etiquette... |
Not to worry
I do appreciate it when someone lets me know i've stepped on my hand.
Quote: |
I suspect is it is just a lack of experience in debugging. |
Yup, unfortunately, going overboard on diagnostics can slow the problem resolution.
If more about the actual "oppportunity" is posted, we may be able to offer suggestions on how to resolve. . . |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
I also find it difficult to believe that this file will "help" with debugging - just on the off-chance that you need it, as well!
I keep writing and deleting. It is just too absurd to capture how absurd it seems.
Has to be a better way. Let us know, please, let us know, what you are trying to do. Lots of detail. There has to be a better way. Can't believe you are even considering it for this purpose. Is you site made of money/DASD?
You could "easily" keep 1,000,000 lines in memory in Cobol, trap the abend, write out the latest million if needed. And that is a dumb idea. |
|
Back to top |
|
|
gcicchet
Senior Member
Joined: 28 Jul 2006 Posts: 1702 Location: Australia
|
|
|
|
Hi,
if want to try something different, you can always use this
Code: |
//GENERATE EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD *
DUMMY
//SORTOUT DD DSN=output.R100000,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,
// SPACE=(TRK,(500,100),RLSE)
//SYSIN DD *
SORT FIELDS=COPY
OUTFIL BUILD=(133C' '),REPEAT=100000
/*
|
The output file will have 100000 records. Check the amount of space used and multiply the result by 4000.
Gerry |
|
Back to top |
|
|
|