Recovery from wireless devices abending

[jack1955]

My boss asked me to research this- we have wireless scanners in awarehouse- the 5250 emulation type connected to the AS/400 - that when they have a record lock or lose power or lose signal, causes some records to be updated and not others. We cannot use commitment control.

The major problem is the inventory is out of whack.

First ideas- save indications of files updated, etc, some data in data areas or some kind of control files so that when the user or device comes back on, we can recover (or recover automatically in some other fashion).

We expect programming to be involved, which will be my job as well as the analysis and design.

I'm looking for advice or someone's experiences in such matters.

Has this happened to you and what have you done?

Thanks,
Jack

 

[ladeecroft]

hi jack.

had a similar problem like yours, only in our case, we interface a PC application with AS400 as backend. The PC application uploads text file to a PC folder in QDLS which is then processed by the AS400 RPG programs. The problem in this scenario is that sometimes, the uploading is interrupted and those records that were not uploaded are never uploaded again because our process is done once a day only.

What we did to solve this problem is that we've used 2 temporary files, File A - for the uploaded text file and then File B- for the successfully processed records. For every record read from the File A, we update it and then transfer it to the processed records file (File B). After successfully processing that record, we delete it from the uploaded text file in RPG (File A). This way, all the records that will be retained in File A are the ones that were left out during the processing (due to several reasons like downtme or system failure) and all those successfully processed records are in File B. The next day, when we start to upload again, those records that were not processed the day before will be processed together with the new records to be uploaded from the PC folder.

Another thing, im not familiar with using wireless scanners but if this device uses a text file to communicate with the backend, you could use a delimiter, sort of a flag to identify which record are updated and which is not. And the next time you access this file, you'll know which rcord to process.

I know this is not exactly what you need but i do hope i gave you an idea.

 

[jack1955]

Thanks for the reply, ladeecroft. The scanners emulate the 5250 screen and send the transactions directly to the AS/400- there is no text file or anything.

Jack

 

[PeteJohnston]

You could try using a data queue written to by the scanner program and a single job running in batch which receives them. The scanner program is then doing virtually no work (only sending to the data queue) and all of the processing is done by the background job. The data sent to the queue (probably part, location, quantity info) will sit on the data queue until it is processed so you can't lose it. The files are updated only by the background job so there should be no problem with record locks. The elapsed time to send to the queue is tiny compared with the time to do a transaction so the chances of losing something because of power or signal loss should be reduced.

I had a quick look in Google for "as400 data queue" and found a few sites. This one was the first which had some examples and useful links:

http://www.iseriesnetwork.com/Resources/ClubTech/TNT400/bo400ng/as400dataqs.htm

PeteJ
(Contract Code-monkey)

It's amazing how many ways there are to skin a cat
(apologies to the veggies)

 

[jack1955]

Thanks, PeteJohnson, but the scanner program edits and updates, so sending the transactions to a data queue might be a good solution, but not what IT wants for a solution.

We use data queues and message queues and async tasks to update in the background. My boss didn't want me to rewrite the programs.

Plus this hot item of a few days ago has been forgotten and I'm off to fix other things. It's hard to keep track of all the hot items that go cold in days.

 

[SwinerBock]

Jack,

First off, the record lock problem should easily be avoided by using the (N) operation extender on all of your CHAIN's and READE's. The only CHAIN and READE that should not have the (N) extender are the ones immediately preceding the UPDATE step.

As for the rest of it, you could use intermediate workfiles to hold the data currently "on the screen" of the scanners, and make the workfiles (or the data contained in them) either user-specific or workstation-specific. It would be a concept similar to the pc or text file mentioned in a previous post...similar even to the data queue concept. Some sort of intermediate storage needs to be used.

Otherwise, the only thing that I can think of as far as knowing what got updated and what didn't is either putting an update timestamp in the production files or create a log file that keeps tracks of updates made, along with what program/user/workstation/time...etc.

Brian Price
South Arkansas Technology Services