subject:"How comments treated by DIRMAINT"

On 13/02/2008, Huegel, Thomas [EMAIL PROTECTED] wrote:

  I am amazed that so many people here still use 80 column '3270's..


My diopter is -4.25. What's yours?

Re: How comments treated by DIRMAINT


 All in all, maybe the 80-col 3270 **isn't** such a bad thing.


No, it's not. I find it hard to read anything on model 5. My weary eyes go
slowly from right to left and often hit the wrong spot. And having XEDIT
prefix area on my preferred right side, it's just too far away. Model 3 is
to my liking.

And hallelujah to the good old 3278's (although you had to keep typing while
lying on the floor if you dropped them). :-)


Ivica

Re: How comments treated by DIRMAINT

2008-02-12 Thread David Boyes

All facetiousness aside, there's a remarkable amount of ergonomics and
human factors stuff that went into the 3278 that is still valid. Having
that sucker be 2.5-3 ft high just to put the screen at eye level was a
Good Thing. Having a keyboard that gave you really good tactile feedback
was a Good Thing (perfected, IMHO, in the 3279). Having fonts that
clearly distinguished between O and 0 and S and 8 was a Good Thing (as
was the sizing of same). 

 

All in all, maybe the 80-col 3270 *isn't* such a bad thing. 

 

-- db

Re: How comments treated by DIRMAINT

2008-02-12 Thread Adam Thornton



On Feb 12, 2008, at 12:56 PM, Huegel, Thomas wrote:


I am amazed that so many people here still use 80 column '3270's..


80 columns is the width that God Intended.

If we were supposed to read wider screens, we'd have eyestalks.

Adam

Re: How comments treated by DIRMAINT

2008-02-12 Thread pfa

My memory buffer - at the present time - is only 80 bytes wide.  Anything 
more than that, and I'd have a data over-run (or overlay, hmm..) 
condition.
 



[EMAIL PROTECTED] 
Sent by: IBMVM@LISTSERV.UARK.EDU
02/12/2008 02:08 PM
Please respond to
IBMVM@LISTSERV.UARK.EDU


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: How comments treated by DIRMAINT







All facetiousness aside, there?s a remarkable amount of ergonomics and 
human factors stuff that went into the 3278 that is still valid. Having 
that sucker be 2.5-3 ft high just to put the screen at eye level was a 
Good Thing. Having a keyboard that gave you really good tactile feedback 
was a Good Thing (perfected, IMHO, in the 3279). Having fonts that clearly 
distinguished between O and 0 and S and 8 was a Good Thing (as was the 
sizing of same). 
 
All in all, maybe the 80-col 3270 *isn?t* such a bad thing. 
 
-- db

Re: How comments treated by DIRMAINT

2008-02-12 Thread Huegel, Thomas

And the size was the same size as a 1900 dollar bill... No Susan B. Anthony
back then.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Stephen Frazier
Sent: Tuesday, February 12, 2008 2:49 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT

The way I heard it was that there were 80 questions on the 1900 census.
Machines were built to 
process the census data. As the machines were there they got used for other
things.

RPN01 wrote:
 I’m not sure why Mr. Hollerith chose 80 columns, but 
 it has really hung on. 
-- 
Stephen Frazier
Information Technology Unit
Oklahoma Department of Corrections
3400 Martin Luther King
Oklahoma City, Ok, 73111-4298
Tel.: (405) 425-2549
Fax: (405) 425-2554
Pager: (405) 690-1828
email:  stevef%doc.state.ok.us

Re: How comments treated by DIRMAINT

2008-02-12 Thread Stephen Frazier

The way I heard it was that there were 80 questions on the 1900 census. Machines were built to 
process the census data. As the machines were there they got used for other things.


RPN01 wrote:
I’m not sure why Mr. Hollerith chose 80 columns, but 
it has really hung on. 

--
Stephen Frazier
Information Technology Unit
Oklahoma Department of Corrections
3400 Martin Luther King
Oklahoma City, Ok, 73111-4298
Tel.: (405) 425-2549
Fax: (405) 425-2554
Pager: (405) 690-1828
email:  stevef%doc.state.ok.us

Re: How comments treated by DIRMAINT

2008-02-12 Thread Thomas Kern

Some entries in one of my systems are more than 23 years old. The lack 
of a year makes this date/time stamp irrelevant. A separate transaction 
audit log would be much better and archivable.


/Tom Kern

RPN01 wrote:

You can get rid of them But DirMaint is just going to put them right
back again when you replace the user. :-)

If it's a modification date, it doesn't contain a year, which, on
longer-term systems, would become useless. It'd be like saying It changed
Wednesday. Also, the DirMaint DVHOPT record has a different line number
than the rest of the entry.

Re: How comments treated by DIRMAINT

2008-02-12 Thread Jim Bohnsack

Back in the 80's, give or take a decade, but I think early 80's, there 
was a machine, might have been the IBM System 3 or one of it's 
relatives, that used a 96 col card. I never really caught on, at least 
the card didn't, because it was only about 3 or 3 1/2 long and maybe 2 
1/2 high. I think the reason was because they didn't stick up in your 
shirt pocket behind your plastic pocket protector to announce that you 
were a computer geek and they didn't have enough room for a good sized 
grocery list--at least when the list would be started with essentials 
such as:


12 pack beer
donuts
Jack Daniels Black Label
wine.

Jim

Stephen Frazier wrote:
The way I heard it was that there were 80 questions on the 1900 census. Machines were built to 
process the census data. As the machines were there they got used for other things.


RPN01 wrote:
  
I’m not sure why Mr. Hollerith chose 80 columns, but 
it has really hung on. 




--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]

Re: How comments treated by DIRMAINT

2008-02-12 Thread RPN01

You can get rid of them But DirMaint is just going to put them right
back again when you replace the user. :-)

If it's a modification date, it doesn't contain a year, which, on
longer-term systems, would become useless. It'd be like saying It changed
Wednesday. Also, the DirMaint DVHOPT record has a different line number
than the rest of the entry.

-- 
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55200 First Street SW
  /( )\   507-284-0844  Rochester, MN 55905
  ^^-^^   - 
In theory, theory and practice are the same, but
 in practice, theory and practice are different.




On 2/12/08 11:41 AM, Thomas Kern [EMAIL PROTECTED] wrote:

 Columns 73-80 in my directory are not sequential. They seem to be a
 date/time stamp of when a record was modified by a DIRMAINT command. I
 don't use them. My xedit profile does a 'Verify 1-72' for directory
 entries. I think they can be gotten rid of if a good audit log is kept.
 
 /Tom Kern

Re: How comments treated by DIRMAINT

2008-02-12 Thread Thomas Kern

Columns 73-80 in my directory are not sequential. They seem to be a
date/time stamp of when a record was modified by a DIRMAINT command. I
don't use them. My xedit profile does a 'Verify 1-72' for directory
entries. I think they can be gotten rid of if a good audit log is kept.

/Tom Kern

Mike Walter wrote:
And why, pray tell, do we really need sequence numbers on the records any
more? Is someone afraid that they are going to drop the virtual card deck
on the real raised data center floor?

Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.floor? ;-)

Schuh, Richard [EMAIL PROTECTED]

Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
02/12/2008 10:59 AM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU

To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: How comments treated by DIRMAINT

If all of the records were actually the same length (as are the current
directory source records, having a sequence number in 72-80), RECFM V
would waste space, not save it.
Think of the disk savings!

The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email.

Re: How comments treated by DIRMAINT

2008-02-12 Thread Stracka, James (GTI)

What happened to PA4 and PA5?
 
I could not adjust my eyes to those red plasma terminals.  We had some
here until last November when they decided we had to say good-bye to
them.

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of David Boyes
Sent: Tuesday, February 12, 2008 2:58 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT



Per your comment on the 3279: Did you ever use any of the
original 3279 terminals with the chicklet keyboards? We had serial
numbers 6, 10 and 12, and the keyboards were horrible; there was ample
space between the keys (both vertically and horizontally) for you to be
able to miss a key entirely. The intent was to allow overlays to be put
over the keyboard describing additional functions and / or layouts, but
it was abysmal to type on.

I've seen them, but managed to avoid having to use one. The mod
2 and 3 (particularly the 3G) 3279s are what I consider to be perfect. 

We also had some of the 3290 terminals, with the 160 column
screens, which could be split into four 80 column virtual screens. These
were great, other than coming only in orange. We had them as Operator
consoles, allowing them to monitor four screens at a time, and blow up
one screen when something deemed important was going on there.

Still have one...8-)  I need to find the microcode support for
it for my last functioning 3174, though.


This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.

Re: How comments treated by DIRMAINT

2008-02-12 Thread David Boyes

Per your comment on the 3279: Did you ever use any of the original 3279
terminals with the chicklet keyboards? We had serial numbers 6, 10 and
12, and the keyboards were horrible; there was ample space between the
keys (both vertically and horizontally) for you to be able to miss a key
entirely. The intent was to allow overlays to be put over the keyboard
describing additional functions and / or layouts, but it was abysmal to
type on.

I've seen them, but managed to avoid having to use one. The mod 2 and 3
(particularly the 3G) 3279s are what I consider to be perfect. 

We also had some of the 3290 terminals, with the 160 column screens,
which could be split into four 80 column virtual screens. These were
great, other than coming only in orange. We had them as Operator
consoles, allowing them to monitor four screens at a time, and blow up
one screen when something deemed important was going on there.

Still have one...8-)  I need to find the microcode support for it for my
last functioning 3174, though.

Re: How comments treated by DIRMAINT

2008-02-12 Thread Huegel, Thomas

I am amazed that so many people here still use 80 column '3270's..

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Ivica Brodaric
Sent: Tuesday, February 12, 2008 12:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT

And when entering XEDIT ALL commands, the comments appear with the
displayed statements, rather than being on a hidden line before or after the
displayed record.  (Personally, MINIOPT has always bugged me).

Me too. The cure: Z 1 1#ALL /M/ 

Granted, the comments can be a little far to the right of an 80-byte wide
the screen, but XEDIT's SET VERIFY 1 * takes care of that pretty easily.

Hmmm, followed by SET TRUNC, SET ZONE (even SET LRECL) if XEDIT PROFILE
doesn't take care of that correctly. I personally dislike lines spilling on
to the next line on screen given that SCALE doesn't spill. I hate when my
text gets cut off in that hard-to-calculate column in the second line. 

F 80 is just fine for me.

Ivica

Re: How comments treated by DIRMAINT

2008-02-12 Thread Dale R. Smith

Not to mention all of my PIPE's in Execs that read the source directory 

and the first thing they do is CHOP 72 to get rid of any sequence 
numbers in 73-80!

-- 
Dale R. Smith

If we knew what we were doing, it wouldn't be called research,
would it? 
 
   
- Albert Einstein   
 
  

On Tue, 12 Feb 2008 11:41:36 -0600, RPN01 [EMAIL PROTECTED] wrote:

The downside is that DirMaint currently uses the columns from 73 to 80 f
or
its own information. Changing to a V format would break DirMaint.

--
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55200 First Street SW
  /( )\   507-284-0844  Rochester, MN 55905
  ^^-^^   -
In theory, theory and practice are the same, but
 in practice, theory and practice are different.

Re: How comments treated by DIRMAINT

As far as the volume labels are concerned, there are programs (DDR,
ICKDSF, etc.) that verify the label before destroying the disk, so the
label isn't all that onerous. It keeps from having to create a Windows
Registry to record identifying information. That central area where the
DEVDESC information that you ask for is stored is likely to become just
such  an area. For example, we are in the process of upgrading our DASD.
We have thousands of disks that must be copied. Any shop that moves
things around for whatever reason is likely to have problems with the
DEFINE command changes you suggest. You cannot try to ease the pain of a
big move by having CP delete entries when a disk no longer exists
because is is possible that hardware failure could mimic the removal
process when seen from CP's vantage.
 
Regards, 
Richard Schuh 

 

 




From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Ivica Brodaric
Sent: Tuesday, February 12, 2008 9:33 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT


I never meant this to be top of the list for IBM Development.
There are more pressing issues, of course. But it just annoys me that in
this day and age (yes, I'll use that phrase) all we have to describe a
minidisk using whatever we want to put in there is a minidisk label
(apart from address, of course). Not to mention other devices that don't
have that 6-character luxury. Sooo 1960's, which may be a good thing
(but so was Y2K, for my back pocket).  

I mean, what does TCP191 tell you? Is it TCPIP or TCPMAINT? I
won't even go to TC0191. And how many times did we forget to change the
label after changing the minidisk address? Q MDISK was invented because
Q DISK couldn't tell you enough and was possibly telling you the wrong
thing. So why not give us a bit more that we can change *at the same
time* when we change something in the directory? 

I don't care if that comment or device name is in the
directory or CP gets it from somewhere else (but where else?). Not
putting rubbish in those comments would be just a matter of common sense
which you can't rely on, but if one wants to put something stupid like a
URL of MP3 of disk spinning in that field, so what? The advantage of
being able to name a disk CMS Apply Level n to a newbie (and even to
me, considering a rate of my brain cell depletion) overweighs that. And
I can think of much worse ways of bloating the directory like not using
profiles where you can.

I would also like to see it added in CP DEFINE. Call it DEVDESC
or DEVNAME, or whatever.

One has to be careful though not to introduce an ambiguity in
design, so that applications and guest OSs of the future don't hijack it
for their own selfish purpose (you can put anything in this field
unless you use XXX, in which case it has to be structured). I'd hate to
see /LINUX SWAPFILE MAKEONCE or ;TCPIP MAILME WHEN DEAD as device
description. But that could even be a feature, depending on your view.
We already have RSCS...

Again, this is not very important, but could open some new doors
in the future and make our VM a bit more modern and palatable to
newbies.

Ivica Brodaric

Re: How comments treated by DIRMAINT


 And when entering XEDIT ALL commands, the comments appear with the
 displayed statements, rather than being on a hidden line before or after the
 displayed record.  (Personally, MINIOPT has always bugged me).


Me too. The cure: Z 1 1#ALL /M/

Granted, the comments can be a little far to the right of an 80-byte wide
 the screen, but XEDIT's SET VERIFY 1 * takes care of that pretty easily.


Hmmm, followed by SET TRUNC, SET ZONE (even SET LRECL) if XEDIT PROFILE
doesn't take care of that correctly. I personally dislike lines spilling on
to the next line on screen given that SCALE doesn't spill. I hate when my
text gets cut off in that hard-to-calculate column in the second line.

F 80 is just fine for me.

Ivica

Re: How comments treated by DIRMAINT

Do you want those who have 1 yeaar's experience 20 times over to contact
you?

Regards, 
Richard Schuh 

 

 -Original Message-
 From: The IBM z/VM Operating System 
 [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark
 Sent: Tuesday, February 12, 2008 10:12 AM
 To: IBMVM@LISTSERV.UARK.EDU
 Subject: Re: How comments treated by DIRMAINT
 
 On Tuesday, 02/12/2008 at 12:33 EST, Ivica Brodaric 
 [EMAIL PROTECTED] wrote:
 
  Again, this is not very important, but could open some new doors in 
  the
 future 
  and make our VM a bit more modern and palatable to newbies.
 
 Importance is in the eye of the beholder.
 
 I invite anyone with fewer than 2 years with VM to e-mail me 
 with your Top Five list of things that you have found hard, 
 complicated, or needlessly
 (?) confusing about VM.  That is, things related to the 
 planning, acquisition, installation, customization, 
 maintenance, operation and monitoring of z/VM.  Feel free to 
 include hardware-related issues as well.
 
 I know we old-timers have lots of war stories about the Olden 
 Days, but I am more interested in a fresh perspective.  Thanks!
 
 Alan Altmark
 z/VM Development
 IBM Endicott

Re: How comments treated by DIRMAINT

2008-02-12 Thread Alan Altmark

On Tuesday, 02/12/2008 at 12:33 EST, Ivica Brodaric 
[EMAIL PROTECTED] wrote:

 Again, this is not very important, but could open some new doors in the 
future 
 and make our VM a bit more modern and palatable to newbies.

Importance is in the eye of the beholder.

I invite anyone with fewer than 2 years with VM to e-mail me with your Top 
Five list of things that you have found hard, complicated, or needlessly 
(?) confusing about VM.  That is, things related to the planning, 
acquisition, installation, customization, maintenance, operation and 
monitoring of z/VM.  Feel free to include hardware-related issues as well.

I know we old-timers have lots of war stories about the Olden Days, but I 
am more interested in a fresh perspective.  Thanks!

Alan Altmark
z/VM Development
IBM Endicott

Re: How comments treated by DIRMAINT

2008-02-12 Thread David Boyes

 But the next thing you know you'll be wanting a V-format file!  :-)

Nah, VBS!  It's about time that CMS moved into the 1970's with OS/VS1,
SVS, and MVS!  ;-) 



VSAM anyone?... oh, wait, they discontinued that - it might lead to
application development. How about an embedded DB/2? 

 

Ok, the vapors have passed. -1d4 sanity. 

-- db

Re: How comments treated by DIRMAINT

2008-02-12 Thread RPN01

The downside is that DirMaint currently uses the columns from 73 to 80 for
its own information. Changing to a V format would break DirMaint.

-- 
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55200 First Street SW
  /( )\   507-284-0844  Rochester, MN 55905
  ^^-^^   - 
In theory, theory and practice are the same, but
 in practice, theory and practice are different.




On 2/12/08 10:45 AM, Schuh, Richard [EMAIL PROTECTED] wrote:

 Source comments would be great. V format would be perfectly acceptable,
 even preferable. (Why does everything have to be so Holerith Card-like,
 anyway?) 
  
 
 Regards, 
 Richard Schuh

Re: How comments treated by DIRMAINT

Because that is the way it has always been. They are needed just in case
the CMS file system scrambles the file or the virtual card deck gets
dropped on the real minidisk :-)

Regards, 
Richard Schuh 

 

 




From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter
Sent: Tuesday, February 12, 2008 9:21 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT



And why, pray tell, do we really need sequence numbers on the
records any more?  Is someone afraid that they are going to drop the
virtual card deck on the real raised data center floor? 

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not
necessarily represent the opinions or policies of Hewitt
Associates.floor?  ;-) 




Schuh, Richard [EMAIL PROTECTED] 

Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 

02/12/2008 10:59 AM 
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU



To
IBMVM@LISTSERV.UARK.EDU 
cc
Subject
Re: How comments treated by DIRMAINT






If all of the records were actually the same length (as are the
current directory source records, having a sequence number in 72-80),
RECFM V would waste space, not save it. 
Think of the disk savings! 






The information contained in this e-mail and any accompanying
documents may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient of this
message, or if this message has been addressed to you in error, please
immediately alert the sender by reply e-mail and then delete this
message, including any attachments. Any dissemination, distribution or
other use of the contents of this message by anyone other than the
intended recipient is strictly prohibited. All messages sent to and from
this e-mail address may be monitored as permitted by applicable law and
regulations to ensure compliance with our internal policies and to
protect our business. Emails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you
communicate with us by email.

Re: How comments treated by DIRMAINT

2008-02-12 Thread Huegel, Thomas

I know .. 72-80 can be a 'pointer' into a COMMENT FILE, that way we can use
the same set of comments for many directory source statements, similiar to
the message text files... OK I think I have had too much winter this year,
or maybe I should have skipped that 3rd cup of coffee. 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Mike Walter
Sent: Tuesday, February 12, 2008 11:21 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT

And why, pray tell, do we really need sequence numbers on the records any
more?  Is someone afraid that they are going to drop the virtual card deck
on the real raised data center floor? 

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.floor?  ;-) 

Schuh, Richard [EMAIL PROTECTED] 

Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 

02/12/2008 10:59 AM 

Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU

To
IBMVM@LISTSERV.UARK.EDU 

cc

Subject
Re: How comments treated by DIRMAINT

If all of the records were actually the same length (as are the current
directory source records, having a sequence number in 72-80), RECFM V would
waste space, not save it. 
Think of the disk savings! 

  _  

The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately alert
the sender by reply e-mail and then delete this message, including any
attachments. Any dissemination, distribution or other use of the contents of
this message by anyone other than the intended recipient is strictly
prohibited. All messages sent to and from this e-mail address may be
monitored as permitted by applicable law and regulations to ensure
compliance with our internal policies and to protect our business. Emails
are not secure and cannot be guaranteed to be error free as they can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by email.

Re: How comments treated by DIRMAINT

2008-02-12 Thread Alan Altmark

On Tuesday, 02/12/2008 at 12:21 EST, Mike Walter [EMAIL PROTECTED] 
wrote:
 And why, pray tell, do we really need sequence numbers on the records 
any more? 
  Is someone afraid that they are going to drop the virtual card deck on 
the 
 real raised data center floor? 

I would imagine that everyone who is steadfast in their committment to 
manage USER DIRECT themselves likes being able to use update mode, 
control, and aux files to track updates.

But in case you DO accidentally move all the records around and get them 
mixed up (never teach a 6-year-old how to use XEDIT, by the way), you can 
sort them back into place.  :-)

Alan Altmark
z/VM Development
IBM Endicott

Re: How comments treated by DIRMAINT

2008-02-12 Thread Mike Walter

And why, pray tell, do we really need sequence numbers on the records any 
more?  Is someone afraid that they are going to drop the virtual card deck 
on the real raised data center floor?

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.floor?  ;-)




Schuh, Richard [EMAIL PROTECTED] 

Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
02/12/2008 10:59 AM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: How comments treated by DIRMAINT






If all of the records were actually the same length (as are the current 
directory source records, having a sequence number in 72-80), RECFM V 
would waste space, not save it. 
Think of the disk savings!

 
The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. Emails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by email.

Re: How comments treated by DIRMAINT

If all of the records were actually the same length (as are the current
directory source records, having a sequence number in 72-80), RECFM V
would waste space, not save it. 

Think of the disk savings!

Re: How comments treated by DIRMAINT

2008-02-12 Thread Mike Walter

 But the next thing you know you'll be wanting a V-format file!  :-) 
Nah, VBS!  It's about time that CMS moved into the 1970's with OS/VS1, 
SVS, and MVS!  ;-)

But seriously, why not?  What would be the harm?  At least it's worth 
considering.  Think of the disk savings!  ... Oh, that's right; IBM sells 
disk, too!

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.




Alan Altmark [EMAIL PROTECTED] 

Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
02/11/2008 08:30 PM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: How comments treated by DIRMAINT






On Monday, 02/11/2008 at 05:20 EST, Mike Walter [EMAIL PROTECTED] 
wrote:

 Removing the 80-byte card restriction (antiquated given that very few 
sites 
 have in-use physical card punches or readers any more) sets the stage 
for many 
 other future directory statement improvements and extensions. 

Yeah, I was looking at that, too.  If all you want are source comments 
rather than something queryable, it can be easily since DIRECTXA only 
scans cols 1-71 anyway.  No need for special characters.

But the next thing you know you'll be wanting a V-format file!  :-)

Alan Altmark
z/VM Development
IBM Endicott



 
The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. Emails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by email.

Re: How comments treated by DIRMAINT

2008-02-12 Thread Stracka, James (GTI)

Because, That is the way we always did it!

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Tuesday, February 12, 2008 11:45 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT

Source comments would be great. V format would be perfectly acceptable,
even preferable. (Why does everything have to be so Holerith Card-like,
anyway?) 

Regards, 
Richard Schuh

This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.

Re: How comments treated by DIRMAINT

Source comments would be great. V format would be perfectly acceptable,
even preferable. (Why does everything have to be so Holerith Card-like,
anyway?) 
 

Regards, 
Richard Schuh 

 

 -Original Message-
 From: The IBM z/VM Operating System 
 [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark
 Sent: Monday, February 11, 2008 6:31 PM
 To: IBMVM@LISTSERV.UARK.EDU
 Subject: Re: How comments treated by DIRMAINT
 
 On Monday, 02/11/2008 at 05:20 EST, Mike Walter 
 [EMAIL PROTECTED]
 wrote:
 
  Removing the 80-byte card restriction (antiquated given 
 that very few
 sites 
  have in-use physical card punches or readers any more) sets 
 the stage
 for many 
  other future directory statement improvements and extensions. 
 
 Yeah, I was looking at that, too.  If all you want are source 
 comments rather than something queryable, it can be easily 
 since DIRECTXA only scans cols 1-71 anyway.  No need for 
 special characters.
 
 But the next thing you know you'll be wanting a V-format file!  :-)
 
 Alan Altmark
 z/VM Development
 IBM Endicott

Re: How comments treated by DIRMAINT

2008-02-12 Thread RPN01

Per your comment on the 3279: Did you ever use any of the original 3279
terminals with the ³chicklet² keyboards? We had serial numbers 6, 10 and 12,
and the keyboards were horrible; there was ample space between the keys
(both vertically and horizontally) for you to be able to miss a key
entirely. The intent was to allow overlays to be put over the keyboard
describing additional functions and / or layouts, but it was abysmal to type
on.

We also had some of the 3290 terminals, with the 160 column screens, which
could be split into four 80 column virtual screens. These were great, other
than coming only in orange. We had them as Operator consoles, allowing them
to monitor four screens at a time, and blow up one screen when something
deemed important was going on there.

There¹ve been so many attempts to supplant the 80 column ³card² mentality
that have failed so completely. I.E. The 90 column System-3 cards, for
example. I¹m not sure why Mr. Hollerith chose 80 columns, but it has really
hung on. (Actually, Hollerith¹s original cards were 45 columns, with round
holes. It would appear that IBM is responsible for the rectangle holes and
the 80 columns.)

Have a great Tuesday...

-- 
Robert P. Nix Mayo Foundation  .~.
RO-OE-5-55  200 First Street SW  /V\
507-284-0844   Rochester, MN 55905  / ( ) \
-^^-^^
In theory, theory and practice are the same, but ³Join the story...
Ride Ural.²
 in practice, theory and practice are different.




On 2/12/08 1:08 PM, David Boyes [EMAIL PROTECTED] wrote:

 All facetiousness aside, there¹s a remarkable amount of ergonomics and human
 factors stuff that went into the 3278 that is still valid. Having that sucker
 be 2.5-3 ft high just to put the screen at eye level was a Good Thing. Having
 a keyboard that gave you really good tactile feedback was a Good Thing
 (perfected, IMHO, in the 3279). Having fonts that clearly distinguished
 between O and 0 and S and 8 was a Good Thing (as was the sizing of same).
  
 All in all, maybe the 80-col 3270 *isn¹t* such a bad thing.
  
 -- db

Re: How comments treated by DIRMAINT

2008-02-12 Thread Dave Jones


Alan Altmark wrote:

mixed up (never teach a 6-year-old how to use XEDIT, by the way), you can 
sort them back into place.  :-)




Why not? When my son was around 6 or so, I showed him how to use Xedit 
to write simple thank you notes and he thought it was way cooler than 
anything he had seen on Windows;-) Plus, it's *intuitive*.

Alan Altmark
z/VM Development
IBM Endicott


--
DJ

V/Soft
  z/VM and mainframe Linux expertise, training,
  consulting, and software development
www.vsoft-software.com

Re: How comments treated by DIRMAINT

I never meant this to be top of the list for IBM Development. There are more
pressing issues, of course. But it just annoys me that in this day and age
(yes, I'll use that phrase) all we have to describe a minidisk using
whatever we want to put in there is a minidisk label (apart from address, of
course). Not to mention other devices that don't have that 6-character
luxury. Sooo 1960's, which may be a good thing (but so was Y2K, for my back
pocket).
I mean, what does TCP191 tell you? Is it TCPIP or TCPMAINT? I won't even go
to TC0191. And how many times did we forget to change the label after
changing the minidisk address? Q MDISK was invented because Q DISK couldn't
tell you enough and was possibly telling you the wrong thing. So why not
give us a bit more that we can change *at the same time* when we change
something in the directory?
I don't care if that comment or device name is in the directory or CP
gets it from somewhere else (but where else?). Not putting rubbish in those
comments would be just a matter of common sense which you can't rely on, but
if one wants to put something stupid like a URL of MP3 of disk spinning in
that field, so what? The advantage of being able to name a disk CMS Apply
Level n to a newbie (and even to me, considering a rate of my brain cell
depletion) overweighs that. And I can think of much worse ways of bloating
the directory like not using profiles where you can.

I would also like to see it added in CP DEFINE. Call it DEVDESC or DEVNAME,
or whatever.

One has to be careful though not to introduce an ambiguity in design, so
that applications and guest OSs of the future don't hijack it for their own
selfish purpose (you can put anything in this field unless you use XXX, in
which case it has to be structured). I'd hate to see /LINUX SWAPFILE
MAKEONCE or ;TCPIP MAILME WHEN DEAD as device description. But that could
even be a feature, depending on your view. We already have RSCS...

Again, this is not very important, but could open some new doors in the
future and make our VM a bit more modern and palatable to newbies.

Ivica Brodaric

Re: How comments treated by DIRMAINT

2008-02-11 Thread Horlick, Michael

Hi,

 

Is there a command that can tell what these parameters are set to or do I need 
to check all the mdisks that DIRMAINT has access to.

 

I started this thread and what we want is simple. For our VSE machines what we 
want is WYSIWYG. When I want to do a 'DIRM REPLACE', DIRMAINT should replace 
the current source directory entry as given to it if there are no errors in it 
(how about having an 'ASIS' option?).  

 

I know sometimes adding a comment for a new minidisk is sometimes preserved in 
the source and sometimes I'll see the comment somewhere else in the directory 
entry. If I could find out the logic of how DIRMAINT does the shuffling, maybe 
I could follow its rule(s) in order to get the source looking the way I want.   

 

Thanks,

 

Mike 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of RPN01
Sent: February 11, 2008 11:31 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT

 

The first question I have is, what do you both have your SORT_DIRECTORY= and 
SORT_BY_DEVICE_ADDRESS= parameters set to, in CONFIG DATADVH or it's minions? 
These may or may not be the issue.

Second, someone mentioned comments taking space in the object directory... My 
impression / hope would be that comments would be stripped from the information 
before building the object directory, since there is no actual purpose for them 
there, and there isn't a convenient tool to take an object directory and turn 
it into a source directory. Are the comments actually left in the object 
directory? If so, MAINT is one of the worst offenders, leaving in the hundreds 
of links that it uses during the installation as comments.

-- 
Robert P. Nix Mayo Foundation  .~. 
RO-OE-5-55  200 First Street SW  /V\ 
507-284-0844   Rochester, MN 55905 / ( ) \   
-^^-^^  
In theory, theory and practice are the same, but Join the story... Ride 
Ural.
in practice, theory and practice are different. 




On 2/11/08 9:07 AM, Colin Allinson [EMAIL PROTECTED] wrote:


I have just been doing some checking because we don't seem to have this problem 
of comments moving around within the directory entry. 

Initially, I thought this was because we use special local procedures that 
interface with DIRMAINT but I just tried some vanilla GET's  REPL's without 
any movement of comments at all. 

I guess this must be some DIRMAINT configuation item that causes the difference 
for us, but I am not sure which. 

Note: Comments DO get repositioned when creating a new directory entry.

Colin Allinson
Technical Manager - VM Systems Support
Operating Systems Services
Amadeus Data Processing GmbH
T: +49 (0)8122 43 4975
F: +49 (0)8122 43 3260
[EMAIL PROTECTED]
www.amadeus.com http://www.amadeus.com/ http://www.amadeus.com/  



IMPORTANT  -  CONFIDENTIALITY  NOTICE  - This e-mail is intended only for the 
use of the individual or entity shown above as addressees . It may contain 
information which is privileged, confidential or otherwise protected from 
disclosure under applicable laws .  If the reader of this transmission is not 
the intended recipient, you are hereby notified that any dissemination, 
printing, distribution, copying, disclosure or the taking of any action in 
reliance on the contents of this information is strictly prohibited.  If you 
have received this transmission in error, please immediately notify us by reply 
e-mail or using the address below and delete the message and any attachments 
from your system . 

Amadeus Data Processing GmbH 
Geschäftsführer: Eberhard Haag 
Sitz der Gesellschaft: Erding 
HR München 48 199 
Berghamer Strasse 6 
85435 Erding 
Germany

Re: How comments treated by DIRMAINT

2008-02-11 Thread Mike Walter

But were one of your original ideas revisited... if the 80-character limit 
to the directory records was eliminated, then comments could be in the 
same line with the actual statement (perhaps with a hex character such as 
'05'x or x'00'x as the field-mark?), then having to remember which related 
records follow a live statement (e.g. MINIOPT), and which precede it 
(the suggested COMMENT), and keeping them in place becomes a moot point.

That way comments just stay right with their pertinent statement.  No 
problems with sorting regardless of what application is dealing with them. 
 And when entering XEDIT ALL commands, the comments appear with the 
displayed statements, rather than being on a hidden line before or after 
the displayed record.  (Personally, MINIOPT has always bugged me).

Granted, the comments can be a little far to the right of an 80-byte wide 
the screen, but XEDIT's SET VERIFY 1 * takes care of that pretty easily.

Removing the 80-byte card restriction (antiquated given that very few 
sites have in-use physical card punches or readers any more) sets the 
stage for many other future directory statement improvements and 
extensions.

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.



Alan Altmark [EMAIL PROTECTED] 

Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
02/11/2008 03:58 PM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: How comments treated by DIRMAINT






On Monday, 02/11/2008 at 09:46 EST, Thomas Kern [EMAIL PROTECTED] 
wrote:
 I like the idea of following the MINIOPT model and extending it to LINK,
 CPU, CRYPTO, SPECIAL, DEDICATE and now the COMMAND(?) statements.
 
 Do you think the CLASS, OPTION and SPOOL statements also require 
comments?

I would limit my model to a single USER comment, and one per device.  That 

means each SPOOL statement could have a COMMENT.

Not COMMAND, since it is neither a user nor a device.

Alan Altmark
z/VM Development
IBM Endicott



 
The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. Emails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by email.

Re: How comments treated by DIRMAINT

2008-02-11 Thread Horlick, Michael

Thanks. I have:

   SORT_DIRECTORY=  NO  | YES 
   SORT_BY_DEVICE_ADDRESS=  NO  | YES 
   SORT_COMMENTS_WITH_STATEMENTS=   NO  | YES

I am going to try to create a scenario where the comments are relocated.

Mike

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Jim Bohnsack
Sent: February 11, 2008 12:23 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT

Michael--You can do a DIRM CMS L CONFIG* DATADVH * (DA.  Mine, and I 
think that this is the standard case, is on the DIRMAINT 11F disk.  Also

I run with SORT_DIRECTORY=  YES, SORT_COMMENTS_WITH_STATEMENTS= YES 
(should not matter because we do not have SYSSAFIN specified, but who 
knows), and SORT_BY_DEVICE_ADDRESS= NO.

I don't have any problem with comments being relocated when I do a DIRM 
GET followed by DIRM REP.  All comments stay where I put them.

Jim

Horlick, Michael wrote:
 This is a multi-part message in MIME format.

 --_=_NextPart_001_01C86CCF.63555168
 Content-Type: text/plain;
   charset=iso-8859-1
 Content-Transfer-Encoding: quoted-printable

 Hi,

 =20

 Is there a command that can tell what these parameters are set to or
do =
 I need to check all the mdisks that DIRMAINT has access to.

 =20

 I started this thread and what we want is simple. For our VSE machines
=
 what we want is WYSIWYG. When I want to do a 'DIRM REPLACE', DIRMAINT
=
 should replace the current source directory entry as given to it if =
 there are no errors in it (how about having an 'ASIS' option?). =20

 =20

 I know sometimes adding a comment for a new minidisk is sometimes =
 preserved in the source and sometimes I'll see the comment somewhere =
 else in the directory entry. If I could find out the logic of how =
 DIRMAINT does the shuffling, maybe I could follow its rule(s) in order
=
 to get the source looking the way I want.  =20

 =20

 Thanks,

 =20

 Mike=20

 =20

 

 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
On =
 Behalf Of RPN01
 Sent: February 11, 2008 11:31 AM
 To: IBMVM@LISTSERV.UARK.EDU
 Subject: Re: How comments treated by DIRMAINT

 =20

 The first question I have is, what do you both have your =
 SORT_DIRECTORY=3D and SORT_BY_DEVICE_ADDRESS=3D parameters set to,
=
 in CONFIG DATADVH or it's minions? These may or may not be the issue.

 Second, someone mentioned comments taking space in the object =
 directory... My impression / hope would be that comments would be =
 stripped from the information before building the object directory, =
 since there is no actual purpose for them there, and there isn't a =
 convenient tool to take an object directory and turn it into a source
=
 directory. Are the comments actually left in the object directory? If
=
 so, MAINT is one of the worst offenders, leaving in the hundreds of =
 links that it uses during the installation as comments.

 --=20
 Robert P. Nix Mayo Foundation  .~.=20
 RO-OE-5-55  200 First Street SW  /V\=20
 507-284-0844   Rochester, MN 55905 / ( ) \  =20
 -^^-^^ =20
 In theory, theory and practice are the same, but Join the
story... =
 Ride Ural.
 in practice, theory and practice are different.=20




 On 2/11/08 9:07 AM, Colin Allinson [EMAIL PROTECTED] wrote:


 I have just been doing some checking because we don't seem to have
this =
 problem of comments moving around within the directory entry.=20

 Initially, I thought this was because we use special local procedures
=
 that interface with DIRMAINT but I just tried some vanilla GET's  =
 REPL's without any movement of comments at all.=20

 I guess this must be some DIRMAINT configuation item that causes the =
 difference for us, but I am not sure which.=20

 Note: Comments DO get repositioned when creating a new directory
entry.

 Colin Allinson
 Technical Manager - VM Systems Support
 Operating Systems Services
 Amadeus Data Processing GmbH
 T: +49 (0)8122 43 4975
 F: +49 (0)8122 43 3260
 [EMAIL PROTECTED]
 www.amadeus.com http://www.amadeus.com/ http://www.amadeus.com/
=20



 IMPORTANT  -  CONFIDENTIALITY  NOTICE  - This e-mail is intended only
=
 for the use of the individual or entity shown above as addressees . It
=
 may contain information which is privileged, confidential or otherwise
=
 protected from disclosure under applicable laws .  If the reader of
this =
 transmission is not the intended recipient, you are hereby notified
that =
 any dissemination, printing, distribution, copying, disclosure or the
=
 taking of any action in reliance on the contents of this information
is =
 strictly prohibited.  If you have received this transmission in error,
=
 please immediately notify us by reply e-mail or using the address
below =
 and delete the message and any attachments from your system .=20

 Amadeus Data Processing GmbH=20
 Gesch

Re: How comments treated by DIRMAINT

2008-02-11 Thread Jim Bohnsack

Michael--You can do a DIRM CMS L CONFIG* DATADVH * (DA.  Mine, and I 
think that this is the standard case, is on the DIRMAINT 11F disk.  Also 
I run with SORT_DIRECTORY=  YES, SORT_COMMENTS_WITH_STATEMENTS= YES 
(should not matter because we do not have SYSSAFIN specified, but who 
knows), and SORT_BY_DEVICE_ADDRESS= NO.


I don't have any problem with comments being relocated when I do a DIRM 
GET followed by DIRM REP.  All comments stay where I put them.


Jim

Horlick, Michael wrote:

This is a multi-part message in MIME format.

--_=_NextPart_001_01C86CCF.63555168
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

=20

Is there a command that can tell what these parameters are set to or do =
I need to check all the mdisks that DIRMAINT has access to.

=20

I started this thread and what we want is simple. For our VSE machines =
what we want is WYSIWYG. When I want to do a 'DIRM REPLACE', DIRMAINT =
should replace the current source directory entry as given to it if =
there are no errors in it (how about having an 'ASIS' option?). =20

=20

I know sometimes adding a comment for a new minidisk is sometimes =
preserved in the source and sometimes I'll see the comment somewhere =
else in the directory entry. If I could find out the logic of how =
DIRMAINT does the shuffling, maybe I could follow its rule(s) in order =
to get the source looking the way I want.  =20

=20

Thanks,

=20

Mike=20

=20



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On =
Behalf Of RPN01
Sent: February 11, 2008 11:31 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT

=20

The first question I have is, what do you both have your =
SORT_DIRECTORY=3D and SORT_BY_DEVICE_ADDRESS=3D parameters set to, =
in CONFIG DATADVH or it's minions? These may or may not be the issue.

Second, someone mentioned comments taking space in the object =
directory... My impression / hope would be that comments would be =
stripped from the information before building the object directory, =
since there is no actual purpose for them there, and there isn't a =
convenient tool to take an object directory and turn it into a source =
directory. Are the comments actually left in the object directory? If =
so, MAINT is one of the worst offenders, leaving in the hundreds of =
links that it uses during the installation as comments.

--=20
Robert P. Nix Mayo Foundation  .~.=20
RO-OE-5-55  200 First Street SW  /V\=20
507-284-0844   Rochester, MN 55905 / ( ) \  =20
-^^-^^ =20
In theory, theory and practice are the same, but Join the story... =
Ride Ural.
in practice, theory and practice are different.=20




On 2/11/08 9:07 AM, Colin Allinson [EMAIL PROTECTED] wrote:


I have just been doing some checking because we don't seem to have this =
problem of comments moving around within the directory entry.=20

Initially, I thought this was because we use special local procedures =
that interface with DIRMAINT but I just tried some vanilla GET's  =
REPL's without any movement of comments at all.=20

I guess this must be some DIRMAINT configuation item that causes the =
difference for us, but I am not sure which.=20

Note: Comments DO get repositioned when creating a new directory entry.

Colin Allinson
Technical Manager - VM Systems Support
Operating Systems Services
Amadeus Data Processing GmbH
T: +49 (0)8122 43 4975
F: +49 (0)8122 43 3260
[EMAIL PROTECTED]
www.amadeus.com http://www.amadeus.com/ http://www.amadeus.com/ =20



IMPORTANT  -  CONFIDENTIALITY  NOTICE  - This e-mail is intended only =
for the use of the individual or entity shown above as addressees . It =
may contain information which is privileged, confidential or otherwise =
protected from disclosure under applicable laws .  If the reader of this =
transmission is not the intended recipient, you are hereby notified that =
any dissemination, printing, distribution, copying, disclosure or the =
taking of any action in reliance on the contents of this information is =
strictly prohibited.  If you have received this transmission in error, =
please immediately notify us by reply e-mail or using the address below =
and delete the message and any attachments from your system .=20

Amadeus Data Processing GmbH=20
Gesch=E4ftsf=FChrer: Eberhard Haag=20
Sitz der Gesellschaft: Erding=20
HR M=FCnchen 48 199=20
Berghamer Strasse 6=20
85435 Erding=20
Germany

=20


--_=_NextPart_001_01C86CCF.63555168
Content-Type: text/html;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

html xmlns:v=3Durn:schemas-microsoft-com:vml =
xmlns:o=3Durn:schemas-microsoft-com:office:office =
xmlns:w=3Durn:schemas-microsoft-com:office:word =
xmlns:st1=3Durn:schemas-microsoft-com:office:smarttags =
xmlns=3Dhttp://www.w3.org/TR/REC-html40;

head
meta http-equiv=3DContent

Re: How comments treated by DIRMAINT

2008-02-11 Thread Colin Allinson

I have just been doing some checking because we don't seem to have this 
problem of comments moving around within the directory entry. 

Initially, I thought this was because we use special local procedures that 
interface with DIRMAINT but I just tried some vanilla GET's  REPL's 
without any movement of comments at all. 

I guess this must be some DIRMAINT configuation item that causes the 
difference for us, but I am not sure which.

Note: Comments DO get repositioned when creating a new directory entry.

Colin Allinson
Technical Manager - VM Systems Support
Operating Systems Services
Amadeus Data Processing GmbH
T: +49 (0)8122 43 4975
F: +49 (0)8122 43 3260
[EMAIL PROTECTED]
www.amadeus.com



IMPORTANT  -  CONFIDENTIALITY  NOTICE  - This e-mail is intended only for 
the use of the individual or entity shown above as addressees . It may 
contain information which is privileged, confidential or otherwise 
protected from disclosure under applicable laws .  If the reader of this 
transmission is not the intended recipient, you are hereby notified that 
any dissemination, printing, distribution, copying, disclosure or the 
taking of any action in reliance on the contents of this information is 
strictly prohibited.  If you have received this transmission in error, 
please immediately notify us by reply e-mail or using the address below 
and delete the message and any attachments from your system . 

Amadeus Data Processing GmbH 
Geschäftsführer: Eberhard Haag 
Sitz der Gesellschaft: Erding 
HR München 48 199 
Berghamer Strasse 6 
85435 Erding 
Germany

Re: How comments treated by DIRMAINT

2008-02-11 Thread RPN01

The first question I have is, what do you both have your ³SORT_DIRECTORY=²
and ³SORT_BY_DEVICE_ADDRESS=² parameters set to, in CONFIG DATADVH or it¹s
minions? These may or may not be the issue.

Second, someone mentioned comments taking space in the object directory...
My impression / hope would be that comments would be stripped from the
information before building the object directory, since there is no actual
purpose for them there, and there isn¹t a convenient tool to take an object
directory and turn it into a source directory. Are the comments actually
left in the object directory? If so, MAINT is one of the worst offenders,
leaving in the hundreds of links that it uses during the installation as
comments.

-- 
Robert P. Nix Mayo Foundation  .~.
RO-OE-5-55  200 First Street SW  /V\
507-284-0844   Rochester, MN 55905  / ( ) \
-^^-^^
In theory, theory and practice are the same, but ³Join the story...
Ride Ural.²
 in practice, theory and practice are different.




On 2/11/08 9:07 AM, Colin Allinson [EMAIL PROTECTED] wrote:

 
 I have just been doing some checking because we don't seem to have this
 problem of comments moving around within the directory entry.
 
 Initially, I thought this was because we use special local procedures that
 interface with DIRMAINT but I just tried some vanilla GET's  REPL's without
 any movement of comments at all.
 
 I guess this must be some DIRMAINT configuation item that causes the
 difference for us, but I am not sure which.
 
 Note: Comments DO get repositioned when creating a new directory entry.
 
 Colin Allinson
 Technical Manager - VM Systems Support
 Operating Systems Services
 Amadeus Data Processing GmbH
 T: +49 (0)8122 43 4975
 F: +49 (0)8122 43 3260
 [EMAIL PROTECTED]
 www.amadeus.com http://www.amadeus.com/
 
 
 
 IMPORTANT  -  CONFIDENTIALITY  NOTICE  - This e-mail is intended only for the
 use of the individual or entity shown above as addressees . It may contain
 information which is privileged, confidential or otherwise protected from
 disclosure under applicable laws .  If the reader of this transmission is not
 the intended recipient, you are hereby notified that any dissemination,
 printing, distribution, copying, disclosure or the taking of any action in
 reliance on the contents of this information is strictly prohibited.  If you
 have received this transmission in error, please immediately notify us by
 reply e-mail or using the address below and delete the message and any
 attachments from your system .
 
 Amadeus Data Processing GmbH
 Geschäftsführer: Eberhard Haag
 Sitz der Gesellschaft: Erding
 HR München 48 199
 Berghamer Strasse 6
 85435 Erding 
 Germany

Re: How comments treated by DIRMAINT

2008-02-11 Thread David Boyes

Umm, not to rain on anyone's parade, here, but something tells me we're
trying to engineer a solution to a problem that might be better solved
elsewhere. 

The problem that we're trying to solve (IMHO) is documenting what goes
where. If you start putting text commentary in the CP object directory,
you start consuming substantial space in a shared resource that has a
fixed size.  Yes, Alan and Co can expand that size, but who hasn't seen
finance weenies using Lotus 1-2-3 as a word processor because that's
what they know? 

If the problem is DIRMAINT mucking around with comment locations,
wouldn't it be simpler to add code to DIRM and the other directory
maintenance tools that recognized a :format on/off meta-comment in the
directory source to tell the tool to leave statements inside the block
ordered as received. Let those tools manage the human text part of the
problem and let CP worry about the virtual machine statements as fast as
possible? 

I think I'm agreeing with Rob's earlier statement: I really don't think
the CP object directory is the right place for this kind of thing, and
there's a bunch more things that I'd rather have Alan  Co work on.

Re: How comments treated by DIRMAINT

2008-02-11 Thread Rob van der Heij

On Feb 11, 2008 10:37 AM, Ivica Brodaric [EMAIL PROTECTED] wrote:

  Another approach we've used in the past is a common file on each
  system disk that lists the purpose and change history (e.g. @WHATSON
  THISDISK).

 But if you format that disk, you lose @WHATWASON THISDISK as well! :-)

I consider that a feature, because the contents of that file may not
be correct when you replace the entire contents. Obviously you could
have an automagic process that scans the disks for this file and and
reports the disks where the file is missing (or pretty old compared to
what's on the disk). The file could also have information about backup
requirements so that you can validate whether your backup selection
has not missed anything.

Keeping the file on the disk itself has the advantage that access to
that file is automatic. The disadvantage is that it may be gone when
you want to restore it, so the automagic process above should harvest
the files and keep a 2nd copy somewhere. That also helps detect
changes in the files.

 I actually have a MDISKMAP COMMENTS file that contains userid, address and
 comments for critical minidisks. That file is then used by my MDISKMAP EXEC
 which can then display comments in the right-most column of the 132-column
 listing. And it uses PIPEs and LOOKUPs extensively.

It depends on the relative size of your world. When other people must
make changes to your inventory, things tend to get ugly. Oh, and if
you use a file in NAMES format, you could even use VMLINK to link the
disks. And you could include SFS directories as well.

Rob

Re: How comments treated by DIRMAINT

2008-02-10 Thread Alan Altmark

On Saturday, 02/09/2008 at 01:15 EST, Ivica Brodaric 
[EMAIL PROTECTED] wrote:
 How about adding COMMENT parameter in MDISKOPT? Or even MDISKC 
statement? Yes, 
 it would reduce vertical readability, but there is not much space in the 
MDISK 
 statement and if you introduce asterisk, semicolon, or any other 
character as a 
 start of comment, you'd have to make sure you don't have any passwords 
that 
 look just like that. And if you use ESM that does password encryption, 
you 
 might have a password that in encrypted form looks like asterisk.

If you're going to propose changes in directory syntax, why not go all the 
way?

1. Add a COMMENT statement that applies to the most-recently encountered 
non-COMMENT statement
2. Compile it into the object directory
3. Provide a way to extract the comment (e.g. QUERY VIRT 190 DETAILS)
4. Eliminate the F 80 requirement.

Alan Altmark
z/VM Development
IBM Endicott

Re: How comments treated by DIRMAINT

2008-02-10 Thread Ivica Brodaric

5. Make the syntax similar to the one in SYSTEM CONFIG6. Integrate it into
SYSTEM CONFIG via INCLUDE and keep the source directory on PARM disks.
7. Define the DRCT space in SYSTEM CONFIG the way warmstart and checkpoint
areas are
8. Provide compile/nocompile option or a checkpointing system that would not
compile the directory at every IPL but would if the system is brought up on
a disaster recovery site.

I could go on. That would be NICE. But that would be quite a sweeping
change. I was arguing for a special comment statement just for MDISK because
I think that is the statement that cries for comment option the most. If I
ever put any comment into the directory, then if it is not to do with the
userid itself (which is already catered for by *) it is most likely to do
with MDISK. I would also like the minidisk comment statement to immediately
precede MDISK, not follow it. Plus your ideas 2 and 3. I would like the
comment to be query-able. I can imagine many situations where it would be
very useful and reassuring.

Ivica Brodaric

On 11/02/2008, Alan Altmark [EMAIL PROTECTED] wrote:

 On Saturday, 02/09/2008 at 01:15 EST, Ivica Brodaric
 [EMAIL PROTECTED] wrote:
  How about adding COMMENT parameter in MDISKOPT? Or even MDISKC
 statement? Yes,
  it would reduce vertical readability, but there is not much space in the
 MDISK
  statement and if you introduce asterisk, semicolon, or any other
 character as a
  start of comment, you'd have to make sure you don't have any passwords
 that
  look just like that. And if you use ESM that does password encryption,
 you
  might have a password that in encrypted form looks like asterisk.

 If you're going to propose changes in directory syntax, why not go all the
 way?

 1. Add a COMMENT statement that applies to the most-recently encountered
 non-COMMENT statement
 2. Compile it into the object directory
 3. Provide a way to extract the comment (e.g. QUERY VIRT 190 DETAILS)
 4. Eliminate the F 80 requirement.

 Alan Altmark
 z/VM Development
 IBM Endicott

Re: How comments treated by DIRMAINT

2008-02-10 Thread Ivica Brodaric


 Then you have never set up guest crypto.  :-)


I no speak English. :-)

Unlike you, I have tended
 to have far more comments on LINKs than on MDISKs, since I care more about
 *why* a user is linking rather than *what* is on the disk.


OK, LINK is crying too, but less so because it has more free space than
MDISK

MINIOPT already established the precedent of a statement that adds
 information to the previous statement.  It was my intent to keep that
 model, but provide a more generally useful function.  Further, I most
 especially didn't want to compromise the syntactical integrity of existing
 statements.


I agree. I suggested preceeding to visually distinguish it from MINIOPT,
but if you want to provide a general COMMENT statement tied to any
preceeding statement, I'm all for it.

As to QUERY MDISK, it could be done of course, but QUERY VIRTUAL has the
 advantage of being able to handle all virtual devices, not just MDISKS.


Again, I'm all for it. I was (maybe naively) going for a minimum effort, and
response to QUERY MDISK has a lot of free space.


Ivica Brodaric

Re: How comments treated by DIRMAINT

2008-02-10 Thread Rob van der Heij

On Feb 11, 2008 6:55 AM, Ivica Brodaric [EMAIL PROTECTED] wrote:

 And maybe extract the comment via QUERY MDISK?

The mistake of having QUERY MDISK USER as a class G command would then
make this even more attractive to those who have no business need to
know...  ;-)

Sorry to spoil the party, but I think implementation of the entire
thing is less trivial than it appears. Such new statements also
require delegation in DIRMAINT. Some people may be authorized to
adjust the comment to their directory statements, but not the actual
statement. And should it change when the statement changes? Old
documentation often is worse than no documentation (But it said *old*
version / Yes, that was before I put the new stuff there)

A popular attempt to documentation has been to move the actual MDISK
statement to another placeholder userid. This is limited, but can be
enough to classify stuff. The more specific the comments, the more
likely they will be out-of-date.
Another approach we've used in the past is a common file on each
system disk that lists the purpose and change history (e.g. @WHATSON
THISDISK). As anything else it requires discipline to keep it valid.
Or if you want, one single disk in the system that has one file per
system disk, named with userid and CUU.
If you have the information in a file or multiple files, it is very
easy to use a lookup stage to annotate some output with this (I do
this also for SFS directories, for example - how about adding comments
there as well).

Obviously with competition in this area, it takes a very long time
before things change in the directory. IMHO that is a good thing. I
have at least a dozen other things I would rather see VM development
do.

-Rob

Re: How comments treated by DIRMAINT

2008-02-09 Thread Ivica Brodaric

How about adding COMMENT parameter in MDISKOPT? Or even MDISKC statement?
Yes, it would reduce vertical readability, but there is not much space in
the MDISK statement and if you introduce asterisk, semicolon, or any other
character as a start of comment, you'd have to make sure you don't have any
passwords that look just like that. And if you use ESM that does password
encryption, you might have a password that in encrypted form looks like
asterisk.
Ivica Brodaric

Re: How comments treated by DIRMAINT

I took DIRMAINT's shuffling for granted and never tried to get rid of
it.  The reason I think is that keeping the comments in place is far
from easy: when using CMDISK for example, DIRMAINT removes user's the
MDISK statement(s), and stores it/them a while in DATAMOVE's entry.
When a copy is done, the new MDISK statement is move to the user's
entry.  I don't say all CMDISKed MDISK statements cannot be inserted
at the old places with some extra REXX logic in DIRMAINT, but it
wouldn't be easy to make it bulletproof.

-- 
Kris Buelens,
IBM Belgium, VM customer support

2008/2/8, Horlick, Michael [EMAIL PROTECTED]:
 Hello Kris,

 I don't have RACF. What is the logic behind the shuffling that is done
 by DIRMAINT regarding comment and MDISK statements?

 Also, is there a command to DIRMAINT that tells you what its' settings
 are (for example, what the SORT_BY_DEVICE_ADDRESS is set at)?

 Thanks,

 Mike

 -Original Message-
 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
 Behalf Of Kris Buelens
 Sent: February 8, 2008 10:06 AM
 To: IBMVM@LISTSERV.UARK.EDU
 Subject: Re: How comments treated by DIRMAINT

 If you are lucky enough to have an ESM like RACF, what means the LINK
 checks are not password based, you can work the way I set things up
 for my client: use the minidisk passwords as descriptive comments.
 Here an extract of MAINT's entry:
MDISK 0490 3390 2362 107 VTERES RR ALL ZVM520 NOV2006
MDISK 0493 3390 1433 167 VTERES RR ALL ZVM520 NOV2006
MDISK 019D 3390 681 146 VTEBKP RR ALL ZVM520 NOV2006
MDISK 049E 3390 2687 190 VTERES RR ALL ZVM520 NOV2006
MDISK 0CF1 3390 587 80 VTERES RR
MDISK 0CF2 3390 408 80 VTEBKP
MDISK 0190 3390 399 107 VTE52R MR ALL ZVM520 AUG2007
MDISK 0193 3390 0001 167 VTE521 MR ALL ZVM520 AUG2007
MDISK 019E 3390 1735 190 VTE521 MR ALL FIXESCA DEC2007
 Side remark:
 As one can see, we set the read password to ALL for these general
 public minidisks.  This way if we'd be forced to IPL without RACF,
 people would still be able to LINK RR without password (but, even
 though I still have a CP nuc without RACF on CF1, we never had to use
 a CP-without-RACF in the 19 years we run with RACF)

  
   We have a situation that has been annoying us for quite awhile now
 with
   regards to DIRMAINT. When we add MDISKs for a user (especially for a
 VSE
   user) we usually add comment statements just before the new MDISK.
 No
   problem, except when we later GET the directory entry the comments
 are
   in the wrong place.
 


 --
 Kris Buelens,
 IBM Belgium, VM customer support

Re: How comments treated by DIRMAINT

2008-02-08 Thread Horlick, Michael

Thanks , I will.

Mike

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of 
Bruce Hayden
Sent: February 7, 2008 11:23 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT

In your CONFIG* DATADVH file for DIRMAINT, do you have
SORT_BY_DEVICE_ADDRESS=YES?  If so, you probably want to change it to
no.  I think the comments are moving when the directory entry is
sorted.  There are some other sorting options that can be specified -
you may want to look at those.

On Feb 7, 2008 11:30 AM, Horlick, Michael [EMAIL PROTECTED] wrote:

 Greetings,

 We have a situation that has been annoying us for quite awhile now with
 regards to DIRMAINT. When we add MDISKs for a user (especially for a VSE
 user) we usually add comment statements just before the new MDISK. No
 problem, except when we later GET the directory entry the comments are in
 the wrong place.

 Example:

 I created a dummy user:

 USER TEST1 X1X2X 32M 128M G
 01300910

INCLUDE CMSSTD
 01300910

LINK RSCS 0191 0192 RR
 01300910

 *  THIS IS A COMMENT

 *  MDISK 0191 3380 1548 3 ST160D MR ALL
 01300910

 When I do a DIRM FOR TEST1 GET, I get back in my reader:

 USER TEST1 X1X2X 32M 128M G
 02071121

INCLUDE CMSSTD
 02071121

 *  THIS IS A COMMENT
 02071121

 *  MDISK 0191 3380 1548 3 ST160D MR ALL
 02071121

LINK RSCS 0191 0192 RR
 02071121

 *DVHOPT LNK0 LOG1 RCM1 SMS0 NPW1 LNGAMENG PWC20080207 CRCæE

 Why and how does DIRMAINT shuffle the directory entry sent to it and is
 there a way to stop it from doing so?

 Thanks,

 Mike

-- 
Bruce Hayden
Linux on System z Advanced Technical Support
Endicott, NY

Re: How comments treated by DIRMAINT

If you are lucky enough to have an ESM like RACF, what means the LINK
checks are not password based, you can work the way I set things up
for my client: use the minidisk passwords as descriptive comments.
Here an extract of MAINT's entry:
   MDISK 0490 3390 2362 107 VTERES RR ALL ZVM520 NOV2006
   MDISK 0493 3390 1433 167 VTERES RR ALL ZVM520 NOV2006
   MDISK 019D 3390 681 146 VTEBKP RR ALL ZVM520 NOV2006
   MDISK 049E 3390 2687 190 VTERES RR ALL ZVM520 NOV2006
   MDISK 0CF1 3390 587 80 VTERES RR
   MDISK 0CF2 3390 408 80 VTEBKP
   MDISK 0190 3390 399 107 VTE52R MR ALL ZVM520 AUG2007
   MDISK 0193 3390 0001 167 VTE521 MR ALL ZVM520 AUG2007
   MDISK 019E 3390 1735 190 VTE521 MR ALL FIXESCA DEC2007
Side remark:
As one can see, we set the read password to ALL for these general
public minidisks.  This way if we'd be forced to IPL without RACF,
people would still be able to LINK RR without password (but, even
though I still have a CP nuc without RACF on CF1, we never had to use
a CP-without-RACF in the 19 years we run with RACF)

 
  We have a situation that has been annoying us for quite awhile now with
  regards to DIRMAINT. When we add MDISKs for a user (especially for a VSE
  user) we usually add comment statements just before the new MDISK. No
  problem, except when we later GET the directory entry the comments are
  in the wrong place.



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: How comments treated by DIRMAINT

2008-02-08 Thread Colin Allinson

I am not sure this is going to help you a lot but we have somewhat side 
stepped this issue.

We have a general purpose SHOWME/ALTER (both are essentially the same 
code) routine that has directory management as one of its functions.

With this routine we don't do a DIRM GET but read the source directory 
directly from DIRMAINT and put it into an XEDIT session for editing.

Dont seem to have too much problems with comments moving (except for new 
users).

Contact me off list if you want a (unsupported) copy of the code.

With best regards / mit den besten Grüßen,

Colin Allinson
Technical Manager - VM Systems Support
Operating Systems Services
Amadeus Data Processing GmbH
T: +49 (0)8122 43 4975
F: +49 (0)8122 43 3260
[EMAIL PROTECTED]
www.amadeus.com



IMPORTANT  -  CONFIDENTIALITY  NOTICE  - This e-mail is intended only for 
the use of the individual or entity shown above as addressees . It may 
contain information which is privileged, confidential or otherwise 
protected from disclosure under applicable laws .  If the reader of this 
transmission is not the intended recipient, you are hereby notified that 
any dissemination, printing, distribution, copying, disclosure or the 
taking of any action in reliance on the contents of this information is 
strictly prohibited.  If you have received this transmission in error, 
please immediately notify us by reply e-mail or using the address below 
and delete the message and any attachments from your system . 

Amadeus Data Processing GmbH 
Geschäftsführer: Eberhard Haag 
Sitz der Gesellschaft: Erding 
HR München 48 199 
Berghamer Strasse 6 
85435 Erding 
Germany

Re: How comments treated by DIRMAINT

2008-02-08 Thread Alan Altmark

On Friday, 02/08/2008 at 10:06 EST, Kris Buelens [EMAIL PROTECTED] 
wrote:
 If you are lucky enough to have an ESM like RACF, what means the LINK
 checks are not password based, you can work the way I set things up
 for my client: use the minidisk passwords as descriptive comments.
 Here an extract of MAINT's entry:
 MDISK 0490 3390 2362 107 VTERES RR ALL ZVM520 NOV2006
 MDISK 0493 3390 1433 167 VTERES RR ALL ZVM520 NOV2006
 MDISK 019D 3390 681 146 VTEBKP RR ALL ZVM520 NOV2006
 MDISK 049E 3390 2687 190 VTERES RR ALL ZVM520 NOV2006
 MDISK 0CF1 3390 587 80 VTERES RR
 MDISK 0CF2 3390 408 80 VTEBKP
 MDISK 0190 3390 399 107 VTE52R MR ALL ZVM520 AUG2007
 MDISK 0193 3390 0001 167 VTE521 MR ALL ZVM520 AUG2007
 MDISK 019E 3390 1735 190 VTE521 MR ALL FIXESCA DEC2007
 Side remark:
 As one can see, we set the read password to ALL for these general
 public minidisks.  This way if we'd be forced to IPL without RACF,
 people would still be able to LINK RR without password (but, even
 though I still have a CP nuc without RACF on CF1, we never had to use
 a CP-without-RACF in the 19 years we run with RACF

Since they are public and you don't require auditing of their access, you 
can add them to RACF's GLBLDSK macro to prevent RACF from protecting or 
auditing read-only access.

Unfortunately your use of the password fields in that way creates a 
security exposure.  If the system does come up without RACF, OR if the 
VMMDISK were deactivated, anyone who knows your naming convention can get 
r/w access.  If, in 19 years, you never had to run without RACF, then I 
think the risk of the security exposure exceeds the risk of a RACF outage 
sufficient to make you run without RACF.

Alan Altmark
z/VM Development
IBM Endicott

Re: How comments treated by DIRMAINT

2008-02-08 Thread Horlick, Michael

Hello Kris,

I don't have RACF. What is the logic behind the shuffling that is done
by DIRMAINT regarding comment and MDISK statements?

Also, is there a command to DIRMAINT that tells you what its' settings
are (for example, what the SORT_BY_DEVICE_ADDRESS is set at)?

Thanks,

Mike 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: February 8, 2008 10:06 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT

If you are lucky enough to have an ESM like RACF, what means the LINK
checks are not password based, you can work the way I set things up
for my client: use the minidisk passwords as descriptive comments.
Here an extract of MAINT's entry:
   MDISK 0490 3390 2362 107 VTERES RR ALL ZVM520 NOV2006
   MDISK 0493 3390 1433 167 VTERES RR ALL ZVM520 NOV2006
   MDISK 019D 3390 681 146 VTEBKP RR ALL ZVM520 NOV2006
   MDISK 049E 3390 2687 190 VTERES RR ALL ZVM520 NOV2006
   MDISK 0CF1 3390 587 80 VTERES RR
   MDISK 0CF2 3390 408 80 VTEBKP
   MDISK 0190 3390 399 107 VTE52R MR ALL ZVM520 AUG2007
   MDISK 0193 3390 0001 167 VTE521 MR ALL ZVM520 AUG2007
   MDISK 019E 3390 1735 190 VTE521 MR ALL FIXESCA DEC2007
Side remark:
As one can see, we set the read password to ALL for these general
public minidisks.  This way if we'd be forced to IPL without RACF,
people would still be able to LINK RR without password (but, even
though I still have a CP nuc without RACF on CF1, we never had to use
a CP-without-RACF in the 19 years we run with RACF)

 
  We have a situation that has been annoying us for quite awhile now
with
  regards to DIRMAINT. When we add MDISKs for a user (especially for a
VSE
  user) we usually add comment statements just before the new MDISK.
No
  problem, except when we later GET the directory entry the comments
are
  in the wrong place.



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: How comments treated by DIRMAINT

2008-02-08 Thread Stracka, James (GTI)

We do this:

*
* CMS 23 disks at 1st Level
*
 MDISK 2390 3390 2184 107 VMRESB RR ALL  CMS23A   190
 MDISK B390 3390 0282 107 VMRESB RR ALL  CMS23B   190
 MDISK 2393 3390 1664 200 VMRESA RR ALL  CMS23193
 MDISK 239D 3390 1864 300 VMRESA RR ALL  CMS2319D
 MDISK 239E 3390 1007 250 VMRESA RR ALL  CMS2319E
 MDISK B39E 3390 3139 200 VMRESB RR ALL  CMS23B   19E

Of course we use the CMS IPLER.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: Friday, February 08, 2008 3:32 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT


These block comments don't solve the problems of deleted minidisks. (I
reverted to that too when we started with DIRMAINT).  Nor do they help
when working like me with two alternating runtime minidisks.  Eg MAINT
190 and 490 have two different CMS levels.  When switching levels
(forward or backout), I swap the addresses in the directory.  I don't
use DDR, address swapping can often be done in flight: old users go one,
new users get the new stuff, impossible with DDR (for CSM I have
different saved segments). With comments on the MDISK card itself, it
also always clear which is which, even if a phone call interrupts your
thoughts in the XEDIT session used to swap the addresses (did or didn't
I swap this one already? In the day preceeding this trick, I often
encountered this in real life and QQUIT was often the only safe way to
go on). Standard example:
  MDISK 0490 3390 2362 107 VTERES RR ALL WMAINT MMAINT
  MDISK 0493 3390 1433 167 VTERES RR ALL  WMAINT MMAINT
  MDISK 019D 3390 681 146 VTEBKP RR ALL  WMAINT MMAINT
  MDISK 049E 3390 2687 190 VTERES RR ALL  WMAINT MMAINT
  MDISK 0190 3390 399 107 VTE52R MR ALL  WMAINT MMAINT
  MDISK 0193 3390 0001 167 VTE521 MR ALL  WMAINT MMAINT
  MDISK 019E 3390 1735 190 VTE521 MR ALL WMAINT MMAINT
When looking at this, you don't know which is the newest copy (the
volsers are different in this case, and might help here, but this is
from my test system, on other systems these CMS minidisks might be all
located on the same volser, a matter of chance/malchance).


2008/2/8, Dale R. Smith [EMAIL PROTECTED]:
 What I have done for this situation is add a block comment to the 
 directory entry before the MDISKs that describes what each MDISK is 
 used

 for.  The comments are not directly associated with a MDISK, so you 
 have

 to maintain the comments and MDISKs separately, (you kinda have to do 
 tha t now).  The advantage of using a comment block is that the 
 descriptions ar e
 all in one place and you don't have to worry about DIRMAINT, (or any
othe
 r
 directory manager), messing with them.  Here is an example from one of
ou
 r
 DB2/VM userids:


*-*
 * CMS Minidisk Layout
*
 * 191 Work Disk and Profile Exec
*
 * 193 DB2/VM Service Disk
*
 * 195 DB2/VM Production Disk
*
 * 200 Directory
*
 * 201 Log Disk 1
*
 * 202-203 Pool  1 - System Catalogs
*
 * 204-205 Pool  2 - Internals
*
 * 206 Pool  3 - QMF and DBEDIT
*
 * 207 Pool  4 - PUBLIC.EXPLAIN
*
 * 208-211 Pool -5 - Non-Recoverable
*
 * 212-219 Pool  6 - Recoverable
*
 * 220-221 Pool -5 - Non-Recoverable
*
 * 222 Pool  3 - QMF and DBEDIT
*
 * 223-224 Pool -5 - Non-Recoverable
*
 * 225-226 Pool  6 - Recoverable
*
 * 227 Log Disk 2
*
 * 228 Pool  3 - QMF AND DBEDIT
*
 * 229 Pool  6 - Recoverable
*
 * 230 Pool  6 - Recoverable
*
 * 231-234 Pool  2 - Internals
*
 *-
 *


 Of course, your comments for VSE MDISKs would be a lot different!  
 :-) Just put in what makes sense to you.  Add a new comment line when

 you add

 a new disk, delete a line when delete a disk.

 --
 Dale R. Smith

 It's just a simple matter of programming.
 - Any boss who has never written a program

 On Fri, 8 Feb 2008 11:12:34 -0500, Horlick, Michael 
 [EMAIL PROTECTED] wrote:

 Hi Kris,
 
 We are only concerned with our VSE guests which have hundreds of 
 minidisks. Normally we just do a DIRM GET, receive the directory 
 entry from our reader, XEDIT the file and add a minidisk or more (or 
 delete
 some) and insert comments here and there. We then do a DIRM REPLACE.
 
 All we want is to have DIRMAINT leave the entry that we XEDITed (and 
 made pretty) alone. No changes so that next time we get it we see it 
 the

 way we originally XEDITed it.
 
 Is that possible and making can you explain what DIRMAINT does on a 
 REPLACE that causes this shuffling?
 
 Thanks,
 
 Mike



-- 
Kris Buelens,
IBM Belgium, VM customer support


This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated

Re: How comments treated by DIRMAINT

These block comments don't solve the problems of deleted minidisks.
(I reverted to that too when we started with DIRMAINT).  Nor do they
help when working like me with two alternating runtime minidisks.  Eg
MAINT 190 and 490 have two different CMS levels.  When switching
levels (forward or backout), I swap the addresses in the directory.  I
don't use DDR, address swapping can often be done in flight: old users
go one, new users get the new stuff, impossible with DDR (for CSM I
have different saved segments).
With comments on the MDISK card itself, it also always clear which is
which, even if a phone call interrupts your thoughts in the XEDIT
session used to swap the addresses (did or didn't I swap this one
already? In the day preceeding this trick, I often encountered this in
real life and QQUIT was often the only safe way to go on).
Standard example:
  MDISK 0490 3390 2362 107 VTERES RR ALL WMAINT MMAINT
  MDISK 0493 3390 1433 167 VTERES RR ALL  WMAINT MMAINT
  MDISK 019D 3390 681 146 VTEBKP RR ALL  WMAINT MMAINT
  MDISK 049E 3390 2687 190 VTERES RR ALL  WMAINT MMAINT
  MDISK 0190 3390 399 107 VTE52R MR ALL  WMAINT MMAINT
  MDISK 0193 3390 0001 167 VTE521 MR ALL  WMAINT MMAINT
  MDISK 019E 3390 1735 190 VTE521 MR ALL WMAINT MMAINT
When looking at this, you don't know which is the newest copy (the
volsers are different in this case, and might help here, but this is
from my test system, on other systems these CMS minidisks might be all
located on the same volser, a matter of chance/malchance).


2008/2/8, Dale R. Smith [EMAIL PROTECTED]:
 What I have done for this situation is add a block comment to the
 directory entry before the MDISKs that describes what each MDISK is used

 for.  The comments are not directly associated with a MDISK, so you have

 to maintain the comments and MDISKs separately, (you kinda have to do tha
 t
 now).  The advantage of using a comment block is that the descriptions ar
 e
 all in one place and you don't have to worry about DIRMAINT, (or any othe
 r
 directory manager), messing with them.  Here is an example from one of ou
 r
 DB2/VM userids:

 *-*
 * CMS Minidisk Layout *
 * 191 Work Disk and Profile Exec  *
 * 193 DB2/VM Service Disk *
 * 195 DB2/VM Production Disk  *
 * 200 Directory   *
 * 201 Log Disk 1  *
 * 202-203 Pool  1 - System Catalogs   *
 * 204-205 Pool  2 - Internals *
 * 206 Pool  3 - QMF and DBEDIT*
 * 207 Pool  4 - PUBLIC.EXPLAIN*
 * 208-211 Pool -5 - Non-Recoverable   *
 * 212-219 Pool  6 - Recoverable   *
 * 220-221 Pool -5 - Non-Recoverable   *
 * 222 Pool  3 - QMF and DBEDIT*
 * 223-224 Pool -5 - Non-Recoverable   *
 * 225-226 Pool  6 - Recoverable   *
 * 227 Log Disk 2  *
 * 228 Pool  3 - QMF AND DBEDIT*
 * 229 Pool  6 - Recoverable   *
 * 230 Pool  6 - Recoverable   *
 * 231-234 Pool  2 - Internals *
 *-*


 Of course, your comments for VSE MDISKs would be a lot different!  :-)
 Just put in what makes sense to you.  Add a new comment line when you add

 a new disk, delete a line when delete a disk.

 --
 Dale R. Smith

 It's just a simple matter of programming.
 - Any boss who has never written a program

 On Fri, 8 Feb 2008 11:12:34 -0500, Horlick, Michael
 [EMAIL PROTECTED] wrote:

 Hi Kris,
 
 We are only concerned with our VSE guests which have hundreds of
 minidisks. Normally we just do a DIRM GET, receive the directory entry
 from our reader, XEDIT the file and add a minidisk or more (or delete
 some) and insert comments here and there. We then do a DIRM REPLACE.
 
 All we want is to have DIRMAINT leave the entry that we XEDITed (and
 made pretty) alone. No changes so that next time we get it we see it the

 way we originally XEDITed it.
 
 Is that possible and making can you explain what DIRMAINT does on a
 REPLACE that causes this shuffling?
 
 Thanks,
 
 Mike



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: How comments treated by DIRMAINT

2008-02-08 Thread Dale R. Smith

What I have done for this situation is add a block comment to the 
directory entry before the MDISKs that describes what each MDISK is used 

for.  The comments are not directly associated with a MDISK, so you have 

to maintain the comments and MDISKs separately, (you kinda have to do tha
t 
now).  The advantage of using a comment block is that the descriptions ar
e 
all in one place and you don't have to worry about DIRMAINT, (or any othe
r 
directory manager), messing with them.  Here is an example from one of ou
r 
DB2/VM userids:

*-*
* CMS Minidisk Layout *
* 191 Work Disk and Profile Exec  *
* 193 DB2/VM Service Disk *
* 195 DB2/VM Production Disk  *
* 200 Directory   *
* 201 Log Disk 1  *
* 202-203 Pool  1 - System Catalogs   *
* 204-205 Pool  2 - Internals *
* 206 Pool  3 - QMF and DBEDIT*
* 207 Pool  4 - PUBLIC.EXPLAIN*
* 208-211 Pool -5 - Non-Recoverable   *
* 212-219 Pool  6 - Recoverable   *
* 220-221 Pool -5 - Non-Recoverable   *
* 222 Pool  3 - QMF and DBEDIT*
* 223-224 Pool -5 - Non-Recoverable   *
* 225-226 Pool  6 - Recoverable   *
* 227 Log Disk 2  *
* 228 Pool  3 - QMF AND DBEDIT*
* 229 Pool  6 - Recoverable   *
* 230 Pool  6 - Recoverable   *
* 231-234 Pool  2 - Internals *
*-* 


Of course, your comments for VSE MDISKs would be a lot different!  :-)
Just put in what makes sense to you.  Add a new comment line when you add
 
a new disk, delete a line when delete a disk.

-- 
Dale R. Smith

It's just a simple matter of programming.
- Any boss who has never written a program 

On Fri, 8 Feb 2008 11:12:34 -0500, Horlick, Michael 
[EMAIL PROTECTED] wrote:

Hi Kris,

We are only concerned with our VSE guests which have hundreds of
minidisks. Normally we just do a DIRM GET, receive the directory entry
from our reader, XEDIT the file and add a minidisk or more (or delete
some) and insert comments here and there. We then do a DIRM REPLACE. 

All we want is to have DIRMAINT leave the entry that we XEDITed (and
made pretty) alone. No changes so that next time we get it we see it the

way we originally XEDITed it.

Is that possible and making can you explain what DIRMAINT does on a
REPLACE that causes this shuffling?

Thanks,

Mike

Re: How comments treated by DIRMAINT

2008-02-08 Thread Brian Nielsen

On Fri, 8 Feb 2008 10:08:01 -0600, Brian Nielsen [EMAIL PROTECTED]
 
wrote:

A simpler approach is just to include in the comment what MDISK it 
applies 
to.  The comment no longer needs to be next to the MDISK statement.  Now
 
you're covered for all cases except transfering the MDISK to another 
userid.

Brian Nielsen

Another case not covered is deleting the MDISK.

Brian Nielsen

Re: How comments treated by DIRMAINT

2008-02-08 Thread Horlick, Michael

Hi Kris,

We are only concerned with our VSE guests which have hundreds of
minidisks. Normally we just do a DIRM GET, receive the directory entry
from our reader, XEDIT the file and add a minidisk or more (or delete
some) and insert comments here and there. We then do a DIRM REPLACE. 

All we want is to have DIRMAINT leave the entry that we XEDITed (and
made pretty) alone. No changes so that next time we get it we see it the
way we originally XEDITed it.

Is that possible and making can you explain what DIRMAINT does on a
REPLACE that causes this shuffling?

Thanks,

Mike  
 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: February 8, 2008 10:38 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT

I took DIRMAINT's shuffling for granted and never tried to get rid of
it.  The reason I think is that keeping the comments in place is far
from easy: when using CMDISK for example, DIRMAINT removes user's the
MDISK statement(s), and stores it/them a while in DATAMOVE's entry.
When a copy is done, the new MDISK statement is move to the user's
entry.  I don't say all CMDISKed MDISK statements cannot be inserted
at the old places with some extra REXX logic in DIRMAINT, but it
wouldn't be easy to make it bulletproof.

-- 
Kris Buelens,
IBM Belgium, VM customer support

2008/2/8, Horlick, Michael [EMAIL PROTECTED]:
 Hello Kris,

 I don't have RACF. What is the logic behind the shuffling that is done
 by DIRMAINT regarding comment and MDISK statements?

 Also, is there a command to DIRMAINT that tells you what its' settings
 are (for example, what the SORT_BY_DEVICE_ADDRESS is set at)?

 Thanks,

 Mike

 -Original Message-
 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
On
 Behalf Of Kris Buelens
 Sent: February 8, 2008 10:06 AM
 To: IBMVM@LISTSERV.UARK.EDU
 Subject: Re: How comments treated by DIRMAINT

 If you are lucky enough to have an ESM like RACF, what means the LINK
 checks are not password based, you can work the way I set things up
 for my client: use the minidisk passwords as descriptive comments.
 Here an extract of MAINT's entry:
MDISK 0490 3390 2362 107 VTERES RR ALL ZVM520 NOV2006
MDISK 0493 3390 1433 167 VTERES RR ALL ZVM520 NOV2006
MDISK 019D 3390 681 146 VTEBKP RR ALL ZVM520 NOV2006
MDISK 049E 3390 2687 190 VTERES RR ALL ZVM520 NOV2006
MDISK 0CF1 3390 587 80 VTERES RR
MDISK 0CF2 3390 408 80 VTEBKP
MDISK 0190 3390 399 107 VTE52R MR ALL ZVM520 AUG2007
MDISK 0193 3390 0001 167 VTE521 MR ALL ZVM520 AUG2007
MDISK 019E 3390 1735 190 VTE521 MR ALL FIXESCA DEC2007
 Side remark:
 As one can see, we set the read password to ALL for these general
 public minidisks.  This way if we'd be forced to IPL without RACF,
 people would still be able to LINK RR without password (but, even
 though I still have a CP nuc without RACF on CF1, we never had to use
 a CP-without-RACF in the 19 years we run with RACF)

  
   We have a situation that has been annoying us for quite awhile now
 with
   regards to DIRMAINT. When we add MDISKs for a user (especially for
a
 VSE
   user) we usually add comment statements just before the new MDISK.
 No
   problem, except when we later GET the directory entry the comments
 are
   in the wrong place.
 


 --
 Kris Buelens,
 IBM Belgium, VM customer support

Re: How comments treated by DIRMAINT