Core Image program and Supervisor Control Records

[John McKee]

I never tried this when I had access to the physical 1130.  I should try this with the emulator, I know.  Just have not had the energy, of late.

Following a successful compile of a program that uses a file stored in the fixed area, DUP is invoked and STORECI is used.  There will need to be a *FILES record (presuming program is FORTRAN or COBOL),  The core image program is then created referencing the file in the fixed area.

So, what happens if that core image program is referenced on a // XEQ that indicates one supervisor control record follows, and that record is *FILES, referencing a different file?

Does an error get produced?  Is the record ignored?

I have forgotten so much as to how files are referenced in FORTRAN.  Also managed to misplace my FORTRAN book.

Thanks.

John McKee

[Bob Flanders]

http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/1130/lang/

Here is where some 1130 fortran documents are available. 

Hope you feel better.

Bob

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

[Richard Stofer]

Here’s what the Disk Monitor System, Version 2, Programming and Operator’s Manual says:

 

“When data files are equated in a program stored in DCI, successful execution of this program requires that all cartridges on which these files are stored must be in the same condition and on the same logical drives as when the STOECI occurred.  This is necessary since the Core Load Builder places an absolute sector address, including the drive code, into the file table for each equated file.”

 

The manual doesn’t say anything about generating an error and, as I read the statement, there is no real requirement that the files be in Fixed Area as long as they aren’t moved in the User Area.  Of course, the right answer is to put the files in Fixed Area.  The DCI program can be in either Fixed Area or User Area.

 

I think if the user messes this up, they are on their own!

 

Richard

 

[John McKee]

I thought that I read that *STORECI woulf fail if files were in UA.  Seems it should, to prevent trashing a program or data file .  Guess I need to take time to wander through the source code.  Sure seems like CIL  could process a *FILES record with alternate file name.  I could see how it might be done, but also how that could be a very bad idea.  I just can't remember if it allowed file reassignment at lod time or it was just assumed it did not allow it.  Without a *FILES card, the CI program had specific sector address for a file that had beter be there.  What could >possibly< go wrong if program was copied to a different disk pack?  Plenty of damage.  Yet, I don't think there was any information about the cartridge id associated with the absolute sector address.  If there was, then additional code would be required to ensure the proper disk pack was installed.  And, due to some programs use of all of storage, that would seem to be wasteful, just like aray subscript checking was not checked at run time.  Which prompted my curiosity about what would happen if // XEQ indicated supervisor records followed and *FILES was used.  Maybe it was ignored.

John McKee

--

[Richard Stofer]

Since the absolute file location has been encoded into the DCI program, I see no reason for the Monitor to accept any *FILES cards for DCI programs.  I suppose you could just test it with the simulator.  The Fixed Area isn’t any more fixed than User Area.  I’m pretty sure I can add and delete files and, in doing so, actually move a file location in Fixed Area.  You can use DUMPDATA to copy the file from FA to WS and then use STOREDATA to copy the file from WS back to FA after deleting some earlier files in FA.  That ought to mess up the addressing!

 

I think DCI and FA were advanced topics.  I used them a couple of times where core load building was grim but I didn’t make a habit of it.  Today I wouldn’t even consider it.  The Compact Flash coupled with the speed of an FPGA and there is no need for core image.

 

It’s possible that the core image builder would croak if the files were in UA but I haven’t tested it.  Again, the simulator is probably the easy way to test.

[John McKee]

I do take exception to stating that FX moves files.  If you delete a file from FX, either a 1DUMY entry is created or it is expanded.  Existing entries are never moved precisely because DCI programs have absolute disk addresses.  In fact, with a fixed area present, *DEFINE VOID will fail with an error that the function is not allowed when a fixed area is present.

A kid from high school wrote a job accounting system.  Files were in fixed area and names were clobbered.  Files coulnot be deleted.  Program also resided in fixed area as it was loaded by a patch to the system phase that processed monitor control records.  Program name also had a clobbered name.  Result was DUP would not delete and thus compilers could not be removed.  I learned interesting things just looking at his discarded assembly lists. 

When you attempt to create a file in FX, space is either taken from the end or from an existing 1DUMY,

At least I remember that stuff.

John McKee 

[Peter Sawyer]

My own recollection is thathe CIB would fail the STORECI if the files were not in the Fixed Area. But as a previous contributor pointed out, you could unload the file to another location, delete it, and then reload it in a different place. That would not be a good idea, but nothing would detect that the CI module was no longer valid. Indeed, just deleting the FX file would create an exposure.

[Richard Stofer]

I didn’t mean to imply that DUP moved files in FA.  That won’t happen.  But suppose there are2 files and I delete the first.  Then I use DUMPDATA, DELETE and STOREDATA to move File 2  to the beginning of FA.  There’s no reason I can’t do this that I know of.

[John R Pierce]

On 6/18/2015 9:31 PM, Richard Stofer wrote:

I didn’t mean to imply that DUP moved files in FA.  That won’t happen.  But suppose there are2 files and I delete the first.  Then I use DUMPDATA, DELETE and STOREDATA to move File 2  to the beginning of FA.  There’s no reason I can’t do this that I know of.

the reason you /don't/ do that is core image linking.

-- 
john r pierce, recycling bits in santa cruz

[John McKee]

Correct.  And, any DCI program associated with the file will now create a mess.  Suppose the two files were the same size.  Delete file 1, store file 2 under a different name into UA, then delete file 2.  Move copy of file 2 back to FX and it will be first file.  And everything will seem broken when file 2 is updated successfully, but contents don't change when referenced by newly created DCI program.  What a bit of torture that might have created!

John McKee

[Richard Stofer]

One factoid from the DMS user manual:  All files referenced in a DCI program must exist in FX.  Considering how often UA changes, this seems reasonable.

The DCI program itself can be stored in UA or FX.

[rbsteup]

The 1130 Disk Monitor System's biggest shortcoming was that a Fortran program could only access existing files in the fixed area and that fixed area files could not change in size.
While writing a large CAD system for the physical design of large integrated circuit chips this restriction precluded any reasonable file handling under DMS abilities.

The solution was to create assembly language subroutines, callable by Fortran programs to dynamically locate and access files. All of the files were located in the fixed area of disk, but their size and location were managed by the Fortran programs.
The Fortran programs used DEFINE FILE statements that were dummies that created entries in the core image that were modified at execution time by the assembly language subroutines to access the actual files to be used.

Unfortunately I no longer have the source for these assembler programs, but as I remember they were not difficult to create once you had an understanding of the Fortran disk code.

[Eddy Q]

At DNA Systems we created XBASE. That would, among other things, let you specify the name and location of a file from within your program. It would also let you concatenate files to create one logical file ... and the cartridge IDs for the files did not have to be named on the // JOB card or CYTOS mount command. 

--