Distributed Troubleshooting

Troubleshooting Distributed Resync with “open error 5” using a CD ROM.

You can walk a customer through this over the phone for messages like: Open Error 5: File used by others, ready busy (or similar)

Go into Windows Explorer and check the file on the CD, which is being used in the resync. See if it resides in another folder or if it is on the CD without a folder, and note the name of the file. For our example it is RESYNC.
Go to the PM.DIST Main Menu and type in TCL and hit <ENTER>.
Type in DEV-MAKE –T TAPE –A “D:\RESYNC,P” and hit <ENTER> (Or use the drive letter which corresponds to the CD ROM.
Next Type in T-SELECT and hit <ENTER>. Note the tape device you just created and then hit <ENTER> to get out of the list.
At the colon (:) type in U MASTER DIST.TAPE.COMMAND and hit <ENTER>.
At the “01” line make sure the T-SELECT command is the command you noted in the T-SELECT list. This would look like this: 01 T-SELECT 4
Hold down the control key and hit X then F to file the item.

Type in “M” and have them try the resync again – it should work.

TROUBLESHOOTING OTHER DISTRIBUTED SUPPORT CALLS

1. Do a sort load.log by-dsnd id

2. Check each que

RECEIVE.QUE

Log into the PM.DIST account, at TCL, and type the following commands.

CT DICT PM.RECEIVE RECEIVE.QUE

This que shows what has been received, but not yet converted. If there are any items in the que, there was a failure somewhere in the receiving computer. Usually two processes have locked up with each other. CLEAR-LOCKS can be executed to clear the lockups, but use caution. Clearing locks could foul them up if the customer is working on the system.

Also, this can cause 2 distributed processes to run at the same time on the same packet. This usually does not cause a problem since items in the packet are stamped when converted with the time and date. Items already converted will not be re-converted. If the distributed process does not continue after locks are cleared, you may run CPRR.PH to push them through. If all fails type: STAT PM.RECIVE, 39_XXXXXXXXX to find out if you get any errors (-Remote file error-). In case you do, from the Laptop type:

Copy PM.DIST1, PM.SEND, 39_XXXXXX, (O Note: you must put “,” (coma) at the end

TO: (PM.RECEIVE, 39_XXXXXX

Where:

PM.DIST1 is remote Q-pointer to PM.DIST on Main server
(O is to overwrite old file.

Clear-file PM.RECEIVE, 39_XXXXXX (make sure is the one on the Laptop)

Then:

Copy PM.DIST1, PM SEND, 39_ XXXXXX

To: (PM.RECEIVE, 39_XXXXX

Run CPRR.PH again (on D3 systems CPRR.PH F will bring this process to foreground)

CT DICT PM.CONVERT CONVERT.QUE

These items are in the process of being converted or are awaiting conversion. These are received items only (See CONVERT.QUE.OUT for Send items). Again, this is usually a Pick lock problem. SHL CVT.PM.CONVERT will convert these files. Use CPRR.PH if there are items in both the RECEIVE.QUE and CONVERT.QUE.

CT DICT PM.CONVERT CONVERT.QUE.OUT

Though rare, items found in here were in the process of being converted from PM.CHANGES to PM.CONVERT for sending purposes. There is no easy answer for this being here, and each situation would have to be examined for the solution to pushing it through. If the file in this does not exist then you can probably delete it from this list (UD PM.CONVERT CONVERT.QUE.OUT and Edit the file name out of the list and save).

QSELECT DICT PM.CONVERT CONVERT.QUE.OUT

This will select the list which is in the file and then you must do LIST DICT PM.CONVERT at the >. This will tell you whether they are any good or not.

CT DICT PM.SEND SEND.QUE

These are items that have been converted from PM.CHANGES, and compressed to PM.SEND, but did not go successfully across the modem. Doing the transfer from the Main store again will usually resolve this problem. Otherwise, it is probably a port lockup, modem problem, or some other cause.

LIST-USERS (LU)

Check for PM.DIST.X users logged on and working (or locked). Then use WATCH WHERE xxx, where xxx=port number to see what that port is doing. You can generally tell by its movement if it is locked or working. If it appears to be working, move on to CSTATUS checking. Otherwise, you may need to end the process, using END xxx PM.DIST.X where xxx=port number. Then check the print que with SP-EDIT (see below).

CSTATUS

CT MD CSTATUS, or WATCH CT MD CSTATUS, will tell you where the program is currently in the expansion/conversion process. This can be critical information when trying to figure out where the process is locked up. SP-EDIT (U

This will edit the print que. Press Y to display, then ENTER for string, then T for terminal. Often error messages will appear in the spooled file. This will point to where the problem lies.

DIST.FIND

This is a utility program that will search for a string in PM.CONVERT sub-files, or selected sub-files. This is handy for finding parts, customers, invoices, etc. that somehow got out of whack during the download.

Use this to validate that items in a subfile were converted:

SORT PM.CONVERT,x_yyyyyyyyyy A1 will give you a list of the items in the PM.CONVERT file. Note that the subvalue for A1 is a Time/Date stamp, this is the time and date the item was converted. Be careful, though, the item is marked before it actually is converted, so depending on where/when it locked up, the last item with a Time/Date stamp may not have been fully converted.

SORT MDS PM.DIST1 (shows the loc information for loc 1 in the setup for the transfer.)

CT DICT PM.CONVERT, XXXXXX

CT CONVERT.LOG XXXXXXX

CT DICT PM.SEND, XXXXXX

STAT PM.CONVERT, XXXXX
SORT PM.CONVERT,XXXXXXXX A1

Other things to check:

All PM.SEND and PM.RECEIVE sub-files should have a corresponding PM.CONVERT subfile. Unless sub-files have undergone purging (automated via PURGE.DIST that runs every time), if one exists without the other, there is definitely a problem. Double check the queues for any stray packet sub-files.

Sometimes if packets are not being sent, check to see if FILESIZE is in the first packet in the send.que. If this is messing it will cause the packet not to verify when trying to transfer.

SORT PM.SEND,XXXXXXXXX (packet#)

If the SEND.QUE appears to not be working, you can verify that capturing is on by doing a COUNT PM.CHANGES,XXXX(ex. LOC 40) to count current changes then change something and count it again. The number should increase. Then check the CONVERT.QUE.OUT, because something is stuck out there and do a SHL CVT.PM.CONVERT to force conversion to continue to go.

Sometimes licensing information gets fouled up for Infolinke. This is easy to check. Type IL from TCL and you should get the Infolinke Main Menu. If you get a Security Violation, then you have discovered the problem. Refer to the section on security violations.

Modem1 will not log on message, see section on Port will not logon.

Excessive Persistently Corrupted messages can be controlled by making changes in the destination file in Infolinke. This is menu option #4 in the Main Infolinke Menu. You can try:

#7 lowering the baud rate

#19 and #28 raising the retries parameters

#30 lowering the input buffer size

#31 lowering the block size to use

Make sure the logon prompt (#13) in Destination file says 'PICK user id:'. The process will not be able to log on after Infolinke connects.

Check MAXUSERS in DM. Make sure that they are not at the limit either at the Main or Remote stores when attempting transfers.

STAT PM.SEND,XXXXXXXXXXX

XXXXXXXXXX = Packet number

This will help you see the size of the packet if it stuck or not transferring.

To See If A Packet Can Be Deleted

Look in the sort load.log by-dsnd id or sort Dump.log by-dsnd id

And see if packet# is in the convert list for that day. If it is and was complete then

the packet was converted and can be deleted.

Deleting A Packet

DELETE-FILE (location),XXXXX(packet#)

Ex.- DELETE-FILE PM.RECEIVE,3_12065123459

Utility Programs

NICK.INV – Forces an inventory part item to be copied to a location. (INVENTORY, INVENTORY.LOC, INVENTORY.COST, INVENTORY.PRICE)

NICK.POS – Forces an order & pos.invoice across to a location.

NICK.FILE – Forces file to go over to remote locations.

*Can be necessary when resyncing a new location because EMPLOYEE, ACCOUNT & EMP.XREF do not transfer.

SPLIT.PMC.PACKETS – The causes packets to be split up into small, easier to download packets.

Infolinke-Specific Fixes

Security Violations

In the Bundle account if Infolinke is in Bundle:

COPY OBJECT,PRO IL.CONSTANTS (O If on AP/Nat use NAT instead of PRO.

to:(IL.MODES

DELETE IL.ITEMS PICK.SERIAL

MLOAD.MODES

Enter site name: PERFECTION (Or name of where you are at)

IL.CHECK

IL <ENTER> (should give you the main Infolinke menu)

Reactivating Bundle

Log to Bundle, and go to TCL.

COPY SW.LIB SERIAL

to:(ERRMSG BL001

Port will not log on:

Error message:

"Attachment attempt failed; MODEM1 will not log on."

"No new attachment has been made."

To correct:

log to BUNDLE

X to TCL

U MD IL.PROCESS

Before line that says:

HIL.PROCESS.VERB IL.TRANSFERS (32)

Insert the following 2 lines:

HEXEC IL.ABS

This should fix the problem. Be sure to reset port, user, and execute IL.COLDSTART before attempting again.

Copying a INVENTORY.LOC item from the main to the remote.

:ct mds pm.dist1

pm.dist1

001 Q

002 FSI:[//216.187.249.170]PM.DIST

003

004

005

006

007

008

009 L

010 10

:copy FSI:[//216.187.249.170]PM

[201] 'FSI:[//216.187.249.170]PM' is not a file name

:copy FSI:[//216.187.249.170]PM,inventory.loc, ss.616

to :(invl

1 ss.616 TO ss.616

[805] 1 item(s) copied

Additional Troubleshooting:

Support call number 54287

**** Problem ****

ORDER 4-0026917 Already Posted on 11/16/2001

This usually indicates a severe problem. Please fix the item and re-run the

convertion.

**** Solution ****

CT PM.CONVERT,1_1272166977 ORDER_4-0026917

ORDER_4-0026917

001 51 PM PM

002 12721

003 53804

004 Deleted

DELETE PM.CONVERT,1_1272166977 ORDER_4-0026917

10/31/2002 09:25AM Call updated by Steven R. Shourds

1_1272269534 recapturing problem.