Conference help::decnet-osi_for_vms

>   But what to do if you have a DTE containing 14 digits + preceding 0 
>   (of international call) ==> so being 15 digits in total?
>     e.g. a customer (in Belgium) has an incoming DTE from the UK being:
>                    .CN.DCS%023424890016601 
>
    I'll check with the implementor of the NSAP mapping code what the
    correct procedure is in this case. My guess is that you lose the
    leading 0 and precede with 1036. The alternative is to drop the final
    digit and preced with 1052 (giving 105202342489001660 in your example)
    but that seems less likely.
    
>   What about the alternative (mentioned in same release notes)
>   to use a PSI$L3CS.EXE that does NOT perform X.121 mapping? 
>   ==> I couldn't find a
>               PSI$L3CS.EXE-X121-NSAP-MAPPING-DISABLED 
    
    We changed the name to PSI$L3CS.EXE-NMD. But then we stopped shipping
    it altogether (at least its not on my V7.1 system).
    
    It's definitely going to end up in the V7.1 ECO-1 kit but I don't
    recommend that you use that unless you absolutely have to - we don't
    test with it at all.
    
>   ==> can the one form the DNVOSI058.S -kit (as mentioned in release
>       notes of DECnet/OSI V7.0) still be used on DECnet OSI V7.0 ?
    Even if it worked, you would be losing two years or more of bug fixes.
    But I think there have been enough changes in other components that
    mean you would be given an early crash if you tried this.
    
>   ==> the kit (DNVOSI058.S) is NOT on the CD-distribution of DEC96,
    
    What should happen is that the NMD variant of the image is loaded onto
    the system in the same directory as the real PSI$L3CS.EXE.
    
    Antonio

    Antonio,
    
    Thanks for your reply!
    
    So the message is: avoid using the NMD-variant, even when available	
    in a (future) ECO-kit: ok?
    
    If you can get more info about the NSAP-mapping, I'll be glad to hear
    it... in the meantime I'll try to do some tests...
    
    Patrick
                  

My understanding is, that if you want to use X.121 mapping, then at the
OSITP level use full DTE addresses padded to 14 digits. Do NOT use local
or International prefixes (eg additional 0, 1, or 9 digits on the front).

So for a UK PSS DTE (12 digits, starting with something other than 0) pad to
14 digits with leading zeros and then prepend the APF of 36:

	DTE = 234225621126

	NSAP = 3600234225621126

For a 14 digit DTE address (eg 12 digit UK PSS DTE plus 2 digits subaddress),
no padding is required:

	DTE = 23422562112699

	NSAP = 3623422562112699

If you are on a PSDN which requires local or International prefixes, then use
the DTE class to 'fix' things up for you. For example, if your DNIC is 1234
and you require local prefix 1 and International prefix 0 and for local calls
you have to remove the local DNIC then:

    International Prefix              = 0
    Local Prefix                      = 1
    DNIC                              = 1234
    Strip DNIC                        = True

International example:

	NSAP = 3623422562112699

	Resulting DTE in CALL = 023422562112699

Local example:

	NSAP = 3612345678901234

	Resulting DTE in CALL = 15678901234

I have never tried this, as I don't have any networks which behave this way,
but it is quite clearly the intention of the way things are designed.

Regards,

	John

Oh yes, and one more thing...

Avoid the NMD kit, now, and for-ever. The only purpose was to help out
people who had already configured MRX the old way so that they did not have
to 'correct' it immediately. There has been enough time for people to correct
their configurations, so there should be no more need for the NMD image.

Regards,

	John

    John,
    
    Thanks for this info but I still have a question:
    (... X25 is not my "mother-tongue")
    I understand this for an outgoing call but what happens with
    an incoming call?  
    Defining the DTE class' 
    
             International Prefix       = 0
    
    is that supposed to strip the 0 from incoming international calls?
    (Isn't the default value assumed to be a 0?)
    
    Regards,
    
    Patrick
     

    I think that the stripping on incoming depends on the profile setting
    (which you cannot change), but as I can't test this easily, I'm only
    guessing. Give it a try.
    
    I spoke to the developer of this functionality, and it's been so long
    that he cannot give a definitive answer as to what happens. Clearly 15
    digit DTEs won't work. If you get it down to 14 digits by stripping the
    leading 0 (for international calls) then you should be OK (this was his
    suggestion too, so give it a go).
    
    And I'd like to second and third John's comments about the NMD image.
    It will probably ship in the next V7.1 ECO kit, but only because it's
    more effort to get rid of it than it is to leave it in. Clearly the
    reverse is true for full versions, so be prepared to bid a fond
    farewell to it in V7.2.
    
    Antonio

        When I upgraded FNO mts system HSKRTR to OpenVMS V6.1 and
        DECnet/OSI V5.8 (or was it V5.7A), I had the exactly same
        problem. What to do with those cases where the DTE address was
        already 15 digits long? I think I even posted my finding in some
        notes conference, probably though in FORTY2::MAILBUS.
        
        My experiments lead to observation that you have leave the last
        digit out. Keep the initial 0, prefix therefore with 1052 and
        just leave the last digit out in order to make it 14 digit long.
        
        _veli

        In fact I posted it right here, back in late 1994. See 1852.7
        and .later. And the conclusion of that time seemed to be prefix
        1052, 0, 13 digits from the address, i.e. leave the last out.
        
        _veli

    Hi,
    
    Thanks for your replies: we will see with the customer if we can
    use the "1052 + 0 + 13-digit" workarround....
    
    Regards,
    
    Patrick

Patrick,

>    
>    Thanks for your replies: we will see with the customer if we can
>    use the "1052 + 0 + 13-digit" workarround....
>

Why use a workaround for something that works properly in the first place?

I have set up my DTE Class (ie the one used for outgoing and the one set up
as the Inbound DTE Class on the DTE) as:

    International Prefix              = 1
    Local Prefix                      = 0
    DNIC                              = 9999
    Strip DNIC                        = True

I made a call to NSAP 103600234225621126 (10 = count of 16, 36 = AFI, etc),
from a DTE defined with leading 0. The X.25 call showed as:

	Called DTE = 1234225621126 (ie, with International prefix)
	Calling DTE = 000083300100 (ie already defined with local prefix)

The incoming OSI Transport call showed as:

	LOCAL ADDR = 103600234225621126 (ie target with Int prefix removed)
	REMOTE ADDR = 103699990008330010 (ie, the first leading 0 was dropped
		because it is the prefix, and the DNIC (9999) was restored)

So, it looks good to me if you set it up properly, and it appears to not need
any work-arounds...

Regards,

	John Weir