Re: Ten Questions to ask a Prospective z/VM Systems Programmer
Do you follow the IBMVM Discussion List? (In which case, if the answer's, "Yes" you might reasonably expect them to have revised and already know the answers to the other nine. :-) ) A couple of, "matters arising" that're otherwise apropos of nothing ... Do people who survive on a diet of pizza and coffee ever LIVE to see 80? What is a, "normal" personality profile for a Systems Programmer?
Re: something with tn3270 and ssl
If you specify the HOLD option on your LOGOFF / DISC command: LOGOFF HOLD -- or -- DISC HOLD do the symptoms change at all? To quote from the HELP ... HOld causes the non-SNA TTY display terminal telecommunication connection to remain in effect after your session is disconnected. If you specify the HOLD option from a logical device, you disconnect from the logical device without losing the connection between the logical device and the system.
Re: Shared *-STAT not available
and ... purely becasue I'm paranoid ... IPL 190 CLEAR PARM SAVESYS CMS Regards jeff
Re: CMS Programming: How to sort files entries retrieved by DMSGETDF
If I wanted a completely self-contained program (no calls to PIPE, Rexx, etc) then I think I'd be tempted to code a sort routine into the program. After all - the entire, "file" to be sorted is in-store, it's not going t o be very large (even a rather inefficient bubble sort should be able to cope with up to 10K entries without causing the CPU to break into a sweat - and how many typical 191's contain even 1K files?) and doing it myself would give me complete control over the final sequence. Gosh - how many years is it since I last coded a sort routine? (JPH's fault - nowadays it's hard for me to imagine developing a capability that is to run in a VM/CMS environment that wouldn't involve PIPE at some poin t in the proceedings.) Regards Jeff Gribbin
Re: how to wait for dfsmsrm command
I have no direct experience of the specific device in question, but would a slow poll on a CP REWIND command do the trick? Say something like ... Do 10 Mounted = 1 "CP REWIND 181" If Rc == 0 then Leave Mounted = 0 "CP SLEEP 1 MIN" End If \ Mounted then Do <<< Timeout Logic >>> End One of my earliest usermods was to make CP REWIND give a non-zero return- code on REWIND NOT PERFORMED as it was (and probably still is) the only, "easy" command that gives control back regardless of whether or not the device is ready. (TAPE REW waits for the device to come ready before returning control.) Regards Jeff Gribbin
Re: Moving Spool
Hello Richard, If a Q ALLOC shows the SPOOL (DUMP) areas on the pack as being empty, and there's no other data on the pack that should be preserved then, provided the new pack is format/allocated in the same way as the old pack, I see n o requirement to copy the contents. However, given your, "standalone" environment, DDRing it would be equally effective and removes the need to do the format/allocate - so, overall, I'd suggest is unlikely to take much longer and leaves you with a simpler process to execute because there will be no exceptions to handle. Regards Jeff Gribbin
Good Citizenship Opportunity
It's been a while but, if I may, I think it's time to repeat my perennial plea on behalf of those who, like me, have good reasons to access this list in, "Plain Daily Digest Mode". When possible, could you PLEASE use Plain Text for your messages and ESPECIALLY PLEASE, when possible, avoid HTML. Daily Digest Mode displays all the HTML source and, currently, the, "junk" substantially overwhelms the, "content" when one is reading a digest (I would estimate about 80% junk in every digest received). Secondary to this plea for Plain Text, but also significant; it would als o be appreciated if you could consciously consider whether or not it is strictly necessary to re-send the original message when replying. Sometimes it's obviously of benefit but at other times it's, "just more clutter" and communication is actually enhanced by the deletion of the original from the reply. As I usually do when it's time for me to make this request, I'd like to emphasise that I'm not trying to discourage anybody from posting - if all you have is HTML, and all your replies are required to contain the original messages, then, please, fire away! However, if you DO have any control over this and are willing to exercise that control, your consideration for others will be appreciated. Regards Jeff
Re: Controlling MONWRITE and the size of its 191 disk
Regarding the, "problem" of perhaps wishing to only collect a subset of the monitor records for, "MONWRITE" / post-processing activities while still needing a fuller set of records for realtime monitoring, it is really a trivial exercise to write a PIPE that collects MONITOR records ( a la MONWRITE) and, of course, it would be equally trivial to code a filter into that pipe to drop the records that were only of, "real time" interes t. While I completely understand that new folks on the block may have other priorities I'm always bemused when I see folk struggling with the vanilla data collection mechanisms for accounting, monitoring and the such when it's so easy use PIPE to roll a customised collector that fits your exact needs. (Nowadays, the vanilla tools are, "sufficient unto my needs" - but this has not always been the case and, of course, Melinda's Plumbing Papers contain discussion regarding the collection of accounting data - most of which reads straight across into the monitor data collection context.) Jeff
Re: Z/VM 5.3 and VTAM and GCS
Jim,
Check out SC24-6098-02 (z/VM Group Control System) Appendix A (Tailoring
and Building the GCS Nucleus) - subsection headed, "Creating a New GCS
Nucleus Build List". Items 7 and 8 at the bottom of page 544 through to
the top of Page 547) are what you need.
It's terse to the point of incomprehensibility unless you have prior
experience of nucleus addressing in a VM context (something which,
nowadays, fewer and fewer people have need of) but this is definitely
your, "official reference point".
Essentially, what you need to do is to widen the gaps between GCALP and
GCTZET (to expand Low Common Storage), and/or between GCTBHC and GCTEHC
(to expand High Common Storage) by changing / replacing the SLC ("Set
Location Counter") files referenced by the load list.
It's these, "gaps" which define the amount of Low/High Common Storage
("CSA" in z/OS parlance) available to a particular GCS group and it's thi
s
Common Storage which is used by VTAM (and any other app which needs to
share storage between separate tasks running in the group). As you're
carrying forward an existing update I'll assume that you can work out how
much increase you need by referring back to your previous system but, if
not, then ask again and maybe somebody a bit more current than I am on
VTAM will be able to offer some pointers.
The precise mechanics of WHAT to do are (IMV) fairly well-described in th
e
manual (albeit without any real explanation as to WHY) but if you want to
explore the background to this further - or have other questions - then
please say so and I'll try (no doubt along with others) to expand on the
above and clarify what's going on.
Don't forget to put in your notes that the GCS NSS definitions (DEFNSS
stuff) need to be reviewed / adjusted to match with whatever locations ar
e
used by the loadlist or you'll end up building a new nucleus in storage
and then saving the wrong stuff into the NSS - a practice that can be the
source of some serious head-scratching until the penny (dime?) drops ...
Regards
Jeff Gribbin
Re: MAINTENANCE
Hi Anne, Unless you discover a bug in CP (HIGHLY unlikely) then nothing that you d o in a Class G virtual machine can impact the first-level system (other tha n maybe in terms of excessive resource consumption if your system is , "inappropriately" tuned ). Maybe it's the, "do it all again on first level" that's worrying you ... Well, I tend not to, "do it all again" because I only keep the maintenance materials on second-level - what I do for first-level is to identify the RESULTS of the maintenance and then copy just those parts that a running system requires, "up" to first level. I do this, "by hand" and set things up on first-level in a very manual and (relatively) labour-intensive way. If I don't use any automatic procedures then it's much harder to be, "surprised" because the quantum value of each step is sufficiently small for me to be usually be able to fully grasp its impact before I tak e it - if I manually enter ten commands rather than run an EXEC containing those ten commands then I have time to think between each micro-step and confirm to myself that I'm still comfortable with what I'm about to do. The downside is that you have to dig around a bit and discover what is truly, "The tip of the iceberg" that is actually NEEDED to run the system / subsystems and learn how to migrate those essentials to first- level. You have to develop skills with some of the elemental commands (such as, say, DEFNSS), but the payback is that you end up with a far greater awareness of the detail of what's going on in your system which then spins off into better problem diagnosis and analysis skills and better ways of ensuring that maintenance is non-disruptive. If that seems like, "all too much" and you DO want to simply, "do it all again" then I suggest investing effort in replicating as complete a model as you can of your first-level environment in your second-level system. Then, when you, "do it second-level" you can look for and learning how to deal with any unexpected side-effects that might arise (such as TCPIP suddenly going off the air). The other thing of course, which I'm SURE I don't really need to tell you , is to take copious notes - document exactly what you did and what happene d as a result - including all those things that you thought at first happened but then it turned out that they didn't, plus all those things that you didn't notice had happened and only discovered afterwards. Hmm - I'm preaching again - does any of that help or am I off-target? (If yes, please rephrase the question and I - plus many others, I'm sure - will take another shot at it.) Regards Jeff Gribbin
Re: 2007 Order of the Knights of VM
The certificate makes a great background for your PC's desktop (I've been using mine since about 30 minutes after I first discovered scanners). The resolution's improved a bit over the years as scanner technology has move d forward. :-) Congratulations and Welcome! Sir Jeff the Builder of Bridges
Re: Guest in 31 or 64 bit?
If you have TRACK installed, that'll answer the question on an ad-hoc basis without any further programming effort on your part. Otherwise, if it were me and I were looking for a reliable, "programmable" interface I reckon I'd be starting to think about writing an extension to QUERY ...
Re: Multiple Logical Operator Consoles... how?
Hello Fred, I hope that you (eventually) find this useful, but I'm going to unhelpfully start by suggesting that you take a step back and delete from your mind the idea that VM has a, "console". The VM paradigm is fundamentally different to the OS paradigm - in VM, an y appropriately privileged userid can issue any CP command from any location. Period. The idea of a, "system console" is not part of the mode l. Asynchronous system status messages are directed to the VIRTUAL console o f the currently-logged on userid that is designated as SYSTEM OPERATOR. If there is no logged-on and currently-designated SYSTEM OPERATOR then the asynchronous messages are simply discarded. The SYSTEM OPERATOR may be logged-on-connected or it may be be logged-on-disconnected - CP just doesn't care. So ... I'll now attempt to redefine what I think is the problem that you're trying to solve - it'll be helpful to the list if you would confir m or refine this definition so that we can then suggest pragmatic solutions . I think that your, "problem" is that you wish to display all (or some subset of) the asynchronous system status messages on several real displa y devices. Possibly you also wish to allow provileged commands that alter the system status to be entered from several real display devices. Both of these capabilities are quite straightforward to implement in a basic form using nothing other than the essential VM capabilities - the challenges come once one starts imposing all those, "real life" constraints such as subsetting of function, logging, authorisation, readability, usability, automation of routine events and the such. So - to summarise - in the VM paradigm there is a single, "touchpoint" (SYSTEM OPERATOR) through which all asynchronous system status messages are channelled. This touchpoint is programmable and the end-capability is therefore limited only by our imaginations and our ability to develop suitable code. As you have suggested, much commercial code is available that makes use of this touchpoint, but at a monetary cost. However, all the interfaces are documented and there is nothing to stop you from developing your own code that uses the touchpoint. (Note well that PROP i s NOT the touchpoint - it's an example of a user of the touchpoint.) Hope that helps - please publish a bit more background on what you're trying to achieve and then we can better advise you regarding what's already, "out there" and what you might have to, "roll yourself". Regards, Jeff Gribbin
Re: Best procedure to migrate dedicated VSE volume to VM minidisk
I have had lots of experience with DDR - not recently, but I'm pretty confident that this should still be accurate. I've no experience pre-3330 and the following is written in a 3390 contex t. Assuming you're runnning DDR in a virtual machine and moving from and to the same VIRTUAL cylinders you'll NEVER need to use REORDER. The actual physical cylinders occupied by the minidisks are irrelevant - it's the (virtual) cylinder values, "seen" by DDR that are significant. Therefore, assuming you have a virtual machine with read access to your source disk at (say) , and write access to your (3338 cylinder) targe t disk at (say) , some variation (e.g.you supply the disk labels) on th e theme of: PROMPTS OFF IN 3390 OUT 3390 COPY 0 3337 will do what you want. If you were running standalone to real disks then you could achieve the same effect using REORDER, thus; ... ... ... COPY 0 3337 REORDER 1 but personally I'd have to be short of options to choose this method! Regards Jeff (writing as me, not an EDS employee) Gribbin
Re: Historical curiousity question.
Chris Langford has already stated the fundamental answer to the original question - I'll re-state it for emphasis before we fly off on too many tangents and it gets lost: To allow complete virtualisation of minidisks of any size up to and including full-pack. Virtualising a full-pack minidisk makes it intrinsically impossible to save hypervisor-related information on the physical pack that's being virtualised - there's nowhere to put it! Remember - one is virtualising HARDWARE - so there's no scope for, "agreement" with the (software running in the) guests to not use par t of the pack - at best this would lead to a less-than-complete virtualisation. CP-OWNED volumes are a different kettle of fish - they are specifically reserved for use by (and ownership of) CP itself - not guests. The fact that CP is generous enough to allow (guest) minidisk allocation of the parts that it does not wish to use itself (the, "I'm not using these cylinders" generally being flagged as, 'PERM' in the Allocation Table) - and even allow minidisk mapping of the parts that it DOES use - is a bonus. (This bonus is one that definitely fits in with VM's philosophy of only expecting grownups to play at system level - gun-bullet-foot - but, if you survive, a great way to learn!) Jeff (These opinions are entirely personal) Gribbin
Re: Issuing HX from Rexx
"An Assembler Program That ABENDs" ... A little convoluted, and it would need a bit of wrap-round code to generalise it and do things like verify load/start address, but it seems that one could write an EXEC that effectively, "HX"d based on the following ... load dmsbtp DMSLIO201W The following names are undefined: BATEXIT1 BATEXIT2 Ready(4); T=0.01/0.01 12:41:03 st s14002 Store complete. Ready; T=0.01/0.01 12:41:19 start DMSLIO740I Execution begins... DMSABE141T Operation exception occurred at 0006 in routine USER PGM CMS (I really should get out more) Jeff
Re: PSI story
With a small amount of trepidation (but inviting stomping from anybody wh o feels that I'm off-base here) can I remind folk that, on IBM mainframe hardware, MIPS aren't the whole story. There's channels too - and in an I/O-related situation their power needs to be ADDED to the CPU power to come up with a realistic, "comparative MIPS" figure. It's a very long time since I saw anything that indicated how much MIPpag e is offloaded into the channels by a typical, "mainframe" workload but please remember that, unless you understand how channels are implemented when comparing two different solutions, you can quickly mislead yourself regarding the genuine value of the, "MIPS" comparison. (I have a similar problem regarding, "channel bandwidth" - each individua l channel on a mainframe might be, "slow" but potentially I can have severa l hundred running in parallel - in the right circumstances doesn't this giv e me greater capacity to work with than a single but much faster I/O portal ? Do I want a firehose or do I want the Mississippi? As a man to whom I would happily defer when it comes to performance issues has occasionally been heard to comment, I think, "It depends ...") Regards Jeff Gribbin (Speaking only for himself.)
Re: z/VM 5.3
Ahah! Guess I just got lucky then! :-) Looks like several nice features in there that I'm unlikely to ever get5 to use in anger. Seen a GA date yet?
z/VM 5.3
Stumbled across this while lookig for TCP/IP Manuals. I don't recall
seeing any discussion on the topic - did I miss it?
http://www.vm.ibm.com/pubs/hcsf8b20.pdf
The really weird part was that I was looking in the TCP/IP Manuals to fin
d
out if there was a recommended way of doing a SET RESERVE on MPROUTE ...
and what do I find in here ... ? ...
Enhanced Guest Configuration
z/VM V5.3 helps improve the guest LOGON process by providing a new COMMAN
D
directory statement in a virtual machine definition or profile to
configure the virtual machine. Any form of a CP command may be invoked
using this capability, including privileged class commands (such as SET
RESERVED), on behalf of the virtual machine, eliminating the need to
provide some other method to configure it.
Spooky ...
(Alas, they forgot to spell, "privileged" VM-style with an extra, "d"
("priviledged") - the curse of the spellchecker strikes again. )
Regards
Jeff
Re: Question re: Hercules
Alan / David / Adam, Thanks for your responses - it would seem that my understanding of the rules is not at odds with yours and that such a strategy is at least acceptable from a legal / contractural standpoint. Support of old DASD geometries was my specific thought - but I love the idea of, "doing" a 64-bit system under a 31-bit system via Hercules - hig h on cough-syrup indeed! Your responses leave me with the comfortable feeling that, should the nee d ever arise, I do at least have some kind of, "Plan B" to entertain. Regards Jeff
Re: Question re: Hercules
> "NO you can not run VM - any version - under > Hercules". Now, this is one of those, "But why would you want to do this?" questions , but howabout running z/VM in a Hercules that was itself running under Linux in a virtual machine that was being delivered using the same z/VM a s was running, "down there" - and is, of course, properly and fully license d. Not entirely academic - some of the devices that Hercules can emulate are pretty hard to find nowadays and if one happened to have an application that depended on one of these devices ... (I would, of course, not expect such a configuration to be SUPPORTED but ... is it legal?) Regards Jeff
Re: Saving a backup copy of NSSs with no tape drive
To save into CMS files, somebody would have to teach CP how to WRITE CMS
files - MUCH more challenging than its current ability to ("simply") read
them. (SAVESYS needs to be a CP function - just because most SAVESYS
commands are executed within CMS doesn't mean that we can simply throw
away the capability to SAVESYS any image.)
SAVESYS onto a single SPOOL volume - yes, very nice, but to what end?
Being able to DDR restore that volume for recovery? Yes, quite reasonable
.
Being able to avoid loss of a SDF if a single SPOOL volume fails?
Reasonable, but long odds and probably of minor consideration alongside
the other problems you'll be mitigating against to cover that scenario.
Missing SDF's at IPL time? This problem is already solved by V/SEG -
AUTOVSEG (with an IPL 190 in its directory entry) already scans for
missing SDF's and replaces them - and even comes with instructions on how
to make AUTOLOG1 wait until the restores are complete before proceeding.
(It's fun at a DR to do a CLEAN start and watch all those SDF's
automagically appear at IPL time.)
So far, I haven't seen a single goal expressed which hasn't already been
solved by V/SEG so, once again I ask the question - what business reason
can we show IBM that would make it worthwhile investing time money and
effort in providing a second solution to a problem that's already been
solved? I'm not trying to suggest that a more modern set of solutions
wouldn't be attractive (V/SEG is seriously showing its age in some places
and has a certain, "clunkiness" about it which makes it kind-of endearing
)
and I'd love to see CA investing some serious manpower in the product (I
still suspect they aren't really aware of what a gem they acquired here)
-
but I just can't see how it'd make commercial sense for IBM to develop a
rival product unless it solves some real operational problem that's not
already been solved by V/SEG. So far, (unless I've missed it) nobody's
come up with one. (Folk have suggested alternative METHODS, but nobody's
yet pointed out a significant PROBLEM that's outside of V/SEG's scope.)
Regards
Jeff
Re: Saving a backup copy of NSSs with no tape drive
To protect oneself from rapid depletion of backups given a, "Post me when the SDF changes" situation and a beserk SDF-generator one simply needs to apply a minimum age on any backup-to-be-deleted. Couple that with a maximum-versions-to be-retained mechanism plus a notify-when-backup- disallowed-due-to-age-of-oldest-version process and (I think) all bases would be covered. (Of course, the minidisk where the backups are held is itself backed up on a cyclic basis to meet the need to recover a VERY OLD backup. Make minimum age for deletion 1 day and backup the disk daily and nothing will ever be, "lost accidentally".) I've never had reason to look closely at this part of V/SEG but I'd be surprised if it's not do-able by any user of the product who's also a sem i- competent Rexx coder in < 1 day and possibly do-able in exits (I'll leave Phil to provide a considered opinion ). Like others, I do wonder if the existence of a well-respected product tha t already does the job puts the damper on any further commercial developmen t of this capability inside IBM. Why reinvent the wheel where there are so many other wheels crying out to be invented! Regards Jeff Gribbin
Re: VM directory entry for shared DASD
Unsurprisingly, it looks as if I need to clarify a little ... Tom's not happy with, "assuming" R/R support for Reloc 0 Minidisks. My take here is that CP is not unilaterally adding any R/R activity - if the disk at Reloc 0 is a VSE minidisk and VSE doesn't issue any R/R then CP won't either - but if VSE DOES, "feel the need" then the R/R will be honoured by CP and protection from other systems running in other images will be provided - just as it would be in the, "Real World". This being the case, I don't see how with R/R propagation at the, "real" level we're significantly worse off than we are today - if VSE doesn't do it then CP doesn't do it - if VSE DOES do it then it gets the protection it's asking for instead of a weak subset of what it's expecting. There IS a new impac t (in terms of responsiveness) for users of other minidisks that share the real volume - but I would far rather manage the impact of coping with the consequences of, "safe" behaviour than manage the impact of coping with the consequences of a data corruption caused by CP's failure to fully honour a request from a guest asking for short-term exclusive use of a minidisk. (I contend that the CPU overhead of checking for the need to drive R/R support is not worthy of consideration - we are talking a few tens of instructions increase in the normal pathlength at most and - to my mind - the benefit of consistent behaviour far outweighs the cost of these few instructions.) Richard's appears to be unhappy with me suggesting that XLINK has a part to play here. I think that Rob's response should have settled these concerns but, just to make sure, a reminder that XLINK extends the protection against, "unintentional" multi-write access that one gets on a single system to cover multiple systems sharing a single real volume. It does this via a, "Compare-and-Swap" mechanism on a cylinder-map that resides on the real volume and it requires no additional hardware or (onc e set up) support process. Again, as it's intrinsically dangerous to have multiple CP images sharing minidisks on a real volume without the protection of XLINK, and XLINK is part of the base system, why on Earth would anyone wish to operate a production system without it? That being the case, it seems natural to me to deliver real R/R in support of any virtual R/R issued by a guest to any minidisk with a, "V" in the MDISK statement (or starts at Cylinder 0) that's on a real volume under the control of XLINK. In the vast majority of cases the non-reloc-0 minidisks will be CMS minidisks and (because CMS doesn't use R/R) there will not be any reason to code the, "V" anyway - but having the support in CP gives u s the CAPABILITY (which we don't currently have) should we wish to make use of it for - say - a VSE LOCKFILE residence minidisk. (At least nobody's yet taking me to task for suggesting that volumes unde r XLINK control should default to SHARED when ATTACHED to SYSTEM! ) Hopefully I've been able to make my points somewhat more clearly this tim e around. Tom and Richard - through your comments, thanks for giving me the opportunity to do so. Regards Jeff
Re: VM directory entry for shared DASD
Well Alan, as you've, "Opened the floor for discussion" - here's my two penn'orth on how I think it SHOULD work. I think we're all pretty-much agreed on Virtual R/R support within a single VM image, it's when to issue a REAL R/R that's the sticking-point. I would contend that a REAL R/R should be issued whenever the virtual R/R is honoured on ANY minidisk associated with a real volume (that supports real R/R) that's under control of cross-system link (aka XLINK) or whenever the subject minidisk begins on real cylinder zero. I would like to retain the "V" appendage to explicitly tell CP which minidisks are subject to virtual R/R support because this would protect m e from, "denial of service" behaviour based on someone realising that their CMS minidisk is on a cross-system-linked disk and that they can therefore mess things up by issuing a RESERVE CCW. However, this is unlikely enough that I'd be willing to be persuaded that CP should simply honour all R/R activity on all minidisks under the scheme outlined above. (Maybe relocat e- zero should imply, "V" but it needs to be explicitly coded on non-relocat e zero?) While I was at it, I would also extend the automatic assignment of SHARED status to any real volume that's put under XLINK control at the time that it's ATTACHED to SYSTEM, with (of course) the option of using the appropriate SET command to change this to cater for, "unusual" circumstances. I find the current mechanisms for establishing SHARED status on real packs tiresome - and it'd be so natural to assume shared for XLINK packs. OK, let's see what others think :-) Regards Jeff Gribbin
S/N Ratio - A Suggestion ...
Folks, A suggestion I'd like to make on behalf of the Digest Readers to help maintain the Signal-to-Noise ration on the list as high as conveniently possible ... When you're replying via email to a post and quoting the original message , if possible, could you please review the quoted material and prune out an y noise - in particular any now-redundant / duplicate lengthy legal disclaimers attached to the quoted material. (I'm even tempted to suggest getting in the habit of defaulting to NOT quoting original message as an appendage - but that's maybe a bit TOO radical for some ... ) If you can then I think that it'd help a little to avoid my problem of occasionally missing a, "nugget" because I was, "scrolling dross" and wen t a little too far. I'm not asking anyone to, "Do the impossible" - we all have to live with Company Rules on these things - just, "if you can" ... :-) With thanks in anticipation, Jeff Gribbin
Re: z/VM paging problem
Somebody please pass me my hat - it's lunchtime. I'm astonished and delighted.
Re: z/VM paging problem
Mmmm - after I hit, 'submit' I thought, "What's wrong with adding some ne w stuff and just draining the old stuff." (Never say, "Oops" after hitting, "Submit" :sigh.)
Re: z/VM paging problem
Hello Alan, Seriously, what in your opinion are the odds that a problem with a paging volume on a running system that's having NO OTHER paging problems could produce the symptoms of ONLY and ALWAYS failing on IPL vdev? Replacing paging volumes might be simple and easy but -given the symptoms as described- I see it as being so incredibly unlikely to resolve the problem that even the slight effort involved is unjustified without something else to corroborate the, "bad pack" hypothesis. Finding out if IPL CLEAR works and checking with Support for known problems are both (in my view) even simpler and easier and even negative answers will at least move Ed's understanding forward. Rob's TRSOURCE suggestion also looks like effort that one can expect to bear some fruit even if, again, it's of a negative nature. I'd be nervous about IPLing without understanding the problem - if for no other reason than potentially destroying the evidence without ever identifying the cause. (This is, of course, Ed's call - does he want to identify the problem or is he happy for it to just, "go away" - if the latter and it's not too disruptive to his community then maybe an IPL is justified ...) Regards Jeff
Re: z/VM paging problem
Rob, If Ed can confirm whether or not IPL vdev CLEAR fails that should reduce the number of places where TRSOURCE traps need to be set ... Jeff
Re: z/VM paging problem
Er ... meanwhile back at the original problem ... Folks, Ed is reporting that EVERY attempt to issue CP IPL command to ANY vdev is ALWAYS generating HCPCLS174E on a system that is otherwise runnin g happily. Now, sorry and all that, but I just don't buy the idea that thes e symptoms match with a faulty paging pack - the symptoms are too consisten t and there are no other symptoms - remember that this system is UP AND RUNNING, with LOTS of active users - unless Ed's current system pagerate is really and truly zero, for this to be the one-and-only symptom of a faulty page volume would be downright bizarre. Now, IIRC, the way that CP, "loads" the IPL simulator is by first paging out a guest page (page 1?) and then messing with the guest's page tables to point the guest page at the IPL simulator which sits inside the CP nucleus (it's been several years - can anybody help out here?) and then dispatching the guest, which triggers a pagein. This, "feels" like the only paging operation that's going to be common the ALL IPL VDEV commands . Comment? Personally, for starters, I'd be using TRACE ALL (probably NOT to the console, but to the virtual printer) just to get a feel for how long it goes before it crashes - and then, "fine down" the trace based on that experience. If Ed gets HCPCLS174E before any instructions are executed then we'll have a, "smoking gun" pointing straight at the process that saves the guest page and then loads the IPL Simulator - if not then at least one real possibility will have been eliminated. (A thought - the guest page is probably not saved with IPL CLEAR - Ed, can you confirm tha t IPL vdev CLEAR fails as well as IPL vdev NOCLEAR?) I have a second Euro that I'll stake against a nickel that says that this is NOT a problem with Ed's paging packs - any takers for THIS one? Regards, Jeff (Eliminate the impossible) Gribbin
Re: z/VM paging problem
I've been sitting on my thumbs ever since this thread started, expecting the, "Ahah!" post at any minute ... but it's not arrived. If I'm reading the problem definition correctly we have a consistent, repeatable problem - that alone makes me suspect that it's not a dodgy chunk of pagespace. However, it DOES get me asking, "Why not TRACE the beastie"? If you set traces before issuing the IPL command you will, "see" the IPL Command Simulator running in guest storage and will (hopefully) gain some insight as to exactly what's happening at the moment that the error occur s. In extremis, assuming that the problem can be recreated 2nd-level and the guest trace is insufficient to generate that, "Ahah!" moment, you could even enjoy a day tracing it through CP . It just depends on how stubborn you really are. I have 5 cents that says we're all going to feel dreadfully dumb once thi s one is bottomed out. (Well, actually, it might have to be a Euro - not sure if there are any nickels left in my coin collection - any takers?)
Re: MDC, Storage, xstore, and cache on External dasd.
On the, "Get close to the application" thread, remember that any I/O request satisfied from MDC is likely to be satisfied (on modern boxes) in less than a microsecond. Even cached, anything that involves a conversation with a channel is going to experience a service time that is several orders of magnitude higher. It's always important to reflect on the cost and consider the best way of investing ones limited currency (in this case, central / expanded storage), but some MDC payback is usually a no-brainer. I believe this to be especially true when dealing with synchronous I/O - and how much I/O nowadays is truly, "application asynchronous"? Not as much as in the, "batch sequential" days, that's for sure. (Not, of course , that CMS has ever been strong in the, "I/O overlap" department from a single user's perspective.) It would be an unusual configuration that would benefit from the reassignment of all MDC storage to, "other uses".
Re: duplicate dasd volume serial numbers
In this specific instance ("I wanna move a dedicated paging volume") wher
e
the data contained on the pack is purely ephemeral and only relevant unti
l
the next SHUTDOWN, it can be worthwhile to know that, once CP's recognise
d
a CP-OWNED volume at (usually) IPL time and added it to the CP-OWNED list
,
it has no reason to go back and re-read the volume serial number.
It is therefore perfectly straightforward to format and allocate a new
paging pack and then, via a minidisk definition covering cylinder zero of
the, "old" pack, relabel the, "old" pack without giving the currently-
running system any problems at all - it'll happily carry on paging to the
relabelled pack until SHUTDOWN time. If one format/allocates the new pack
with a dummy label and then runs the two relabel steps together using a
single file as input to ICKDSF then this reduces the, "window of
opportunity" when (neither or) both volumes have the, "magic" volser to
(usually) milliseconds.
"There's old sysprogs, and there's bold sysprogs ..."
Regards
Jeff Gribbin
Re: Volume with minidisks has no allocation information
Further to the comments regarding sharing of DASD between CMS users and OS - this was routine behaviour at a former employer of mine (back when DASD was always in short supply). We would format the DASD on the OS side , allocate a dataset covering the back end - and then zap the VTOC to flag the dataset as password-protected, but never put a password into the password dataset (RAC-who? ). This effectively rendered the, "CMS" cylinders unreadable from OS. On VM we would allocate a dummy minidisk that mapped the OS part of the disk (to keep DISKMAP and the such happy) and then simply allocate CMS minidisks on the, "CMS portion" in the usual manner. Never a problem in many years of operation. As Tom said, "As long as everyone agrees to what's being done ...". In this particular setup, V M and OS ran on separate machines with a fully-shared DASD farm. Reading CMS minidisks from OS is not, "difficult". Again, at a different former employer, this was routine behaviour - we had a utility that serve d as a kind-of poor man's RSCS by reading JCL stored on a specified CMS minidisk and submitting it into the internal reader. The writing of code of this kind was considered a training exercise for junior sysprogs - onc e they'd successfully done something like this you could confidently expect them to understand a whole raft of basic functionality from BDAM through DYNALLOC and the internals of the CMS File System and the CP Object Directory. It also helped to break down the barriers between the VM Bigot s and the OS Bigots (not that, other than in the sense of gentle rivalry, I've ever found this to exist among real systems programmers - who seem eager to take apart anything and everything to find out how it works - or was that, "worked" ). Regards Jeff Gribbin
Re: Emulated tape/ECKD disk
David - thanks for the clarification - it certainly improves my understanding of what-and-why and where you're coming from. I agree that we should refrain from asking IBM for specific solutions - this makes it all the more important though that the problem is well- defined - otherwise (especially in todays business climate) one ends up with a narrow and specific solution that is incapable of forming the foundation for further development into currently-unimagined areas. We need to ensure that any solution is engineered with an eye on the future. As you so rightly say, this is hopefully addressed by dialogue with the developers at the design / concept stage - ensuring that the problem description accurately reflects the vision of what is needed. Alas, so far it only seems to be you-and-me that're willing to get excite d by this - I really expected you to start a mailstorm with this one but it seems to have failed to capture the community's imagination. We'll certainly need more opinions than just yours-and-mine if this ever gets t o the, "IBM asking for feedback" stage! Regards Jeff
Re: Emulated tape/ECKD disk
"This really needs to be core VM function" ...
David,
Let me reiterate that comment as I understand it, because I think it's
possible to interpret the scope of what you mean by, "Core VM function" i
n
different ways - and it's a definition that we need to agree upon if we'r
e
to have a fruitful discussion.
In my view, the, "Core VM Function" that IBM has to buy into is the
provision of an API in CP that allows the creation of an RDEV of any kind
("take, "any" with a pinch of salt - hopefully it could be architeched to
do, "any" in principle but maybe limited for practical/business reasons t
o
(say) tape and DASD on its first outing) together with the supporting API
that allows communication between the created RDEV and a Service Virtual
Machine. Again, I cite *CCS as the conceptual model.
Personally, I DO NOT see (and, if I read you correctly, neither do you)
the provision of the server code that drives this API as part of the "Cor
e
VM Function" that IBM needs to buy into. While I can see that IBM might
well wish to take advantage of the API and deliver function that is based
on the API I am also certain that there are entrepreneurs across the whol
e
spectrum from Open-Sourcers to Proprietary OCOers who would gladly grab
the opportunity to provide all kinds of arcane and esoteric device suppor
t
base upon the aforesaid, "Core VM Function".
As I said earlier, I believe that this is just a re-statement and
clarification of the scope that you already subscribe to but - if not the
n
at least, with your reply, we're likely all to be definitely talking abou
t
the same thing.
Pardon my pedantry.
Regards
Jeff
Re: Emulated tape/ECKD disk
I recall how excited I was when I first learned about the *CCS support mechanism that is used to support VTAM logon terminals in CP. The concept of having an RDEVBLOK as the gateway to a server (didn't call 'em servers back then - big mistake) opened up so many possibilities for device emulation and mapping that I (then) felt that it was OBVIOUS that this interface would be extended to other device types - providing a general- purpose API for using a server to emulate any kind of RDEV that CP supports. Alas, in those young, exciting days I was horribly naive and didn't understand words like, "business case". I'm thankful that David, however, does. If implemented, this proposal would, in my view, be the best thing to happen to VM since Linux. (Sliced bread? Doesn't even come close.)
Re: zVM 5.2 ESAMAP and MXG
This has now been resolved. MXG Update 24.035, available from Merrill, addresses the problems. Many thanks to all who contributed to identifying and resolving this problem. Regards Jeff
Re: zVM 5.2 ESAMAP and MXG
Thanks Mike - that makes it more likely, "something silly" at this end. Yes, I meant the HISTORY file (we actually ship the, "daily" HISTORY file that ESAMAP builds from the HISTORY file created by ESAWRITE - the one with the date as the filetype). We use NETDATA to pack the file and ship it via RSCS rather than go via tape but otherwise we're doing similar things. Our ESAWRITE / ESAMAP (as shown in the header of the HISTORY records) is at 3.5.2.5 and our MXG is at 23.05. I'd be interested in knowing your ESAWRITE / ESAMAP level. Suggest we now take this off-list as it looks like a, "minority interest topic" and I'll post a conclusion once one's achieved. Regards Jeff
zVM 5.2 ESAMAP and MXG
This is a stab in the dark - I'm looking for somebody else who's running Velocity's ESAMAP under zVM 5.2 and feeding the ESAMAP, "Daily Digests" into Merrill's MXG software. We are (obviously) experiencing some difficulties with this setup, or I wouldn't be asking, but we'd like to reassure ourselves that they're problems of our own making - hopefully by finding somebody who says, "Problem? What problem?". If you ARE running this software mix - either successfully or unsuccessfully - I'd appreciate it if you could please say so - either on - list or off-list, whichever you prefer. I'll take silence to mean that we're the pioneers. TIA Jeff Gribbin
