If you encounter this, it is probably a Prime INFORMATION (PI) legacy code. As this was a commonly used convention in natively developed PI applications (rather than PICK-ported apps).
As globally catalog'd object was a typical naming convention for "production" object in PI. Plus as mentioned by others it was also primarily for performance reasons. Some of those performance reasons still exist. If you don't resolve the subroutine name in your BASIC code, then the VOC file has to be referenced to find out the "true" catalog name. If you define and call a variable - if by-passing the VOC calling entirely. Of course there were many non-native applications running on PI from the PICK world that never took any advantage of this and many other PI features. Legacy PICK code tends to be account catalog centric (ie., *MYACCT*MYOBJECT). So typically doesn't use this convention, we use this convention to define test / non-production object code in the catalog space. Hence, we also use it to load/deignate different versions of the object code dynamically. Our account initialisation code defines "*CATALOGNAME" as the production code. When initialising on logon to the UV account, It then checks the local VOC for any different definitions in the local account - and asks the test user (not end-users) if they wish to local that object version. This allows versions of the code to be loaded for different users - for testing and pre-implementation purposes - on demand. For example, we run to run "*V1.1*SOME.PROGRAM" rather than "*SOME.PROGRAM". This is especially useful if you share your single UV environment with multiple accounts and versions of your software. This saves having change VOC entries too, but of course you can do that too. But then if you have some users that don't what or need to test that version - then how would you control/enforce that? Regards, David -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, 4 December 2012 11:39 AM To: u2-users@listserver.u2ug.org Subject: [U2] Advantage of indirect call in BASIC I've not encountered this is my career previously, but now I'm seeing a system written almost entirely with the use of indirect calls in Universe BASIC. That is SOURCE = "*SOME.PROGRAM" ... CALL @SOURCE(INPUTS) Is there some advantage to the use of indirect calls that a system would be written entirely in this fashion? ************** IMPORTANT MESSAGE ***************************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ************************************************************** _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
