Double exponential smoothing

Anyone have an rpg technique (or just an understandable formula for us non
econ/statistics majors) for double exponential smoothing for inventory
control?
Jim Horn

____________________________________________________
-----rpg400-l-bounces@xxxxxxxxxxxx wrote: -----

To: rpg400-l@xxxxxxxxxxxx
From: rpg400-l-request@xxxxxxxxxxxx
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
Date: 05/21/2009 09:37AM
Subject: RPG400-L Digest, Vol 8, Issue 387

Send RPG400-L mailing list submissions to
rpg400-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
[1]http://lists.midrange.com/mailman/listinfo/rpg400-l
or, via email, send a message with subject or body 'help' to
rpg400-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
rpg400-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of RPG400-L digest..."

*** NOTE: When replying to this digest message, PLEASE remove all text
unrelated to your reply and change the subject line so it is meaningful.

Today's Topics:

1. RE: Detecting that a submitted batch job is ending from w/in
an RPG program. (Christen, Duane)
2. RE: Detecting that a submitted batch job is ending from w/in
an RPGprogram. (John Rusling)
3. RE: Detecting that a submitted batch job is ending from w/in
an RPG program. (rob@xxxxxxxxx)
4. RE: Detecting that a submitted batch job is ending from w/in
an RPGprogram. (rob@xxxxxxxxx)
5. Re: Detecting that a submitted batch job is ending from w/in
an RPGprogram. (Alan Campin)

----------------------------------------------------------------------

message: 1
date: Thu, 21 May 2009 08:43:31 -0500
from: "Christen, Duane" <Duane.Christen@xxxxxxxxxx>
subject: RE: Detecting that a submitted batch job is ending from w/in
an RPG program.

The question I have is what clean up would a NEP need to do to close
gracefully?

A NEP shouldn't sleep/dlyjob in the middle of processing a transaction,
when a NEP goes to sleep it should be in a state that would allow for a
fairly clean end. Yes you may have files open etc... but all processing
for a transaction should be complete, and if you use %SntDn between
transactions and/or at recoverable boundaries within a transaction you
should be able to shut down cleanly then. Throw in appropriately
implemented commitment control and I can't imagine (I'm sure someone
can) a situation in which killing the NEP, at any time, would be a
problem.

Duane Christen

--


Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx

Visit PAETEC.COM


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[[2]mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, May 21, 2009 8:10 AM
To: RPG programming on the IBM i / System i
Subject: Re: Detecting that a submitted batch job is ending from w/in an
RPG program.

That exit program is unlike any other's I've seen. Like you said it is
only executed when the command is executed. Which brings us back to the
NEP. A useful parameter, but just not in the context of avoid a NEP.

One of the problems with using a NEP to read a directory and post a file
based on it's existence is that the file may exist, but still be in the
process of being wrote to. We ran into this problem when trying to use
ftp exit points to trap that a file has been put and should now be
posted.
The ftp exit points were designed to check permission, not process data
that's already been posted. Think of it as the exit program to check
stream file open's, not close's. So, in FTP land, we did all sorts of
strange stuff like after you PUT the real data you PUT a dummy file and
we flagged that as go process the real data. Or you ran the RCMD to
post the data. Some customers were flexible - others told us to go
defecate in our hats and pull it down over our ears.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
[3]http://www.dekko.com

From:
Tom Liotta <qsrvbas@xxxxxxxxxxxx>
To:
rpg400-l@xxxxxxxxxxxx
Date:
05/20/2009 06:23 PM
Subject:
Re: Detecting that a submitted batch job is ending from w/in an RPG
program.
Sent by:
rpg400-l-bounces@xxxxxxxxxxxx

rob wrote:

> - Receive Journal Entries exit program. Wait, where is this exit
program?

Rob:

RCVJRNE EXITPGM() -- it's a parameter on the command.

The command includes some selection criteria and other parameters
that should help in making the choice between the command or the
scan exit point, if those are the choices.

RCVJRNE is only going to associate an exit program with objects
related to that journal and only for as long as the command
executes. The Scan on Close exit point is associated with everything
in the root file system and all processes accessing the root file
system (more or less, and depending on configuration).

If I was simply going to monitor a known directory for streamfiles
being deposited, I'd probably start with just reading the directory
entries rather than using either RCVJRNE or the Scan on Close exit
point. I'd only look deeper if other elements brought the need.

Both journaling and scans have many additional considerations that
require thought. For basic monitoring of directory entries, thoughts
_might_ be limited to (1) does a new directory entry exist? and (2)
can I now do something with it, i.e., is anything else still busy
with it? Each loop through the directory entries gives a chance to
test end-status, BTW.

But 'basic' monitoring for existence is a relatively minor task
compared to the capabilities of each of the choices. I'd simply
suggest going with complexity that's appropriate to the requirements.

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone 253-872-7788 x313
253-479-1416
Fax 253-872-7904
[4]http://www.powertech.com
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [5]http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [6]http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [7]http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [8]http://archive.midrange.com/rpg400-l.

------------------------------

message: 2
date: Thu, 21 May 2009 08:54:55 -0500
from: John Rusling <jrusling@xxxxxxxxxxxxxxxxxxx>
subject: RE: Detecting that a submitted batch job is ending from w/in
an RPGprogram.

Thanks for the feedback.

My original listener design read a file to see what folder(s) to
listen to and what action to take when 'something' gets dropped
in this folder. (file drops random and whenever)

As I'm formulating this though, I've dropped the 'read a file' piece
in favor of calling the listener program with parameters. (yesterday)

Thus, detecting ending in the program is less of a factor since, when
the pgm wakes up, it opens ifs folder, reads contents, closes folder,
wakes up again later... repeat. So, i'm less apprehensive about
the cleanup factor and simply using the ENDJOB command.
(added %shtdn too, didn't know it kicked in on endjob as well
as actual shutdown)

When I submit my listener pgm, I want to pass a jobname, program to
process the new file(s), sleep duration, folder to listen to, folder
to archive the file(s) to. Setting it up like this, I should be able
to have any number of listeners (w/ diff job names), listening to
any number of different folders, each can have different sleep
intervals.

Ie, listenjob1 wakes up every 30 minutes, if files exist in folder1,
then processor1 pgm gets submitted to take care of...
listenjob2 wakes up every 2 hours, files exist in folder2, submit
processor2 pgm... etc...

My idea to drop an QUIT.TXT or ENDJOB.TXT file into the folder works
fine, but is impractical for wakeup calls over a couple minutes.
(didn't stop me from trying it though duh...)

Annywaay... to (rpg'er) me it seems simplest to do it this way.

>If I was simply going to monitor a known directory for streamfiles
>being deposited, I'd probably start with just reading the directory
>entries rather than using either RCVJRNE or the Scan on Close exit
>point. I'd only look deeper if other elements brought the need.

K.I.S.S.

>Both journaling and scans have many additional considerations that
>require thought. For basic monitoring of directory entries, thoughts
>_might_ be limited to (1) does a new directory entry exist? and (2)
>can I now do something with it, i.e., is anything else still busy
>with it? Each loop through the directory entries gives a chance to
>test end-status, BTW.

Great ideas! But more than I need or want to bite off right now.

>But 'basic' monitoring for existence is a relatively minor task
>compared to the capabilities of each of the choices. I'd simply
>suggest going with complexity that's appropriate to the requirements.
>
>Tom Liotta

------------------------------

message: 3
date: Thu, 21 May 2009 10:19:38 -0400
from: rob@xxxxxxxxx
subject: RE: Detecting that a submitted batch job is ending from w/in
an RPG program.

Problem is that our instructions say try a few things to shut down
NEP's.
Like run SHTDWNEDI or some such thing for one NEP that does check a data
queue every x minutes. But for those that do not have the data queue or
whatever, then use ENDJOB *cntrld delay(120) on them to give them two
minutes to shutdown. After that the system automatically converts
*cntrld
to *immed. Now, if the process does this:
- delay ends
- start posting
- crap, *IMMED kicks in
then transactions are left hanging.

Don't know if anyone here has ever used %shtdn or commit in rpg or even
if
there is a %shtdn in CL.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
[9]http://www.dekko.com

From:
"Christen, Duane" <Duane.Christen@xxxxxxxxxx>
To:
"'RPG programming on the IBM i / System i'" <rpg400-l@xxxxxxxxxxxx>
Date:
05/21/2009 09:47 AM
Subject:
RE: Detecting that a submitted batch job is ending from w/in an RPG
program.
Sent by:
rpg400-l-bounces@xxxxxxxxxxxx

The question I have is what clean up would a NEP need to do to close
gracefully?

A NEP shouldn't sleep/dlyjob in the middle of processing a transaction,
when a NEP goes to sleep it should be in a state that would allow for a
fairly clean end. Yes you may have files open etc... but all processing
for a transaction should be complete, and if you use %SntDn between
transactions and/or at recoverable boundaries within a transaction you
should be able to shut down cleanly then. Throw in appropriately
implemented commitment control and I can't imagine (I'm sure someone
can)
a situation in which killing the NEP, at any time, would be a problem.

Duane Christen

--


Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx

Visit PAETEC.COM


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[[10]mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of rob@xxxxxxxxx
Sent: Thursday, May 21, 2009 8:10 AM
To: RPG programming on the IBM i / System i
Subject: Re: Detecting that a submitted batch job is ending from w/in an
RPG program.

That exit program is unlike any other's I've seen. Like you said it is
only executed when the command is executed. Which brings us back to the
NEP. A useful parameter, but just not in the context of avoid a NEP.

One of the problems with using a NEP to read a directory and post a file
based on it's existence is that the file may exist, but still be in the
process of being wrote to. We ran into this problem when trying to use
ftp exit points to trap that a file has been put and should now be
posted.

The ftp exit points were designed to check permission, not process data
that's already been posted. Think of it as the exit program to check
stream file open's, not close's. So, in FTP land, we did all sorts of
strange stuff like after you PUT the real data you PUT a dummy file and
we
flagged that as go process the real data. Or you ran the RCMD to post
the
data. Some customers were flexible - others told us to go defecate in
our
hats and pull it down over our ears.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
[11]http://www.dekko.com

From:
Tom Liotta <qsrvbas@xxxxxxxxxxxx>
To:
rpg400-l@xxxxxxxxxxxx
Date:
05/20/2009 06:23 PM
Subject:
Re: Detecting that a submitted batch job is ending from w/in an RPG
program.
Sent by:
rpg400-l-bounces@xxxxxxxxxxxx

rob wrote:

> - Receive Journal Entries exit program. Wait, where is this exit
program?

Rob:

RCVJRNE EXITPGM() -- it's a parameter on the command.

The command includes some selection criteria and other parameters
that should help in making the choice between the command or the
scan exit point, if those are the choices.

RCVJRNE is only going to associate an exit program with objects
related to that journal and only for as long as the command
executes. The Scan on Close exit point is associated with everything
in the root file system and all processes accessing the root file
system (more or less, and depending on configuration).

If I was simply going to monitor a known directory for streamfiles
being deposited, I'd probably start with just reading the directory
entries rather than using either RCVJRNE or the Scan on Close exit
point. I'd only look deeper if other elements brought the need.

Both journaling and scans have many additional considerations that
require thought. For basic monitoring of directory entries, thoughts
_might_ be limited to (1) does a new directory entry exist? and (2)
can I now do something with it, i.e., is anything else still busy
with it? Each loop through the directory entries gives a chance to
test end-status, BTW.

But 'basic' monitoring for existence is a relatively minor task
compared to the capabilities of each of the choices. I'd simply
suggest going with complexity that's appropriate to the requirements.

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone 253-872-7788 x313
253-479-1416
Fax 253-872-7904
[12]http://www.powertech.com
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [13]http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [14]http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [15]http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [16]http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [17]http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [18]http://archive.midrange.com/rpg400-l.

------------------------------

message: 4
date: Thu, 21 May 2009 10:32:38 -0400
from: rob@xxxxxxxxx
subject: RE: Detecting that a submitted batch job is ending from w/in
an RPGprogram.

Problems include:

If you're delaying for 30 minutes and someone runs
ENDSBS SBS(*ALL) OPTION(*CNTRLD) DELAY(120)
your delay may not wake up to check %shtdn before the two minutes expire
and it does an end *IMMED.

Option: Submit yet another NEP. It only delays 30 seconds or less.
Checks
for %shtdn and submits off data queue entries, drops in stream files
here
and there and does what it takes to get the other jobs to end
gracefully.
Problem: Would work fine on queue driven programs like message queues
and
data queues but wouldn't do squat on programs that sleep for 30 minutes
and then checks for a stream file entry. But you already knew that with
your QUIT.TXT discussion below.

Work around. Two jobs instead of one? 30 minutes stream file program
does nothing upon wake up except check %shtdn. If no %shtdn then check
for stream file, if stream file exists then send data queue entry. Go
back
to sleep. If it dies with *IMMED who cares? Second job would process
the
data queue and only sleep for a minute or less. If it gets the QUIT
entry
in the data queue then die. If it wakes up and detects %shtdn then die,
otherwise, post data.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
[19]http://www.dekko.com

From:
John Rusling <jrusling@xxxxxxxxxxxxxxxxxxx>
To:
"'rpg400-l@xxxxxxxxxxxx'" <rpg400-l@xxxxxxxxxxxx>
Date:
05/21/2009 10:06 AM
Subject:
RE: Detecting that a submitted batch job is ending from w/in an
RPGprogram.
Sent by:
rpg400-l-bounces@xxxxxxxxxxxx

Thanks for the feedback.

My original listener design read a file to see what folder(s) to
listen to and what action to take when 'something' gets dropped
in this folder. (file drops random and whenever)

As I'm formulating this though, I've dropped the 'read a file' piece
in favor of calling the listener program with parameters. (yesterday)

Thus, detecting ending in the program is less of a factor since, when
the pgm wakes up, it opens ifs folder, reads contents, closes folder,
wakes up again later... repeat. So, i'm less apprehensive about
the cleanup factor and simply using the ENDJOB command.
(added %shtdn too, didn't know it kicked in on endjob as well
as actual shutdown)

When I submit my listener pgm, I want to pass a jobname, program to
process the new file(s), sleep duration, folder to listen to, folder
to archive the file(s) to. Setting it up like this, I should be able
to have any number of listeners (w/ diff job names), listening to
any number of different folders, each can have different sleep
intervals.

Ie, listenjob1 wakes up every 30 minutes, if files exist in folder1,
then processor1 pgm gets submitted to take care of...
listenjob2 wakes up every 2 hours, files exist in folder2, submit
processor2 pgm... etc...

My idea to drop an QUIT.TXT or ENDJOB.TXT file into the folder works
fine, but is impractical for wakeup calls over a couple minutes.
(didn't stop me from trying it though duh...)

Annywaay... to (rpg'er) me it seems simplest to do it this way.

>If I was simply going to monitor a known directory for streamfiles
>being deposited, I'd probably start with just reading the directory
>entries rather than using either RCVJRNE or the Scan on Close exit
>point. I'd only look deeper if other elements brought the need.

K.I.S.S.

>Both journaling and scans have many additional considerations that
>require thought. For basic monitoring of directory entries, thoughts
>_might_ be limited to (1) does a new directory entry exist? and (2)
>can I now do something with it, i.e., is anything else still busy
>with it? Each loop through the directory entries gives a chance to
>test end-status, BTW.

Great ideas! But more than I need or want to bite off right now.

>But 'basic' monitoring for existence is a relatively minor task
>compared to the capabilities of each of the choices. I'd simply
>suggest going with complexity that's appropriate to the requirements.
>
>Tom Liotta
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [20]http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [21]http://archive.midrange.com/rpg400-l.

------------------------------

message: 5
date: Thu, 21 May 2009 08:35:34 -0600
from: Alan Campin <alan0307d@xxxxxxxxx>
subject: Re: Detecting that a submitted batch job is ending from w/in
an RPGprogram.

Thing you have to be careful with this design is your program checks and
finds something and then starts processing. The problem being that the
file
may not have already been written. You catch it in mid write. That is
why I
went to the journal entries because they are not written until the file
is
closed. Anyway, just a heads up.

On Thu, May 21, 2009 at 7:54 AM, John Rusling
<jrusling@xxxxxxxxxxxxxxxxxxx>wrote:

> Thanks for the feedback.
>
> My original listener design read a file to see what folder(s) to
> listen to and what action to take when 'something' gets dropped
> in this folder. (file drops random and whenever)
>
> As I'm formulating this though, I've dropped the 'read a file' piece
> in favor of calling the listener program with parameters. (yesterday)
>
> Thus, detecting ending in the program is less of a factor since, when
> the pgm wakes up, it opens ifs folder, reads contents, closes folder,
> wakes up again later... repeat. So, i'm less apprehensive about
> the cleanup factor and simply using the ENDJOB command.
> (added %shtdn too, didn't know it kicked in on endjob as well
> as actual shutdown)
>
> When I submit my listener pgm, I want to pass a jobname, program to
> process the new file(s), sleep duration, folder to listen to, folder
> to archive the file(s) to. Setting it up like this, I should be able
> to have any number of listeners (w/ diff job names), listening to
> any number of different folders, each can have different sleep
intervals.
>
> Ie, listenjob1 wakes up every 30 minutes, if files exist in folder1,
> then processor1 pgm gets submitted to take care of...
> listenjob2 wakes up every 2 hours, files exist in folder2, submit
> processor2 pgm... etc...
>
> My idea to drop an QUIT.TXT or ENDJOB.TXT file into the folder works
> fine, but is impractical for wakeup calls over a couple minutes.
> (didn't stop me from trying it though duh...)
>
> Annywaay... to (rpg'er) me it seems simplest to do it this way.
>
>
> >If I was simply going to monitor a known directory for streamfiles
> >being deposited, I'd probably start with just reading the directory
> >entries rather than using either RCVJRNE or the Scan on Close exit
> >point. I'd only look deeper if other elements brought the need.
>
> K.I.S.S.
>
> >Both journaling and scans have many additional considerations that
> >require thought. For basic monitoring of directory entries, thoughts
> >_might_ be limited to (1) does a new directory entry exist? and (2)
> >can I now do something with it, i.e., is anything else still busy
> >with it? Each loop through the directory entries gives a chance to
> >test end-status, BTW.
>
> Great ideas! But more than I need or want to bite off right now.
>
> >But 'basic' monitoring for existence is a relatively minor task
> >compared to the capabilities of each of the choices. I'd simply
> >suggest going with complexity that's appropriate to the requirements.
> >
> >Tom Liotta
> --
> This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: [22]http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at [23]http://archive.midrange.com/rpg400-l.
>
>

------------------------------

--
This is the RPG programming on the IBM i / System i (RPG400-L) digest
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [24]http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [25]http://archive.midrange.com/rpg400-l.

End of RPG400-L Digest, Vol 8, Issue 387
****************************************

This email is intended only for the person or entity
to which it is addressed and may contain information
that is privileged, confidential or otherwise protected
from disclosure. If you are not the named addressee
or an employee or agent responsible for delivering
this message to the named addressee, you are not
authorized to read, print, retain copy, and disseminate
this message or any part of it. If you have received this
message in error please notify us immediately by email,
discard any paper copies and delete all electronic files
of this message.

References

Visible links
1. http://lists.midrange.com/mailman/listinfo/rpg400-l
2. mailto:rpg400-l-bounces@xxxxxxxxxxxx
3. http://www.dekko.com/
4. http://www.powertech.com/
5. http://lists.midrange.com/mailman/listinfo/rpg400-l
6. http://archive.midrange.com/rpg400-l
7. http://lists.midrange.com/mailman/listinfo/rpg400-l
8. http://archive.midrange.com/rpg400-l
9. http://www.dekko.com/
10. mailto:rpg400-l-bounces@xxxxxxxxxxxx
11. http://www.dekko.com/
12. http://www.powertech.com/
13. http://lists.midrange.com/mailman/listinfo/rpg400-l
14. http://archive.midrange.com/rpg400-l
15. http://lists.midrange.com/mailman/listinfo/rpg400-l
16. http://archive.midrange.com/rpg400-l
17. http://lists.midrange.com/mailman/listinfo/rpg400-l
18. http://archive.midrange.com/rpg400-l
19. http://www.dekko.com/
20. http://lists.midrange.com/mailman/listinfo/rpg400-l
21. http://archive.midrange.com/rpg400-l
22. http://lists.midrange.com/mailman/listinfo/rpg400-l
23. http://archive.midrange.com/rpg400-l
24. http://lists.midrange.com/mailman/listinfo/rpg400-l
25. http://archive.midrange.com/rpg400-l