Posted by Brian Levantine on Mon, 8 Sep 2003 09:13:43 :
Brian Levantine
brian@signature.net
----- Original Message -----=20
From: smoore=20
To: Brian Levantine=20
Cc: jim donahue=20
Sent: Monday, September 08, 2003 9:09 AM
Subject: Re: IB & Printer Appearances
After writing a small program to duplicate the problem, I found that I =
could not do so. Furthermore, what I did find was this:
%MPS LET HEXCOST =3D HQTYPC * ((HUCOST * 1.0000) / HQTYU)
%MCR LET HEXCOST =3D (((HUCOST / HQTYU) * 1.0000) * HQTYPC)
When I corrected %MCR to LET HEXCOST =3D (((HUCOST * 1.0000) / =
HQTYU) * HQTYPC) , everything was fine.
I used HQTYPC =3D 100, HUCOST =3D 1.35, and HQTYU =3D 3031.1
%MCR before correction, let 1.35/100 =3D .01 (not .0135) * 1.0000 =3D =
1.00 * 3031.1 =3D 30.31
%MCR after correction, let (1.35*1.000)/100 =3D .0135 * 3031.1 =3D 40.92
I made the mistake in assuming COMET reacted differently than QANTEL, =
but in reality, it was a construct error.
Sorry for my erroneous conclusions earlier.
Steven Moore - "Still Learning"
JIM: This explains why after running the MCR the unit costs in MPS =
stayed the same but the extended costs changed. The math error only =
effected the extended costs. All is working fine today.
----- Original Message -----=20
From: Brian Levantine=20
To: smoore@mooregreens.com ; Multiple recipients of list support=20
Sent: Friday, September 05, 2003 01:34 PM
Subject: Re: IB & Printer Appearances
Hi Steve. There is no way to suppress the escape codes without =
modifying the program source. Yes - using the DSTAT function it is =
possible for a program to determine the Windows name of the printer and =
thus make the necessary adjustments to include\exclude any escape codes. =
For the precision problem could you please send me a small sample =
program that demonstrates the problem?
Brian Levantine
brian@signature.net
----- Original Message -----=20
From: smoore=20
To: Multiple recipients of list support=20
Sent: Friday, September 05, 2003 8:05 AM
Subject: IB & Printer Appearances
05 September 2003
Hello Support:
Moore Greens Inc. =95 From the desk of Steven Moore
We are running Comet 2000 build 293.
-----------------------------------------------------
We use escape codes in some of our IB programs. Most of the time it =
is to turn on/off bold, expanded, or italicized print. These are for HP =
DeskJet's and LaserJet's.
As these codes are hard written in the print formats, when choosing =
to print to LPT, or any non-HP printer, the escape sequence gets =
displayed both before and after our titles.
Is there a way to suppress escape codes from printing on paper or =
terminal printers as '1B2e55' etc. or is it left to programming to test =
for printer type, and use format HP for HP printers, and format NHP for =
non-HP printers?
-----------------------------------------------------
We have declared in the ini file a terminal printer LPT. I have =
been using QREPORT to run programs with output to PRINTER LPT. When I =
do this, I get 3-boxes at the end of some lines. Also, when running an =
IB program, any instance of (LF) gets displayed as 3-boxes. =20
While I have a workaround for the IB issue, I replace (LF), with =
(CR);'@20@';(CR) and all is fine. I cannot fix the QREPORT issue. Is =
this due to my choices? Is there a fix with newer releases?
------------------------------------------------------
This problem has been long lived. I only noticed it recently =
though.
I have an IB program that is a compound equation. XX =3D XQTY * =
((1.0000*XUNITPC)/XQUNIT) where it is similar to xunitpc =3D 12 and =
xqunit =3D 245 and xx is declared 9.2 which in reading on website, seems =
to be the problem.
In the old Qantel days, including 1.0000 expanded the natural length =
of calculation. IB does not do that. The resultant controls the =
length. Is this corrected in newer version of Comet? =20
I thought of a workaround as declaring a new system variable VARCLC =
as 18.9, and ROUND, and letting VARCLC =3D (original compound equation) =
then next line letting (original resultant) =3D VARCLC. I have tested =
this out and now resultants are accurate. Any time an equation went =
beyond X.2 to the right, it was blown away. Lucky for us, it was never =
an issue on commission and cost reports. But it did have a major impact =
on our manufacturing modules!
---------------------------------------------------