[comp.lang.asm370] Problems with Assembly

wilso_d@wisteria.cs.odu.edu (DeWitte Wilson) (06/27/91)

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

blumen@INFONODE.INGR.COM (Dwayne Blumenberg) (06/27/91)

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

SOMITCW@VCCSCENT.BITNET (06/27/91)

 On Wed, 26 Jun 1991, xanth!cs.odu.edu!wilso_d@LLL-WINKEN.LLNL.GOV said;
>                     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).

    The maximum blocksize is 32760 for EBCDIC, 2048 for ASCII.
  What blocksize are you attempting?

    If you could be more specific about how you are unable to define
 a large blocksize, someone could probably help you quickly.
 An error message perhaps?  An addressibility or syntax error?

    I haven't worked with VSE for seven years, but my guess of your
 problem is that you are defining the I/O buffers with 'DC' instead
 of 'DS', or you are not putting the I/O buffers after all other
 code, constants, etc.  GETVIS is a much better place for I/O buffers
 than putting them in a program.  I believe the system will allocate
 your I/O buffers in GETVIS if you don't code them in the program.
 Or is that only for disk?  You can also allocate I/O buffers in GETVIS
 if the system doesn't do it for you.