Linux 10.4 "issues" (note the air quotes)

Hi all

So, we're on Linux 10.x and it's great - HOWEVER:

• Is there a way we can tell the update processor to flash compile (as opposed to just compile) code?
  Generally, one would exit and compile using Ctl XC
  Just asking
• My client is still using System Builder 5.1 (don't laugh) and there is an option to call a program in the dictionary (correlative field):
  CALL MYPROGRAM
  The interesting this is that this still functions (calling the program etc) but it takes a LOOOONG time to run.
  If one does a 'list filname mydictvar' then it's OK speed; however 
  select filename mydictvar - takes forever!
  Any clues?
  
  
• One last point - has anyone out there got the System Builder source code? If so, I'd really like to connect with you.
  
  
• Thanks

Hi Stefano,

• Yes, you can force a flash compile to be the default position by placing an 'o' in amc 6 of the md entry 'compile'. This is in the d3 reference manual under the syntax for the 'compile' command.
• As you note; you can have a program run from a dictionary item. The routine should be flash compiled for performance and you should specific the full pathname. Again, in the manual. Look for 'call processing code' for full details. Why the routine is slow is anybody's guess but if it is likely not flash compiled.
• Err, no. I doubt source code for SB 5.1 exists legally anywhere. Even SB+ v5.n source does not exist; especially after numerous changes of ownership. Which also means the customer is not within the realm of supported-by-Rocket versions. Not to mention breach of copyright issues if one tried to work with SB 5.1

[Ad]: H3O has success migrating systems from SB to the last supported version of SB+ on d3: v5.1. We can be contracted to do this for you or as part of your resource. That is, we act for you and hand the result back to you. In effect the system will become a 'proper' SB+ system which can then be better supported and maintained; and gives the client a way forward which is not cut-and-change.

PS: In theory you could flash compile SB v5.1 without source; and then everything would run together. Do not recommend doing so, though.

Hope this helps.

Best wishes,

Hi all

So, we're on Linux 10.x and it's great - HOWEVER:

• Is there a way we can tell the update processor to flash compile (as opposed to just compile) code?
  Generally, one would exit and compile using Ctl XC
  Just asking
• My client is still using System Builder 5.1 (don't laugh) and there is an option to call a program in the dictionary (correlative field):
  CALL MYPROGRAM
  The interesting this is that this still functions (calling the program etc) but it takes a LOOOONG time to run.
  If one does a 'list filname mydictvar' then it's OK speed; however 
  select filename mydictvar - takes forever!
  Any clues?
  
  
• One last point - has anyone out there got the System Builder source code? If so, I'd really like to connect with you.
  
  
• Thanks

There is nothing wrong with SB+ 5.1, works like a treat. It just keeps on going.

Hi Alex,

I think the OP was speaking of SYSTEM BUILDER v5.1 which was developed circa 1982-late 1980's whose source is [probably] lost in the mists of time; although I do know certain large scale systems relied on SB [not SB+] such as a warehousing system whose name I forget. System Builder v5.1 was the last or perhaps the last stable release of System Builder to my knowledge.

One product [forget it's name] in particular became quite successful as a stand-alone product used in Australian pharmaceutical warehousing; one notable being FAULDING.

If memory serves that system because so highly modified away from SB's core code that it was tightly bound to the functionality of said warehousing system. I digress.

SB+ on the other hand first came out in about 1990; and went through a lot of version releases quite quickly. Sadly, releases were notoriously unstable; but settled down with release v2.3.2 upon which software I wrote remained for years and was totally OBJECT code [p-code, not flash] compatible across d3 releases from Advanced PICK onwards; and I dare say would RUN even today on the latest d3.

Confusingly the last d3-supported version of SB+ is v5.1; and as you state runs perfectly on current d3 systems because the p-code is compatible. We have clients still using it; and it works. Also technically it is 'licensable' if not supported by Rocket. It is not supported because [sadly] versions of SB+ after v5.1 are no longer supported on d3; only Universe [& UNIDATA, I believe; but for the sake of simplicity and risking annoying Unidata peeps; I'll use the terms UNIVERSE because that is what Rocket seems to be focussed upon].

SB+ has continued to be developed and supported but has morphed into a thing called SB/XA which first came out circa 2008 and while I know little about it appears to be a mashup of SB+ concepts, Redback as middle-ware and SBClient a very fat Windows client. I believe via the mashup SB/XA will also run in a browser. I am probably being very unkind through lack of knowledge and maybe misrepresenting the product but what I know to be true is:

• The current support version of "SB+ - like product"  is now called SB/XA; and
• It only runs on Universe; thus requiring a non-trivial shift from d3 to Universe
• That system while current had it origins almost 20 years ago.

Not a bad legacy I suppose for something which started in the 1980's! 45 years ago!

Finally, my issue with SB+ v5.1 is it is doomed. Which is a shame. Not only does the source code for SB+ v5.1 [probably] not exist; the system is no longer supported by Rocket because of the evolution to SB/XA and it's reliance upon Universe. Further; d3 will one day have changes made that will break SB+ v5.1.

It does provide a pathway from those on System Builder to move forward; which is what we have done with our customers because it buys them time; rather than cut and change to non-mv environments. Being 'back in the fold' with licensable software and allow for alternate enhancements to be made [think API's, web etc] all the while retaining the business logic embedded in their systems. Highly cost effective; but the point is clear: remaining on SB+ v5.1 is a short-window timeframe option. Perhaps the way forward is to Universe; perhaps not. It allows the customer time to plan and make choices that are highly cost-effective and leverage their investment in existing systems.

As the OP has since responded, their client if moving away from mv entirely; which I consider to be a shame as well as a lost opportunity as it likely WILL cost a lot more than a pathway which goes System Builder v5.1 --> SB+ v5.1 --> future.

Our clients understand that and have reaped the benefits.

Onward!

"..... such as a warehousing system whose name I forget"

Masterpack ?