7432Re: [hercules-os380] RE: concatenation of unlike sequential datasets
- Mar 4, 2014
>> But regardless, the code is not required. The C code passes a pointer:
> As per your original request, you stated that the call by address was
> for use by GCC, whereas the call by value was for something else (IBM c?).
I think there is a difference when a value is passed, not a pointer. And regardless, that logic should be governed by this flag:
&COMP SETC 'GCC' Indicate that this is for GCC
* &COMP SETC 'C370' Indicate that this is for C/370
>> As per above aopen call, the "mode" is the second parameter. Also I
>> believe I have tested the unit record code as part of PDOS, where I
>> needed to have line buffering.
> This is another fine mess you've gotten us into <g>
> 1) With concatenated input, any DD may be unit record, but you're only
> getting information for the first.
That's fine. It's only output that I care about unit record.
> 2) Other DDs may present line buffering (e.g., JES2, TSO GETLINE) that
> you didn't request information for.
Ok, I'm happy if it only works properly for simple disk datasets.
> 3) It points out the lack of planning in your requirements. From day one
> you could have requested a record interface (either faux F with variable
> length records, or V) that makes the MVS form of the data set completely
> and totally irrelevant,
This is exactly how it is already done. I have 4 different flavours, for read and write. fixed binary, fixed text, variable binary, variable text.
> or you could use block mode and do everything yourself.
Yes, that would require a rewrite though.
> While Tony has done a good job of explaining why text vs. binary was a
> bad idea,
He hasn't explained how other languages do it better. C has a very logical distinction between text and binary files, which is exactly what is required for when you are reading an FB file and FB could contain either textual content or binary content.
- << Previous post in topic Next post in topic >>