Design concepts, "rewriting" some green screen

This Q&A forum allows users to post and respond to "How Do I Do ....." questions. Please do not use to report (suspected) errors - you must use your regional help desk for this. The information contained in this forum has not been validated by LANSA and, as such, LANSA cannot guarantee the accuracy of the information.
Post Reply
atostaine
Posts: 131
Joined: Wed Jan 20, 2016 7:38 am

Design concepts, "rewriting" some green screen

Post by atostaine » Mon Oct 09, 2017 12:14 pm

Production app is 5250 RPG. it runs on a Symbol type scanning device, 8-12 screens that users either scan a barcode or type data to process returned merchandise.

Customer wants to enhance app to allow users to take pictures of returned merchandise.

Lansa mobile works since it can scan barcodes and take pictures.

I'm trying to figure out the best way to code this. The 5250 Rpg app uses one screen fmt, with 8 lines output and one input field. Thats easy to duplicate. The RPG code uses one Dow Fkey03 = *off (F3) and a step# .. If each panel is a step, 1-8, they can move forward or back by setting the step#.

If an error happens in a step, they can just do another exfmt (write the screen) within the step.

How should I code this? I have to wait for the server process to finish and stay in a loop /while/ this stuff is happening.

I thought a main Method with a case for step#, but I will need to run many Svrroutines and wait for results. Do i do the svrroutines in another method? I'd like to know what others think.

Thank you

MarkD
Posts: 318
Joined: Wed Dec 02, 2015 9:56 am

Re: Design concepts, "rewriting" some green screen

Post by MarkD » Mon Oct 09, 2017 2:42 pm

Are you planning to communicate with and reuse the existing 5250 application - or just replace/reproduce its logic with RDMLX code?

atostaine
Posts: 131
Joined: Wed Jan 20, 2016 7:38 am

Re: Design concepts, "rewriting" some green screen

Post by atostaine » Mon Oct 09, 2017 2:55 pm

I think the logic in the existing RPG is easy enough to rewrite. I could add parameters to the app to extend it though if it gets too difficult.

Really the app doesnt have much business logic. Scan a barcode, is it on file, write a record, that sort of thing. The app prints labels and other documents that I will reuse by calling the same programs from the server modules.

Art

MarkD
Posts: 318
Joined: Wed Dec 02, 2015 9:56 am

Re: Design concepts, "rewriting" some green screen

Post by MarkD » Mon Oct 09, 2017 5:13 pm

Sounds like the server routines should simple and stateless. They each run some stateless RDMLX code that might then on-call to some stateless RPG code. Basically they are just simple ‘subroutines’ that either work or fail. Possibly they are standardized to give back a return code as Y/N, OK/ER etc, and also 1 –> n error or completion messages.

All the smarts and all the visualization is in the client side RDMLX code which orchestrates when to do what.

atostaine
Posts: 131
Joined: Wed Jan 20, 2016 7:38 am

Re: Design concepts, "rewriting" some green screen

Post by atostaine » Tue Oct 10, 2017 4:11 am

No they aren't stateless. It's a progression, with data verification and possibly insert/updates along the way. The final step might be to print some documents.

I'm going to change the RPG to receive a step# and return the error line or the 8 lines of screen. Everywhere it does an EXFMT I'll return to my server module, and I'll increment the step. When user clicks accept or whatever on web, I'll call back and pass the input.

Thanks

MarkD
Posts: 318
Joined: Wed Dec 02, 2015 9:56 am

Re: Design concepts, "rewriting" some green screen

Post by MarkD » Tue Oct 10, 2017 10:37 am

Anything that a VL server module calls needs to be logically stateless I think.

If you execute Srvroutine A and it calls RPG program X then program X needs to be logically stateless.
ie: It needs to (at least logically) set on *INLR after each call and it can’t remember things between calls in program variables.

That's because if you then execute SrvRoutine B (or even A again) and it calls RPG program X again it is likely and quite possible that you will get a new instance of program X running in a different IBM i batch L4Web job assigned to your VL client request.

The design trap here is that sometimes, even quite often, Srvroutines A + B seem to always execute in the same IBM i job and you might, by accident rather than design, pick up a version of RPG program X that (architecturally invalidly) did not set on LR and remembered state.

This can lead you to think that program X can retain state between calls and that your VL client will always run the same state full instance of program X on every srvroutine invocation.

That approach might even work during development and even acceptance testing, but once a system is under load it's likely that a VL client's srvroutine requests get routed into different IBM i L4Web jobs - and thus use different instances of RPG program X. This design oversight may even risk routing the wrong response from the statefull program X back to the wrong VL client.

atostaine
Posts: 131
Joined: Wed Jan 20, 2016 7:38 am

Re: Design concepts, "rewriting" some green screen

Post by atostaine » Wed Oct 11, 2017 2:54 pm

MarkD wrote:
Tue Oct 10, 2017 10:37 am

That approach might even work during development and even acceptance testing, but once a system is under load it's likely that a VL client's srvroutine requests get routed into different IBM i L4Web jobs - and thus use different instances of RPG program X. This design oversight may even risk routing the wrong response from the statefull program X back to the wrong VL client.
Thank you Mark. Stateless is the thing to remember.

Post Reply