Our customers began telling us otherwise early this year. Programs in versions as late as Release 11 of MANMAN have references to 9999 as a special date. A client called in with a problem associated with adding a work order using AD300 in the manufacturing module. That one only affects those MANMAN sites that use ECOs extensively. There are no database corruption problems that we know about.

After some investigation, our client’s problem turned out to be caused by a subroutine called GETREVS in the SSOURCE group. We found a setting for REVOBS to the value 10000 in four different places. This error is in the system all the way through the MANMAN 9.6 release. It was corrected in versions generated on or after May 16, 1994.

Our single discovery sent us on a scavenger hunt for other “opportunities,” as we call them. And we found them. In all, we located a dozen programs with the integer value checks that could cause problems in some form in MANMAN releases 7 through 11. In our page 6 figure we identify what we found, and how to fix the programs.

Keep in mind that the code we have identified only shows results from searching different versions of the MANMAN systems within our client base. It may not include all possible occurrences of this bug, especially in any of the other modules of the MANMAN system, since we have only audited the “core 4” MANMAN systems as of the time of this article. Some source code files are present but not used. Other code is relevant to the use of specific functions, and may or may not apply to how you use your system.

The programs listed in our table require changes as noted to the source code, compiling it into the correct RL, and then recreating the dispatchers (LINKMAN, unless you are on an older version of MANMAN). In three of these cases, the recompiling and linking of stand-alone routines is required. Be sure to correct any customized code where one of these routines was used as the base program. And one more thing: Document the program as you modify it, both in the lead-in section and at each change in the code. Please.

Program: ADDSHPS.FSOURCE
Code is: TAXDAT=9999
Should be: TAXDAT=32767
Effects releases 7 thru 10, fixed on 07/25/97. This field, TAXDAT, is not used in the noted releases.

Program: MA140S.FSOURCE
Code is: IF(QUOSTAT_S2.NE.”OPEN “.AND.(JD_DATE.EQ.0.OR.JD_DATE.EQ.9999))THEN
Should be: IF(QUOSTAT_S2.NE.”OPEN“.AND.(JD_DATE.EQ.0.OR.JD_DATE.EQ.32767))THEN
This is a major bug as it is used in character to integer conversion for the date. Effects releases 7 thru 11.

Program: DATOPTS.MSOURCE
Code is: IF(STARTDAT.NE.9999) GOTO 29
Should be: IF(STARTDAT.NE.32767) GOTO 29
Effects releases 7 thru 11.

Program: DTMPPOS.MSOURCE
Code is: IF((DDUE.EQ.0).OR.(DDUE.EQ.9999)) THEN
Should be: IF((DDUE.EQ.0).OR.(DDUE.EQ.32767)) THEN
Effects releases 7 thru 11.

Program: LI102S.MSOURCE
Code is: IF(SDDATE.EQ.9999)IREQDAT=9999
Should be: IF(SDDATE.EQ.32767)IREQDAT=32767
Effects releases 7 thru 10, fixed on 07/22/97.

Program: RE308S.MSOURCE
Code is: IF(STARTBUC(K).EQ.0.OR.ENDBUC(K).EQ.9999) WRITE(UNIT,1080)
Should be: IF(STARTBUC(K).EQ.0.OR.ENDBUC(K).EQ.32767) WRITE(UNIT,1080)
This code apparently writes a blank line to the output device. Effects releases 7 thru 11.

Program: RE920S.MSOURCE
Code is: IF(NO_SAFETY.AND.PTFDAT.LT.9999.AND….) in two places
Should be: IF(NO_SAFETY.AND.PTFDAT.LT.32767.AND…..)
Effects releases 7 thru 11.

Program: UT308S.MSOURCE
Code is: IF(WOPCD.EQ.9999) GOTO 880
Should be: IF(WOPCD.EQ.32767) GOTO 880
Effects releases 7 thru 11.

Program: RE369S.RMSOURCE
Code is: IF((ENDDATE.EQ.RTEFF).AND.(RTOBS.NE.99999999))GOTO 150
Should be: IF((ENDDATE.EQ.RTEFF).AND.(RTOBS.NE.32767))GOTO 150
Effects releases 8 thru 11, it may or may not be present in Version 7.

Program: T3011328.MSOURCE
Code is: RQADAT=10000
Should be: RQADAT=32767
This bug is in Version 7 only and is apparently not used.

Program: GETREVS.SSOURCE
Code is: REVOBS=10000 (appears four(4) times)
Should be: REVOBS=32767
Effects releases 7 thru 11. This code was fixed on 05/16/94 in Version 9.6 of the system.

We contacted all of the Support Group inc. clients by e-mail or phone before March 16 to clear this up. For them, this situation will probably be all over by the time you read this article. If you’d like our help in resolving any of these types of errors, please let us know at 800.798.9862.

David Floyd and Rob Gentry are support engineers at the Support Group inc., a manufacturing application support provider in Austin, Texas.