From: hoffman@xdelta.zko.dec.nospam Sent: Friday, July 14, 2000 9:28 AM To: Info-VAX@Mvb.Saic.Com Subject: Re: VMS 7.3 wish list In article <396E9CE7.E27924A5@tsoft-inc.com>, David A Froble writes: :"Doug W." wrote: :> :> ...With VMS 7.3 under development, perhaps now is a good time :> to make requests... Perhaps not... Well, not for V7.3... :With the first field test of VMS V7.3 due soon (I believe), it's a bit :late for that version. The contents of OpenVMS V7.3 were effectively frozen quite some time ago. In addition to V7.3, we are now well along on the development for a maintenance update and a functional release (probably V7.3-1 and V7.4, respectively), as well as a rather large side-release (probably V7.2-6C1). Various other hardware-related work, as well as UPDATE-related ECO work, as well as circa-V7.4 (or post-V7.4) advanced development work is also underway. The V7.3 EFT1/SDK1 kits shipped out of engineering last month, and is presently in the manufacturing and distribution process -- I know of customer sites with copies of V7.3 EFT1. : Maybe requests for V7.4 would be appropriate at this time. Ayup, that would be a more appropriate target. -- Interesting suggestions. Thanks! As for the discussion of mailboxes, please take a look at IntraCluster Communications services (ICC) or at the other available communications mechanisms present in OpenVMS systems. As for having smaller messages snarl mailbox traffic when mixed with larger messages, why not simply use mailbox pairs for differing sizes of messages? As for the time-related stuff, take a look at the cycle counters (rpcc and rscc). We can't change the magnitude of the time without breaking applications -- we could probably change the frequency of which the time is updated on OpenVMS Alpha, the "clunks" are now fairly large values. As for the processor affinity stuff, that's an interesting idea. There is a wholely new system service for gathering performance information in V7.3 -- this new sys$getrmi interface replaces the undocumented and unsupported exe$getspi interface used underneath MONITOR. If that does not meet your requirements, that would be the API that would likely be extended. I've seen a couple of very nice home-grown monitor utilities, and have asked for one of the nicest I've seen (an Austrian customer) for the next OpenVMS Freeware -- the MONITOR utility itself is targeted for a rewrite for several reasons, but I don't off-hand know the schedule. Alpha code relocation and fix-up has some interesting implications. That said, there are exec entry points for various of the common operations such as reading and writing the address space of another process. Also, once I started looking at this, I typically prefer to use a pseudo device driver or an execlet -- rather than relocating my own code. Various VAX systems have specific requirements around i-cache flushing when writing to the i-stream, and Alpha systems definitely have a similar requirement around i-cache synchronization. Ask The Wizard topic 2681 has details of some of this Alpha memory management and caching magic. Ruth Goldenberg might be amenable to adding a description of the steps necessary for Alpha code relocation in some future version of the IDSM as this information is already present in the IDSM -- but not in cookbook fashion. I am not familiar with the referenced Intel IOMETER widget, and I don't immediately have the cycles to do a comparision and to then suggest options and alternatives. Various I/O tools are available. An example of locating the parts of the code for use for use in $lkwset or $lckpag was posted recently. I'll repost it below. Alternatively, you might consider writing up a few of these widgets, and submitting them... (The next release where most of (any of?) these new features suggestions might be added would be in V7.4, at the earliest.) --------------------------- pure personal opinion --------------------------- Hoff (Stephen) Hoffman OpenVMS Engineering hoffman#xdelta.zko.dec.com -- $ $ CC /OBJECT=TEST /list=test /machine SYS$INPUT: #pragma module test_code "v1.0" /* // Define the references to the linkage and code psects */ #pragma extern_model save #pragma extern_model strict_refdef "$$C$LINKAGE_BEGIN" noshr void *__linkage_begin ; #pragma extern_model restore #pragma extern_model save #pragma extern_model strict_refdef "__C$LINKAGE_END" noshr void *__linkage_end ; #pragma extern_model restore #pragma extern_model save #pragma extern_model strict_refdef "$$C$CODE_BEGIN" shr void *__code_begin ; #pragma extern_model restore #pragma extern_model save #pragma extern_model strict_refdef "__C$CODE_END" shr void *__code_end ; #pragma extern_model restore #include void test_routine() { printf("Test Routine") ; } main(void) { int *lp; printf("The addresses of the linkage section are:\n"); printf(" begin: %08p end: %08p\n", &__linkage_begin, &__linkage_end); printf("The addresses of the code section are:\n"); printf(" begin: %08p end: %08p\n", &__code_begin, &__code_end); printf("The address of main(linkage) is: %08p\n", main); printf("The address of test_routine(linkage) is %08p\n", test_routine); lp = (int*) &main; printf("The address of main(code) is: %08p\n", (void *) lp[2] ); lp = (int*) &test_routine ; printf("The address of test_routine(code) is %08p\n", (void *) lp[2] ) ; return 1; } $ $ LINK /MAP=TEST_CODE /CROSS/FULL/EXE=TEST_CODE TEST - + SYS$INPUT:/OPT ! ! Match code and linkage section psect attributes ! psect= $$C$CODE_BEGIN,PIC,CON,REL,LCL, SHR, EXE,NOWRT,NOVEC, MOD psect= __C$CODE_END,PIC,CON,REL,LCL, SHR, EXE,NOWRT,NOVEC, MOD psect=$$C$LINKAGE_BEGIN,NOPIC,CON,REL,LCL,NOSHR,NOEXE,NOWRT,NOVEC,MOD psect=__C$LINKAGE_END,NOPIC,CON,REL,LCL,NOSHR,NOEXE,NOWRT,NOVEC,MOD $ $ $ RUN TEST_CODE ..