Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Anjum,
It seems that you have the following situation:
An input file with multiple record-layouts of different sizes.
You have a program to "split" this file into multiple files, one type of record-layout per output file.
You do not know how many files you need to create on any given run.
Down the track, after your program, is another one/many which will read your output (and presumably attempt to do something useful). By some unknown magic it is supposed to collect the scatter of datasets you produce, no more and no less.
Is this about right?
If so, what is the business reason for splitting the input? I don't want to know that some other program expects it like that, I want to know why some other program has to have it like that and no other way.
Dick asked a long time ago for more details from you.
Unless we get some solid information from you, it is unlikely (in the extreme) that we can help.
you are absolutely right, I need a solution for this. I have gone thru quite a many references, including the one which Peter has mentioned. Might be I have missed any information somewhere.
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
So what you're really saying is that you want something like:
Code:
foo21: proc (PARM) options (main) reorder;
dcl parm char (100) var;
dcl howbig fixed bin (31) static;
dcl foo file record output
env(vb recsize(howbig));
howbig = parm;
open file (foo);
/* All your processing */
close file (foo);
end foo21;
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Garry Carroll wrote:
[...]I think the OP is trying to create a single file which contains all the records but the challenge is to determine the maximum LRECL for this file.
Might this be right?
Garry.
Brilliant spot Garry.
anjumraza wrote:
[...]
I need to do dynamic allocation because of different layouts in the file. i need to create the number of files based on the number of record layouts, which i cannot create thru jcl. there can be any number,
[...]
If TS/OP does not know the length of his largest record layout(?) and is without the means to find out(?), then why not blocksize = optimum-for-site-as-defined-by-storage-team, lrecl=blocksize - 4.
Thing is, does PL/I do something similar to Cobol? Ie, by default, write the block when the largest lrecl can no longer fit in the current block. So in this case potentially one record per block. Mmmm... another way to put that is unblocked, with a little extra overhead. In Cobol, you get around it with Apply Write Only. I don't know for PL/I.
How about this? Pre-process the file with a SORT product. Establish the maximum record length. Use that as the PARM for Akatsukami's suggestion.
Or, inherit the lrecl from the input dataset?
Hang on, though, what does TS/OP actually want to do with the program. Just "deblock" the file? Why, with a single output, do the thing "dynamically" (I question whether all this effort counts as being "dynamic").
Joined: 08 May 2006 Posts: 1205 Location: Dublin, Ireland
Bill Woodger wrote:
Thing is, does PL/I do something similar to Cobol? Ie, by default, write the block when the largest lrecl can no longer fit in the current block. So in this case potentially one record per block.
The blocking/deblocking is handled the same way in PL/1. Isn't it the I/O subsystem that handles (de)blocking?
Bill Woodger wrote:
Hang on, though, what does TS/OP actually want to do with the program. Just "deblock" the file? Why, with a single output, do the thing "dynamically" (I question whether all this effort counts as being "dynamic").
I don't think the TS/OP is "deblocking" the file since it's being output. While this is trying to dynamically determine the LRECL, it's not what we would typically understand as "dynamnic allocation" .
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Garry Carroll wrote:
Bill Woodger wrote:
Thing is, does PL/I do something similar to Cobol? Ie, by default, write the block when the largest lrecl can no longer fit in the current block. So in this case potentially one record per block.
The blocking/deblocking is handled the same way in PL/1. Isn't it the I/O subsystem that handles (de)blocking?
Bill Woodger wrote:
Hang on, though, what does TS/OP actually want to do with the program. Just "deblock" the file? Why, with a single output, do the thing "dynamically" (I question whether all this effort counts as being "dynamic").
I don't think the TS/OP is "deblocking" the file since it's being output. While this is trying to dynamically determine the LRECL, it's not what we would typically understand as "dynamnic allocation" .
Garry.
Garry,
I no longer have any idea what the TS/OP wanted, which means I never had any idea at any point :-)
Thus you have to wade through the irony.
With a huge LRECL for the dataset, you'd basically get one record per block (without apply write only). Which would be similar to the unblocked TS/OP was originally after, just with a smidge extra for the block information. This was what I was ironically terming "deblocking", being a method to write an unblocked file (individual records written) but having it blocked as well. I'm still not sure I'm explaining it well, because I was just being a silly sausage at the time I wrote the original. It is not, I think, anything anyone would ever do deliberately for any reason. But, I suppose, you never know :-)
As to the point about whether it is I/O subystem or not, I know this: Cobol knows what can go into a block for output, and actually (without apply write only) gives the Cobol file area access to the buffer area, for both read and write (I'm talking about QSAM here). Whether it is Cobol I/O routines or system I/O routines that are doing it all, or parts thereof, beyond that, I don't know. Determining what goes into a QSAM block is down to "Cobol". Prior to discovering this recently, I thought exactly like you.
