Conference azur::mcc

I have more details about the export problem now. 

When export commands are issued , you get the message "Background exporting 
process is not set up" . But it is !




$ show entry/full 28
  Entry  Jobname         Username     Blocks  Status
  -----  -------         --------     ------  ------
     28  MCC_EXPORTER_BACKGROUND
                         SYSTEM               Executing
         On available batch queue HGDM00_MCC$BATCH
         Submitted  5-JAN-1995 11:00
         /PARAM=("SYS$COMMON:[SYSMGR]:MCC_EXPORT.RDB") /PRIORITY=100
         /RESTART=HGDM00_MCC$BATCH



$ dir/sec MCC_EXPORT.RDB

Directory SYS$COMMON:[SYSMGR]

MCC_EXPORT.RDB;1     [SYSTEM]              (RWED,R,,)



MCC> show export node .generation.head_office.hgdr01 FDDI Station f621-8-0

Node QECGENERATION:.generation.head_office.hgdr01 FDDI Station f621-8-0
AT  5-JAN-1995 11:11:53

No exporting for the specified entity

MCC> export node .generation.head_office.hgdr01 fddi station f621-8-0 -
_MCC>   export target = sys$login:mcc_export.rdb, export period = 0:30:00

Node QECGENERATION:.generation.head_office.hgdr01 FDDI Station f621-8-0
AT  5-JAN-1995 11:12:34

Background exporting process is not set up



There are no errors in the MCC_EXPORTER_BACKGROUND.LOG file. 
The file SYS$COMMON:[SYSMGR]:MCC_EXPORT.RDB exist.

I am greatful for any suggestions

andrew

As far as DECmcc V1.4 is concerned, you must have Phase IV compatible addresses.
The reaseon is simple: all the code is written using transparent or nontransparent
task-to-task. In the NCB a six-character nodename and optional username - password
pair are used to set up the connection. Phase V has a totally different mechanism
of setting up connections.

Some things will work properly: e.g. some pieces of the SNMP AM, because those only 
use sockets as supplied by UCX. Some pieces will behave very strange, e.g. TSAM, 
because phase IV nodenames and addresses are used in many different ways.

Conclusion: your customer runs on an unsupported configuration. If on to your customer
is using DECmcc V1.3 and OpenVMS V6.1 it is once again unsupported.


Hope: migration to full Phase V is planned, but the work has not yet been started.


The bottom line: if you are really upset about this, use the IPMT procedure to get an
official answer.

Dirk

Hi,

$ show entry/full 28
  Entry  Jobname         Username     Blocks  Status
  -----  -------         --------     ------  ------
     28  MCC_EXPORTER_BACKGROUND
                         SYSTEM               Executing
         On available batch queue HGDM00_MCC$BATCH
         Submitted  5-JAN-1995 11:00
>>>>         /PARAM=("SYS$COMMON:[SYSMGR]:MCC_EXPORT.RDB") /PRIORITY=100
         /RESTART=HGDM00_MCC$BATCH


    MCC> export node .generation.head_office.hgdr01 fddi station f621-8-0 -
>>>>_MCC>   export target = sys$login:mcc_export.rdb, export period = 0:30:00

Try to have the same directory specification in the lines show by >>>>.

The background must have the same string than the export request. If it is not
the case : no match.

Try something with full specification like "DISK1:[WORK.EXPORT]MCC_EXPORT.RDB".

Hope this helps,

Benoit

I used full specification of the rdb file in the submiting the batch job as well
as the export command. Still the same problem.

Any more suggestions ?
 

$       submit/queue=hgdm00_mcc$batch/restart -
                /parameter=(dsa0:[sys0.syscommon.sysmgr]::mcc_export.rdb) -
                sys$manager:mcc_exporter_background.com

$ show entry/full 149
  Entry  Jobname         Username     Blocks  Status
  -----  -------         --------     ------  ------
    149  MCC_EXPORTER_BACKGROUND
                         SYSTEM               Executing
         On available batch queue HGDM00_MCC$BATCH
         Submitted  6-JAN-1995 08:54
         /PARAM=("DSA0:[SYS0.SYSCOMMON.SYSMGR]::MCC_EXPORT.RDB") /PRIORITY=100
         /RESTART=HGDM00_MCC$BATCH
         File: _DSA0:[VMS$COMMON.SYSMGR]MCC_EXPORTER_BACKGROUND.COM;2


MCC> export node .generation.head_office.hgdr01 fddi station f621-8-0 -
_MCC>   export target = dsa0:[sys0.syscommon.sysmgr]:mcc_export.rdb, -
_MCC>   export period = 0:30:00

Node QECGENERATION:.generation.head_office.hgdr01 FDDI Station f621-8-0
AT  6-JAN-1995 08:57:19

Background exporting process is not set up

>> As far as DECmcc V1.4 is concerned, you must have Phase IV compatible addresses. 
>> The reaseon is simple: all the code is written using transparent or nontranspare
>> task-to-task. In the NCB a six-character nodename and optional username - passwo
>> pair are used to set up the connection. Phase V has a totally different mechanis
>> of setting up connections.

Now I understand nooothing!

Isn't DECmcc PHASEV compatible? What is the PhaseV AM there for? Or do you mean
that the specific EXPORT function is not handled on a DECmcc station running 
PhaseV?  PhaseV AM has been there for years!

Bj�rn Olav Haugom

The Phase IV NCB (network control block) looks like

   NODE"username password"::"TASK=NML"\0...

which means a STRING, totally readable up until the place where I put \0, because that is tha place
where DECnet fills in the link id and where you can specify up to 16 "user data bytes". 
Totally readable means that the SYS$QIO call uses the address of a (descriptor to) the string as is.

The PHASE V NCB is a tag-length-value encoded structure, as such not at all a string,
containing a awfull lot more (or sometimes even less) info. It all starts off with the type
of service you want, and what the NSP of the recieving end is and so on. This information
is passed to a SYS$IPC call.

What the NODE5 AM does is : it opens a Phase IV connection, using NODE::"TASK=CMIP_LISTENER",
and speaks CMIP over that connection. So it's actually the Phase V node whod does the job
of bweing backwards compatible.


Your problem boild down to the fact that DECmcc doesn't sees the node you want to manage, i.e.
the construct NODE::"TASK=CMIP_LISTENER" will never get to the other node. It's like if the other
node is in another space, or in another network. Exactly the same happens if you specify the name
of an IP node.

Dirk