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

Conference rocks::dec_edi

Title:DEC/EDI
Notice:DEC/EDI V2.1 - see note 2002
Moderator:METSYS::BABER
Created:Wed Jun 06 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3150
Total number of notes:13466

3141.0. "Filebridge behavior in 1.3 and 2.1 - the same?" by JOBURG::BERETTA () Wed May 28 1997 16:58

    Hi,
    
    My customer has two EDI systems, an old 1.3 VMS/VAX system and an ALPHA
    based 2.1c system. He migrates the same message from the 1.3 system to
    the 2.1 system, but found that he had to change his filebridge table to
    get it to work. On the 1.3 system, when processing the message, the
    filebridge table did not take into account the fact that there is a UNS
    segment between HDR, DET and SUM. On the 2.1 system he has to
    explicitly include the UNS segments into the filebridge table otherwise 
    processing fails. Is there a change in the behavior of filebridge in
    this regard between 1.3 and 2.1?
    
    The other thing we have encountered is that since upgrading their
    messages, edifact documents that used to be called EDIFACT-REMADV are
    now appearing as REMADV. To prevent them having to change their
    profiles I made a copy of REMADV to EDIFACT-REMADV. Could this be the
    cause of the above filebridge problem?
    
    Peter
    
     
T.RTitleUserPersonal
Name
DateLines
3141.1Changed problem descriptionJOBURG::BERETTAWed May 28 1997 17:5635
    I have just discussed this problem with the customer again and it
    appears that his original description of the problem as detailed in .0 is 
    not correct. I will try to clarify:
    
    He has created a new edifact message in version 921 and called it
    acinfo. It looks like this:
    
      0001     BGM      00000001   H    M                00000000             
      0002     FTX      00000001   H    O                00000000    
      0003     UNS      00000001   H    M                00000000    
      0004     RFF      00000001   D    M       0101     00009999   O         
      0005     FTX      00000001   D    O       0101     00000000    
      0006     UNS      00000001   S    M                00000000    
      0007     CNT      00000001   S    M                00000000    
    
    He had originally not included the UNS segments, but EDI was failing
    the message. When he added the UNS segments as above, processing
    succeeded. On his 1.3 system his acinfo document looks like this:
    
     0001     BGM      00000001   H    M                00000000  
     0002     RFF      00009999   D    O                00000000
     0003     CNT      00000001   S    M                00000000
    
     and it works. 
    
    He was wondering if after having loaded the new messages and the
    documents names changed as detailed in .0, whether this had changed
    something, and whether decedi processed differently between 1.3 and
    2.1. He had originally told me it was his filebridge table that he had
    edited, this is however not the case. 
    (I will screen the next problem more carefully - sorry for the
    confusion)
    
    Peter.
    
3141.2We had to change to keep abreastSYSTEM::HELLIARhttp://samedi.reo.dec.com/Thu May 29 1997 14:197
    Peter,
    
    EDIFACT's usage of UNS changed and to cater for all cases we had to add
    explixit UNS's in the document definitions in V2.0 (before that we
    ALWATS assumed UNS's between non-empty areas).
    
    Graham
3141.3ThanksJOBURG::BERETTAThu May 29 1997 18:055
    Thanks Graham,
    
    That explains the problem.
    
    Peter.