On 2016-01-05 15:26, Tony Harminc wrote: > On 5 January 2016 at 16:25, Paul Gilmartin > <[email protected]> wrote: >> But I think (I may never have tried) that SMP/E is GOFF-savvy. > > I'd say it's object-format-agnostic. It has no cause that I can think > of to be looking at the insides of what follows a ++MOD statement. > Hmmm... I suppose a GOFF module could contain the string ++MOD, and > that could get wrapped so it's in column 1. > (Or just "++".) I gotta try that. If it breaks, I'll SR it.
> Where have we met this one before? > For example NETDATA (TSO TRANSMIT) format is not SYSIN-friendly because "//" can land in column 1. In one instance, I looped through "DLM=??" values until I found a safe one for a particular NETDATA. I could uuencode it -- uuencode is SYSIN-friendly. And GIMDTS is intended to protect against "++" in data. But if the input is F-80 and contains no "++", GIMDTS simply copies to output. So one can not use GIMDTS to protect JCL elements in a PTF in SYSIN. Why!? (And GIMDTS wouldn't solve the GOFF hazard.) For that matter, if a data element, by happenstance, starts with an apparent GIMDTS prologue, SMP/E RECEIVE will try to extract it and almost certainly fail. But GIMDTS won't transform it if it contains no "++". Your IBM geniuses at work. -- gil
