Paul Gilmartin <[email protected]> wrote:
>
> On 2019-04-15, at 10:28:03, John McKown wrote:
>
> > Hope I'm not too off-topic on this discussion, but now I'm curious what
> > Dignus' Assembler, DASM, would report in this instance.
> >
> They provide a web-based trial, http://www.dignus.com/cgi-bin/assemble.cgi
> which for:
> START
> DC C'..|....+....|....+....|....+....|....+....|....+....'
> ...+....|junk
> END
>
> ... reports:
> Assembler command & output (error/warning messages):
> dasm -flisting=/tmp/1265.lst /tmp/t1265.asm
>
> DASM Dignus Systems/ASM - version 1.95.11
> (c) Copyright Dignus, LLC 1994-2019 All rights reserved.
> DASM is licensed to Dignus,LLC (Linux).
> dasm: /tmp/t1265.asm line 2:DASM900W Input line too long, truncated
> dasm: /tmp/t1265.asm line 2:DASM144E Begin-to-continue columns not blank
> dasm: /tmp/t1265.asm line 2:DASM435I Record 2 in /tmp/t1265.asm
> dasm: /tmp/t1265.asm line 2:DASM140W END record missing
> dasm: /tmp/t1265.asm line 2:DASM435I Record 2 in /tmp/t1265.asm
> DASM Return code 8, 2 Warnings, 1 Error, elapsed time 0.00 seconds,
> object code size X'34'.
>
> Kind of irrelevant, because in z/OS BSAM/BPAM detects the problem and
> HLASM never sees it. What does HLASM under Linux for z do?
>
> -- gil
>
Thanks for posting that!
Let me add that we also have the -fnolonglines option that
turns that DASM900W message into an error instead of a warning
(so that the assembly would fail to match HLASM's failure.)
This is also how the Dignus assembler would act with a USS
file on z/OS, since it uses the Dignus C runtime that
uses direct BPX routines to open/read/write USS files.
- Dave Rivers -
p.s. The reason you're seeing the DASM140W END record missing
message is because the BATCH option is not enabled, and
you have a dangling blank line after the END statement
(indicating the start of another object deck.)
--
[email protected] Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
