In a recent note, john gilmore said:
> Date: Sat, 5 Jul 2003 15:52:25 +0000
>
> Thank you and OK. I understand now what you want to do. Complete
> generality would be difficult to achieve, but if you can specify the
> envelope of all of the MVS utilities you may wish in any circumstances to
> attach, then a simple Rube Goldberg solution to your problem is possible.
>
> First, you attach a driver subtask
>
> The driver subtask then attaches one or more subsubtasks, one for each
> previously envisaged utility you wish to use on some occasion AND posts the
> ECBs associated with the utilities you do not wish to use on that occasion
> complete.
>
Shouldn't be that complicated.
I envision a load module that I can invoke with LINKMVS which takes
as arguments an entry point name followed by the argument(s) for
the child task. (I have a lot of this code written elsewhere).
It can increment R1 by 4 to point to the child task arguments,
GETMAIN storage for an ECB and a TCB pointer, ATTACH the task
named in the original first argument, then RETURN with the address
of the GETMAINed block in R15. A separate entry point, called via
LINKMVS with that pointer as an argument, can perform the WAIT and
DETACH. The utility envelope is then freely expandible.
It's as easy for me to WAIT sequentially on individual ECBs as
to build a vector of pointers; I don't see performance as being
critical.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Fri, 25 Jul 2003 00:59:59 +0000
>
> If, like some COBOL programmers, you prefer 'positive logic', you may use
>
> //STEP1 EXEC PGM=IKJEF01
> // ICF (STEP1.RC = 0)
^
(I had assumed the 'C' was silent.)
> // THEN
> // <JCL for following steps>
> // ELSE
> // ENDIF
>
Works great; thanks!
`
I generally like to think positively. However, in this case
there's good rationale for the contrary formulation: it's
my coding habit whenever possible to put the shorter leg of
the IF (often just print error message and terminate) first.
I believe this reduces the likelihood of overflowing my
reviewers' cognitive stacks.
Concerning the several comments about IKJEFT01's not propagating
return codes, it's either simpler or more complicated than that.
I put "exit(5)" in my Rexx EXEC, which was the only command in
SYSTSIN, and it appeared in JESYSMSGS:
IEF142I VSSKY500 ALCFILES - STEP WAS EXECUTED - COND CODE 0005
Thanks again,
gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Fri, 29 Aug 2003 12:16:40 +0000
>
> > Only via the Binder.
> >
> I use it reflexively merely to move a program object from one PDSE to
> another, a load module from one PDS to another, or to convert load modules
> into program objects by moving them from PDSs to PDSEs and vice versa. It
> is very good at BPAM I/O. Moreover, it does what it is asked to do
> uncomplainingly. There are no barred windows and culs de sac of the sort
> that abound in IEBCOPY.
>
In the Bad Old Days of the Linkage Editor, when I was last faced
with this chore (for reblocking), the drawback to this technique
was that target load module was created with default values for
AC, AMODE, RMODE, REUS, REFR, ENTRY, ALIAS, etc. One needed to
extract these attributes with a utility such as AMBLIST and supply
them in PARM and SYSLIN to re-create the load module. Has this
process been simplified by the Binder?
It was even possible to supply a value for ENTRY on the assembler
END statement that could not be supplied via SYSLIN, creating a
load module that could not be replicated by re-linking. Has Binder
overcome this deficiency?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sun, 7 Sep 2003 20:07:58 +0000
>
> I was trying to be helpful, not flippant. I guess my problem is that
> 'restore' is not an SMP/E operation; there is no ++RESTORE.
>
Well, no, exactly. It's simply "RESTORE", not "++RESTORE":
# 21.0 "SMP/E V3R1.0 Commands"
21.0 Chapter 21. The RESTORE Command
At times, you may want to remove a SYSMOD that has been applied
to the target libraries. For example, perhaps you installed a fix
for a problem and got unexpected results. If you have not yet
accepted the SYSMOD into the distribution libraries, you can use
the RESTORE command to remove it from the target libraries.
... I'd say, rather, it _is_ an SMP/E operation; it's simply
a command rather than an MCS, which would have the initial "++".
But, for various rationales, one of which the manual cites in
an example above, it's useful to be able to RESTORE the status
quo ante any PTF. Various conditions prevent operation of
RESTORE, among them appearance of ++DELETE in the PTF you
are attempting to remove. This restricts the availability of
the useful RESTORE command, and is therefore undesirable.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Thu, 11 Sep 2003 12:22:43 +0000
>
> Moreover, checksumming---while very useful for detecting small 'random'
> transmission errors, bit dropping and the like---won't help you much here.
>
A strong checksumming scheme such as MD5 or SHA-1 is designed to
resist even malicious attempts to provide a known checksum with
erroneous or forged data and would with enormous likelihood
detect such an error. Similarly, by the very objective of its
design, it would do nothing to assist in correcting it.
> The Hamming distance between x'0000' and x'ffff' is 16, and even a hit from
> hard cosmic rays is unlikely to introduce such an error into a transmission.
> Something else is going in here.
>
Agreed, strongly. But often much goes on beyond multiple uncorrelated
single-bit errors.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Mon, 15 Sep 2003 12:57:20 +0000
>
> About the intuition that arithmetic operations are slower than boolean ones
> the only thing that can be said is, as usual: That depends. Arithmetic
> operations are slowed down by carry propagation; but carry propagation is,
> to put the matter politely, exiguous when the contents of a register are
> subtracted from the contents of that same register.
>
I recall a processor (I forget vendor and model) which had no XOR
instruction. The conventional software synthesis was ADD; AND;
SHIFT; SUBTRACT. If microcode did likewise (highly unlikely
nowadays), SUBTRACT could be faster by three entire microinstructions.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Fri, 26 Sep 2003 14:32:00 +0000
>
> The difference between UTC, universal coordinated time, and TAI,
> international atomic time, is currently 32 seconds, i.e., UTC is 32 seconds
> behind TAI.
>
> If your discrepancy is only about 20 sec, the omission of leap seconds from
> one set of timestamps is probably not the explanation of the systematic
> difference between them.
>
I believe IBM's TOD clock runs 10 seconds behind TAI. I suspect
the rationale (if any) is that they counted only chronicled UTC
leap seconds and ignored the era of chordwise corrections during
UT1, before the general acceptance of UTC.
I'm sure Greg Dyck will correct me if I misunderstand.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Fri, 7 Nov 2003 18:24:00 +0000
>
> Paul Gilmartin's notes, with heavy irony, that
>
> >Of course, for RECFM=V, setting BLKSIZE equal to LRECL is dreadfully wrong.
> > Has anyone tried for an
> >APAR on this?
>
> I am willing to bet an arbitrarily large sum that Bruce Black knows that
> LRECL+4 is used.
>
My irony is less heavy than you surmise, and tempered with unpleasant
memory and trepidation.
Until APAR OW46399 , the SDB for subsystem and HFS data sets was 80,
regardless of RECFM and LRECL. I encountered this when a well-exercised
Rexx EXEC that defaulted a BLKSIZE was broken (SYS 013-20) by OW43702,
intended to enable SDB operation for Rexx. After the usual fumbling, a
well-informed Level 2 recommended OW46399, which repaired the problem.
But Level 2 cautioned me that this was an unintended side effect of
OW46399 , and the documented behavior of SDB for HFS remained
unconditionally BLKSIZE=80, and that if another customer were to report
a problem, he would be obliged to restore the irrational BLKSIZE=80.
Level 2 was disinclined (or lacked the authority) to institute a change
in the specification of SDB for HFS.
<IRONY heavy> Level 2 further recommended that in view of the operational
changes made to exploit SDB, I should cease defaulting BLKSIZE and
always specify it for HFS.</IRONY> I've ignored the recommendation. I
suppose I might yet have recourse to Requirement, but I suspect the
Requirement might be rejected given the availability of a simple
circumvention, and, alerted to the inconsistency between the specification
and the behavior, IBM might find it expedient to re-break SDB for HFS
rather than bring the spec into conformance with the prevailing
satisfactory behavior (cf. Level 2's first cautionary remark). I choose
not to rock that boat. IBM has done similarly strange things to me in
the area of re-breaking once-repaired file attribute assignments.
I can cite only the text of the PMR; I never found the passage defining
SDB for HFS in UG/RM.
But, given this bizarre precedent, I could find Bruce Black's words
taken literally to be at least plausible, and could at best only hope
otherwise.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Tue, 25 Nov 2003 13:53:40 +0000
>
> > The invocations of the macros are in IEBGENER; the implementation
> > is in whatever Data Management is nowadays called. And the
> > implementation is wrong. It may be WAD, but the design is wrong.
> > If Boeing 737's regularly crash because the rudder goes awry,
> > the NTSB doesn't discover that the construction conforms to the
> > the design and declare the problem nonexistent. Similarly, if
> > PDS directories are regularly trashed because the design left a
> > pitfall, it's appropriate to seek a fix in the design rather than
> > shrug "WAD."
>
> To begin with a pedantry, a macro invocation is a macro instruction; and a
I stand corrected.
> macro implementation is a macro definition. In the context in which Seymour
By "implementation", I meant not only the macro definition but also
the Data Management code that implements the SVC, PC, or CALL that
macro instruction generates on expansion.
> used just 'macros' he meant and would be understood by coloro che sanno to
^^^^^^^^^^^^^^^^
Errr... doesn't that thread belong in ASM370-L?
> mean macro instructions.
>
> While I would not do so in anything but throwaway code, I confess thart I
> have more than once opened a PDS as PS in order to read a damaged directory,
> and the question whether I should be prevented from doing so seems to me to
> less simple than this characterization of it.
>
> What Paul is advocating is more strong typing: It's a widget and access to
> it as a gidget must be interdicted. My own view is different. Someone who
> is hellbent to shoot himself in the foot will always find ways to do so; and
> heavy-handed, anyway ineffectual machinery intended to protect him from the
> consequences of his own folly makes it harder for me to get my work done.
>
I'll grant you the right to clobber directories, and even DSCBs if
you're so inclined. The operation simply shouldn't be the default.
You should be required to code something such as "OPEN CLOBBER=YES"
to do so. BTW, how did your directory get damaged? Was it perhaps
because a colleague inadvertently allocated a PDS without specifying
a member name?
And I'm curious about Shmuel's METZCOPY. How does it avoid the
hazard? Is it a simple matter of coding the OPEN macro instruction
with the correct argument list? If so, I'll retract my rant and
agree that utilities should all be revised to use the safe form
of OPEN. If anything more complex, such as checking DSORG after
open and looking for a member name in the JFCB if PO, I'll stand
my ground and say that should be done by the macro implementation
(whether definition or Data Management (as it used to be called)
code).
And even the complex check can be done foolishly. Lately
I tried using a fairly new utility with:
//SYSUT2 DD PATH='/my/output/file',PATHOPTS=(OCREATE,OWRONLY)
.. OWRONLY seemed proper because SYSUT2 is described in
the RM as ony an output file. The utility ABENDed with a
permission violation. Why? Because the utility initially
opens SYSUT2 for input in order to prohibit DSORG=PO with
no member name. Presumably a more deliberate implementation
of the check in a central location on OPEN system code would
eliminate the desire for such haphazard implementation with
attendant sporadic failures.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sun, 14 Dec 2003 02:12:41 +0000
>
> These deficiencies were eventually remedied, and it was important that they
> be addressed and remedied. That it be impossible for an MVS application to
> detect that is is being executed under VM is neither important nor
> interesting: It almost always knows 'procedurally' that this is or is not
> the case.
>
There's a slightly better than pedantic argument. While building
a system, the developer is apt to rely on communication with the
hypervisor for debugging, tracing, or protyping of functions not
yet implemented in the targed system but supplied by the hypervisor.
This may rely on tests that distinguish virtual from native
execution. Final testing should be done in an environment in
which all branches take the same path as in a native system.
That said, I wonder about some possibilities not yet discussed
in this thread for detecting virtual execution:
First, instruction timing. A program might detect the virtual
environment by executing a privileged instruction a million times
in a disabled loop. This might well take one second in a native
system and a hundred seconds in a virtual system.
Second, CPU ID. I believe that IBM reserves a set of CPU IDs for
virtual guests, so virtual execution can be detected by storing
the CPU ID. Of course, the hypervisor could return a value from
the set of real CPU IDs (and should, for realistic emulation).
This should be dreaded by vendors who rely on CPU ID for enforcement
of license restrictions, and welcomed by customers who want a
license portable to Disaster Recovery sites, or to execute in a
DR or test environment CPU ID-sensitive code.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Mon, 29 Dec 2003 23:03:46 +0000
>
> It is possible to calculate the value of pi to any desired precision n,
> i.e., in such a way that the n-th digit of the approximation resulting from
> this calculation will be unaffected by further computations. It is NOT
> possible to calculate its exact value because, like all transcendentals, it
> does not have one.
>
Don't confuse the existence of a value with the possibility of
representing that value in any particular scheme. For example,
1/3 has no representation as a finite length decimal fraction,
but is readily represented as the three characters "1/3".
Likewise, 1/10 has no representation as a finite length binary
fraction, as many a novice programmer is astonished and dismayed
to learn the first and likely only time he codes:
for ( x = 0.0; x != 5.0; x += 0.1 ) { ... };
and the loop does not terminate neatly after 50 iterations.
There are many representations of real numbers. In perhaps the
most intuitive, a real number is one of the equivalence classes
of convergent sequences of rational numbers. _Exactly_ one of
these equivalence classes represents pi, and that is the _exact_
value of pi in that representation, quite as much as "1/3"
represents that fraction in the solidus scheme.
> It is possible, of course, to say that a definition of pi, Euler's or
> another, IS the value of pi; but this is only a form of words; and it is not
> the form of words that professional mathematicians use.
>
In my experience, that's very much the form of words that professional
mathematicians use.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Mon, 15 Dec 2003 15:24:30 +0000
>
> Let us now substitute R, a real machine, for H, a human, and V, a virtual
> machine, for C, a computer. Violŕ: VMT turns out to be a trivial
^^^^^
Sounds like an instrument of the mandolinisti.
> specialization of TIG, one that as such is of no great intellectual
> interest.
>
> It may sometimes of course be interesting to play TIG, but the notion that
> VMT 'is violated' when Q succeeds in catching out R as a real machine or V
> as a virtual one is not well formed. Facts do not violate theories.
> Theories are rendered untenable by inconvenient facts.
>
> For these and other reasons I am dubious about the prospects for an
> intellectually respectable VMT.
>
You and Shmuel make a persuasive practical argument, and I'll add
my own previously stated opinion that TIG is strongly biased in
favor of Q for any practical real-world virtual machine facility.
I suppose I was overly impressed by reading some decades ago an
article that argued that that the PDP-6 was not virtualizable
because of the JRST instruction which functioned as LPSW in the
supervisor state and as BR14 in the problem state, and was heavily
used in both senses. This made it impractical to implement a
virtual machine facility on the PDP-6. Certainly one could code
a PDP-6 simulator which would run on the PDP-6, and even defeat
Q at TIG, but I suspect even VMT adherents would disallow this
on a basis largely of performance and utility. But such arguments
are what you recognize as "not well formed".
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Thu, 15 Jan 2004 18:55:48 +0000
>
> This problem is, I think, misformulated. Worse, it is an example of seeking
> dubious external solutions to what are, properly, programming problems.
>
> If an output dataset is required for two quite different purposes, the
> program that writes it should write the same records to two different data
> sets, as for example the HLASM generates both a SYSLIN and a SYSPUNCH data
> set comprised of identical records.
>
On grounds of reusability, I'll favor the "external" solution. The
problem of multiple output destinations is a common one; it should
have a common solution. An old common solution is molti-part forms
with carbon paper -- your programming solution could have been used
rather than the "external" carbon paper solution -- clearly some
administrators have found the latter preferable.
The IEBGENER solution is reusable: for a few lines of code
you get an extra copy. Multiple JCL output statements are
even better -- only one line of code per additional copy.
I think Volker's naive wishful thinking is a good candidate
for a requirement: provide a DSN operand on the OUTPUT statement
to allow capturing the output to a data set. Even better would
be a change in the rules: If multiple DD statements have the
same DDNAME, and that DDNAME is opened for output, all should be
respected: the output should be replicated to all the indicated
destinations. (Will I need to use a certain G.B. Shaw quotation
if there are followups?)
Yah, I know this begs several questions:
o What if the attributes are inconsistent among the various
SYSPRINT DD statements? (I'd find OPEN error, or even
JCL error reasonable.)
o What if one of the several streams encounters an I/O error?
Enter SYNAD for any of them? (But, correspondingly, what
if there are multiple JCL OUTPUT statements and one of the
streams encounters an error?)
I find the UNIX "tee" facility an admirable common (and external)
solution to this common problem. And it avoids the 50% channel
bandwidth overhead of the IEBGENER approach, although it removes
from the core program any meaningful error handling capability.
And I suspect HLASM does as it does merely for want of a better
facility.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sat, 17 Jan 2004 18:25:40 +0000
>
> >RENT
> >
> > [ ... ]. (MVS protects your modules
> >virtual storage so that your module cannot be modified.)
> >Reenterable modules are also serially reusable.
> >
Is this true nowadays? Twenty years ago, I was astonished and
dismayed to discover that my programs, even marked with both
atomic options RENT and REFR could nonetheless modify themselves.
> >REFR
> >
> >A module can only be refreshable if all the control sections within it are
> >refreshable. The refreshable attribute is negated if any input modules are
> >not
> >refreshable. Refreshable modules are also reenterable and serially
> >reusable.
>
> Anciently there was a distinction, at least for system code, between a
> refreshable and a merely reentrant module: A reentrant module could modify
> itself if it held a global lock; a refreshable one could not.
>
Does there remain a distinction nowadays? The description of RENT
lacks the words about "all the control sections"; does a distinction
reside there?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sun, 18 Jan 2004 13:55:09 +0000
>
> In fact the traditional distinction between RENT and REFR was just that a
> RENT program could modify itself while holding a global lock and a REFR one
> could not modify itself in any way. Whether a (hardware) 'CD' [presumably a
> CDS, Compare Double and Swap --jg] would have constituted an acceptable
> surrogate for a global lock is discussable, but a (convention-based) ENQ
> would not have done so.
>
Hmmm. Can someone enlighten me? Why would "a (convention-based) ENQ"
be unsatisfactory to this purpose? I would think any scheme that
gurantees that no two threads pass throught the guarded path
concurrently would suffice. Of course, the ENQ can't specify
"RET=HAVE", and I assume the guarded path is not itself traversed
during processing of the ENQ macro.
Thanks,
gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Tue, 20 Jan 2004 14:25:09 +0000
>
> Some interesting December, 1991 text from SC26-4564-01, which for some
> reason is still availablke at the IBM publications website
>
> >If a module is to be refreshable, all the control sections within it must
> >be refreshable. If the refreshable attribute is specified, and any load
> >modules that are not refreshable become a part of the input to the linkage
> >editor, the attribute is negated.
>
There's a false assumption being made here which, in turn, negates
one basic function of link editing, namely the ability to update
a load module incrementally.
Suppose I have a load module which contains several refreshable
CSECTs and one not refreshable, and is properly marked not
refreshable. I decide to upgrade it by rewriting and compiling
the single nonconforming CSECT so it is refreshable and using the
following SYSLIN:
INCLUDE SYSPUNCH(new-csect) * now refreshable
INCLUDE SYSLMOD(old-loadmodule) * replacing non-refreshable CSECT
SETOPT PARM(REUS(REFR))
NAME old-loadmodule(R)
.. all to no avail because including the non-refreshable old-loadmodule
negates the REFR attribute, even though the offending CSECT is
replaced. This may be worth a warning and RC=4, but the REFR
attribute should be honored. Programmer knows best. Including a
non-refreshable load module in the linkage editor input does not
imply that the aggregate product will contain a non-refreshable
CSECT.
Such binder input is the paradigm for SMP/E, which implies that
SMP/E will never be able to upgrade a load module to REFR, barring
the cataclysmic "++ DELETE" command.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Wed, 28 Jan 2004 12:55:28 +0000
>
> The binder is its own 'load module editor'. It can accept its outputs as
> inputs (again), and it can alter the attributes of the new/replacement load
> module it outputs on this second occasion in response to the control
> statements you provide.
>
Yes, but as I believe we've discussed previously on this list,
that process has the drawback that the binder has no facilty
to copy from the input load module to the output load module
all attributes of the former not explicitly changed in the control
statements. Instead, the programmer must use a utility such as
AMBLIST to extract all attributes of the source load module, then
the programmer must compose control statements to reflect those,
mutatis mutandis, in the target load module.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Mon, 16 Feb 2004 13:46:59 +0000
>
> First, Hal Merritt has already noted that the SENDSITE toggle/modal is
> available for suppressing this message.
>
On a few hours consideration, I'll reverse myself, and throw in with
you on this. In other circumstances I've advocated the expedient
course: rather than attempting to determine in advance whether a
particular command is permissible and bypassing it if not, simply
issue the command and handle the error status intelligently. Not
only is this more efficient, but it avoids the (infinitesimal)
timing window: changes in the environment may affect the validity
between the probing and the issuing.
If the FTP command works to John Mattson's otherwise satisfaction
but he must deal with Datacomm folks charged with investigating
each and every (pleonasm) error message issued, he should tell
them to be grateful he's contributing to their job security.
There are two possible exceptions, both adverse handling of the
command by the server:
o The server deems "SITE LRECL ..." a serious syntax error and
declines to proceed with the transfer.
o The server accepts the nonstandard "SITE LRECL ...", but with
a semantic other than intended, and destructive.
That said, I hate toggle/modals passionately, particularly when
either or both of the following are true:
o The API in use provides no facility to query and act upon the
current state.
o The initial state is determined by administrator's whim, as
in a configuration file
The FTP client would do well to extend the syntax:
SENDSITE [INVERT|ON|OFF]
with omitting the argument retaining the current semantic of
inverting the state.
> Second, pleonasm and pleonastic are good words; but they describe dramatic
> redundancy, the use of gratuitous words, rather more, indeed significantly
> more, words than are required to convey one's meaning. The Alexandrian
> rhetoricians had another Greek synonym for otiose.
>
Thanks.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
>
> If now you DO NOT assign [default] values to these symbolic parameters in
> this procedure you can use SET statements to give them particular values for
> a particular invocation of that procedure, e.g.,
>
But don't get too fancy, lest you run afoul of:
5.4.2.1 "z/OS V1R2.0 MVS JCL Reference"
5.4.2.1 Defining and Nullifying JCL Symbols
* Do not specify JCL symbols within other JCL symbols.
The results can be unpredictable, especially if the
imbedded JCL symbol is not previously defined.
Correctly called "unpredictable". Before I learned the rule,
I had the construct variously both succeed and fail, even when
the imbedded symbol is previously defined.
A carefully designed facility of this sort would specify the
conditions under which imbedding is allowed, and report an
error on attempted misuse. JCL does neither.
What's the difference between "especially" unpredictable and
routinely unpredictable?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Fri, 5 Mar 2004 23:42:56 +0000
>
> Do not specify JCL symbols within other JCL
> symbols.
>
> seems to me to be unambiguous.
>
Granted.
> The usefulness of the SET statement is limited to the assignment of a
> CONSTANT value to a symbol. To relax this restriction would require,
> minimally, a lookahead facility; and it would open the door to viciously
> recursive, i.e., circular, definitions. Recursion has important uses, but I
> am doubtful that this is one of them.
>
I disagree. This need be no different from the semantics of
a simple PL/1 program with no branching or looping. At each
point of reference, the current value of a symbol is used.
The assignment happens after the evaluation, so no dangerous
recursion occurs, and no lookahead is required. For example:
X = 1
Y = 2
X = X + Y /* sets X to 3, no recursion */
Y = 42 /* this value is not used in the assignment to X, above */
> The SET statement nevertheless remains useful for assigning a constant value
> to a symbolic parameter, even a sequence of different constant values to it
> for multiple invocations of procedures in successive job steps.
>
Agreed, but it sacrifices some potentially valuable uses of assigning
non-constant values, such as:
// SET DSN='THIS.IS.A.LONG.DATA.SET.NAME'
// SET M1=&DSN(MEMBER1)
// SET M2=&DSN(MEMBER2)
//STEP2 EXEC PGM=IEFBR14,COND=(0,LE)
//DD1 DD DISP=SHR,DSN=&M1
//DD2 DD DISP=SHR,DSN=&M2
I've done some experimenting. I believe I can predict the current
behavior of an attempted imbedding of a symbol reference (but not,
as you said the behavior subject to possible changes in the processor).
It appears that the designers made some unfortunate choices in the
design of the lexical analyzer (perhaps misguided by a desire for
compatibility with other JCL features) which greatly limit the
usefulness of imbedded symbol references given the current behavior.
This could yet be undone, with no adverse consequences other than
to violators of the "Do not specify ..." stricture, and a useful
semantic provided for use of imbedded JCL symbols, if the designers
so chose.
> Moreover, while I am being testy, I will add that the name given to this
> thread was misleading. It led several posters to answer the wrong questions
> correctly.
>
I believe Dean Montevago used a Subject suited to his original
question; the topic has drifted, as so frequently happens. I'm
a principal offender. I've changed the Subject accordingly.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Tue, 18 May 2004 14:03:06 +0000
>
> Paul Gilmartin <gilmap@no-spam> writes:
>
> > Is it best simply to delete and reallocate the library?
>
> It is. Emptying a PDSE is only marginally better than emptying a PDS.
>
But, now Mark Jacobs comes forth with "STOW PDSE,,I". I hadn't
known of this. It's available only for PDSE. Might I not hope
this initializes the PDSE with an empty directory, exactly as
at initial allocation (even using the same code? Nah, this is IBM.)
so there should be no reason to prefer delete-and-reallocate?
Surely if the security auditors learn of this facility they'll
demand that it be disabled, even as IEHPROGM.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Thu, 27 May 2004 21:19:47 +0000
>
> Paul Gilmartin's logic is in a sense impeccable:The production of a single
> black swan suffices to refute the generality 'There are no black swans'.
>
Thanks.
> That conceded, the facility for specifying the explicit length of an A-type
> ADCON in the interval .1 to 4 is provided for use by those who know, and who
> presumably understand and intend the perhaps bizarre (but in some contexts
> useful) consequences of its untoward use.
>
At one time, AL3() was used pervasively, perhaps by both coloro che sanno
and mandolinisti. I suspect its vestiges are yet prevalent.
> Moreover, as Paul well knows, Chris knows these things. There is thus more
> empty rhetoric than substance in Paul's arguments: Ordinary A-type ADCONs do
> not cross page boundaries, and the production of pathological
> counter-examples does not change this.
>
I don't well know what Chris knows. But I was startled by his use
of "always" and "never" where you and I would more properly use
"ordinarily" and "pathologically".
But the nub of the discussion was my observation that for a NOPRIME
program object the page fault handler (ASM? DIV? Whatever?) must
be prepared to deal with ADCONs that cross page boundaries. I grant
this would be false if Chris's generality were true. But a successful
program must be able to deal with the pathological occurrence as well
as the ordinary.
I plead "not guilty" to the charge of "empty rhetoric" and stand
by my initial observation.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Thu, 15 Jul 2004 15:31:58 +0000
>
> call traverse(. . . . , exit_label) ;
> exit_label: ;
>
> I find this convenient; and it does not strike me as difficult to understand
> or notably unstructured or anarchic; but, as I have already had occasion to
> observe, these attributes are in the mind of the speaker/writer who uses
> them.
>
I'll agree with that. I'll further advocate any scheme that avoids
passing exit-label explicitly to intervening levels and does not
require intervening levels to test a return-code.
But the label must be in scope. Allowing a branch into a
syntactic loop construct (as C allows, or as was recently
proposed in a recent ASSEMLER-LIST thread on structured
programming macros) is bad language design.
There's some argument here in support of nested procedure
declarations, a construct which has declined with the ascendancy
of C. I suppose part of the reason is that with nested
procedure declarations the pointer-to-procedure type must
contain an identification of the related stack frame, a conceptual
block to many programmers and language designers. And OO
constructs have partly supplanted nested procedure declarations
because nested procedures often took the place of methods
associated with the containing stack frame. But an alternative
to the longjump is to call a procedure which exits by branching
to a label in the proper scope.
And Rexx's variable-hiding constructs are such that ITERATE or
LEAVE citing a control-variable of a loop in an ancestral
procedure ought to be feasible. Regrettably, that's not part
of the language specification. And if that procedure were
recursive there would be no way to indicate which instance
to exit to.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Thu, 5 Aug 2004 16:01:11 +0000
>
> Quine:
>
> condone the subliterate treatment of data,.media and agenda as singular
>
And this is compounded by those unaware of the collective character
of "medium", even in the singular. Three reels of tape or three
copies of a newspaper are not "three medias", nor "three mediums",
nor even "three media". Each comprises three units of a single
medium.
Hmmm. How about the common usage of "medium" to refer to one
possessing paranormal abilities? Are three clairvoyants properly
called "three media"?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Wed, 8 Sep 2004 21:36:22 +0000
>
> This syntax is, by the way, identical in PL/I and its dialects.
>
I hadn't been aware that you were such a Rexx expert. But now
I see: The BIFs are BOFs.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Wed, 29 Sep 2004 01:27:04 +0000
> >
> > it's not unlike ...
>
> Regrettably and inconveniently, IBM cannot be blamed for this one. It
> occurs in the Greek and Latin of major figures, in particular in a poem of
> Sappho that Catullus translated literally and perfectly into Latin.
> Moreover, the generic 'not un...' idiom is the subject of one of George
> Orwell's most celebrated and elegant diatribes. Something about a dog . . .
>
Google doesn't identify the Orwell for me. But I can't rest citing
a parody of this figure in "Hitchhiker":
"He had found a Nutri-Matic machine which had provided him with a
plastic cup filled with a liquid that was almost, but not quite,
entirely unlike tea."
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Mon, 4 Oct 2004 14:06:13 +0000
>
> 'executable image' is unclear; what is it an image of?)
>
Sorry; UNIX jargon.
> NE has its (very limited) uses; but it is one of the chief glories of the
> linkage editor and its successor, the binder, that they can reprocess their
> outputs, load modules and program objects respectively, as inputs. Without
> this facility it would be necessary to recompile or reassemble all of the
> locally supplied components of an executable every time a change was made in
> one of them (or, worse, to keep separate object-module libraries for all of
> them).
>
Here, you're describing SMP/E, which keeps object-module (actually
individual CSECTs in link-edited form) libraries containing all
components of controlled executables.
> I have observed schemes of this kind in use in (too) many shops, and their
> disabilities and implicit costs greatly outweigh the putative advantages of
> saving DASD space in libraries.
>
I would be less concerned with DASD space than with I/O overhead
at execution time. Is an editable load module so structured that
the editing information is isolated and need not be read (and
ignored) at execution time?
> attempts to compare the library storage requirements of different operating
> systems should usually be avoided: one needs to know too much to attempt
> them with any prospect that one will not make a fool of oneself.
>
Agreed, of course.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Tue, 5 Oct 2004 16:31:39 +0000
>
> The deficiency is not in the linkage editor or binder. It is in his reading
> of their manuals. I recommend that he consult the discussion of the REPLACE
> statement in z/OS MVS Program Management: Users Guide and Reference,
> SA22-7643-01.
>
I have some familiarity with "REPLACE", and I looked again at the
manual. I don't see how it's relevant to the requirement. Further,
in the SMP/E Commands Manual, I find:
REPLACE statement
REPLACE statements are saved in the LMOD entry and are associated with the DLIB module
name found on the next INCLUDE statement in the JCL. ...
... REPLACE statements are passed to the linkage editor only when the
associated DLIB module is to be replaced in the load module.
My problem is that the associated DLIB module is not being replaced in the
load module; rather I wish it to be added, and that does not happen merely
because I supply a new INCLUDE statement in the JCLIN.
> The question what SMP/E 'does' also seems to me to be misformulated here.
> The real issue is that of what the binder can be induced to do, and it can
> certainly be induced to reconstitute an LM or PO from its DLIBs. That being
> the case, the only relevant question here is whether some mysterious
> deficiency of SMP/E prevents its use to instruct the Binder to do this or
> some other job; and there are none such.
>
There are such. I have identified one, so it's not mysterious. You may
deny it's deficient insofar as it conforms to its specification. I
perceive it's deficient in that it fails to meed a customer need.
> How can the facilities that are provided be used to do what I want to do?
>
The best we've been able to do is to supply a "++ DELETE" MCS to cause the
LM to be deleted and reconstituted from its DLIBs. This is unsatisfactory
in that it is impossible to RESTORE a SYSMOD containing a ++ DELETE.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Tue, 19 Oct 2004 15:05:26 +0000
>
> The English (or, perhaps better, Greek-in-English) word for what in German
> is 'umlaut' is 'diaresis'.
>
Of course. But let's assume he wanted his posting to not get
quarantined by the Bell Helicopter netnanny.
How many Fridays can this thread span?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Thu, 30 Dec 2004 21:08:32 +0000
>
> Yes. Named constants may not [yet] be aggregates. Moreover, addr(<named
> constant>) is not supported, presumably because named constants are not
> always materialized.
>
addr(<named constant>) would be good cause to materialize the
constant. But there's a better reason to prohibit the construct
(and an associated argument favoring strong typing): once one
possesses a pointer to a constant, one may inadvertently assign
to the referenced object. There's good reason to prohibit
the assignment:
<pointer to variable> = <pointer to constant>
while allowing:
<pointer to constant> = <pointer to variable>
and:
<pointer to constant> = addr(<named constant>)
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sun, 27 Mar 2005 16:05:15 +0000
>
> I suspect, Paul, that I am being had, that you're trying to make some
> ulterior point; but the convention is illustrate in
>
> 'O''Hara'
>
Of course, I had already tried that, and it doesn't work. I suppose
we agree that's a "point". Is it what you consider ulterior?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Thu, 31 Mar 2005 20:04:36 +0000
>
> There are also audience questions. Ubiquitous GUIs have had the effect of
> dumbing things down. I still remember with some fondness a compiler for a
> PL/I dialect that had only one syntax-error message. It took the form
>
> xxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxx ;
> |
> eh?
>
Reminiscent of SMP/E's:
GIM20311E ** THERE IS A SYNTAX ERROR IN
THE CONTROL STATEMENT AT COLUMN 41.
.. except that the PL/I compiler affords the programmer at least
the convenience of a visible cursor indication, saving the need
to count 41 presses of the spacebar to find the location of the
error.
And I've seen worse: translators with diagnostics so unintelligible
that I've wished for the SMP/E or variant PL/I convention. If it
can't make it clear what it found wrong, it should at least tell
me where it found it.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Fri, 22 Apr 2005 16:53:25 +0000
>
> and his simile is imperfect. Some control blocks must still be resident
> below the line, and this difference is enshrined in the classic distinction
> belween A[ddressing]MODE and R[esidence]MODE.
>
> There are circumstances in which one must take care to ensure that storage
> is allocated below the line, but both GETMAIN and, more felicitously,
> STORAGE provide facilities for doing this; and their use does not entail or
> require the use of AMODE(24) code..
>
Don't some of those control blocks which must be resident below the
line contain 3-byte pointers to yet other below the line control
blocks, with the top byte containing flags? I grant that all the
operations can be done in 31-bit AMODE by masking the top byte
where necessary, but it's at least tedious, and an error-prone
conversion of existing RMODE(24) code.
I believe Edward Jaffe has provided a more complete answer. And I
believe at least some of the contributors to this thread would
prefer to be free entirely of 24-bit entanglements, whether AMODE
or RMODE.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Fri, 22 Apr 2005 20:59:51 +0000
>
> ... Maintenance of these subroutines is active and one way to avoid
> embedding obsolescent versions of them in applications, thus requiring,
> problematically, that they be relinked or rebound periodically, is
>
> o to make them all DLLs or,
>
> o better, to use a maintenance-insensitive transfer vector that resolves
> their NAMES at Link/Bind
> time but which itself is initialized dynamically for an application to
> reflect their locations on particular
> occasions.
>
> All this is easy to mechanize/relegate to macro instructions. I and others
> have done it many times. It merely adds another level of indirectness to
> subroutine calls, exits invocations and the like. The same pl;umbing can
> be used to address many apparently very different instances of what is, at
> an appropriate level of abstraction, the same problem.
>
Are the parameters to these services nowadays passed via 64-bit
addresses, or should we anticipate more conversion at that
transition?
It occurs to me that depending on 31-bit addresses is already
underreaching. No new interfaces should addresses shorter than
64 bits, even if the objects they refer to are currently required
to reside below the bar; in that case the addresses should simply
be padded with zeros on the left in anticipation of removal of
the constraint.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sun, 24 Apr 2005 15:52:46 +0000
>
> These qurestions are very much more complicated than you make them out to
> be.
>
Simpler is better. I view needless complexity as a design flaw.
> Moreover, the facilities now made available for PDSEs are very different
> from those still made available for PDSs. As an example of the former, an
>
Evidently. I just did the experiment in answer to Charles Mills's
question. On deleting the main name of a PDS member, the alias
names remain usable, even after compressing the PDS. On deleting
the main name of a PDSE member, the alias names vanish. I deem
this YA incompatibility between PDSE and PDS.
> As so often, you have here taken unsupported behavior that you judge
>
What's "unsupported"? (I recognize this is akin to asking for
proof of a negative by absence of positive evidence.) In:
# 2.2.54 "z/OS V1R6.0 DFSMS Macro Instructions for Data Sets"
2.2.54 STOW--Update Partitioned Data Set Directory (BPAM)
I see:
D
specifies that an existing directory entry is to be deleted.
For PDSEs, when the member name is deleted, all aliases for
that member are deleted.
documents the behavior observed above for PDSEs. May I not
assume that since PDSE is mentioned explicitly, but PDS is
not, the behavior is otherwise by design for PDS directory
alias entries? Or, is it unsupported that the leftover alias
entry is usable?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Tue, 26 Apr 2005 13:07:14 +0000
>
> >I discover by experiment that when I edit using the main name a
> >PDSE member having aliases, the aliases quietly vanish. What
> >"perceived PDS deficienc[y]" is this (new with PDSE?) behavior
> >designed to correct?
>
> I have been unable to reproduce this behavior in my own assembly language.
>
Thanks for the verification. (Falsification?)
> I can, however, imagine a scenario in which saving an edited/altered PDSE
> member was accomplished by (1) deleting the 'old', not yet altered version
> of that member and then replacing it with a new, altered member having the
> same name; and the use of this scheme would have the side effects tha PG
> reports.
>
That's also my hypothesis.
> I do of course agree that they should 'work' for source-programs members
> too; and I suspect that they do, i.e., that observed deficiencies in their
> behavior for source-program PDSE members are those of the particular
> (unspecified) tool used to maintain source libraries and not BPAM itself.
>
The editor was ISPF/PDF under z/OS 1.5 (and also one newer release).
The result is the same overwriting the member with IEBGENER.
What did you do in your assembly program? STOW? What operands?
Was the content actually changed? Did the aliases then identify
the changed content or the previous content?
IIRC, updating the user information in a PDS directory entry of
an existing member is a complicated operation. A colleague long
ago puzzled it out only by doing a GTF trace of ISPF's updating
user info. He then submitted an RCF, requesting that the procedure
be documented. IBM declined to do so. So, I had suspected that
for ISPF the need to update the user info was the basis for
deleting and re-creating the directory entry.
Thanks again,
gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Fri, 27 May 2005 22:35:28 +0000
>
> The JCL manual snippet quoted by Paul Gilmartin,
>
> > The system ignores all parameters other than DUMMY or
> > DSNAME=NULLFILE and DCB. The DCB parameter must be coded if you
> > would code it for normal I/O operations. ...
>
>
> specifies just exactly the behavior I describe above. Moreover, it does so
> in language that seems to me to be quite clear enough. In standard English
> the boolean operator AND takes precedence over the boolean operator OR: 'A
> or B and C' means '(A) or (B and C)'.
>
> Expanded, this snippet thus means
>
> o If you code DUMMY all else is ignored
>
I agree with your derivation from the UG. However, a simple
experiment shows the statement to be grossly wrong. The job
output fragment:
3 //STEP EXEC PGM=IEFBR14
//*
4 //SYSUT1 DD DUMMY,DISP=SHR,PATHOPTS=ORDWR
4 IEFC009I KEYWORD PATHOPTS IS MUTUALLY EXCLUSIVE WITH
KEYWORD DISP ON THE DD STATEMENT
This demonstration severely erodes the credibility of the UG: it's
impossible to have a conflict between parameters which are "ignored".
I'll presume further experiments are necessary to manifest the facts.
> Long ago Justice Holmes used the word 'relict' in an opinion, and when his
> law secretary suggested that it was not perhaps very well known his now
> legendary response was,
>
> 'May God twist my tripes if I will string things out for the delectation of
> fools'.
>
> This response was the right one. Dumbing down as a strategy doesn't work.
> It produces only a descending spiral of ignorance.
>
I'll take that cum grano salis. "Dumbing down" is an effective
pedagogic strategy. And here, a little stringing out could have
added value in clarity exceeding the cost of the verbosity:
If you code DUMMY, all other parameters are ignored; if you
code DSN=NULLFILE all other parameters except DCB are ignored.
.. an accurate paraphrase, except for the experimental refutation.
But "standard English" lacks mathematical rigor: an alternative
paraphrase might be:
If you code DUMMY, all other parameters are ignored; if you
code both DSN=NULLFILE and DCB, all parameters other than those
two are ignored.
.. in other words, if you code DSN=NULLFILE absent DCB, other
parameters are not ignored.
> o If you code DCB=NULLFILE, DCB information will be retained.
^^^
"DSN" (editorial correction -- gil)
>
The "and" operator is mathematically commutative. Is this likewise
true in "standard English"? What of the putative paraphrase:
The system ignores all parameters other than DUMMY or
DCB and DSNAME=NULLFILE. The DCB parameter must be coded if you
would code it for normal I/O operations. ...
By a derivation parallel to yours above, this results in:
o if you code DCB information, DSN=NULLFILE will be retained.
if you code DCB, all additional parameters other than DSN=NULLFILE
are ignored. I'm rapidly convincing myself that the text needs
stringing out. I know, I'm engaging in pedantry, but, PKB.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sat, 28 May 2005 21:35:56 +0000
>
> Before you draw any large conclusions about the equivalence of DUMMY and
> DSN=NULLFILE from your invesatigations, let me strongly suggest that you
> separate the JCL parse and its associated error messages from what happens
> afterwards. You are drawing conclusions from epiphenomena.
>
Readers of the list would welcome being enlightened by your sharing
the experiment you did to demonstrate the difference. I have
lately posted two experimental results, one of which, granted,
clearly dealt with "the JCL parse and its associated error messages";
the other equally clearly with "what happens afterwards." Each
directly contradicts what you inferred from the JCL UG.
> In the matter of my being beaten up, I think you should try.
>
???
That sounds like a challenge to take the topic from the metaphorical
to the literal.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Tue, 31 May 2005 15:16:36 +0000
>
> Once written within a procedure neither of the DD statements
>
> //<ddname> DD DUMMY
>
> or
>
> //<ddname> DD DUMMY, . . .
>
> can be altered into one that in fact is functional, permits non-null
> outputs to be written or non-null inputs to be read.
>
Thanks! I hadn't considered that. Now I'll know better.
> address the other, in my view more important, question of what is put into
> control blocks.
>
And on this question, I have yet no empirical evidence that, for example,
"DUMMY,DCB=..." behaves any differently from "DSN=NULLFILE,DCB=..."
I'm inclined to believe that the writers of the JCL manual were not
as adept as you at boolean algebra, and wrote text with incorrect
logical consequences.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Tue, 31 May 2005 15:16:36 +0000
>
> Quos deus perdere vult amentat. Anyone but the Pope needs to be safely dead
> to make such an argument.
>
I can find, "Quos deus perdere vult, dementat prius." (and I was vaguely
familiar with it.) Is "amentat" any different in sense from "dementat"?
I find two citations of your precise form, both in Italian, which
hardly helped me.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sat, 4 Jun 2005 14:44:04 +0000
>
> >You should, then, consider the alternative big jump: HFS instead of PDSE.
> >
>
> This is good advice iff the C or C++ programs (functions) involved are to be
> executed under
> USS. It is very bad advice if they arre instead to be executed undrer MVS
> (which I suspect to be the case here since the PDS-PDSE incompatibility
> problem is most unlikely to have arisen in a USS environment).
>
Thanks for the wise caution; I should have made that explicit. I would,
however, have qualified it to "... executed under _Classic_ MVS", since
Unix Services (quiet, Shmuel!) is also "under MVS".
> More interesting here is of course the implicit notion that UNIX is better
> than MVS. My own retrograde view is of course that it is not. I use it
> when I must, but it and its dialects are still radically immature,
> labor-intensive, and unreliable.
>
It depends. I find "make" far less labor intensive than writing JCL.
Of course, there's the added environmental concern: much portable
software comes packaged with the UNIX "make" trappings. I suppose
the latter was among IBM's initial motivations to provide Unix
Services.
The one apect of maturity that allows "make" to work at all is that
the OS maintains timestamps for all files. MVS is haphazard and
immature in this respect. However, SMP/E's process of tracking
dependencies outside of file attributes is more mature than "make"s.
I see more similarities between SMP/E and "make" than most observers.
Each has its advantages.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Fri, 17 Jun 2005 02:30:25 +0000
>
> >Yet I wonder, beyond uniqueness, can there ever be any perceived violation
> >of monotonicity?
> > Might one processor do a STCK, then send a signal to another processor
> >which, in turn does its
> >STCK and sees a value (including the TOD register content) algebraically
> >less than the one that
> >demonstrably happend earlier?
>
> Substituting STCKE values for at best obsolescent STCK values in the above,
>
I stand corrected; thanks.
> it is clear that for two STCKE values a, b
>
> a||<programmable value0>
> b||<programmable value1>
>
> and a < b,
>
I had thought that for different processors; more likely on different
systems (have I got that term right?) in a sysplex, it is possible that
a = b; in fact that is the rationale for providing the programmable
value -- it guarantees uniqueness overall. So, if the processor with
the higher programmable value does a STCK[E] very shortly before the
processor with the lower programmable value so a = b, the first STCKE
will store a higher value than the second. The question is whether
any event, or communication between processors, in so short an interval
(less than one clock tick) can manifest monotonicity violation.
> a||<programmable value0> < b||<programmable value1>
>
> obtains for all values of <programmable value0> and <programmable value1>.
>
> Consider
>
> <programmable value0> = 'zzz', <programmable value1> = 'aaa', it is still
> the case that
>
> a||'zzz' < b||'aaa'
>
> for all a < b. This, of course, is why the programmable field occupies the
> rightmost two bytes of an STCKE value.
>
> The triviality of this argument suggests that the thrust of Terence's
> injunction to think before one speaks has somehow been lost and needs to be
> recovered here.
>
All predicated on the assumption that a < b.
So, I RTFM:
Title: ESA/390 Principles of Operation
Document Number: SA22-7201-04
(I'm on a dialup connection right now and haven't access to the newer PDFs.)
I see:
# 4.6.1.4 "ESA/390 Principles of Operation"
_________________________________________________________________________
4.6.1.4 Setting and Inspecting the Clock
The values stored for a running clock always correctly imply the sequence of execution
of STORE CLOCK on one or more CPUs for all cases where the sequence can be established
by means of the program.
Which answers my question, for a single system, not necessarily for a sysplex.
Or does the restriction "a running clock" as opposed to "one or more running
clocks" leave open the question in cases where the model posesses multiple clocks?
Zeros are stored in positions to the right of the bit
position that is incremented. In a configuration with more than one CPU, however, when
the value of a running clock is stored, nonzero values may be stored in positions to
the right of the rightmost position that is incremented. This ensures that a unique
value is stored.
I'll assume that the nonzero values are necessary to ensure uniqueness, not
frivolous complexity, and thus that it's possible that a = b.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sun, 26 Jun 2005 13:13:04 +0000
>
> It is almost certainly too late to recover the legitimate use of 'oxymoron'
> here; but it is perhaps worth noting that its original and still its only
> legitimate use is as a rhetorical figure that states an apparent
> contradition and then shows that it is in fact no such thing.
>
I hadn't understood that; I'm not sure I do yet. Can you enlighten
us with examples of a fully legitimate oxymoron and a conventional,
illegitimate oxymoron.
> Use of 'oxymoron' in this sense has a long history, extending from the
> Alexandrian rhetoricians forward through Milton, Voltaire, Burke, and I. A.
> Richards. The cute folk etymology that relates 'oxymoron' to 'moron' has
> less weight, and it of course marks its users as uninformed.
>
It's more than a folk etymology. I understand that "oxy" means
"sharp" and "moron" means dull. So "oxymoron" is an onomatopoeia,
notional rather than phonic. (Is there a precise name for such a
figure?) A free English translation that nicely mirrors the sense
is "bittersweet".
And I had believed that the etymology of the English "moron"
was related; viz. cognitively dull.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sat, 16 Jul 2005 14:59:23 +0000
>
> My first comment was more anthropological than technical.
>
Somewhat akin to the election of "abbandonate" over "lasciate",
which is at least projectively anthropological.
> My feeling about the use of these redundant parentheses is thus akin to my
> feeling about the practice of wearing both a belt and suspenders/braces.
> Inelegant they may be, indeed certainly are; but there should be no
> sanctions against those who use|wear them.
>
Thanks for the clarification; it spared me the creative angst of
composing an apologia.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Tue, 13 Dec 2005 12:25:06 +0000
>
> Beware of the complications of daylight time, summer time or whatever if you
> use it.
>
I'll expand on this. In such locations, converting a 6-month-old
TOD value will more likely than not result in a value in error by
an hour. So:
If the timestamp already has CVTLSO applied, good; otherwise:
Use a table of the canon of leap seconds to correct for leap seconds.
Note that this depends on when the site may have installed a
Sysplex Timer -- prior to installation, the Leap Second offset
will be zero; afterwards, use the table.
Once you have corrected for Leap Seconds, the CRTL function,
localtime() can give the mostly correct local time in its format,
but beware yet:
o You must apply an affine transformation to convert microseconds
based in 1900 to seconds based in 1970.
o The granularity of localtime() is one second.
o The z/OS version of localtime() may give incorrect results for
timestamps older than about 1974, when the U.S. DST convention
changed. (But was there a TOD clock then?) Most OS other than
z/OS do better. A similar problem may arise circa 2007, when
it is proposed again to change the U.S. DST convention.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Mon, 19 Dec 2005 19:04:43 +0000
>
> Shiaoyun Wang has done it again! After breaking MD5 last year, she has now
> broken SHA-1. The NSA's own pridefully recommended encryption system now
> affords not even minimal security.
>
> Look to the situations in which you are using it, directly or at one remove.
>
From:
Linkname: Schneier on Security: New Cryptanalytic Results Against SHA-1
URL: http://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html
Shamir presented few details -- and there's no paper -- but the time
complexity of the new attack is 2^63. (Their previous result was 2^69;
brute force is 2^80.) He did say that he expected Wang and her students
to improve this result over the next few months. The modifications to
their published attack are still new, and more improvements are likely
over the next several months. There is no reason to believe that 2^63 is
anything like a lower limit.
But an attack that's faster than 2^64 is a significant milestone. We've
already done massive computations with complexity 2^64. Now that the
SHA-1 collision search is squarely in the realm of feasibility, some
research group will try to implement it. Writing working software will
both uncover hidden problems with the attack, and illuminate hidden
improvements. And while a paper describing an attack against SHA-1 is
damaging, software that produces actual collisions is even more so.
This is far from the Holy Grail of cryptanalysis, the "preimage",
the ability to generate a message given the hash code.
And I wonder, given an engine that enumerateS 2^63 160-bit bit
strings and the presumption that two are identical, how does one
locate the duplicates? Sort and look for a repeat?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Mon, 2 Jan 2006 19:24:30 +0000
>
> The most recent, 2005 October, '-04', version of the Principles of Operation
> contains an additional table row for the 2005 EOY leap-second correction,
> which was +1.
>
I stand corrected. Where can/should I have found this?
Necrodendritic media?
> By international convention leap-second corrections
>
> o may be inserted only at midnight of July 30th and/or December 31st of the
> year and
>
ITYM June 30.
> o must be for an integer number of seconds.
>
> They are not, that is, required to be positive or for only one second at a
> time.
>
From:
Linkname: NIST Time and Frequency FAQ
URL: http://tf.nist.gov/general/leaps.htm#Anchor-52904
What is a leap second?
A leap second is a second added to Coordinated Universal Time (UTC) to
make it agree with astronomical time to within 0.9 second.
I don't believe the 0.9 second constraint can be maintained while
inserting more than one leap second at a time. Proof is left as
an exercise for the reader.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Mon, 2 Jan 2006 19:24:30 +0000
>
> The most recent, 2005 October, '-04', version of the Principles of Operation
>
Ah! It's available only in PDF. I usually search only the list
of Bookmasters. Whenever I look at a PDF, I am reminded of how
relatively tedious it is to download and search a PDF.
I know your sentiments differ.
I suppose it's partly a matter of spending my CPU cycles versus
IBM's. But a PDF spends both our network bandwidths, also.
But another link concerning my assertion of the 0.9 second skew
limit:
Linkname: Systems of Time
URL: http://tycho.usno.navy.mil/systime.html
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Wed, 5 Apr 2006 22:00:49 +0000
>
> Transmission latency is easily measured and corrected for where it is
> important; and there are both theory and practice for doing so already in
> place, elaborated for use in adjusting and rationalizing the TAI values
> generated by the national observatories that form part of the BIPM network.
>
The most difficult case is where the round-trip path is asymmetric:
terrestrial in one direction, satellite in the other. NIST dialup,
at least, can detect this condition but not analyze it -- it refuses
to correct.
> Relativistic mechanics is more interesting that classical, Newtonian
> mechanics; but for the foreseeable future its use here is, unfortunately,
> otiose.
>
The applicable statement of Special Relativity is that no signal
can propagate faster than the speed of light. Generalizing
this to Tony H's practical case with far greater latencies,
the statement becomes, "As long as no signal used to coordinate
remote processes propagates faster than the signal used to
synchronize the clocks (even lacking any correction for
propagation delay), no temporal inconsistency can appear among
the various logs."
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Thu, 13 Apr 2006 15:26:11 +0000
>
> The notion that the Binder is a new, arcane and/or dubious piece of
> technology is a curious one. It can pretend to be the Linkage Editor,
>
With at least one exception. With Linkage Editor, I was accustomed to
an orderly termination with RC=0 when it encountered an empty SYSLIN.
Binder produces RC=12. I had to change a bit of code because of this.
I've never had much respect for IBM's handling of boundary conditions.
Apparently they're getting worse.
> Moreover, no effort to avoid putting load modules and/or program objects
> into either linkage-editor or binder inputs should ever be made. Both
>
But note that if I code the entry point on the assembler END statement,
it gets reflected in SYSLIN, and is effective in the load module.
If I then re-link, the entry point is lost. I believe the "INCLUDE -attr"
construct solves this imputed problem. And I recall you deprecated
"-attr" a while back in ASSEMBLER-LIST. But how else can IEBCOPY
employ Binder to convert between load modules and program objects?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Thu, 13 Apr 2006 18:04:23 +0000
>
> About '-attr', my earlier point was that this UNIX syntax, whatever its
> merits in its original home, is without merit in Binder control statements,
> which until its introduction had a very different, coherent syntax.
>
On that, we readily agreed in:
Linkname: Re: stable entry points in rebound modules
URL: http://listserv.uga.edu/cgi-bin/wa?A2=ind0407&L=asm370&D=1&O=D&X=71DC0A15CC83077DDC&Y=gilmap@no-spam
.. where you suggested:
If this facility is needed---I'm not sure it is---why not
introduce the new statement
| ATTRIBUTES ddname(member)
But you said earlier, in:
Linkname: Re: load module editor
URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0401&L=ibm-main&D=1&O=D&P=212825
the binder behavior [not replicating attributes] he [PG]
describes is not in my view broken or, if 'broken' cannot
at all readily and in my view should not be 'fixed'.
[ ... ]
Let me make my point in even more brutal language: the naif
use of the binder as a black box is and will I hope remain
problematic. Its workings must be mastered, but once they
are mastered it is a very useful tool indeed.
(registration required for each link).
Alas, I believe IEBCOPY needs to be able to use the Binder
as a "black box".
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Fri, 14 Apr 2006 14:19:23 +0000
>
> When I do I also use a pair of CONTROL statements. the first to increase the
> number of log buffers (I double them) and the second to restore the status
> quo ante.
>
If two such processes could execute concurrently, the number of
buffers could be left in an unpredictable final state. Is there
a lock to prevent this? I suppose it could be as simple as
incrementing and decrementing the buffer count with a Compare
and Swap.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Mon, 17 Apr 2006 15:53:45 +0000
>
> > > By experiment, this appears to be a restriction of the Linkage
> > Editor, but not of the Binder. z/OS 1.5.
>
> The operative distinction and restriction are not between object modules and
> load modules (or program objects). They are between sequential and
> "library" dataset organizations.
>
Thanks for the clarification, unnecessary to me in this case, but
always welcome. Better pleonastic than elliptical.
> (As usual a DD statement or the like that
> fully identifies the name of a PDS[E] member, which can be opened and read
> by QSAM, is treated as a sequential data set.)
>
But don't ignore the distinction between "As usual" and "Always".
Some facilities (e.g. TSO TRANSMIT) treat even "a DD statement
or the like that fully identifies the name of a PDS[E] member"
as a library allocation. In consequence, errors occur if the
DDNAME operand of TRANSMIT is a concatenation of PDS members,
unless one deceives the command by precatenating an empty
physical sequential data set.
This is Cowlishaw-think: a spurning of linguistic uniformity
that I often deplore and with which I am always uncomfortable.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Tue, 18 Apr 2006 14:50:27 +0000
>
> Two other IBM-supplied callable services are available:
>
> o STCKCONV converts arbitrary, in general non-current ETOD values into
> date-time ones; and
>
> o CONVTOD converts an STCKCONV date-time value [back] into an ETOD value.
>
> All three of these facilities make the necessary corrections for the
> peculiarities of the Grergorian calendar; the facilities they provide are
> comprehensive; and they should always be used in preference to homegrown
> conversion routines, which no non-specialist programmer ever gets right.
>
Do these likewise make the necessary corrections for Daylight Saving
Time and Leap Seconds? How do they deal with the uncertainty of
future leap seconds?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Wed, 19 Apr 2006 18:47:02 +0000
>
> STCKCONV and CONVTOD both use a table, the current instance of which can be
> examined on page 7-189 of the z/Architecture principles of operation
> publ.ication, SA-227632-04. (Worth noting is that this manual, published in
> 2005 September, already included the EOY 2005 leap-second entry.)
>
Good. Perhaps the schedule the publication deadline to match
the IERS announcement.
Heh. Heh. Heh. I wonder what happens if I give it an ETOD reading
corresponding to 2005-12-31 23:59:60.5? It should be allowed to
report Invalid Argument, since the z/OS protocol is to dispatch
nothing during the Leap Second, so no such value can be returned
to a program by STCKE. Of course, it could result from a
naive arithmetic operation.
And there is the matter that some sites may have implemented
leap seconds late in the process; at least later than the
origin of the table. Maybe it's best just to ignore that.
> These conversions are to and from ETOD and UTC, as I think they should be.
> Civil time is another kettle of fish/can of worms. I can imagine wishing to
> display it, but saving it is always and everywhere unwise.
>
Similar can of fish, merely requiring a larger table.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Wed, 19 Apr 2006 18:47:02 +0000
>
> STCKCONV and CONVTOD both use a table, the current instance of which can be
> examined on page 7-189 of the z/Architecture principles of operation
> publ.ication, SA-227632-04. (Worth noting is that this manual, published in
> 2005 September, already included the EOY 2005 leap-second entry.)
>
Hmmm. I've thought about this more. Surely there are z/OS releases
which went to field before IERS announced that leap second, and which
remain under support subsequent to that leap second. z/OS 1.6 likely
fits. For those releases, the table must have been updated after
GA. I'd guess this is by PTF. But a search of IBMLink for STCKCONV,
CONVTOD, and "leap second" severally finds no likely suspects. Just
curious, but does anyone know the PTF ID, or if not by PTF, how was
it done? Is the table extended automatically by the same process
that updates CVTLSO on command from the ETR?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Fri, 12 May 2006 11:18:55 +0000
>
> and JCL support for parameter values can differ too. (Failure to understand
> that the original model for the syntax of JCL was that of the HLASM macro
> language is the root of much trouble.)
>
Alas, one who starts from that understanding may be misled,
for example, by assuming that keyword arguments may be supplied
in arbitrary order. JCL does not allow this in all cases.
> Certain facilities may thus support the dubious practice of treating
>
> . . . ,parm=, . . .
>
> and
> . . . ,parm=<default value>, . . .
>
> as equivalent; but, I think fortunately, there is no mechanism currently
> avaiable for ensuring that all of them do so.
>
I agree with you (but is it possible to agree viscerally?) that
the latter form is safer. But when the latter form is not
syntactically available, I'll resort to the former. My first
statement was that all keyword arguments should have an explicit
default value.
And, regardless, the doc should not deny the validity of the former
when it is in fact accepted.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sun, 30 Jul 2006 13:12:44 +0000
>
> My favorite---storm warning of a big word to come---is their notional
> usefulness in avoiding homoeoteleutera; but others may well have their own,
> different favorites.
>
Congratulations!
homoeoteleutera - Google Search
homoeoteleutera__________________________ Search Advanced Search
Did you mean: homoioteleuton
No standard web pages containing all your search terms were found.
Your search - homoeoteleutera - did not match any documents.
©2006 Google
I'm trying to parse it as same/early/distant/good/??? with
little success. "Homoioteleuton" could be somewhat relevant
in that sequence numbers distinguish the endings of lines.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
(cross-posting, and setting Reply-to: ASM370)
In a recent note, john gilmore said:
> Date: Mon, 7 Aug 2006 21:06:27 +0000
>
> Paul Gilmartin writes:
> >
> > I'd be delighted to be able to supply an INCLUDE member
> > with all the strings we invite customers to change
> > provided as JCL symbols, so editing one line (no CHANGE
> > ALL) would properly affect every DD statement in every
> > step in every job template. And this makes me again
> > ardently wish for symbol substitution in instream data
> > sets, so that changing a single SET symbol could
> > make synchronized changes in the DD statements and the
> > UCLIN.
>
> These are reasonable, not at all ambitious functional requirements for a
> macro preprocessor. Unfortunately, JCL does not have a macro preprocessor
> and is not likely to be supplied with one.
>
> The traditional solution to problems of this sort was to write HLASM macro
> definitions.
>
> SYSGENs were, for example, implemented in this way. Users wrote a set of
> macro instructions which invoked these IBM-supplied macro definitions to
> generate JCL, utility control statements, source programs, and the like.
>
> This machinery is still in place. The HLASM macro language is now indeed
> much more powerful than it was when it was being used for SYSGENs. Using it
> would be a better course than bewailing the putative deficiencies of JCL.
> (Adlai Stervenson recalled, at her death, that Eleanor Roosevelt "would
> rather light a candle than curse the darkness".)
>
It's gotta be even older. A Google search finds many attributions
to a Chinese proverb. But the objective of lighting a candle is
to dispel the darkness whereas a curse is ineffective. And here,
the (minimally) effective kindling is a Requirement. Has such been
submitted? Does cursing morph into windmill-tilting?
But the darkness is pervasive. Lately I tried to acquaint myself
with AREAD, a necessary primitive to use of HLASM as a macro
processor. I had problems with the following test:
Loc Object Code Addr1 Addr2 Stmt Source Statement
1 MACRO
2 COPYIT
3 &X AREAD
4 MNOTE 0,'String was: &X'
5 MEND
6 *
7 PRINT MCALL,GEN
000000 00000 00000 8 START
9 COPYIT
10-O'Reilly
11+ MNOTE 0,'String was: O'Reilly
+
** ASMA163W Operand not properly enclosed in quotes
** ASMA435I Record 4 in SPPG.AREAD.JOB01703.D0000101.? on volume:
12 END
What must I do to process general input text with the assembler?
must I do my own lexical analysis, character by character?
I know Mr. Gilmore often avers that JCL syntax is derivative of
HLASM; the lexical conventions, quoting, symbol substitution,
and continuation are similar. But I anticipate problems when
a path name must be continued onto a separate line, or when
substitution moves a continuation mark into a column other
than 80.
Where should I look for further guidance?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sat, 19 Aug 2006 15:14:20 +0000
>
> There are ways to do what you want to do. They would be APARable as z/OS
> security breaches if they werje described in sufficient detail to be usable.
>
> The presence of bank vaults in the world means that there must also be
> locksmiths in it who can open them, and I suppose that there is a similar
> rationale for the skills needed to breach z/OS, but this is a public forum
> in which I for one do not think we should facilitate such operations by
> unknown people.
>
Certainly any system is breachable by:
o Brute force attack on a password.
o Physical access to the system. But that's ineffective if the
sensitive data are suitably encrypted; it devolves to a
password attack.
If you are aware of further ways that "would be APARable", I'll
suggest that it's your ethical responsibility, not to disclose
them or even hint of their existence in a pubic forum, but to
initiate the APAR. I'd guess Walt F. could suggest secure channels
for a PMR that contains information that shouldn't even be known
to IBM L1. (But how do we know that we can trust what Walt
appears to say, any more than the E-mails I regularly receive
telling me I must log in to revalidate my account)
Or are you suggesting that IBM by "a similar rationale" delivers
systems with intentional back doors, perhaps for use by service
personnel, perhaps master passwords? I'm sure that there are
sites which insist on means to seal any such back doors. And
perhaps other organizations, outside IBM, which insist, with
considerable coercion, that such back doors be left in systems
delivered to all customers other than themselves.
Hmmm. I wonder if there's an incompleteness theorem, akin to Gödel's
Proof, that any sufficiently complex system contains at least one
back door?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sat, 19 Aug 2006 20:28:56 +0000
>
> I have not exploited these weaknesses for fun or profit, and I will not do
> so, but I cannot as a practical matter spend time writing up a PMR every
>
There are so many?
> time I identify a possible security flaw. That is not my job. Moreover,
> although this is a species of 'trust me' argument from authority, I will add
> that other very experienced people known to me have similar war stories to
> tell.
>
Ethical customers should feel obliged to report such flaws, even as
ethical apartment tenants should feel obliged to report perceived
mechanical, plumbing, electrical, and, yes, security flaws lest their
peers be harmed by them.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Sun, 17 Sep 2006 15:33:03 +0000
>
> Here I have often advocated distinguishing kibibytes, 2^10 = 1024 bytes, and
> kilobytes, 10^3 = 1000 bytes, etc., etc.; but to say this is not at all to
> say that the original JCL design decision was an irrational one.
>
> ...
>
> The original JCL design decision was not irrational, but it was very much of
> its time, and we need this new distinction now.
>
Can we yet urge and hope that if IBM embraces abbrevations for
larger multipliers they can fall in line with IEC and use
"Gi" (or "GI" if they must commit another anachronistic deviation)
for 2^30 and/or G for 10^9?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
In a recent note, john gilmore said:
> Date: Mon, 9 Oct 2006 13:17:52 +0000
>
> Perlis's three-pronged formulation:
>
> A programming language provides mechanisms for
>
How do I shoehorn JCL into this?
> o identifying a data type or data types,
>
The data types I see are:
- Data sets
- The condition code
- (I'll exclude the SET symbols for reasons below).
> o specifying operations on them, and
>
- Utility programs such as IEBGENER, which perform operations
on data sets and set the condition code.
> o speciifying a path or paths of control among these operations,
>
- COND= and IF.
- But these don't affect SET, the only operation on SET symbols,
so I exclude them from the data types.
> has not been improved upon in, now, forty odd years; and it seems unlikely
> that it will be possible to replace it with a more perspicuous formulation
> anytime soon.
>
I see two important omissions here:
- If the path of control can not vary depending on values of the
data types, it's an unacceptable weakness.
- Lack of a facility for iteration (or, equipotentially, recursion)
impoverishes unacceptably the set of control paths. Here JCL fails.
> On Perlis's formulation LISP is a programming language.
>
And COBOL readily is. I'm confident also that a Turing machine
could be emulated in COBOL. Surely no technical case for Google's
omission of COBOL has been made in this thread.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@no-spam with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html