Small assembler program

[Bob Flanders]

Ages ago, I wrote some programs for the 1130 that did direct I/O (using XIO and processing interrupts.) That was easy, but I never figured out how to use the DISKn routines. I read the manuals but never figured out how to connect connect the FILE statement with the IOAR of when calling a write routine. 

I decided to play with it and finally got something to write to working storage. Here's the program and the output. 

FWIW....

Bob

[Richard Stofer]

That was an education! Back in the day,  I just wrote Fortran.  I never had to think about dealing directly with the hardware.

 

Then came the bit about putting a ‘1’ in column 19 of the XEQ card.  This isn’t well documented in the books I have – it is barely mentioned in “Elements of IBM1130 Programming” by Price and then only in the table of linker errors.

It is also shown in the “IBM1130 Disk Monitor System, Version 2 Programming and Operator’s Guide” after Price describes the R22 error.

 

Nevertheless, it works on hardware.  Later on, I’m going to read the file back and print the contents to the console.  I want to be certain the data was actually written.

 

Richard

--
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/groups/opt_out.

[Bob Flanders]

So, you tried the program on the hardware emulator, and it worked? Cool.

I dumped WS with // DUP (See attached.) and the contents looked appropriate.

On Brian Knittel's emuloator, I just say "do asm" and this works. I created a DMS disk callsed "dmsBF.dsk" with 1403 and 2501 support. but this program  should run on any DMS disk.

Thanks!

Bob

[Richard Stofer]

Works fine!  The dump looks right…  My hardware also emulates the 1403 Printer and 2501 Card Reader.  I chose these because the data transfer is based on DMA and that was easier to implement.  And faster…

 

My problem was with tabs versus spaces and column alignment.  These problems could have been inserted by my editor.  My sources have to be in exactly the proper column with only spaces, no tabs.  I probably should have used Notepad.

 

Richard

--

[John R Pierce]

On 1/21/2014 11:10 AM, Richard Stofer wrote:

My hardware also emulates the 1403 Printer and 2501 Card Reader.  I chose these because the data transfer is based on DMA and that was easier to implement.  And faster…

hahahah, an 1132 emulation would be /awful/

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

[Bob Flanders]

On the emulator, there's an option to reformat cards read based on tabbing. There's Assembler, Fortran and regular 8 space tabs, hence the poor" formatting... but easier to type.

[Richard Stofer]

I imagine it is FAR easier to type.  Keeping track of the various columns for assembly language programs is a huge pain.

 

I need an editor that has programmable tabs – kind of like the 029 card punch programming card.  There needs to be a saved setup for each type of coding.

 

From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf Of Bob Flanders
Sent: Tuesday, January 21, 2014 12:15 PM
To: ibm...@googlegroups.com
Subject: Re: [IBM1130] Small assembler program

 

On the emulator, there's an option to reformat cards read based on tabbing. There's Assembler, Fortran and regular 8 space tabs, hence the poor" formatting... but easier to type.

 

[John McKee]

A friend told me about genie.  It can produce source in multiple formats.  I don't know how hard it would be to create a format.  Maybe not all that involved.

John McKee

--

[Bob Flanders]

I thought I would write a few notes about FirstDisk.

1. I did some testing and I the FILE statement is not needed. When reading the Monitor document, I was thinking that the FILE statement, when referenced by the *FILES(FILE1,,) command without a file name would save the address of working storage in WSSCT. It didn't. I checked this by adding a DUMP command right after start and dumping the program WSSCT remained zero.

2. DISK1 and DISKN (which I did not try) both check if you are writing anywhere on the disk except working storage. It's called "File Protection". The first LIBF to DISK1 uses operation /2001 which means "Write. This sector address in IOAR is an OFFSET from the start of working storage". So the program writes to the first sector of working storage (offset 0). If you want to write anywhere, you have to use DISKZ, but you can ruin a disk with it. 

3. Looking at the code for DISK1, the ERROR routine is only called if there is a hardware error. It's not "Hey, your program just made an error." If your program makes an error, the DISKn routine exits to the monitor with a code in ACC. For example, I started with the value /2000 for the write operation. It took a while for me to realize the system was exiting with /5001 in the ACC because I was trying to write to sector zero, not working storage. Needed /2001 for WS.

4. I don't think the TEST (/0000) calls to DISK1 and WRTY0 are needed. I don't think the routines that write data return until the operations are complete. I may try removing them later, but it doesn't really prove what the real system would have done.

Finally, when reading DISK1, I was surprised at the spaghetti and self-modifiction techniques. I shouldn't have been. They used every trick to save space and make it as fast as possible.

If you are interested, DISK1 can be found in the file 1130SW\dmsr2v12\pmonitor.asm that comes with the emulator -- line 4383 or so. I also suggest having some Excedrin extra strength nearby.

Bob

[Richard Stofer]

I tried it without the FILE statement or the FILES card and it seems to work fine.  I changed the data so that I wasn’t reading something left behind.  I also recompiled a lengthy program hoping to overwrite WS before testing again.

I don’t think either of these are required.

 

I’m pretty sure that the disk driver just sets up the operation and returns.  There will be an interrupt later on and it will reenter the program and do whatever is required.  $DBSY marks the disk routine as busy.  It is set to allow 16 retries.  I’m pretty sure you have to do the test before you can start another operation.  Regardless of what the code does, the hardware gets a command block by way of the XIO instruction and autonomously deals with it.

 

Here’s a fun scenario:  Hardware that isn’t known to work, no real debugging platform (JTAG would have been nice) and booting hangs.  It was a simple fix but it took a while to get there.  Fortunately, I built a breakpoint facility into hardware using the console switches.  I could set an address, run to the breakpoint and then single step.

--

[Bob Flanders]

That's a cool feature.I don't know if the emulator can do that.

To clear (or change) WS, you could use DUP and do a *STOREDATA to put cards images in WS.

I think you are right about DISK1. It does an XIO then goes to D1150 .. no looping waiting for IO to complete. That means you could call to write... do some other stuff then check if it's done. Or just test before calling the routine. I wonder if it would get upset if you called to write then returned to monitor.

I'm amazed at how much information is missing from the 1130 docs, at least for assembler. You have to read the docs very carefully, or you can miss vital information. Sometimes, information is not in the place you expect.

Over the years, I bought some books... Programming the IBM 1130 by Hughes and Programming the 1130 and 1800 by Louden. Both are mainly Fortran books. What assembler they have says nothing about writing to disk. Now I think I know why the authors didn't try to write about it.

Bob

[John Doty]

On Jan 21, 2014, at 6:41 PM, Bob Flanders wrote:

I think you are right about DISK1. It does an XIO then goes to D1150 .. no looping waiting for IO to complete. That means you could call to write... do some other stuff then check if it's done. Or just test before calling the routine. I wonder if it would get upset if you called to write then returned to monitor.

If my memory serves me, the monitor will loop on $IOCT until it's zero. That insures it doesn't do anything stupid (like overwrite an ILS or ISS) while I/O is in progress.

John Doty              Noqsi Aerospace, Ltd.

http://www.noqsi.com/

j...@noqsi.com

[Peter Sawyer]

That is consistent with my recollection. $IOCT must be zero for $EXIT to proceed. And the ISS routines all returned control while the operation was in progress. Waiting on a write was needed to be able to reuse the buffer for other data. Waiting on a read, well, that is pretty obvious. ;)

[Bob Flanders]

You are right. $S300 in pmonitor. Loops until $IOCT is zero.

I saw your web site... you did FORTH. You (probably already) know
where that name comes from?

IBM 1130 was the first FORTH interpreter.

I wrote a system for MCI (Site Controller") in FORTH. LMI FORTH,
specifically. Had all the miserable complexities fully implemented. ;)

Bob

[Bob Flanders]

Well, now I feel like this day has been way too long. Don't mess with
the output buffer 'til it's written.

Maybe it's a good thing that I didn't know how to use these routines before now.

:D
Bob

[John Doty]

On Jan 21, 2014, at 7:21 PM, Bob Flanders wrote:

> I saw your web site... you did FORTH. You (probably already) know
> where that name comes from?
>
> IBM 1130 was the first FORTH interpreter.

Yep. The classic FORTH model of arithmetic comes from the 1130: product of two cells is a double cell, dividends are double while divisors are single, ...

My little stripped-down portable FORTH will be taking a ride to an asteroid in a couple of years!

[John Doty]

On Jan 21, 2014, at 5:02 PM, Bob Flanders wrote:

1. I did some testing and I the FILE statement is not needed. When reading the Monitor document, I was thinking that the FILE statement, when referenced by the *FILES(FILE1,,) command without a file name would save the address of working storage in WSSCT. It didn't. I checked this by adding a DUMP command right after start and dumping the program WSSCT remained zero.

I believe FILE is there to emulate FORTRAN's "DEFINE FILE" statement so that you can share data in WS between FORTRAN and assembly language programs. I don't recall I ever used it. You might find "DSA" more useful: it'll give you the sector address of a named file.

Note how strange this is from a modern perspective: "DSA" makes the *linker* responsible for "opening" a disk file!

Finally, when reading DISK1, I was surprised at the spaghetti and self-modifiction techniques. I shouldn't have been. They used every trick to save space and make it as fast as possible.

"Structured programming" hadn't been invented back then. Self modification was pretty common, a practice left over from first generation hardware, although the 1130 had most of the features (such as index registers and indirect addressing) that made that unnecessary. But then there was the BSI instruction.

[Richard Stofer]

“Elements of IBM 1130 Programming” by Winston T. Price is ALL about assembly level programming.  Fortran is only mentioned in passing on page 36.

http://www.alibris.com/Elements-of-IBM-1130-programming-Wilson-T-Price/book/2000997?matches=5&cm_sp=works*listing*title

 

Richard

 

 

From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf Of Bob Flanders

Sent: Tuesday, January 21, 2014 5:41 PM
To: ibm...@googlegroups.com

Subject: Re: [IBM1130] Re: Small assembler program

[Bob Flanders]

The funny thing is, you can't write to any already-defined file unless
you use DISKZ. all files are in the File Protected Area of the disk
for DISKN and DISK1.

Very cool about going to comet. Can you encode a hex 'BOBF' in the
program somewhere so I can ride along? ;)

Bob

[John McKee]

What I dimly remember is that DISKN allowed for multiple sectors to be transferred at one time.  Beyond that, what is the point to using DISKN or DISK1 if they can't write to defined files?  Does the restriction only apply to previously created files? 

John McKee

[Bob Flanders]

Richard,

Thank you! I just ordered a copy.

Bob

[Bob Flanders]

I think that IBM figured if you want to write to existing file, do so
at your own risk and use DISKZ. Then file, DSA, etc become valuable,
but know what you are doing. If you only need scratch space, use DISKN
or DISK1.

[John Doty]

On Jan 22, 2014, at 9:44 AM, Bob Flanders wrote:

> The funny thing is, you can't write to any already-defined file unless
> you use DISKZ. all files are in the File Protected Area of the disk
> for DISKN and DISK1.

// JOB T

Then you can create an unprotected temporary file with DUP's DFILE.

>
> Very cool about going to comet. Can you encode a hex 'BOBF' in the
> program somewhere so I can ride along? ;)

Sure. We'll see if it survives code review. I did manage to encode my kids' birthdays in the HETE-2 (gamma ray mission) software a few years ago ;-)

[Richard Stofer]

Quoting from "Elements of IBM1130 Programming":
" A special feature of the Monitor System is that of file protection. All
disk I/O subroutines check to make certain that writing on the disk is to
take place in the Working Storage area. Thus, the programmer cannot
inadvertently wipe out a portion of the Systems Area or User Area. However,
there are two exceptions to this. First, a special function called Write
Immediate will cause information to be written wherever the access mechanism
is positioned without making any check. Second, data files that are built
up in Working Storage can be moved into User Area with the appropriate
statements.
"The reader should recognize that these safeguards int eh Assembly language
are software-provided and are not part of the 1130 System Handware"

DISKZ is intended for use with Fortran programs because it doesn't make
checks for correct calls. Instead it relies on the compiler to make the
proper calls. DISKZ was not intended to hold the programmer's hand.

What would be more interesting is creating more than 1 file in working
storage. At this point, I suspect that the assembler FILE statement and/or
the *FILES card will become important because there has to be some kind of
offset over the first file to the beginning of the second file.

For those who really want to get their hands dirty working with assembly
language and hardware devices, Chapter 17 of "Elements..." has an airline
reservation system written in assembly language. It begins with creating a
file from cards that contains flight numbers, seats available in first class
or coach and fare for first class or coach. It progresses to using the
console to make reservations on the flight by updating the data file. It's
certainly not a complete solution to airline reservation but it's an
interesting bit of code. Maybe tomorrow...

I have so much to learn about the 1130. I thought I had it down pretty well
but that's just because my Fortran code worked. I certainly never had to
drive devices.

Richard

-----Original Message-----
From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf
Of Bob Flanders
Sent: Wednesday, January 22, 2014 9:02 AM
To: ibm...@googlegroups.com
Subject: Re: [IBM1130] Re: Small assembler program

[John Doty]

On Jan 22, 2014, at 2:39 PM, Richard Stofer wrote:

> DISKZ is intended for use with Fortran programs because it doesn't make
> checks for correct calls. Instead it relies on the compiler to make the
> proper calls.

Also system programs, not just Fortran. DISKZ was the disk driver that was in core by default.

[Peter Sawyer]

The DISKZ interface, a BSI to DZ000 (decimal 242, /F2) was supported by
DISK1 and DISKN, so code written to use that calling method would work no
matter which DISKx version was in core. Writes using that interface could be
done anywhere. DISKN was able to support multiple operations on multiple
devices, but was also fast enough to read consecutive sectors without
missing a revolution of the disk. When Fortran programs had large SOCAL
overlays, it was sometimes worth it to run them with DISKN. Despite the
smaller available memory, the execution time could be better.

BTW, when the DISKx sub was being switched (that was done by the CIL, phase
2 @CIL2 (/A1)), there was a visible WAIT during the disk read. Neat to see
on the console lights.

----- Original Message -----
From: "John Doty" <j...@noqsi.com>
To: <ibm...@googlegroups.com>
Sent: Wednesday, January 22, 2014 11:35 PM
Subject: Re: [IBM1130] Re: Small assembler program


>

[John McKee]

I can't remember now, this could have been during COBOL compile or during CLB.  But, there were two different pitches of buzzing from the drive.  Bit 13 in the accumulator extension would be on for one sound and off for the other.  No idea which way the head was moving when the lamp was on or off.  Wish I could have watched it like I could on the 1401 system.  I miss the sounds of that drive.

John McKee

To unsubscribe from this group and stop receiving emails from it, send an email to ibm1130+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
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+unsubscribe@googlegroups.com.

[James Field]

I remember imitating the solenoid sound of the 1130 disk drive to my friends when I was in College. "buzz...buzz click.
I used a sputtering sound with my voice to imitate  solenoid action as the read/write head progressed.
Has anybody ever recorded the lovely "seek and read" sounds of one of the earliest mechanical predecessors of the Winchester" drive?


Jim

On 23/01/2014 11:35, John McKee wrote:

I can't remember now, this could have been during COBOL compile or during CLB.  But, there were two different pitches of buzzing from the drive.  Bit 13 in the accumulator extension would be on for one sound and off for the other.  No idea which way the head was moving when the lamp was on or off.  Wish I could have watched it like I could on the 1401 system.  I miss the sounds of that drive.

John McKee

On Wed, Jan 22, 2014 at 11:21 PM, Peter Sawyer <peter....@sympatico.ca> wrote:

The DISKZ interface, a BSI to DZ000 (decimal 242, /F2) was supported by DISK1 and DISKN, so code written to use that calling method would work no matter which DISKx version was in core. Writes using that interface could be done anywhere. DISKN was able to support multiple operations on multiple devices, but was also fast enough to read consecutive sectors without missing a revolution of the disk. When Fortran programs had large SOCAL overlays, it was sometimes worth it to run them with DISKN. Despite the smaller available memory, the execution time could be better.

BTW, when the DISKx sub was being switched (that was done by the CIL, phase 2 @CIL2 (/A1)), there was a visible WAIT during the disk read. Neat to see on the console lights.

----- Original Message ----- From: "John Doty" <j...@noqsi.com>
To: <ibm...@googlegroups.com>
Sent: Wednesday, January 22, 2014 11:35 PM
Subject: Re: [IBM1130] Re: Small assembler program

On Jan 22, 2014, at 2:39 PM, Richard Stofer wrote:

DISKZ is intended for use with Fortran programs because it doesn't make
checks for correct calls.  Instead it relies on the compiler to make the
proper calls.

Also system programs, not just Fortran. DISKZ was the disk driver that was in core by default.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com

--
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/groups/opt_out.

--
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/groups/opt_out.

--
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.

[Peter Vaughan]

Here you go... a small snippet of the disk test from our machine @ TNMOC

- Peter

[John R Pierce]

On 1/23/2014 10:55 AM, James Field wrote:
> I remember imitating the solenoid sound of the 1130 disk drive to my
> friends when I was in College. "buzz...buzz click.
> I used a sputtering sound with my voice to imitate solenoid action as
> the read/write head progressed.
> Has anybody ever recorded the lovely "seek and read" sounds of one of
> the earliest mechanical predecessors of the Winchester" drive?

some kids made motorcycle sounds, us nerds made disk drive noises. heh.

[Norman Jaffe]

When I worked with an IBM 1800, running process control software, we could tell what program was running by the sounds coming from the disk drives.

[Jeff Jonas]

>> I remember imitating the solenoid sound of the 1130 disk drive

> some kids made motorcycle sounds, us nerds made disk drive noises. heh.

We're the last generation to enjoy such
electro-mechanical devices such as

- computers with card readers, line printers,
paper tape reader & punch
- floppy drives
. the Apple ][ used to slam the heads upon booting,
a prominent sound effect in a Disney movie
indicating "I started up the computer"
. the PC stepped the floppy drive in 41 steps, back 40
to distinguish 40 from 80 track drives.
(I always enabled that BIOS feature because it
delayed the boot enough for me to press an F-key)
. sometimes you heard the disk spinning inside the envelope

around the home, there were unique sounds for
- dialing a rotary phone
- changing the station on a TV with mechanical tuner
- a phonograph record's lead-in, lead-out

[Philip Leonard]

On 1/23/2014 2:31 PM, Jeff Jonas wrote:
>>> I remember imitating the solenoid sound of the 1130 disk drive
>
>> some kids made motorcycle sounds, us nerds made disk drive noises. heh.
>
> We're the last generation to enjoy such
> electro-mechanical devices such as
>
> - computers with card readers, line printers,
> paper tape reader & punch

I was explaining to one of my younger coworkers just today about how in
school we punched our programs into cards and the card deck was
processed at night on the school's mainframe (IBM 360/20) after all the
"normal" night job's were finished. He stared at me in amazement.

[Richard Stofer]

Here's what I think I learned from the Airline Scheduling program in
"Elements..."

Create a file of 17 sectors named 'SCHED' in User Area from trash in Working
Storage
*STOREDATA WS UA SCHED 17

The next project is to populate the file with real data. Ignoring the
specifics of reading cards, converting data and 3 records per sector, etc,
here's how it works:
In the assembly code there is a statement 'DSA SCHED'. The instruction
generates 3 words (after the program is linked): The length of the file in
words, the first sector number on disk and the sector count.
The assembler doesn't need to know about the file. The linker fills in the
values. I put a core dump instruction at the top of my code and came up
with this:
/1540 -- length in words which should be 320 * 17 - and it is
/025C -- first sector on disk and my *DUMPLET shows the DB address as /25C0
- which is correct (16 blocks per sector)
/0011 -- the sector count - this is exactly the 17 sectors defined when the
file was created

So, the assembly program first reads a sector of the file (it knows the
first sector and can calculate the others) and makes no intervening seeks.
It updates the values in the sector buffer and then does a /4000 (write
immediate) to update the sector.

Sure, you can use DISK1 or DISKN to update a file in UserArea but the key
word is UPDATE.

BTW, no FILE statement or FILES card is required for the above. I need to
read more about these. I know how to use the FILES card for Fortran but I
have no idea how to use it with Assembly Language.

As I get further along, I want to see how to create multiple files in WS and
then how to move them to UA. My guess is that the FILE statement becomes
important.

Richard

[Jeff Jonas]

On Thu, 23 Jan 2014, Philip Leonard wrote:
> I was explaining to one of my younger coworkers just today
> about how in school we punched our programs into cards
> and the card deck was processed at night
> on the school's mainframe (IBM 360/20)

> after all the "normal" night jobs were finished.

> He stared at me in amazement.

Before the "personal computer",
the CPU was a precious resource that was SHARED, in BATCH mode :-0
Then the "personal computer" gave folks the expectations that
everything was immediate and resources weren't shared.

Now we're back to shared mainframes with "cloud computing"
and "cloud storage". If cycles or bandwidth becomes limited,
we'll be back to the old days of
calling after 8 when the rates are lower,
or overnight batch jobs :-/

Once network neutrality is taken away,
that'll hasten the digital divide
of the cheap seats from the box-seats.
Line up for those gigabytes, folks :-/

[Clare Owens]

I was the SE at Airco Speer in Niagara falls in 1968-1970 and their 1800 had 6 drives.  One day I put in a pack and could clearly hear that the heads were hitting the disk as it spun up.  Kind of a tisk, tisk, tisk sound.  So of course I turned it off immediately and called for a CE to take a look.  The heads had worn the magnetic coating off of the disk at one spot but all that was needed was a good head cleaning and the drive was fine.  Ah the good old days :-)  I still have the disk from one of those packs or maybe from the packs used on the Series/1 out in the garage.  And a couple of 8 inch floppies.  Also a whole stack of the new, shiny nickel plated ones in three different diameters from modern drives.  No drive leaves here (or where I used to work as long as I was there) intact.  A combination of data security concerns and loving those magnets.  Just took one drive apart today and have two more to go. 

Clare

[John R Pierce]

On 1/23/2014 12:38 PM, Philip Leonard wrote:
> I was explaining to one of my younger coworkers just today about how
> in school we punched our programs into cards and the card deck was
> processed at night on the school's mainframe (IBM 360/20) after all
> the "normal" night job's were finished. He stared at me in amazement.

I play CD's in my car, my 23 year old son laughs at me.

of course, my 19 year old daughter has a Walkman cassette player jacked
into her 1987 Volvo's car stereo so she can play these vintage cassettes
she finds at thrift stores, hahahahaahah. who's laughing now? (the
Volvo is my wife's old car, bought new, has 400K+ miles on it). I put
some really good back speakers in that 240 about 6-8 years ago.

[Jeff Jonas]

combining several replies:

> ... One day I put in a pack and could clearly hear that the

> heads were hitting the disk as it spun up.
> Kind of a tisk, tisk, tisk sound.

I still dread head crashes since it's MAD:
Mutually Assured Destruction of the drive & platters.
It's not just hard drives: the iomega Zip drive
"click of death" was a head crash by any other name.

And it's back :-(
I was using an external 1 terabyte hard drive for backups.
It was jogged while running. DEAD!
No way to scrape off the remaining bits either.

Sadly, my "rings of Saturn" head-crashed platter disappeared.

Whatever happened to all those disk platter cleaning machines?
A fellow used to visit the computer center
with a machine that cleaned and inspected diskpacks.


re: telling what's running by the sound of the disk seeks

That's the side effect of contiguous-only file allocation.
I worked on an IBM system 3 with Memorex diskpacks
where the cylinder was displayed in binary.
The system OCL (Operator Control Language) allowed specifying
the number of tracks and absolute location,
so the cylinder display was easily translated into
file and offset. Sure made it easy
to monitor the progress of programs
that scanned the master file sequentially!

Dynamic file allocation has taken that away,
but LVM (logical volume manager) has kinda brought it back!


re: shared vs. non shared resources

Replying to myself:
the IBM system 1130 was a "personal computer"
when used interactively, such as APL, or using the front panel.
It was /normally/ used in batch mode since that's the
familiar assembler/Fortran environment
and it's fairer when sharing it among many people.
Had there been a file editor
and the compilers taken input from files the same as cards,
THEN things would've been a lot more interactive!

The main obstacle was lack of connectivity to external systems.
Punched cards were the primary input and output,
particularly with off-line editing
via the room full of keypunches.

1) None of the IBM 1130s I used has the SCA (modem).
(Even the college's PDP11/45 was used in isolation,
connected only to local peripherals: printer, terminals).
An interesting side note: I found notes that
clever folks used the SCA to generate timer/clock interrupts
for primitive time-sharing systems.

2) That's why I'm so fascinated by the
IBM 1800 variant and the System/7 attachment:
it was specifically for interfacing to other things.

3) the platters were unique to the IBM 1130:
could not be read on other systems due to hard sectoring
and formatting, even if it physically fit.

That's why most systems were isolated communities.
Until BBS (dialup bulletin board systems) and the Internet,
there was no common link or data exchange method
among different machines or makers.

That made archiving 1130 things harder!
I scanned some IBM 1130 user group newsletters:
http://ferretronix.com/1130/newsletters/
Does anyone have the software they mention
such as the "smogarboard" disk of shareware/open-source?

My web page is:
http://ferretronix.com/1130/


re: the sounds of the peripherals

Some of the IBM 1130's peripherals (Selectric console, plotter)
have simple interfaces so an Arduino, Raspberry Pi, BeagleBone
or such can run them, particularly when connected to an emulator!


re: being forced back to overnight batch runs

There's an old saying:
"never underestimate the bandwidth of a
station wagon filled with magtapes".
Many of us now enjoy fiber to the living room
and megabit broadband at home.
But there are still many places in the world
without decent digital links,
who have rediscovered "sneaker net"
with SUVs full of flash drives.
Thanks to recent revelations
about snooping into all communications,
sneakernet and other off-line communications
may be back in vogue again :-/


re: car tunes

I still support vintage formats at home:
laserdisk, VHS, LP/vinyl records, audio cassettes
particularly since great movies are available for $1-3
at the local Thrift Shop in those formats.

My car (VW Passat) has a CD player
that supports other formats (so I can burn my own disks),
and an iPod connector :-/
I'll have to retrofit that to something standard
to use non Apple products such as my cassette walkman.

-- jeffj

[John Doty]

On Jan 23, 2014, at 1:45 PM, Richard Stofer wrote:

> Sure, you can use DISK1 or DISKN to update a file in UserArea but the key
> word is UPDATE.

I believe that DUP contains the only code in DM2 for creating or deleting a file in the UA. Of course, it wouldn't be all that hard for a user program to go through the machinations to make a new LET entry.

[John Doty]

On Jan 23, 2014, at 3:38 PM, Jeff Jonas wrote:

> The main obstacle was lack of connectivity to external systems.
> Punched cards were the primary input and output,
> particularly with off-line editing
> via the room full of keypunches.

Yep. One of the things that's strange about DM2 to modern eyes is that storing source code on the machine is an alien concept.

>
> 1) None of the IBM 1130s I used has the SCA (modem).
> (Even the college's PDP11/45 was used in isolation,
> connected only to local peripherals: printer, terminals).
> An interesting side note: I found notes that
> clever folks used the SCA to generate timer/clock interrupts
> for primitive time-sharing systems.

For FORGO, we counted ticks of the SCA timer to determine if a job had exceeded its allotted time. In that ILS, we'd also peek back at the return address. If we saw an illegal instruction, we'd kill the job. That saved a great deal of operator intervention. It also meant that if the system WAITed for the operator to load more cards or paper, it would poll the status every SCA tick. The operator didn't have to go back to the console and press START to get things going again.

The "S" in SCA stands for synchronous. It couldn't talk to a TTY (asynchronous). It was for connecting to a mainframe.

[Bob Flanders]

I used two 1130's -- high school and college. HS had a 1442 R/P and
1132. No SCA. College had 2501 CR, 1442 P and 1403 Printer. SCA was
used to talk to Princeton's 370/168 then Rutgers 370/158 on the New
Jersey Education Computer Network. We didn't mess around with that,
but we did speed up loading of the RJE deck. Later, they made it load
off of disk.

One time, a friend and I hacked into the system and changed the MOTD
that printed on the header pages for HASP. We made it say something
like "Welcome to HASP 1.4. The reading, printing and punching of job
output is no longer supported. Also, the old 'program execution'
feature has been done away with." I don't think the system programmers
liked us very much.

heh.
Bob

[Chuck Worthley]

Heehee i remember that

we were chastised for 'confusing naive users', when the sys progs stopped laughing (-:

From:        Bob Flanders <bob.fl...@gmail.com>
To:        "ibm...@googlegroups.com" <ibm...@googlegroups.com>
Date:        01/23/2014 11:26 PM
Subject:        Re: disk drive sound [IBM1130] Re: Small assembler program

[Bob.Flanders]

Yeah.  That was fun. 

Remember litebulb?

Sent from my T-Mobile 4G LTE Device

[James Field]

[Ross Patterson]

Funny how this business is connected. I started on an 1130 at Stuyvesant High School in New York City, then wound up as a systems programmer at NJECN, running the VM/370 system on that 370/158 in the Rutgers computer center.  I'm still good friends with the guy whose HASP system you hacked, on the NJECN 370/168, and yeah, he hated it people figured out how to set the banner message :-)

Ross Patterson

[Bob Flanders]

Was that Jeff Broido?

[Ross Patterson]

I was thinking of Bob Schreiber, but yeah, Jeff fit that description too  :-)

Ross

Sent from my phone - apologies for brevity

[gmail]

There was a time-sharing company that I worked for in the late 70's.
One of the logout messages included the line "Files untied". It wasn't
uncommon to have it changed on April Fool's Day to "Flies United".
Occasionally the customer support desk would get a call from some
confused user. Then people started automating their their terminal
sessions just to slurp data. Seems a lot of those users were relying on
"Files untied" to confirm that their terminal sessions ended correctly.
No more "Flies united".

jack

On 1/24/14, 7:51 AM, Chuck Worthley wrote:
> Heehee i remember that
>
> we were chastised for 'confusing naive users', when the sys progs
> stopped laughing (-:
>
>
>
>
> From: Bob Flanders <bob.fl...@gmail.com>
> To: "ibm...@googlegroups.com" <ibm...@googlegroups.com>
> Date: 01/23/2014 11:26 PM
> Subject: Re: disk drive sound [IBM1130] Re: Small assembler program
> Sent by: ibm...@googlegroups.com

> ------------------------------------------------------------------------

[Jeff Jonas]

> There was a time-sharing company that I worked for in the late 70's.
> One of the logout messages included the line "Files untied".

Ah, the lost art of ASCII art & blast page jokes.
Things that were so ubiquitious that nobody thought to save any,
'till they were all gone.

NYC high schools in the late 70s to mid 80s
used RJE terminals to dial into mainframes for
administration (attendance, report cards, class scheduling)
as well as for student use.
UAPC tended to have more ornate blast pages
to separate the wide fanfold,
sometimes celebrating holidays, seasons, etc.
MIDP, CCNY tended to have plain separator pages
with just block letters.

One April's Fool Prank was changing the line printer banner
from "The Cooper Union" to "The Copper Onion".
Few folks probably noticed.

[Carl Claunch]

Hi John

Bit 13 of the IOCCC for a seek (control) specifies the direction. If the bit was on, the arms were moving back toward cylinder 0 at the outside of the spinning disk. Bit 13 off moves the arm further out of the mechanism and towards the center hub of the disk, the higher cylinders. Seems likely that the code calling XIO to do the seek set up the IOCCC in the accumulator and extension, dynamically creating the address and count for a seek.  It likely did a STD to stick that in the location pointed to by the XIO just prior to issuing the request. You were seeing the residue of the instructions just before the XIO. 

[John McKee]

Thanks.  Nice to have the answer to that trivia question. 

John McKee

--
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.

[James Field]

It is likely that the timesharing company you are referring to was
either I.P.Sharp Associates (of Toronto ON) or Scientific Time Sharing
(of Bethesda MD).
The original "FILES UNTIED" messages was issued from the central data
processing facility after the user requested a disconnection from the
timesharing facility.
The intent was to assure the timesharing user that their data held as an
"open" file had been "closed" properly and completely. There was the
additional wish for that any ABSENCE of this reassuring message would be
reported back to the service provider.

I know and believe that the intent of the very conscientious creators of
these services was to guarantee and assure that the customers' data was
secure.

THEN THERE WAS THE FALSE SIGN-ON SPOOF...

It is all old trick...

been there, done that, but never with harm or malace.

[gmail]

It was STSC. I was there quite a while and then worked for IPSA for a
few years too. Timesharing was a fun business.

[Eddy Quicksall]

For programmable tabs, if you can get a hold of CYTOS (written by Tim Mellon) then that editor has programmable tabs. I know he originally ran CYTOS on DM2. I use CYTOS now but I don't remember how or even if I could extract the binary and post it. Today I use Visual Studio to edit my 1130 files and then transfer them to the 1130 file system with a Windows program. If it would help I could post the program I use to transfer files to/from the 1130 file system (but it assumes my format of the "drives" which is a 1::1 copy of the 1130 cartridges).

On Tuesday, January 21, 2014 4:02:18 PM UTC-5, Richard Stofer wrote:

I imagine it is FAR easier to type.  Keeping track of the various columns for assembly language programs is a huge pain.

 

I need an editor that has programmable tabs – kind of like the 029 card punch programming card.  There needs to be a saved setup for each type of coding.

 

From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf Of Bob Flanders
Sent: Tuesday, January 21, 2014 12:15 PM
To: ibm...@googlegroups.com
Subject: Re: [IBM1130] Small assembler program

 

On the emulator, there's an option to reformat cards read based on tabbing. There's Assembler, Fortran and regular 8 space tabs, hence the poor" formatting... but easier to type.

 

[Eddy Quicksall]

A friend of mine (Richard Sherin) wrote a DISKN that fit in the space of DISKZ. I wonder if that source is still floating around.

On Thursday, January 23, 2014 12:21:37 AM UTC-5, Peter Sawyer wrote:

The DISKZ interface, a BSI to DZ000 (decimal 242, /F2) was supported by
DISK1 and DISKN, so code written to use that calling method would work no
matter which DISKx version was in core. Writes using that interface could be
done anywhere. DISKN was able to support multiple operations on multiple
devices, but was also fast enough to read consecutive sectors without
missing a revolution of the disk. When Fortran programs had large SOCAL
overlays, it was sometimes worth it to run them with DISKN. Despite the
smaller available memory, the execution time could be better.

BTW, when the DISKx sub was being switched (that was done by the CIL, phase
2 @CIL2 (/A1)), there was a visible WAIT during the disk read. Neat to see
on the console lights.

----- Original Message -----
From: "John Doty" <j...@noqsi.com>
To: <ibm...@googlegroups.com>
Sent: Wednesday, January 22, 2014 11:35 PM
Subject: Re: [IBM1130] Re: Small assembler program


>
> On Jan 22, 2014, at 2:39 PM, Richard Stofer wrote:
>
>> DISKZ is intended for use with Fortran programs because it doesn't make
>> checks for correct calls.  Instead it relies on the compiler to make the
>> proper calls.
>
> Also system programs, not just Fortran. DISKZ was the disk driver that was
> in core by default.

[Eddy Quicksall]

I remember HASP very well. I wrote the HASP emulator for TSO at DNA systems.

[Richard Stofer]

I have returned to using VEDIT, a program I used MANY years ago with CP/M.  It has programmable tabs and works very well for creating assembly language programs.

 

Richard

 

 

From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf Of Eddy Quicksall
Sent: Tuesday, April 22, 2014 5:13 PM
To: ibm...@googlegroups.com
Subject: Re: [IBM1130] Small assembler program

 

For programmable tabs, if you can get a hold of CYTOS (written by Tim Mellon) then that editor has programmable tabs. I know he originally ran CYTOS on DM2. I use CYTOS now but I don't remember how or even if I could extract the binary and post it. Today I use Visual Studio to edit my 1130 files and then transfer them to the 1130 file system with a Windows program. If it would help I could post the program I use to transfer files to/from the 1130 file system (but it assumes my format of the "drives" which is a 1::1 copy of the 1130 cartridges).

On Tuesday, January 21, 2014 4:02:18 PM UTC-5, Richard Stofer wrote:

I imagine it is FAR easier to type.  Keeping track of the various columns for assembly language programs is a huge pain.

 

I need an editor that has programmable tabs – kind of like the 029 card punch programming card.  There needs to be a saved setup for each type of coding.

 

From: ibm...@googlegroups.com [mailto:ibm...@googlegroups.com] On Behalf Of Bob Flanders
Sent: Tuesday, January 21, 2014 12:15 PM
To: ibm...@googlegroups.com
Subject: Re: [IBM1130] Small assembler program

 

On the emulator, there's an option to reformat cards read based on tabbing. There's Assembler, Fortran and regular 8 space tabs, hence the poor" formatting... but easier to type.

 

--

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.

[James Field]

I'm just cleaning out (deleting olde messages) and I came across your
reference to "files untied".

The IPSA/STSC APL Plus/Sharp APL system(s) were based upon a hugely
enhanced and better supported timesharing system based upon the original
IBM APL offering
[XM1, XM6].
Significant improvements and inventions to 'packet switching' from Roger
Moore, Michael Harbinson and others included a novel file subsystem for
which I believe Eric Iversen was mostly responsible.

In the BSS (Backing Storage S(ub) System I believe that the earlier term
"open" was replaced by "tie", that is the connection between the dataset
[files] and the user currently on-line.
Upon opening a session to their files the user was "tied" to their data
files and when the session was closed, either by user intent, or other
interruption, the files were untied by the operating system so that no
unwanted communication could be made to the private data contained on
the user's files. The message "FILES UNTIED" would be issued to assure
the user that their data was not exposed.






























































.

One of the major enhancements to the useful but not commercially
attractive APL timesharing system offered by IBM was the Backing
Storage Subsystem [BSS].
The creation of a novel and Innovative way to build a data structure
with t is my understanding that Eric B. Iversen

[Pete]

Bitsavers has some files of ASCII (or rather EBCDIC) art. Thank goodness someone saved them.

[James Field]

Duh!? Is HASP a spooing utility associated with Huston TX. Was it O.S.
related?. My memory ain't what it was...

I'm mostly BPS/TOS/DOS /APL and therefrom trained and experienced. Did
HASP preceed or follow DOS POWER?

jIM

[Carl Claunch]

Hi Jim

HASP as the spooling program for OS/360, OS/MFT and OS/MVT, although some also used ASP. These became JES2 and JES3 with the VS versions of the operating system.

DOS users had GRASP or POWER as the spooling program. 

HASP preceeded POWER. In the 7000 and 1400 generation, preceeding S/360, spooling originally involved a second system - a 1401 might handle the card reading, punching and line printing for a 7090, leaving the faster machine free to do more arithmetic work. HASP and ASP were developed in customer locations, as was much of the key software in that era, often adopted later as formal IBM programs. HASP was developed at a customer in Houston, thus the name. 

Carl

[Carl Claunch]

Hi Pete

I have many printer art card decks which I will read in and upload once my card reader is working well. 

Carl

[Tom Watson]

Just "so you know", that customer in Houston was the Johnson Man
Spacecraft Center. Or in the movie "Apollo 13" the "Houston" as in
"Houston, we have a problem". IBM people distributed the program as one
of those "contributed programs" in their program library (as I
understand it). Lots of programs were distributed that was, even on the
1130.

It came into existence in the mid 60's. I knew it in 1967, and it was
before that. I understand that after the spooler worked on "local" I/O,
it was a bit later that using an 1130 as a "remote batch terminal" came
into being.

--
Tom Watson Generic short signature
t...@johana.com I'm at home now

> --
> 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.

[Carl Claunch]

Both ASP and HASP stemmed from a customer project, as did so much of the key middleware of S/360. The Aerospace Corporation came up with the idea of connecting a smaller 7000 series computer to a 7090 to offload work, they developed it with help from NASA Houston (the tie to HASP), but Direct Couple as it was called in those days took over IBSYS (operating system) functions such as job scheduling, device reservation/allocation, console message processing as well as spooling. IBM adopted this software as a product, converted it for S/360 when that came out and offered it as ASP. NASA didn't need all the heavyweight functions of ASP, produced a stripped down system that became the HASP product. 

Also driven by the race to the moon, IMS was originally developed for two defense contractors (Rockwell and Caterpillar) to support the huge scale of Apollo (as with ASP/HASP, IBM programmers contributed to the code along with customer programmers) as Information Control System and Data Language/Interface (ICS DL/I) but renamed as a product to IMS. becoming their flagship database system for many years.

There was much less customer design contributions for the origin of CICS, although it was built based on utility industry needs especially the US telephone companies and initially brought out as Public Utility Customer Information Control System PU-CICS until it was generalized and evolved by IBM's UK group as CICS for generalized transaction processing. 

Delta, American and Pan Am worked with IBM in the creation of Airline Control Program for reservation systems which became the IBM product TPF, still used today by airlines and financial services companies (e.g. Visa). Actually, IBM worked with AA on SABER (now SABRE) with the 7090 systems, then took that to work with Delta and Pan Am on their Deltamatic and Panamac res systems. With the launch of 360, they committed to merge and expand the work into PARS which included ACP. This helped protect that customer segment from poaching by other mainframe vendors since the incompatibility of S/360 would mean a substantial rewrite of SABRE et al, a vulnerable point when another provider could get involved. 

Carl

[Eddy Q]

I wrote the HASP RJE program for DNA system's time sharing system (TSO) which ran on modified 1130's and 1130 clones. I wrote that around 1975. It was probably the most fun of any of the synchronous communications programs that I wrote ... it used multi-leaving and would run the card reader, printer, punch (and maybe more) all simultaneously. I can't remember a lot but as I remember error recovery could recover an intermediate block.

[Yvette S. Hirth, CCP, CDP]

On 06/04/2015 04:26 PM, Eddy Q wrote:

> I wrote the HASP RJE program

(snippage)

i haven't seen this mentioned yet, so i'll ask: wasn't HASP the
original acronym for, "Houston Automated Spooling Program"?

yvette

[Peter Sawyer]

According to a relic I have, it was in the Contributed Program Library as:

Houston Automatic Spooling Priority System 360D 05.1.007.

The document is dated August 15, 1967.

[Yvette S. Hirth, CCP, CDP]

On 06/05/2015 03:07 PM, Peter Sawyer wrote:

> According to a relic I have, it was in the Contributed Program Library as:
> Houston Automatic Spooling Priority System 360D 05.1.007.
> The document is dated August 15, 1967.

thanks! and that was just about the time i discovered the 1130...

yvette

[Eddy Q]

By HASP RJE program I mean a program for the 1130 that communicated with a remote HASP system via the Synchronous Communications Adapter. I think the protocol was intended for smaller 360's to allow communication with a larger HASP system.  I also wrote simulations of the IBM 2780 and IBM 3780 ... those also communicated with 360/370's. I once sold the IBM 3780 simulation to the IBM typewriter division where they ran it to their 360/370/s from an IBM 1130. They ran through their 3780 test system (which said "yep, that 3780 is working just fine"). I then wrote simulators for the IBM 3741, UT 200 and CDC 1004.