Calling //job from //job in .wsf 
Author Message
 Calling //job from //job in .wsf

Greetings All:

I'm creating a .wsf file with multiple jobs. I want to call other (sub) jobs
from Main job or control job execution sequence dynamically. Is this
possible or should I just write sub routines to accomplish basically the
same thing? Also, do jobs execute in order, first job auto-magically per
docs, until no more jobs or can I stop file execution at end of first (main)
job with WScript.Quit?

I can't seem to get other jobs to execute when called from Main job. I've
tried:

OtherJobId
and
file://job:OtherJob

(ignore 'file:' in above, OE auto-magically inserts)

I'm either syntactically challenged or barking up the wrong tree.

Insights appreciated,

Marcus



Sat, 13 Jul 2002 03:00:00 GMT  
 Calling //job from //job in .wsf

When you define more than one <job> in a wsf file, you can only execute one job at a time.  By default, the 1st job is executed.  To execute any other, use (ignore the _ )

wscript_//job:foobar

to execute <job id="foobar">

When executing any given job, you can't access anything in any of the other <job> elements.  As far as the current job is concerned the other jobs don't exist.  You can use a WScript.Shell object's Run method to execute other jobs using the wscript_//job:jobid syntax above.  But you have limited communication between jobs.  You can pass command line arguments to the 2nd job and it can return a numeric exit code, but that's about it.

To share common code across jobs, you have 2 choices...

1) put the common code in separate .vbs/.js file and "include" them with

<script language="VBScript" src="path\commoncode.vbs" />
<script language="jscript" src="path\commoncode.js" />

where path can be absolute (fully qualified) or relative to the folder containing the .wsf file.

2) convert the common code to public methods of a Windows Script Component (a .wsc  file), register the .wsc file as a component, and "include" it with

set cc = createobject("commoncode.wsc")
or
set cc = getobject("script:fullpath\commoncode.wsc")

assuming you used commoncode.wsc as both filename and the progid when you created the .wsc file.   If you use the getobject method with the "script:" COM moniker, you don't need to register the component (in fact it doesn't even need a <registration> element.

Now subs/functions are called as object methods

result = cc.myfunction(<myarguments>)
cc.mysub arguments <myarguments>

HTH

--
Michael Harris


  Greetings All:

  I'm creating a .wsf file with multiple jobs. I want to call other (sub) jobs
  from Main job or control job execution sequence dynamically. Is this
  possible or should I just write sub routines to accomplish basically the
  same thing? Also, do jobs execute in order, first job auto-magically per
  docs, until no more jobs or can I stop file execution at end of first (main)
  job with WScript.Quit?

  I can't seem to get other jobs to execute when called from Main job. I've
  tried:

  OtherJobId
  and
  file://job:OtherJob

  (ignore 'file:' in above, OE auto-magically inserts)

  I'm either syntactically challenged or barking up the wrong tree.

  Insights appreciated,

  Marcus



Sat, 13 Jul 2002 03:00:00 GMT  
 Calling //job from //job in .wsf
Michael:

Excellent info. I guess I'll stick to sub/function routines :-) I do have a
question on the following:

<snip>
2) convert the common code to public methods of a Windows Script Component
(a .wsc  file), register the .wsc file as a component, and "include" it with

set cc = createobject("commoncode.wsc")
or
set cc = getobject("script:fullpath\commoncode.wsc")

assuming you used commoncode.wsc as both filename and the progid when you
created the .wsc file.
If you use the getobject method with the "script:" COM moniker, you don't
need to register the component (in fact it doesn't even need a
<registration> element.

Now subs/functions are called as object methods

result = cc.myfunction(<myarguments>)
cc.mysub arguments <myarguments>
</snip>

How do you specify progid or does it just happen when you create the .wsc
file?
Not sure I follow the "..don't need to register" approach. I thought you had
to register. Do the docs explain this? So if I had a .wsc file I wouldn't
have to register on all my clients I could just do the following:

result = [relative path | <share>] \cc.myfunction(<myarguments>) ?

I would appreciate furthur info,

Marcus



Sun, 14 Jul 2002 03:00:00 GMT  
 Calling //job from //job in .wsf
Thanks G., your sites been a solid resource for me.

Marcus


Quote:
> Shell the 2nd job using run

> Set oAdr = CreateObject ("WScript.Shell")
> oAdr.Run "WScript.exe file://J:Jobname " & wsf-file

> G. Born

> Check out the WSH Bazaar at:

> http://ourworld.compuserve.com/hompages/Guenter_Born/index0.htm


> >Greetings All:

> >I'm creating a .wsf file with multiple jobs. I want to call other (sub)
> jobs
> >from Main job or control job execution sequence dynamically. Is this
> >possible or should I just write sub routines to accomplish basically the
> >same thing? Also, do jobs execute in order, first job auto-magically per
> >docs, until no more jobs or can I stop file execution at end of first
> (main)
> >job with WScript.Quit?

> >I can't seem to get other jobs to execute when called from Main job. I've
> >tried:

> >OtherJobId
> >and
> >file://job:OtherJob

> >(ignore 'file:' in above, OE auto-magically inserts)

> >I'm either syntactically challenged or barking up the wrong tree.

> >Insights appreciated,

> >Marcus



Sun, 14 Jul 2002 03:00:00 GMT  
 Calling //job from //job in .wsf

Download the "Script Component Wizard" and it handles those details for you...

Windows Script Component Wizard released

--
Michael Harris


  Michael:

  Excellent info. I guess I'll stick to sub/function routines :-) I do have a
  question on the following:

  <snip>
  2) convert the common code to public methods of a Windows Script Component
  (a .wsc  file), register the .wsc file as a component, and "include" it with

  set cc = createobject("commoncode.wsc")
  or
  set cc = getobject("script:fullpath\commoncode.wsc")

  assuming you used commoncode.wsc as both filename and the progid when you
  created the .wsc file.
  If you use the getobject method with the "script:" COM moniker, you don't
  need to register the component (in fact it doesn't even need a
  <registration> element.

  Now subs/functions are called as object methods

  result = cc.myfunction(<myarguments>)
  cc.mysub arguments <myarguments>
  </snip>

  How do you specify progid or does it just happen when you create the .wsc
  file?
  Not sure I follow the "..don't need to register" approach. I thought you had
  to register. Do the docs explain this? So if I had a .wsc file I wouldn't
  have to register on all my clients I could just do the following:

  result = [relative path | <share>] \cc.myfunction(<myarguments>) ?

  I would appreciate furthur info,

  Marcus



Sun, 14 Jul 2002 03:00:00 GMT  
 Calling //job from //job in .wsf

Missed part 2 of the question...

The --> set cc = getobject("script:drive\path\foobar.wsc") <-- syntax is tucked away in the Windows Script Components tutorial.   When creating an instance of a wsc this way, the "component engine" (scrobj.dll) knows exactly where the source for the component is (note that the current (5.1) version of scrobj.dll doesn't support relative paths).  That's why it doesn't need to be registered with a progid or even need a registration element.  But this applies only to creating an instance.  After that you access it normally.

It's a good idea to read the tutorial, because there quite a few things in there that (IMO) should be included in the "reference" section...

Script Component Tutorial
http://msdn.microsoft.com/scripting/scriptlets/doc/lettitle.htm

--
Michael Harris


  Michael:

  Excellent info. I guess I'll stick to sub/function routines :-) I do have a
  question on the following:

  <snip>
  2) convert the common code to public methods of a Windows Script Component
  (a .wsc  file), register the .wsc file as a component, and "include" it with

  set cc = createobject("commoncode.wsc")
  or
  set cc = getobject("script:fullpath\commoncode.wsc")

  assuming you used commoncode.wsc as both filename and the progid when you
  created the .wsc file.
  If you use the getobject method with the "script:" COM moniker, you don't
  need to register the component (in fact it doesn't even need a
  <registration> element.

  Now subs/functions are called as object methods

  result = cc.myfunction(<myarguments>)
  cc.mysub arguments <myarguments>
  </snip>

  How do you specify progid or does it just happen when you create the .wsc
  file?
  Not sure I follow the "..don't need to register" approach. I thought you had
  to register. Do the docs explain this? So if I had a .wsc file I wouldn't
  have to register on all my clients I could just do the following:

  result = [relative path | <share>] \cc.myfunction(<myarguments>) ?

  I would appreciate furthur info,

  Marcus



Sun, 14 Jul 2002 03:00:00 GMT  
 Calling //job from //job in .wsf

Clarence's and Ian's site are probably the best you'll find for general scripting.  

If you're willing to part with about $20, I'd recommend picking up a copy of "VBScript Programmer's Reference" from Wrox Press.  It does an excellent job of introducing nearly all of the scripting "host contexts" where you can use vbscript, including a full chapter on windows script components.

--
Michael Harris


  Already got it. Been reading the documentation and now realize there's more than meets the eye with these scripting technologies. My head's starting to spin! I'm not sure I've been able to sort out when to create a vbs file, a wsf file or a wsc file.

  I've found lots of WSH, VBS/JS resources but few Component resources. Know anybody with a site devoted primarily to Script Components? I've read most the msdn articles but the examples are fairly light, though beneficial.

  It seems like there is quite a bit of overlap amongst the technologies as a wsf or wsc file can contain any supported language so when's it best to use which technique? Do you create stand alone vbs/js files and "src=..." them in a wsf? Create stand-alone vbs/js files that call jobs in a wsf file that has a "src=.." to outside vbs/js files? Create a wsf that instantiates a component? Create a Component with multiple <component> elements that can reference each other? Sheesh, I'm confused. Any recomendations on "best practices"?

  TIA,

  Marcus


    Download the "Script Component Wizard" and it handles those details for you...

    Windows Script Component Wizard released

    --
    Michael Harris



Sun, 14 Jul 2002 03:00:00 GMT  
 Calling //job from //job in .wsf

Already got it. Been reading the documentation and now realize there's more than meets the eye with these scripting technologies. My head's starting to spin! I'm not sure I've been able to sort out when to create a vbs file, a wsf file or a wsc file.

I've found lots of WSH, VBS/JS resources but few Component resources. Know anybody with a site devoted primarily to Script Components? I've read most the msdn articles but the examples are fairly light, though beneficial.

It seems like there is quite a bit of overlap amongst the technologies as a wsf or wsc file can contain any supported language so when's it best to use which technique? Do you create stand alone vbs/js files and "src=..." them in a wsf? Create stand-alone vbs/js files that call jobs in a wsf file that has a "src=.." to outside vbs/js files? Create a wsf that instantiates a component? Create a Component with multiple <component> elements that can reference each other? Sheesh, I'm confused. Any recomendations on "best practices"?

TIA,

Marcus

  Download the "Script Component Wizard" and it handles those details for you...

  Windows Script Component Wizard released

  --
  Michael Harris



Sun, 14 Jul 2002 03:00:00 GMT  
 Calling //job from //job in .wsf

Thanks.

Marcus


  Clarence's and Ian's site are probably the best you'll find for general scripting.  

  If you're willing to part with about $20, I'd recommend picking up a copy of "VBScript Programmer's Reference" from Wrox Press.  It does an excellent job of introducing nearly all of the scripting "host contexts" where you can use vbscript, including a full chapter on windows script components.

  --
  Michael Harris


    Already got it. Been reading the documentation and now realize there's more than meets the eye with these scripting technologies. My head's starting to spin! I'm not sure I've been able to sort out when to create a vbs file, a wsf file or a wsc file.

    I've found lots of WSH, VBS/JS resources but few Component resources. Know anybody with a site devoted primarily to Script Components? I've read most the msdn articles but the examples are fairly light, though beneficial.

    It seems like there is quite a bit of overlap amongst the technologies as a wsf or wsc file can contain any supported language so when's it best to use which technique? Do you create stand alone vbs/js files and "src=..." them in a wsf? Create stand-alone vbs/js files that call jobs in a wsf file that has a "src=.." to outside vbs/js files? Create a wsf that instantiates a component? Create a Component with multiple <component> elements that can reference each other? Sheesh, I'm confused. Any recomendations on "best practices"?

    TIA,

    Marcus


      Download the "Script Component Wizard" and it handles those details for you...

      Windows Script Component Wizard released

      --
      Michael Harris



Sun, 14 Jul 2002 03:00:00 GMT  
 Calling //job from //job in .wsf
Shell the 2nd job using run

Set oAdr = CreateObject ("WScript.Shell")
oAdr.Run "WScript.exe //J:Jobname " & wsf-file

G. Born

Check out the WSH Bazaar at:

http://ourworld.compuserve.com/hompages/Guenter_Born/index0.htm


Quote:
>Greetings All:

>I'm creating a .wsf file with multiple jobs. I want to call other (sub)
jobs
>from Main job or control job execution sequence dynamically. Is this
>possible or should I just write sub routines to accomplish basically the
>same thing? Also, do jobs execute in order, first job auto-magically per
>docs, until no more jobs or can I stop file execution at end of first
(main)
>job with WScript.Quit?

>I can't seem to get other jobs to execute when called from Main job. I've
>tried:

>OtherJobId
>and
>file://job:OtherJob

>(ignore 'file:' in above, OE auto-magically inserts)

>I'm either syntactically challenged or barking up the wrong tree.

>Insights appreciated,

>Marcus



Sun, 14 Jul 2002 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. WSF Multiple Job Self Calling ?

2. Job posting to ba.jobs.offered

3. ** JOB ** - JOB Opportunities in NYC area

4. Trying to DUPLEX PCL job at the back of a poscript job

5. Using one function among several WSF jobs

6. Multiple jobs in wsf file.

7. Using one function among several WSF jobs

8. WSF-file don't make two job

9. Starting multiple jobs (wsf)

10. Jobs in WSF files

11. How do I execute Job from a Wsf

12. file://Job:<job> problem with .wsf FIles

 

 
Powered by phpBB® Forum Software