Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- H390-MVS
- Messages
Search
|
Re: DLI loading on Tk4 and MVSCE?
Hi? I am a novice?here but I have to admit? this seems very interesting: The IEAAPP00 member did in fact exist in MVS.? Does this mean that it is possible to apply this member to MVS TK4/5 with the corresponding necessary changes. Does the member exist in MVT? In other words - is it possible to get DL1 to work in the MVS 3.8 J environment? That would be something worth fighting for. Kind regards DagfinnOn Wed, 19 Feb 2025 at 21:30, Dagfinn Hammar <dagfinndh33@...> wrote:
|
|
Re: DLI loading on Tk4 and MVSCE?
Hi? I am a novice?here but I have to admit? this seems very interesting: The IEAAPP00 member did in fact exist in MVS.? Does this mean that it is possible to apply this member to MVS TK4/5 with the corres?onding necessary changes. Does the member exist in MVT? In other words - is it possible to get DL1 to work in the MVS 3.8 J environment? That would be something worth fighting for. Kind regards Dagfinn On Wed, 19 Feb 2025 at 20:36, Jay Maynard via <jaymaynard=[email protected]> wrote:
|
|
Re: DLI loading on Tk4 and MVSCE?
The IEAAPP00 member did in fact exist in MVS. That TK5 does not have one simply means that no appendages are used. The member, and what appendages are and how to use them, is described?starting at page 50 (PDF page 64) of? . On Wed, Feb 19, 2025 at 1:19?PM John James via <johnjamesmain=[email protected]> wrote:
--
Jay Maynard |
|
Re: DLI loading on Tk4 and MVSCE?
Thanks for your thoughts.
?
About the only documentation that I can find about the abend in question is in a z/OS manual. It says......
? ? ? ? ? ?? ? An OPEN macro instruction was issued using the EXCP access method in which user-written appendages were required. The appendage names were not included in the SYS1.PARMLIB member IEAAPP00, and the program issuing the OPEN was not authorized either under APF, or by being in a system protect key (0-7).
?
User-written appendages?? Sounds like DL/1!!
?
The SYS1.PARMLIB(IEAAPP00) member doesn't appear to exist in MVS, which is why I'm wondering if there's anybody out there who can suggest a suitable alternative program authorization function for MVS. Might be worth a try? Or maybe RAKF can be of help somehow.
?
JJ |
|
Re: DLI loading on Tk4 and MVSCE?
It's been a loooong time but ISTR the 360 version of DL/1 couldn't run on MVS. The OSAM open routines built a DEB which goes into (I think) LSQA or CSA for local protected storage. In MVS there was a complete rework of the access routines with support to move the DEB. ISAM/OSAM will surely open the ISAM part but the OSAM open will fail miserably. Try it under MVT ... I think I got it working long (5 years?) ago. The channel end appendage is another issue - it was used to update the TTR of the last block in the OSAM file to allow it to be reopened correctly in event of a (usually frequent) hang or system crash. There also was a standalone utility that had to be loaded from somewhere (card reader) to write pending buffers and insure a tape mark was written on the log tape. That all applies to the IMS/360 version of DL/1.
? |
|
Re: DLI loading on Tk4 and MVSCE?
I haven't had time to do anything lately with the IMS/360 DLI tape that was being discussed here a year or so ago. But I've just had a chance to have another go at it, and I've run into what's looking like an authorisation (RAKF?) issue; I'm looking for ideas.
?
I have done successful PSB and DBD gens and I'm now running the first program from the COBOL test suite that appeared from somewhere some time back. When I start up a batch DLI program to load the database initially, the ISAM "half" of the DLI file appears to open OK, but then the open of the OSAM "other half" of the file fails (which is a shame, because I'm using the ISAM-VSAM "bridge", and I don't think that OSAM is needed at all in this situation - but it still wants to open the file).
?
The failure is IEC150I 913-20 for IFG0196X. I came across a z/OS manual that implies to me that this means that the DLI OSAM channel end appendage module needs to have some kind of authorised status, and that the PARMLIB member IEAAPP00 needs to be updated.
?
However, in MVS there is no such member in SYS1.PARMLIB.
?
Does anyone know what the equivalent advice would be for MVS (i.e. TK4-?). Where can I find a list of authorised modules that I can update?
?
Thanks for any help, JJ |
|
File /tapemgr.tgz uploaded
#file-notice
Group Notification
The following items have been added to the Files area of the [email protected] group. By: Stephen Dennis <afflictedunlivablejubilant@...> Description: |
|
Re: Historical Question
In case you are interested in seeing what the 3850 MSS looked like when it was operating, fetching the tapes from the honeycomb, I found these videos at this site:
?
? ?? ?
?
Note: the text is in German but you can still enjoy the videos.? :-)
?
And this page (of the same site) has a bunch of still pictures of the 3850:
?
? ? ?
?
Enjoy,
?
Mark S. Waterbury |
|
Re: Historical Question
This brings back cringing memories! We were part of the bleeding edge community and has 2 3850 MSS devices. In the pre HSM days, we actually were quite successful in implementing a migration/retrieval system for our pretty massive DASD farm. This was in the HASP/MVT days when we created the first SHARED spool capability. Here are a couple of pictures of the last piece of the honeycomb and the CE cartridge. I keep them in our den/office . |
|
Re: Historical Question
ISTR that JES3 had some issues if the data to be transmitted via NJE/RJE was on a MSS volume that needed to be mounted. The line would hang until everything was ready causing timeouts and line drops.?
I also clearly remember seeing a cartridge ejected (how you got one out) when the mechanism was broken - cartridge skidded 25 or 30 feet until it hit something.?
The cartridges were black, a somewhat bigger than a toilet paper tube.
Now days its all solid state stuff - no more IBM maintenance engineer with a wrench, hammer, and a scope tuning up things.?
Where is the fun in that :-)
? |
|
Re: Historical Question
Let me clarify a few things here: User data was never read directly from or written directly to the magnetic tapes in the MSS. There was a viertualization layer where physical disk space was allocated in 8 cylinder chunks on the 3330(or3350) staging direves. Do not remember if you could have more than 32 (that means 64)? virtual disks mounted on a control unit (pair), which was christened Staging Adapter in a MSS context. So a seek to a new cylinder which is not already on any physical dasd would require mounting a tape, requesting dasd space, reading data to dasd, repeat the channel program.? Any data written would eventually have to be copied back to tape of course. Least recently used style. A worst case could be that a virtual volume was demounted (KEEP'ed) and then remounted on a different staging adapter before data was destaged to tape from the previous adapter.? The JES3 support intended to prevent this situation but did not alwasys manage.? The Mass Storage Controller was an addressable device of it's own. MVS (and some MSS untilities) was sending orders (like Mount or Create a viertual volume) on this device. As far as I know it is not emulated by Hercules and I would not argue to introduce such support either!? I would guess that the MVS support for MSS still is there in the TK4/5 distributions of 1980-like MVS. ?? |
|
Re: Jay Moseley's sysgen instructions
On 2/9/25 08:04, William Turner via groups.io wrote:
Hi - just a note to document a small error in the above remarkablyBill, Sounds like your version of my mvsInstallationResources archive, whichever you use - Windows or Linux - is not the correct match for the instructions on the page. Whenever I update these instructions, almost always the contents of the archives change. Therefore, you always need to download a fresh copy of the archive if you are following the instructions from the live website. You should also always download a fresh copy of SYSCPK, because there have certainly been at least a couple of times when I had to update one or more programs on SYSCPK to facilitate a change in the System Generation process. Jay |
|
Jay Moseley's sysgen instructions
Hi - just a note to document a small error in the above remarkably
detailed and comprehensive instructions. SMPJOB04 instruction section requests tape j90012.het - this is present but appears to be completely blank and the job actually specifies j90009.het. The illustrations show j90012.het being mounted so SMPJOB04 has been changed at some time. Might save someone some head scratching if they are trying to learn the intricacies of system generation. Amazing job Jay - thanks Bill |
|
Re: Historical Question
开云体育That is certainly better than the reputation the MSS had; when the Central Bank switched to IBM, we had NCR CRAM units ("double drop!") and at some time the MSS was discussed briefly. But rumour had it that they were quite dangerous and people had died through neglecting the safeguards. Never knew whether that was an urban legend or not. best regards, 搁别苍é.
|
|
Re: Historical Question
On Fri, Feb 07, 2025 at 11:00:41PM +0000, Dave Trainor - N8ZFM wrote:
It seems to me there is still a need for the larger spinning disks inMy current employer recently received three new DS8A00 storage arrays, the latest, 10th generation, in IBM's DS8000 SAN storage array line. All drives in the arrays are flash core modules. -- Kevin Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. |
|
Re: Historical Question
This discussion has been interesting, a good idea that never really worked out due to implementation.
toggle quoted message
Show quoted text
--- I was unaware that IBM had discontinued all spinning platters, while I certainly myself would not think of using anything other than a SSD as my boot device on any machine. It seems to me there is still a need for the larger spinning disks in array's for massive amounts of data, would be dog gone expensive to put all that on solid state and the speed is not required in that application, like for my video storage of movies and tv shows. But I guess as time goes on it for sure will be the future. Thanks for the interesting stories of this device I had not heard of before, seems like I was lucky I missed out on the 3850. Thanks, Dave ?On 2/7/25, 11:03 AM, "[email protected] <mailto:[email protected]> on behalf of Jeff Bassett" <[email protected] <mailto:[email protected]> on behalf of bassettj@... <mailto:bassettj@...>> wrote: Dave, The 3850 mass store was at the time quite a device - And due to the high cost of DASD at the time - it really did serve a purpose - At the larger shops that had these - you will hear all manner of horror stories - there were some doozies - believe me - The device was of course very mechanical - and - as such - had many places and opportunities to have failures - This was of early introduction of robotics to do the mounts - THANKFULLY they are gone - relegated to these old stories - Today - we use similar techniques - with HSM (Hierarchical Storage Manager) to back up and recall when required data sets - And of course, HSM has evolved - from using special staging disks to migrating to tape - with auto mounts - and now in today's world VTS which are now entire virtual tape systems - that are entire units that are full of staging DASD - and special units that EMULATE tape - Remember - IBM no longer even sells spinning rust - everything is now solid state - shows how much the technology has evolved. Regards -J- Jeff Bassett Bassettj@... <mailto:Bassettj@...> (301) 424-3362 (office) (240) 388-7148 Cell Time spent flying - is NOT deducted from one’s lifespan -----Original Message-----
From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>> On Behalf Of Dave Trainor - N8ZFM via groups.io Sent: Friday, February 7, 2025 1:22 AM To: [email protected] <mailto:[email protected]> Subject: [H390-MVS] Historical Question So I am studying the OS JCL and Utilities book (Michael Trombetta) from the mid 80's, good book ,was recommended to me for the MVS 3.8j era of JCL. Am happy with it and can also recommend it. They discuss utilization of the MSS storage device(s) a 3850, and at the mid 80's of the book it was a current device, seems to consist of a 3330 disk (maybe more than one) and a series of tape carts, with an "invisible" autoloader system, so as to implement "near-line" storage. Only one actual dasd and a bunch of different images of it on tape, that would be recalled by the VOLSER from MVS and loaded on the live DASD where it was then a live 3330 disk. (obviously a delay in preforming this "staging operation" as I take it was called). Probably more complicated in reality but that is my gist of the functionality. Different logically but easier than mounting a tape, doing a restore, then archiving, not as fast as having dedicated DASD. I assume since I can't find it in Hercules, that this device and not sure to call it tape or disk - is not emulated by Hercules, probably would not be useful and no one uses any such scheme since the mid 80 As the need probably got replaced quickly by vastly larger amounts of cheap DASD being available? Anyone know? Or remember these things and why they are obscure today? I do not see this as being the same functionality as a backup tape library (automounter) of true tapes treated as tapes which is for sure still being utilized. Is my assessment of what this 3850 MSS device was correct? And why we don't have an emulation for such a thing anymore? Thanks, Dave N8ZFM |
|
Re: Historical Question
开云体育Back in, probably the mid 1990's, the competitive analysis team of the tape development mission in Tucson, bought one of these STK tape library silos and played around with it.? They wanted to find a way to increase market share for our IBM tape drives.? They developed a modified version of our tape drive's microcode so that it would identify itself as an STK tape drive and accept commands from the STK silo.? This would allow it to be mounted in an STK silo in place of an STK drive.IBM's first offering of a tape library was a fast-track effort to throw together something that could compete with STK's tape library.? They re-purposed some giant robot mechanism that had been developed for something else to make it do the job of storing and retrieving tapes from a long linear library.? They nicknamed it "Conan the Librarian".? It was a huge overkill but it did the job. IBM's later tape libraries were much better.? They had several of these in some of our labs running 24/7 with some software that would issue continuous random requests for mounts and unmounts of tapes, looking for failures so that the cause could be investigated and corrected.? I think some of the largest libraries could hold 50K tape cartridges. Charles Bailey On 2025-02-07 10:44, S. L. Garwood via
groups.io wrote:
|
|
Re: Historical Question
Oh yes .. the MSS (or Mess as we used to call it). The JES3 interfaces were horrendous - JES3 tried to own all tapes and disks. The cobbled together MSS support was a support nightmare. At the time I was supporting one of our JES3 complexes. ISTR we had 2 of the beasts and they were heavy - the floor had to be checked for weight limits. I used to have a cartridge somewhere but it got lost in one of my moves (or my wife threw it out, along with a complete set of the PL/1 Optimizing and Checkout compiler manuals). That and the IBM tape library were 2 of the not so great ideas from big blue. The STC tape library (the round one) was faster, had better support. |
|
Re: Historical Question
Even modern machines can be interesting. I was on-site at an implementation of a new IBM tape robot box a few years back. The box tested out fine, but intermittently shut down when we were loading tapes. Eventually during one shutdown one robot broke its plastic fingers off.
toggle quoted message
Show quoted text
It turned out one of the doors had a problem with its sensor switch. The movement of loading the tapes caused the machine to think the door had opened, and to protect puny humans the arm was programmed to immediately drop to the floor. By chance, that occurred while the robot had its fingers in a tape slot. It was willing to harm itself instead of possibly harm a human. On 2/7/2025 8:27 AM, Jeff Bassett wrote:
Charles, |
Frank R
to navigate to use esc to dismiss