1130 source to ECAP, Linear Programming System, Complex Variables Subroutine, Craps and other games

131 views
Skip to first unread message

Carl Claunch

unread,
Feb 5, 2015, 12:17:12 AM2/5/15
to ibm...@googlegroups.com

John R Pierce

unread,
Feb 5, 2015, 12:31:38 AM2/5/15
to ibm...@googlegroups.com
On 2/4/2015 9:17 PM, Carl Claunch wrote:
> Linear Programming System
> https://dl.dropboxusercontent.com/u/88601644/LinearProgrammingSystem.029
>

wait, I remember LPS/1130, I set that up on a disk on our school's 1130
back in the day, it was at LEAST a whole box of cards in binary, maybe
2. not sure what this is, but its not the whole LPS system by any stretch.





--
john r pierce 37N 122W
somewhere on the middle of the left coast

David Nagel

unread,
Feb 5, 2015, 1:34:16 AM2/5/15
to ibm...@googlegroups.com
IBM custom wrote a LP program for my employer back in 1967. This was my introduction to the  1130. Written in Fortran the source took up over a box of cards. Had a lot of fun with the system but didn't trust it further than I could throw it, all 2000 plus pounds of it. Eventually we evolved into a System/34 which was a good system also but not as much fun.

David Nagel


--
You received this message because you are subscribed to the Google Groups "IBM1130" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ibm1130+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Clare Owens

unread,
Feb 5, 2015, 9:15:16 AM2/5/15
to ibm...@googlegroups.com
The IBM "Big" linear programming system for the 1130 was much like ECAP, having many load on call subroutines and a complex common area.  in 1968 a customer of mine, Airco Speer Electrodes and Anodes in Niagara Falls, NY was installing an 1800 to do graphitizing furnace temperature monitoring (calculated from time/power formulas they supplied), power factor correction, power demand limiting and payroll (!?) but then decided they wanted to use the 1130 LP program to optimize the assignment of loads to furnaces.  There were two problems, first that the programs had to be recompiled since the 1800 Fortran common area is organized in reverse order to that of the 1130 Fortran.  Second was that IBM considered some of the really deep matrix manipulation LOCALS to be proprietary and thus would not release the source to us.  But we found that an SE down South somewhere had the "secret" sources in his closet at home and he compiled them for us on an 1800 near him. 

I have no idea how the Airco engineers formulated the problem but it ran once a week for several hours in the background and gave them good results.  Once a week was often enough since the "cycle time" from starting loading to completing the unload of a furnace was over a week.  As I recall they had four graphitizing furnace buildings and could have 6 or 8 furnaces on power at once, some on preheat and the rest at full power.  A LOT of thermal mass and those large rods had to be heated and cooled slowly to prevent cracking.  I still remember walking by their 34 megaVA transformer that serviced the whole plant site.  A real hummer!

Also, in the summer the streets between the graphitizing buildings and the machine shop building where they put the finishing touches on the big rods were graphite dust covered, which made them quite shiny and slippery.  That's when I had to start removing my shoes when I came home at night.

After a year or so we had tracked enough graphite dust into the computer room to have it begin to cause the 1800 to become "irregular" in operation.  Our CE Bill and his manager came out over a weekend with an air compressor and blew all of the dust out of the machine.  Our IBM management told Airco that if it happened again they'd have to buy the 1800.  So they became much more diligent about cleaning in the room and in the hall leading there.

Clare

gah

unread,
May 6, 2015, 2:55:34 PM5/6/15
to ibm...@googlegroups.com


ECAP - all these files are FORTRAN decks that are run to build up the program, in a zip file

Seems that these have been through an EBCDIC to ASCII conversion, but the source is BCDIC coded.
(Some OS/360 compilers accept cards in BCDIC form.)

sed and the following sed script will fix it.

s/%/(/g
s/</)/g
s/#/=/g
s/&/+/g
 
-- glen

Carl Claunch

unread,
May 6, 2015, 8:38:48 PM5/6/15
to ibm...@googlegroups.com
Yes, the Documation reader program uses the same ASCII encoding method as the IBM 1130 simulator. rather than recording files as Hollerith, they are converted via a table defined by Brian Knittel. There is an alternate format that records the hole patterns directly, which avoids any issue of code conversion since the card images would be exactly as distributed by PID. 

Carl

gah

unread,
May 18, 2015, 4:32:07 PM5/18/15
to ibm...@googlegroups.com

ECAP - all these files are FORTRAN decks that are run to build up the program, in a zip file


I have the ECAP book, which I think mostly describes the OS/360 version.

I wonder if it is the same source?

Somewhere I have a PDP-10 Fortran version of ECAP, which I presume was modified from the IBM source.
(It has OPEN statements and such.) 

Jeff Jonas

unread,
May 19, 2015, 7:33:22 AM5/19/15
to ibm...@googlegroups.com
> I have the ECAP book, which I think mostly describes the OS/360 version.
> I wonder if it is the same source?

For some reason, IBM 1130 FORTRAN arrays run "backwards"
(block ended by symbol instead of BSS: block started by symbol).
equivalencing arrays was a common trick to save RAM,
and using subsets of arrays.
That is non-portable code.

Is that documented by someone already?

gah

unread,
May 19, 2015, 2:42:28 PM5/19/15
to ibm...@googlegroups.com, je...@panix.com
Arrays ran backwards in Fortran starting from the 704, but that should not be visible to Fortran. 
It only matters when you interface to assembly programs. (I didn't know it was true on the 1130, though.)

The 704 index registers subtract, instead of add, so it worked better that way.
(EQUIVALENCE should still work the same way, as seen from Fortran.)
Also, it is convenient to allocate back from the end of memory.

-- glen 

Clare Owens

unread,
May 19, 2015, 9:29:28 PM5/19/15
to ibm...@googlegroups.com
As I wrote in this thread back on Feb. 5, the 1130 and 1800 Fortran compilers organized the common area differently so we had to recompile the entire 1130 LP/MOSS system on the 1800 so we could use it.  I think, contrary to my original note, that I may well have had the entire source on the tape that Carl had read for me.  But someone will have to do the compiles to know for sure.  Any takers?

Clare

--

Eddy Q

unread,
May 23, 2015, 1:35:07 PM5/23/15
to ibm...@googlegroups.com
I thought the reason they ran the arrays backwards was for allocation from end of memory. I think the reason they did that was so a program that ran on 4K would run on 8, 16 and 32K as well. I used a 7040 and I thought that was an upgrade from the 704. I wrote a lot of assembler and Fortran on the 7040 but don't remember them running arrays backwards.

Regarding EQUIVALENCE, it was not uncommon to do something like this (NAMA1 converts name code to A1). The programmer knew that arrays run backwards so he stores the program name into memory in the correct INTEGER*4 order and to get a pointer to the high order part of the name he could equivalence to the 2nd element of the array (I got this clip from some old code I have).
      INTEGER*4 NAMCD
      INTEGER NAME(2),WORK(18)
      EQUIVALENCE (NAMCD,NAME(2))
C                             PROGRAM NAME FROM CIH
      I = LOOK(123)
      NAME(1) = LOOK(I+19)
      NAME(2) = LOOK(I+18)
      CALL NAMA1(WORK,NAMCD)

This is one reason why it is difficult to use an automatic conversion program to convert 1130 Fortran to C.

On Tue, May 19, 2015 at 2:42 PM, gah <greatcea...@gmail.com> wrote:

--

gah

unread,
May 27, 2015, 4:40:21 PM5/27/15
to ibm...@googlegroups.com


On Saturday, May 23, 2015 at 10:35:07 AM UTC-7, Eddy Quicksall wrote:
I thought the reason they ran the arrays backwards was for allocation from end of memory. I think the reason they did that was so a program that ran on 4K would run on 8, 16 and 32K as well. I used a 7040 and I thought that was an upgrade from the 704. I wrote a lot of assembler and Fortran on the 7040 but don't remember them running arrays backwards.

Using standard (well, IBM standard) Fortran you should not notice that arrays go the other way.  If you get addresses of things, then you might find things that are unusual. 
 

Regarding EQUIVALENCE, it was not uncommon to do something like this (NAMA1 converts name code to A1). The programmer knew that arrays run backwards so he stores the program name into memory in the correct INTEGER*4 order and to get a pointer to the high order part of the name he could equivalence to the 2nd element of the array (I got this clip from some old code I have).
      INTEGER*4 NAMCD
      INTEGER NAME(2),WORK(18)
      EQUIVALENCE (NAMCD,NAME(2))
C                             PROGRAM NAME FROM CIH
      I = LOOK(123)
      NAME(1) = LOOK(I+19)
      NAME(2) = LOOK(I+18)
      CALL NAMA1(WORK,NAMCD)


I thought INTEGER*4 didn't come until S/360:


EQUIVALENCE should work in the appropriate way, such that you don't notice that arrays
index backwards. 

Eddy Q

unread,
Jun 4, 2015, 8:08:25 AM6/4/15
to ibm...@googlegroups.com
INTEGER*4 was a part of the IBM 1130 EMU Fortran compiler.

ga...@u.washington.edu

unread,
May 27, 2021, 8:13:35 PM5/27/21
to IBM1130
Is the ECAP source still available somewhere?  The link doesn't work anymore.

thanks.

dave....@gmail.com

unread,
May 28, 2021, 5:13:32 AM5/28/21
to ibm...@googlegroups.com, Carl Claunch

I took a copy,

https://1drv.ms/u/s!Ag4BJfE5B3onr2VU1YKK_ub1zBm8?e=UGhfb9

but its pretty raw. You need to replace several characters. I wonder if Carl ever cleaned it up.

Just the sort of thing for running on a replica 1130 if I ever get my FPGA one running again….

 

Dave

 

--

You received this message because you are subscribed to the Google Groups "IBM1130" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ibm1130+u...@googlegroups.com.

ga...@u.washington.edu

unread,
May 28, 2021, 8:43:12 AM5/28/21
to IBM1130
OK, got it.

Yes raw is fine. 

I have the PDP-10 version, which has had lots of modifications done to it.
Funny thing, there is one constant not used, which is the integer
value of EBCDIC characters.

But they used a lot of DEC extensions, which I hope to undo.

thanks!

-- glen
 

dave....@gmail.com

unread,
May 28, 2021, 9:01:52 AM5/28/21
to ibm...@googlegroups.com

Glen,

Please let me know if you get it running. I am thinking of building “blinken lights” simulation of the 1130.

Dave

 

--

You received this message because you are subscribed to the Google Groups "IBM1130" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ibm1130+u...@googlegroups.com.

ga...@u.washington.edu

unread,
May 28, 2021, 9:03:30 PM5/28/21
to IBM1130
Just wondering, does anyone know how much (code size) overhead there is for * ARITHMETIC TRACE?

It sounds like it would at a lot of code for each assignment statement.

It seems that all the ECAP routines use it.

Reply all
Reply to author
Forward
0 new messages