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

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

1029.0. "Use DSAB: field instead of Handling field (?)" by COPCLU::COPLE4::GLARGAARD (Allan Glargaard, DS @DMO) Mon Jul 13 1992 09:37

    A customer is using the Handling field on their documents to specify
    the appartment name of the creator. They added tons of department
    definitions to their FORMAT database, but this works fine as long as
    they only send mail between their two customized ALL-IN-1 systems
    (3000+ users)
    
    However, they have problems when they send an attachment to an ALL-IN-1
    MAIL user. The attachement could have a Handling field as eg. �E-BSC,
    which would then be checked against the users "recognized data formats"
    and then be converted to one of the known types. This of course
    "corrupts" the attachment - unless the users "recognized data types"
    database is also modified to include the 1000+ ever-changing
    department names as in the ALL-IN-1 IOS FORMAT database.
    
    The customer feels that the field DSAB: should be passed to tell the
    format of the attachment instead of the field Handling: - anything we
    can do to help him?
    
    Best regards,
    Allan
T.RTitleUserPersonal
Name		DateLines
1029.1Kind of backwardsSHALOT::NICODEMAvoid traffic; leave work at noonMon Jul 27 1992 18:0411
	Since there has been no reply in two weeks, I'm assuming that most of
our gentle readers have had the same reaction that I did -- namely, that the
Handling field is designed for document *Handling*!  And should a site decide 
to use it for something else -- whether departmental information, date of birth,
or golf score -- it is almost certain to lead to confusing results.

	Rather than the user making a recommendation that ALL-IN-1 use another
field to determine the document's handling, I guess I'd have to suggest that the
customer use another method of storing their customized information.

	F
1029.2Sorry - missed the original noteIOSG::SHOVEDave Shove -- REO-D/3CTue Jul 28 1992 14:0525
    Probably the only safe, supported way of carrying extra info in mail
    messages is to put them into a little file and add that as an
    attachment.
    
    Then your modified systems can recognise the "special" attachment and
    process its contents (and not display it, if you change the MAILATT1/2
    boilperplate files). Unmodified ALL-IN-1 systems, and non-ALL-IN-1
    systems will, at worst, just display the contents (which could include
    a text line saying what it is, and "not to worry"!)
    
    Very small amounts of data can also be carried on the end of the
    subject line (after the 76-odd characters that fit on the screen).
    Ideally, you'll need to modify the mail header boilerplates to include
    a :76 on the end of the subject expression, otherwise a
    diamond-character gets displayed/printed to show that the line has been
    truncated.
    
    Any use of any of the "standard" fields for anything other than their
    intended purpose is likely to give problems, as you've found.
    
    Dave.
    
    (_someday_ we and the mail program will get our acts together and
    _finally_ implement customisable attributes. Don't hold your breath
    though!)
1029.3I agree, user is not being fair to ALL-IN-1COPCLU::COPSPD::GLARGAARDAllan Glargaard, DS @DMOMon Aug 03 1992 10:2612
Re. .1 , .2:

  Thanks both, for your thoughts on this. I told my customer something
  similar to what you said, but he wanted a second opinion on his
  feeling the ALL-IN-1 is being silly here :-)

  I'll have the developers of the application work out how to put some
  intelligens in to this, if I remember maybe I'll let you know what
  they ended up doing.

  Best reards,
  Allan
1029.4Why not use the keywords field?LARVAE::PATON_SIt's not easy having a good time!Mon Aug 03 1992 12:381
1029.5Keywords don't work remotelyIOSG::SHOVEDave Shove -- REO-D/3CWed Aug 05 1992 16:204
    Because keywords aren't transmitted between ALL-IN-1 systems (no NBS
    element for them).
    
    D.