HDTenEightyP/NetNews huggingface dataset:
From: omk@jyu.fi (Oiva M Kuittinen)
Subject: Post-implementation EDI (Production phase)
Organization: University of Jyvaskyla, Finland
Date: Wed, 26 Aug 1992 15:57:46 GMT

I would like to hear your opinion of the above subject. There are many
implementation models but they are only concerned with getting EDI up
and running. Some of the issues involved with the production phase
are software updates, transaction set version maintenance, staffing (as 
compared to that of an implementation project) but I am sure EDI people 
could extend the list far beyond that.

Please let us hear your comments, and, if you have read a good article
on the subject, please quote it to those of us who cannot buy the
magazine :-)

Finally, something not totally unrelated to the above... disbursed vs.
centralized EDI. A company/corporation could use just one EDI software
package or have several, one for each department/location. Are both
alternatives used in practice? Also, theoretically a corporation could
use BOTH disbursed processing for data transfer intensive applications
AND centralized processing for applications with a small transaction
volume, but does anyone use such a solution?

Regards... can hardly wait for your response

Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: edi-l@uccvma.ucop.edu
X-VMS-To: IN"edi-l@uccvma.ucop.edu"
X-VMS-Cc: OMAHONY
Newsgroups: bit.listserv.edi-l
Date:         Thu, 27 Aug 1992 10:56:00 GMT
From:         "Donal O'Mahony, Comp Sc,
              Trinity College Dublin" <OMAHONY@CS.TCD.IE>
Subject:      RE:Viruses
Comments: To: edi-l@uccvma.ucop.edu

   Donal O'Mahony writes:
> > If, on the other hand, people start to use this as a means of distributing
> > executable code, then the dangers become exactly analagous to the
> > movement of floppy disks, and the same precautions should be taken.

   Bill Laidley responds:
> My thoughts precisely. Boeing uses it to distribute executable code
> already. The reason I started this particular line of discussion is
> that this issue needs to be thought about and acted on.

If this is the case, then there is indeed cause for concern.  Nevertheless,
this is not a problem with the new transaction, but with the way in
which it is used.

One must be very careful in how this is put to the EDI user population - it
could easily be interpreted as: "If I get involved in EDI, I risk total
loss or corruption of my computer system resources".

The people who need to be careful are the application designers, and for
them, the problem is not an EDI-specific one.  It is simply that
they must be careful not to write programs which allow code to be
implanted into the system, unless this code is "trusted".

Donal O'Mahony
Computer Science Dept
Trinity College
Dublin 2
Ireland
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer:     Pegasus Mail v2.3 (R3).
Newsgroups: bit.listserv.edi-l
Date:         Thu, 3 Sep 1992 16:28:32 EST
From:         "Michael S. Hines" <MSHINES@FREH-03MS.ADPC.PURDUE.EDU>
Subject:      Transaction Sets

I'm trying to get documentation on the Insurance Set of Transactions..

835 Health Care Claim Payment/Advice (pp 432)
834 Benefit Enrollment (pp 428)
837 Health Care Claim (pp435)

All references are to the Version Release 3020 Standards Development
Workbook.

Can anyone give me some assistance?

Thanks.

I called EDI Support Services, and was quoted $375 for the complete
book.  That would be nice if I was a fortune 500, but I am just a
little guy trying to do the job for a startup client in Managed
Health Care.

Thanks again for your consideration.






----------------------------------------------------------------------
Internet:  mshines@ia.purdue.edu      |  Michael S. Hines
Bitnet:  michaelh@purccvm             |  Internal Auditor-EDP
Purdue WIZARD Mail: MSHINES           |  Purdue University
GTE Net: (317) 494-5845               |  1065 Freehafer Hall
Compuserve: Mike Hines (73240,1631)   |  West Lafayette, IN 47907-1065
----------------------------------------------------------------------
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.edi-l
Date:         Wed, 26 Aug 1992 17:57:00 LCL
From:         Dave Kearns <DKEARNS.TCC@KLAVEN.TCI.COM>
Subject:      Re: Viruses, worms, wildlife & EDI
Comments: To: MSHines <EDI-L@uccvma.ucop.edu>

>..........Dave says, in part...
>>
>>Its as easy as changing the attribute of any EXE or Overlay file to READ
>>ONLY. Now, a piece of software could modify this on a standalone PC, but
>>(again) it would have to be RUN. Path and file name information in the
>>transaction which attempted to overwrite a RO file when simply cause an
>>error message.........
>>
>And anyone with enough epertise to write a virus, worm or any other
>intrusion program will know how to change these attributes fairly
>easily too.  Read Only is only read only so long as the system says
>so.  The same system that protects it, allows it to be changed..at
>the low level - DOS calls, or at the high level using ATTRIB command.

But SOMETHING needs to be run to change the attribute! If you can't
overwrite the file, then the trojan horse can't be installed, so it can't
be run to change the attributes!

I really think we're getting far too 'het up' about this. This particular
transaction will have a net zero effect on the ability of viruses, worms,
etc. to proliferate.

-dave
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Posted-From: The MITRE Corporation, Bedford, MA
Newsgroups: bit.listserv.edi-l
Date:         Thu, 27 Aug 1992 09:21:40 -0400
From:         MacFarland.Hale@HECKLE.MITRE.ORG
Subject:      The virus saga continues...
Comments: To: EDI-L@uccvma.ucop.edu

Dave Kearns makes two points (at least):

> Its as easy as changing the attribute of any EXE or Overlay file to READ
> ONLY. Now, a piece of software could modify this on a standalone PC, but
> (again) it would have to be RUN. Path and file name information in the
> transaction which attempted to overwrite a RO file when simply cause an
> error message.........

Yes, but again, I don't think average PC users would think about READ ONLY
themselves, no matter how easy it is.  Also, recall that in my example the
virus overwrites a module of the EDI package itself, so it WILL BE RUN at
some point.

> I really think we're getting far too 'het up' about this. This particular
> transaction will have a net zero effect on the ability of viruses, worms,
> etc. to proliferate.

Well, I obviously disagree that this will have a "net zero effect" on virus
proliferation.  As to whether we're getting too "het up" over this, I guess
that depends on how strict your security requirements are, what level of
computer expertise your organization has, and so forth.  (Besides, I ENJOY
getting "het up" now and again - it gets my blood flowin'! :-) )

I still think it'd be a good idea for EDI vendors to be careful in how they
handle the 841.  As Bill alluded to, the EDI software should provide a way to
address all this (e.g., a configuration option to disallow writing over any
file that already exists; an option to allow overwriting only a specified set
of files; etc.).  It doesn't seem to me that this would be all that big a
deal from an implementation perspective.  Donal O'Mahony pointed out that the
problem is not the 841 itself, but the way in which it's used - I view the EDI
translator as the "user" of the 841.

By the way, I also agree with Donal that we must be careful to point out this
is an easily solvable problem when talking about this to the EDI user
population.

	Mac

	MacFarland Hale			machale@mitre.org
	The MITRE Corporation		(617) 271-3703
	202 Burlington Road, MS K331	(617) 271-2352 FAX
	Bedford, MA  01730-1420
From: GOVE036@TWNMOE10.BITNET (Anne Liang)
Newsgroups: bit.listserv.edi-l
Subject: About official statistics
Date: 1 Sep 92 03:38:35 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

Hi, Everybody

I works for the government statistical department in my country, the
Republic of China, and I am new to this list and EDI.

Recently, I was assigned a job to regulate the data transmission procedure
efficently from LOCAL GOVERNMENT to CENTRAL GOVERNMENT.

The data are classified into two class: rawdata(record by record) from
sampling survey, tabular forms filled by statistical figures.

I wonder if there are some discussions about these types of data.
I know very little about EDI. However, what I want is to deliver the data
electronically and facilitate the data processing consequently.
It sounds like there's some relationship. Help me clarify whether EDI is
feasible for my case. Actually, I just want part of EDI, ie the TRANSLATOR
SOFTWARE. Please shed some light on it.

Thanks in advance.

Anne Liang in Taipei Taiwan
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.edi-l
Date:         Sat, 29 Aug 1992 11:24:26 +0900
From:         MYO-SEOB KIM <moskim@SOREL.KOTEL.CO.KR>
Subject:      EDI Products
Comments: To: EDI-L@uccvma.ucop.edu

Dear netters,

Does anyone know products which is implemented by X.435 based EDI products.
It is commercial or in progress O.K.
Any informations are O.K.

If you know then send e-mail to me.

Thanks...

E-mail: moskim@sorel.kotel.co.kr
KOREA TELECOM.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: EDI-L@uccvma.ucop.edu
X-VMS-To: IN"EDI-L@uccvma.ucop.edu"
X-VMS-Cc: OMAHONY
Newsgroups: bit.listserv.edi-l
Date:         Wed, 26 Aug 1992 18:28:00 GMT
From:         "Donal O'Mahony, Comp Sc,
              Trinity College Dublin" <OMAHONY@CS.TCD.IE>
Subject:      Re: Viruses, worms, wildlife & EDI
Comments: To: EDI-L@uccvma.ucop.edu

It seems to me that the document on Viruses submitted by Bill Laidley
is a touch alarmist.

Going on his description of this 841 X.12 transaction, the only new
change is that a section of data in an EDI message can be tagged to
specify that it is to be INTERPRETED as raw binary, rather than
ASCII text.

Note that all EDI data is expressed in the machine and on the wire as
binary - It is only when it is rendered on an output device, or
acted on by software that the interpretation comes into play.

There is no suggestion in the supplied description that this transaction
allows a remote site to implant a file into their EDI partners file
system - let alone cause it to be executed.

If this logic is followed to the extreme, any external source of data,
(including allowing someone to type in a username in response to a
login prompt) could POTENTIALLY implant a virus.

If, on the other hand, people start to use this as a means of distributing
executable code, then the dangers become exactly analagous to the
movement of floppy disks, and the same precautions should be taken.

Donal O'Mahony
Computer Science Dept
Trinity College
Dublin 2
Ireland
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Newsgroups: bit.listserv.edi-l
Date:         Thu, 27 Aug 1992 09:44:44 -0700
From:         Richard Hintz <hintz@OZ.UCOP.EDU>
Subject:      EDI Network in China
Comments: To: edi-l@uccvma.ucop.edu

I am very interested to see that we have participants from China on EDI-L.
Welcome.  Perhaps someone would post a note on the status of EDI in China
today and plans for the future?
  Rich Hintz
  University of California
From: eggenberger@csghsg5a.bitnet
Newsgroups: bit.listserv.edi-l
Subject: Re: EDI Network in China
Date: 30 Aug 92 17:36:09 GMT
Organization: University of St.Gallen, Switzerland

Dear Mingdong,
May I ask you in which sectors you are implementing EDIFACT?
Is just inside China or also cross-border projects? Are there any
projects between banks and production company? Did you have any
Chinese based standards before? In which geographical areas of
China are you implementing EDI (China - Hongkong)? Are you using
Hard- and software from U.S.?
.
In article <19:mingdong.yan@cnlab.nci.crn.cn>, mingdong.yan@CNLAB.NCI.CRN.CN (Mingdong Yan) writes:
> ==================
> 
> Dear Rich Hints and other EDI-L participents:
> 
> I am very glad to introduce the status of EDI in China.
> 
> At 1990, some peoples in China began to discuss EDI's usage in our country.
> Several conferrences on EDI have been held, about EDI standards,chinese EDI
> and so on.
> 
> We will put attention to make our future EDI system to accept EDI message
> encoded by ISO 10646 characters set .
> 
> We will implement EDI communication network based on X.400 MHS, according
> to CCITT X.435 Recommention.
> 
> Generally ,we will use EDIFACT standard in EDI message generating.
> 
> I am engaged at EDI communication network, we will complete it in next year.
From: af041@cleveland.Freenet.Edu (Mark Webster)
Newsgroups: bit.listserv.edi-l
Subject: Mail request
Date: 3 Sep 1992 19:31:19 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu


If possible, please add mwebster@reach.com to the edi-l mailing list.

Thanks!
-- 
Mark Webster                   |  mwebster@reach.com    or
Cleveland, OH                  |  af041@cleveland.Freenet.Edu


Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.edi-l
Date:         Thu, 27 Aug 1992 10:12:00 LCL
From:         Dave Kearns <DKEARNS.TCC@KLAVEN.TCI.COM>
Subject:      RE: 841's
Comments: To: randalls <EDI-L@uccvma.ucop.edu>

>I LOVE to get 'het up'.  Thought about starting a school for
>administrative types to give lessons in 'contructive agression'.  Sort of
>a 'Rambo school of Business'.  I just kidding, I think.
>
>Anyway, we at DMS addressed the 841 with concern, even alarm, so we gave
>it a lot of thought.  If a file name is specified, and the file
>name/extension exists in the directory path indictated for our product to
>store the file in, then we simply create a new name and notify the user.
>There is no way that an incoming BIN can 'overwrite' and existing file via
>our product.
>
>Just thought I'd let y'all know that not all of us vendors/designers are
>completely insensitive to the business concerns of our users.
>
>see ya, I'm gonna go get 'het up' about something.  I love that phrase,
>haven't heard it since I left the dirt-floor bars of south Texas.  Getting
>'het up' was a full time job in those places.
>
******************* NOTES from Dave Kearns (DKEARNS @ TCC) at 8/27/92 10:03a

We've still got dirt floor bars here in Central Texas, Randall. (Yes,
right here in what south- and west-texans call the "people's Republic of
Austin"!)

Note that your method would defeat me from using an 841 for software
upgrades to my products - especially with non-computer-friendly types who
are ideal candidates for this. Better to have your installation program
flag all of its files Read-Only to guard against the rogue.

I do think, though, that we're blowing this out of proportion. The
knowledge necessary to create an effective worm/virus coupled with the
small target audience (user's of a particular EDI translator who are
using the 841) compared to the large pool of potential targets for other
methods of spreading mayhem are what led me to label this a 'zero-effect'
problem.

We do tend to see threats in our own backyard as larger than they perhaps
are, often without examining the larger threats which only affect us
tangentially.

-dave
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Posted-From: The MITRE Corporation, Bedford, MA
Newsgroups: bit.listserv.edi-l
Date:         Wed, 26 Aug 1992 16:29:44 -0400
From:         MacFarland.Hale@HECKLE.MITRE.ORG
Subject:      Re: Viruses, worms, wildlife & EDI
Comments: To: "Electronic Data Interchange Issues" <EDI-L@uccvma.ucop.edu>
              26 Aug 92 13:26:00 -1100. <9208261929.AA24561@mbunix.mitre.org>

> >True, Dave, the code must be executed, but I don't think this would be too
> >tough for the person in Bill's example.  This person has an intimate
> >knowledge of the EDI software in use on the trading partners' PCs.  Some
> >EDI packages are organized into separate executable modules that call one
> >another.  A virus could be passed using the 841 transaction with a file
> >name equivalent to one of these modules.  If the EDI software doesn't
> >check the file name, it could overwrite this module and, once that module
> >is next called, the virus is off and running.  The virus could, among
> >other things, perform the functions of the original module so as to hide
> >itself as long as it pleases.

> That scenario has nothing to do with EDI, but everything to do with
> system security. Any sysadmin who'd allow the possibility of program code
> being overwritten should be given a one-way ticket to the unemployment
> line. Every desktop OS I know of is able to implement this minimum
> security.

In an environment that provides real security features, such as UNIX, I agree
with you completely - a sysadmin should protect program code.  But we're
talking about PCs here - the "sysadmin" (user) often isn't conscious of
security at all.  You say every desktop OS can prevent program code from being
overwritten?  DOS certainly does NOT have this feature.  It could be added
using a third party product (e.g, one of the popular anti-virus programs), but
it's not a function of the OS (if we can call DOS that :-) ).

In the traditional "hub and spoke" scenario of EDI propagation, the spokes
often have no prior PC experience whatsoever.  These are the folks that could
easily be burned in my example above.  "Mom and Pop" shops may install a small
PC with EDI just to win a contract, but don't believe for a minute that they're
going to spend a lot of time becoming computer savvy.  In fact, much of today's
marketing hype from PC-based EDI vendors pushes the ease of setup and use of
their products.  These vendors know they can't assume small shops will hire
computer-smart staff.

I don't think Bill intended his writing to be alarmist or to imply that the
problem can't be fixed - just to highlight that the problem exists and needs to
be addessed (correct me if I'm wrong, Bill).

	Mac

	MacFarland Hale			machale@mitre.org
	The MITRE Corporation		(617) 271-3703
	202 Burlington Road, MS K331	(617) 271-2352 FAX
	Bedford, MA  01730-1420
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: Pegasus Mail v2.1c R5.
Newsgroups: bit.listserv.edi-l
Date:         Wed, 26 Aug 1992 16:16:59 EST
From:         "Michael S. Hines" <MSHINES@FREH-03MS.ADPC.PURDUE.EDU>
Subject:      Re: Viruses, worms, wildlife & EDI
Comments: To: EDI-L@uccvma.ucop.edu

..........Dave says, in part...
>
>Its as easy as changing the attribute of any EXE or Overlay file to READ
>ONLY. Now, a piece of software could modify this on a standalone PC, but
>(again) it would have to be RUN. Path and file name information in the
>transaction which attempted to overwrite a RO file when simply cause an
>error message.........
>
And anyone with enough epertise to write a virus, worm or any other
intrusion program will know how to change these attributes fairly
easily too.  Read Only is only read only so long as the system says
so.  The same system that protects it, allows it to be changed..at
the low level - DOS calls, or at the high level using ATTRIB command.
 Don't underestimate that capabilities of these troublemakers.

Let's see, if I were going to inflict pain and suffering on DOS, what
program gets run more than any other...and most people don't even
think about it.  Obviously, the ingenious program that displays you
C:> prompt.  It runs at start up, and between every application
program you execute.  Just try deleteing COMMAND.COM and see how your
system works.  I've tried it as a less than scientific experiment,
and take my word for it, it is not a good thing to do.  :)

Even the WINDOWS operating system add on does very little to address
system security.

Do I sense there is a market waiting there somewhere..........



----------------------------------------------------------------------
Internet:  mshines@ia.purdue.edu      |  Michael S. Hines
Bitnet:  michaelh@purccvm             |  Internal Auditor-EDP
Purdue WIZARD Mail: MSHINES           |  Purdue University
GTE Net: (317) 494-5845               |  1065 Freehafer Hall
Compuserve: Mike Hines (73240,1631)   |  West Lafayette, IN 47907-1065
----------------------------------------------------------------------
From: eggenberger@csghsg5a.bitnet
Newsgroups: bit.listserv.edi-l
Subject: RE: EDI-92
Date: 27 Aug 92 10:58:07 GMT
Organization: University of St.Gallen, Switzerland



Hi J-C,
Do you know that the conference will be held at the International Conference
Centre Birmingham from 6-8 October? The theme for the exhibition is
"Partnership in a Competitive Environment"
The exhibition is organized by Blenheim Queensdale.
Contact Karen Dawson, 630 Chiswick High Road, London W45BG.
Tel. +44 (0)81 742 2828
Fax. +44 (0)81 742 3605

I found this information in Electronic Trader July / August 1992 p 32, 33

See you, Chips


In article <EDI-L%92082608372231@UCCVMA.UCOP.EDU>, "J.CHEN" <A096@CPC865.EAST-ANGLIA.AC.UK> writes:
> Hi,
> Could you please tell me some more details of EDI-92 conference?
> I would like to attend, if it is not too late.
> Thank you.
> 
> J-C Chen
> University of East Anglia, Norwich
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Newsgroups: bit.listserv.edi-l
Date:         Tue, 1 Sep 1992 19:28:29 -0700
From:         Richard Hintz <hintz@OZ.UCOP.EDU>
Subject:      re: unscribe
Comments: To: "Electronic Data Interchange Issues" <EDI-L@uccvma.ucop.edu>

On Mon, 31 Aug 1992 09:47:39 N, Michael Kuschke wrote:
> please unscribe "mk@*materna.de" from the edi-l mailinglist.


Done.
  Rich Hintz
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.edi-l
Date:         Fri, 4 Sep 1992 10:56:13 -0700
From:         Bill Laidley <WLAIDLEY@BCSC02.BITNET>
Subject:      RE: Transaction sets

 Michael,

 DISA does sell transactions individually. One that you listed costs:

 #835 - $32.00 (member) $80.00 (non-member)

 Numbers 834 and 837 are not listed in my DISA catalog - which covers the
 period January 1/92 to June 30/92. The prices per transaction are consistent.

 Given that you want 3 transaction sets your cost would be $240 (plus shipping
 and handling), would saves some money. X.12 membership dues vary depending on
 gross revenue, whether or not you are a financial institution or government...
 The bottom line is that the cheapest membership is $500, which won't save you
 any money.

 Regards, Bill Laidley
 EDI Expert Team
 BC Systems Corp. Vancouver (604) 660-9705
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.hellas
Date:         Wed, 26 Aug 1992 16:32:09 EDT
Reply-To:     pavlopou@ACE.RUTGERS.EDU
From:         pavlopou@ACE.RUTGERS.EDU
Subject:      Bomba sto xwro tou Mpasket
Comments: To: hellas@brownvm.brown.edu

Gigantiaia epituxia sto xwro tou Mpasket.
O PANA0HNAIKOS meta apoo megales prospa0eies tou proedrou Giannakopoulou
ekleye sth kuriolexia apo ta xeria ton Milwakee Mpaks ton Stoiko Brankobits
Etsi to kroatiko lompi pou eixe dhmiourghsei o Zeliko Pablisebits
bernontas ton Komazets sumplhrw0hke me ton Brankobits.
\
Poios ton pianei to PA0 me Gallh-Brankobits-Komazets-Oikonomou kai
olous tous allous paixtarades.
Pou einai o Kistanhs kai oi alloi gabroi pou mas taxan zalisei
me ton Itrakompinadoro tous.

Trifilara kai ta muala sta kaggela.

Sotiris - Nova Club (me th sunergasia tou Kou. Kontaxakh pou efere
			efhmerides kai periodika apo Ellada shmera.)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU