A Caché of Tips: Cataloging
10 views
Skip to first unread message
Ed Clark
Oct 22, 2012, 3:51:57 PM10/22/12
to intersy...@googlegroups.com
You can run a compiled mvbasic program using the RUN verb:
USER:ED BP NOW
NOW
New record.
----:I
0001= CRT TIMEDATE()
0002=
Bottom at line 1.
----:FI
"NOW" filed in file "BP".
USER:BASIC BP NOW
NOW
[B0] Compilation completed.
USER:RUN BP NOW
09:24:58 15 Oct 2012
But using RUN requires you to know what file the program NOW was compiled from, and also involves more typing. To run a program using just it's name, you can catalog it:
USER:CATALOG BP NOW
[243] 'NOW' Cataloged Local.
USER:NOW
09:32:18 15 Oct 2012
After cataloging, You can run NOW just by typing NOW.
----TYPES OF CATALOGING----
The various legacy multivalue platforms evolved different forms of cataloging, serving various purposes in different ways. Cache supports 4 styles of cataloging: Local, Normal, Global, and Global Account.
The account's CEMU emulation controls the default cataloging style. In most emulations, Local cataloging is the default. Non-default styles are chosen by adding a parenthetical option to the CATALOG command.
LOCAL CATALOGING:
Cataloging a program "Locally" creates a verb in the VOC of the current account. The verb points to the compiled version of the program. To catalog a program locally, use the (L) option:
USER:CATALOG BP NOW (L
[243] 'NOW' Cataloged Local.
USER:CT VOC NOW
NOW
0001 V
0002 MVB.2]USER
0003 B
0004
0005
0006
0007 L
0008 NOW
0009 BP
0010 USER
In this case, the mvbasic item BP NOW was compiled, producing the routine MVB.2 (the routine name MVB.2 is generated by cache because not all possible mv program names are also valid routine names. If the BP NOW program contains the #PRAGMA ROUTINENAME directive specifying a routine name, then that name would be used for the routine instead of a generated one). When the new NOW catalog verb is run, it will run the MVB.2 routine.
If the BP NOW program is changed and recompiled, the MVB.2 routine will be updated. Because the catalog entry points to MVB.2 the existing catalog entry will always run the most recently compiled version of BP NOW.
Local cataloging only creates a catalog verb in the voc of the current account. If you want the verb in other accounts, you will need to also catalog in those accounts. However, once cataloged, the verb in those accounts will also point to the latests compiled version of the program.
The first line of the catalog entry contains the letter V indicating that this is a verb. The second line contains the compiled routine name, a value mark, and the namespace that the routine is in. The namespace is necessary if the program file is a q-pointer to a file in a different namespace. The third line is the letter B indicating that this is a catalog pointer for an mvbasic program. Line 7 contains the letter "L" indicating that this program is cataloged locally. Lines 8,9, and 10 give the account/file/item name of the program source. Note that line 2 contains the namespace name, while line 10 is the account name. These might be different if the account name is not a valid namespace name (for example, creating an account MY.ACCT will create a namespace MYACCT, because dots aren't allowed in namespace names).
Line 4,5 and 6 can contain other flags that control how the verb is run. The CATALOG command itself doesn't write or modify these flags. See the sample programs PROTOCLASS and LIST.CSV for examples of some of these flags. Also see the tip on VOC item formats at https://sites.google.com/site/intersystemsmv/home/a-cache-of-tips/vocformat
NORMAL CATALOGING
Cataloging "Normally" creates a verb that points to a *copy* of the compiled routine. Use the (N) flag to catalog Normally.
USER:CATALOG BP NOW (N)
[241] 'NOW' Cataloged.
USER:CT VOC NOW
NOW
0001 V
0002 MVC.1]USER
0003 B
0004
0005
0006
0007
0008 NOW
0009 BP
0010 USER
The program BP NOW was compiled into routine MVB.2, but line 2 of the catalog verb references a different routine, MVC.1. When cataloging Normally, the compiled routine MVB.2 is copied to a new routine (which will always have a generated name MVC.nn--thus you may want to avoid normal cataloging if you plan to use the #PRAGMA ROUTINENAME directive). As a result, running the catalog verb will run the compiled version of BP NOW that existed when the verb was cataloged. If BP NOW is recompiled, MVB.2 will be updated, but the routine in the catalog verb (MVC.1) is not, so the catalog verb will continue to run the same old version of the routine. To get a new version, the program must be re-cataloged.
The namespace referenced on line 2 of the catalog entry will always be the namespace for the current account. Even if BP is a q-pointer to a different account, the routine from that other account will be copied to an MVC.nnn name in the current account.
As with Local cataloging, the catalog entry is only written to the voc in the current account, so you need to catalog in every account where you need the verb to be used, and you will need to re-catalog in those accounts when the program changes.
Otherwise, the voc catalog entry is mostly the same as for a locally cataloged program. Line 7 is empty instead of containing "L" (since it isn't cataloged Locally). Lines 8,9, and 10 still point to the program source, but that source may be newer than the version used to compile the MVC.1 routine that gets run by the catalog verb.
GLOBAL CATALOGING
Cataloging "globally" does not create a verb in the VOC (and will delete any existing VOC catalog entry in the current account). Instead, a copy of the compiled routine is placed in a global catalog area (in the %SYS namespace. %SYS is the namespace used by the SYSPROG account) and an entry is made in the ^%MV.CATALOG global. Use the (G) option to catalog globally:
USER:CATALOG BP NOW (G
[244] 'NOW' Cataloged Global.
USER:[ZW ^%MV.CATALOG("NOW")
^%MV.CATALOG("NOW")="MVG.A9"
The compiled routine MVB.2 was copied to MVG.A9 (always a generated name beginning with MVG) in the %SYS namespace. When looking for a verb, the mv shell first looks in the voc, and if it doesn't find a verb, looks in ^%MV.CATALOG. So when you catalog a program globally, the catalog entry is visible in every account, provided that the VOC doesn't already contain a verb with the same name.
Normally, a VOC entry overrides a global catalog entry. However, in CEMU UNIDATA, if you prefix a name with a star, it will always look for a global catalog entry. So even with a local or normal voc catalog entry, *NOW will always look for NOW in the global catalog.
As with Normal cataloging, Global cataloging makes a copy of the compiled routine, so if the program is changed and recompiled, you also need to re-catalog to have the catalog entry run the most current version. This allows you to debug and test a program in a test account using a locally cataloged verb before making it available to production as a globally cataloged verb.
Because there is no VOC entry for globally catalog programs, the behavior of such programs is partially limited. For example, PROTOCLASS can *not* be globally cataloged, because it requires special flags in a VOC catalog entry to enable TCL-II features.
Also, with no VOC entry, the information on lines 8,9 and 10 pointing to program source is not immediately available. However, the cataloging process does store this information in the ^MV.RTN global:
USER:[ZW ^%MV.RTN("MVG.A9")
^%MV.RTN("MVG.A9")=$lb("B","USER","BP","NOW",2)
ACCOUNT CATALOGING
Account Cataloging is a special version of global cataloging. When you catalog using the (GA) parenthetical option, an entry is made in the global catalog, as with the (G) option alone, but the entry is made under the name *ACCOUNT*PROGRAM:
USER:CATALOG BP NOW (GA
[244] 'NOW' Cataloged Global.
USER:*USER*NOW
11:08:41 15 Oct 2012
This entry is visible from all accounts. Account Cataloging allows you to easily run versions of programs from different accounts.
----REQUIRED CATALOGING----
You can run any compiled mvbasic program or subroutine using the RUN command (If you RUN a subroutine, the subroutine's parameters are unassigned). However, to call a subroutine-- using the mvbasic CALL statement, or the itype SUBR statement, or as a user defined function with DEFFUN--the subroutine must be cataloged.
---CATALOGING AND STUDIO DEBUGGING---
When you compile a program in Cache Studio, Studio will also catalog it. Studio will only catalog a program locally. There is currently no option to change this. If the program is already cataloged normally (or if there is some other VOC entry using the name) Studio will never overwrite the pre-existing VOC entry. Studio displays a message in the output window when the catalog fails, but does not treat it as an error--there is no popup box, just a warning. If you use normal cataloging, or use a CEMU where normal cataloging is the default, beware that you might have to manually catalog programs when studio can't.
When you set a program as a debugging target in studio, and run it, studio always runs it as though you used the RUN verb. It does not use any catalog entry to run a debug target, and It will always run the most recently compiled version of debug targets. Consequently, programs like PROTOCLASS which require flags in the catalog entry will not work in Studio.
When Studio encounters a CALL statement, it does use the catalog entry to find the subroutine. This can be a problem if the subroutine was compiled through a q-pointer to another account. If a subroutine from another account is cataloged locally or globally, Studio will not be able to step into it, because of issues that Studio has with changing namespaces while running. If studio needs to step into a subroutine where the source is in a different account, the subroutine must be cataloged Normally. When you catalog Normally, the compiled routine is copied into the current account, and Studio will be able to debug it.
----DECATALOGING----
If you want to remove a catalog entry, use the DECATALOG verb.
DECATALOG will remove the catalog entry, but by default it does not remove the compiled routine. After decataloging, you can still run the program with RUN or re-catalog it. You can use the (A) option on DECATALOG to also get rid of the compiled routine:
USER:DECATALOG BP NOW
NOW
USER:NOW
'NOW' is not a verb.
USER:CATALOG BP NOW
[241] 'NOW' Cataloged.
USER:NOW
11:51:13 15 Oct 2012
USER:DECATALOG BP NOW (A
NOW
USER:CATALOG BP NOW
[40] Program 'NOW' has not been compiled.
----PRINT.CATALOG---
you can use the PRINT.CATALOG command to display information about cataloged programs. For example:
USER:PRINT.CATALOG BP NOW
[233] Program 'NOW' is Globally cataloged.
Target is routine 'MVG.151' compiled 10/22/12 15:32:18.
Source Account: USER, File: BP, Item: NOW
----CREATING CATALOG ENTRIES FOR OTHER ROUTINES----
There is a special format for voc catalog entries which allows you to create verbs for class methods. Look at the voc entry for the LISTDICT verb:
LISTDICT
0001 V
0002 ListDict
0003 M
0004
0005 2DCA
The M on line 3 tells the shell to look for up name on line 2 as a class method in the %MV.Verbs class. The %MV.Verbs class gets overwritten when you upgrade a cache instance, so be careful if you use this mechanism to catalog your own class methods.
The voc catalog format is fairly flexible and can be used to create verbs for object script routines. For example:
SYSPROG:ED MD DATABASE
DATABASE
New record.
----:I
0001= V
0002= DATABASE
0003= B
0004=
Bottom at line 3.
----:FI
"DATABASE" filed in file "MD".
SYSPROG:DATABASE
1) Create a database
2) Edit a database
3) List databases
4) Delete a database
5) Mount a database
6) Dismount a database
7) Compact globals in a database
8) Show free space for a database
9) Show details for a database
10) Recreate a database
11) Manage database encryption
12) Return unused space for a database
13) Compact freespace in a database
14) Defragment globals in a database
Option?
The "B" on line 3 tells the mv shell that this is a catalog entry for an mvbasic program, but the format is flexible enough that you can put any valid routine name on line 2. In the example DATABASE refers to the ^DATABASE routine. The routine name could be qualified with a namespace name, for example:
0002 DATABASE]%SYS
but in this example, the ^DATABASE routine can only be run in %SYS (^DATABASE calls methods from classes that are normally only mapped into the %SYS namespace)
----CATALOGING FOR THE OBJECTSCRIPT SHELL----
In the object script shell, there is no direct equivalent of the multi value VOC. Everything entered at the shell needs to be a valid object script command. However, it is possible to create new object script commands. Refer to the documentation at http://server:port/csp/docbook/DocBook.UI.Page.cls?KEY=GSTU_customize#GSTU_customize_zlang
For example, you can add a command ZZE to quickly display the description for a %Status return code. Enter this text into a new object script routine in Studio:
; Decode and display the passed error. If no error passed, then use
; %objlasterror. If %objlasterror doesn't exist, then display nothing.
ZZE(Status) public {
Set $ZTRAP="zzderr"
if '$DATA(Status) {
if $data(%objlasterror) {
do $SYSTEM.Status.DisplayError(%objlasterror)
} else {
;Don't display anything if no error
}
} else {
do $SYSTEM.Status.DisplayError(Status)
}
Quit
zzderr Set $ZTRAP="" Ztrap $ZUTIL(96,3,$ZUTIL(96,0)) ; Throws error to caller
}
and save the routine as %ZLANGC00. Then you can use it as:
USER>s st=$SYSTEM.OBJ.Load("oops","c-d")
USER>zze st
ERROR #5012: File 'oops' does not exist
Note that the example ZZE will work when entered from the object script shell, and will also work from the mv shell when entered as:
USER:COS ZZE
OR
USER:[ZZE
but it will not work in mvbasic with the $XECUTE statement:
USER:;st=$SYSTEM.OBJ->Load("oops","c-d")
USER:;$xecute "zze"
<SYNTAX>^MVBASIC1972.mvi
If you want custom objects script commands to work with $XECUTE in mvbasic, you need to also create a routine named %ZLANGC11 with the same contents as %ZLANGC00.
USER:ED BP NOW
NOW
New record.
----:I
0001= CRT TIMEDATE()
0002=
Bottom at line 1.
----:FI
"NOW" filed in file "BP".
USER:BASIC BP NOW
NOW
[B0] Compilation completed.
USER:RUN BP NOW
09:24:58 15 Oct 2012
But using RUN requires you to know what file the program NOW was compiled from, and also involves more typing. To run a program using just it's name, you can catalog it:
USER:CATALOG BP NOW
[243] 'NOW' Cataloged Local.
USER:NOW
09:32:18 15 Oct 2012
After cataloging, You can run NOW just by typing NOW.
----TYPES OF CATALOGING----
The various legacy multivalue platforms evolved different forms of cataloging, serving various purposes in different ways. Cache supports 4 styles of cataloging: Local, Normal, Global, and Global Account.
The account's CEMU emulation controls the default cataloging style. In most emulations, Local cataloging is the default. Non-default styles are chosen by adding a parenthetical option to the CATALOG command.
LOCAL CATALOGING:
Cataloging a program "Locally" creates a verb in the VOC of the current account. The verb points to the compiled version of the program. To catalog a program locally, use the (L) option:
USER:CATALOG BP NOW (L
[243] 'NOW' Cataloged Local.
USER:CT VOC NOW
NOW
0001 V
0002 MVB.2]USER
0003 B
0004
0005
0006
0007 L
0008 NOW
0009 BP
0010 USER
In this case, the mvbasic item BP NOW was compiled, producing the routine MVB.2 (the routine name MVB.2 is generated by cache because not all possible mv program names are also valid routine names. If the BP NOW program contains the #PRAGMA ROUTINENAME directive specifying a routine name, then that name would be used for the routine instead of a generated one). When the new NOW catalog verb is run, it will run the MVB.2 routine.
If the BP NOW program is changed and recompiled, the MVB.2 routine will be updated. Because the catalog entry points to MVB.2 the existing catalog entry will always run the most recently compiled version of BP NOW.
Local cataloging only creates a catalog verb in the voc of the current account. If you want the verb in other accounts, you will need to also catalog in those accounts. However, once cataloged, the verb in those accounts will also point to the latests compiled version of the program.
The first line of the catalog entry contains the letter V indicating that this is a verb. The second line contains the compiled routine name, a value mark, and the namespace that the routine is in. The namespace is necessary if the program file is a q-pointer to a file in a different namespace. The third line is the letter B indicating that this is a catalog pointer for an mvbasic program. Line 7 contains the letter "L" indicating that this program is cataloged locally. Lines 8,9, and 10 give the account/file/item name of the program source. Note that line 2 contains the namespace name, while line 10 is the account name. These might be different if the account name is not a valid namespace name (for example, creating an account MY.ACCT will create a namespace MYACCT, because dots aren't allowed in namespace names).
Line 4,5 and 6 can contain other flags that control how the verb is run. The CATALOG command itself doesn't write or modify these flags. See the sample programs PROTOCLASS and LIST.CSV for examples of some of these flags. Also see the tip on VOC item formats at https://sites.google.com/site/intersystemsmv/home/a-cache-of-tips/vocformat
NORMAL CATALOGING
Cataloging "Normally" creates a verb that points to a *copy* of the compiled routine. Use the (N) flag to catalog Normally.
USER:CATALOG BP NOW (N)
[241] 'NOW' Cataloged.
USER:CT VOC NOW
NOW
0001 V
0002 MVC.1]USER
0003 B
0004
0005
0006
0007
0008 NOW
0009 BP
0010 USER
The program BP NOW was compiled into routine MVB.2, but line 2 of the catalog verb references a different routine, MVC.1. When cataloging Normally, the compiled routine MVB.2 is copied to a new routine (which will always have a generated name MVC.nn--thus you may want to avoid normal cataloging if you plan to use the #PRAGMA ROUTINENAME directive). As a result, running the catalog verb will run the compiled version of BP NOW that existed when the verb was cataloged. If BP NOW is recompiled, MVB.2 will be updated, but the routine in the catalog verb (MVC.1) is not, so the catalog verb will continue to run the same old version of the routine. To get a new version, the program must be re-cataloged.
The namespace referenced on line 2 of the catalog entry will always be the namespace for the current account. Even if BP is a q-pointer to a different account, the routine from that other account will be copied to an MVC.nnn name in the current account.
As with Local cataloging, the catalog entry is only written to the voc in the current account, so you need to catalog in every account where you need the verb to be used, and you will need to re-catalog in those accounts when the program changes.
Otherwise, the voc catalog entry is mostly the same as for a locally cataloged program. Line 7 is empty instead of containing "L" (since it isn't cataloged Locally). Lines 8,9, and 10 still point to the program source, but that source may be newer than the version used to compile the MVC.1 routine that gets run by the catalog verb.
GLOBAL CATALOGING
Cataloging "globally" does not create a verb in the VOC (and will delete any existing VOC catalog entry in the current account). Instead, a copy of the compiled routine is placed in a global catalog area (in the %SYS namespace. %SYS is the namespace used by the SYSPROG account) and an entry is made in the ^%MV.CATALOG global. Use the (G) option to catalog globally:
USER:CATALOG BP NOW (G
[244] 'NOW' Cataloged Global.
USER:[ZW ^%MV.CATALOG("NOW")
^%MV.CATALOG("NOW")="MVG.A9"
The compiled routine MVB.2 was copied to MVG.A9 (always a generated name beginning with MVG) in the %SYS namespace. When looking for a verb, the mv shell first looks in the voc, and if it doesn't find a verb, looks in ^%MV.CATALOG. So when you catalog a program globally, the catalog entry is visible in every account, provided that the VOC doesn't already contain a verb with the same name.
Normally, a VOC entry overrides a global catalog entry. However, in CEMU UNIDATA, if you prefix a name with a star, it will always look for a global catalog entry. So even with a local or normal voc catalog entry, *NOW will always look for NOW in the global catalog.
As with Normal cataloging, Global cataloging makes a copy of the compiled routine, so if the program is changed and recompiled, you also need to re-catalog to have the catalog entry run the most current version. This allows you to debug and test a program in a test account using a locally cataloged verb before making it available to production as a globally cataloged verb.
Because there is no VOC entry for globally catalog programs, the behavior of such programs is partially limited. For example, PROTOCLASS can *not* be globally cataloged, because it requires special flags in a VOC catalog entry to enable TCL-II features.
Also, with no VOC entry, the information on lines 8,9 and 10 pointing to program source is not immediately available. However, the cataloging process does store this information in the ^MV.RTN global:
USER:[ZW ^%MV.RTN("MVG.A9")
^%MV.RTN("MVG.A9")=$lb("B","USER","BP","NOW",2)
ACCOUNT CATALOGING
Account Cataloging is a special version of global cataloging. When you catalog using the (GA) parenthetical option, an entry is made in the global catalog, as with the (G) option alone, but the entry is made under the name *ACCOUNT*PROGRAM:
USER:CATALOG BP NOW (GA
[244] 'NOW' Cataloged Global.
USER:*USER*NOW
11:08:41 15 Oct 2012
This entry is visible from all accounts. Account Cataloging allows you to easily run versions of programs from different accounts.
----REQUIRED CATALOGING----
You can run any compiled mvbasic program or subroutine using the RUN command (If you RUN a subroutine, the subroutine's parameters are unassigned). However, to call a subroutine-- using the mvbasic CALL statement, or the itype SUBR statement, or as a user defined function with DEFFUN--the subroutine must be cataloged.
---CATALOGING AND STUDIO DEBUGGING---
When you compile a program in Cache Studio, Studio will also catalog it. Studio will only catalog a program locally. There is currently no option to change this. If the program is already cataloged normally (or if there is some other VOC entry using the name) Studio will never overwrite the pre-existing VOC entry. Studio displays a message in the output window when the catalog fails, but does not treat it as an error--there is no popup box, just a warning. If you use normal cataloging, or use a CEMU where normal cataloging is the default, beware that you might have to manually catalog programs when studio can't.
When you set a program as a debugging target in studio, and run it, studio always runs it as though you used the RUN verb. It does not use any catalog entry to run a debug target, and It will always run the most recently compiled version of debug targets. Consequently, programs like PROTOCLASS which require flags in the catalog entry will not work in Studio.
When Studio encounters a CALL statement, it does use the catalog entry to find the subroutine. This can be a problem if the subroutine was compiled through a q-pointer to another account. If a subroutine from another account is cataloged locally or globally, Studio will not be able to step into it, because of issues that Studio has with changing namespaces while running. If studio needs to step into a subroutine where the source is in a different account, the subroutine must be cataloged Normally. When you catalog Normally, the compiled routine is copied into the current account, and Studio will be able to debug it.
----DECATALOGING----
If you want to remove a catalog entry, use the DECATALOG verb.
DECATALOG will remove the catalog entry, but by default it does not remove the compiled routine. After decataloging, you can still run the program with RUN or re-catalog it. You can use the (A) option on DECATALOG to also get rid of the compiled routine:
USER:DECATALOG BP NOW
NOW
USER:NOW
'NOW' is not a verb.
USER:CATALOG BP NOW
[241] 'NOW' Cataloged.
USER:NOW
11:51:13 15 Oct 2012
USER:DECATALOG BP NOW (A
NOW
USER:CATALOG BP NOW
[40] Program 'NOW' has not been compiled.
----PRINT.CATALOG---
you can use the PRINT.CATALOG command to display information about cataloged programs. For example:
USER:PRINT.CATALOG BP NOW
[233] Program 'NOW' is Globally cataloged.
Target is routine 'MVG.151' compiled 10/22/12 15:32:18.
Source Account: USER, File: BP, Item: NOW
----CREATING CATALOG ENTRIES FOR OTHER ROUTINES----
There is a special format for voc catalog entries which allows you to create verbs for class methods. Look at the voc entry for the LISTDICT verb:
LISTDICT
0001 V
0002 ListDict
0003 M
0004
0005 2DCA
The M on line 3 tells the shell to look for up name on line 2 as a class method in the %MV.Verbs class. The %MV.Verbs class gets overwritten when you upgrade a cache instance, so be careful if you use this mechanism to catalog your own class methods.
The voc catalog format is fairly flexible and can be used to create verbs for object script routines. For example:
SYSPROG:ED MD DATABASE
DATABASE
New record.
----:I
0001= V
0002= DATABASE
0003= B
0004=
Bottom at line 3.
----:FI
"DATABASE" filed in file "MD".
SYSPROG:DATABASE
1) Create a database
2) Edit a database
3) List databases
4) Delete a database
5) Mount a database
6) Dismount a database
7) Compact globals in a database
8) Show free space for a database
9) Show details for a database
10) Recreate a database
11) Manage database encryption
12) Return unused space for a database
13) Compact freespace in a database
14) Defragment globals in a database
Option?
The "B" on line 3 tells the mv shell that this is a catalog entry for an mvbasic program, but the format is flexible enough that you can put any valid routine name on line 2. In the example DATABASE refers to the ^DATABASE routine. The routine name could be qualified with a namespace name, for example:
0002 DATABASE]%SYS
but in this example, the ^DATABASE routine can only be run in %SYS (^DATABASE calls methods from classes that are normally only mapped into the %SYS namespace)
----CATALOGING FOR THE OBJECTSCRIPT SHELL----
In the object script shell, there is no direct equivalent of the multi value VOC. Everything entered at the shell needs to be a valid object script command. However, it is possible to create new object script commands. Refer to the documentation at http://server:port/csp/docbook/DocBook.UI.Page.cls?KEY=GSTU_customize#GSTU_customize_zlang
For example, you can add a command ZZE to quickly display the description for a %Status return code. Enter this text into a new object script routine in Studio:
; Decode and display the passed error. If no error passed, then use
; %objlasterror. If %objlasterror doesn't exist, then display nothing.
ZZE(Status) public {
Set $ZTRAP="zzderr"
if '$DATA(Status) {
if $data(%objlasterror) {
do $SYSTEM.Status.DisplayError(%objlasterror)
} else {
;Don't display anything if no error
}
} else {
do $SYSTEM.Status.DisplayError(Status)
}
Quit
zzderr Set $ZTRAP="" Ztrap $ZUTIL(96,3,$ZUTIL(96,0)) ; Throws error to caller
}
and save the routine as %ZLANGC00. Then you can use it as:
USER>s st=$SYSTEM.OBJ.Load("oops","c-d")
USER>zze st
ERROR #5012: File 'oops' does not exist
Note that the example ZZE will work when entered from the object script shell, and will also work from the mv shell when entered as:
USER:COS ZZE
OR
USER:[ZZE
but it will not work in mvbasic with the $XECUTE statement:
USER:;st=$SYSTEM.OBJ->Load("oops","c-d")
USER:;$xecute "zze"
<SYNTAX>^MVBASIC1972.mvi
If you want custom objects script commands to work with $XECUTE in mvbasic, you need to also create a routine named %ZLANGC11 with the same contents as %ZLANGC00.
Reply all
Reply to author
Forward
0 new messages