I hate to post this since it is off topic but....
I am trying to find info on building Herc for macOS Sonoma on a 16 inch M2 ... the Github Herc info seems way out of date - latest RC version is 4.0.0 from 2016 or so. I can build it from source, just want to find any gotchas that may have been documented. I am only going to build an ARM64 version for MacOS. If someone wants a AMD64 version I suppose I could build it too.
As a general comment the documentation seems to have fallen on hard times lately. Way back when ( Hercules 3-13 or so) there was a coherent way to find info and good links in the web pages. I have hit some 404 pages trying to dig around. I just filed a git ticket about the Mac How To having Windows references and assumptions in it.
?
?
|
Re: Jay Moseley's sysgen instructions
On 2/24/25 08:31, William Turner via groups.io wrote: On 2/9/25 14:52, Andre via groups.io wrote:
Please, download correct version of mvsInstallationResources from
Andre
_._,_._,_ Thank you - apologies for not keeping my notes up-to-date. I didn't
realize they changed quite so often. Anyway, I managed to carry out the
build to completion, learning a lot in the the process as always. Many
thanks for the pointer and, of course, to Jay for such detailed and
complete instructions.
Two minor problems - isn't there always something :-
In the ? "Performing a System Generation" stage, the "usermods.jcl" step
fails one update namely UMOD009 because member MS00100 was not found in
the dataset SYS1.USERMODS. I haven't been able to find the item anywhere
so am not sure what that will affect. Otherwise, the final 3390 build
went extremely well and no further problems.
The logon procs for the default userids HMVS01 and HMVS02 use REVINIT to
start RPF and/or REVIEW (not sure which) but it is missing or, at least,
not in the normal executable chain and I have not been able to find it.
Not a serious problem, I changed REVINIT to RPF in one userid logon and
RFE in the other so I have both ;-)
Best regards
Bill
Bill, The series of pages for installing MVS 3.8j from the IBM distribution tape images has not been getting complete updates terribly frequently. I did make a couple of revisions to the tape image containing the DASD User Modifications, which is what snagged you. Rob Prins fed me some updates which, one way or another, caused a couple of update cycles to the het tape image, before we got it settled. As I recall, we went from VOLSER J90009 (Jim Morrison's original designation) to the current J90012. At that time, I simply put some comments wherever the name of the tape image and VOLSER were mentioned, as I didn't have time immediately to go through the entire installation and capture new screen shots wherever the tape VOLSER was displayed. Later I did update all the captures and page text during June, 2024, although even that was not a complete overhaul. The cover letter and ZAPs for MS00100 are loaded from tape (usermods.het, tape dataset #2, SMP.SMPPTFIN) in the second step of job USERMODS (step name PDSLOAD, program executed is PDSLOAD). From the SYSOUT from the last SYSGEN I did (for the system I currently run each day): ./ ADD NAME=JLM0005 MEMBER JLM0005 ADDED (20 RECORDS) ./ ADD NAME=MS00100 MEMBER MS00100 ADDED (70 RECORDS) <--- ./ ADD NAME=M096220 MEMBER M096220 ADDED (89 RECORDS) Neither RPF or REVINIT are installed until the page following the System Generation instructions. REVINIT is installed as a part of Greg Price's REVIEW package. I suppose to eliminate the possibility of seeing an error from occurring during a logon prior to completing the customization (REVIEW is part of the TSO applications package added from the het image tsoaps.het), I can remove the REVINIT line from the logon procedure and have the installation job for REVIEW add it at the same time REVIEW is installed. I already have a Batch TSO job to edit the REVINIT add a VOLUME parameter to the ISP Profile dataset allocation, and that could easily be inserted in that step (STEP14 of job MVS03). I am looking at a new update to the MVS 3.8j installation/SYSGEN instructions in the not too distant future. Lots of small items need updating. For instance, Rob Prins' RPF no longer requires a separate profile, as it now uses the ISP Profile dataset that Wally Mclaughlin's ISPF and Greg Price's REVIEW use. It does no harm for this allocation to still be present if you later upgrade to the latest version of RPF, but it just needs to be cleaned up. All but one of the changes I need to make to the process are like that, just small changes that have accumulated as various applications have been upgraded. Jay
|
Re: Jay Moseley's sysgen instructions
On 2/9/25 14:52, Andre via groups.io
wrote:
Please, download correct version of mvsInstallationResources
from
?
Andre
_._,_._,_
Thank you - apologies for not keeping my notes up-to-date. I
didn't realize they changed quite so often. Anyway, I managed to
carry out the build to completion, learning a lot in the the
process as always. Many thanks for the pointer and, of course, to
Jay for such detailed and complete instructions.
Two minor problems - isn't there always something :-
In the ? "Performing a System Generation" stage, the
"usermods.jcl" step fails one update namely UMOD009 because member
MS00100 was not found in the dataset SYS1.USERMODS. I haven't been
able to find the item anywhere so am not sure what that will
affect. Otherwise, the final 3390 build went extremely well and no
further problems.
The logon procs for the default userids HMVS01 and HMVS02 use
REVINIT to start RPF and/or REVIEW (not sure which) but it is
missing or, at least, not in the normal executable chain and I
have not been able to find it. Not a serious problem, I changed
REVINIT to RPF in one userid logon and RFE in the other so I have
both ;-)
Best regards
Bill
|
I did forget about not everyone using Linux or a derivative of Unix as a host.
Probably a good point on adding some delay as I can certainly see that instant operation, which a software emulation would have, of this device, could certainly cause problems.
How it would be implemented, one huge file vs several in a directory or collection of files would depend on the approach the programmer took to writing the device emulation.
I agree the mechanical aspect of this was very interesting, and watching the video of the device work, I enjoy the watchmaking aspect of it but it seems that was also one of the main issues with its reliability.????
I also agree that TCP/IP would be nice, but also we could just run a later version of MVS and get that. ?
Is most likely not worth much effort at all if its more than a trivial endeavor as the usefulness of it is not huge,
?
Dave, N8ZFM
?
?
?
toggle quoted message
Show quoted text
On 20/02/2025 05:06, Dave Trainor - N8ZFM via groups.io wrote:
In the interest of the historical pats of this hobby,? having such a device available to use in Hercules might not be a bad idea, (...or maybe it is as I am speculating).?
I think its an interesting idea but ...
It’s not an autotape library, but it's an auto dasd library of 3330's in appearance to MVS, the support for the device is apparently in the OS already, so it’s a single address and provides a selection of 3330 volumes.? - Admittedly small in size by today's standards, but the allocation in the underlying Linux disk system is not overly large, the mechanical aspects would not exist as it's all software as a Hercules device.
Not everyone is a linux user!
?
So the issues relating to this at the time being cumbersome and prone to breakage were all in the mechanical aspect, and it would no doubt be faster in operation.
You might need to slow it down. We already have issues with emulated tape because rewind and unload is instant.
???
Now I have no idea the effort required to create such a device, and assume one would need to have allocated the entire disk space at the time of creation of this MSS device when adding it to a config file.?? But it might be interesting to have. The whole allocation is not that excessively large given our host system disk space available. I mean seriously, a Tb is trivial anymore.
It depends how you implement it. You could just use one "huge" file and have some king of mapping logic, or one file for each cartridge and actually copy them to tracks on an emulated 3330.
If you have one file for each cartridge you don't need to create them all at boot up.? You can just have a cartridge number in the name and create as needed...
?
What are the thoughts of others???? I would not be capable at the moment of creating this addition to Hercules itself to allow it to be allocated, and that may be a huge task for all I know it is.?? This is a question to the developers of Hercules and they no doubt have many competing priorities, this would be low priority.
I think the Hercules work isn't terrible, but like you I can't do it. There are other things I think that are more interesting....
... real TCPIP for example...
?
But it might be nice to have it none the less, as a historical artifact, still useful, ecpically since the mechanical issues would not exist.? For those using MVS 3.8.??? It truly was a good idea at the time, and of course disk sizes and technology has passed it by, but so has technology passed by a lot of this and we still play with it.
?
?
What's anyone think?
I think that what was interesting about this was the mechanical aspects. Remove those and things get a little boring. Does any one run tape sorts...
?
?
Dave,
N8ZFM, Louisville, KY
dave@...?? dave40272@...
??
?
Dave
G4UGM
|
No offense taken, it’s a fair opinion. Dave, N8ZFM ?On 2/20/25, 9:40 AM, " [email protected] <mailto: [email protected]> on behalf of Jeff Bassett" < [email protected] <mailto: [email protected]> on behalf of bassettj@... <mailto:bassettj@...>> wrote: Dave, You asked - WASTE OF TIME AND EFFORT (IMHO) Sorry to sound negative. -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: Thursday, February 20, 2025 12:07 AM To: [email protected] <mailto: [email protected]> Subject: Re: [H390-MVS] Historical Question In the interest of the historical pats of this hobby, having such a device available to use in Hercules might not be a bad idea, (...or maybe it is as I am speculating). It’s not an autotape library, but it's an auto dasd library of 3330's in appearance to MVS, the support for the device is apparently in the OS already, so it’s a single address and provides a selection of 3330 volumes. - Admittedly small in size by today's standards, but the allocation in the underlying Linux disk system is not overly large, the mechanical aspects would not exist as it's all software as a Hercules device. So the issues relating to this at the time being cumbersome and prone to breakage were all in the mechanical aspect, and it would no doubt be faster in operation. Now I have no idea the effort required to create such a device, and assume one would need to have allocated the entire disk space at the time of creation of this MSS device when adding it to a config file. But it might be interesting to have. The whole allocation is not that excessively large given our host system disk space available. I mean seriously, a Tb is trivial anymore. What are the thoughts of others? I would not be capable at the moment of creating this addition to Hercules itself to allow it to be allocated, and that may be a huge task for all I know it is. This is a question to the developers of Hercules and they no doubt have many competing priorities, this would be low priority. But it might be nice to have it none the less, as a historical artifact, still useful, ecpically since the mechanical issues would not exist. For those using MVS 3.8. It truly was a good idea at the time, and of course disk sizes and technology has passed it by, but so has technology passed by a lot of this and we still play with it. What's anyone think? Dave, N8ZFM, Louisville, KY dave@... <mailto:dave@...> dave40272@... <mailto:dave40272@...> On 2/7/25, 11:23 AM, " [email protected] <mailto: [email protected]> <mailto: [email protected] <mailto: [email protected]>> on behalf of Charles Bailey" < [email protected] <mailto: [email protected]> <mailto: [email protected] <mailto: [email protected]>> on behalf of txlogicguy@... <mailto:txlogicguy@...> <mailto:txlogicguy@... <mailto:txlogicguy@...>>> wrote: When I worked for IBM in Tucson, AZ, in the early 1980's, much of our data was stored on MSS. When we would run a foreground job from TSO, the application would typically output a message like: "Allocating datasets, please be patient". That is because executing a statement like "ALLOC DD(xxxx) DSN(xxx.yyy.zzz)" took a half minute to a full minute to execute. The MSS monstrosity was amazing to watch in operation. It consisted of a wall of honeycomb-like compartments where the tapes were stored. The operation of the whole contraption was mostly transparent to the user. The command to allocate a dataset would cause the picker to locate the honeycomb location where the tape was stored, retrieve it, and mount it on a device that emulated a DASD. I don't think the tape was copied to a real DASD. Data was read from and written directly to the tape, which was quite wide. I think each vertical (crosswise) stripe on the tape emulated a DASD track. When a FREE command was executed, the tape would be rewound back into the cartridge and the picker would put it back into the honeycomb. I'm not sure if any special support would be required from Hercules. I think the VOLSER of the tape appeared to the OS as just another 3330 DASD. (This is all from my distant memory of conversations with older engineers would used to work on the beast. I'm sure an internet search would yield a much better description.) Charles Bailey On 2025-02-07 00:21, Dave Trainor - N8ZFM wrote: 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: DLI loading on Tk4 and MVSCE?
Hello Kevin, thanks for the notes. I hope it didn't sound like I was disparaging your programs, I certainly didn't mean to. I think the whole collection of tests is great. I'll move on to the next test job as soon as I can find some time,
?
Regards, JJ
|
Re: DLI loading on Tk4 and MVSCE?
Well, it's still early days yet. So far I've only managed to do a sequential load of a database, in which all of the segments have been stored in the ISAM (VSAM) file. What will happen if and when DL/I decides that it needs to write something into the OSAM file, who knows? All that has happened to the OSAM file up to now is that DL/I has opened it and closed it, that's all - nothing has been written to OSAM (the OSAM file that I've defined is not a VSAM file, by the way, it's a regular old MVS disk dataset). Whatever happens from here, I don't expect it to be easy - every step along the way so far has involved one or more abends, followed by debugging, followed (usually) by going back and changing the starter macros in some way.
?
My main problem is going to be finding the time to push this along further from here. If I can make progrees, I'll report it here.
?
?
?
|
Basically, each mass storage device held half a 3330 volume for a user.??
In a Hercules environment, a similar effect? could be a user gets a single DASD volume that is mounted when they sign in and demounted when they log off.??
This would require logic to scan the correct range of UCBs for an unused UCB then issuing?the volume mount.? And signoff would unmount the volume.
It would allow the system to handle a large number of users without generating a large number of devices so all volumes are online at the same time.
On Wed, Feb 19, 2025 at 11:06?PM Dave Trainor - N8ZFM via <dave= [email protected]> wrote: In the interest of the historical pats of this hobby,? having such a device available to use in Hercules might not be a bad idea, (...or maybe it is as I am speculating).? It’s not an autotape library, but it's an auto dasd library of 3330's in appearance to MVS, the support for the device is apparently in the OS already, so it’s a single address and provides a selection of 3330 volumes.? - Admittedly small in size by today's standards, but the allocation in the underlying Linux disk system is not overly large, the mechanical aspects would not exist as it's all software as a Hercules device.
So the issues relating to this at the time being cumbersome and prone to breakage were all in the mechanical aspect, and it would no doubt be faster in operation.
Now I have no idea the effort required to create such a device, and assume one would need to have allocated the entire disk space at the time of creation of this MSS device when adding it to a config file.? ?But it might be interesting to have. The whole allocation is not that excessively large given our host system disk space available. I mean seriously, a Tb is trivial anymore.
What are the thoughts of others?? ? I would not be capable at the moment of creating this addition to Hercules itself to allow it to be allocated, and that may be a huge task for all I know it is.? ?This is a question to the developers of Hercules and they no doubt have many competing priorities, this would be low priority.
But it might be nice to have it none the less, as a historical artifact, still useful, ecpically since the mechanical issues would not exist.? For those using MVS 3.8.? ? It truly was a good idea at the time, and of course disk sizes and technology has passed it by, but so has technology passed by a lot of this and we still play with it.
What's anyone think?
Dave,
N8ZFM, Louisville, KY
dave@...? ?dave40272@...
?On 2/7/25, 11:23 AM, "[email protected] <mailto:[email protected]> on behalf of Charles Bailey" <[email protected] <mailto:[email protected]> on behalf of txlogicguy@... <mailto:txlogicguy@...>> wrote:
When I worked for IBM in Tucson, AZ, in the early 1980's, much of our
data was stored on MSS. When we would run a foreground job from TSO,
the application would typically output a message like: "Allocating
datasets, please be patient". That is because executing a statement
like "ALLOC DD(xxxx) DSN(xxx.yyy.zzz)" took a half minute to a full
minute to execute. The MSS monstrosity was amazing to watch in
operation. It consisted of a wall of honeycomb-like compartments where
the tapes were stored. The operation of the whole contraption was
mostly transparent to the user. The command to allocate a dataset would
cause the picker to locate the honeycomb location where the tape was
stored, retrieve it, and mount it on a device that emulated a DASD. I
don't think the tape was copied to a real DASD. Data was read from and
written directly to the tape, which was quite wide. I think each
vertical (crosswise) stripe on the tape emulated a DASD track. When a
FREE command was executed, the tape would be rewound back into the
cartridge and the picker would put it back into the honeycomb. I'm not
sure if any special support would be required from Hercules. I think
the VOLSER of the tape appeared to the OS as just another 3330 DASD.
(This is all from my distant memory of conversations with older
engineers would used to work on the beast. I'm sure an internet search
would yield a much better description.)
Charles Bailey
On 2025-02-07 00:21, Dave Trainor - N8ZFM wrote:
> 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
>
>
>
>
>
>
>
>
-- Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
|
Re: DLI loading on Tk4 and MVSCE?
I would be interested in how you got 360 era DL/1 (the only one AFAIK in the public domain) to talk to an entry sequenced 'OSAM' file. ?The MVS versions were definitely not unlicensed. The ISAM to VSAM key sequenced file I can understand with the ISAM to VSAM bridge. I don't ever recall that the pre-IMSVS DL/1 code ever even understanding VSAM. Especially the mess that was OSAM - custom open, dynamic DEB built, TCLOSE every write.
?
|
Re: DLI loading on Tk4 and MVSCE?
John, On Thu, Feb 20, 2025 at 02:08:26AM -0800, John James via groups.io wrote: I suspect the the given COBOL program has some issues. I don't know where
the DL/I testing program suite came from (I found the name Monceaux in one
place - I don't know who that is), That would be me. and I'm not convinced that the logic is 100% reliable (for example, it
doesn't even count the number of input records correctly). There is a good chance the logic is illogical. I'm a COBOL novice, and DL/I pre-novice. I'm surprised I got it working at all on MVT way back then. I was lead to believe that the OSAM appendage we have is incompatible with MVS, so it's exciting to hear that someone has managed to get it working on MVS. -- Kevin Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
|
Re: DLI loading on Tk4 and MVSCE?
John,
It has been a VERY LONG TIME AGO – however, I seem to remember there is a HIGH VALUES record at the end
?
There were many tricks with the old IMS data bases – like loading in reverse sequence to prevent the index from getting overwhelmed as it grew
?
?
?
-J-
?
Jeff Bassett
Bassettj@...
(301) 424-3362 (office)
(240) 388-7148 Cell
?
Time spent flying? - is
NOT deducted from one’s lifespan
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of John James via groups.io
Sent: Thursday, February 20, 2025 8:29 AM
To: [email protected]
Subject: Re: [H390-MVS] DLI loading on Tk4 and MVSCE?
?
So... a brief update in case anyone is really interested.
A couple of little tweaks to the COBOL code and to the VSAM cluster setup, and it all appears to have worked. A hundred thousand segments loaded onto a new DL/I database successfully, and read back/printed using IDCAMS.
Just one interesting thing, there's a 100,001st segment loaded at the back end of the VSAM file, which appears to have some kind of high-values key. I suspect that it's been added there by DL/I or VSAM for some obscure reason that will
hopefully become clear in due course.
I hope to have time soon to get onto some real testing - updating segments, inserting and deleteing segmants, and so on.
|
Dave,
You asked - WASTE OF TIME AND EFFORT (IMHO)
Sorry to sound negative.
-J-
Jeff Bassett
Bassettj@...
(301) 424-3362 (office)
(240) 388-7148 Cell
Time spent flying - is NOT deducted from one’s lifespan
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of Dave Trainor - N8ZFM via groups.io Sent: Thursday, February 20, 2025 12:07 AM To: [email protected]Subject: Re: [H390-MVS] Historical Question In the interest of the historical pats of this hobby, having such a device available to use in Hercules might not be a bad idea, (...or maybe it is as I am speculating). It’s not an autotape library, but it's an auto dasd library of 3330's in appearance to MVS, the support for the device is apparently in the OS already, so it’s a single address and provides a selection of 3330 volumes. - Admittedly small in size by today's standards, but the allocation in the underlying Linux disk system is not overly large, the mechanical aspects would not exist as it's all software as a Hercules device. So the issues relating to this at the time being cumbersome and prone to breakage were all in the mechanical aspect, and it would no doubt be faster in operation. Now I have no idea the effort required to create such a device, and assume one would need to have allocated the entire disk space at the time of creation of this MSS device when adding it to a config file. But it might be interesting to have. The whole allocation is not that excessively large given our host system disk space available. I mean seriously, a Tb is trivial anymore. What are the thoughts of others? I would not be capable at the moment of creating this addition to Hercules itself to allow it to be allocated, and that may be a huge task for all I know it is. This is a question to the developers of Hercules and they no doubt have many competing priorities, this would be low priority. But it might be nice to have it none the less, as a historical artifact, still useful, ecpically since the mechanical issues would not exist. For those using MVS 3.8. It truly was a good idea at the time, and of course disk sizes and technology has passed it by, but so has technology passed by a lot of this and we still play with it. What's anyone think? Dave, N8ZFM, Louisville, KY dave@... dave40272@... ?On 2/7/25, 11:23 AM, " [email protected] <mailto: [email protected]> on behalf of Charles Bailey" < [email protected] <mailto: [email protected]> on behalf of txlogicguy@... <mailto:txlogicguy@...>> wrote: When I worked for IBM in Tucson, AZ, in the early 1980's, much of our data was stored on MSS. When we would run a foreground job from TSO, the application would typically output a message like: "Allocating datasets, please be patient". That is because executing a statement like "ALLOC DD(xxxx) DSN(xxx.yyy.zzz)" took a half minute to a full minute to execute. The MSS monstrosity was amazing to watch in operation. It consisted of a wall of honeycomb-like compartments where the tapes were stored. The operation of the whole contraption was mostly transparent to the user. The command to allocate a dataset would cause the picker to locate the honeycomb location where the tape was stored, retrieve it, and mount it on a device that emulated a DASD. I don't think the tape was copied to a real DASD. Data was read from and written directly to the tape, which was quite wide. I think each vertical (crosswise) stripe on the tape emulated a DASD track. When a FREE command was executed, the tape would be rewound back into the cartridge and the picker would put it back into the honeycomb. I'm not sure if any special support would be required from Hercules. I think the VOLSER of the tape appeared to the OS as just another 3330 DASD. (This is all from my distant memory of conversations with older engineers would used to work on the beast. I'm sure an internet search would yield a much better description.) Charles Bailey On 2025-02-07 00:21, Dave Trainor - N8ZFM wrote: 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: DLI loading on Tk4 and MVSCE?
So... a brief update in case anyone is really interested.
?
A couple of little tweaks to the COBOL code and to the VSAM cluster setup, and it all appears to have worked. A hundred thousand segments loaded onto a new DL/I database successfully, and read back/printed using IDCAMS.
?
Just one interesting thing, there's a 100,001st segment loaded at the back end of the VSAM file, which appears to have some kind of high-values key. I suspect that it's been added there by DL/I or VSAM for some obscure reason that will hopefully become clear in due course.
?
I hope to have time soon to get onto some real testing - updating segments, inserting and deleteing segmants, and so on.
?
JJ
|
Re: DLI loading on Tk4 and MVSCE?
Many thanks for the replies. Creating the IEAAPP00 member has indeed solved the imediate problem. But, as usual, that has just meant that I've moved on to something else.
?
I can report that both the HISAM and OSAM files are now opening OK (as far as I can see) and that DL/I is now writing into the HISAM file as it should for a DL/I load operation.
?
But there seems to be an issue in that additional strange records are being written to HISAM (which is actually VSAM, via the "bridge"). Whether I have defined the VSAM cluster incorrectly, or whether there is duff logic in the COBOL program, I don't know., so that's my next avenue to investigate.
?
I suspect the the given COBOL program has some issues. I don't know where the DL/I testing program suite came from (I found the name Monceaux in one place - I don't know who that is), and I'm not convinced that the logic is 100% reliable (for example, it doesn't even count the number of input records correctly).
?
So... further investigating to be done when I have a chance, JJ
?
|
On 20/02/2025 05:06, Dave Trainor -
N8ZFM via groups.io wrote:
In the interest of the historical pats of this hobby, having such a device available to use in Hercules might not be a bad idea, (...or maybe it is as I am speculating).
I think its an interesting idea but ...
It’s not an autotape library, but it's an auto dasd library of 3330's in appearance to MVS, the support for the device is apparently in the OS already, so it’s a single address and provides a selection of 3330 volumes. - Admittedly small in size by today's standards, but the allocation in the underlying Linux disk system is not overly large, the mechanical aspects would not exist as it's all software as a Hercules device.
Not everyone is a linux user!
So the issues relating to this at the time being cumbersome and prone to breakage were all in the mechanical aspect, and it would no doubt be faster in operation.
You might need to slow it down. We already have issues with emulated
tape because rewind and unload is instant.
Now I have no idea the effort required to create such a device, and assume one would need to have allocated the entire disk space at the time of creation of this MSS device when adding it to a config file. But it might be interesting to have. The whole allocation is not that excessively large given our host system disk space available. I mean seriously, a Tb is trivial anymore.
It depends how you implement it. You could just use one "huge" file
and have some king of mapping logic, or one file for each cartridge
and actually copy them to tracks on an emulated 3330.
If you have one file for each cartridge you don't need to create
them all at boot up.? You can just have a cartridge number in the
name and create as needed...
?
What are the thoughts of others? I would not be capable at the moment of creating this addition to Hercules itself to allow it to be allocated, and that may be a huge task for all I know it is. This is a question to the developers of Hercules and they no doubt have many competing priorities, this would be low priority.
I think the Hercules work isn't terrible, but like you I can't do
it. There are other things I think that are more interesting....
... real TCPIP for example...
But it might be nice to have it none the less, as a historical artifact, still useful, ecpically since the mechanical issues would not exist. For those using MVS 3.8. It truly was a good idea at the time, and of course disk sizes and technology has passed it by, but so has technology passed by a lot of this and we still play with it.
What's anyone think?
I think that what was interesting about this was the mechanical
aspects. Remove those and things get a little boring. Does any one
run tape sorts...
Dave,
N8ZFM, Louisville, KY
dave@... dave40272@...
Dave
G4UGM
|
In the interest of the historical pats of this hobby, having such a device available to use in Hercules might not be a bad idea, (...or maybe it is as I am speculating). It’s not an autotape library, but it's an auto dasd library of 3330's in appearance to MVS, the support for the device is apparently in the OS already, so it’s a single address and provides a selection of 3330 volumes. - Admittedly small in size by today's standards, but the allocation in the underlying Linux disk system is not overly large, the mechanical aspects would not exist as it's all software as a Hercules device. So the issues relating to this at the time being cumbersome and prone to breakage were all in the mechanical aspect, and it would no doubt be faster in operation. Now I have no idea the effort required to create such a device, and assume one would need to have allocated the entire disk space at the time of creation of this MSS device when adding it to a config file. But it might be interesting to have. The whole allocation is not that excessively large given our host system disk space available. I mean seriously, a Tb is trivial anymore. What are the thoughts of others? I would not be capable at the moment of creating this addition to Hercules itself to allow it to be allocated, and that may be a huge task for all I know it is. This is a question to the developers of Hercules and they no doubt have many competing priorities, this would be low priority. But it might be nice to have it none the less, as a historical artifact, still useful, ecpically since the mechanical issues would not exist. For those using MVS 3.8. It truly was a good idea at the time, and of course disk sizes and technology has passed it by, but so has technology passed by a lot of this and we still play with it. What's anyone think? Dave, N8ZFM, Louisville, KY dave@... dave40272@... ?On 2/7/25, 11:23 AM, " [email protected] <mailto: [email protected]> on behalf of Charles Bailey" < [email protected] <mailto: [email protected]> on behalf of txlogicguy@... <mailto:txlogicguy@...>> wrote: When I worked for IBM in Tucson, AZ, in the early 1980's, much of our data was stored on MSS. When we would run a foreground job from TSO, the application would typically output a message like: "Allocating datasets, please be patient". That is because executing a statement like "ALLOC DD(xxxx) DSN(xxx.yyy.zzz)" took a half minute to a full minute to execute. The MSS monstrosity was amazing to watch in operation. It consisted of a wall of honeycomb-like compartments where the tapes were stored. The operation of the whole contraption was mostly transparent to the user. The command to allocate a dataset would cause the picker to locate the honeycomb location where the tape was stored, retrieve it, and mount it on a device that emulated a DASD. I don't think the tape was copied to a real DASD. Data was read from and written directly to the tape, which was quite wide. I think each vertical (crosswise) stripe on the tape emulated a DASD track. When a FREE command was executed, the tape would be rewound back into the cartridge and the picker would put it back into the honeycomb. I'm not sure if any special support would be required from Hercules. I think the VOLSER of the tape appeared to the OS as just another 3330 DASD. (This is all from my distant memory of conversations with older engineers would used to work on the beast. I'm sure an internet search would yield a much better description.) Charles Bailey
On 2025-02-07 00:21, Dave Trainor - N8ZFM wrote: 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: DLI loading on Tk4 and MVSCE?
Looking at the DL/1 manual in the OS360 file section ( /g/hercules-os360/files/DLI/360D-01.6.007.pdf ), on page 161, it refers to IGG019Z8 as the Channel End Appendage (CHEAPP), but this is no guarantee it will work in MVS 3.8.? It also indicates it should be copied to SYS1.SVCLIB, along with other DL/1 IGG modules (which could already exist - I didn't check). ?
As usual, make backups and proceed at your own risk.
?
Shawn Goodin
|
Re: DLI loading on Tk4 and MVSCE?
Look in the MVS 3.7 manual on Bitsavers. GC28-0681-2 OS/VS2 SPL Initialization and Tuning?Guide.? Even though it says 3.7, that's when the parameter was added, and will be applicable for MVS 3.8.
?
I don't know what the I/O appendage module's name is, but it's probably in the DL1 program library as IGG019xx, where xx is the appendage name to be specified in IEAAPP00.? The module itself probably needs to be copied to SYS1.LPALIB, or perhaps SYS1.SVCLIB.
?
The DL1 manual probably specifies which appendage the module is for (SIOAPP, EOEAPP, PCIAPP, CHEAP, ABEAPP).
?
Create an IEAAPP00 member with the format of?
?
appendage type? ?suffix
?
so, ab example is?
?
SIOAPP? ?WA,W1
?
which would load startI/O appendages as IGG019WA and IGG019W1.
?
I don't think anything is needed in IEASYSxx.
?
I also doubt that? RAKF has anything to do with this.? An authorized module means that it resides in an authorized library (LPALIB and SVCLIB are both authorized) and the module was linked as AC=1.
?
Shawn Goodin
|
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 Dagfinn
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
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: 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?
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
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: 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
--
|
Jeff Bassett
Shawn Goodin