28 Feb 1995.

History prior to release 3.0 is deleted.

=====================================================================
Abstract:
Incorrout -- Organization: (null) in message header of digest mailing lists

Reported: 3.x

Description:

For several message header statements in digest mailing lists the
operand is "(null)". These header statements include "References:",
"Organization:", "Date:".

Conclusion:

This is broken.  There should be no "References:" statement at all.
The "Date:" statement should be the date/time the digest was
processed.  The "Organization:" should be the 'organ' from the STATIC
file.

Circumvention:

none.

Fixed: 3.0.1

Updated: 6-Jul-93
======================================================================
Abstract:
Incorrout -- CHKDSK reports 'lost allocation units' after WFSREQST

Reported: 3.x

Description:

After WFSREQST processes (recieves) a message for a Digest Mailing
List, if the SysOp runs the CHKDSK program, then CHKDSK reports a
'lost allocation unit'.

WFSREQST performs the receive with no error reported and no other
unexpected behavior.

The problem exists only for those sites running a Digest Mailing
List.

The problem is not reported in all environments!  In plain MS-DOS
(not all environments here too!) the problem does occur. The problem
does not occur under Windows and may or may not occur under DesqView.


Conclusion:

Function RecieveMailListFile() in mls.c does not close the spool file
before deleting it.

A call to SplClose() will be added before the call to SplRemove() in
the path where a Digest Mailing List message is being saved. Note the
code path that recieves Mailing List message works correctly; no
change is required.


Circumvention:

Run CHKDSK /F occasionally, depending on the amount of traffic you
have for a Digest Mailing List, to clean up the lost allocation
units.

The amount of space temporarily out of service because of the lost
allocation unit is small, about the size of a small 'session
transcript' message.

Fixed: 3.0.2

Updated: 24-Jul-93
======================================================================
Abstract:
Incorrout -- Subject: line in Mailing List messages have "Re:" added

Reported: 3.x

Description:

The subject: line in messages forwarded to members of a mailing list
have an "Re:" added to the subject: line.

Conclusion:

Function MailServer() in sendf.c inserts the "Re:" between the
Subject: string and the subject data from the original message.

The insert of the "Re:" will be removed.

Circumvention: none.

Fixed: 3.1.0

Updated: 29-July-93
======================================================================
Abstract:
Incorrout -- Files $$WFS*.DIG are left in the 'temporary' directory

Reported: 3.x

Description:

WFSSENDF, after creating Mailing List digests, leaves the temporary
files $$WFSTOC.DIG and $$WFSART.DIG in the directory named in the
'temporary' statement in the STATIC file.

Conclusion:

The files should be deleted after the digest has been created.

Function MakeDigest() in mld.c will be changed to delete the
temporary files after creating the digest.

Circumvention:

Manually, or use a batch file, to delete the temporary files after
running WFSSENDF.

Fixed: 3.1.0

Updated: 29-Aug-93
======================================================================
Abstract:
Incorrout -- A closed digest's mailing list address is exposed

Reported: 3.x

Description:

The address of a digest mailing list, where the MAILLIST.CFG file
has a "ReplyTo:" statement, is disclosed in the body of the mailing list.

The spec for RFC1153 says that the To: and Cc: headers are to be
included in the message body for each submission to a digest mailing
list. WFS's intention to have the list's address visible only to the
SysOp when the ReplyTo operand is specified in the MAILLIST.CFG file.
This intention flies in the face of the requirement stated in the
RFC.

By carrying forward the address on the To: or Cc: headers, the
mailing list's address is disclosed to readers of the digest.

Conclusion:

No matter what I do, I'm gonna piss off somebody. So be it.

<a bunch of negotiations with myself deleted... you don't wanna know>

The digestifier will be changed so that if the ReplyTo statement is
specified in the MAILLIST.CFG file and the mailing list's alias is
found in the To: or Cc: header, then that header will be re-written
to obscure the mailing list's address.

Some data in the original header statement may be lost. Too bad.

Fixed: 3.1.0

Updated: 6-Sep-93.
======================================================================
Abstract:
Incorrout -- Boolean expression "token : on" is not parsed

Reported: 3.x

Description:

Boolean terms of the form "token : on" are not recognized in any of
WFS's configuration files.

A user had coded "join : on" in a MAILLIST.CFG file. The form got the
standard Parse error message from the boolean term parser.

Conclusion:

"On" and "Off" seem to be valid boolean terms.  ParBoolean() in par.c
will be changed to recognize them.

Fixed: 3.1.0

Updated: 6-Sep-93.
======================================================================
Abstract:
Incorrout -- Message "Abnormal Program Termination" issued w/o explanation

Reported: 3.x

Description:

When running WFSREQST, as invoked by UUXQT, the message "Abnormal
Program Termination" appeared. The results of processing the
incomming message appeared to have caused queuing (QD*.2 file) of the
commands, but there was no session transcript message queued (in the
spool) responding to the incomming request.

Conclusion:

Function Rmail() in waf.c invokes the RMAIL program using spawnl().
The function checks the return value from spawnl() for '-1' to ensure
that the function was able to start the RMAIL program. The function
does not check for any other non-zero returns that would indicate an
error.

In the reported case, the user was running waffle on a 286 box with
network drivers, and scads of other TSRs so that the available memory
was less than 450K. Waffle ran OK. The support programs ran OK, most
of the time. When UUXQT invoked WFSREQST, and WFSREQST subsequently
invoked RMAIL, there was not enough memory for RMAIL to run
successfully.  RMAIL issued the "Abnormal Program Termination"
message when he discovered he did not have enough memory to run.

Rmail() in waf.c will be changed to check for any non-zero return
from RMAIL and report the error when encountered.

Fixed: 3.1.0

Updated: 16-Sep-93.
======================================================================
Abstract:
Incorrout -- Digest files not deleted when autoDelete specified

Reported: 3.x

Description:

When multiple digest files are created as a result of the digest
command only the last minus one digest file is deleted when
AutoDelete is 'yes' in the MAILLIST.CFG file.

Suppose digest V001N001 exists. Suppose that as a result of digesting
articles digests V001N002 and V001N003 are created because a single
digest would exceed the DigestSize limit. When the AutoDelete
processing occurs, only digest V001N002 will be deleted.  This leaves
digest V001N001 and V001N003 in the directory. The expected result is
to leave only V001N003.

Conclusion:

Inadequate design. Feh! :-}

The digest delete algorithm in Function MakeDigest() in mld.c will be
changed to delete the current -1 digest after a new digest has been
created and mailed.

Fixed: 3.1

Updated: 22-Sep-93.
======================================================================
Incorrout -- Waffle's ADMIN\MAIL file entry says "(null)"

Reported: 3.1

Description:

Waffle's ADMIN\MAIL file is written to by WFS programs when recieving
or sending mail.  If the mail item recieved by WFSREQST does not have
a properly constructed mail header, having a valid "From " line, then
the value for the "From " portion of the ADMIN\MAIL line written by
WFSREQST will be "(null)".

Conclusion:

The reported error occured because a 'Hand Built' mail message was
fed to WFSREQST [probably by I/O redirection, as in: "WFSREQST <MSG"].
The "From " line was missing.

Also, a message generated using Waffle's 'mail' command where the
target of the mail is aliased to WFSREQST on the local system does
not have a "From " line causes the symptom too.

Function ReadHeader() in reqst.c will be changed to substitute the
value of the "From:" header statement when no "From " header statement
is found.

Circumvention:

Ensure that there is a valid "From " statement in the message header,
or tolerate the "(null)" in the ADMIN\MAIL file.

Fixed: 3.1.1 (no public release)

Updated: 3-Oct-93
======================================================================
Abstract:
Incorrout -- Message "Error: cannot open spool file..." with AddMember

Reported: 3.1

Description:

The message appears in the log following an 'addmember' command.

The addmember command appears to have worked successfully otherwise.

Conclusion:

There are several anomalies here...

First, it appears that the mailing list owner did not configure the
MAILLIST.CFG file with a 'welcome:' statement.

Second, the message is misleading. This message was issued by function
SplCopy() in spl.c. The message text will be changed to give a better
hint as to where it came from.

Third, the algorithm for sending the welcome message to the new
subscriber of the mailing list does not check for the presence of the
welcome message before attempting to send it.  This algorithm will be
changed to check for the presence of the welcome file before
attempting to send it. Appropriate messages will be added when the
welcome file is not present.

Circumvention:

Add a 'welcome:' statement to the MAILLIST.CFG file.

Fixed: 3.1.1 (no public release)

Updated: 10-Oct-93
======================================================================
Abstract:
Incorrout -- Filename.ext causes incorrect encoding

Reported: 3.1

Description:

Taken directly from the users emailed PR:

  "A friend of mine requested a file called "KANJIW.TIFF". Now the file
  name is "kanjiw.TIF" (not "TIFF"!!). Instead of trapping the error by
  saying "file not available", it apparently sent the ".TIF" file in
  binary, which it shouldn't have done (it has been set up to uuencode
  TIF files).

  * Info: QD000176.2: File Request: /waffle/public/aikido/calligr/kanjib.tiff: 37838

  * Info: c:/waffle/public/aikido/calligr/kanjib.tiff
  * Info: Part 1 sent plaintext

Conclusion:

The file not conforming to the MS-DOS 8.3 filename format, when
passed to the access() function, as implemented by Microsoft's
runtime library, has some 'magic' applied to the filename so that the
file 'KANJIW.TIFF' resolves to 'KANJIW.TIF'. This means that from the
file is found. The desired response is to flunk the access()
function.

Function FileFind() in fil.c will be changed to do a rigorous 8.3
format edit on the filename passed as an argument.

Fixed: 3.1.1 (no public release)

Updated: 16-Oct-93.
======================================================================
Abstract:
Incorrout -- MembersOnly statement in MAILLIST.CFG file is not respected

Reported: 3.1

Description:

The MembersOnly statement in the MAILLIST.CFG file is not respected.

Conclusion:

Hmmm... This feature *was* tested, once upon a time. ... Yet, the code
that should have internalized the MAILLIST.CFG file does not capture
the MembersOnly statement. What happened? Dunno. I suspect that the
MembersOnly statement in the parse table was inadvertently deleted
during some other maintenance action. The feature was not regression
tested; too many tasks, not enough time.

In any case, the supporting use of the MembersOnly statement is
already in place.

The parse table in function RecieveMailListFile() in mls.c will be
changed to parse the MembersOnly statement as a Boolean term.

Fixed: 3.1.1 (no public release)

Updated: 16-Oct-93
======================================================================
Abstract:
DocError -- AutoMail.immediate works differently than the 'get' command

Reported: 3.1

Description:

Mail addressed to automail.immediate addresses causes the reply to be
sent without uuencoding or without being split into parts.


Conclusion:

The documentation incorrectly states that AutoMail respects the
uuencode options delared in the STATIC file.

The documentation will be changed to clearly indicate the intent of
the AutoMail.immediate address. That is: to provide an immediate
response to information requests, such as for help, product
information, or other short topics suitable for mailing, without
encoding, in a single part.

The documentation will be changed to show distinciton for automail
(without the ".immediate" designation) that says that the uuencoding
options and the various file splitting options will be respected.


Fixed: 3.2.0

Updated: 29-Oct-93
======================================================================
Abstract:
Incorrout -- The timezone in dates is truncated to 3 characters

Reported: 3.1

Description:

From a long time 'unregistered' user's problem report:

  I have a problem with the timezone format, I use +0100 and that is
  legal, but WFS makes it +01, which is illegal.


Conclusion:

Function Udate() in dos.c will be changed to allow for longer date
tokens in Waffle's timezone STATIC file statement.

The WFS startup messages will still rely upon the Microsoft defined
TZ environment variable. This is a fixed format string [pst8pdt], so
there's not much I can do about that...
                                   

Fixed: 3.2.0

Updated: 2-Nov-93
======================================================================
Abstract:
Incorrout -- No message to user for JOIN command when user already JOINed

Reported: 3.1

Description:

When someone tries to rejoin a list they are already a member of, the
following is written to the ADMIN\WFSLOG file:

  Info: Requestor: someuser@some.site.com
  Info: JOIN:    SomeMailList
  Warning: Already a Member. Not added

... but nothing is sent back to the person making the request.

Conclusion:

Function AddMember() in mls.c is inadequately designed; the function
returns a Boolean. AddMember() returns FALSE for any error or
exception;  the function can detect an error (file operation error)
and an exception (requested add is already a member). There needs to
be a distinction between an error condition and the simple exception
of the requested addition already being a member of the list. A
return of a Boolean is inadequate. 

AddMember() will be changed to return an enum { AddOK, AlreadyMember,
Error }.

The call to AddMember() from function MlJoin() in mls.c will be
changed to deal with the 3 returns from AddMember(). A message will
be returned to the requestor when he is already a member of the list.

The call to AddMember() from function MlAddMember() in mls.c will be
changed to deal with the 3 returns from AddMember().

Fixed: 3.2.0 

Updated: 27-Nov-93
======================================================================
Abstract:
Incorrout -- tabs in fileinfo causes funny stuff

Reported: 3.1

Description:

Verbatim, from a user's report:

  In a FILEINFO file (@files) with an entry such as:

  file1.txt	This is a text file 1 of 1

  The white space between the filename and file description is allowed
  to contain a <TAB> in Waffle and not allowed to in WFS.

On testing, this causes WFSFILES to emit an error message about a
filename being too long.

Conclusion:

Function ReadFileInfo() in files.c does not recognize <tab> character
as a valid separator. The function will be changed to recognize the
tab character.

Fixed: 3.2.0

Updated: 24-Dec-93
======================================================================
Abstract:
DocError -- REPLYTO user command must be placed before affected commands

Reported: 3.1

Description:

A user reported that the "replyto" command does not work. He had sent
the command sequence:

  join some-list
  replyto foo@bar.com

The replyto command becomes effective in the command stream where it
appears, not for all commands in the stream.

Conclusion:

The description of the REPLYTO command in USERCMD.SPR will be changed
to say that the replyto command only becomes effective for commands
following it in the command stream.

Note also that the session transcript is mailed to the last specified
replyto address in the command stream. This surprised at least one
user; that's the way it works.

Circumvention:

Place the REPLYTO command before any command in the command stream
for which you want the replyto to be effective. For the above
example, the command stream should be:

  replyto foo@bar.com
  join some-list


Fixed: 3.2.0

Updated: 25-Mar-94
======================================================================
Abstract:
Incorrout -- No error message written to WFSLOG when invalid wfs.uuencode

Reported: 3.1

Description:

When the wfs.uuencode static file statement references an invalid
path (the drive, directory, or program), WFS does not detect or
report the error.

Analysis:

Code in SendEncoded() checks the return from the system() function
call as described in the MS documentation. System() does not report
that the referenced program could not be found; it reports only that
the command interpreter (command.com) was successfully run or not.

In the reported incident, command.com was successfully run, but the
uuencode program was not. ... Hence no uuencoded files to send.

Further, the path thru SendEncoded() caused the WFSSENDF program to
delete the QD* file containing the users request resulting in lost
data (Ack!).

Conclusion:

SendEncoded() will be changed to verify a good path to the UUENCODE
program.  If the program file is not found, the program will
abnormally terminate, preserving the QD* file for the SysOp to deal
with. ... Hopefully correct the pathspec error and re-run WFSSENDF.

The path thru SendEncoded() will be changed so that errors that cause
the requested file not to be sent will abnormally terminate.  The
intention is to preserve the QD* file and allow the SysOp to correct
whatever is wrong without loss of data.

Fixed: 3.2.0

Updated: 13-Oct-94
======================================================================
Abstract:
Incorrout -- Message-ID header field is not RFC 1036 compliant

Description:

RFC 1036 says that the Message-ID: header field is to contain the
full domain name of the originating host.

Conclusion:

Function SplOpen() in spl.c will be changed to use the Waffle node
static file variable for data in the Message-ID: header statement.

Fixed: 3.2.0

Updated: 14-Oct-94
======================================================================
Abstract:
Message -- Panic: expired

Reported: 3.0.x, 3.1.x

Description:

WFS programs issue a message: "Panic: expired" sometime at the end of
January 1995.

Conclusion:

WFS programs are designed to issue this message, then terminate
gracefully sometime at the end of January 1995.


Circumvention:  

Register your use and get an immediate upgrade to release 3.2.0.
Release 3.2.0 does not expire. It does, however, have a nasty NagWare
message that can be disabled by registering. When you register, you
will be given a 'RegisteredKey' that disables the NagWare message.

Fixed: 3.2.0

Updated: 27-Jan-95
======================================================================
Abstract:
Doc -- JOIN command syntax: "join <listname> [address [comments]]"

Reported: 3.2.0

Description:

The WFS documentation describes the join command suggesting that
[address] is optional. It is. By ommission, the documentation
suggests that [comments] may be provided when [address] is ommited.
This is not true; [address] is required when [comments] are present.

The real problem is that some users confuse WFS command syntax with
"listserv" command syntax and attempt to use listserv command syntax
on WFS.  This apparently does not work. No surprise. What some users
want is for WFS's join command to have the same syntax as listserv.

Note: I have no personal experience with listserv, and so, did not
have a clue as to what was wrong when reports of "bugs" in the join
command came in. The command works advertized. ... I guess we call
this "cognitive dissonance".

The common mail servers: WFS, MajorDomo and listserv all have
different command syntax. That's just the way it is.

WFS's join command does indeed work, and work correctly, when fed the
correct command syntax.


Conclusion:

Suggestions by an small, but publicly vociferent few users, that want
the join command syntax to be changed to something similar to
"listserv" cannot be accomodated in the absence of complaints by the
many scores of other, apparently satisfied, users. Sorry.

When joining a mailing list, if you want to specify comments to be
added to the members file, then [address] is required.  The
documentation will be changed in the ShareWare release of WFS 3.2.0
to emphasize this.

In function MlJoin() in mlsr.c, a tighter edit will be applied to
[address], if present, to ensure that a "@" or "!" character is
present in the address; this will reduce, but not eliminate comments
being interpreted as addresses, then being inserted into the
members.mbr file, as addresses.

If the [address] does not pass the edit, the join command will fail
and the help message will be sent to the requestor. ... The SysOp
should instruct his users in the help message on the proper syntax
for the Join command.


Circumvention:

Update your 'help' text provided to users to show that if [comments]
are desired in the join command, then [address] is required.

Also, to help correct errors introduced into the members file, divert
commands to WFS into a mailbox file. Then review the messages
resulting in funny members file entries and manually update the
incorrect members file entries with what was intended by the users.

To divert commands into a mailbox file, while continuing to process
commands as they arrive, set up the ALIASES file like this:

server    $$log $$server
$$log     + c:\user\fileserv\command.log
$$server  | c:\bin\wfsreqst.exe


Fixed: 3.2.xac

Updated: 18-Feb-95.
======================================================================
Abstract:
Incorrout -- /wfs.deny token in DIRS file not recognized

Reported: 3.2.0

Description:

The /wfs.deny token in the DIRS file is not recognized.


Conclusion:

Yup, that's right.
There are multiple problems here:

1 -- in dir.c, the /wfs.deny token is found, but the indicator in the
dirs structure is not set properly. This causes WFSFILES to list the
directory.

Function ParseDirsStatement() in dir.c will be changed to set the
deny flag in the dir structure on detecting "/wfs.deny".

2 -- in reqst.c the deny indicator is not interrogated on the get
command. This causes WFSREQST to queue the file for send.

Function FileRequest() in reqst.c will be changed to call
DirGetDeny() before honoring the get request.


Circumvention:  

Consider removing the offending entries from your dirs file
altogether.


RCA: PE, QA

In the [complete] re-write of dir.c to reduce memory consumption, the
"dir" object was completely extracted from the "fil" object and
encapsulated a-la OOP style. ... Complete regression testing of the
re-engineered objects was not done.


Fixed: 3.2.xaa

Updated: 6 Feb 95
======================================================================
Abstract:
Incorrout -- DIRS file error when 'label' field missing from statement

Reported: 3.2.0

Description:

The Waffle documentation says, and I quote:

  Entries in the /waffle/system/dirs file may contain a number
  of parameters, described later in this document. For now, place
  as the first line in this file:

  (For DOS systems)

           1   /dir="c:/files"   /access=1

  (For Unix systems)

           1   /dir="/u/files"   /access=1

  Here, the first field (which should be in the first column)
  is an identifier that will be used with a future version.

  The /dir= specifies the location where you will store files
  for that file area, and /access= determines the minimum access
  level that may enter that file area.
  ...

The dirs file processing algorithms did not allow for users ommiting
the 'label' field (the '1' in the example above) and caused
"unpredictable" results, usually the directory listing of something
you did not want, or nothing.

Waffle allows the label field to be ommitted. ... Tom! Shame on you.
:-)


Conclusion:

ParseDirsStatement() in dir.c will be changed to allow for an
ommitted label on a dirs file statement. The algorithm will issue a
Warning level message and assume a label of "*".

Circumvention:  

Place a label field on each dirs statement.

RCA: ID, PE

Never assume valid data where a human can screw it up!

Fixed: 3.2.xab

Updated: 18 Feb 1995.
======================================================================
Abstract:
Incorrout -- WFS splash screens emit '19101' for year 2001

Reported: 3.2.0

Description:

The WFS splash screen displays the date and time it is run.  The date
for dates greater than 1999 have a formatting error that displays the
year as '19' plus the number of years since 1900. 

Discovered by a registered user trying to see if WFS 3.2 had
an expire-by date in it. ... It does not.

Conclusion:

Function Udate() in dos.c formats the date incorrectly.
The function will be changed to format the date correctly.

Circumvention:  

I won't worry about it for now. You can wait. :-)

RCA: PE

Fixed: 3.2.xac

Updated: 18 Feb 1995.
======================================================================
Abstract:
Incorrout -- Unpredictable results when WFS programs multi-task

Reported: 3.2.0

Description:

Well, somebody had to do it.

A user running OS/2 ran Waffle in one dos session. He ran a cron job
in another. At midnight Waffle's schedule file said run uuxqt; uuxqt
processed a piece of mail directed at WFSREQST. Also, the cron job in
the other dos session ran WFSSENDF at the same time. ... All hell
broke loose!

The symptom experienced is that the temporary file and the spool
files got corrupted. There were numerous messages in the WFS logs
about deleting temporary files. Ugh!

Also, because the queue control file was accessed simultaneously, a
"counters reset" message (presumably the counters were reset also)
was issued twice. ... Ugh!

Multiple other symptoms are possible, depending on the timing.  The
major objects exposed are: the log file, spool temporary file,
temporary work file, the queue control file.


Conclusion:

WFS programs were not designed to run multitasked. People do it
anyway. The best I can do is protect them from themselves.

A set of locking functions will be implemented in lock.c.  LockGet()
will be called just after the waffle static file has been
internalized and before the log is opened. LockGet() will get a lock
on a temporary file. This means that the WFS programs will have to
wait if another WFS program is running.

LockRelease() will be called at normal program termination and from
Abend().

LockGet() will try for about 30 minutes to get the lock. If he is
unable to get the lock, then he will give up and exit gracefully with
exit code 3 (the WFS Abend() exit is 1). The assumption is that
whoever is holding the lock is hung. 

Since one of the resources to be protected from concurrent update is
the WFSLOG file, the failed attempts to get the lock will not be
shown in the log file (the lock is obtained before the log is
opened). ... You have to see it on the console to believe that it
works.

WFS serialization algorithms use Microsoft's runtime library routine
_locking() to cause serialization. When WFS programs are run on an
operating systems that does not support the _locking() function, ...
serialization is ineffective, at best. 

The serialization function is predicated on multiple instances of WFS
programs seeing the same STATIC file variable "temporary".  When
"temporary" is different between instances, serialization is
attempted, but not actually performed. ... You are on your own.


Circumvention:  

Don't run WFS programs multi-tasked.

RCA: NR

Fixed: 3.2.xae

Updated: 2/28/95
======================================================================
Abstract:
Incorrout -- MSG "Info: Waiting for WFS lock" then program termination

Reported: 3.3.0

Description:

On startup, WFS program issues message "Info: Waiting for WFS lock".
The message repeats 200 times VERY QUICKLY then the program
terminates.

There are conflicting reports on what configurations cause the
symptom. On a "vanilla" MS-DOS platform (3.0 and up) without
SHARE.EXE loaded, the symptom occurs as described above.  With
SHARE.EXE loaded (the author's configuration) the problem does not
occur. The symptom does NOT occur under Windows, with or without
SHARE.EXE loaded.

There have been no reports from OS/2 Warp users (that I recall) of
any kind.

One DesqView user reported that with SHARE.EXE loaded, the box locked
up without displaying any messages; another DesqView user reported
that without SHARE.EXE loaded, the box locked up. ... What's the
truth?

I'd go for "DesqView without SHARE.EXE" causes the box to lock up,
based on the report of a reliable user. ... Thanks, Jerry.

My request for help from DesqView has gone unanswered now for about a
week. ... Oh well.


Conclusion:

WFS 3.3 was not tested under DesqView before release.  Apparently, I
didn't test with and without share.exe loaded.

Code will be changed in LockGet() to detect whether share.exe is loaded.
If loaded, it uses the serialization mechanism; when not loaded, the
serialization mechanism is not used.

SHARE.EXE (or equivalent function, e.g. Windows) is required to be
loaded before WFS programs run.

Circumvention:  

Load SHARE.EXE before running WFS programs.

When DesqView is used, load SHARE.EXE before starting DesqView.

RCA: ID, QA

Fixed: 3.3.1

Updated: 23 Mar 1995
======================================================================
Abstract:
Abend -- Abend with message: "Panic: ParseFile(): fopen():..."

Reported: 3.2.0

Description:

A user reports an Abend and the above message when he selectively
runs WFSSENDF with the -F option, later without.


Conclusion:

When specific queue types are processed, ommiting others, a gap is
created in the sequencing of queue record numbers.  As designed,
WFSSENDF is supposed to not care if there are queue records missing
from the sequence. Some maintenance activity removed the "don't care"
part of this code. What maintenance activity? Dunno. It is restored
now.


Circumvention:  

Don't run WFSSENDF with any exclusion options.


RCA: PE, QA

Fixed: 3.3.xba

Updated:  4/7/95.
======================================================================
