m204wiki - User contributions [en]

https://m204wiki.rocketsoftware.com/api.php?action=feedcontributions&feedformat=atom&user=JAL3 m204wiki - User contributions [en] 2026-05-08T12:29:07Z User contributions MediaWiki 1.43.1 https://m204wiki.rocketsoftware.com/index.php?title=Serial_(XmlDoc/XmlNode_function)&diff=11482 Serial (XmlDoc/XmlNode function) 2011-03-29T21:25:43Z

<p>JAL3: /* See also */</p> <hr /> <div>{{Template:XmlDoc/XmlNode:Serial subtitle}}<br /> <br /> This function converts an <var>XmlDoc</var> subtree to the UTF-8 or EBCDIC<br /> text string representation of the subtree.<br /> (This process is called '''serialization''',<br /> because the text representation of a document is called the '''serial'''<br /> form.)<br /> ==Syntax==<br /> {{Template:XmlDoc/XmlNode:Serial syntax}}<br /> ===Syntax terms===<br /> <table class="syntaxTable"><br /> <tr><th>%string</th><br /> <td>A string variable for the string serialization of the subtree, encoded either in UTF-8 or, if the <var>EBCDIC</var> option (see below) is used, in EBCDIC. </td></tr><br /> <br /> <tr><th>nr</th><br /> <td>An <var>XmlDoc</var> or <var>XmlNode</var>, used as the context node for the <var class="term">xpath</var> expression. If an <var>XmlDoc</var>, the <var>Root</var> node is the context node. </td></tr><br /> <br /> <tr><th>xpath</th><br /> <td>A <var>Unicode</var> string that is an [[XML processing in Janus SOAP#XML Path Language (XPath) in the XmlDoc API|XPath]] expression that results in a nodelist, the head of which is the top of the subtree to serialize. This is an optional argument; its default is a period (<tt>.</tt>), that is, the node referenced by the method object (<var class="term">nr</var>).<br /> <br /> Prior to <var class="product">Sirius Mods</var> version 7.6, this is an EBCDIC string. </td></tr><br /> <br /> <tr><th>options</th><br /> <td>A blank delimited string that can contain one or more of the following options (but no repeats), which are identified below and described in greater detail in [[XmlDoc API serialization options|"XmlDoc API serialization options"]]: <br /> <ul> <br /> <li><b>EBCDIC</b><br><br /> Produces serialized output in EBCDIC text rather than the default encoding, UTF-8. <br /> <br /> <li><b>ExclCanonical</b><br><br /> Produces serialized output in exclusive XML canonical form, as defined in the W3C "Exclusive XML Canonicalization" specification (http://www.w3.org/tr/xml-exc-c14n). <br /> <br /> <li><b>Indent <i>n</i></b><br><br /> Inserts space characters and line-ends into the serialized string such that if the string is broken at the line-ends and displayed as a tree, the display of each lower level in the subtree is indented ''n'' spaces from the previous level's starting point. You must also specify <var>CR</var>, <var>LF</var>, or <var>CRLF</var> (see below).<br /> <br /> <li><b>CR</b> (carriage-return), <b>LF</b> (linefeed), or <b>CRLF</b> (carriage-return followed by a linefeed)<br><br /> Inserts one of these line-end characters to provide line breaks in the serialized output. <br /> <br /> <li><b>NoEmptyElt</b><br><br /> Deprecated as of <var class="product">Sirius Mods</var> version 7.0, this option ensures that all empty elements are serialized with a start tag followed by an end tag. The default is to serialize an empty element with an empty element tag (as in <code><middleName/></code>).<br /> <br /> <li><b>OmitNullElement</b><br><br /> An <var>Element</var> node that has no children and no <var>Attributes</var> will not be serialized, unless it is the top level <var>Element</var> in the subtree being serialized. <br /> <br /> <li><b>SortCanonical</b><br> <br /> <br /> This deprecated option serializes namespace declarations and attributes in sorted order (from lowest to highest with Unicode code ordering).<br /> It is superseded by the <var>ExclCanonical</var> option. <br /> <br /> <li><b>WithComments</b><br> <br /> Includes in the serialized output all <var>Comment</var> nodes in the specified subtree. <br /> <p>'''Note:''' Specifying <var>WithComments</var> without specifying <var>ExclCanonical</var> has no effect. Specifying <var>ExclCanonical</var> without specifying <var>WithComments</var> suppresses all <var>Comment</var> nodes from the result.</p> <br /> <br /> <li><b>XmlDecl</b><br><br /> Ensures that the serialization will contain the "XML Declaration" (<code><?xml version=...?></code>), if the value of the <var>[[Version (XmlDoc property)|Version]]</var> property is a non-null string, if the <var>XmlDoc</var> is not empty,<br /> and if the top of the subtree being serialized is the <var>Root</var> node.</ul></td></tr><br /> <br /> <tr><th><var>AddTrailingDelimiter</var></th><br /> <td>This <var>[[Boolean]]</var>, [[Methods#Named_parameters|name required]] parameter determines whether a final line-end character is added to the serialization when one of the <var>Serial</var> method line-end options (<var>LF</var>, <var>CR</var>, or <var>CRLF</var>) is specified.<br /> <br /> The default value of <var>AddTrailingDelimiter</var> is <var>True</var>, so <var>Serial</var> specified with a line-end option adds a trailing line-end by default. If <var>AddTrailingDelimiter</var> is <var>False</var>, no final line-end character is added.<br /> Specifying the <var>AddTrailingDelimiter</var> argument without also specifying one of the line-end options has no effect on the resulting serialization.<br /> <var>AddTrailingDelimiter</var> is new as of <var class="product">Sirius Mods</var> version 7.0. It may be useful if a digital signature must be created which includes line-end characters between XML tags, but the <var>XmlDoc</var> does not contain those line-end <var>Text</var> nodes.</td></tr><br /> </table><br /> <br /> ==Usage notes==<br /> <ul><br /> <li>The <var class="term">options</var> argument values may be specified in any case.<br /> For example, <code>XmlDecl</code> and <code>xmldecl</code> are interchangeable.<br /> <br /> <li>As of <var class="product">Sirius Mods</var> version 7.6, <var>Attribute</var> values are always serialized<br /> within double-quotation-mark (<tt>"</tt>) delimiters,<br /> and a double-quotation mark character in an <var>Attribute</var> value is serialized<br /> as <code>&amp;quot;</code>.<br /> Prior to version 7.6, this convention was not strictly observed.<br /> </ul><br /> <br /> ==Examples==<br /> In the following example, the <var>Serial</var> method EBCDIC<br /> formatting of a document is shown.<br /> A <var>Print</var> statement display of the default UTF-8 formatting of <var>Serial</var> is a<br /> string that is not readily decipherable.<br /> <p class="code">Begin<br /> %doc is Object XmlDoc<br /> %sl is Object Stringlist<br /> %doc = New<br /> %sl = New<br /> <br /> text to %sl<br /> <nowiki><top><br /> <a><br /> <b>05</b><br /> </a><br /> <c><br /> <d att="val"/><br /> </c><br /> </top></nowiki><br /> end text<br /> <br /> Call %doc:LoadXml(%sl)<br /> Print 'Serial method output follows:'<br /> Print %doc:Serial('top', 'ebcdic')<br /> End<br /> </p><br /> <br /> The example results follow:<br /> <p class="output">Serial method output follows:<br /> <nowiki><top><a><b>05</b></a><c><d att="val"/></c></top></nowiki><br /> </p><br /> <br /> ==Request-Cancellation Errors==<br /> <ul><br /> <li><var class="term">xpath</var> is invalid.<br /> <li>Result of <var class="term">xpath</var> is empty.<br /> <li>An <var class="term">options</var> setting is invalid.<br /> <li>Insufficient free space exists in CCATEMP.<br /> </ul><br /> <br /> ==See also==<br /> <br /> <ul><br /> <li>The subroutine that serializes an <var>XmlDoc</var> and sends it as a<br /> Web response is <var>[[WebSend (XmlDoc subroutine)|WebSend]]</var>.<br /> <li>Additional serializing methods include:<br /> <ul><br /> <li><var>[[Xml (XmlDoc function)|Xml]]</var><br /> <li><var>[[Print (XmlDoc/XmlNode subroutine)|Print]]</var><br /> <li><var>[[AddXml]]</var> (<var>[[HttpRequest]]</var> class)<br /> </ul><br /> <li>To deserialize a string,<br /> use <var>[[LoadXml (XmlDoc/XmlNode function)|LoadXml]]</var><br /> or <var>[[WebReceive (XmlDoc function)|WebReceive]]</var>.<br /> <li>For more information about using XPath expressions, see [[XPath|"XPath"]].<br /> </ul><br /> <br /> {{Template:XmlDoc/XmlNode:Serial footer}}</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=CurrentTimeMilliseconds_(System_function)&diff=41201 CurrentTimeMilliseconds (System function) 2011-03-29T21:19:05Z

<p>JAL3: /* See also */</p> <hr /> <div>{{Template:System:CurrentTimeMilliseconds subtitle}}<br /> <br /> ==Syntax==<br /> {{Template:System:CurrentTimeMilliseconds syntax}}<br /> ===Syntax terms===<br /> <table class="syntaxTable"><br /> <tr><th>%number</th><td>A numeric variable to receive the current time, in milli-seconds, since January 1, 1900.</td></tr><br /> <tr><th>%(System)</th><br /> <td>The class name in parentheses denotes a shared method. <var>CurrentTimeMilliseconds</var> can also be invoked via a <var>System</var> object variable, which may be null.</td></tr><br /> </table><br /> <br /> ==Usage notes==<br /> <br /> ==Examples==<br /> Oohh bad<br /> <br /> ==See also==<br /> <ul><li><var>CurrentTimeMilliseconds</var> is the same as <var>[[$Sir_DateNM]]</var>.</ul><br /> {{Template:System:CurrentTimeMilliseconds footer}}<br /> <table><tr><td><ul><li>[[Talk:CurrentTimeMilliseconds (System function)|User contributions]] <br>You are encouraged to add examples, corrections, etc. User contributions are not validated by Sirius.</ul></td></tr></table></div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=CurrentTimeMilliseconds_(System_function)&diff=41199 CurrentTimeMilliseconds (System function) 2011-03-29T15:58:02Z

<p>JAL3: </p> <hr /> <div>{{Template:System:CurrentTimeMilliseconds subtitle}}<br /> <br /> ==Syntax==<br /> {{Template:System:CurrentTimeMilliseconds syntax}}<br /> ===Syntax terms===<br /> <table class="syntaxTable"><br /> <tr><th>%number</th><td>A numeric variable to receive the current time, in milli-seconds, since January 1, 1900.</td></tr><br /> <tr><th>%(System)</th><br /> <td>The class name in parentheses denotes a shared method. <var>CurrentTimeMilliseconds</var> can also be invoked via a <var>[[System object]]</var> variable, which may be null.</td></tr><br /> </table><br /> <br /> ==Usage notes==<br /> <br /> ==Examples==<br /> Oohh bad<br /> <br /> ==See also==<br /> <ul><li><var>CurrentTimeMilliseconds</var> is the same as <var>[[$Sir_DateNM]]</var>.</ul><br /> {{Template:System:CurrentTimeMilliseconds footer}}<br /> <table><tr><td><ul><li>[[Talk:CurrentTimeMilliseconds (System function)|User contributions]]: You are encouraged to add examples, corrections, etc. User contributions are not validated by Sirius.</ul></td></tr></table></div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=CurrentTimeMilliseconds_(System_function)&diff=41198 CurrentTimeMilliseconds (System function) 2011-03-29T15:55:11Z

<p>JAL3: /* See also */</p> <hr /> <div>{{Template:System:CurrentTimeMilliseconds subtitle}}<br /> <br /> ==Syntax==<br /> {{Template:System:CurrentTimeMilliseconds syntax}}<br /> ===Syntax terms===<br /> <table class="syntaxTable"><br /> <tr><th>%number</th><td>A numeric variable to receive the current time, in milli-seconds, since January 1, 1900.</td></tr><br /> <tr><th>%(System)</th><br /> <td>The class name in parentheses denotes a shared method. <var>CurrentTimeMilliseconds</var> can also be invoked via a <var>[[System object]]</var> variable, which may be null.</td></tr><br /> </table><br /> <br /> ==Usage notes==<br /> <br /> ==Examples==<br /> Oohh bad<br /> <br /> ==See also==<br /> <ul><li><var>CurrentTimeMilliseconds</var> is the same as <var>[[$Sir_DateNM]]</var>.</ul><br /> {{Template:System:CurrentTimeMilliseconds footer}}<br /> <table><tr><td>[[Talk:CurrentTimeMilliseconds (System function)|User contributions]]: You are encouraged to add examples, corrections, etc. User contributions are not validated by Sirius.</td></tr></table></div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=Journal_class&diff=14009 Journal class 2011-03-25T21:53:12Z

<p>JAL3: </p> <hr /> <div><br /> The Journal class provides an object-oriented interface to<br /> CCAJLOG or CCAJRNL datasets and streams, including those that have<br /> been aggregated by the MERGEJ utility.<br /> A ''Model 204'' stream is a<br /> datastream comprising one or more sequential journals which is created by the ''Model 204''<br /> DEFINE STREAM command (see the [[Model 204 Command Reference Manual]]).<br /> <br /> To extract information programmatically<br /> about the contents of a Journal object, you use<br /> the methods of the Journal class.<br /> To view such a journal's actual data, you use the Stringlist class<br /> [[AppendJournalData (Stringlist function)|AppendJournalData]] function<br /> &mdash;<br /> or you use [[SirScan]], which implicitly calls AppendJournalData.<br /> <br /> The Journal class is available in ''Sirius Mods'' 7.7 and later.<br /> <br /> The Journal class operates on CCAJRNL or CCAJLOG datasets or streams,<br /> which you make available to your Online by any of the following:<br /> <ul><br /> <li>An MVS DD card.<br /> <li>A VSE DLBL card.<br /> <li>A CMS FILEDEF command.<br /> <li>A ''Model 204'' ALLOCATE command (see the ''Model 204 Command Reference Manual'').<br /> <li>A ''Model 204'' DEFINE STREAM command (see the ''Model 204 Command Reference Manual'').<br /> </ul><br /> <br /> The [[List of Journal methods]] lists all the methods in this class.<br /> <br /> ==Journal example==<br /> <br /> The following example is a program that displays the properties and contents of a<br /> historical CCAJRNL.<br /> The request makes use of a low setting of the parameter option MAXREC of the<br /> AppendJournalData method to control the amount of journal data that is displayed:<br /> <br /> Begin<br /> %list is object stringlist<br /> %rc is float<br /> %jStartTime is longstring<br /> %jEndTime is longstring<br /> %journal is object Journal<br /> %msg is longstring<br /> %sTime is longstring<br /> %eTime is longstring<br /> %jHold is longstring<br /> %parm is longstring<br /> %threads is longstring<br /> <br /> '''* Get old journal and view its properties'''<br /> %journal = new('OLDJRNL')<br /> if %journal eq Null then<br /> %msg = 'Journal is invalid or not allocated.'<br /> jump to someErrorCondition<br /> end if<br /> <br /> printText {~} is {%journal:isMerged:tostring}<br /> printText {~} is {%journal:MergeCount}<br /> printText {~} is {%journal:stringFirstDateTime}<br /> printText {~} is {%journal:stringLastDateTime}<br /> <br /> '''* Set values for appendJournalData call'''<br /> %list = new<br /> %parm = 'AA USER MAXREC=100'<br /> %threads = '*'<br /> %sTime = '1012202370444'<br /> %eTime = '1012302373097'<br /> <br /> '''* Test for time values that are out of range'''<br /> %jStartTime = %journal:stringFirstDateTime<br /> %jEndTime = %journal:stringLastDateTime<br /> if %sTime ge %jEndTime:subString(2) Then<br /> %jHold = %jEndTime<br /> %msg = 'Requested start time is after end of journal.'<br /> jump to someErrorCondition<br /> elseIf %eTime lt %jStartTime:subString(2) then<br /> %jHold = %jStartTime<br /> %msg = 'Requested end time is before start of journal.'<br /> jump to someErrorCondition<br /> end if<br /> <br /> '''* Call the method'''<br /> %rc = %list:appendJournalData( -<br /> StartTime=%sTime, -<br /> EndTime=%eTime, -<br /> Options=%parm, -<br /> Threads=%threads, -<br /> journal=%journal)<br /> <br /> Print %list:count AND 'list items:'<br /> If %list:count eq 0 then<br /> Print %rc And 'is return code'<br /> End If<br /> %list:print<br /> <br /> someErrorCondition:<br /> * do some error processing here<br /> Print %msg<br /> <br /> End<br /> <br /> <br /> The result is:<br /> <br /> %journal:isMerged:tostring is False<br /> %journal:MergeCount is 0<br /> %journal:stringFirstDateTime is 11012202370444<br /> %journal:stringLastDateTime is 11012509464897<br /> 100 list items:<br /> 0 ************************************************************************<br /> **<br /> 0 * MODEL 204 IS PROPRIETARY TO AND A REGISTERED TRADEMARK OF COMPUTER<br /> *<br /> 0 * CORPORATION OF AMERICA. ALL TITLE, COPYRIGHT AND OTHER PROPRIETARY<br /> *<br /> 0 * RIGHTS SHALL BE RETAINED BY COMPUTER CORPORATION OF AMERICA. MODEL<br /> 204 *<br /> 0 * HAS BEEN LICENSED BY THIS CUSTOMER AND THE USE AND PROTECTION OF<br /> *<br /> 0 * MODEL 204 IS GOVERNED BY THE LICENSE AGREEMENT BETWEEN THE CUSTOMER<br /> *<br /> 0 * AND COMPUTER CORPORATION OF AMERICA.<br /> *<br /> 0 *<br /> *<br /> 0 * COPYRIGHT (C) 2010 COMPUTER CORPORATION OF AMERICA<br /> *<br /> 0 * ALL RIGHTS RESERVED<br /> *<br /> 0 ************************************************************************<br /> **<br /> 0 M204.0060: MODEL 204 INITIALIZATION. VERSION = 7.2.0D EVCP/RSQL<br /> VERSION = 7.2.0D 03/01/10 23.11<br /> 0 M204.0061: SMF SYSTEM ID = CMS, JOB NAME = ULSPFPRO, STEP NAME =<br /> 02?³?2, JES ID =<br /> 0 M204.0062: EXECUTE PARAMETERS: SYSOPT=187,LIBUFF=1600,NJBUFF=31,<br /> RESTARTU=1,SIRTUNE=0<br /> 0 M204.1119: READING PARAMETERS<br /> ''' . . . (70+ lines not shown)'''<br /> <br /> [[Category:System classes]]</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=CharacterMap_class&diff=12345 CharacterMap class 2011-03-25T21:51:50Z

<p>JAL3: </p> <hr /> <div>A CharacterMap class object contains a mapping of characters to characters.<br /> Each character in an In string<br /> (the &ldquo;input table&rdquo;) is associated with, or mapped to, an individual character<br /> from an Out string (the &ldquo;output table&rdquo;).<br /> The output table may be supplemented with instances of a pad character<br /> to ensure a one-to-one mapping with the input table characters.<br /> <br /> The [[List of CharacterMap methods]] lists all the methods in this class.<br /> <br /> CharacterMap includes a constructor, copy methods, and an update method<br /> for modifying the map.<br /> ===Example===<br /> Most of these methods are shown in the following example,<br /> which features the intrinsic String [[Translate (String function)|Translate]] function.<br /> In the example, a new CharacterMap is the argument for the Translate method;<br /> then that map is copied and modified, and the modified map is used in a<br /> second Translate call:<br /> <br /> begin<br /> %map is object characterMap<br /> %map2 is object characterMap<br /> %ls is longstring<br /> <br /> %map = New(in='x-', out='!c')<br /> %ls = 'xu--exx'<br /> [[Targeted Text statements|printtext]] {~} = '{%ls:translate(%map)}'<br /> <br /> %map2 = %map:Copy<br /> %map2:Update(in='x',out='s')<br /> printtext {~} = '{%ls:translate(%map2)}'<br /> <br /> end<br /> <br /> <br /> The result is:<br /> <pre><br /> %ls:translate(%map) = '!ucce!!'<br /> %ls:translate(%map2) = 'success'<br /> </pre><br /> <br /> This class is new as of version 7.3 of the ''Sirius Mods''.<br /> [[Category:System classes]]</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=Daemon_class&diff=2325 Daemon class 2011-03-25T21:41:40Z

<p>JAL3: /* References */</p> <hr /> <div>The '''Daemon class''' provides a facility for issuing [[Model 204]] commands from inside a [[User Language]] request, simulating the calling of programs as if they were subroutines. <br /> <br /> Daemon objects are much like an object-oriented version of the Sirius $COMMxx $functions, which use Sirius sdaemons to run a command on another thread on behalf of the issuing user. Daemon objects offer a number of advantage over $COMMxx function, and over non-daemon program execution:<br /> <br /> <ul><br /> <li>They can execute multiple calls per sdaemon login/logout sequence.<br /> <li>From within a User Language program, you can issue commands that ordinarily cannot be executed within that program, for example, a REORG (for which you typically have to exit the program and execute another procedure).<br /> <li>From within a User Language program, you can call a legacy application that is already packaged as a program as if it were a subroutine. Ordinarily, such a program is equivalent to a command, and it cannot be called as a subroutine. You have to switch to it and set up complex mechanisms to pass control between the two routines.<br /> <li>You can reduce the size of your programs, gaining relief from server size limitations. Although a network service like a socket might also provide benefits comparable to those listed above, a Daemon object offers simplicity, both in the ability to implement and in the ease of adoption. Security-wise, there is no doubt which user is issuing the command, what subsystem that user is running, what files the user has open, what privileges the user has, etc.<br /> <li>Data structures are more easily passed between a master and an sdaemon than over a communications connection, where every data structure has to be serialized by the sender and deserialized by the receiver.<br /> </ul><br /> <br /> The Daemon API is implemented as a set of functions, subroutines and properties, documented as the [[:Category:Daemon methods|Daemon methods]].<br /> <br /> =Working with Daemon objects=<br /> <br /> In this Wiki the terms “daemon” or “daemon thread” are often used to mean “the sdaemon thread that is activated or involved when you employ or operate on a Daemon object.” The user or thread that invokes a daemon is the “master” or “master thread.” If a daemon itself invokes another daemon, both daemons have the same master, and the first daemon is the “parent” of the second. For more information about the master/parent distinction, see the [[#MasterNumber property|MasterNumber property]].<br /> <br /> A daemon thread runs a command on behalf of the issuing user, and the thread is only available to that master user. The thread does not, for example, maintain some context and accept requests from different users. A daemon thread operates (only) synchronously: processing on the issuing thread pauses to wait for the daemon thread to run the command(s) it receives. To pass a command to a daemon, you use the [[Run (Daemon function)|Run function]] with the command as argument. Two examples follow for the %foo Daemon object:<br /> <br /> %foo:Run('OPEN FILE MYPROC')<br /> %list = %foo:Run('I REPORT')<br /> <br /> To have a daemon thread run multiple commands, you can specify multiple Run method calls, or you can define the commands as items in a Stringlist, and then specify the Stringlist as the argument in the Run method. The Stringlist is fed to the daemon as terminal input and executed item by item until that input runs out. For example, if the commands from the examples above were defined in that order as the items in Stringlist %testproc, the following statement would include the procedure REPORT from the MYPROC file:<br /> <br /> %foo:run(%testproc)<br /> <br /> You use a Stringlist argument in this way to pass a User Language request to a daemon. Note: If the code in a request you pass to a daemon in a Stringlist depends on being mixed case, precede your Run method call with a statement like the following, so the daemon thread will preserve mixed case:<br /> <br /> %foo:run('*LOWER')<br /> <br /> Although a daemon thread is request-specific, Daemon objects do have persistence. The daemon thread waits for work as long as the Daemon object exists. Since the Daemon object can be Global or Session as well as not, its span of existence can be arbitrarily long or short, depending on how it is being used.<br /> <br /> By default, a daemon thread does not share record locks or transactions with its master thread, and Commits and Backouts apply only to the thread that issues them. However, you can easily create daemons that share the update unit with the issuing thread. When such a daemon (“[[#Transactional daemons|Transactional daemons]]”, below) commits or backs out a transaction, the issuing thread's updates are committed or backed out as well.<br /> <br /> If a daemon thread does a user restart, the request is cancelled, but the calling thread is not also restarted. If a calling thread is logged off or restarted, its associated daemon threads are deleted. A daemon is not automatically restarted if the master restarts. The daemon does a user restart if it is processing a User Language request that calls for terminal input, and no Run method input follows the end of request.<br /> <br /> =A Daemon example=<br /> <br /> In the following example, the Run method is called three times for the %speed daemon. In the first two calls, the daemon executes a command that has no output object. In the final call, it executes a request and returns an XmlDoc. Note the use of "text to %list" which captures to a stringList object the program we're submitting to the daemon:<br /> <br /> b<br /> %speed is object daemon<br /> %list is object stringList<br /> %silly is object xmlDoc<br /> %speed = new<br /> %speed:run('V UTABLE'):print<br /> %speed:run('*LOWER'):print<br /> %list = new<br /> text to %list<br /> b<br /> %doc is object xmlDoc<br /> %(daemon):getInputObject(%doc)<br /> %doc:selectSingleNode('/outer/inner'):addAttribute('foo','bar')<br /> %(daemon):returnObject(%doc)<br /> end<br /> end text<br /> %silly = new<br /> %silly:loadXml('<outer><inner><innest>huh?</innest></inner></outer>')<br /> %speed:run(%list, %silly, %silly)<br /> %silly:print<br /> end<br /> <br /> The example result follows:<br /> <br /> HDRCTL X'01' HEADER CONTROL<br /> LVTBL 3000 LENGTH OF VTBL<br /> LNTBL 150 LENGTH OF NTBL<br /> . . .<br /> . . .<br /> . . .<br /> FIXSIZE 20392 FIXED SERVER SIZE REQUIREMENT<br /> SERVACTV 150416 CURRENT SIZE OF THIS SERVER<br /> <br /> <outer><br /> <inner foo="bar"><br /> <innest>huh?</innest><br /> </inner><br /> </outer><br /> <br /> =Daemon record locking=<br /> <br /> Prior to Sirius Mods version 6.8, sdaemons running on behalf of other threads, via the $COMMxx functions or via Daemon objects, can suffer record locking conflicts with other threads in the same thread family, because they are separate update units. Two threads are in the same family if one is a synchronous child daemon of the other via a $COMMxx function or via a Daemon object. In addition, all families with common threads are considered to be a single family. So, if thread A is a synchronous parent of thread B, which is a synchronous parent of thread C, threads A, B, and C are all considered part of the same family. Furthermore, if in this example, thread B has two other synchronous children (via Daemon objects), threads D and E, then threads A, B, C, D, and E are all considered part of the same family.<br /> <br /> As of version 6.8, only one condition remains under which two threads in the same family can suffer a record locking conflict: if they both try to update the same record, which would require both threads to have an exclusive pending update lock on the record being updated. However, even this possibility of a record locking conflict is eliminated for [[#Transactional daemons|transactional daemons]].<br /> <br /> Sirius Mods version 7.0 introduced support for [[#Asynchronous and Independent daemons|asynchronous and independent]] running of daemon requests. A daemon running asynchronously or independently is, at that point, no longer part of the family for the purposes of record locking. That is, an independently or asynchronously running daemon, or any of its daemons, cannot hold record locks that would conflict with its original master or any other daemons in the master's family.<br /> <br /> Effectively, while a daemon is running independently or asynchronously, the master's family is split from the daemon's family. For example, thread A has daemon threads B, C, and D, and D has daemon threads E and F; if D runs asynchronously, then while it is running asynchronously, the family A, B, and C is considered separate from D, E, and F as far as record locking goes. Since an asynchronous request will (usually) eventually go back to waiting for its parent, at that point the families are rejoined. Since an independent request never rejoins its parent, once a family is split because a daemon is running independently, it is never rejoined. Since a daemon thread (and its daemons) that is running asynchronously or independently leaves its family at the moment it starts running asynchronously or independently, it is possible for the RunAsynchronously or RunIndependently methods to fail because they would result in a record locking conflict between the newly split families.<br /> <br /> =Transactional daemons=<br /> <br /> As of Sirius Mods version 6.8, the New constructor for Daemon objects has a Boolean, named parameter called Transactional:<br /> <br /> %pantalaimon is object daemon<br /> ...<br /> %pantalaimon = new(transactional=true)<br /> <br /> If Transactional is set to True, the master and daemon thread will share a single updating transaction. This means that if updates are performed by both the master and daemon thread, these updates are all committed or all backed out when a commit or backout is performed on either the daemon or master thread. If the master thread of a transactional daemon closes a file that was open in update mode, the transaction is committed; if the transactional daemon closes the file, the transaction is unaffected. If a transactional daemon thread is bumped, its master is also bumped.<br /> <br /> If a thread has multiple transactional daemons, then all those daemons share a single updating transaction with the master thread. In addition, if a transactional daemon thread itself has transactional daemon threads, those threads also share a single updating transaction with the ultimate master thread. Effectively, all of a thread's transactional daemons, and all those transactional daemon's transactional daemons, and so on, make up a transactional family that shares a single updating transaction. The processing of updating transactions on a transactional daemon thread differs from other threads in these ways:<br /> <br /> <ul><br /> <li>Transactional daemon threads never do an implied commit. Other threads typically do implied commits at end of request, unless inside a nonautocommit subsystem. In addition, certain operations, such as a procedure update, cause an implied commit on non-transactional daemon threads. Of course, an explicit Commit or Backout statement run on a transactional daemon thread results in the transaction being committed or backed out, including those updates performed on the master thread or some other thread in the transactional family.<br /> <li>As an outgrowth of the previous item, transactional daemon threads can perform procedure updates in the middle of an updating transaction, as well as other file maintenance operations, such as field definitions.<br /> <li>Transactional daemon threads cannot perform User Language updates against files that their ultimate master thread does not have open in update mode. The ultimate master thread is the thread's master or the master's master, if that thread is, itself, a transactional daemon, and so on. The actual commit or backout is always performed on the highest level master thread in a transactional family, so that thread must have update privileges for all files in an updating transaction. One benefit of this approach is that it's possible for a daemon thread to perform some updates, go away (log off), and for the update to still not be committed. As noted in "[[#Daemon record locking|Daemon record locking]]" below, transactional daemons cannot suffer record locking conflicts with other threads in the family, and they can even update the same records as other threads in the transactional family.<br /> </ul><br /> <br /> =Asynchronous and Independent daemons=<br /> <br /> As of Sirius Mods version 7.0, there are two new daemon methods: RunAsynchronously and RunIndependently:<br /> <br /> %pantalaimon is object daemon<br /> ...<br /> %pantalaimon = new<br /> ...<br /> %pantalaimon:runAsynchronously(%commands)<br /> ...<br /> %pantalaimon:runIndependently(%commands)<br /> <br /> As the names suggest, both of these methods return immediately, before the daemon has completed processing its input commands. With RunAsynchronously, when the daemon commands are all processed, the daemon goes back to waiting for the master to tell it what to do next. To do this, the master thread has to make sure the daemon thread has completed processing by issuing the WaitAsynchronous method (new in Sirius Mods 7.0) against the Daemon object:<br /> <br /> %pantalaimon is object daemon<br /> ...<br /> %pantalaimon:runAsynchronously(%commands)<br /> ...<br /> %pantalaimon:waitAsynchronous<br /> <br /> Even if a daemon thread running asynchronously has completed processing its commands, a WaitAsynchronous method must be issued against the Daemon object before further commands can be sent to the daemon. Most methods applied to a Daemon object that is running asynchronously result in request cancellation. Once the daemon that had been running asynchronously has been resynched with the master thread via WaitAsynchronous, the master thread can treat it just as any other daemon thread and issue further Open, Run, RunAsynchronous, RunIndependently, or other methods against the daemon.<br /> <br /> With RunIndependently, the daemon logs off when the daemon commands are all processed. This means that a daemon thread for which RunIndependently is issued can no longer be controlled by its master thread (as the method name would suggest). In fact, upon return from the RunIndependently method, the Daemon object is set to null, so any further methods invoked against it would result in request cancellation. RunIndependently is roughly analogous to the $commbg function with some important differences:<br /> <br /> <ul><br /> <li>The RunIndependently method allows interaction with the daemon before it does its independent processing.<br /> <li>RunIndependently operates on a Daemon object that already has a daemon thread associated with it. $commbg obtains a daemon thread as part of its processing and,<br /> <li>if one is not available or the maximum independent/background daemons are already running, the request is enqueued.<br /> </ul><br /> <br /> That RunIndependently already has a thread has positive and negative aspects: If the master thread wants to be sure that the daemon thread is actually running, RunIndependently has the preferred behavior. If the master thread doesn't care whether the request runs immediately (and in fact, would prefer that the request be run later if/when it is convenient), then $commbg's behavior is preferable. Note, however, that there is no guarantee that a request enqueued by $commbg will ever be run — it is quite possible that the request remains enqueued until the ONLINE is brought down.<br /> <br /> Despite their similarities, $commbg and RunIndependently use different terminology for the daemon threads. $commbg refers to the threads running “in the background,” while RunIndependently refers to them running “independently.” As alluded to above, there is a limit to the number of background or independent requests that may be running at a time. When this limit is exceeded for $commbg requests (or when there are simply no daemon threads available to run the requests), the requests are enqueued, until a daemon thread is available to run the request and the limit for background/independent requests would not be exceeded. RunIndependently, on the other hand, causes a request cancellation if the limit for background/independent requests is to be exceeded. RunIndependently cannot fail, because there are no daemon threads available since the daemon thread is assigned to the object at the time it is instantiated (with the New method), so RunIndependently does not have to allocate a daemon thread for the request.<br /> <br /> Before Sirius Mods 7.0, the limit for background/independent requests was one-half of, or ten fewer than, the number of daemon threads, whichever was greater. That is, if there were 10 daemon threads defined in an ONLINE, no more than 5 of them could be running $commbg requests. If there were 40 daemon threads defined, no more than 30 could be running $commbg requests. Under Sirius Mods 7.0 and later, the system parameter MAXBG indicates the maximum number of simultaneously running background/independent requests that are allowed at a time. For backward compatibility with previous Sirius Mods versions, the default value for MAXBG is one-half of, or ten fewer than, the number of daemon threads defined to the ONLINE, whichever is greater.<br /> <br /> Daemon threads running asynchronously, as well as threads that are about to run independently (but aren't yet), are counted against the master thread's MAXDAEM limit. When a thread switches to running independently, it is no longer counted against the master's MAXDAEM limit.<br /> <br /> RunAsynchronously can be used to allow a thread to do parts of large, complex tasks in parallel. The master thread could be doing some of the work at the same time a daemon thread is asynchronously doing some of it. In fact, multiple daemon threads can be running asynchronously at the same time for a given master thread. When the master thread is done with its work, it can then do a WaitAsynchronous for each daemon running asynchronously until all the work is completed.<br /> <br /> If the work being run in parallel is very CPU intensive, there is not likely to be any benefit in running work asynchronously unless the ONLINE is using multiple tasks (MP/204 authorized and AMPSUBS > 0). On the other hand, if the work being performed asynchronously is I/O intensive, a significant reduction in the time required to perform the work can be achieved compared to doing all the I/O serially in the master thread. Work involving network delays is an ideal candidate for running asynchronously, especially if multiple such delays are present in a batch of work.<br /> <br /> ==References==<br /> <br /> See the [[:Category:Daemon methods]] page for detailed Daemon use information<br /> <br /> [[Category:System classes]]</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=User:JAL3/monobook.css&diff=42792 User:JAL3/monobook.css 2011-03-25T02:53:06Z

<p>JAL3: </p> <hr /> <div>var {<br /> font-style: normal;<br /> font-family: "Times New Roman", Times, serif;<br /> font-size: 1.1em;<br /> color: #601010;<br /> }<br /> <br /> var.term {<br /> text-transform: none;<br /> font-style: italic;<br /> font-family: sans-serif;<br /> font-size: 1.0em;<br /> color: #000;<br /> }<br /> <br /> var.product {<br /> color: black;<br /> font-family: sans-serif;<br /> font-style: italic;<br /> font-size: 1.0em;<br /> }<br /> <br /> p.syntax {<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-size: 13.97px;<br /> line-height: 15.37px;<br /> }<br /> <br /> <br /> p.code, p.output {<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-size: 13.33px;<br /> line-height: 14.67px;<br /> }<br /> <br /> <br /> p.syntax span.literal {<br /> font-style: normal;<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax span.term {<br /> font-style: italic;<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> <br /> p.syntax2 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Courier New", Courier, monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax2 span.literal {<br /> font-style: normal;<br /> font-family: "Courier New", Courier, monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax2 span.term {<br /> font-style: italic;<br /> font-family: "Courier New", Courier, monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> p.syntax3 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax3 span.literal {<br /> font-style: normal;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax3 span.term {<br /> font-style: italic;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> color: #000;<br /> }<br /> <br /> p.syntax4 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Lucida Console", monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax4 span.literal {<br /> font-style: normal;<br /> font-family: "Lucida Console", monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax4 span.term {<br /> font-style: italic;<br /> font-family: "Lucida Console", monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> .syntaxTable th {<br /> font-style: italic;<br /> }<br /> <br /> .syntaxTable th var {<br /> font-style: normal;<br /> font-family: sans-serif;<br /> }<br /> <br /> code {<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-size: 1.05em;</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=User:JAL3/monobook.css&diff=42791 User:JAL3/monobook.css 2011-03-25T02:50:30Z

<p>JAL3: </p> <hr /> <div>var {<br /> font-style: normal;<br /> font-family: "Times New Roman", Times, serif;<br /> font-size: 1.1em;<br /> color: #601010;<br /> }<br /> <br /> var.term {<br /> text-transform: none;<br /> font-style: italic;<br /> font-family: sans-serif;<br /> font-size: 1.0em;<br /> color: #000;<br /> }<br /> <br /> var.product {<br /> color: black;<br /> font-family: sans-serif;<br /> font-style: italic;<br /> font-size: 1.0em;<br /> }<br /> <br /> p.syntax {<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-size: 13.97px;<br /> line-height: 15.37px;<br /> }<br /> <br /> <br /> p.code {<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-size: 13.33px;<br /> line-height: 14.67px;<br /> }<br /> <br /> <br /> p.syntax span.literal {<br /> font-style: normal;<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax span.term {<br /> font-style: italic;<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> <br /> p.syntax2 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Courier New", Courier, monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax2 span.literal {<br /> font-style: normal;<br /> font-family: "Courier New", Courier, monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax2 span.term {<br /> font-style: italic;<br /> font-family: "Courier New", Courier, monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> p.syntax3 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax3 span.literal {<br /> font-style: normal;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax3 span.term {<br /> font-style: italic;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> color: #000;<br /> }<br /> <br /> p.syntax4 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Lucida Console", monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax4 span.literal {<br /> font-style: normal;<br /> font-family: "Lucida Console", monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax4 span.term {<br /> font-style: italic;<br /> font-family: "Lucida Console", monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> .syntaxTable th {<br /> font-style: italic;<br /> }<br /> <br /> .syntaxTable th var {<br /> font-style: normal;<br /> font-family: sans-serif;<br /> }<br /> <br /> code {<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-size: 1.05em;</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=System_and_Subsystem_classes&diff=13964 System and Subsystem classes 2011-03-24T23:06:33Z

<p>JAL3: /* Lists of System and Subsystem methods */</p> <hr /> <div><br />  <br /> The System and Subsystem classes are collections of shared methods that<br /> operate on entities (globals, strings, objects) made<br /> available to all users in an Online system or all users in a subsystem,<br /> or that operate on environmental entities such as the current INCLUDE<br /> arguments, or the current call stack that are essentially part of the<br /> &ldquo;system.&rdquo;<br /> <br /> There are no System or Subsystem objects, per se.<br /> That is, you cannot instantiate an instance of a System or Subsystem object,<br /> nor assign references from one variable to another, nor are there any<br /> instance-specific methods in these classes.<br /> You can, however, declare objects of these classes.<br /> The main use of such objects is to provide a short-hand way of referencing<br /> the classes:<br /> <pre style="xmp"><br /> %sys is object system<br /> %subsys is object subsystem<br /> ...<br /> %sys:setGlobal('GOOSE', 'SAUCE')<br /> %subsys:setGlobal('GANDER', 'SAUCE')<br /> </pre><br /> <br /> Even though you cannot instantiate or invoke instance-specific<br /> methods against System or Subsystem objects, you may find it<br /> helpful to think of there being an implicit System object<br /> that contains system-wide and thread-specific context for the system,<br /> and a SubSystem object for every valid subsystem context.<br /> Still, all System and Subsystem class methods are shared methods,<br /> so they are invokable via their class names:<br /> <pre style="xmp"><br /> %(system):setString('STATUS', %status)<br /> print %(subsystem):string('INFO')<br /> </pre><br /> ==Subsystem context==<br /> Subsystem class methods operate on entities associated with the current<br /> subsystem context.<br /> This context is, by default, the current subsystem in which a request<br /> is running.<br /> It is, possible, however, to run with a subsystem context different from<br /> the current subsystem.<br /> This subsystem context can be a subsystem other than the one being run,<br /> or it can even be a context that isn't associated with a real subsystem &mdash;<br /> the context is simply a name, and it is not required to be a started or<br /> even defined subsystem.<br /> It is also possible to set a subsystem context for requests that are not even<br /> inside a subsystem.<br /> <br /> When a subsystem is entered, the subsystem context is automatically set to<br /> the name of the one being entered.<br /> When the subsystem is exited, the context is set back to the subsystem<br /> context in effect at entry to the subsystem, whether or not the subsystem was<br /> changed inside the subsystem.<br /> <br /> Once the subsystem context is set, all Subsystem class methods apply to<br /> that subsystem context.<br /> For example, if subsystem ORDER is entered, the following statement<br /> sets a subsystem string for that subsystem:<br /> <pre style="xmp"><br /> %(subsystem):setString('DEBUG', 'ON')<br /> </pre><br /> However, if the following statement is run before it,<br /> the SetString method actually applies to the DISORDER subsystem context:<br /> <pre style="xmp"><br /> %(subsystem):context = 'DISORDER'<br /> </pre><br /> <br /> Since setting the subsystem context allows a request to modify entities<br /> associated with another subsystem, the ability to set subsystem context<br /> is protected.<br /> Ordinarily, only a system manager can set the subsystem context, though<br /> the ability to set subsystem context can be controlled with SIRMETH<br /> rules.<br /> ==Using SIRMETH to specify security rules==<br /> The ability to modify system or subsystem entities gives a user the<br /> ability to cause problems in threads other than their own.<br /> As such, this capability must be protected to prevent malicious or<br /> unintentional modification of system-wide or subsystem-wide<br /> entities.<br /> <br /> The default protection for system-wide and subsystem-wide entities<br /> is:<br /> <ul><br /> <li>Only system managers can modify system-wide entities (system globals<br /> and strings, for example).<br /> <li>Only pre-compiled procedures in a subsystem can modify subsystem-wide<br /> entities.<br /> <li>Only system managers can set their subsystem context.<br /> </ul><br /> <br /> While these rules prevent intentional or unintentional tampering<br /> with system or subsystem entities, they can also be onerous:<br /> <ul><br /> <li>There might be several trusted subsystems that one would want to<br /> allow to set System globals.<br /> <li>One might want to set SubSystem globals in non-precompiled procedures.<br /> <li>One might want several subsystems to operate under the same subsystem<br /> context, that is, share subsystem entities.<br /> <li>For development and debugging, one might want very loose restrictions<br /> on what programmers can and cannot do.<br /> </ul><br /> While most of these problems can be worked around by giving programmers system<br /> manager privileges or by having subsystems run with system manager privileges,<br /> this might be further than one wants to go to provide these capabilities.<br /> <br /> To ameliorate these problems, the SIRMETH command is provided.<br /> The SIRMETH command provides a way of giving specific subsystems or all<br /> users access to certain System or Subsystem class capabilities.<br /> Of course, the SIRMETH command itself requires system manager privileges.<br /> ===SIRMETH command syntax===<br /> SIRMETH {ALLOW | DISALLOW} -<br /> {SYSTEMSET | SUBSYSTEMSET | -<br /> SUBSYSTEMCONTEXT csubsys | ALL} -<br /> [SUBSYSTEM subsys [NONPRE] ]<br /> Where:<br /> <dl><br /> <dt>ALLOW<br /> <dd>Indicates that requests matching the rule will be allowed to perform<br /> the indicated action.<br /> <dt>DISALLOW<br /> <dd>Indicates that requests matching the rule will not be allowed to perform<br /> the indicated action.<br /> <dt>SYSTEMSET<br /> <dd>Indicates the ability to set system strings or globals.<br /> This applies to the SetGlobal and SetString methods in the System<br /> class, as well as the $setg_sys function.<br /> <dt>SUBSYSTEMSET<br /> <dd>Indicates the ability to set subsytem strings or globals.<br /> This applies to the SetGlobal and SetString methods in the SubSystem<br /> class, as well as the $setg_subsys function (when the third argument,<br /> the subsystem name, is not specified).<br /> <dt>SUBSYSTEMCONTEXT<br /> <dd>Indicates the ability to change subsytem context to the subsystem<br /> indicated by ''csubsys''.<br /> ''csubsys'' can be a specific subsystem name such as SIRPRO,<br /> or it can be a wild-card such as SIR* or ???PRO.<br /> <dt>ALL<br /> <dd>Only allowed on a DISALLOW rule, this indicates that no extra<br /> capabilities are to be provided to requests matching the rule.<br /> <dt>SUBSYSTEM<br /> <dd>Indicates that the action is to be allowed to methods in the subsystem<br /> indicated by ''subsys''.<br /> ''subsys'' can be a specific subsystem name such as INVENTORY, or it<br /> can be a wild-card such as INV* or INVENTO?Y.<br /> <br /> Note that if SUBSYSTEM is specified, the rule applies to the real subsystem<br /> being run, regardless of the current subsystem context.<br /> Note also that unless followed by the keyword NONPRE, the rule only applies<br /> to pre-compiled procedures in the subsystem.<br /> <dt>NONPRE<br /> <dd>Indicates that non-pre-compiled<br /> procedures in the subsystem are also to be given the capabilities indicated by<br /> the SIRMETH rule.<br /> NONPRE must immediately follow the subsystem name.<br /> </dl><br /> <br /> You can specify as many SIRMETH rules as you want.<br /> A SIRMETH rule that<br /> totally encompasses a previous rule preempts that rule.<br /> For example, in the following two rules,<br /> the second SIRMETH rule completely encompasses the first, so the first<br /> rule is discarded:<br /> <pre style="xmp"><br /> SIRMETH ALLOW SUBSYSTEMSET SUBSYS FOOBAR<br /> SIRMETH ALLOW SUBSYSTEMSET SUBSYS FOO*<br /> </pre><br /> A SIRMETH DISALLOW ALL preempts all previous rules,<br /> so it is a way of starting from a clean slate.<br /> If you place a SIRMETH DISALLOW ALL at the start of a<br /> sequence of SIRMETH rules (most likely in a procedure), those rules<br /> can be run again and again, perhaps after some of the rules have been<br /> modified.<br /> Of course, in the interval between the SIRMETH DISALLOW ALL and the<br /> subsequent rules, some ordinarily legal requests might be disallowed,<br /> so it is probably not a good idea to reapply SIRMETH rules in<br /> a production region.<br /> <br /> Generally, SIRMETH rules are placed in the CCAIN stream or in<br /> a procedure INCLUDE'd in the CCAIN stream.<br /> <br /> The reason for the NONPRE keyword is that many debugging and development<br /> subsystems allow users (programmers, typically) to run arbitrary code<br /> from inside the subsystem.<br /> Typically, this arbitrary code is run from a non-pre-compiled<br /> procedure that includes the programmer's code.<br /> To prevent such code from picking up the subsystem's capabilities,<br /> System and Subsystem class security does not apply SIRMETH rules<br /> to non-pre-compiled procedures, unless the NONPRE keyword is specified<br /> on the rule.<br /> Since most subsystems don't allow users to run arbitrary code inside<br /> them, and since it is quite likely that you might want to set<br /> subsystem globals or switch subsystem contexts inside a non-pre-compiled<br /> procedure, it is probably a good idea to specify NONPRE for those<br /> subsystems.<br /> <br /> In a development environment,<br /> to avoid the effort of modifying multiple individual SIRMETH rules,<br /> you may be willing to risk letting<br /> programmers modify any system or subsystem entity.<br /> If so, the following rules allow everyone<br /> to do everything with system and subsystem entities:<br /> <pre style="xmp"><br /> SIRMETH ALLOW SUBSYSTEMSET<br /> SIRMETH ALLOW SUBSYSTEMSET<br /> SIRMETH ALLOW SUBSYSTEMCONTEXT<br /> </pre><br /> <br /> It is worth reiterating that while the System and Subsystem classes are<br /> the preferred interface for setting system and subsystem globals,<br /> the SIRMETH rules also apply to $setg_sys and $setg_subsys.<br /> If the third parameter of $setg_subsys (subsystem name) is specified,<br /> no SIRMETH rules apply, and the user must be a system manager.<br /> You can get the same effect as a $setg_subsys with a subsystem<br /> name by saving the subsystem context, setting it, and then restoring it:<br /> <pre style="xmp"><br /> %oldContext = %(subsystem):context<br /> %(subsystem):context = 'CUSTOMER'<br /> %(subsystem):setGlobal('CUSTFILE', 'GROUP CUST2004')<br /> %(subsystem):context = %oldContext<br /> </pre><br /> ==System and subsystem globals and strings==<br /> Typically, a $getg function or a dummy string compile-time string<br /> (that is, something that begins with <tt>?&</tt>) is resolved from a thread-level<br /> global variable (that is, a variable set via $setg).<br /> Often, however, all requests in an Online or subsystem will use the<br /> same value for some of these globals, so it seems appealing for these<br /> users to share a copy of those globals rather than each wasting GTBL<br /> space to hold a copy for each thread.<br /> System and subsystem globals make this feasible.<br /> <br /> By default, if a global reference (either a $getg or a dummy string)<br /> cannot be resolved with thread-level globals, subsystem and then system<br /> globals will be searched.<br /> If one of these matches the requested global, that global will be<br /> returned for the $getg or the dummy string.<br /> <br /> For example, if the following statement exists in a subsystem initialization<br /> procedure:<br /> <pre style="xmp"><br /> %(subsystem):setGlobal('INVFILE', 'PERM GROUP INV2004')<br /> </pre><br /> the following line<br /> <pre style="xmp"><br /> %inventoryRecords is object recordSet in ?&INVFILE<br /> </pre><br /> is resolved as<br /> <pre style="xmp"><br /> %inventoryRecords is object recordSet in PERM GROUP INV2004<br /> </pre><br /> <br /> $SIRPARM has settings to indicate that $get or dummy string lookup<br /> should use subsystem or system globals ahead of thread-specific globals.<br /> For example, the following statement<br /> indicates that subsystem or system globals are to be used ahead of thread-specific<br /> globals for dummy strings:<br /> <pre style="xmp"><br /> %rc = $sirparm('DUMMYSYS', 1)<br /> </pre><br /> And the following call indicates that subsystem or system globals are to be used<br /> ahead of thread-specific globals for $getg calls:<br /> <pre style="xmp"><br /> %rc = $sirparm('GETGSYS', 1)<br /> </pre><br /> <br /> Note that system and subsystem globals are different from system and<br /> subsystem strings.<br /> The latter are never returned for $getg or dummy string requests,<br /> and they can only be retrieved via the [[String (System/Subsystem function)|String]]<br /> function.<br /> Also, system and subsystem global values can never be longer than 255 bytes,<br /> whereas<br /> system and subsystem strings are longstrings, which can be up to 2**31-1 bytes<br /> long.<br /> ==System-wide objects==<br /> ''Sirius Mods'' version 6.7 adds methods to the Janus System and Subsystem classes<br /> that make designated objects available to all users in an Online or of a subsystem.<br /> Such objects, referred to as '''system-wide''' objects, are made available<br /> via deep copy, so only<br /> deep copyable (see [[Copying objects]]) objects are eligible.<br /> <br /> An object becomes system-wide if and only if it is saved by the System class<br /> SetObject method or by the Subsystem class SetObject method.<br /> If by the System class SetObject method, the &ldquo;system&rdquo; in system-wide<br /> refers to all users in the Online; if by the Subsystem SetObject method, all<br /> users in the current or a specified subsystem.<br /> <br /> System-wide objects belong to a namespace that is not the same as<br /> that for System and Subsystem longstrings.<br /> That is, both a System longstring and a system-wide object may be called by the<br /> same name at the same time.<br /> <br /> The methods that work with system-wide objects are one System and one Subsystem<br /> class version of each of the following:<br /> <dl><br /> <dt>SetObject<br /> <dd>Makes an object available system-wide with a<br /> specified name, as described in [[SetObject (System/Subsystem function)|SetObject]].<br /> <dt>GetObject<br /> <dd>Retrieves a copy of the specified system-wide object,<br /> as described in [[GetObject (System/Subsystem function)|GetObject]].<br /> <dt>DeleteObject<br /> <dd>Deletes the specified system-wide object,<br /> as described in [[DeleteObject (System/Subsystem subroutine)|DeleteObject]].<br /> <dt>ListOfObjects<br /> <dd>Returns a Stringlist containing information about system-wide objects,<br /> as described in [[ListOfObjects (System/Subsystem function)|ListOfObjects]].<br /> </dl><br /> ==Lists of System and Subsystem methods==<br /> The individual System methods are summarized in [[List of System methods|"List of System methods"]].<br /> <p></p><br /> The individual Subsystem methods are summarized in [[List of Subsystem methods|"List of Subsystem methods"]].</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=GetObject_(Subsystem_function)&diff=41612 GetObject (Subsystem function) 2011-03-24T22:55:08Z

<p>JAL3: /* Syntax terms */</p> <hr /> <div>{{Template:Subsystem:GetObject subtitle}}<br /> The <var>GetObject</var> shared method retrieves a copy of a specified [[Subsystem_class#System-wide_objects|subsystem-wide]] object.<br /> <br /> ==Syntax==<br /> {{Template:Subsystem:GetObject syntax}}<br /> ===Syntax terms===<br /> <table class="syntaxTable"><br /> <tr><th>%number</th><td>The generation number associated with name. This is a positive integer (initially set to 1) that increases by one each time the name object is updated. gen is set to 0 if the method encounters a problem and cannot retrieve the object.</td></tr><br /> <tr><th>%(Subsystem)</th><br /> <td>The class name in parentheses denotes a shared method. <var>GetObject</var> can also be invoked via a <var>Subsystem</var> object variable, which may be <var>Null</var>.</td></tr><br /> <tr><th>string</th><br /> <td>The string name by which the subsystem-wide object is identified.</td></tr><br /> <tr><th>object</th><br /> <td>The object variable to which the subsystem-wide object is assigned.</td></tr><br /> </table><br /> <br /> ==See also==<br /> {{Template:Subsystem:GetObject footer}}</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=GetObject_(Subsystem_function)&diff=41611 GetObject (Subsystem function) 2011-03-24T22:52:22Z

<p>JAL3: </p> <hr /> <div>{{Template:Subsystem:GetObject subtitle}}<br /> The <var>GetObject</var> shared method retrieves a copy of a specified [[Subsystem_class#System-wide_objects|subsystem-wide]] object.<br /> <br /> ==Syntax==<br /> {{Template:Subsystem:GetObject syntax}}<br /> ===Syntax terms===<br /> <table class="syntaxTable"><br /> <tr><th>%number</th><td>The generation number associated with name. This is a positive integer (initially set to 1) that increases by one each time the name object is updated. gen is set to 0 if the method encounters a problem and cannot retrieve the object.</td></tr><br /> <tr><th>%(Subsystem)</th><br /> <td>The class name in parentheses denotes a shared method. <var>GetObject</var> can also be invoked via a <var>[[Subsystem_class|Subsystem]]</var> object variable, which may be <var>Null</var>.</td></tr><br /> <tr><th>string</th><br /> <td>The string name by which the subsystem-wide object is identified.</td></tr><br /> <tr><th>object</th><br /> <td>The object variable to which the subsystem-wide object is assigned.</td></tr><br /> </table><br /> <br /> <br /> ==See also==<br /> {{Template:Subsystem:GetObject footer}}</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=GetObject_(Subsystem_function)&diff=41610 GetObject (Subsystem function) 2011-03-24T22:50:37Z

<p>JAL3: </p> <hr /> <div>{{Template:Subsystem:GetObject subtitle}}<br /> The <var>GetObject</var> shared method retrieves a copy of a specified [[Subsystem_class#System-wide_objects|subsystem-wide]] object.<br /> <br /> ==Syntax==<br /> {{Template:Subsystem:GetObject syntax}}<br /> ===Syntax terms===<br /> <table class="syntaxTable"><br /> <tr><th>%number</th><td>The generation number associated with name. This is a positive integer (initially set to 1) that increases by one each time the name object is updated. gen is set to 0 if the method encounters a problem and cannot retrieve the object.</td></tr><br /> <tr><th>%(Subsystem)</th><br /> <td>The class name in parentheses denotes a shared method. <var>GetObject</var> can also be invoked via a <var>[[Subsystem_class|Subsystem]]</var> class object variable, which may be <var>Null</var>.</td></tr><br /> <tr><th>string</th><br /> <td>The string name by which the subsystem-wide object is identified.</td></tr><br /> <tr><th>object</th><br /> <td>The object variable to which the subsystem-wide object is assigned.</td></tr><br /> </table><br /> <br /> <br /> ==See also==<br /> {{Template:Subsystem:GetObject footer}}</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=User:JAL3/monobook.css&diff=42790 User:JAL3/monobook.css 2011-03-24T22:48:42Z

<p>JAL3: </p> <hr /> <div>var {<br /> font-style: normal;<br /> font-family: "Times New Roman", Times, serif;<br /> font-size: 1.1em;<br /> color: #601010;<br /> }<br /> <br /> var.term {<br /> text-transform: none;<br /> font-style: italic;<br /> font-family: sans-serif;<br /> font-size: 1.0em;<br /> color: #000;<br /> }<br /> <br /> var.product {<br /> color: black;<br /> font-family: sans-serif;<br /> font-style: italic;<br /> font-size: 1.0em;<br /> }<br /> <br /> p.syntax {<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-size: 13.97px;<br /> line-height: 15.37px;<br /> }<br /> <br /> <br /> p.code {<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-size: 13.33px;<br /> line-height: 14.67px;<br /> }<br /> <br /> <br /> p.syntax span.literal {<br /> font-style: normal;<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax span.term {<br /> font-style: italic;<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> <br /> p.syntax2 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Courier New", Courier, monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax2 span.literal {<br /> font-style: normal;<br /> font-family: "Courier New", Courier, monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax2 span.term {<br /> font-style: italic;<br /> font-family: "Courier New", Courier, monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> p.syntax3 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax3 span.literal {<br /> font-style: normal;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax3 span.term {<br /> font-style: italic;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> color: #000;<br /> }<br /> <br /> p.syntax4 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Lucida Console", monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax4 span.literal {<br /> font-style: normal;<br /> font-family: "Lucida Console", monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax4 span.term {<br /> font-style: italic;<br /> font-family: "Lucida Console", monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> <br /> <br /> <br /> p.code {<br /> font-family: Consolas, "Courier New", Courier, monospace;<br /> }<br /> <br /> .syntaxTable th {<br /> font-style: italic;<br /> }<br /> <br /> .syntaxTable th var {<br /> font-style: normal;<br /> font-family: sans-serif;<br /> }</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=GetObject_(Subsystem_function)&diff=41609 GetObject (Subsystem function) 2011-03-24T21:37:37Z

<p>JAL3: </p> <hr /> <div>{{Template:Subsystem:GetObject subtitle}}<br /> The <var>GetObject</var> shared method retrieves a copy of a specified <var>[[Subsystem_class#System-wide_objects|subsystem-wide]]</var> object.<br /> <br /> ==Syntax==<br /> {{Template:Subsystem:GetObject syntax}}<br /> ===Syntax terms===<br /> <table class="syntaxTable"><br /> <tr><th>%number</th><td>The generation number associated with name. This is a positive integer (initially set to 1) that increases by one each time the name object is updated. gen is set to 0 if the method encounters a problem and cannot retrieve the object.</td></tr><br /> <tr><th>%(Subsystem)</th><br /> <td>The class name in parentheses denotes a shared method. <var>GetObject</var> can also be invoked via a <var>[[Subsystem_class|Subsystem]]</var> class object variable, which may be <var>Null</var>.</td></tr><br /> <tr><th>string</th><br /> <td>The string name by which the subsystem-wide object is identified.</td></tr><br /> <tr><th>object</th><br /> <td>The object variable to which the subsystem-wide object is assigned.</td></tr><br /> </table><br /> <br /> <br /> ==See also==<br /> {{Template:Subsystem:GetObject footer}}</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=GetObject_(Subsystem_function)&diff=41608 GetObject (Subsystem function) 2011-03-24T21:37:11Z

<p>JAL3: </p> <hr /> <div>{{Template:Subsystem:GetObject subtitle}}<br /> The <var>GetObject</var>shared method retrieves a copy of a specified <var>[[Subsystem_class#System-wide_objects|subsystem-wide]]</var> object.<br /> <br /> ==Syntax==<br /> {{Template:Subsystem:GetObject syntax}}<br /> ===Syntax terms===<br /> <table class="syntaxTable"><br /> <tr><th>%number</th><td>The generation number associated with name. This is a positive integer (initially set to 1) that increases by one each time the name object is updated. gen is set to 0 if the method encounters a problem and cannot retrieve the object.</td></tr><br /> <tr><th>%(Subsystem)</th><br /> <td>The class name in parentheses denotes a shared method. <var>GetObject</var> can also be invoked via a <var>[[Subsystem_class|Subsystem]]</var> class object variable, which may be <var>Null</var>.</td></tr><br /> <tr><th>string</th><br /> <td>The string name by which the subsystem-wide object is identified.</td></tr><br /> <tr><th>object</th><br /> <td>The object variable to which the subsystem-wide object is assigned.</td></tr><br /> </table><br /> <br /> <br /> ==See also==<br /> {{Template:Subsystem:GetObject footer}}</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=GetObject_(System_function)&diff=41330 GetObject (System function) 2011-03-24T21:27:17Z

<p>JAL3: /* Syntax terms */</p> <hr /> <div>{{Template:System:GetObject subtitle}}<br /> The <var>GetObject</var> shared method retrieves a copy of a specified <var>[[System_class#System-wide_objects|system-wide]]</var> object.<br /> <br /> ==Syntax==<br /> {{Template:System:GetObject syntax}}<br /> ===Syntax terms===<br /> <table class="syntaxTable"><br /> <tr><th>%number</th><td>The generation number associated with name. This is a positive integer (initially set to 1) that increases by one each time the name object is updated. gen is set to 0 if the method encounters a problem and cannot retrieve the object.</td></tr><br /> <tr><th>%(System)</th><br /> <td>The class name in parentheses denotes a shared method. <var>GetObject</var> can also be invoked via a <var>System</var> class object variable, which may be <var>Null</var>.</td></tr><br /> <tr><th>string</th><br /> <td>The string name by which the system-wide object is identified.</td></tr><br /> <tr><th>object</th><br /> <td>The object variable to which the system-wide object is assigned.</td></tr><br /> </table><br /> <br /> ==See also==<br /> {{Template:System:GetObject footer}}</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=GetObject_(System_function)&diff=41329 GetObject (System function) 2011-03-24T21:25:26Z

<p>JAL3: </p> <hr /> <div>{{Template:System:GetObject subtitle}}<br /> The <var>GetObject</var> shared method retrieves a copy of a specified <var>[[System_class#System-wide_objects|system-wide]]</var> object.<br /> <br /> ==Syntax==<br /> {{Template:System:GetObject syntax}}<br /> ===Syntax terms===<br /> <table class="syntaxTable"><br /> <tr><th>%number</th><td>The generation number associated with name. This is a positive integer (initially set to 1) that increases by one each time the name object is updated. gen is set to 0 if the method encounters a problem and cannot retrieve the object.</td></tr><br /> <tr><th>%(System)</th><br /> <td>The class name in parentheses denotes a shared method. <var>GetObject</var> can also be invoked via a <var>[[System_class|System]]</var> class object variable, which may be <var>Null</var>.</td></tr><br /> <tr><th>string</th><br /> <td>The string name by which the system-wide object is identified.</td></tr><br /> <tr><th>object</th><br /> <td>The object variable to which the system-wide object is assigned.</td></tr><br /> </table><br /> <br /> <br /> ==See also==<br /> {{Template:System:GetObject footer}}</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=User:JAL3/monobook.css&diff=42789 User:JAL3/monobook.css 2011-03-24T00:45:42Z

<p>JAL3: </p> <hr /> <div>var {<br /> font-style: normal;<br /> text-transform: none;<br /> font-family: "Times New Roman", Times, serif;<br /> font-size: 1.1em;<br /> color: #601010;<br /> }<br /> <br /> var.term {<br /> text-transform: none;<br /> font-style: italic;<br /> font-family: sans-serif;<br /> font-size: 1.0em;<br /> color: #000;<br /> }<br /> <br /> var.product {<br /> color: black;<br /> font-family: sans-serif;<br /> font-style: italic;<br /> font-size: 1.0em;<br /> }<br /> <br /> p.syntax {<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-size: 13.97px;<br /> line-height: 15.37px;<br /> }<br /> <br /> <br /> p.code {<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-size: 13.33px;<br /> line-height: 14.67px;<br /> }<br /> <br /> <br /> p.syntax span.literal {<br /> font-style: normal;<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax span.term {<br /> font-style: italic;<br /> font-family: "Consolas", "Courier New", Courier, monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> <br /> p.syntax2 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Courier New", Courier, monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax2 span.literal {<br /> font-style: normal;<br /> font-family: "Courier New", Courier, monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax2 span.term {<br /> font-style: italic;<br /> font-family: "Courier New", Courier, monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> p.syntax3 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax3 span.literal {<br /> font-style: normal;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax3 span.term {<br /> font-style: italic;<br /> font-family: "Lucida Sans Typewriter", monospace;<br /> color: #000;<br /> }<br /> <br /> p.syntax4 {<br /> color: #000;<br /> background-color: #f9f9f9;<br /> padding: 5px 5px 5px 10px;<br /> border: 1px dashed #4169E1;<br /> font-family: "Lucida Console", monospace;<br /> font-size: 12.7px;<br /> line-height: 13.97px;<br /> vertical-align: baseline;<br /> white-space: pre; <br /> }<br /> <br /> p.syntax4 span.literal {<br /> font-style: normal;<br /> font-family: "Lucida Console", monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> p.syntax4 span.term {<br /> font-style: italic;<br /> font-family: "Lucida Console", monospace;<br /> color: #000;<br /> }<br /> <br /> <br /> <br /> <br /> <br /> p.code {<br /> font-family: Consolas, "Courier New", Courier, monospace;<br /> }<br /> <br /> .syntaxTable th {<br /> font-style: italic;<br /> }<br /> <br /> .syntaxTable th var {<br /> font-style: normal;<br /> font-family: sans-serif;<br /> }</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=User:JAL3/monobook.css&diff=42788 User:JAL3/monobook.css 2011-03-21T19:24:07Z

<p>JAL3: </p> <hr /> <div>var {<br /> font-style: normal;<br /> text-transform: none;<br /> }<br /> <br /> var.term {<br /> text-transform: none;<br /> font-style: italic;<br /> }<br /> <br /> var.product {<br /> color: black;<br /> font-style: italic;<br /> }<br /> <br /> span.literal {<br /> font-style: normal;<br /> font-family: Consolas, "Courier New", monospace;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> span.term {<br /> font-style: italic;<br /> font-family: Consolas, "Courier New", monospace;<br /> color: #000;<br /> }<br /> <br /> p.syntax {<br /> font-family: Consolas, "Courier New", monospace;<br /> }<br /> <br /> p.code {<br /> font-family: Consolas, "Courier New", monospace;<br /> }<br /> <br /> .syntaxTable th {<br /> font-style: italic;<br /> }</div>

JAL3 https://m204wiki.rocketsoftware.com/index.php?title=User:JAL3/monobook.css&diff=42787 User:JAL3/monobook.css 2011-03-18T21:43:21Z

<p>JAL3: Created page with "var { font-style: normal; text-transform: none; } var.term { text-transform: none; font-style: italic; } var.product { color: black; font-style: italic;..."</p> <hr /> <div>var {<br /> font-style: normal;<br /> text-transform: none;<br /> }<br /> <br /> var.term {<br /> text-transform: none;<br /> font-style: italic;<br /> }<br /> <br /> var.product {<br /> color: black;<br /> font-style: italic;<br /> }<br /> <br /> span.literal {<br /> font-style: normal;<br /> font-family: Consolas, "Courier New", monospace;<br /> font-size: 1.0em;<br /> font-weight: normal;<br /> color: #601010;<br /> }<br /> <br /> span.term {<br /> font-style: italic;<br /> font-family: Consolas, "Courier New", monospace;<br /> font-size: 1.0em;<br /> color: #000;<br /> }<br /> <br /> p.syntax {<br /> font-family: Consolas, "Courier New", monospace;<br /> }<br /> <br /> p.code {<br /> font-family: Consolas, "Courier New", monospace;<br /> }<br /> <br /> .syntaxTable th {<br /> font-style: italic;<br /> }</div>

JAL3