YYGQC@CUNYVM.BITNET (03/03/91)
Hi... I'm looking for any information on SVC's, and what they do... All I have info on right now, is the SVC 202, (To send a command to CMS or CP or whatever...) Does anyone out there have a list of what different SVC numbers do? Also, one problem w/ using SVC 202 if you're writing something that say uses words greater than 8 bytes, Something like if you're writing a prg that sends messages to other users, if you have a word that's longer than 8 bytes, the program will chop it up into pieces 8 bytes each. So, a message Like Hellothere would come out as Hellothe re Does anyone know how to transfer something to the system directly, w/o having to split it up into doubleword chunks? Any help appreciated... Thanks...
richg@locus.com (Rich Greenberg) (03/04/91)
In article <91061.170411YYGQC@CUNYVM.BITNET> YYGQC@CUNYVM.BITNET writes: >Hi... I'm looking for any information on SVC's, and what they do... >All I have info on right now, is the SVC 202, (To send a command to >CMS or CP or whatever...) Does anyone out there have a list of what >different SVC numbers do? Also, one problem w/ using SVC 202 if you're >writing something that say uses words greater than 8 bytes, Something like >if you're writing a prg that sends messages to other users, if you have >a word that's longer than 8 bytes, the program will chop it up into pieces >8 bytes each. So, a message Like Hellothere would come out as Hellothe re >Does anyone know how to transfer something to the system directly, w/o >having to split it up into doubleword chunks? Any help appreciated... >Thanks... The function of an SVC is very operating system dependant. I presume that since you mention SVC 202, you want info on CMS SVCs. I am home without my manuals, and I am a bit fuzzy on some of these but I will do the best I can. CMS basically has 3 SVCs 202, 203, & 204. 202 is the old style command interface, 203 is mostly used for CMS services, and is usually the result of a macro expansion. 204 is the new style command interface. The primary difference is that 202 uses some 3 byte address fields, which are a no-no under XA. 204 was introduced in the CMS 5.5 which is part of VM/XA, but has since been retrofilled into non XA CMS for compatibility. As a sop to the great god of compatability, and to allow the OS compilers to run under CMS, a subset of the OS SVCs are also supported. The 8 byte tokenization problem has been with us as long as CMS has. There are two ways to get around it. 1) Use diagnose 8 for CP commands. LA Rx,CMD CMD contains the CP command. LA Ry,L'CMD Length of CP command. DIAG Rx,Ry,8 Diag is a system macro. . . . . CMD DC C'whatever CP command you want' Command itself MUST be in caps * If MSG, text may be mixed case You can also get the CP response back in a buffer in your program. Uses 2 more registers and some flag bits in left byte of Rx. On return, Ry contains the CP return code from the command. (0 = ok) See the "CP for Systems Programming" manual. 2) Use SVC 202/204 with an "untokenized plist". I don't remember the details offhand, but the manual that describes SVC 202 will show you. Try the CMS command ref or CMS for sysprogs. Basically, R0 points to a list of adcons which point to various parts of the command to be issued, and there are some flag bits involved. -- ------------------------------------------------------------------------- Disclaimer: The above writings are the ramblings of one human being and have nothing what-so-ever to do with Locus Computing Corp. ---> Rich Greenberg, richg@locus.com TinsleTown, USA
richg@prodnet.la.locus.COM (Rich Greenberg) (03/04/91)
In article <91061.170411YYGQC@CUNYVM.BITNET> YYGQC@CUNYVM.BITNET writes: >Hi... I'm looking for any information on SVC's, and what they do... >All I have info on right now, is the SVC 202, (To send a command to >CMS or CP or whatever...) Does anyone out there have a list of what >different SVC numbers do? Also, one problem w/ using SVC 202 if you're >writing something that say uses words greater than 8 bytes, Something like >if you're writing a prg that sends messages to other users, if you have >a word that's longer than 8 bytes, the program will chop it up into pieces >8 bytes each. So, a message Like Hellothere would come out as Hellothe re >Does anyone know how to transfer something to the system directly, w/o >having to split it up into doubleword chunks? Any help appreciated... >Thanks... The function of an SVC is very operating system dependant. I presume that since you mention SVC 202, you want info on CMS SVCs. I am home without my manuals, and I am a bit fuzzy on some of these but I will do the best I can. CMS basically has 3 SVCs 202, 203, & 204. 202 is the old style command interface, 203 is mostly used for CMS services, and is usually the result of a macro expansion. 204 is the new style command interface. The primary difference is that 202 uses some 3 byte address fields, which are a no-no under XA. 204 was introduced in the CMS 5.5 which is part of VM/XA, but has since been retrofilled into non XA CMS for compatibility. As a sop to the great god of compatability, and to allow the OS compilers to run under CMS, a subset of the OS SVCs are also supported. The 8 byte tokenization problem has been with us as long as CMS has. There are two ways to get around it. 1) Use diagnose 8 for CP commands. LA Rx,CMD CMD contains the CP command. LA Ry,L'CMD Length of CP command. DIAG Rx,Ry,8 Diag is a system macro. . . . . CMD DC C'whatever CP command you want' Command itself MUST be in caps * If MSG, text may be mixed case You can also get the CP response back in a buffer in your program. Uses 2 more registers and some flag bits in left byte of Rx. On return, Ry contains the CP return code from the command. (0 = ok) See the "CP for Systems Programming" manual. 2) Use SVC 202/204 with an "untokenized plist". I don't remember the details offhand, but the manual that describes SVC 202 will show you. Try the CMS command ref or CMS for sysprogs. Basically, R0 points to a list of adcons which point to various parts of the command to be issued, and there are some flag bits involved. -- ------------------------------------------------------------------------- Disclaimer: The above writings are the ramblings of one human being and have nothing what-so-ever to do with Locus Computing Corp. ---> Rich Greenberg, richg@locus.com TinsleTown, USA