The second job (iehmove2.jcl) won’t process the tape because its target is already known to RACF. (I have to type in from memory, as laptop shutdown at moment)

The DLI files came from Moshix’ github, and the JCL modified to have a username and passwords on the jobcard, and to put the files on pub003/Pub001 respectively, fix unit to match.

This was with users Herc01 and MVSCE01, respectively.

What’s necessary to get IEBMOVE to pass RAKF muster when it creates datasets? First job works fine…but that creates the pds explicitly.



Thanks!

—顿别补苍

Hi Dean,

Have you checked the authorization rules in SYS1.SECURE.CNTL(PROFILES)?
Perhaps there are some rules, that obstruct you, creating datasets.

The original user HERC01 has the group RAKFADM.? This group has a many RAKF privileges.
You should check if the datasets created by IEHMOVE does have the ALTER attribute in
SYS1.SECURE.CNTL(PROFILES).

If you add rules in this member don't forget to start RAKFPROF to make the rules effective,

Cheers,
Rob

Hello Dean,

I have tried recently to install DL/I from moshix github. As far as i understood, it is intended to be installed on MVT, not MVS.
Also using that tape, you would not be able to run third job iehmove3.jcl, cause it does not contain two tapemarks at the end.
Rene Ferland helped me with that and created corrected tape, which i will attach to this message.
Using this tape and MVT i was able to restore all datasets to 2314 DASD SORT01.CCKD that i created beforehand.
If you want, i can send it to you.

Best wishes,
Andre

Andre,

(and anyone else trying to get this to work under MVS) ...

Note that IMS or DL/1 used "channel end appendages" to do various tricks to keep channel programs going.

This kind of tricky stuff usually does not work well, or at all, under MVS, due to virtual memory, paging, etc.

So, my advice would be to only attempt to use this in a V=R region, that more closely emulates OS/360 MVT, without doing any "paging" or channel program translation, etc.

Also, I do not think we have all of the source code for that ancient first version of IMS for OS, so some disassembly may be required to figure out what the special SVCs for DL/1 are doing, and possibly they may require some modifications to work in MVS.

I applaud any and all efforts to get this early DBMS running under MVS (or even under OS/360 MVT).

Mark S. Waterbury

Going back many many years I spent a lot of time with IMS/360 on MVT/MFT. The DL/1 database system is essentially ISAM; the channel? end appendages logic that you refer to relates to a part of DL/1 called OSAM - the Overflow Sequential Access Method - used by IMS to maintain data segments that have been inserted into a running DL/1(ISAM) database. Such insertions could optionally be stored in an additional dataset labelled OVFLOW in the JCL (in the latest IMS/VS version, OSAM is still there, but the allocation protocol in the JCL is completely different).

I have never used IMS/360 under MVS, but I can confirm that IMS/360 worked fine on SVS. I never had to run it V=R or anything like that. Presumably the OSAM stuff was not a problem on SVS. It sounds like the consensus is that it could be an issue on MVS.

So my suggestion would be to try to avoid OSAM under MVS.

I would suggest using the ISAM-VSAM bridge (AMP='AMORG') instead of an ISAM/OSAM database. So you would define the database as a VSAM dataspace and run IMS/360 against that. Hopefully VSAM would handle all the I/O without having to worry about the OSAM channel end appendages stuff when data segments are inserted.

Just a suggestion. I would love to have a go at getting IMS/360 running again, but I just don't have the time at the moment.

If you have an opportunity to try this, I be very interested to hear how you get on.

JJ

Following on from my post dated December 13th, I had a spare hour this evening, and I downloaded the "The DL/I" system (AKA, I believe, IMS/360); I did the stage 1 and stage 2 sysgen to install the DB-only system on TK4-, and everything appears to have gone well. Of course, I have no idea whether it's going to work OK because I don't have an IMS DB application that I can run to test it.

So, a question: does anyone out there have a sample IMS DB application that I could get hold of, or do you know where I can find one (perhaps some very old IMS/360 manual or something?). It would have to be not only the programs themselves, but also the control blocks and some data to load a DL/I database.

If I can find one then I'll see whether it will run on MVS.

JJ

JJ,

On Sun, Dec 24, 2023 at 01:00:20PM -0800, John James wrote:

Following on from my post dated December 13th, I had a spare hour this
evening, and I downloaded the "The DL/I" system (AKA, I believe, IMS/360);
I did the stage 1 and stage 2 sysgen to install the DB-only system on
TK4-, and everything appears to have gone well. Of course, I have no idea
whether it's going to work OK because I don't have an IMS DB application
that I can run to test it.

It don't think it will work, unless someone has found a way to work around
the OSAM appendage issue. If I remember correctly, the OSAM appendage is
incompatible with MVS, and the source code library on the tape is
incomplete.

So, a question: does anyone out there have a sample IMS DB application
that I could get hold of, or do you know where I can find one (perhaps
some very old IMS/360 manual or something?). It would have to be not only
the programs themselves, but also the control blocks and some data to load
a DL/I database.

I managed to get it running on MVT many moons ago. Unfortunately I put it
aside for too many years, didn't make adequate notes, and attempts to get it
running again on MVT have been less than successful. It's been a few years
since I last tried. Maybe I should give it another shot one of these years.

The first time around, I did create a very simple contact address/phone
number database. I took a list of given names, surnames, street names,
etc., and used them to generate random data to insert into the database.
The jobs I used, containing the programs, random data, etc., can be found
at:








--

Kevin


Bruceville, TX

What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.

To Kevin Monceaux,

Please see third reply in this thread.
There is link to restored tape with source code library dataset.

Best wishes,
Andre

Andre, Kevin, and everyone:

When IMS/360 first came out, there was no "IMS/DB" -- there was only the batch DL/1 (IMS/DB) component... the IMS/DB/DC (data communications) came later, after IMS had transitioned from a TYPE II program to a full-fledged IBM "program product."? ?(APL\360, CICS and IMS were, IIRC, the first three IBM software products to be packaged and licensed as "program products.")

We now have INTERCOMM, that can act as an IMS/DC or CICS replacement, and has a "database interface" so that it could be made to work with DL/1, if we can get that going.? :-)? ? INTERCOMM is a part of the MVS-TK5 distribution.? ?INTERCOMM was a popular alternative to CICS in the early days.

You must run the DL/1 job in a V=R (ADDRSPC=REAL) address space, because OSAM used channel end appendages, since that old version of DL/1 was meant for MVT ... V=R gives you much closer compatibility with MVT with regard to things like use of channel programs and channel end appendages, etc.

Also, it should not be a problem to run the DL/1 in a V=R region, while INTERCOMM is running in a normal V=V region, as the INTERCOMM database interface is designed to work with separate jobs and provides an SVC to provide for inter-region communications.

Hope that helps,

Mark S. Waterbury

Hello John James,

How did you manage to copy the datasets from the tape, as the initial question was asked.
I also have a RAKF problem when trying to restore the 2nd and 3rd blocks from tape.

To everybody who has responded to my post of a couple of days ago.

Kevin Monceaux: many thanks for the link that you sent. I'll take a look at it as soon as I have a chance to devote a bit of time and attention to it.

Marcel Faber: I think that the DL/I distribution tape can be found at various places online. The link that I used was ?????
There is also a DL/I manual there, but it's not completely useful. It's stored in a strange orientation and is difficult to read; plus there are some (important) pages missing, and those that are there are sometimes in the wrong order.

Crni Mrki: it looks like you are trying to run the "restorejobs.tar". I didn't link the look of that jobstream, you don't need nine jobsteps to restore one AWS tape. So I constructed some JCL of my own and it ran OK. What I'll do is send it "privately" as an attachment to the email address in your posts. I hope you find it useful.

Regards to everyone, JJ

To Kevin (and everyone), I took a look at the DL/I COBOL application that you provided. Sadly, not much luck so far (as below), but I'll take another look when I have some time. I did the DL/I download from the AWS tape, and the stage 1 and stage 2 IMSGEN worked fine.

So I ran the DL/I application in MVT/HASP, on the basis that it ought to work, and would provide some sort of baseline. The PSBGEN, COBOL compile, and link, all went fine. But the DBDGEN gave me several MNOTE-style errors, which I thought I had fixed, but maybe not. The DLIBATCH execution failed 0C5 as soon as the COBOL program got control. I suspect that the parameter list passed by DFSIRC00 was invalid, but I still have some work to to on the dump.

I then tried MVS (TK4-) and it actually went further. Once again, all started out OK with the exception of the DBDGEN (same error messages, unsurprisingly). The COBOL program got control, outputted an "I've started" message, opened a QSAM file and read several input records, which it used to create a DL/I segment, but when COBOL did an ISRT call on the DL/I database there was an error message from an SVC 19 module. The message was complaining that it couldn't open a DCB because it couldn't find the appropriate DD statement, but it was obvious that the DDNAME had been somehow overwritten with garbage.

If there's anyone out there in MVS land who has a long memory and can recall DL/I, and who remembers any error situations such as those above, then I'd appreciate any ideas about what has gone wrong - so it's (1) strange DBDGEN MNOTE messages (2) 0C5 in DL/I batch (3) open error in DL/I batch with garbled DD name.

I'll keep trying, but time is up for a little while; hopefully I'll get back to it some time in the future.

JJ

On Fri, Jan 05, 2024 at 12:17:26PM -0800, John James wrote:

So I ran the DL/I application in MVT/HASP, on the basis that it ought to
work, and would provide some sort of baseline. The PSBGEN, COBOL compile,
and link, all went fine. But the DBDGEN gave me several MNOTE-style
errors, which I thought I had fixed, but maybe not. The DLIBATCH execution
failed 0C5 as soon as the COBOL program got control. I suspect that the
parameter list passed by DFSIRC00 was invalid, but I still have some work
to to on the dump.

Did you link the DL/I SVC into the nucleus? Rummaging around I think this
is the job I used to link the HASP and DL/I SVCs into a nucleus on the
MVT/HASP system I tried it on:

//P05LSVC JOB 1,'P05LSVC HASP 4',MSGLEVEL=(1,1),CLASS=A,MSGCLASS=A
//****
//* ***
//* Job: P05LSVC ***
//* Product: HASP V4 for MVT. ***
//* Purpose: Link HASP and DL/I SVCs into the nucleus. ***
//* Update: 2003/01/26 ***
//* ***
//****
//*
//LINKSVC EXEC PGM=IEWL,REGION=192K,
// PARM='NCAL,DC,SIZE=(128K,6K),SCTR,LET,LIST,XREF'
//HASPOBJ DD DISP=SHR,DSN=SYS1.HASPOBJ
//DLIRESLB DD DISP=SHR,DSN=DLI.RESLIB
//SVCLIB DD DISP=SHR,DSN=SYS1.SVCLIB
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(10,5))
//SYSLMOD DD DISP=SHR,DSN=SYS1.NUCLEUS
//SYSPRINT DD SYSOUT=A
//SYSLIN DD *
INSERT IEAANIP0
INSERT IEAQFX00
INCLUDE HASPOBJ(HASPSVC)
INCLUDE DLIRESLB(IGG019Z9)
INCLUDE DLIRESLB(IGC230)
INCLUDE SVCLIB(IGC0024H)
INCLUDE SYSLMOD(IEANUC01)
NAME IEANUC01(R)
/*
//
/*EOF

I think that used an alternate nucleus for testing and there were some steps
I can't remember that had to be performed before/during the IPL in Hercules
to select the alternate nucleus. There might also be some other steps
needed with the SVC that I'm forgetting. Does it need to be in an SVC table
somewhere, perhaps in the OS SysGen?




--

Kevin


Bruceville, TX

What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.

I also tried with no success.
The only hope is that moshix would release a video with step by step walkthrough.

Best wishes,
Andre

Thanks for the suggestion. I'll add it to my list of things to look into/think about. As far as I can make out, the IMS SVC had not been invoked by the time the failures occurred, but you never know.

The last time that I installed an SVC for IMS was some time in the 1970s, on MVS and IMS V3 (maybe V4). All that was needed was for the SVC to be given its proper SVC name (IGC0025E) and put in SYS1.SVCLIB. Maybe IMS/360 needs more.

JJ

开云体育

Hi Crni

I don't have a STEP5 in my stage 2 jobstream, but then I did mess a round with the JCL quite extensively.

The ASM and LINK for DFSIDLB0 is below, I didn't see any error messages as far as I can recall,

HTH, JJ

//STEP3? EXEC? PGM=IEUASM,PARM='LOAD,NODECK',REGION=1024K
//SYSLIB?? DD? DSNAME=SYS1.MACLIB,DISP=SHR
//???????? DD? DSNAME=HERC01.IGEN,DISP=(OLD,PASS),
//???????????? UNIT=3390,VOL=SER=PUB013
//SYSGO??? DD? UNIT=SYSDA,DISP=(,PASS),DCB=(LRECL=80,BLKSIZE=400,???? ?
//???????????? RECFM=FB),SPACE=(TRK,(10,10),RLSE)
//SYSPRINT DD? SYSOUT=A,DCB=(LRECL=121,BLKSIZE=605,RECFM=FBA),??????? ?
//???????????? SPACE=(605,(100,50),RLSE,,ROUND)
//SYSUT1 DD??? UNIT=SYSDA,DISP=(,DELETE),SPACE=(1700,(100,50))
//SYSUT2 DD??? UNIT=SYSDA,DISP=(,DELETE),SPACE=(1700,(100,50))
//SYSUT3 DD??? UNIT=(SYSDA,SEP=(SYSLIB,SYSUT1,SYSUT2)),DISP=(,DELETE),
//???????????? SPACE=(1700,(100,50))
//SYSIN? DD??? *
DFSISCD? CSECT
???????? PRINT OFF
???????? DLIBATCH CENDA=Z9,SPVSVC=255
???????? ISCD???? SECTYPE=CSECT
???????? END
/*
//STEP4? EXEC? PGM=IEWL,PARM='REUS,NCAL',REGION=110K
//SYSPRINT DD? SYSOUT=A,DCB=(LRECL=121,BLKSIZE=605,RECFM=FBA),??????? ?
//???????????? SPACE=(605,(10,10),RLSE,,ROUND)
//SYSLIN?? DD? DSNAME=*.STEP3.SYSGO,DISP=(OLD,DELETE)
//???????? DD? DDNAME=SYSIN
//SYSOBJ?? DD? VOLUME=SER=PUB013,DISP=(OLD,PASS),?????????????????? ?
//???????????? DSNAME=HERC01.IRES,UNIT=3390
//SYSLMOD? DD? VOLUME=SER=PUB013,DISP=(OLD,PASS),?????????????????? ?
//???????????? DSNAME=HERC01.IRES,UNIT=3390
//SYSUT1?? DD? UNIT=(SYSDA,SEP=(SYSLIN,SYSLMOD)),DISP=(,DELETE),????? ?
//???????????? SPACE=(1700,(100,50))
//SYSIN??? DD? *
? INCLUDE SYSOBJ(DFSIOS10)?? OSAM OPEN ROUTINE
? INCLUDE SYSOBJ(DFSISMM0)?? STORAGE MANAGEMENT MODULE
? INCLUDE SYSOBJ(DFSIDLO0)?? DL/I OPEN MODULE
? INCLUDE SYSOBJ(DFSIDLC0)?? DL/I CLOSE MODULE
? INCLUDE SYSOBJ(DFSIDBA0)?? DL/I BATCH ANALYZER
? INCLUDE SYSOBJ(DFSIBKB0)?? DL/I BATCH BLOCK MODULE
? ENTRY DFSSTART
? NAME DFSIDLB0(R)???????? DL/I BATCH NUCLEUS
/*

Thank you, I have added DLI.GENLIB in SYSLIB concatenation in my JCL and now is linking OK.

Test program runs good at first look:

Hi, I'm sorry to burst your bubble, but "DL/I Status: AI" means that the ISRT call to the database failed. This is the same result I saw with MVS, as I posted here a few days ago.

If you look at your JES2 console output, you'll probably see a number of messages saying that an Open has failed because a garbled DDNAME could not be found.

I'm going to try to take a look at this a bit further when I get a chance. It might be a problem with the SVC 255 placement, which I'm still thinking about.

JJ