> ("mainly"? What else? UTF-8?)
I assume that "mainly of EBCDIC" refers to character data copied directly into
the message, a opposed to binary data converted to printable hex (also EBCDIC.)
> I assume that's Y(count),X'0000',up to 32,752 bytes of message text.
More like 120 bytes, with a secondary message if the buffer ends with "S".
> Isn't storage about a million times cheaper, which should accommodate
> more complete message texts?
There's no excuse for not including the dsname, member and path, but I have no
issue with using the SYNADAF text. However, the explanation of ASMA999U should
include a reference to, e.g., z/OS DFSMS Macro Instructions for Data Sets for
the format.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Assembler List <[email protected]> on behalf
of Paul Gilmartin <[email protected]>
Sent: Saturday, April 13, 2019 11:22 AM
To: [email protected]
Subject: Re: Lousy error from HLASM in USS
On 2019-04-13, at 07:57:41, Peter Relson wrote:
> I'd guess that you get this same error from a lot of places in z/OS, just
> not with ASMA999U as the prefix. Searching for "WRONG LEN RECRD" gets a
> lot of hits.
>
> Perhaps you ought to focus on the area that is likely to be changed (the
> documentation) rather than one that isn't (the code). The doc for ASMA999U
>
Times change. New capabilities entrain new responsibilities. The OP
discussed macros in a z/OS UNIX filesystem, where, for example not every
file can be identified by the 44+8 bytes once graven on stone tablets.
> ought to be improved. It should mention this extra information courtesy of
> the SYNAD processing (or at least point to a place where the extra
> information is described, and that description ought to explain what it
> means and in this case give some of the obvious examples).
>
Is there such a place? Following your hint about SYNAD(AF), I find:
https://secure-web.cisco.com/16f41FZirzko6SRYPy2Q3hZlS6VkpHuam-yvQ7kIm_wEmsBv4WX46Gawa3xTshvABqa9dirP1PLMTvJzreHUY61vir95wHjO32KSptirhkEk20QkstHraw8VKPyR7NW8PcQ2sfODokhAABy6ba9QxRb_kOJjLSqDZ3PgemgAj2nENuzPVEcvhNmZPmi_MFZ5RHaiNXYxwBmmZgDikaTLAr4DHth6tOIlsLGpsuP0nLiLUDkEWbUqAkTkM-SePZAFEDHa312k64seg5BTYMXZI3XRIVeOqjzlKOOq44wujsFwHFQ5jIslBHZdywtYnN-Lods50ud4gCOSTDqNHi64SpF_DXFjKbgGlmqN6QneIK-TXh2lX-Xx3P6Wkk6iY5GTpZZbktkKI81CkuXSeRu10pHVJfAjX-qAajsGKpkQ7nSketFFnhs3UraVgyXyCJxzT/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.idad500%2Fsyndf.htm
The SYNADAF macro uses register 1 to return the address of an area
containing
a message. The message describes the error, and can be printed by a later
PUT,
WRITE, or WTO macro. The message consists mainly of EBCDIC information and
is in variable-length record format. The format of the area is shown
following the
descriptions of the SYNADAF parameters.
("mainly"? What else? UTF-8?)
I assume that's Y(count),X'0000',up to 32,752 bytes of message text. That
suggests it might be PUT (directly?) to SYSTERM. Better be RECFM=VB. Is
there carriage control? A or M? What LRECL is required? Of course, if
that's documented somewhere it boxes the design in from providing additional,
better, information in the future.
In 1970, a programmer might know everything needed about OS/360. z/OS is
bigger; the programmer needs more help.
Isn't storage about a million times cheaper, which should accommodate
more complete message texts?
-- gil
