-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
rvjansen@...
Sent: 15 January 2021 21:45
To: [email protected]
Subject: [h390-vm] add new dasd to vm/370 sixpack

I cannot find anything on the net.

What I want to do: add a dasd for a new user (bRexx tester) to a sixpack
instance (I want a new dasd because I will take that dasd for the user to new
systems with new levels of bREXX on it). I also can take a new instance online
and just reuse CMSUSER’s disks, like I did for my own userid, but I thought
that this should be doable and should be documented. I will do the
documenting if someone can help me.

What I did:

(I chose 6A0 because that seemed to be defined as a 3350)

dasdinit -a vm3350-7.6a0.cckd 3350-1 VM50-7

Added that to sixpack.conf at A06, Hercules (4.00) starts without complaining.

Added a clone of CMSUSER to the directory, but with VM50-7 instead of
VM50-6. Ran direct sixpack, worked like a charm. User can logon.

with maint, VARY ONLINE 6A0

ATTACH 6A0 TO SYSTEM

it then complains VOLID MISSING OR INVALID

I cannot find IBCDASDI to put a label on it, but I thought dasdinit did do that

I cannot find SYSTEM CONFIG so I assume this level did not have that yet

On 15 Jan 2021, at 23:57, Dave Wade <dave.g4ugm@...> wrote:

-----Original Message-----
From:?[email protected]?<[email protected]> On Behalf Of
rvjansen@...
Sent: 15 January 2021 21:45
To:?[email protected]
Subject: [h390-vm] add new dasd to vm/370 sixpack

I cannot find anything on the net.

What I want to do: add a dasd for a new user (bRexx tester) to a sixpack
instance (I want a new dasd because I will take that dasd for the user to new
systems with new levels of bREXX on it). I also can take a new instance online
and just reuse CMSUSER’s disks, like I did for my own userid, but I thought
that this should be doable and should be documented. I will do the
documenting if someone can help me.

What I did:

(I chose 6A0 because that seemed to be defined as a 3350)

dasdinit -a vm3350-7.6a0.cckd 3350-1 VM50-7

Added that to sixpack.conf at A06, Hercules (4.00) starts without complaining.

Added a clone of CMSUSER to the directory, but with VM50-7 instead of
VM50-6. Ran direct sixpack, worked like a charm. User can logon.

with maint, VARY ONLINE 6A0

ATTACH 6A0 TO SYSTEM

it then complains VOLID MISSING OR INVALID

You need to specify the volume ID here

"CP ATTACH 6A6 TO SYSTEM AS VM50-7"

I cannot find IBCDASDI to put a label on it, but I thought dasdinit did do that

It does

I cannot find SYSTEM CONFIG so I assume this level did not have that yet

Yes it needs to be assembled into DMKSYS and the nucleus re-built

Dave

On 16 Jan 2021, at 13:58, carlos feldman <carlfelster@...> wrote:

Hi René,

?

For attaching a DOS disk I use a similar procedure as Dave's

a) format a disk for instance?dasdinit -a mydisk.cckd 3350-1 mydisk

b) list in hercules:

07A2? ? 3350? ? Disks/mydisk.cckd ro sf=Disks/Shadows/mydisk_

c) attach it in operator console:

? ?cp attach 7a2 to CMSUSER as 199
?( you'll se a message in CMSUSER console; 199 ATTACHED

d),access it in CMSUSER

? ? ?ACCESS 199 C.

?

In my case is a DOS partition, but you may well format as a CMSDISK.

?

This procedure is repeated each time I logon to CMS.

?

If you want it as a permanent disk, you have to modify and load, the? current direct file to add your disk, for USER CMSUSER:

* userid? ?cuu type adr num volser mode readpw? ?writepw? multpw
? MDISK? ? 191 3350 001 115 VM50-6 MR? ?ALL? ? ? WRITE? ? MULT??
? MDISK? ? 192 3350 116 115 VM50-6 MR? ?ALL? ? ? WRITE? ? MULT??
? MDISK? ? 193 3350 231 115 VM50-6 MR? ?ALL? ? ? WRITE? ? MULT??
? MDISK? ? 194 3350 346 115 VM50-6 MR? ?ALL? ? ? WRITE? ? MULT??
? MDISK? ? 195 3350 461 094 VM50-6 MR? ?ALL? ? ? WRITE? ? MULT??

?

For me, this was a test, so I preferred the first method

--
Carlos

Argentina

?

Hi Carlos,

On 16 Jan 2021, at 16:43, Peter Coghlan <groups@...> wrote:

Hi Rene,

I was thinking to do the VARY ONLINE nnn and the
ATTACH nnn TO SYSTEM AS VM50-X in the PROFILE EXEC of OPERATOR.
But I noticed that disk 191 of OPERATOR was not formatted, and
even when I did that, IPL CMS falls back to CP very quickly. I
gave OPERATOR some more storage, but that did not do the trick.
I am now looking to do that in hercules.rc but I wonder if OPERATOR
should be able to work with CMS.

I have seen it suggested somewhere to put stuff to be done at startup in the
PROFILE EXEC of OPERATOR but I can't recall where. This is not the correct
thing to do. You should place your ATTACH nnn to SYSTEM as xxxxxx command
in the PROFILE EXEC of AUTOLOG1. You won't need the VARY ONLINE command if
the dasd is available when VM ipls, only when it gets attached after VM ipls.

OPERATOR has difficulties with CMS because it is the primary system operator
and comes up in TERM MODE CP by default. You could change it to TERM MODE VM
and have it ipl CMS but I think you would still need to do the equivalent of
pressing enter on the OPERATOR console in order to get the ipl of CMS to
complete. The best idea is to stay away from OPERATOR for this purpose and
get AUTOLOG1 to do stuff that needs to be done at startup, like it is
supposed to do.

Regards,
Peter Coghlan.

best regards,

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Martin Taylor
via groups.io
Sent: Saturday, January 16, 2021 11:07 AM
To: [email protected]
Subject: Re: [h390-vm] add new dasd to vm/370 sixpack

Hello,
I have had the same issue when adding DASD to a VM370 system at the 1.3 level.
Prior to this a simple create of the DASD and adding it to the machine config file
with a suitable device address (that matches the DASD type) was all that was
required. I had added new DASD to a 1.2 system many time with no issue. A
VARY all devices in AUTOLOG1 brought the DASD online. However moving my
system to 1.3 caused all the DASD I had added to become inaccessible with
message DMKLNK108E NOT LINKED NOT MOUNTED being issued when logging
on to an affected user.

The cause of the above problem is that in VM/370 1.3 a fix is implemented that
meant that the SYSUSR parameter, in DMKSYS, had to be used to have the new
DASD accessible. This means that a CP regen is required. As with the 1.2 system
once the new DASD is online it can be used to allocate mini disks space (just do
not use the first cylinder), or any other use.

Below is an explanation of what that fix was and it’s implications.

—————————————————— Start of insert————————————
——————-
I traced the cause of the DMKLNK108E message down to an flag setting in the
RBLOK field RDEVFLAG. When set to RDEVMOUT its considered not to be
ATTACHED/MOUNTED hence the message.

Further digging showed that adding my DASD to the SYSUSR macro and
regenning CP allowed my userid to logon correctly.

Given the above I did some more searching and found fixes that dealt with these
fields/values. This revealed fix HRC039DK which is not on the 1.2 VM/370 system
but is on the 1.3. This fix is attempted to add clarity and consistency to device
status as explained in HRC039DK MEMO.

So I would say its a pretty safe bet that the behaviour I had seen is not so must
of a bug but a correction to wooly handling of device status in the past. It does
mean that when using VM/370 beta 1.3 the use of the SYSUSR parameter in
DMKSYS is mandated, which I think is the purpose of HRC039DK. Users of the 1.3
beta who just move their directory entries over, as has worked in the past, and
expect the system to run the same as previous versions.

—————————————————end of insert —————————————
———————

Hope this is of use, at least it documents this behaviour for those moving to 1.3
and above from 1.2 systems.

Regards,
Martin.