Qbasic cvs problem

[Michael Mattias]

>The same code in PB9 gives a different result... thanks...

Which code?

Better still, show failing code and provide test data along with expected results.

Or... if you are saying ...

CVS(four byte string) [PB 7] <>  CVS (same four-byte string)[PB 9]

.. then that problem has to go directly to PB support, because either the 7x or 9x CVS function is broken. Of course, you will know which one because you must be testing against known data.

If it's 7x that's broken....

... well, don't bother reporting it because it ain't gonna get fixed. Well, give it a shot, but I'd think the best you could do if 7x is broken is to break down and cry and hope they give you a free or reduced-cost upgrade; but today's related health tip is "Don't hold your breath."

MCM

[dean goodman]

CVS issue

I just noticed an issue with CVS as well today. I am trying to convert seismic segy data, and running an older version of the software with PB7 works fine. Can someone else test the CVS issue. The same code in PB9 gives a different result... thanks...

[John Petty]

Good advice Michael, thankyou. Yes, we are testing many times, actually the code needed to be cleaned up so we recompiled after the cleanup (although some programs could not be compiled - too big and I don't know how the author got them to compile).

In properties for BC.exe "Memory" have you given it a good chunk of EMS and XMS memory? I forget which one it uses so give it a few MB of both.

[Dan English]

Testing...

Good advice Michael, thankyou. Yes, we are testing many times, actually the code needed to be cleaned up so we recompiled after the cleanup (although some programs could not be compiled - too big and I don't know how the author got them to compile).

I have someone running the original code along side the cleaned up code with the same data (copy it back and forth) to be sure that works.) The next step will be running the same data with the PowerBasic code, compare reports trial balance etc.

We will leave the data alone for now until the windows rewrite is well along. Fortunately we have all the original file layouts so writing conversion programs should be straight forward.

[John Petty]

Call me old-fashioned, but recompiling and retesting all the programs (you WERE going to retest, right?) sure sounds like converting all the programs.

But now that we have learned this software is installed at multiple user sites.... I don't think I'd bother converting the data.
MCM

Of course you retest on a sample data base, remembering the change I listed didn't change a single line of code in all the actual programs merely a compiler option from back in the days when MS compilers were much more reliable.
You tell us how long you have been programming so from your comments are you saying all your programs still use MBF number formats, very ineficient.
Are you saying you never do a data base upgrade? I have done many (either writing or supervising) including bringing my own early apps from MBF to IEEE.
The more you post the more I begin to understand that your actual experience with more than your own application is rather limited.

[Michael Mattias]

Not really Michael, He has the batch files for the compilation so most likely the BC compiler is present so after the conversion he just has to recompile any other programs without the /MBF option in the batch files and they will work fine.

Call me old-fashioned, but recompiling and retesting all the programs (you WERE going to retest, right?) sure sounds like converting all the programs.

But now that we have learned this software is installed at multiple user sites.... I don't think I'd bother converting the data.

A, Not all customers will run the conversion in the correct sequence (given enough customers, there will always be one who could mess up a free lunch).

B, For sure they won't run the conversions on the same day, meaning I am now supporting multiple versions, at least for a while.

C, Customers may have written their own "QuickBASIC" or other programs AGAINST that data - eg some extra screens and/or reports - and converting the data breaks those programs. This will not earn you points with your customers. (I am not the only person who complains about "backward incompatibility").

D, for every customer who successfully navigates A, B, and C, there will be at least one who manages to archive the wrong set of programs, the wrong set of data or both... and the day they decide to bring back EITHER ONE BUT NOT BOTH programs and data, you have a total and absolute disaster.

For this application, MBF format sounds real good, forever.

MCM

[Dan English]

The conditions

Just as a matter of interest (since there seems to be some), the reason we are doing this is money of course! This app is 20 years old, its an accounting and payroll app with customers that are willing to pay to have it converted and upgraded. I know there are many apps out there that can do the job but when customers are willing to pay to keep the look and feel who are we to argue. The first step was cleanup of the QuickBasic code, then convert to PowerBasic CC which was almost done when this CVS issue showed up. Now we will start a re-write in windows keeping the look and feel similar to the old app. The last step will be changing the data base. Thanks again for all the help.

[John Petty]

Well, the 'conditions' are not stated, but if other programs which read and write that data are still in service, you could not convert that data unless you converted ALL the programs in the application suite... at the same time.
MCM

Not really Michael, He has the batch files for the compilation so most likely the BC compiler is present so after the conversion he just has to recompile any other programs without the /MBF option in the batch files and they will work fine.
As the program is done in version 7 if I were Dan I would be more worried as to why it is using the Es option.

[Manuel Valdes]

Not knowing the backward compatibility issues, or in general the compatibility issues involved in the program conversion, it's quite risky to advise in one sense or the other. If not compatibility problems are present, then I think John is right; it's better to go standard. Also there are precision differences between the IEEE standard and MBF, which may or may not be relevant, depending on the program purpose.

[Arthur Gomide]

> Are you seriously suggesting that any competent programmer would leave the data in the old format and so require your level of documentation?

I think the problem is not about the power of this or that developer - perhaps there is a need to do it this way!

[Michael Mattias]

wouldn't an experienced programmer like you write a one time conversion of the data

Well, the 'conditions' are not stated, but if other programs which read and write that data are still in service, you could not convert that data unless you converted ALL the programs in the application suite... at the same time.

So let's say I have made a good guess about this; that means the new PB program needs to use the CVMS functions in that DLL; that means the param to same must be a string, and if converting it from FIELD to STRING by adding extra parens, I think the comment is a good idea for the reasons stated therein.

MCM

[John Petty]

Gee Micheal wouldn't an experienced programmer like you write a one time conversion of the data. Are you seriously suggesting that any competent programmer would leave the data in the old format and so require your level of documentation? Is that what you are suggesting?

[Michael Mattias]

Z=CVMS((FC))

===>

Z=CVMS((FC))  ' use extra parens to force conversion of value to correct data type
             ' use comment so when I look at this in six months I won't have 
             ' to wonder why I did this; also so if someone else works on this 
             '  program they don't 'help' by taking out the 'superfluous' parens 
             ' and then come whining to me the program doesn't work anymore.

[Steve Rossell]

You do not need to convert the FIELD string to a string first, you can let the compiler do it for you by

...
LOCAL FC AS FIELD
...
Z=CVMS((FC))
...

[Dan English]

Solved

Thanks for all the responses, we have a solution. The only additional change is that a FIELD is not exactly the string the function was expecting. We had to change the field to a string then use the CVMS function on the string. It works great!

[Michael Mattias]

The CVMS and CVMD functions hould be declared with param "AS STRING."

I only used the word FIELD because you had FIELDed a buffer in you code... I FORGOT there is now a "FIELD" data type in PB and I should never have used that (now magic) word in this post.

As far as the GPF... if you don't have data that might be the problem. ie., file 'gwbf.bin' not found, and was created empty, meaning you would be passing garbage to the CVMS function.

[Arthur Gomide]

#COMPILE EXE
#DIM ALL

' PowerBASIC declarations for MSBF.DLL functions
DECLARE FUNCTION CVMS LIB "MSBF.DLL" (x AS STRING) AS SINGLE
DECLARE FUNCTION MKMS LIB "MSBF.DLL" (BYVAL s AS SINGLE) AS STRING
DECLARE FUNCTION CVMD LIB "MSBF.DLL" (x AS STRING) AS DOUBLE
DECLARE FUNCTION MKMD LIB "MSBF.DLL" (BYVAL d AS DOUBLE) AS STRING

FUNCTION PBMAIN () AS LONG

    LOCAL s,d AS FIELD
    'local a as single
    'local b as double

    OPEN "gwbf.bin" FOR RANDOM AS #1 LEN=12
    FIELD #1, 4 AS s, 8 AS d
    GET #1,1
    'FIELD STRING s,d
    'CLOSE #1
    PRINT CVMS(s); CVMD(d)

    WAITKEY$
    CLOSE #1


END FUNCTION


PowerBASIC Console Compiler
PB/CC   Version 5.01 
Copyright (c) 1998-2009 PowerBasic Inc.
Venice, Florida USA
All Rights Reserved

Error 480 in F:\PBCC50\Cvrtgwbf.bas(21:017):  Parameter mismatches definition
Line 21:     PRINT CVMS(s); CVMD(d)

If I change the "x as string" to "x as field" in declares it compiles but I receive a gpf.

[Guy Dombrowski]

I often sit with not a heck of a lot to do

Now we know the real reason for those 22k post from MCM

[John Petty]

Of course if you still have QuickBasic they have the conversion functions as standard ie CVSMBF and CVDMBF so you should be able to write a converter. They were still there in my copies of QB4.5 and BC7.1, can't quickly find my Windows for DOS 1 but think they were in that as well. Default mode for all the was IEEE.

[Michael Mattias]

>Must be a "string variable" here

Forgot... there now is a type FIELD variable.

I got my printed manual about a week ago. I took it out of the mailing envelope, but it's still in the shrink wrap. I got that because just surfing through a manual, you can find all the new and improved stuff a lot easier than trying to divine it from the help file.

Rumor has it there is lots of new stuff since my last printed manual... PB/DLL version 2.0

(The "new" I can usually remember, but the "Improved!" go right past me).

Guess I'll have to break that open and put it somewhere I often sit with not a heck of lot else to do except read.

MCM