Re: This way or that? -- MIDRANGE-L

I have wondered if a successful algorithm for this situation is to install 
the software package on a new box, and then migrate the data you still 
want to the new box, and not take the accumulated trash of 15 years with 
you?
_______________________
Booth Martin
booth@martinvt.com
http://www.MartinVT.com
_______________________




MacWheel99@aol.com
Sent by: owner-midrange-l@midrange.com
06/10/2000 01:26 AM
Please respond to MIDRANGE-L

 
        To:     MIDRANGE-L@midrange.com
        cc: 
        Subject:        Re: This way or that?

From Al Macintyre

I love these educational discussions, although I am not competent to fully 

participate in them all.

Kenneth, 

We have a similar situation with BPCS ... Users transactions go into a 
member 
named after their work station sharing the external description of the 
file 
to which the data will ultimately end up in.  I have lost track of how 
many 
files do this, but it is systemic to the whole package. 

Of our almost 50 current users, perhaps 30 at most need access to any 
given 
file with this phenomena, but since we name work stations after 
departmental 
locations, and have gone through a variation in remote connection 
protocols, 
there are these member names dating back to years ago development no 
longer 
needed & many of them are from the original SSA developers, coming with 
the 
package for work station addresses we never had. 

Most of our files have the 30 we need & 100 members we do not need.

These files also have many logicals ... I think the most I have seen for 
any 
one file is 100. 

We did have a conversation with SSA tech support regarding the records 
soft 
coded for deletion & hard coded that are never removed & learned that in 
really large files (our largest is like 2 million records), that are being 

used vigorously during the day, there is a performance hit searching for a 

place to add records if deleted spaces are to be reused ... the upshot of 
this discussion is we left that alone, & run a large scale file reorg to 
remove deleted records approx weekly.

In my to-do list of programming assignments is "Garbage Incineration" 
since 
we have learned that BPCS 405 CD System Parameters for History Retention 
not 
withstanding, some files are NEVER purged by the system, so for example in 

addition to under 1,000 valid customer orders we have over 5,000 
historical 
filled orders we want to get rid of. 

If you too are on BPCS, there is a 3rd party solution to clean up all of 
this, called BPCS LITE from UPI, which also addresses the issue of the ERP 

creating files for every conceivable client contingency.

James

In an earlier flirtation with "Garbage Incineration" I removed individual 
lines from files where the contents we no longer needed & discovered that 
I 
had caused a disaster ... most of the files use multi-field index access 
in 
which the last field is a sequence # ... some programs do not track what 
all 
they need to find.

Read next sequence # --- successful read? --- left justified fields still 
the 
same baby? --- Ok, process that & loop

Except by me erasing individual lines in the middle, it would go from line 

0001 to line 0050 & because 0002 was missing, that was a failed access, 
and 
it quit right there, so I need to study the application & see if I need to 

resequence the sequence #s when I remove garbage from the middle.

I do not know precisely what is going on with BOM, but a collegue at a 
neighbor company also using BPCS warned me NOT to use IBM tools to reorg 
that 
file ... they had done so & it trashed their BOM, related to the use of 
record numbers for access that IBM reorg not easily notice ... you HAVE to 

use the BOM reorg tools that come with the package, which incidentally 
default to non-compliant Y2K dates.

Joel

I use similar standards to SSA approach in some of my programs, but at end 
of 
CL after successful processing, I clear the member, on the theory that 
some 
disk space will be reclaimed & when I am noodling around with DSPFD it is 
almost easy to see candidates for manual deletion.

In BPCS ... One person can work at some work station address, then sign 
off, 
then someone else sign on at the same work station & get into the same 
batch, 
because they are keyed on environment & application & work station, not 
user.

We once had a scenario with a hardware failure in mid batch, in which the 
hardware could not be rapidly resolved & the user had spent all day keying 

into this unfinished task & pleading with IT to save their bacon.  Part of 

our recovery was to rename work members so another work station could 
recover 
the job.

If I was designing Ken's scenario, I would include several pieces of 
software 
that SSA neglected.

1. Run the member names against our WRKSYSCFG valid addresses & if the 
member 
has no active records & the member name has no corresponding valid work 
station, then delete that member.

2. Any member names that exist that are empty & have not been used in some 

reasonable time period like 1 month, erase them also ... allow for folks 
on 
vacation.

3. Also run BPCS security against AS/400 security & get rid of stuff on 
people no longer working for our company ... you can add BPCS security for 

new people but you cannot purge the old folks, other than to take them off 
of 
AS/400 security.

Now SSA does have some software to recover batch from a user session that 
abnormally terminated, which we need to use occasionally.

I am on BPCS_L & all of my points have come up in past threads there, 
although some not recently.

Al Macintyre  ���
http://www.cen-elec.com MIS Manager Programmer & Computer Janitor
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to 
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: 
david@midrange.com
+---




+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---