We're running ceridian's HR-1, version 5.52 (ARev 3.02) with NLM 1.5. We have an R/Basic routine which imports data into EMP (not always a good idea, but stuck with it) and is actually quite straightforward, setting up an EMP record variable, then writing it, after having set the variable into @Record and the desired key into @ID. The problem is that the STATUS field, which has AUDITING on, does not always generate CHANGES record. In tests with the same 4 records to be imported, we get everything from only one of the records generating a STATUS changes record to all 4 of them generating a STATUS changes record, and every conceivable combination in between. The order of writes does not seem to matter, nor does the specific content of the import records. All 4 are new hires, and thus all 4 should generate a changes record with an old value of null and a new value of A. Has anyone seen anyhting reembling this behavior? Could Audit Groups (we have several monitoring status, most seemingly more than a little ju
nky) be interfering with CHANGES records?
I've seen this before on DOS/Novell HR-1 systems (e.g. NLM is not a factor). Usually due to low string space conditions. Optimize the DOS window settings to give maximum amount of conventional memory. Fiddle around with the expand memory settings also, sometimes ARev runs better without EMS.
We had a similar problem that was the result of running out of space on the program stack. The main culprit was the EMP1 screen. In a test mode, I added a perpetual process that displayed the number of entries on the program stack in the upper-left corner of the screen. As the user traversed the screen, you could see the number growing. The number was higher on the (2*n)th record (every other record starting at the second one). I don't have an explanation for that one, but the resolution was twofold.
I modified the main commuter routine to check the program stack for sufficient available entries before allowing the process to continue else display an error message.
Train the users to exit the screen between records.
Of course the best solution would be to redesign the screen, but considering the lifespan of the product (it will be replaced with Seeker) a decision was made not to do this.
I don't know if this addresses your problem or not, but at least it's something to look at. Email me if you would like a copy of the program to display the number of entries in the program stack. I think it's still around somewhere.
Thanks to Both! I had not thought of program stack issues, but I'll investigate. This program is not called from a screen, however there are 11 audit groups called in sequence, each of which calls, of course, group.execute, plus we've got emp3.sub, emp3.audit,sub, etc., being called by the audit groups.
Quite an irritating problem, as the manifestation is not consistent.
Steve:
MEMORY. Plain and simple. Audit groups take a lot to fire, especially the ones that deal with salaries and status. EMP1 is the worst. Warren's advice is good. He's had to deal with this more than once at a client . Try to get every byte possible available in conventional. Make certain the EMS has 2 - 4MB too. Then test memory and remove EMS if it doesn't help the base memory at WHO.
Feel free to call and/or ask on Arev-fans if you need more help.
Good luck,
Bryan deSilva
Improvisations.net – "innovation by design"
Voice 970/352-4711
Fax 970/392-1499
Email bryan_desilva@improvisations.net
To join one of our helpful mailing lists click on the appropriate link below and send a blank email to:
PeopleSoft-Fans-Subscribe@egroups.comArev-Fans-Subscribe@egroups.com
Thanks to all for the point in the direction of memory. To be certain, there have been irresponsible hands on this system in the past, leading to a proliferation of audit groups and to audit groups calling larger programs than they should as well as calling programs containing nested calls to other programs. Absolute lack of design skills, IMHO, but, there I go again……
Anyhoo, given that the program we were using to update the EMP file via R/Basic was dictionary-based, we were able to easily modify the program so that it does grouped, discrete writes, first to only those fields associated with EMP1, then those assciated with EMP2, then those associated with EMP3 (which is the real killer in terms of memory). Obviously, it takes a little longer this way, but with the NLM, a huge memory pool on the server, and P133 workstations, it is still fine. The problem is gone completely.
If you haven't resolved this let me know. I have run into this before.
Original design and prior updates allowed for audits to overwrite one another as well as the addition of the post-process and validation routines. Some tried to hide the coding there.
It sounds like you took a good approach.
Congratulations on your success!