On 2016-01-06 19:04, Tom Marchant wrote:
>
> I remain unconvinced that there is a need for GIMDTS to transform data just
> because it contains "//" or "/*" in columns 1 and 2. If this hs ever come up
> as a
> problem for you where you couldn't select a two byte delimiter, please show
> an
> example.
>
You easily win that one. Either:
o The data contain a record beginning with "++" in which case
GIMDTS will transform them. Or:
o The data contain no such record, in which case DLM='++' works.
But what became of the KISS principle? If the programmer invokes
GIMDTS, let it transform the data regardless of content. The
code becomes simpler; the documentation becomes simpler.
Why make any exceptions? IBM has stumbled into its own needless rule:
http://www-01.ibm.com/support/docview.wss?uid=swg1OW33063
... and apparently IBM reacted not by removing all exceptions, but by
removing the one exception that impacted the customer.
On 2016-01-06 19:13, Tom Marchant wrote:
>
>> Make it 64 or even 80 bytes!
>
> There are a lot of areas where z/OS could use improvement. I am unconvinced
> that the delimiter for in-stream data is an important constraint. Has anyone
> here
> ever coded JCL with in-stream data that they couldn't find a suitable
> delimiter for?
>
It's not a matter of whether it can be done at all but of whether it can be done
easily. For a delimiter of the size Charles envisions, using a random character
string from /dev/random (ICSF) with no selection leaves no practical exposure.
That's in the range used for strong encryption; good enough for NSA.
A more likely hazard is that the data contain a GIMDTS header. One looks like:
$$ GIMDTS FORMAT
That, too, could be protected by transforming the data with GIMDTS.
I imagine someone asking, "Why would a programmer want to use a file
beginning with such a record?" But that's rhetoric, best countered
with rhetoric: "What need has IBM to prohibit it?" Just to flout KISS?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
