| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1593.1 | Some hints | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Thu Oct 03 1991 15:23 | 79 |
| RE: .0
Very good questions!
> If an AM was developed on DECmcc/VMS v1.1 platform,
>
> (1) Will it be portable (maybe with minor change, and if so please
> advise what are they) to V1.2? Is recompile required?
I think there are some small changes you'll have to make. Some new
include files for CMA(?) - things like that.
> (2) Will it be portable to DECmcc/Ultrix V1.2? I presume recompile is
> required in this case?
I doubt that it will *directly* portable to Ultrix without code
changes. (and yes,the source must be recompiled on Ultrix)
<< Type Casting >>
The most common change will be 'type casting'. The VMS C compiler is
real relaxed about assigning pointer variables of different types -
whereas the Ultrix compiler will require the type-casts.
<< O/S specific operations >>
If you perform and O/S specific operations (QIOW), you must break
these routines out into a VMS version and an Ultrix version. The
Sample AM will show how this is done.
<< Include Files >>
You must remove directory paths from your include files. The directory
information is obtained through the 'CC' command line:
VMS /Include
Ultrix -i
<< Build procedure >>
You will require a MAKE file for building your Management Module. You
can copy the files provided by the DECmcc Toolkit.
<< #ifdef / #endif >>
Non-portable operations may require ifdef/endif compiler directives for
things that are VMS or Ultrix specific. I recommend using macros
defined within the ifdefs, then used in the body of your code. This
makes the code easier to read, and puts the conditional stuff in a
minimum of include files:
/* -----------------------------------------------------------------
* Macro: _GLOBALDEF
* Macro: _GLOBALREF
*
* Used to declare global / extern variables
*
* For VMS, the globaldef & globalref are used because they
* are more memory efficient -- also, this macro ensures
* that the global data is 'noshare', which is manditory if you
* are building a shared image library (like a management module)
*
*/
#ifdef unix
#define _GLOBALREF extern
#define _GLOBALDEF
#else
#define _GLOBALDEF noshare globaldef
#define _GLOBALREF globalref
#endif
|
| 1593.2 | Take a look at the NAS Guide to Developing Portable Software | HVDSQR::HERRLICH | Alan, DTN 223-4408, TSGDEV::HERRLICH | Thu Oct 03 1991 17:21 | 6 |
| I'm just designing my AM and found lots of guidelines that I will be following.
The guide mentions all the things mentioned in RE: .1 and others. Even gives
some suggestions about how to get around problems and which version of C to
use.
- Alan
|
| 1593.3 | Other minor changes. | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Thu Oct 03 1991 18:35 | 27 |
| RE .-1 and base note
>> If an AM was developed on DECmcc/VMS v1.1 platform,
>>
>> (1) Will it be portable (maybe with minor change, and if so please
>> advise what are they) to V1.2? Is recompile required?
>
> I think there are some small changes you'll have to make. Some new
> include files for CMA(?) - things like that.
Others I can think of...
1. Recompile is required.
2. Threads environment is pre-emptive for V1.2, meaning you'll have
to add mcc_mutex calls (documented in the SRM very soon) around
common data structures (caches, etc)
3. mcc_ea routine interfaces have changed (see *V1.1* Release Notes
for details). only affects users of ethernet access routines...
4. msl translator has changed. .ms files may have to be "tweaked"
to accomodate tighter rules.
5. mcc_thread_create() has been replaced by mcc_thread_create2().
only affects MM's that use threads.
6. others (to be documented in the TOOLKIT Release Notes)...
Minor changes, really.
Chris
|
| 1593.4 | | COOKIE::KITTELL | Richard - Architected Info Mgmt | Mon Oct 07 1991 11:52 | 5 |
| RE: .2
Can you post a pointer to NAS Guide to Developing Portable Software?
Thanks.
|
| 1593.5 | recompile/link may just do it. | TOOK::CALLANDER | MCC = My Constant Companion | Thu Oct 17 1991 19:18 | 4 |
| Just to keep the optimism up, some of the v1.1 mcc modules DID simply
require a recompile/link to work under ultrix. Those modules were designed
with the portability guidelines in mind (and used kernel services for
anything non portable!).
|
| 1593.6 | Which ones? | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Tue Oct 22 1991 10:27 | 6 |
| > some of the v1.1 mcc modules DID simply
> require a recompile/link to work under ultrix.
That's excellent!
Which ones?
|
| 1593.7 | notif went vms to ultrix comp/link only | TOOK::CALLANDER | MCC = My Constant Companion | Wed Nov 06 1991 16:28 | 7 |
| the original notification fm worked with a simple recompile/relink.
Mind you notification fm was a new module in v1.1 and was coded using
the ultrix coding guidelines. This made for the easier port. For v1.2
we are rewriting the notification FM (for a lot of reasons; all having
to do with changed requirements on the module), and so far we have no
difference between the ultrix and vms versions.
|