|
On 2/26/25 13:22, John James via groups.io wrote: P.S. Is there is user guide available anywhere for RECV370? Darned if I can remember how to use it. Thanks.
The source is included on SYSCPK, and also available at CBT:
|
Allan, yes, that's a pretty good summary of why you'd probably have to be insane to try to get IMS/360 DL/I (especially what appears to be a beta version) working on MVS.
?
Which I suppose is where I come in. Looks like a nice little project to me, especially as there's no pressure or a given target date. I can take as much time as I like.
?
As far as the OSAM DCB is concerned, I imported an MVT copy of SYS.1.MACLIB into MVS, and used it for the IMSGEN, PSBGEN, and DBDGEN. Has worked fine so far.
?
The OSAM SVC was no problem. For convenience, I copied it into SYS1.LPALIB as SVC 233, an unused Type 4 slot on TK4-, and it's working fine. It's a very small piece of code that, as far vas I can see, should run as any SVC type.
?
The matter of the OSAM channel-end appendage and the IEAAPP00 SYS1.PARMLIB member was straightforward to address. I created the IEAAPP00 member with some help from the good folk on this forum.
?
At that point, DL/I loaded up a database with new main segments. But, as I had expected, in the next test the load of dependent segements into the OSAM file failed because the OSAM DEB had been GETMAINed from the wrong subpool (from subpool zero, when in MVS it should be subpool 230). The offending module is DFSIOS10, but the source code that we have is incomplete. So my next task is to use a disassembler (as supplied to me by the ever-helpful Jay Moseley) to make changes to that module. No doubt there will be more problems to solve after that. I think this little project is going to give me something interesting to do for some time yet.
?
Regards, JJ
?
P.S. Is there is user guide available anywhere for RECV370? Darned if I can remember how to use it. Thanks.
|
Performing a little searching, I found this link which shows the difficulty of ever getting that version of DLI to work on MVS 3.8:
?
|
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
|
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.
?
?
?
|
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.
?
|
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.
|
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.
|
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
|
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
?
|
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
|
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
|
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
--
|
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
--
|
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
|
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
|
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.
?
|
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
|
John James wrote: Just wondering how to persuade the automated operator
to do it for me.
As a fully paid-up member of the Lazy so-and-so society, * So, e.g.: hao tgt IEA101A... hao cmd /r 00,clpa hao tgt ...(clpa response message)... hao clear (I don't use TK myself, so I'm not familiar with the messages that it issues.) -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Just wondering how to persuade the automated operator to do it for me.
As a fully paid-up member of the Lazy so-and-so society,
JJ
|
Jeff Bassett
Shawn Goodin