Loading ...
Sorry, an error occurred while loading the content.
 

Re: [H390-MTS] Re: File Restoration with Original Names

Expand Messages
  • Jeff Ogden
    ... RIP is Reference If Present and defines APL as an optional external symbol. COM is a comment. LCS stands for Low Core Symbol table and causes the named
    Message 1 of 19 , Dec 15, 2012
      On Dec 15, 2012, at 1:09 PM, halfmeg wrote:

      I went back to try to print out *APL and found it missing. Thinking I had botched the shutdown, I just unzipped the D6.0A system again and restored the 1115-1133 files again.

      I see that when something is renamed to *xxx it disappears but filestatus *xxx still shows it is there.

      Anyway you are right about no object in *APL there are only 4 lines:

      1 RIP APL
      2 COM
      3 LCS LCSYMBOL
      4 LDT APL

      I had thought this was a short pre-process program to set up translation, size and I/O support for different terminals but see now that it isn't.

      Running the S2APL object directly permits the use of the 'par=SP,NOBALL' or other options.

      Phil


      RIP is "Reference If Present" and defines APL as an optional external symbol. COM is a comment. LCS stands for "Low Core Symbol" table and causes the named low core symbol table to be searched for any undefined symbols.  LDT stands for "Load Terminate" or "Loader Terminate" and transfers control to the named symbol assuming that it is defined (APL in this case).

      And, in spite of some confusion following your $Rename, this sounds like good news.  You have a running version of APL\360.  Am I reading things correctly? If so, congratulations.

      I'm guessing that the next stop on your adventure is terminal support with or without a special APL character set. Terminal support without the special APL character set will involve using the two character transliteration codes, but will probably be much faster to get working than anything involving a special APL character set.  Good luck.

      Here is some background on MTS filenames:

      MTS files are organized into a catalog that has separate sub-catalogs for each userID.  So, if you are signed on to the userID SEG2, the user files are owned by SEG2 and would be in the catalog for SEG2 (the owner and the sub-catalog are the same). Most files have three forms of names, a local name, an external name, and an internal name. Internal names are only used internally by systems programmers. End users use local names and sometimes external names.

      The $Filestatus command will list all of the files in the SEG2 catalog. So will the command $Filestatus SEG2:? or  $Filestatus ?. The names for a user file might be:
      • local: APL (no user ID or colon on the front, up to 12 characters long, doesn't start with an asterisk or a minus sign)
      • external: SEG2:APL (a user ID and a colon separator prefixed to the local name, a one to 4 character user ID, the colon, and a one to 12 character name)
      • internal: SEG2APL (the external name without the colon, up to 16 characters long) 
      There are two exceptions to the above, public files (or star files, files whose names begin, but do not end with an asterisk)  and temporary files (files whose name begins with a minus sign). These two sets of files are stored in separate sub-catalogs and the files are owned by whichever user ID created the files. So the owner's user ID is not always the same as the sub-catalog in which the file is located. 

      You use $Filestatus *? to list all of the public files (or at least the ones that are permitted to your user ID).  To see a list of all of the public IDs that are owned by a particular user ID, you would use the command $Filestatus *? owner=SEG2. The local, external, and internal file names for public files are all the same, *APL in this example. Public file names are from two to 16 characters long including the initial asterisk.  

      You use $Filestatus -? to list your temporary files.  You could also use $Filestatus <SF>:? to list your own and other people's temporary files (or at least those that are permitted to you) The <SF> form of the name is a not very well kept secret. The names for temporary files are: 
      • local: -xxxx (from one to 8 characters not including the leading minus sign)
      • external: <SF>:hhhhxxxx where "hhhh" is the hex encoded MTS task number of the task that created the file and "xxxx" is a one to eight character name
      • internal: <SF>hhhhxxxx (same as external name without the colon)
      So, when you $Renamed APL it disappeared from the SEG2 (or whichever) sub-catalog and moved into the public file sub-
      catalog and the form of the $Filestatus command needed to list it changed.

        -Jeff

    • Jeff Ogden
      More comments edited into the text below. -Jeff ... End users were assigned individual user IDs by the Business Office. Only computing center staff members had
      Message 2 of 19 , Dec 15, 2012
        More comments edited into the text below.

        -Jeff

        On Dec 15, 2012, at 1:46 PM, halfmeg wrote:

        > > Jeff Ogden <jco@...> wrote:
        >
        > > Some comments edited into the text below.
        >
        > > > halfmeg wrote:
        >
        > > > I must be missing something simple but quick search on restore and
        > > > rename on the forum hasn't helped. All below is from memory of
        > > > yesterday experiments and sometimes my memory isn't too good.
        >
        > > > After some 'rename xxxx as xxxx':
        >
        > > $Rename is as good a way as any to switch to the file names you
        > > want.
        >
        > Uggh!
        >
        > Source 'input mass rename file'
        > Source *MSOURCE* to get input back to terminal ?
        >
        > > You also need to permit the files, since that isn't done by *FS. Use
        > > the "$Filestatus filename fa" command to check the permit status of
        > > a file (fa stands for "full access"). The default is Unlim owner,
        > > None others. I can't remember if public files (the ones that start
        > > with an asterisk) are a special case and default Unlim owner, Read
        > > others or not.
        >
        > Uggh!!
        >
        > ><snip about SEG2 stuff >
        >
        > > No need to run this from the MTS. ccid. The MTS id can read any
        > > file, so using it will bypass any file permission problems. You need
        > > to $PERMIT *APL and SEG2:APL read others or perhaps run or etc.run.
        >
        > What is/was the normal signon for averger Joe User ? Surely it wasn't MTS that can read everything.

        End users were assigned individual user IDs by the Business Office. Only computing center staff members had access to the user ID MTS. and only a very few of them. So, for end users to be able to use files owned by other user IDs, the files had to be permitted ($Permit) to allow such use. File could be permitted to everyone, to specific user IDs, to specific projects (groups), and to program keys or combinations of all three.

        > > > I thought specifying a driver file on the restore statement would
        > > > 'auto-magically' restore the files in the 'correct' 'high-level's
        > > > with correct names. I see that is only for the creation (?) of the
        > > > FS tapes and not the restore.
        >
        > > MTS does not allow the creation of files on a different ccid from
        > > the one you are signed on to.
        >
        > Uggh!!!
        >
        > > So you can restore to the "real" file names from the driver file, if
        > > you wish. But if the file was copied to the *FS tape from another
        > > tape, then this "real" filename may not be what you want since it is
        > > the information about the tape rather than a disk file name. And
        > > sadly for you the *APL components on D5.0 seem to have come from a
        > > tape.
        >
        > In the case of APL which I am tinkering with this is not a problem. I have already changed the names to what they need to be in order for APL to work as described in both the MTS APL MEMO and the IBM APL/360 expectations of LIB 1, LIB 2, etc...
        >
        > ><snip>
        >
        > > You can tell *FS to restore files to a specific name. The command
        > > you used was:
        >
        > > RESTORE (m) (n)
        >
        > > Which says to restore all of the files from m to n on the *FS tape
        > > using their FS Names. A command of the form
        >
        > > RESTORE (m) newname
        >
        > > says to restore file m as new name. This only works one file at a
        > > time. And new name can't be the name of a driver file.
        >
        > Again the:
        >
        > Source 'input file with one liners for each file to rename
        > Source *MSOURCE*
        >
        > may have that MSOURCE wrong but *MSINK* worked after a 'sink *PRINTER* permitted 'list' output to go to printer.

        *MSOURCE* and *MSINK* are the same device for a terminal session. They are different for a batch session or a *file job.

        > > > How does one get FS dumped files back into the system with their
        > > > pre-dumped names and in their respective 'high-level's ?
        >
        > > If you need files restored to several different ccids, you need to
        > > sign on to each one, mount the tape, and run *FS. That is a pain
        >
        > .... that is an understatement. It's incomprehensible for a file save program to be able to dump from everywhere but not restore to everywhere.

        Remember that *FS was a regular public file that was mostly used by regular end users to save and restore disk files to and from magnetic tape. Regular users had little need to restore to multiple user IDs.

        You aren't acting as a regular user here. And as systems programmers, we weren't as kind to ourselves as we could have been.

        But, even this isn't as bad as it may sound since at most MTS sites, individual system programmers would restore the files for the components they were responsible for from the distribution tapes to their private user IDs, look the new material over, do some testing, figure out what, if anything, needed to be done to integrate any local site specific changes into the distribution material, develop a plan for how they were going to release the new material to their own end users, and finally, execute that plan at which time (perhaps over many weeks or months) the individual files would be renamed or moved and permitted appropriately for the local site.

        > I looked in 'FILE' a little as I was trying to find how much 'SPACE' was used on the current 3380. Didn't see it anywhere in CMDMACLIB which I thought was where it would be. Signoned to RSTR and checked out DEADFILE or thought I would since it could archive all dead files to an FS tape along with some listings of CCIDs (?) and other things. DF_xxxx something was closest I came and it only created the listing files for the other part of the utility.

        To find out how much space is in use, try the *file job *DSK (or the program SYS:DSK) and its LIST or SPACE commands. Or the *file-job *DSO is a canned version of this.

        You'll want to look at RSTR too.

        > > and so most people restore everything to one ccid, permit the files
        > > Unlim to the other ccids, and then sign on to the other ccids and
        > > $RENAME the files from the original ccid to the new location. Public
        > > files such as *APL can be created from any ccid that is allowed to
        > > create public files (flags in the accounting record for the ccid).
        >
        > So a complete restore of all 6 FS tapes for D6 would be 1st to a single CCID then copy them to other CCIDs ? What just happened to DASD space ? Did the copy create another file or just change the CCID and keep the file where it was ?

        It would be unusual for all of the files from all of tapes for a distribution to be restored to a single user ID. The MTS sites just didn't work that way.

        $Copy creates a new copy of the file and does not remove or release the original file. One must $Destroy a file to release its space. You cannot copy to another user ID from the user ID where the file exists unless the file you are copying to already exists and is permitted to allow modifications by the originating user ID. You can copy to a userID from another user ID if the original file is permitted read to the user ID where the file is to end up. I didn't say that very well. You can't push files from one user ID to another, but you can pull files to a ccid from another.

        $Rename doesn't make a copy of a file, but just changes its name and possibly its sub-catalog location. You can rename to one user ID from another, but you can't rename from one user ID to another, if the original user ID is permitted to allow renaming. It is the same push vs. pull business and all hints around the inability to crate a new file on a user ID that is different from the one to which you are signed on. And that limitation had to do with accounting and billing (money) and disk space quotas/limits.

        $Duplicate is a lot like $Copy, but it makes it easy to make an exact copy of a file including the files permit status. $Duplicate has the same limitations on from and to as $Copy.

        > Noticed several different MTS Volume files in the FS tapes. How does one get the files back on say MTS Volume 15 where the INDEX or Catalog or whatever mechanism MTS uses to track where a file is located ?

        The MTS Volumes in this case are documentation manuals and not disk volumes.

        MTS distributions did include a dump/restore tape for a single disk volume test or starter MTS system. That would be used to get a small version of MTS up and running at a new site or to quickly get a test version of a new release of MTS up at an existing site so it could be tested. In some cases the test system would be modified to look like the final production system and then its files would be moved over to the production system using a system utility program called File Move (FM).

        > If everything goes into the Master Catalog upon a FS restore such as the above ( 6 FS tapes ), don't you have to get rid of the old secondary catalogs and indexes (?) as they aren't any use ?

        It goes into many sub-catalogs. The catalog and sub-catalogs can get fragmented, but in general they do clean themselves up as files and sub-catalogs are created and destroyed. There are system utility programs to deal with expired user IDs and related sub-catalogs. The DEADFILES program or really a procedure consisting of several programs, is one of them.

        > While I'm on DASD stuff, I didn't find SMEAR either. It is suppose to redistribute files to level out DASD usage. Is/was it still in use ?

        I'd have to look around to find it, but there was a procedure to do this. If I remember correctly it involved running with a separate set of tables and file routines and possibly patching some values so that the "smearing" would occur as you wanted it to. I'm guessing that it was part of the disk disaster recovery procedures since cleaning up from a disk disaster was a time when you might want to spread things out or gather them together or otherwise rebalance the catalog and files. A big issue was too little free space on any one volume since files don't span volumes and so couldn't expand if the volume they were on ran out of space. The catalog could expand across disk volumes.

        > > Not so very far out in left field. In fact since you are just
        > > getting started with MTS, you are doing pretty well.
        >
        > Thanks, I tinker a lot and forget where I saw something a lot also lately.
        >
        > Phil
        >
        > ps - didn't any MTS sites dump the whole DASD farm with pack dumps so that a disaster recovery could be done quickly and easily instead of what appears to be to be ( loss for words here )


        MTS sites had a file save procedure (it didn't use *FS) that saved files to tape. There was the daily file save that only saved files that had changed since the last backup. There was the weekly save that saved everything (or at least everything that wasn't marked NOSAVE). These file save/restore procedures didn't do a pack by pack or volume by volume save and restore. They did file by file saves and restores. End users could restore from these tapes using *RESTORE.

        There is also the MTS Disk Copy program that would do a disk volume to tape or disk volume to disk volume, or tape to disk volume copy. This was a block by block or page by page copy. Only pages that were in use were copied. It was used to move disk packs around and to copy the test pack. It wasn't used for routine file save and restore. It might be used before a complete replacement of one set of disk equipment with some new equipment.

        -Jeff
      • halfmeg
        ... Yes, the MTS version of APL/360 is running correctly. ... Yes, the character set for APL under wc3270 client had been puzzling. Mike gave a reference to
        Message 3 of 19 , Dec 15, 2012
          > Jeff Ogden wrote:

          ><snip>

          > And, in spite of some confusion following your $Rename, this sounds
          > like good news. You have a running version of APL\360. Am I
          > reading things correctly? If so, congratulations.

          Yes, the MTS version of APL/360 is running correctly.

          > I'm guessing that the next stop on your adventure is terminal
          > support with or without a special APL character set. Terminal
          > support without the special APL character set will involve using the
          > two character transliteration codes, but will probably be much
          > faster to get working than anything involving a special APL
          > character set. Good luck.

          ><snip>

          Yes, the character set for APL under wc3270 client had been puzzling. Mike gave a reference to the PDF version of the APL Memo and several pages there explained the interpretation of the transliterated codes. I had wondered initially why some output was longer and included '$' signs in it instead of how the IBM example looked.

          Thanks to both you and Mike for assistance.

          Another thought just popped into my head.

          While looking around I noticed a reference to Waterloo ASMG and it's ability to create an object deck or file under MTS. I don't remember that capability under MVS. I thought it was an assemble and go only.

          I saw some ASMG update files on the FS tapes, so am wondering if MTS folks have modified ASMG to add the object deck capability ? Have seen some posts about MTS SVCs being different than MVS but this isn't interactive assemble like TSS or other esoteric OS specific thing I wouldn't think but don't know.

          Phil
        • Mike Alexander
          --On December 15, 2012 3:40:06 PM -0500 Jeff Ogden ... What is SMEAR? Is that an MVS program? I don t know of any MTS program by that name.
          Message 4 of 19 , Dec 15, 2012
            --On December 15, 2012 3:40:06 PM -0500 Jeff Ogden <jco@...>
            wrote:

            >> While I'm on DASD stuff, I didn't find SMEAR either. It is suppose
            >> to redistribute files to level out DASD usage. Is/was it still in
            >> use ?
            >
            > I'd have to look around to find it, but there was a procedure to do
            > this. If I remember correctly it involved running with a separate set
            > of tables and file routines and possibly patching some values so that
            > the "smearing" would occur as you wanted it to. I'm guessing that it
            > was part of the disk disaster recovery procedures since cleaning up
            > from a disk disaster was a time when you might want to spread things
            > out or gather them together or otherwise rebalance the catalog and
            > files. A big issue was too little free space on any one volume since
            > files don't span volumes and so couldn't expand if the volume they
            > were on ran out of space. The catalog could expand across disk
            > volumes.
            >

            What is SMEAR? Is that an MVS program? I don't know of any MTS
            program by that name.

            In MTS very few people, even system programmers, cared about disk
            volumes. From the point of view of the end user, and even most of the
            operating system, the file system was one big (well not so big by 2012
            standards) storage area. While it is possible to find out which volume
            a file is on, and to control where a new file goes, few people cared
            about this. I don't think the parameter to pick a volume for a new
            file is even documented for end users. MTS would pick an appropriate
            volume for a new file taking into consideration how much space was
            available on each volume, whether the volume was marked special in any
            of several ways, and other things. Given that there were thousands of
            users (over 30,000 at the peak) creating hundreds of thousands of
            files, most of which were small, this worked pretty well. We almost
            never had to move files around to balance space. Sometimes a disk
            would fail and we had to move files off of it, but that's a separate
            problem.

            Mike
          • Mike Alexander
            --On December 15, 2012 3:40:06 PM -0500 Jeff Ogden ... And this works in the Hercules based system. I sometimes run file save on my test MTS
            Message 5 of 19 , Dec 15, 2012
              --On December 15, 2012 3:40:06 PM -0500 Jeff Ogden <jco@...>
              wrote:

              >> ps - didn't any MTS sites dump the whole DASD farm with pack dumps
              >> so that a disaster recovery could be done quickly and easily instead
              >> of what appears to be to be ( loss for words here )
              >
              >
              > MTS sites had a file save procedure (it didn't use *FS) that saved
              > files to tape. There was the daily file save that only saved files
              > that had changed since the last backup. There was the weekly save
              > that saved everything (or at least everything that wasn't marked
              > NOSAVE). These file save/restore procedures didn't do a pack by pack
              > or volume by volume save and restore. They did file by file saves
              > and restores. End users could restore from these tapes using *RESTORE.

              And this works in the Hercules based system. I sometimes run file save
              on my test MTS system and use *RESTORE when I accidentally change
              something.

              Going forward this is probably the best way to distribute updates to
              the Hercules based MTS. Things are quite different now than back in
              the 80s when there were staffs of system programs vetting changes for
              thousands of users. Now people probably want to just dump updates into
              their system quickly and keep going. For this we can either use file
              save tapes, or perhaps cobble together something that is the front half
              of *FS with the back half of *RESTORE. I don't think this would be too
              hard to do and it would be much easier to use.

              Tom Valerio did something like this already. His program reads an *FS
              tape with special comments on each file (essentially the output of
              FileStatus total for the file) and restores the file to the correct
              user ID with all attributes restored. Unfortunately it requires
              patching the resident system and I've had some evidence that the patch
              might cause disk corruption so I'm reluctant to suggest using it.
              Taking his program and hooking it up to the back end of *RESTORE might
              not be too hard.

              Mike
            • halfmeg
              ... MTS Distribution 6.0 Doc folder NEWSYS text file section 13.F and OLDSYS text file section 22. My bad memory about an actual program name versus a
              Message 6 of 19 , Dec 15, 2012
                > Mike Alexander wrote:

                ><snip>

                > What is SMEAR? Is that an MVS program? I don't know of any MTS
                > program by that name.

                MTS Distribution 6.0 Doc folder NEWSYS text file section 13.F and OLDSYS text file section 22.

                My bad memory about an actual program name versus a procedure called smear or smearing.

                > In MTS very few people, even system programmers, cared about disk
                > volumes. From the point of view of the end user, and even most of
                > the operating system, the file system was one big (well not so big
                > by 2012 standards) storage area.

                ><snip>

                Beginning to see that.

                ><snip>

                > Given that there were thousands of users (over 30,000 at the peak)
                > creating hundreds of thousands of files, most of which were small,
                > this worked pretty well. We almost never had to move files around
                > to balance space. Sometimes a disk would fail and we had to move
                > files off of it, but that's a separate problem.

                I'm thinking contention and talking space, sorry. My mind is going.

                Phil
              • Tony Harminc
                ... No - ASMG was essentially IBM s ASMF (IEUASM) modified in several ways, mostly to improve performance. One of the modifications added a batch assembly and
                Message 7 of 19 , Dec 15, 2012
                  On 15 December 2012 16:22, halfmeg <opplr@...> wrote:

                  > While looking around I noticed a reference to Waterloo ASMG and it's ability to create an object deck or file under MTS. I don't remember that capability under MVS. I thought it was an assemble and go only.

                  No - ASMG was essentially IBM's ASMF (IEUASM) modified in several
                  ways, mostly to improve performance. One of the modifications added a
                  batch assembly and load & go features, but they were just another
                  couple of options among many.

                  > I saw some ASMG update files on the FS tapes, so am wondering if MTS folks have modified ASMG to add the object deck capability ?

                  'twas always there, at least to the extent that MTS object decks are
                  compatible with those of DOS and OS, which I believe they are.

                  > Have seen some posts about MTS SVCs being different than MVS but this isn't interactive assemble like TSS or other esoteric OS specific thing I wouldn't think but don't know.

                  Either they modifed ASMG or they used some sort of cradle. I suspect
                  the former, but I don't know.

                  Tony H.
                • Steven J Gold
                  ... Yes, MTS SVC s were different than OS/3x0 ones and even though the format of the object code was similar, you couldn t (with minor exceptions) execute an
                  Message 8 of 19 , Dec 15, 2012
                    >> On 15 December 2012 16:22, halfmeg <opplr@...> wrote:
                    >> > Have seen some posts about MTS SVCs being different than MVS but this isn't interactive assemble like TSS or other esoteric OS specific thing I wouldn't think but don't know.
                    >>
                    > On Dec 15, 2012, at 8:36 PM, Tony Harminc <tharminc@...> replied:
                    >
                    > Either they modifed ASMG or they used some sort of cradle. I suspect the former, but I don't know.
                    >
                    > Tony H.
                    >

                    Yes, MTS SVC's were different than OS/3x0 ones and even though the format of the object code was similar, you couldn't (with minor exceptions) execute an MVS program in MTS and expect it to run.

                    But those were the good-old-days and you could order the source code for the IBM compliers on tape; modify and rebuild them as required.

                    I did that. IBM's programing practices (and memory constraints!) back then resulted in fairly modular compilers where the various required system services such as I/O and memory allocation/deallocation were localized into a single support module which remained resident and the functions were subroutine entry-points in it. The actual compiler routines almost never actually issued SVC's; they called subroutines in the support module. And often, in that subroutine, the system services were involved using IBM's "standard" assembly macros (such as DCB, READ, WRITE, GET, PUT,etc.). These macros set up the parameters to the OS/3x0 SVCs and involved them. So in many cases, we could just change the macro's definition code to use the equivalent MTS SVCs so we hardly had to change the actual "source code" much.

                    (ok, this is an oversimplification, but you get the idea)

                    ….Steve Gold, WSU MTS staff
                  • Mike Alexander
                    --On December 16, 2012 12:27:33 AM +0000 halfmeg ... Contention is an issue. That s why all disk I/O went through a common program (the
                    Message 9 of 19 , Dec 16, 2012
                      --On December 16, 2012 12:27:33 AM +0000 halfmeg <opplr@...>
                      wrote:

                      >> Given that there were thousands of users (over 30,000 at the peak)
                      >> creating hundreds of thousands of files, most of which were small,
                      >> this worked pretty well. We almost never had to move files around
                      >> to balance space. Sometimes a disk would fail and we had to move
                      >> files off of it, but that's a separate problem.
                      >
                      > I'm thinking contention and talking space, sorry. My mind is going.

                      Contention is an issue. That's why all disk I/O went through a common
                      program (the disk manager or DMGR) that scheduled it according to head
                      position and cached pages in memory. If I remember correctly, it would
                      also transfer multiple pages in one channel program to avoid rotational
                      delay and reduce overhead. This allowed us to get increase the
                      bandwidth to disk and reduce contention significantly. Without that
                      MTS wouldn't have been able to keep up with the demand for disk I/O.

                      Mike
                    • halfmeg
                      ... Have almost finished reading all the posts in the forum. Was wondering where the ADVENTURE tape was made available. Last mention was submitting it. I
                      Message 10 of 19 , Jan 11, 2013
                        > Jeff Ogden wrote:

                        > - snip -

                        > You aren't acting as a regular user here. And as systems programmers,
                        > we weren't as kind to ourselves as we could have been.

                        > But, even this isn't as bad as it may sound since at most MTS sites,
                        > individual system programmers would restore the files for the
                        > components they were responsible for from the distribution tapes to
                        > their private user IDs, look the new material over, do some testing,
                        > figure out what, if anything, needed to be done to integrate any
                        > local site specific changes into the distribution material, develop
                        > a plan for how they were going to release the new material to their
                        > own end users, and finally, execute that plan at which time
                        > (perhaps over many weeks or months) the individual files would be
                        > renamed or moved and permitted appropriately for the local site.

                        Have almost finished reading all the posts in the forum. Was wondering where the ADVENTURE tape was made available. Last mention was 'submitting' it. I haven't seen where it was put in the files section or on the web. Where can it be obtained ?

                        Is there a backup available for all the Wxxx CCID files ? I keep running across references to various Wxxx IDs and somewhere think I read where they were 'special' to administer the system.

                        Looking back at the d2 tapes earlier today I see that d2.0.tape4.aws is a DASDR dump tape. It has/maybe has a DASDI/R program (?) in the 1st file and the MTS001 in the 2nd. Trying to IPL the tape is a no go, but using a good DASDR and pointing it to the 2nd file gives a variety of responses.

                        1st time - It evidently isn't a VAM2 formatted disk - after I gave it a V2 it came back and stated it didn't match the dump.

                        2nd time - It evidently isn't a normal 2314 as I get a 'hardware' error ( can't remember what right now ). Tried V1 type format (?).

                        3rd time - same as 2nd but tried S for type format (?).

                        Looking at the dump file itself there are a lot of BADTRACK records. Is this one of those 400 CYL 2314's back when D2 was running ? A 3330 which I didn't try but might be it instead ?

                        Phil
                      • Mike Alexander
                        --On January 11, 2013 11:24:19 PM +0000 halfmeg ... What ADVENTURE tape are you talking about? I don t know of any such tape associated
                        Message 11 of 19 , Jan 11, 2013
                          --On January 11, 2013 11:24:19 PM +0000 halfmeg <opplr@...>
                          wrote:

                          > Have almost finished reading all the posts in the forum. Was
                          > wondering where the ADVENTURE tape was made available. Last mention
                          > was 'submitting' it. I haven't seen where it was put in the files
                          > section or on the web. Where can it be obtained ?
                          >

                          What ADVENTURE tape are you talking about? I don't know of any such
                          tape associated with MTS.

                          > Is there a backup available for all the Wxxx CCID files ? I keep
                          > running across references to various Wxxx IDs and somewhere think I
                          > read where they were 'special' to administer the system.

                          The Wxxx CCIDs were used by Computing Center staff members both for
                          their own use and for maintaining MTS and other programs. As such they
                          contained a mixture of personal and system related information. Many
                          of them were preserved when MTS was shutdown in 1996, but not all of
                          them. If and when the 1996 system is made available, the relevant
                          files from the CCIDs which were preserved will be made available.

                          > Looking back at the d2 tapes earlier today I see that d2.0.tape4.aws
                          > is a DASDR dump tape. It has/maybe has a DASDI/R program (?) in the
                          > 1st file and the MTS001 in the 2nd. Trying to IPL the tape is a no
                          > go, but using a good DASDR and pointing it to the 2nd file gives a
                          > variety of responses.
                          >
                          > 1st time - It evidently isn't a VAM2 formatted disk - after I gave it
                          > a V2 it came back and stated it didn't match the dump.
                          >
                          > 2nd time - It evidently isn't a normal 2314 as I get a 'hardware'
                          > error ( can't remember what right now ). Tried V1 type format (?).
                          >
                          > 3rd time - same as 2nd but tried S for type format (?).
                          >
                          > Looking at the dump file itself there are a lot of BADTRACK records.
                          > Is this one of those 400 CYL 2314's back when D2 was running ? A
                          > 3330 which I didn't try but might be it instead ?
                          >

                          You should look at the README file in the MTSDistDoc directory in the
                          distribution archive file. It describes the contents of each of the
                          tapes and discusses any problems encountered copying them. Both of the
                          dump/restore tapes had errors during the copy. The errors were
                          eventually recovered from, but the data is a bit suspect.

                          At the time of D2 (early 1970), MTS did not use VAM formated disks.
                          Those tapes are OS/360 dump/restore tapes for a 2314 disk. Unused
                          tracks on the disk may or may not be formatted. Used tracks are
                          formatted with two records per track (not page-size records). I think
                          the disks are ordinary 2314 disks, not double size or anything like
                          that.

                          Doing anything useful with these tapes will be a real challenge. Even
                          if you get them restored, you'll need a running MTS to make sense of
                          them, and the only versions of MTS that understand that disk format
                          require 360/67 architecture. If you want to make a go of it, there is
                          a TABLES definition in file 22 on d2.0.t1t2.aws which probably
                          describes the machine that the system on these tapes expects to see.
                          If you added 360/67 support to Hercules and configured a virtual
                          machine to match that TABLES definition, it might work. You'll
                          probably also need 2301 support for paging and, if you want a terminal,
                          2260 support (since 3270s didn't exist then) or 2703 support.

                          Mike
                        • halfmeg
                          ... http://tech.groups.yahoo.com/group/H390-MTS/message/402 It existed for a long time as CRLT:Adventure, but I don t think that it ever made it to a
                          Message 12 of 19 , Jan 12, 2013
                            > Mike Alexander wrote:

                            > > halfmeg wrote:

                            > > Have almost finished reading all the posts in the forum. Was
                            > > wondering where the ADVENTURE tape was made available. Last
                            > > mention was 'submitting' it. I haven't seen where it was put in
                            > > the files section or on the web. Where can it be obtained ?

                            > What ADVENTURE tape are you talking about? I don't know of any such
                            > tape associated with MTS.

                            http://tech.groups.yahoo.com/group/H390-MTS/message/402

                            "It existed for a long time as CRLT:Adventure, but I don't think that it ever made it to a distribution."

                            http://tech.groups.yahoo.com/group/H390-MTS/message/411

                            "I have both files. Always knew there was a reason for keeping them :)"

                            http://tech.groups.yahoo.com/group/H390-MTS/message/467

                            "Having received source and data files for the classic ADVENTURE game, ..."

                            > > Is there a backup available for all the Wxxx CCID files ? I keep
                            > > running across references to various Wxxx IDs and somewhere think
                            > > I read where they were 'special' to administer the system.

                            > The Wxxx CCIDs were used by Computing Center staff members both for
                            > their own use and for maintaining MTS and other programs. As such
                            > they contained a mixture of personal and system related information.
                            > Many of them were preserved when MTS was shutdown in 1996, but not
                            > all of them. If and when the 1996 system is made available, the
                            > relevant files from the CCIDs which were preserved will be made
                            > available.

                            I'll get back to you on the specific ones. One was for debugging APL via trace ( W170 ? mayge but not sure right now ) the other for LISP IIRC and W11W was where the TABLES went ( I think ) as the example shows W11W at the end of the DECKGEN write ups for sample execution.

                            > > Looking back at the d2 tapes earlier today I see that
                            > > D2.0.tape4.aws is a DASDR dump tape.

                            > - snip -

                            > Doing anything useful with these tapes will be a real challenge.
                            > Even if you get them restored, you'll need a running MTS to make
                            > sense of them, and the only versions of MTS that understand that
                            > disk format require 360/67 architecture. If you want to make a go
                            > of it, there is a TABLES definition in file 22 on d2.0.t1t2.aws
                            > which probably describes the machine that the system on these tapes
                            > expects to see.
                            > If you added 360/67 support to Hercules and configured a virtual
                            > machine to match that TABLES definition, it might work. You'll
                            > probably also need 2301 support for paging and, if you want a
                            > terminal, 2260 support (since 3270s didn't exist then) or 2703
                            > support.

                            This is probably a bridge too far for me. IIRC there was something that didn't work quite right with a 2305 under Hercules while messing with the TSS system. Maybe it was just the multiple access addresses for the single drum, can't remember right now.

                            And just checking the Hercules source, I see no support for a 2301 disk/drum type.

                            Thanks,

                            Phil
                          • Kevin Monceaux
                            ... I hope it s when instead of if. :-) No rush. I know there s a lot of work involved. Some of the recent discussions on the list suggest that the work
                            Message 13 of 19 , Jan 15, 2013
                              On Fri, Jan 11, 2013 at 10:19:37PM -0500, Mike Alexander wrote:

                              > If and when the 1996 system is made available, the relevant files from the
                              > CCIDs which were preserved will be made available.

                              I hope it's when instead of if. :-) No rush. I know there's a lot of work
                              involved. Some of the recent discussions on the list suggest that the work
                              involved could very likely be even more than most of us would think. I'm
                              sure the 1996 system will be well worth the wait. I suspect there are many
                              members of the Hercules community who would be willing to help with the
                              effort, if we could. But most, if not all, of us are MTS newbies, and since
                              the assembler we'd need to use can't be distributed we couldn't be of much
                              help anyway. If there's anything someone with my limited knowledge could do
                              to help, just ask.

                              I started to get familiar with the D6.0 and D6.0A distributions, then
                              decided to stop and wait for the 1996+ distribution to be released. I've
                              already forgotten most of what I learned. I hate my terrible memory. Maybe
                              I should get back to tinkering with the D6.x distributions.


                              --

                              Kevin
                              http://www.RawFedDogs.net
                              http://Lassie.RawFedDogs.net
                              http://www.WacoAgilityGroup.org
                              Bruceville, TX

                              What's the definition of a legacy system? One that works!
                              Errare humanum est, ignoscere caninum.
                            Your message has been successfully submitted and would be delivered to recipients shortly.