Re: How comments treated by DIRMAINTThere is actually a tool that does a fair
job of recreating the source directory from the object directory. It actually
won't put PROFILEs back in, or INCLUDEs, or comments, but can put all object
parts back to their source equivalents. The DIRENT tool (in t
:[EMAIL PROTECTED] On
> Behalf Of Alan Altmark
> Sent: February 15, 2008 10:29 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: How comments treated by DIRMAINT
>
> On Friday, 02/15/2008 at 10:10 EST, "Horlick, Michael"
> <[EMAIL PROTECTED]> wrote:
>
> >
alf Of Alan Altmark
> Sent: February 15, 2008 10:29 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: How comments treated by DIRMAINT
>
> On Friday, 02/15/2008 at 10:10 EST, "Horlick, Michael"
> <[EMAIL PROTECTED]> wrote:
>
> > The line ?LINK QALPCS 0500
Ok, will do.
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: February 15, 2008 10:29 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How comments treated by DIRMAINT
On Friday, 02/15/2008 at 10:10 EST, "Horlick, Mi
On Friday, 02/15/2008 at 10:10 EST, "Horlick, Michael"
<[EMAIL PROTECTED]> wrote:
> The line ?LINK QALPCS 0500 0500 MW? has been shuffled after the comment
line
> ?* 360 - ZYZMGH (Master Catalog, Power, Hardcopy,Recorder,etc...)?
>
> So what?s the secret here?
I would suggest opening a PMR
Greetings,
Hopefully you can see the attachments. I created a user, got its
directory entry from DIRMAINT, saw that it was shuffled a bit, put in
back in the way I wanted (see ESAMGH BEFORE) and did a DIRM REPLACE
followed by DIRM GET NOLOCK. Did a RECEIVE as ESAMGH AFTER. These are
the actual
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 thin
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 ag
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 reco
lone 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"
02/12/2008 10:59 AM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LIS
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 h
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
Inform
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. Hav
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
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.
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.
>
> 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 l
e respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: How comments treated by DIRMAINT
On Feb 12, 2008, at 1:07 PM, Ivica Brodaric wrote:
On 13/02/2008, Huegel, Thomas <[EMAIL PROTECTED]> wrote:
I am amazed that so many people here still us
On Feb 12, 2008, at 1:07 PM, Ivica Brodaric wrote:
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?
-4.5 right, -6 left.
Adam
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 T
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?
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
>
> 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.
>
I never said that label should be dropped.
It keeps from having to create a Windows Registry to record identifying
> i
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 b
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?"
>
> 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 th
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
> &
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 li
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
> 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
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
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
:[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
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
c
--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
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 ev
represent the opinions or policies of Hewitt Associates.floor? ;-)
"Schuh, Richard" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System"
02/12/2008 10:59 AM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
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!
ating System"
02/11/2008 08:30 PM
Please respond to
"The IBM z/VM Operating System"
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 r
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
Sourc
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 r
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 extensi
System"
02/11/2008 03:58 PM
Please respond to
"The IBM z/VM Operating System"
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
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?
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
t. =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
] 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&
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
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 move
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,
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
?
/Tom Kern
On Mon, 11 Feb 2008 01:26:14 -0500, Alan Altmark <[EMAIL PROTECTED]
>
>
>
> > > 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 o
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! :-
>
> Such new statements also
> require delegation in DIRMAINT.
Both DIRMAINT and VM:Secure cater for MINIOPT. Why not expand on that?
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
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, b
>
> 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
On Sunday, 02/10/2008 at 11:45 EST, Ivica Brodaric
<[EMAIL PROTECTED]> wrote:
> 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.
Then you have never set up guest crypto. :-) Unlike you, I have tended
And maybe extract the comment via QUERY MDISK?
On 11/02/2008, Ivica Brodaric <[EMAIL PROTECTED]> wrote:
>
> 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 CONFI
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 w
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
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
ssed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
"Kris Buelens" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System"
02/08/2008 11:42 AM
Please respond to
"The IBM z/VM Operating System"
@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 hav
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)
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).
I somewhat agree with you Alan (and these minidisks are indeed already
in the HCPRww so that CP doesn't even consult RACF for a RR link.
As for these passwords: there is no real convention thet the passwords
msut be "mon", they can be anything that explains the
content/level. It would be more s
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 e
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 rea
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 anot
m: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] O
n
>> 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
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 dir
tings
> 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@LISTSER
nks,
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
chec
Kris Buelens <[EMAIL PROTECTED]> wrote :-
> 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 wit
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
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
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
Not that I know. If you have a comment line about a minidisk in from of a
MDISK statement, then if you move or change a minidisk allocation using
DATAMOVE, DIRMAINT will insert a new MDISK statement not following your
visual connection with the comment line, so don't use that technique.
On 08/02/2
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
79 matches
Mail list logo
