Hello,

I'm seeing several issues.? I'm hoping to find solutions and learn at the same time.

1. I create a drive (file) using the dasdinit command, but dasdls isn't finding the VOLSER.
2. I'm trying to add to the Hercules configuration file three drives, but Hercules won't accept them with shadow files.
3. I can get VM to see the drives, but I can't get them attached to the system via DMKSYS.

I suspect these issues may be related, as one progresses from one to three, but I can't see the relationship (and none may exist).? The details are:

Issue One:

I can't get dasdinit to put a VOLSER on the drive.? I'm creating the drive (file) using the command dasdinit -a vm380-0.cckd 3380 BGM380

The output is:


I run the command "dasdls vm380-0.cckd" I get:


Issue Two:

In the configuration file, I'm using the entry:


Hercule fails to use the drive, giving the message:

HHC00469E 0:0380 CKD file disks/vm380-0.cckd: shadow files not supported for CKD dasd
HHC00007I Previous message from function 'ckd_dasd_init_handler' at ckddasd.c(474)
HHC01463E 0:0380 device initialization failed

When I remove the: ro sf=disks/shadows/vm380-0.shadow

I get:

HHC00414I 0:0380 CKD file disks/vm380-0.cckd: model 3380-A cyls 886 heads 15 tracks 13290 trklen 47616

Issue Three:

In VM on Maint, I'm seeing:


This is all good and well to this point.? I added DMKSYS the VOLSERS:? BGM380, BGM381, and BGM382 by adding them to DMKSYS (well, I thought):


I did a nucleus build, cp shutdown, and replied 6A1 in the Hercules console.

The problem is the drives 380-382 don't show as being attached to the system or owned by the system.? I'm seeing:


while VM14-0 through VM14-3 are system drives.

DASD 6D0 CP SYSTEM VM14-0 ? 001
DASD 6D1 CP SYSTEM VM14-1 ? 001
DASD 6D2 CP SYSTEM VM14-2 ? 001
DASD 6D3 CP SYSTEM VM14-3 ? 001

Thank you so very much,

Bertram Moshier
WB8ERT

I'm playing with porting SQLite to VM/370 CE CMS. It may not be possible - I have to solve a few issues around truncating files and committing data to disk. Both of those are outside the normal realm for CMS application code. SQLite attempts to make porting easy, by encapsulating the OS interface into a single module - the "Virtual File System". The VFS interface maps OK onto the CMS filesystem for almost all functions, but not all. I had similar issues porting a PC/Unix embedded database to VM/SP 5 CMS about 30 years ago, so it's familiar country, but the final solution wasn't my favorite and I'm trying to do something more general this time.

The did . It uses a Unix I/O model, so I assume he intended it to be used with the CMS Byte File System, since that's been available to VMers since the last century. So his VFS implementation isn't going to work for me.

Ross

Brian_Westerman wrote:

Hi Fish,

Send me your address (offline, not here)

No need. It's no secret. My physical mailing address is on my Contact web page:

*

and the next time the hard drives and NVMe or SSD drives
(if your motherboard can support NVMe) go on a good sale
I'll have some shipped to you.

I appreciate the offer, but my system is an older used Dell Precision T7500 manufactured in 2009, and I'm pretty sure it doesn't support NVMe or SSD, so don't bother.

(But as I said, I *do* appreciate the offer!)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Hi Fish,

Send me your address (offline, not here) and the next time the hard drives and NVMe or SSD drives (if your motherboard can support NVMe) go on a good sale I'll have some shipped to you.?

Brian

Brian_Westerman wrote:

Hi Fish,

The reason I use DASDCOPY64 is because I am then left with
an unchanged old BASE and shadow 1 that can be mix/matched
with later maintenance to get to just the level of maintenance
I want. I keep all of my old shadow files (every one of them)
in a separate set of directories kept by z/OS release and date
in the dir-name with the matching BASE. I also keep all of
the bases for almost all z/OS releases, so for instance I have
2.5 as originally released and then every quarterly RSU (as
the shadow file 1) up till current that I can apply to that base.
Then I have yearly bases, that start with the final quarterly
RSU of the previous year.

Hmmm... Okay, I think I see your strategy now. Cool! Even with the limit of 8 shadow file sets, you still are able to keep a restorable shadow file set snapshot history of *every* maintenance release (even if there are more than 8 of them over the years) by saving the corresponding base and its associated shadow file set #1 via dasdcopy64! Nice! That's a good strategy. I myself couldn't afford things that way though, due to my limited host disk space (limited budget; I'm POOR!). But yes, I can now see how, in your case, using dasdcopy64 to merge all shadow file sets back into the base (well, not the original base, but a NEW base) is actually a valid and good strategy. Well done! I'm proud of you. :)

For me it's not just a move forward type of thing, I also need
to (occasionally) move backwards.

Ah. I see. Truth be told, I too also need (and use) that ability. When chasing a bug, I need to be able to start my system in the exact same state each and every time. So I simply set my current shadow file set to read-only to cause a new shadow file set to be created, and before each test, I simply delete that shadow file set. It takes me back (reverts me) to the *exact* same original starting point each time. That's important when testing, as each time you run a test (to test your proposed bug fix), all of your dasds are necessarily changed/updated/modified. Each time you IPL your guest operating system, datasets are necessarily updated, so that if you run the same test again, your starting environment is ever so subtly different. You can't have that when chasing a bug. You want consistency. You want the *exact* same starting point each time. Thus I simply delete the current set of shadow files before each test, and voila! I'm right back the where I was before. Each test starts at the exact same point in time. All of my guest dasds are in the *exact* same state they were in when the previous test was performed. That is SO critically important when chasing a bug or testing a change, and using shadow files makes doing so trivially easy. I *love* shadow files! :)

<snip remainder>

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Hi Fish,

The reason I use DASDCOPY64 is because I am then left with an unchanged old BASE and shadow 1 that can be mix/matched with later maintenance to get to just the level of maintenance I want.? I keep all of my old shadow files (every one of them) in a separate set of directories kept by z/OS release and date in the dir-name with the matching BASE.? I also keep all of the bases for almost all z/OS releases, so for instance I have 2.5 as originally released and then every quarterly RSU (as the shadow file 1) up till current that I can apply to that base.? Then I have yearly bases, that start with the final quarterly RSU of the previous year.?

For me it's not just a move forward type of thing, I also need to (occasionally) move backwards.? We do that same thing on the z/16, from time to time we need to mirror the environment of a client site (maintenance wise).? Unfortunately the z/16 can't go back very far (z/OS release wise).? Some people might be at 2.5 (or 2.4 or 2.3, or 2.2 all the way back to OS/390).? If they were z/OS 2.5 RSU2212 with a couple hipers, so I can go back and re-ipl at RSU2212 on the z/16 and apply the hipers (I download but don't necessarily apply every hiper as they are released) they have and we can debug and (hopefully) fix their issue.? But if it's a release that the z/16 doesn't support then the "fix plan" becomes more difficult.? Usually it's to help a software vendor client, but sometimes it's IBM.? But, you are correct, most people won't have to do that, especially at home.? :)

I do it at home more as practice (and habit), but it does come in handy to be able to do things that can't be done otherwise.

Incidentally Amazon has the 8TB Seagate IronWolf for $120 right now, this morning there were 5 10tb ones for $150 each.? You need to be careful though because sometimes they are used, which isn't necessarily bad so long as you still get a 5 year warranty.?? I have all of the hard drives and NVMe drives that I am willing to use set up on the camelizer to tell me when they reach the price I'm willing to pay.? I only care about the warranty and I supposed who the seller it.? Amazon and Amazon Warehouse are okay because you get the warranty, and some "other" sellers also supply you with the warranty, but you have to be careful with them.?

For me, the hard drives are basically fodder, so if one were to break, I would exchange it for another if under warranty, and drop it in the recycle bin if not.? I've been very lucky in that I have only once received a bad 6TB drive (about 7 years ago) and it died after 15 months of use.? Since it was in the NAS, I just replaced it with a spare and sent it back for a replacement.? I received it from Seagate within a week or two.? I had to pay for shipping, but I sent it to them in a padded priority mail fixed price envelope for about $8, and they sent me one back in a nice padded shipping box.? Once I started using 10 and 20TB drives I have yet to get a bad one, but they do happen, and you need to try to be prepared. ?

Brian_Westerman wrote:

[...]

But, if you apply monthly or quarterly RSU maintenance,
then you will end up with a greater number of shadow files
over time. I'm not sure what the limit on shadow files
is now, but it was 8 when I set up my standard backup routine.
Obviously, if you apply maintenance and each maintenance
set is a separate Shadow file, you will reach the limit fairly
quickly.

Quite true, BUT... That would *only* occur if you never merged any of your shadow file sets. But again, why would you do that? Not merge your shadow file sets once you were confident everything was good?

For example: You have your base images, read-only, and your first set of shadow files (read-write) containing your customizations. Time passes, with shadow file set #1 (your ONLY shadow file set at the moment) accumulating all of your routine day-to-day activity.

Then IBM releases maintenance, which you want to apply to your system. So what do you do? Answer: after shutting your [Hercules] system down normally, you mark your shadow file set #1 READ-ONLY. Then when you bring up Hercules, shadow file set #2 is created. You apply your IBM maintenance. All maintenance gets written to shadow file set #2 (since it's the current read-write set).

You then test everything and after completing your testing, return back to your normal day-to-day routine.

Time passes some more, with shadow file set #2 (the one that has the maintenance applied) continues to accumulate your day-to-day activity.

Then IBM release *another* set of maintenance that you want to apply to your system. So what do you do?

Well, the first thing I would do is merge shadow file set #2 into shadow file set #1, since you've had an entire month or longer to verify it's good and your system is stable. With Hercules shutdown, you mark shadow file set #1 read-WRITE, and then bring Hercules up again. But before IPLing, you issue your "sf-*" command to merge shadow file set #2 into shadow file set #1. Once complete, shadow file set #2 no longer exists (because it's been merged into set #1). You then power off Hercules, and mark shadow file set #1 READ-ONLY again.

Then you bring Hercules up (which automatically creates a BRAND NEW ("empty" so to speak) shadow file set #2 again), IPL you system and proceed to apply the new maintenance just like you did before.

Lather, rinse, repeat.

For as long as desired.

Result: you will never have more than 2 sets of shadow files! Well below the maximum of 8.

So once again, there is NO NEED to *ever* merge your shadow file sets into your original base images. You original base images should remain UNMODIFIED. Your shadow files, over time, will be constantly changing, but who cares? Each time new maintenance is released (or whenever the frick you want to, really!), you either:

a) Save your current shadow file set by marking it read-only so that a new shadow file set is created.

or:

b) You merge your current shadow file set back into your previous shadow file set, and then continue normally from there.

Note that you will *eventually* need to do b) anyway once you've reached the maximum allowable number of shadow file sets (currently 8), but my point is, you can continue to run your Hercules system essentially forever, applying maintenance month after month after month *without* ever exceeding the maximum number of allowable shadow file sets, *AND* without ever having to merge *anything* into your base images (which I will maintain until the day I die should *NEVER* be modified from their original unmodified as-delivered state).

The "safest" (according to IBM) sequence to apply the RSU
maintenance to z/OS, and the one IBM likes, is to get the
hiper stuff on asap and apply the maintenance at the quarterly
RSU releases, which for 2024 will be (RSU2403, RSU2406 RSU2409
and RSU2412). So even if you were to just use that method,
you wouldn't get very far before you were at the limit.

WRONG. It just depends on your goal.

If your goal is to have each application of maintenance in its own separate shadow file set, then yes, you are obviously going to reach the Hercules limit very quickly. But why would you want to manage your shadow files that way? Why not merge your shadow file sets back into the previous set on routine intervals.

OR... do it your way (keep each new set of maintenance in its own set of shadow files), but merge the last set back into the previous set once the limit is reached? But again, why not merge ALL of your shadow file sets into their previous set, until you have only ONE shadow file set? Then once all sets have been merged back into set #1, mark it read-only again to auto-create set #2 and continue normally from there. (Then at some point merge set #2 back into set #1, etc. Lather, rinse, repeat.)

Methinks you guys are not fully grasping what shadow files ARE. They're like incremental backups.

I don't understand your confusion. Using shadow files seems rather simple and straightforward to me. But then maybe that's because I've been using them for so long.

It's not rocket science we're dealing with here.

Some people don't apply maintenance at all, and some simply load
the new levels that are released periodically, which is likely
the case for Fish,

Correct. I don't have access to maintenance. I receive a new release, get it installed and up and running and customized/configured the way I want it (almost exclusively it's just the networking), and then never f**k with it. I only use it to verify the changes we make to Hercules doesn't break anything. If z/OS IPLs fine and I can logon and do some simple things, I'm happy.

Others, like you, are actually USING z/OS in semi-production mode. Doing shit that z/OS system admins and advanced z/OS users/developers do. That's not me.

But... *neither* should have jack all to do with the way you manage your Hercules shadow files! Just as how you use your real Windows or Linux hosts should have anything to do with your routine daily and monthly system backups. To stand there and say "If you're a game player, you need to backup your system this way, but if you're a software developer or a lawyer or a doctor or a musician, etc, you need to backup your system this other way."

BULLSHIT. You backup your system the same way.

Same thing with shadow files. You manage them the same way.

so his method works for him.

And has been for many, MANY years now.

And the way I'm managing my shadow files *SHOULD* work identically for you or anyone else too.

You certainly don't HAVE to do it my way! Personally I don't give a rat's ass HOW the frick you or anyone else does it. I'm just explaining how *I'M* doing and *why* I'm doing it, and recommending and encouraging others to do it the same way too, based on my years of experience and expertise. It's up to each of you to decide for yourselves whether you want to take my advice or not. Whatever you decide is no skin off my nose.

It just doesn't work for me,

Because you're obviously misunderstanding the way I'm saying you should (IMHO) do it. That's probably my fault. I sometimes have trouble explaining things clearly and concisely. (Especially the concisely part! <g>) It's a personal failing of mine.

but then everyone does things differently so what works for me or
for Fish, might not work for you.

A truer truism has rarely been stated. :)

I have found that merging the shadow files down to just one shadow
is quite simple.

Right! So what's the problem then?

Merging into the base file is where you have to really worry and
I have had a couple times (my fault) where it failed. My solution
(which Fish probably won't like) is that when necessary (or yearly
at the longest) I merge to just the one shadow, and then using
DASDCOPY64 copy the Base and the single shadow and make a new base.

You're right: I don't like it. :(

My golden rule is to NEVER modify the base. EVER EVER EVER.

That gives me the new BASE that I want, plus leaves me with the
backup of the old base and shadow file(s).

Which wastes backup disk space and time doing the dasdcopy64, *AND* runs the risk of data corruption should something go wrong during the dasdcopy64 merge/consolidate.

With my way, neither is required and you *always* have a fully backed up CURRENT system with everything. Always.

(As long as you do daily/regular backups of your most current shadow file set of course, which, being shadow files, are usually very small, with backups typically only taking a few seconds up to a minute or three at most.)

To each their own. <shrug>

I also copy everything every day and my backups are not just
the Hercules data, but everything on my computer.

Ditto.

I have five 4TB NVMe drives (20TB total) and a 20TB HDD.

Lucky you. I have only one 4TB backup drive. But then I also have 2 other 4TB drives I used to make monthly clones of my primary backup drive too. So I guess technically that makes 12TB of backup space, with over a year's worth of backup history. I can restore my system to any state it was in on any day of the past year.


[...]

So, for me, space is not really an issue, but recovery is.

Ditto. But why waste the space if you don't need to?

If I could have more than 8 shadow files

Increasing the limit to an infinite number of shadow files has been on my list of things to do for the past almost 20 years now. Sadly, I never seem to find the time to work on it. Other more important things always seem to jump ahead of it. And besides, if you simply manage your shadow files a little differently, the current limit of 8 is actually quite sufficient IMO.

(I rarely go above 4),

Ditto again. :)

then I would/might change things a little, but it would probably
be less efficient to have more than 8 and that's likely why they
set that limit.

Quite right. The more shadow files you have, the slower your reads are, since each read needs to search the previous shadow file (possibly all the way down to the base image) if the track you want isn't in to the current shadow file. That's the way shadow files work. Just like incremental backups.

But given the peace of mind and ease of use, it's completely worth it IMO.

I'm not saying that you should go out and buy a bunch of hardware,
but based on the way I use Hercules, the way I do things works for me.

If it works for you and you're happy with doing it your way, then that's fine. I'm just explaining for the benefit of others the way *I* use shadow files and why I use them the way I do. Once a person grasps (groks) the concept of shadow files, they use them in whatever way works best for them too. As I said, it's no skin off my nose. I'm just offering what I believe to be is good advice backed up with (what I hope is!) sound reasoning and years of experience. Everyone is free to take it or leave it.

I'm constantly moving between RSU levels and sometimes before
certain hipers, and my way lets me move to just about any maintenance
level of any year back for several years. Most people don't
have a need to do that, but I do.

Everybody's situation and needs are different.

In my case, when the NVMe drives went on a super good sale,
(4TB Western Digital Black drives for right around $125 each)
so I bought a bunch, the same with the 20TB Seagate Ironwolf
Pro drives

Ooooo! Those are GOOD ones! I've heard about them. Top of the line.

(which were also cheap at about $150 each) and the NAS boxes
that ended up costing more than the DASD inside of them.

I'm jealous. :)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

I also use shadow files, but unlike Fish, I do (occasionally) merge them.? I usually do this once per year.? I think that Fish doesn't have the same issue that arises when you apply maintenance to the system, so keeping a single base at one level does make sense for him.? But, if you apply monthly or quarterly RSU maintenance, then you will end up with a greater number of shadow files over time.? I'm not sure what the limit on shadow files is now, but it was 8 when I set up my standard backup routine.? Obviously, if you apply maintenance and each maintenance set is a separate Shadow file, you will reach the limit fairly quickly.?

The "safest" (according to IBM) sequence to apply the RSU maintenance to z/OS, and the one IBM likes, is to get the hiper stuff on asap and apply the maintenance at the quarterly RSU releases, which for 2024 will be (RSU2403, RSU2406 RSU2409 and RSU2412).? So even if you were to just use that method, you wouldn't get very far before you were at the limit.?

Some people don't apply maintenance at all, and some simply load the new levels that are released periodically, which is likely the case for Fish, so his method works for him.? It just doesn't work for me, but then everyone does things differently so what works for me or for Fish, might not work for you.?

I have found that merging the shadow files down to just one shadow is quite simple.? Merging into the base file is where you have to really worry and I have had a couple times (my fault) where it failed.? My solution (which Fish? probably won't like) is that when necessary (or yearly at the longest) I merge to just the one shadow, and then using DASDCOPY64 copy the Base and the single shadow and make a new base.? That gives me the new BASE that I want, plus leaves me with the backup of the old base and shadow file(s).

I also copy everything every day and my backups are not just the Hercules data, but everything on my computer.? I have five 4TB NVMe drives (20TB total) and a 20TB HDD.? I don't use all of the space on the NVMe drives, they actually run at around a single TB (more or less) on each one, and I use a program called BVCKUP2 (very inexpensive and very good) to make very quick copies of everything to alternate NVMe drives.? NVMe to NVMe especially with BVCKUP2 which can be set to copy only the changed blocks within each file, and not the entire file, is extremely quick (a matter of seconds).? Then everything also gets copied to the 20TB HDD (in the background and only from the backup copies not the original data on the NVMe drives).? I also make daily copies of some drives with Acronis to the HDD in incremental format.? Weekly the HDD gets copied to my NAS (4 20TB drives).? I also take a weekly (full every 16 weeks) and incremental (every week) of the NVMe drives directly to the NAS.? I have a duplicate, though slightly smaller NAS at another location that is used to hold snapshot copies of my primary NAS. ??

So, for me, space is not really an issue, but recovery is.? If I could have more than 8 shadow files (I rarely go above 4), then I would/might change things a little, but it would probably be less efficient to have more than 8 and that's likely why they set that limit.

I'm not saying that you should go out and buy a bunch of hardware, but based on the way I use Hercules, the way I do things works for me.? I'm constantly moving between RSU levels and sometimes before certain hipers, and my way lets me move to just about any maintenance level of any year back for several years.? Most people don't have a need to do that, but I do.? In my case, when the NVMe drives went on a super good sale, (4TB Western Digital Black drives for right around $125 each) so I bought a bunch, the same with the 20TB Seagate Ironwolf Pro drives (which were also cheap at about $150 each) and the NAS boxes that ended up costing more than the DASD inside of them.?

Brian

[...]

In my scenario, if I wanted, I could mark my first set of shadow
files (set #1) read-write, and then merge my set #1 into my set #1,

That should of course be: "merge my set #2 into my set #1".

Ross Patterson wrote:

I'm considering merging my disks' shadow files into their
base files. Why?

Exactly my question.

Well, because ... I dunno, it seems like I don't need the
ability to undo literally everything I've ever done on my
VM/CE system.

"literally everything I've ever done" only applies if you only create a shadow file and then never create another one ever again. Which is fine I suppose.

Me? I create a new set of shadow files whenever I want to do *anything* I'm not sure of. Otherwise, I just continue running with the current set.

But one thing I personally *never* do is modify my original base images. My base images are always unmodified. They always remain as the original, virgin, as-originally-delivered/distributed uncustomized base images.

Whenever I install a new distribution of whatever, I create my base images (which is usually to simply unzip the distribution volumes and then immediately convert them to CCKD64), and then immediately mark them as READ-ONLY.

On the first IPL, the first set of shadow files gets automatically created. I then begin to slowly customize my installation to set it up the way I want it. Once I'm happy with the way things are, I then mark THAT set of shadow files as READ-ONLY as well (which of course is done only after the system has been shutdown and Hercules powered off).

On the next IPL, another new set of shadow files gets automatically created (set #2), and from then on, no more shadow files are created. I have the original base images (marked read-only), shadow file set #1 (with my customizations, marked read-only), and the current set of shadow files (still read-write) where all writes go.

In this way I only have to do ONE backup of the original distribution volume and never again, since they will never change. Same with my first shadow file set too (set #1). They too will never change, so I only have to back them up once too, and never again.

The only files I ever need to backup on a daily basis, is shadow file set #2, where all updates occur. The backup of this shadow files set #2 (as well as set #1 too, but that's unimportant at this point) is always quite small. Usually only a few K or a few MB at most. This makes backups quite fast and convenient. I don't need to be constantly backing up my entire system, since the base images have *already* been backed up once, and have never been changed. They've never been modified. And base images are usually many, many GB in size (whereas shadow files are typically very small).

But if you merge your shadow files into your base image, then you need to do another multi-GB backup of everything again! If you never modify your base images, you don't ever need to do that. You back them up once and never again.

And if you ever need to restore your system from a disaster, you only need to restore your two sets of shadow files, because they're all based on the original unmodified set of base images (as well as the previous set of shadow files too of course).

Now maybe you don't mind wasting time and disk space and are quite happy doing things in the most inefficient way possible, but not me. I prefer to think things through and do things in the most disk-space efficient and time efficient manner. But then maybe that's just me. (No slight or disrespect intended by the previous by the way. Just commenting on the way I'm seeing things.)

BUT ... the Hercules doc (at
390.github.io/html/cckddasd.html#utilities) says "Note: It is
not advisable to merge shadow files back into base images. When
merging shadow files, it is only recommended to merge one set
of shadow files back into the previous set of shadow files

Correct. In my scenario, if I wanted, I could mark my first set of shadow files (set #1) read-write, and then merge my set #1 into my set #1, resulting in having only one set of shadow files again. This might be done as you make changes to your system and wish to "save" those changes permanently. (It also prevents the number of shadow file sets from growing too large too, since you can only have a maximum of 8 sets of shadow files.)

But as I said (and as stated in the documentation), we discourage modifying base dasd images for simple logical reasons.

Can certainly CAN (MAY) merge your shadow files back into your base if you want to. But why in the world would you want to do that? Doing so forces you to do a FULL SYSTEM BACKUP all over again, which wastes time and disk space. Your original backup of your base images immediately become obsolete as soon as you modify your current set of base images. It's much faster and easier to just backup your *current* set of shadow files (set #2 only, since set #1, just like your base images, are read-only and thus are never modified, so you only need to back them up *once* and never again).

"When you merge a shadow file back into the base image, you might
see some error/warning message being issued as a result, which
should be considered an unpreventable side effect of such a merge,
and are completely benign. No file damage has actually occurred."

Correct.

Naturally, I get a little concerned when the authors say "Don't use
this tool we built you, or at least not if you don't want your data
destroyed."

Your data will NOT be destroyed. As the documentation states, some error and/or warning messages might be issued, but the merge *will* be successful.

As long as your system doesn't crash before the merge can complete of course. (i.e. power failure or hardware failure, etc.)

Except in the hardware failure or power failure case, data corruption, when it occurs, *always* occurs when the data is being modified (i.e. updated / written to), but never when it's just being read. So why in the world would you want to risk modifying/re-writing known good data if you don't have to? Create you installation default base images, mark then read-only, and back them up. ONCE. And never again. And just use shadow files from then on. MUCH less risky. MUCH faster backups. MUCH less backup disk space consumed.

I mean, it's a no-brainer!

But I have a hard time understanding how to reconcile the first
sentence that says "Hey! Don't do that!", with the last one
that says "It works just fine!".

Do you now? After reading what I've written above, do you now understand why those two statement are not contradictory at all?

So, what say ye? Merge, or not?

Me? I personally would not *ever* merge updates into my original base image. I'd leave all modifications remain in shadow files for the reasons I've already explained.

You do what you want, Ross. It's your system. Just like when you see a doctor who gives you sound medical advice, it's up to you whether you want to heed it or not.

Good Luck

(if there's anything I've written that's unclear or if you have any questions/concerns about any of it, let me know and I'll try to address them. Thanks.)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

开云体育

Ross,

I think you deserve a huge thank you for your tenacity in tracking down this problem. It was a really sticky one.

Despit it being exonerated I still think the GCC log() could do with a clean-up. I have been expecting the bug to be in there. I seem to remember it was the last bit of math.h that I wrote and my usual go-to texts were not helpful, so it was l really bodgeing and cludging as I went along. Perhaps time to borrow the code from FORTRAN G or H which is effectively public domain.

Dave? - G4UGM

p.s. This article on traditional bodging didn?t help either

开云体育

I’m so glad you asked this question and I look forward to reading the responses. ?I’m not sure why I shouldn’t merge to the base files either, I have the original base files anyway if I need to go back. ?Besides, the daily backups I have would also give me a way to restore my updates should I need it.

Fish wrote:

Doug Wegscheid wrote:

Fish wrote:

[...]

I guess maybe dasdinit should be changed to also create an
"empty VTOC" too? (i.e. a valid Format 4 record indicating
zero VTOC entries?)

Can dasdls be changed to print the volser if there is a VOL1
record, but no DSCB 4? I don't understand why the lack of a
DSCB 4 would prevent detection of the VOLSER?

Excellent point, Doug! I'm embarrassed I hadn't thought of that myself. As
I said, I must be losing my edge.

I'll look into it. It should hopefully be a simple change. Stay tuned.

Fix committed to develop branch and will appear in next release.

For those who want the fix now, you'll of course have to rebuild the develop branch of Hercules for yourself.

Thanks again Doug for pointing out the obvious! :)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Doug Wegscheid wrote:

Fish wrote:

[...]

I guess maybe dasdinit should be changed to also create an
"empty VTOC" too? (i.e. a valid Format 4 record indicating
zero VTOC entries?)

Can dasdls be changed to print the volser if there is a VOL1
record, but no DSCB 4? I don't understand why the lack of a
DSCB 4 would prevent detection of the VOLSER?

Excellent point, Doug! I'm embarrassed I hadn't thought of that myself. As I said, I must be losing my edge.

I'll look into it. It should hopefully be a simple change. Stay tuned.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

On Wed, May 1, 2024 at 10:58 AM, Jean-Pierre Cabanié wrote:

Formerly, I was the head of the applications development team in a French research lab (now you have some explanations about my poor English). This may explain (if not excuse for many people) that I'm not that familiar with the VM system internals. I daily struggle trying to have a VM-CE or a VM-ESA just operating and I use your discussions (you ?systems? guys?) to try to discover how to have a working DIRMAINT under VM-ESA or just how to add a physical disk to a VM-CE machine in order to re-implant the backups I made years ago of my own userid under a real VM-ESA operating on a real 3090.

Don't feel stupid, and don't stop asking questions. Part of the reason we are all here is to learn, from wherever we started. Some of these people can still run circles around the rest of us. Some of us walk, into doors, walls, over cliffs. The fantastic thing is we get to learn from our mistakes, and the mainframe OS can be copied over and started from fresh in minutes, with no one else the wiser.

If you don't understand the reply, ask about what you don't understand. We can forget that people don't know that a 3278 is a terminal plugged into a mainframe, via 'magic', or that a special file, USER DIRECT, on a userid, such as MAINT, contains what is needed to manage users on the system.

Finally, most of us have started out where you are, at the beginning, asking questions, listening to the elders speak in strange tongues and spend many hours reading manuals.

?... Mark S.

开云体育

-- 

闯π谤

On Tue, Apr 30, 2024 at 11:52 AM, Fish Fish wrote:

I guess maybe dasdinit should be changed to also create an "empty VTOC" too? (i.e. a valid Format 4 record indicating zero VTOC entries?)

Can dasdls be changed to print the volser if there is a VOL1 record, but no DSCB 4? I don't understand why the lack of a DSCB 4 would prevent detection of the VOLSER?