22 replies to this topic

[Lewis Mccabe]

Chris,

Does your support come from your ERP vendor? If so, if you are not sure of the status of your system, I would get with them.

I checked with PROIV and PRO-ISAM files now do max out at 2GB as Darren says. FYI to all, the docs make no reference of this. Use 16000 as the record size in iscr for a 2GB file.

So the command would be: iscr -kKEYSIZE -r16000 somefile.pro
KEYSIZE being the length of your file key (include additional 3 chars for company division code if it is used in the file).

[Richard Bassett]

Good to know, thanks for checking Lewis.

The -r16000 seems to work at least as far back as V5.5 R5.6.3. It accepts the command without complaint anyway, I didn't generate 2Gb of test data!

[Chris Heeschen]

The company that created the ERP system is 4GL. I do believe we are their largest customer. The system is called SM3 (Steel Manager 3).

[gkwalton]

Hi All,

Yes the product is marketed and is Steel Manager III written by 4GL Solutions. Chris Heeschen is one of my customers. Chris... how are things? Glad to hear that you have stopped the backup in the middle of the day.

Chris, as we discussed, the max file size is 2Gb providing that the record length of the file is 16000. Currently the biggest file that you have in the system is approx. 350 Gb so we have some room to grow. The file sizes are monitored on a daily basis and if any file reaches 80% of its capacity we will be notified via email so that the situation can be addressed.

Chris, please do not try the iscr command that Lewis described below. Yes, the file will be recreated with a new record length, but it will also blow away all the data in the file.

Regards,
George.

[Lewis Mccabe]

Chris,

The instructions on the iscr command were not necessarily meant for you. It was instructions to other PROIV members on the forum. George is correct. Used alone, iscr will cause you to lose your data. To use iscr properly, the system must not be in use. You then use the isout command followed by iscr and then isin. It sounds as if George's system has it covered though.

If you can, I would get with 4GL for your support since they wrote the system and would be the most knowledgeable about it. The forum will always be here to help you out.

Richard,

You are correct. PROIV said the 2 GB limit was introduced in 5.5. Which flavor I don't know.

[andykay]

thank you all. I was just speaking to the company that created our ERP system. I questioned them on going to an SQL system. They said that it would be slower unless they rewrote the code. I have worked with Syspro ERP system for years and they were using C-ISAM and switched to SQL. The difference was unbelieveable. Currently it takes 45 minutes to run one of our inventory reports. And why does ProIV only use one processor on our server? I asked this question to the company that created our ERP system and they said it has to do with ProIV. So we have 114 users in multiple locations accessing one server which can only use one processor, pretty scary stuff. Any help would be greatly appreciated.

Chris...

...Going to a SQL system would make the system slower?!?!?!

...45 minutes to run a report!?!?!?!

What version of ProIV are you currently runing? 45 minutes for a report would've been GREAT time...20 years ago. I'm sorry that your first introduction to ProIV has been on this SM3 product. It reminds me of the first computer our family every had. It took 10 minutes to load a simple word processing program, but this was before Apple, Atari, Commodore, or Windows and it was far superior than the alternative of using a manual typewriter. I'm sure that this SM3 product has been tailor written to satisfy every niche of a limited market, but believe it or not, ProIV can be quite fast, when used with in conjunction with modern ERP systems and modern technologies.

I would try to get an idea of how much time is wasted by the 114 employees, on a daily basis, just WAITING. If this amount is significant, I would present this figure to the company and suggest upgrading to an ERP system that uses SQL, and a machine that could run it adequately, too. Your, as well as the other employee's, stress will decrease, and everyone's productivity would increase...but you would have to couple that against the time it would take to customize the application to meet your companies needs.


AK

[Chris Heeschen]

As I have just started here and this is my first experience with ProIV I am going to do more research. I do see some issues with this software compared to other ERP systems I have worked with. Speed of the system for the users is one of the most important issues. I know no system is perfect. Stopping the lunchtime backup has greatly improved performance. Part of my job here is to evaluate this system and to improve user experience with it. I have spoken to George Walton about these and other issues and I feel we are making headway. Some issues are certainly caused by the users here. Thank you all for your comments.

[George Macken]

Hi Chris

It is a long long time since I worked on a system where pro-isam was used for the production database, it did work but it was really important to manage/monitor the data files to ensure no corruptions occurred.

One of the steps that we implemented as part of nightly backup procedures was to run the "ischk -n " on all of the pro-isam tables.
We would output the results to a txt-file proisam-results-yymmdd.txt" and this text file could be checked every day (AM) to ensure there were no coppuptions in the files backep up.
If there was corruption then we have to set about resolving the corruption if the file held valid data.
We would also have run the "ischk -n" whenever the server crashed.
Perhaps this is already part of your procedures, please check this with your supplier

Hope this helps

Rgds

George