That looks like it's been modified to support load modules over 1MB, because
here's z/VSE's version:
A.5 Format of the REP (User Replace) Statement
Card Columns Content
1
X'02'. Identifies this as a statement of an object module.
2 - 4
REP -- Replace text statement.
5 - 6
Blank.
7 - 12
Assembled address of the first byte to be replaced (hexadecimal). Must
be right justified with leading zeros if needed to fill the field and must
be equal to or greater than the starting address of the control section
(columns 14-16). Note that there is no check to determine if the assembled
address is actually within this control section.
13
Blank.
14 - 16
External symbol identification number (ESID) of the control section (SD)
containing the text (hexadecimal). Must be right justified with leading
zeros if needed to fill the field.
17 - 70
From 1 to 11 4-digit hexadecimal fields separated by commas, each
replacing two bytes. A blank indicates the end of information in this
statement.
71 - 72
Blank.
73 - 80
May be used for program identification.
Man, this stuff is taking me down memory lane.
Later,
Ray
--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/
http://www.mrmullins.big-bear-city.ca.us/
http://www.the-bus-stops-here.org/
German is essentially a form of assembly language consisting entirely of far
calls heavily accented with throaty guttural sounds.
--ilvi
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Chris Mason
> Sent: Tuesday 18 April 2006 19:31
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Binder REP Cards (Was: What's the linkage editor
> really wants?)
>
> Eric,
>
> Similar but not identical.
>
> A REP card belongs to the days when you had a 2540 card
> reader/punch connected to your machine in the good old days
> of the 360 and 360 GT (aka 370).
>
> You submitted the compile job and went off to the coffee
> lounge. When you came back the object deck was in the card
> punch stacker. You wrapped it in a "link and go" job and
> tried it. One you had analysed the dump, you saw that you had
> made just one most trivial mistake. Rather than go though
> that long compile job again, you went over to the 029 card
> punch and "fixed up" the error with a REP card, slipped the
> card into the object deck just before the END card - or RLD
> cards - and tried again.
>
> Once you had got a working program - REP cards and all - you
> filed the deck away wrapped in an elastic band and with an
> explanation of what it was written with a felt-tipped pen in
> a colour which contrasted with the card colour.
>
> I was in a project once where, as the junior, I was in charge
> of the "library of past trials", the rubbish bin which
> nevertheless contained neatly stacked bound and marked decks.
>
> For completeness here's an explanation of what a REP card is
> from what appears to be the help text for the CMS LOAD
> command (clearly a non-proportional font is required to view
> it properly):
>
> <quote>
>
> Replace (REP) Statement
>
> A REP statement allows instructions and constants to be
> changed and additions made. The REP statement must be
> punched in hexadecimal code.
>
> The format of an REP statement is shown in the following
> figure. The data in columns 17-70 (excluding the commas)
> replaces what has already been loaded into virtual storage
> at the address specified in columns 5-12. REP statements are
> placed in the file either (1) immediately preceding the last
> statement (END statement) if the text deck does not contain
> relocatable data such as address constants, or (2)
> immediately preceding the first RLD (relocatable
> dictionary) statement if there is relocatable data in the
> text deck. If additions made by REP statements increase the
> length of a control section, an ICS statement, which defines
> the total length of the control section, must be placed at
> the front of the deck.
>
>
> +-------------------------------------------------------------
> ----------
> +----
> -+
> | Table 7. REP Statement Format
> |
>
> +----------+--------------------------------------------------
> ----------
> +----------+----
> -+
> | Column | Contents
> |
>
> +----------+--------------------------------------------------
> ----------
> +----------+----
> -+
> | 1 | X'02' (12-2-9 punch). Identifies this as a
> loader control
> |
> | | statement.
> |
>
> +----------+--------------------------------------------------
> ----------
> +----------+----
> -+
> | 2-4 | REP -- identifies the type of load statement.
> |
>
> +----------+--------------------------------------------------
> ----------
> +----------+----
> -+
> | 5-12 | Hexadecimal starting address of the area to be
> replaced as
> |
> | | assigned by the assembler. It must be
> right-justified in these
> |
> | | columns with unused leading columns filled with
> blanks or
> |
> | | zeros.
> |
>
> +----------+--------------------------------------------------
> ----------
> +----------+----
> -+
> | 13-14 | Blank.
> |
>
> +----------+--------------------------------------------------
> ----------
> +----------+----
> -+
> | 15-16 | ESID (External Symbol Identification) -- the hexadecimal
> number |
> | | assigned to the control section in which
> replacement is to be
> |
> | | made. The LISTING file produced by the compiler
> or assembler
> |
> | | indicates this number.
> |
>
> +----------+--------------------------------------------------
> ----------
> +----------+----
> -+
> | 17-70 | A maximum of 11 four-digit hexadecimal fields,
> separated by
> |
> | | commas, each replacing one previously loaded halfword (2
> |
> | | bytes). The last field must not be followed by a comma.
> |
>
> +----------+--------------------------------------------------
> ----------
> +----------+----
> -+
> | 71-72 | Blank.
> |
>
> +----------+--------------------------------------------------
> ----------
> +----------+----
> -+
> | 73-80 | Not used by the loader. This field may be left blank or
> program |
> | | identification may be inserted.
> |
>
> +----------+--------------------------------------------------
> ----------
> +----------+----
> -+
>
> </quote>
>
> 73-80 What rot. As everyone knows, columns 73-80 are sequence
> numbers in case there's a fumble when trying to slip on the
> elastic band. <g>
>
> Information from (
> http://mitvma.mit.edu/cmshelp.cgi?CMS%20LOAD%20(ALL ) where,
> just to show how close to AMASPZAP all this is, I see that
> there is also a VER card.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
