Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!INFONODE.INGR.COM!blumen
From: blumen@INFONODE.INGR.COM (Dwayne Blumenberg)
Newsgroups: comp.lang.asm370
Subject: Re: Problems with Assembly
Message-ID: <9106270300.AA12365@ucbvax.Berkeley.EDU>
Date: 27 Jun 91 03:01:12 GMT
References: <9106262214.AA04667@ucbvax.Berkeley.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: IBM 370 Assembly Programming Discussion List
              <ASM370@OHSTVMA.BITNET>
Distribution: inet
Organization: The Internet
Lines: 63

In article <9106262214.AA04667@ucbvax.Berkeley.EDU> you write:
>Hi - I'm just getting started in Assembly language programming on an
>IBM 4381 using DOS/VSE (actually, an equivalent of DOS/VSE called MVT/VSE
>from some third party company which isn't important).  I'm mentioning this
>for background.  The problem I am having is I don't seem to be
>able to define a large blocksize in a file using DTFMT (for tapes).  At
>first I was thinking that this is a limitation of the assembler, but I would
>tend to think that assembly wouldn't be very restrictive of such things.
>My question is therefore, is there a maximum tape block size that I can
>use, what is it, and is there something extra that I need to add to the
>assembly to let the system know beforehand that I'm about to define a lot of
>storage for buffer-IO area.  I've asked two company-internal people this
>question and the answers I received were (1) People don't use Assembly with
>tapes, so it was never set up that high anyway and (2) I think you have to
>recompile your open and close macros.  (both of which seem a little on the
>outer edge of reality).
>
>All help and insight will be greatly appreciated.
>
>...wilso_d@cs.odu.edu

Well, it's been a few years since I worked with VSE (and I never worked
MVT/VSE), but I don't remember any restrictions for tape blocksizes (not
below 32k anyway).  Just guessing, but I suspect you didn't take into
account that the big blocksize would run beyond what you can address
with one or two base registers.  If that's the case, you're probably
getting addressability errors during assembly.  If so, here are a few
ways to get around the problem:

1.  GETMAIN (or GETVIS?) the buffer storage at run time and use registers
    in the I/O macros to point to the buffers.  To use register format,
    you normally just use the register in parenthesis where you would
    have used the buffer label.  Ie.  (R5) instead of BUF1.  Of course,
    avoid using registers that the macro uses internally, like R0,
    R13-R15, and possibly R1.  See your IBM macro reference.

    - or -

2.  Move the DSs for the buffers to the very end of your program.
    Get the address of the buffers using "L Rx,=A(buffer)" in
    your program and use registers in the I/O macros to point to
    the buffers.
    Note:  Using "LA Rx,buffer" won't work (the linkage editor is
    really doing the work for the "=A").  Also, be sure to use an
    LTORG directive *BEFORE* the buffer DSs.

    - or -

3.  I seem to recall that DTFs can be assembled separately (SEPASM
    option for the I/O macros?).  If so, you can assemble the DFTs
    separately or in a different CSECT and reference them in the
    main program using EXTERNs or V-type constants.

Solution #1 is probably the best choice, but #2 is probably the
easiest for a simple program.  I'm sure there are other solutions
as well.

Dwayne A. Blumenberg
--
Dwayne A. Blumenberg            | Internet:  b17d!dwayneb!dwayne@ingr.com
MVS Systems Programmer          | UUCP:      ...uunet!ingr!b17d!dwayneb!dwayne
Intergraph Corp., M.S. IW17D1   | Voice:     (205) 730-7785
Huntsville, AL  35894-0001      | FAX:       (205) 730-7509