We are planning a migration from UNIX to Windows. I'm wondering how this will change the work I do in the tools / development. We are also changing DB from Informix to MS SQL.

We have made plans for someone to do the migration of code and data. Then we test. After we are satisfied with testing, he'll come back to migrate production data. Then we start running in new environment.

Who is willing to comment about the differences I'll face?

Printers are currently UNIX networked printers. Windows?
Administration differences?
Development differences?
Archiving?

Printers: you will use the fonts that windows uses for your printers. It's different compared to the fixed fonts that are generated from the printinf files of baan. Also landscape will print only about 43 lines instead of 66 lines.
Printing will be done via the client.

Development is not that different. If you install gvim on you client you can still use vi to update your code. However if you use unix scripts in your jobs and or hard coded file paths than you have a lot to convert. It's possible to use e.g. services for unix to run your unix scripts but even than it's not always easy to migrate. (I am currently performing one.)

Admin: if your win server is part of the domain you don't need to create os users anymore.
Database users is like before: you can create one to one users in the db or link baan users to one single db user.

Regards,

Worked with both unix and windows.

@Development: If you use the baan internal tools to transfer the development from unix to windows there should be no issues (as far as i remember).

@Admin: There are some tools for the administration in windows environments.
Could be some issues with the shared memory. If you modify programms you have to restart the shared memory so the users access the modifications, different behaviour than unix or linux.

@Printing: With windows printers you can use the bwprint utility, e.g. for barcode labels.

@Reporting
If you have external reporting systems could be that you have to modify some sql querries.

The separator for tablefields with informix was "t_", with oracle it was "t$", don't know what the sepparator in sql server is (e.g. t_cuno is than t$cuno).

With SQL Server you can use the microsoft reporting studio, giving you a free tool to design and populate Reports e.g. via the intranet.

The separator for tablefields with informix was "t_", with oracle it was "t$", don't know what the sepparator in sql server is (e.g. t_cuno is than t$cuno).
.


The table field names in SQL Server are in "t_cuno" format

- We had to use Windows task manager to schedule and execute all the jobs in the Job Management module.

- In several Baan sessions/reports we had built Unix Shell scripts to execute Sendmail e-mal notifications to users. These all had to be re-written to use with Windows.

- If any of your customized scripts write files you need to change the seq.open command to use the 't' openmode for NT filesystems.

Joy,

If I remember right, you use overlays in your printing for "prettifying" some reports. Those will not work in a Windows environment.

Vince

I'm on Unix shop but have done a lot on Windows:

Printing: As some guys said bwprint locally but you can also have the option of From Server. you just have to make sure you have the correct fonts. This also does not stop you from using Windows program from seagull or zebra for barcoding.
Database Users: one db user per Baan user, you can also see orphaned users.

Backup: SQL backup to a local/network directory and you can save the BAK copy to your backup device.

Table re-orgs: have to be careful to have plenty of space, be sure to set checkpoints.

DB Admin: Be sure to map your most used/least used tables and re configure your tabledef wisely.this might be your only convenient opportunity. also you have the opportunity to configure tablespaces/filespaces taking in consideration your archiving/backup and restore strategy. recommend transaction log backup every 30 minutes.

Replication: Tricky but doable between servers across the globe. have done this successfully :)
SLM licensing: separate windows SLM server.
JOb management: using task scheduler but running on separate virtual pc. my preference.
Scripts: unix scripts can be converted to VB script. have a beginners book, complex scripts are found in google everywhere :) For T-sql scripting, there are a lot of references everywhere.
Reporting: You are right on SSRS/SSIS alley make full use of them. They are LN's choice in FP7. It can do FTP, Auto emailing, file conversion (excel, text, pdf, etc). you can do logo easily, even link to other Informix, DB2, oracle servers in your company.
Development: not much difference here, backslash against forward slash. now you can have UNC paths. i still use winvi, your choice if you want visual notepad :)
Admin: Your baan password is linked to your Domain password. you need to be fully authorized as domain admin to be effective.
Reporting notification: recommend SSRS subscription service, you also have the option of Data-driven notification/emailing,ie if a certain condition exists in a report email to ...

Extra tool: i kept one Unix box for a while (about a year) so i don't have to rush converting. then later put Ubuntu linux in one of the PCs (just in case :) )

I see your preference it so use a separate virtual machine for Scheduled Tasks (Job Management)...

What experiences have led you to using this as your preference? Just curious...

eddie, more like fighting with the network admin (windows patch, admin) on the access of the app server if the jobs are there. i can access my jobs, modify, etc. at my own time.

I have written several programs that use brp.open, ready and close. All the printers were direct devices. Will I have to change these programs?

If your programs are referencing Baan Print Devices from Maintain Device Data (ttaad3100m000) then as long as the Device Queue field references a working printer on the Baan server, I believe that is all you would need to do. If they are different Device names, you will need to change them in your code.

Finished about a month ago a migration of 550 solaris/oracle users to w2k8r2/msql.
The customer had developed all kind of unix scripts. Most of them could be translated to the 'services for unix' version of ms.
The biggest issues where:
- using home folders;
- windows permissions on folders in which files were placed;
- printing from jobs.

Regarding printing: we used the portingset 8.8a below BaanIV. First we used a script with bw in it to run jobs. However using this interactively didn't work, only if the process was active on the screen than it would finish. Not very nice if you have about > 100 jobs. In older versions I am sure this worked but not anymore.
Solution was to use jobs running with startjob.bat as supplied with the portingset and use windows server printers. We couldn't use these as normal end users unless the printers were part of the windows profile of the user on the server.

You can convert your direct printers to windows server printers for jobs. For normal users I would recommend to use windows printers so printing is done via the client default printer so you don't have to configure all printers as baan devices.

Regards,
Han

agree with han on windows printer, less headache. btw, i have a general question to you guys. what is your motivation in switching from oracle to sql server? in my previous assignments, it was easy. motivation was the boss does not know unix. also, the db is around 500 gb only. in my current job we are on the 2 tb range and everybody is a unix guy :)

In our case...

About every 6 months our IT department reviews our ongoing 3-year strategy. Looking at our infrastructure as it was and where we wanted to go, the addition of several more 'enterprise' level applications, as well as cost structures for different infrastructure scenarios we opted to migrate from Unix/Oracle to MS/Sql Server.

Baan was the only application on Unix and moving forward we did not want to have to maintain or pay for two enterprise class databases. The Unix-based HP Itanium servers were much more expensive than equivalent Windows boxes. The move allowed us to save a great deal of money as well as narrow down the number of types of systems we needed to maintain. We outsource our DBA services so there was not much of a 'learning curve' for support of the database itself.

The main motives to move from unix to windows for most of the customers overhere are:
- intel boxes are much cheaper;
- sql server licenses are cheaper;
- most of the time they have windows admin in house and not much knowledge of unix/linux.

Interesting was that one of my customers choose to use linux instead of hp-ux. They were able to buy two intel machines with SSD disks in it for the same price as a hp-ux box.

i have the same opinion about cost. thanks eddie and han. it seems to me that sql server has improved a lot, technical design is not even an issue. i looked at performance benchmarking websites and it's fast too. microsoft is also very serious in improving their database techonology. even the t-sql language has improved a lot with lots of enhancements. i'm equally impressed with the speed of raw sql backup. one reason why the ms guys are very keen on improving their db is also because they are in the erp market with ms dynamics. in my last two sites, they don't have a dedicated db admin. i ended up doing the db management by myself, which is not too hard.

I am not sure whether a windows printers can be used to create and define for barcode labels, but I do know a mature barcode creating control (http://www.businessrefinery.com/barcode-generate/vbnet_barcode_generator.html) can be used to handle barcode lables and any other barcode property.

I am not quite familiar with the barcode label, and even don't know what it looks like. Tritglorlee sounds to be well acknowledged of the barcode software (http://www.onbarcode.com/) things. Don't know if you would mind helping me to do some guides on me for my problems with ssrs 2008 add barcode 3of9 font (http://www.onbarcode.com/products/net_barcode/).

3 0f 9 barcode is barcode type 14. If you are on Windows, it is easier to print barcodes than on a UNIX platform. At least this is my opinion.

- Joy