All the current versions of ManuSoft contain a powerful feature called the Report Generator. This routine lets you create custom reports on your data, so you can extract the information you need quickly. In today's blog post I'm going to give an example of what you can do with the Report Generator. In the example I use version 6.4 of ManuSoft. I'd also recommend trying this in a play system first, if you're new to the report generator.

The scenario: you have a particular raw material and you want to find all manufactured parts which include this raw material in its bill of materials.

If you only want to search for one material you can just select the standard report format, then click printout. In the search criteria form that pops up search for "Material" equal to and enter a stock code. The generated report should list a part code and a description on each line, corresponding to a part which uses the material code you searched for. The image below is an example of the search I mean.

Now that report is reasonably useful, but we probably want to see some details about the material being used, for example the quantity. To do so we will need to create a new report format of our own. 

To start off, open the report generator menu and select the part file. Then choose the standard report format from the drop down menu. Once the standard report is selected and appears on the screen, click the build/copy button to the right of the format selector. Give the new report a name and click ok. The image below shows this.

Now to show some details about the material we need to add a reference to the material file in our report. To do so click the "Secondary" button in the bottom left of the screen. The display in the Format Layout should now show two rows of headings. The first is from the standard report and the data under these will come from the Part file as usual. The second row is for the Material file, and allows you to select the information you wish to show about the material items. Add the following columns in this order: "Stock Code", "Units", "Price ($/U)", Quantity. If you did this correctly your report format should look like the following screen shot.

Before we print the report, click on the Primary button (in fact you have to as the print button will be "greyed out" while you edit the secondary columns). Select the material details column on the primary file and delete it. The reason for doing this is that we already have too much data and the font on the generated report will be far too small if this is the case.

Now we're ready to print. Click printout and use the same selection criteria as before. The new report should show details about how much material each part actually requires, and the associated cost per unit.

Another useful feature of this report is that if you do a wildcard search (say for all materials beginning with a specific prefix) then you can see all uses of a related set of materials quite easily, as per the sample report output seen in the image below.

Long time ManuSoft users will probably already know that NULLs in your ManuSoft data files are a problem, but you probably don't know exactly what they are and why they are problem or how they get there. This entry is a quick discussion on the topic of NULLs.

So, firstly why "NULL" in all capitals? This is because we are referring to a particular 'control code' as defined by the ASCII character set. All modern PCs use the ASCII character set which defines how all the letters, number and symbols on your keyboard are stored as numbers in memory, as well as defining a number of non-displaying characters, like "CR" (Carriage Return), "LF" (Line Feed) and also one called "NULL". These non-displaying 'control codes' take up the first 32 positions in the ASCII table, numbered from 0 to 31, and NULL takes position 0.

ManuSoft has always attempted to avoid all control codes in its data files, for several reasons, but avoiding the NULL character is particularly important because in the C/C++ programming language that ManuSoft is written in the NULL character has a special meaning; it marks the end of a string of characters. So, say ManuSoft wants to read some information, like the standard wording for a Purchase Order, from your WORK.DAT file. In the C++ code we open the WORK.DAT file, position the read pointer at the particular location where that standard wording is saved, and issue a command to read in a block of 600 characters (the maximum length of the standard wording text.) If, for whatever reason, there was a NULL character at the 200 character mark then only the first 200 characters would actually be read by the C++ file sub-system. All the text you had typed in to positions 201 through 600 would be ignored and would not get printed.

Now that example is not particularly dramatic, but when you start considering other possibilities, like a NULL in the middle of a stock record, so that the stock code and description read and update just fine, but the quantity in stock seems to never change, and you can see what sorts of problems can appear. Sometimes quite inexplicable behaviour can be traced back to a NULL in an odd spot.

So how do NULLs appear in your files? ManuSoft obviously tries to avoid creating them itself wherever possible, but some further facts about the behaviour of C/C++ and Windows makes them crop up from time to time. Firstly, there's the problem of buffers. When ManuSoft wants to create a brand new stock record, for example, we initialize a 1024 character "buffer" in memory. We would then normally fill that buffer with exactly 1024 characters before writing the contents to the end of the file. But if for some reason the buffer was only filled with 500 characters then position 501 would contain a NULL (to mark the end of the string), and that NULL could then be written to the file along with the rest of the buffer.

A second main cause is a file being expanded when it is written to. If a file is 50,000 bytes long and a C/C++ program asks Windows to write some characters to the file at position 55,000, then characters 50,001 to 54,999 in the file will end up being NULLs.

And then there are just the regular glitches that can happen on any computer network given enough traffic and enough time. Because the NULL character is the "default" for unallocated memory, etc. if anything goes wrong with any transferring of information inside a computer or around a network then there's a good chance a NULL could end up in the data somewhere.

I said earlier that ManuSoft has always tried to avoid control characters in its data files, but over time we've had to compromise our position on this. The first was when we made the ManuSoft .DAT files compatible with ODBC access, back in Version 6.1. To allow the Microsoft ODBC Text Driver to read our .DAT files we had to insert the control characters "CR" and "LF" at the end of every record in the database, as this is the Microsoft DOS/Windows standard for marking the "end of a line". The next big change was when we converted to using the .DBF file format in Version 6.4 of ManuSoft. The .DBF file format defines a "header" that must appear at the start of every file, before the actual data. This header information includes many NULLs and other control codes. But despite these changes over the years the actual data itself inside our data files continues to exclude all control characters.

Because NULLs in particular are a problem in our data files we created a utility called "FixNULLs" which you can use to clean up your data files, changing all NULL characters to the harmless "space" character instead. This utility used to be a very ordinary looking "DOS mode" program which you had to run at the command prompt. After changing to the .DBF file format this utility has been updated to have a Windows interface and to be a lot more user friendly. You can queue up a number of files to all be checked (by browsing for them, or by drag-and-dropping the files from Windows Explorer) and when run the program gives more feedback and will automatically skip "safe" NULL characters in the the header section of any .DBF files.

The FixNULLs program can be downloaded from the Miscellaneous Files section of the support web site. It would be very hard for you to do any unwitting damage to your data files using this utility, but we would generally recommend you only use it after consulting with ManuSoft Support personnel.

ManuSoft System Administrators should already be aware that it is important that every user on the network is assigned a unique ManuSoft User Number for the system to operate correctly. If two users are given the same User Number then it is quite easy for the Record Locking System to fail, and it is this system that prevents simultaneous operations being performed on the same data inappropriately.

Thus it is always a good idea to keep close tabs on which users have been given which numbers, and to always be careful when adding new users to your network. We have often recommended that you occasionally perform a complete audit of ManuSoft User Numbers on your network, by visiting each user in turn and going into the "User Information" menu option under "System Maintenance" to check precisely what number they have been assigned. (Simply relying on the "Review/Reset Locks" display, which lists all the users and what program they are in, is not sufficient!)

For our larger clients doing such an audit is obviously a fairly tedious task, since there are so many users/computers to visit. To help in these situations I have developed a new Excel spread sheet, UserScan.XLS, and uploaded it to the "Miscellaneous Files" section of the ManuSoft Support Site. This spread sheet contains a macro which when run will seek out your USER.DAT files before displaying in the spread sheet the results of its search, which you can then sort in the normal way, making it easy to spot duplicate of missing User Numbers. Too easy!

Some notes on using this spread sheet:

1. The spread sheet can only work if your USER.DAT files are all being stored on the sever, not if they're on the local (C:) hard drives on each computer. Sorry.
2. When first opening the spread sheet make sure you read the security prompts and enable the macro stored in the spread sheet, otherwise things won't get very far.
3. When you click the "Start" button you will be prompted for a starting directory. You should be able to type in a "UNC Path" pointing to your user folders.
   For example, you have a folder (called "Users") shared out on your server (called "Server"). In that folder there is a folder for each login on the network (JimR, MichaelH, etc.) and in those folders you will find the ManuSoft USER.DAT file. Your server login script maps the drive letter H:, say, to each user's unique "home" folder, so your ManuSoft set up therefore is configured with either "H:\", or "H:\User\" as the "User Data File" directory in the System Installation routine.
   However, when you run the macro in the spread sheet you must enter "\\Server\Users" when prompted for the starting folder for the seach, not "H:\".
   Alternatively, if you are actually running the spread sheet on the server directly, then you may be able to enter the "real" name of the folder. For example, your "Users" share is in fact located in "D:\Data\Users", so when you run the spread sheet (on the server) you can enter "D:\Data\Users" as the starting folder.
4. All sub-folders of the folder you specify are searched, including sub-folders of sub-folders. This may take some time! The Status Bar in Excel should show you which folder it is currently searching, so you can monitor the macro's progress.
5. Depending on the security permissions set on your user folders you may need to be logged in as an Administrator for the macro to have sufficient privledges to go searching for those files.

I hope the "power users" out there find this useful. Let me know if there are any further enhancements you'd like to see made to this routine.

Welcome to the Manufacturing Software Team Blog. We plan to use this blog as an informal method of communicating with our users of ManuSoft and with anyone interested in finding out more about about our software.

This blog will offer the reader previews into upcoming updates to our software, tips and tricks for getting the most out of ManuSoft and descriptions of features which are often overlooked. It will also allow you to provide us with some feedback through the comment buttons. We hope you find this blog interesting and useful!

Happy New Year.