FILEDEF questions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

FILEDEF questions

Hercules390 - Vm mailing list
Hello H390-VM list,

I'm on VM-370 Rel 6, I am working on my Stanford Pascal system,
and now I am having some difficulties with the runtime.

The program is reading a file which is RECFM F, LRECL 80,
then it does some processing, and then it does REWRITE on the same
file and writes it out again, possibly modified.

The new (modified) file has again RECFM F, but now LRECL 1600.

The FILEDEF looks like this:

FILEDEF EADATEI DISK X ZWBDATEN (RECFM F LRECL 80

Somehow the default blocksize of 1600 goes into the LRECL
field of the DCB; this is all OS simulation; the Pascal runtime
uses DCBs, GET, PUT, all that stuff.

All works well, if BLOCK 80 is coded on FILEDEF,
but if BLOCK is omitted, a default Blocksize of 1600 is used
and overrides the LRECL on output.

I did some research and found out, that there is a exit routine
on the DCB, which is executed during OPEN and moves some default
values into the DCB, if the parameters there don't make sense.
The blocksize 1600 is inserted into the DCB by this exit routine.

I changed the exit routine so that the default value for the blocksize
is computed from the record length. (if recfm = F, then blocksize =
record length, or: make sure that the given blocksize is a multiple
of the record length; If recfm = V, the blocksize must at least be
record length plus 4).

Now all works well, given the above FILEDEF.

But, if I code the following FILEDEF:

FILEDEF EADATEI DISK X ZWBDATEN (RECFM F LRECL 80 BLOCK 1600

I get the same behaviour as before; the file has record size 1600
as shown by LISTFILE, and I cannot use it with subsequent runs
of the program, because it now has the wrong record length.

This is kind of strange for me, because the DCB (after open)
shows the correct LRECL, look at these trace outputs:

TRACE: OPEN DDNAM=EADATEI
TRACE: OPEN LRECL=000000080
TRACE: OPEN BLKSI=000001600
TRACE: OPEN RECFM=000000128

So now my questions:

a) does the blocksize on FILEDEF have any meaning for CMS files,
or is it there only for compatibility reasons (for OS programs,
so that they can play with it) ?

b) why does the CMS file system build the output record length
on the FILEDEF block parameter instead of the record length
parameter?

c) are there any drawbacks, if I change my exit to set the
blksize always equal to the record length (with recfm = F),
regardless of what was specified on FILEDEF ?

BTW: my VM/CMS system goes into an endless loop if I issue
Q FILEDEF ... it shows the FILEDEF table followed by endless
garbage ... is that a known error of the Hercules-VM distribution?

Any other suggestions?

Thank you, kind regards

Bernd

Reply | Threaded
Open this post in threaded view
|

Re: FILEDEF questions

Hercules390 - Vm mailing list
Hi Bernd,
 

 One suggestion I have would be to specify RECFM FB instead of just F.  When using F records, the LRECL has no meaning and the blocksize will be the record length.
 

 Regards,
 Bob