[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

4323.0. "How do I enter rel times > 9999 days?" by MOONEY::BEAN (Wing nut.) Wed Dec 30 1992 11:58

Our application (media management) needs relative times > 9999 days.
Don't laugh - 27 years is not that long in storage management time;
we have media to manage that were written in the 50s.

Other notes in this conference have led me to believe that the improved
MCC time routines should be able to handle BinRelTimes in the thousands of
years. But I have been having trouble trying to enter such times through
the command line and forms interfaces.

For some values >9999 days I get errors, for others the value parsed appears
to just get mangled:

> MCC> set persistence time = 9999-00
>
> Node LOCAL_NS:.plow MediaLibrary LOCAL_NS:.mlm_v1_media_library
> AT 29-DEC-1992 16:47:57 Characteristics
>
> Modification(s) completed successfully
>                       Persistence Time = 9999 00:00:00.00

Above value seems ok, as do all values below 9999 days that I have tried.

> MCC> set persistence time = 19999-00
> 
> Node LOCAL_NS:.plow MediaLibrary LOCAL_NS:.mlm_v1_media_library
> AT 29-DEC-1992 17:00:49 Characteristics
> 
> Modification(s) completed successfully
>                       Persistence Time =
> %MCC-E-BIN_REL_TIM_ERR, error in Binary Relative Time value

Attempts to go bigger are refused. Logical if the input routines impose a
4 digit limit.

> MCC> set persistence time = 99999-00
> 
> Node LOCAL_NS:.plow MediaLibrary LOCAL_NS:.mlm_v1_media_library
> AT 29-DEC-1992 16:47:24 Characteristics
> 
> Modification(s) completed successfully
>                       Persistence Time = 578 00:00:00.00

While attempts to go bigger still give bogus results. Not logical if the
input routines impose a 4 digit limit.

Other replies in the conference have implied that the user can "choose" to use
DTS time parsing routines rather than VMS routines. Although I find discussion
of the two formats (VMS and DTS) in the documentation, I can't find how a user
makes a "choice" (other than through the form of the time entered).

So what have I missed? How do I manipulate relative times > 9999 days?

Thanks,
Bob

T.R	Title	User	Personal Name	Date	Lines
4323.1	Use the ISO format	TOOK::T_HUPPER	The rest, as they say, is history.	`Wed Dec 30 1992 13:20`	16
	RE .1: The ISO format (DTS) will handle the relative times that you need. At least 7 digits worth of days can be entered. The VMS times can only deal with the 4 digits worth of days. Sorry. To select the ISO format: $ define MCC_TIME_IN_MODE 2 $ define MCC_TIME_OUT_MODE 2 $ manage/enterprise This gives you the ISO format for both input and output times. The absolute time is expressed as your local time, not GMT. Ted
4323.2		MOONEY::BEAN	Wing nut.	`Wed Dec 30 1992 15:43`	4
	Re: .-1 Thanks Ted. That was the pointer I needed.
4323.3	Oh no, not another logical name	BLUMON::SYLOR	Architect = Buzzword Generator	`Mon Jan 04 1993 22:51`	16
	Re .1: Ted, MCC should never use a logical name as a means of controlling something like the time format used. It should instead define an attribute of the appropriate MCC entity which is setable, and controls this function. Mount soapbox It is difficult to try and convince other groups that they should make their software manageable using MCC when MCC can't manage itself using its own management techniques. Logical names and config files are outmoded techniques that can't be managed remotely. Physician, heal thyself. Mark
4323.4	We know, we know	TOOK::GUERTIN	MCC Managing everything for everyone everywhere	`Tue Jan 05 1993 06:44`	19
	Mark, No person fought harder than myself to make these attributes real attributes. But these things tend to get added at the end of the schedule. And making them attributes would require something more important to be dropped (yes, there are more important things, would you mind if MCC had lower quality?, performed two times slower? you get the picture). At least the user has something, the other possibility was not to provide the user with any way of modifying the characteristic. These attributes are slated to become real attributes as part of Distribution. It is a requirement for Distributed MCC Directors to be remotely manageable. -Matt. (ps, Which is the better physican: One who does a good job at healing himself, and a mediocre job at healing others; or, one that does a mediocre job at healing himself, but does a good job at healing others?).
4323.5	We're working on it	TOOK::T_HUPPER	The rest, as they say, is history.	`Wed Jan 06 1993 12:59`	14
	RE .3: Thank you for the preaching. When the V1.2 Ultrix execution model broke the concept of an MCC entity, we had no place to hang the attributes of an MCC entity. As Matt pointed out, this will be fixed for Distribution. Just because many aspects of DECmcc have been ugly does not mean that we wanted them to be that way. We have been correcting uglinesses as fast as we can, but we haven't had the time to remold DECmcc into the perfectly architected product yet. Customers keep demanding DECmccs that are better than the last one, and SOON. Ted