On Sat, 5 Jul 2014 06:10:29 -0400, John Gilmore wrote:
>There is---I do not write with any inside knowledge---some prospect
>that Paul Gilmartin will not need to confront another option. A
>fairly obvious and 'easy' design option is that of making all
>arithmetic set-symbol values signed doubleword ones, and if I were
>laying bets it is the one I should bet that the IBM group in Hursley
>would choose.
>
That's the design option I'd choose.
And, I'd hope for64-bit support not ony for SETA but also for EQU.
A less 'easy' alternative would be to introduce types, and associated
instructions: GBLA32, GBLA64, SETA32, SETA64, EQU32, EQU64, ...
with the legacy forms equivalent to the -32 forms. And rules for
mixing types in expressions, and BIFs for conversion.
Or, a PARM option to select 64-bit capability. That would most
readily support ASMADATA compatibility.
What should you do if the decision were yours?
>En passant, let me also note 1) that this is not what I should do if
>the decision were mine and 2) that I do not share Paul Gilmartin's
>(and Microsoft's) view that options are bad. They are, on one view,
>inconvenient for developers; but the notion that there is a magic
>number that will meet [almost] everyone's needs seems to be to be
>delusional. Worse, perhaps, is that code tested only for one such
>magic value is very likely to break down when, perforce, that value is
>changed.
>
Of course, tests for a boundary value of 2147483647 would be partly
obsoleted and need to be replaced by 9223372036854775807, with
some retention of smaller values for 32-bit contexts (certainly
ADCONs with no length specifier sould remain AL4, not magically
become AL8.)
>Paul has lamented the card-image orientation of some IBM facilities
>here when his ox was the one being gored, but he has been slow to
>learn the larger lesson of such rigidities.
>
The TSO SUBMIT command could immediately be enhanced to open
the INTRDR with the attributes of the submitted data set with no
harm: merely some job images that now fail SUBMIT would be
submitted, perhaps to fail in execution.
The ISPF SUBMIT command could not be so enhanced: records
that are now truncated to 80 bytes would be submitted in full,
with unpredictable results. (I consider such quiet truncation a
data integrity flaw.)
>What can be conceded to his view is that options are not always for
>novices, that they should mostly be unobtrusive.
>
"Isn't it nice when things just ... work!"
http://www.youtube.com/watch?v=_ve4M4UsJQo&feature=kp
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
