I am by no means a Forth expert, but from what little I do know this should work. I am running this on VM/370 CE V1R1.1
Written new file: FORTH $PROG$ A1
Ready; T=0.08/0.10 19:23:10
type forth $prog$ a
?
: HELLO? ( -- )? CR ." Hello, World!" ;
?
Ready; T=0.01/0.01 19:23:21
forth
Your FORTH extensions loaded
FORTH ready
?
HELLO
HELLO???? Invalid NUMERIC field
?
CR .( Hello, World!)
CR??????? Invalid NUMERIC field
?
end
Do you want to save your extensions (Y/N)?
n
Ready; T=0.01/0.01 19:23:44
Any ideas?
?... Mark S.
|
I like the proposed change, because that is what IBM C for z/OS and z/VM use. Bob
On Sun, Jun 5, 2022 at 8:30 PM Mark A. Stevens via <marXtevens= [email protected]> wrote: On Wed, Jun 1, 2022 at 03:21 PM, Dave Wade wrote:
fopen("my.file","w,recfm=v,lrecl=300,blksize=304");
?
would open ¡°MY FILE A¡± for writing with variable record lengths, maximum record length of 300, block size 304. I was intended to fix PDPCLIB to work the same way, but when I checked in
?
HELP GCCLIB
?
I see that this has been extended to allow this information to be specified as part of the file name. So the above would need to be¡.
?
fopen("my file a v 300¡±,¡±w¡±);
?
I think I should fix BOTH libraries to work BOTH ways.
Does any one have any thoughts on this.
To be honest, I don't like either, as they both appear to be a kludge. If I had to pick, I would recommend the first and forget the second. That and $3 might buy you a cup of coffee ;-) and if it matters and you have to or want to keep the external characteristics in the code, I'd recommend, as those extra items would come after the 'standard' C parameters.
fopen("my.file",w,recfm=v,lrecl=300,blksize=304);
I understand the challenge is dealing with record based I/O rather than stream I/O. Is this a case of not putting that information in the code and leaving it to a FILEDEF to handle the external characteristics? Then your code would be more portable because you would be externalizing those items which are specific to IBM.
FILEDEF MYFILE DISK MY DATA A ( recfm=v lrecl=300 blksize=304
...
fopen(MYFILE,w);?
Current man page documentation for fopen() includes the following as values for the second parameter.
The argument mode points to a string beginning with one of the
following sequences (possibly followed by additional characters,
as described below):
r Open text file for reading. The stream is positioned at
the beginning of the file.
r+ Open for reading and writing. The stream is positioned at
the beginning of the file.
w Truncate file to zero length or create text file for
writing. The stream is positioned at the beginning of the
file.
w+ Open for reading and writing. The file is created if it
does not exist, otherwise it is truncated. The stream is
positioned at the beginning of the file.
a Open for appending (writing at end of file). The file is
created if it does not exist. The stream is positioned at
the end of the file.
a+ Open for reading and appending (writing at end of file).
The file is created if it does not exist. Output is
always appended to the end of the file. POSIX is silent
on what the initial read position is when using this mode.
For glibc, the initial file position for reading is at the
beginning of the file, but for Android/BSD/MacOS, the
initial file position for reading is at the end of the
file.
I REALLY Hope This Helps.
?... Mark S.
|
Mark A. Stevens wrote: On Sun, Jun 5, 2022 at 07:32 PM, Jay Maynard wrote: Except that your proposal is not valid C syntax. That's
why the first proposal is done that way. Please help me understand your comment. Given that the definition
is ...
FILE *fopen(const char *restrict pathname, const char *restrict mode);
and:
"The fopen() function opens the file whose name is the string
pointed to by pathname and associates a stream with it."
How is using a DDNAME, which points to a file not valid C syntax?
Or is that what fdopen would be used for?
Maybe it's because your proposal: fopen("my.file",w,recfm=v,lrecl=300,blksize=304); Does not match the very C definition (syntax) that you quoted? In 'C', the function 'fopen' is passed only TWO parameters, BOTH being string parameters, whereas in your proposed syntax, the function is being passed FIVE parameters, each of the second through fifth parameters are of an unknown/undefined type. Perhaps you meant to enclose them with double quotes like Dave proposed? I myself haven't been following this thread too closely and I have zero interest in Paul's hacks, but I would listen to Dave Wade. He knows what he's talking about/doing. Me? I would vote for Dave's original proposed syntax, but with blanks instead of commas as the separators in the second string parameter: fopen( "my.file", "w recfm=v lrecl=300 blksize=304" ); <shrug> -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
On 6/5/2022 5:32 PM, Jay Maynard wrote:
Except that your proposal is not valid C syntax.
That's why the first proposal is done that way.
On Wed, Jun
1, 2022 at 03:21 PM, Dave Wade wrote:
fopen("my.file","w,recfm=v,lrecl=300,blksize=304");
?
would open ¡°MY FILE
A¡± for writing with variable record lengths, maximum
record length of 300, block size 304. I was intended to
fix PDPCLIB to work the same way, but when I checked in
?
HELP GCCLIB
?
I see that this has
been extended to allow this information to be specified
as part of the file name. So the above would need to
be¡.
?
fopen("my file a v
300¡±,¡±w¡±);
?
I think I should
fix BOTH libraries to work BOTH ways.
Does any one have
any thoughts on this.
To be honest, I don't like either, as they both appear to be a
kludge. If I had to pick, I would recommend the first and
forget the second. That and $3 might buy you a cup of coffee
;-) and if it matters and you have to or want to keep the
external characteristics in the code, I'd recommend, as those
extra items would come after the 'standard' C parameters.
fopen("my.file",w,recfm=v,lrecl=300,blksize=304);
I understand the
challenge is dealing with record based I/O rather than
stream I/O. Is this a case of not putting that
information in the code and leaving it to a FILEDEF to
handle the external characteristics? Then your code would be
more portable because you would be externalizing those items
which are specific to IBM.
FILEDEF
MYFILE DISK MY DATA A ( recfm=v lrecl=300 blksize=304
...
fopen(MYFILE,w);?
The fopen with the recfm=v (hopefully you have a v defined with a
value)
The as defined variables recfm,? lrecl, blksize would all be
assigned the values shown.
Unless the assignment of values to those variables serve some
purpose, they will have no impact on the call to fopen, the values
will be passed.
The w requires a value such as "w" which is conventional.
this is submitted as FWIW.? The assignments in the parameters work,
but I don't usually do that as one can miss them or otherwise when
reading code.? Worse believe them if someone codes them wrong.? The
variables have no impact at all in the routine called as they aren't
passed.
Current man page documentation for fopen()
includes the following as values for the second parameter.
The argument mode points to a string beginning with one of the
following sequences (possibly followed by additional characters,
as described below):
r Open text file for reading. The stream is positioned at
the beginning of the file.
r+ Open for reading and writing. The stream is positioned at
the beginning of the file.
w Truncate file to zero length or create text file for
writing. The stream is positioned at the beginning of the
file.
w+ Open for reading and writing. The file is created if it
does not exist, otherwise it is truncated. The stream is
positioned at the beginning of the file.
a Open for appending (writing at end of file). The file is
created if it does not exist. The stream is positioned at
the end of the file.
a+ Open for reading and appending (writing at end of file).
The file is created if it does not exist. Output is
always appended to the end of the file. POSIX is silent
on what the initial read position is when using this mode.
For glibc, the initial file position for reading is at the
beginning of the file, but for Android/BSD/MacOS, the
initial file position for reading is at the end of the
file.
I REALLY Hope This Helps.
?... Mark S.
|
On Sun, Jun 5, 2022 at 07:32 PM, Jay Maynard wrote:
Except that your proposal is not valid C syntax. That's why the first proposal is done that way.
Jay, Please help me understand your comment. Given that the definition is ...
FILE *fopen(const char *restrict pathname, const char *restrict mode);
and
The fopen() function opens the file whose name is the string
pointed to by pathname and associates a stream with it.
How is using a DDNAME, which points to a file not valid C syntax? Or is that what fdopen would be used for? ?... Mark S.
|
Except that your proposal is not valid C syntax. That's why the first proposal is done that way.
On Wed, Jun 1, 2022 at 03:21 PM, Dave Wade wrote:
fopen("my.file","w,recfm=v,lrecl=300,blksize=304");
?
would open ¡°MY FILE A¡± for writing with variable record lengths, maximum record length of 300, block size 304. I was intended to fix PDPCLIB to work the same way, but when I checked in
?
HELP GCCLIB
?
I see that this has been extended to allow this information to be specified as part of the file name. So the above would need to be¡.
?
fopen("my file a v 300¡±,¡±w¡±);
?
I think I should fix BOTH libraries to work BOTH ways.
Does any one have any thoughts on this.
To be honest, I don't like either, as they both appear to be a kludge. If I had to pick, I would recommend the first and forget the second. That and $3 might buy you a cup of coffee ;-) and if it matters and you have to or want to keep the external characteristics in the code, I'd recommend, as those extra items would come after the 'standard' C parameters.
fopen("my.file",w,recfm=v,lrecl=300,blksize=304);
I understand the challenge is dealing with record based I/O rather than stream I/O. Is this a case of not putting that information in the code and leaving it to a FILEDEF to handle the external characteristics? Then your code would be more portable because you would be externalizing those items which are specific to IBM.
FILEDEF MYFILE DISK MY DATA A ( recfm=v lrecl=300 blksize=304
...
fopen(MYFILE,w);?
Current man page documentation for fopen() includes the following as values for the second parameter.
The argument mode points to a string beginning with one of the
following sequences (possibly followed by additional characters,
as described below):
r Open text file for reading. The stream is positioned at
the beginning of the file.
r+ Open for reading and writing. The stream is positioned at
the beginning of the file.
w Truncate file to zero length or create text file for
writing. The stream is positioned at the beginning of the
file.
w+ Open for reading and writing. The file is created if it
does not exist, otherwise it is truncated. The stream is
positioned at the beginning of the file.
a Open for appending (writing at end of file). The file is
created if it does not exist. The stream is positioned at
the end of the file.
a+ Open for reading and appending (writing at end of file).
The file is created if it does not exist. Output is
always appended to the end of the file. POSIX is silent
on what the initial read position is when using this mode.
For glibc, the initial file position for reading is at the
beginning of the file, but for Android/BSD/MacOS, the
initial file position for reading is at the end of the
file.
I REALLY Hope This Helps.
?... Mark S.
|
On Wed, Jun 1, 2022 at 03:21 PM, Dave Wade wrote:
fopen("my.file","w,recfm=v,lrecl=300,blksize=304");
?
would open ¡°MY FILE A¡± for writing with variable record lengths, maximum record length of 300, block size 304. I was intended to fix PDPCLIB to work the same way, but when I checked in
?
HELP GCCLIB
?
I see that this has been extended to allow this information to be specified as part of the file name. So the above would need to be¡.
?
fopen("my file a v 300¡±,¡±w¡±);
?
I think I should fix BOTH libraries to work BOTH ways.
Does any one have any thoughts on this.
To be honest, I don't like either, as they both appear to be a kludge. If I had to pick, I would recommend the first and forget the second. That and $3 might buy you a cup of coffee ;-) and if it matters and you have to or want to keep the external characteristics in the code, I'd recommend, as those extra items would come after the 'standard' C parameters. fopen("my.file",w,recfm=v,lrecl=300,blksize=304);
I understand the challenge is dealing with record based I/O rather than stream I/O. Is this a case of not putting that information in the code and leaving it to a FILEDEF to handle the external characteristics? Then your code would be more portable because you would be externalizing those items which are specific to IBM.
FILEDEF MYFILE DISK MY DATA A ( recfm=v lrecl=300 blksize=304
...
fopen(MYFILE,w);?
Current man page documentation for fopen() includes the following as values for the second parameter.
The argument mode points to a string beginning with one of the
following sequences (possibly followed by additional characters,
as described below):
r Open text file for reading. The stream is positioned at
the beginning of the file.
r+ Open for reading and writing. The stream is positioned at
the beginning of the file.
w Truncate file to zero length or create text file for
writing. The stream is positioned at the beginning of the
file.
w+ Open for reading and writing. The file is created if it
does not exist, otherwise it is truncated. The stream is
positioned at the beginning of the file.
a Open for appending (writing at end of file). The file is
created if it does not exist. The stream is positioned at
the end of the file.
a+ Open for reading and appending (writing at end of file).
The file is created if it does not exist. Output is
always appended to the end of the file. POSIX is silent
on what the initial read position is when using this mode.
For glibc, the initial file position for reading is at the
beginning of the file, but for Android/BSD/MacOS, the
initial file position for reading is at the end of the
file.
I REALLY Hope This Helps. ?... Mark S.
|
I followed some discussions on this topic between Paul (I don't
recall his last name, the maintainer of mainframe GCC)
and the community in the past. Paul always had his own mind and
was not very open to others' opinions.
IMHO, the first argument of fopen is the file name, and the
second is attributes of the file (like "binary" in the
non-mainframe world). So the CMS filemode IMO would belong into
the first argument, but the other
parameters like RECFM etc. into the second. That said, the IBM way
to do it seems very OK for me
(I am used to this since 1995 ca., OTOH). ... this is true for
other "incompatibilities" between GCC and
IBM's C as well. And: the runtime of IBM's C (which is LE, BTW)
always served me as a guideline, when I had
to make decisions for the runtime of my Stanford Pascal compiler.?
Kind regards
Bernd
Am 01.06.2022 um 22:21 schrieb Dave
Wade:
toggle quoted message
Show quoted text
Folks,
I am feeling rather
frustrated at present. So when I look at the IBM C/370
manual I see that fopen() was extended to allow the file
attributes to specified in the mode attribute so for
exampele:-
?
fopen("my.file","w,recfm=v,lrecl=300,blksize=304");
?
would open ¡°MY FILE A¡±
for writing with variable record lengths, maximum record
length of 300, block size 304. I was intended to fix PDPCLIB
to work the same way, but when I checked in
?
HELP GCCLIB
?
I see that this has been
extended to allow this information to be specified as part
of the file name. So the above would need to be¡.
?
fopen("my file a v
300¡±,¡±w¡±);
?
I think I should fix
BOTH libraries to work BOTH ways.
Does any one have any
thoughts on this.
?
Dave
?
?
?
|
Folks, I am feeling rather frustrated at present. So when I look at the IBM C/370 manual I see that fopen() was extended to allow the file attributes to specified in the mode attribute so for exampele:- ? fopen("my.file","w,recfm=v,lrecl=300,blksize=304"); ? would open ¡°MY FILE A¡± for writing with variable record lengths, maximum record length of 300, block size 304. I was intended to fix PDPCLIB to work the same way, but when I checked in ? HELP GCCLIB ? I see that this has been extended to allow this information to be specified as part of the file name. So the above would need to be¡. ? fopen("my file a v 300¡±,¡±w¡±); ? I think I should fix BOTH libraries to work BOTH ways. Does any one have any thoughts on this. ? Dave ? ? ?
|
Re: novice help with cmsbatch job output
If you add an ? ¡°CP SPOOL CONS CMSUSER * START¡± ? At the start and a ? ¡°SP CPOOL CONS STOP CLOSE¡± ? At the end you can see what is wrong. This shows me the LINK has a spelling mistake, and I believe that SPOOL commands are missing a device type. I tweaked it :- ? /JOB CMSUSER CMSUSER JOB10 CP SPOOL CONS CMSUSER START CP LINK CMSUSER 191 291 RR READ ACCESS 291 B/A CP MSG CMSUSER TESTING CMSBATCH CP SPOOL PRT TO CMSUSER NOCONT PRINT HELLO FORTRAN CP SPOOL PRT CLOSE CP SPOOL PRT OFF RELEASE 291 CP DETACH 291 CP MSG CMSUSER END JOB CP SPOOL CONS STOP CLOSE /* ? And I get :- ? pun test cards PUN FILE 0701? TO? CMSBATCH COPY 01 NOHOLD Ready; T=0.01/0.01 18:15:16 18:15:16? MSG FROM CMSBATCH:? JOB 'JOB10' STARTED. 18:15:16? MSG FROM CMSBATCH:? TESTING CMSBATCH PRT FILE 0703 FROM CMSBATCH COPY 01 NOHOLD 18:15:16? MSG FROM CMSBATCH:? END JOB CON FILE 0702 FROM CMSBATCH COPY 01 NOHOLD 18:15:16? MSG FROM CMSBATCH:? JOB 'JOB10' ENDED. ? This sends the PRINT and console file to CMSUSER. If you want output on the real printer change line 6 to ? ¡°SPOOL ?PRT SYSTEM CLASS A¡± ? And you will have to then start the printer from say OPERATOR ? CP START? F CLASS A ? Dave ? ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Ron Young
Sent: 27 May 2022 17:37
To: [email protected]
Subject: [h390-vm] novice help with cmsbatch job output? Hi All:
I'm trying to figure out how to "real" card decks with vm370ce.... I can get the job deck to run (and the CP MSG lines appear on cmsuser's 3270 session, but I can't figure out how to get the output to spool to the "real" printer. I am using page #236 (page 296 in the pdf) of /bitsavers/pdf/ibm/370/VM_370/Release_6/GC20-1819-2_IBM_Virtual_Machine_Facility_370_CMS_Users_Guide_Rel_6_PLC_17_Apr81.pdf.
I kick off the job by "devinit 00c test.txt trunc eof" in the operator console.
Any help would be appreciated.
-ron
here is the current job deck:
ID CMSBATCH
/JOB CMSUSER CMSUSER JOB10
CP LINK CMUSER 191 291 RR SECRET
ACCESS 291 B/A
CP MSG CMSUSER TESTING CMSBATCH
CP SPOOL A TO CMSUSER NOCONT
PRINT HELLO FORTRAN
CP CLOSE A
CP SPOOL A OFF
RELEASE 291
CP DETACH 291
CP MSG CMSUSER END JOB
/*
messages to cmsuser
16:34:46? MSG FROM CMSBATCH:? JOB 'JOB10' STARTED.
16:34:46? MSG FROM CMSBATCH:? TESTING CMSBATCH
16:34:46? MSG FROM CMSBATCH:? END JOB
16:34:46? MSG FROM CMSBATCH:? JOB 'JOB10' ENDED.
|
Re: novice help with cmsbatch job output
On Fri, May 27, 2022 at 11:00 AM, Ron Young wrote:
is that the right way to it?
Personally, I prefer to submit the batch job from CMSUSER and spool both PRT and CONSOLE back to CMSUSER. This way I can examine the output with the SFBROWSE command, and use the purge and/or print subcommands of SFBROWSE ?depending on what I want to do. Cheers, Rene FERLAND, Montreal
|
Re: novice help with cmsbatch job output
Chris:
Many thanks! It is working (I also added spooling for the console -- is that the right way to it?)
-ron
ID CMSBATCH
/JOB CMSUSER CMSUSER JOB10
CP LINK CMSUSER 191 291 RR SECRET
ACCESS 291 B/A
CP MSG CMSUSER TESTING CMSBATCH
CP SPOOL PRINT TO SYSTEM CLASS A
CP SPOOL CONSOLE TO SYSTEM CLASS A
LISTFILE * * *
PRINT HELLO FORTRAN
RELEASE 291
CP DETACH 291
CP MSG CMSUSER END JOB
CP CLOSE PRT
CP CLOSE CONSOLE
/*
|
Re: novice help with cmsbatch job output
Ron, It was the case that:- cp SPool PRT TO SYSTEM CLass A PRINT HELLO FORTRAN CP Close PRT would print to your printer. You might need to CP START PRT Chris -- <cjar1950@...> ---------------------------------------------------------------------------------------------------------------------------------- On Fri, 27 May 2022 09:36:56 -0700 "Ron Young" <ron.young3+h390-vm@...> wrote: Hi All:
I'm trying to figure out how to "real" card decks with vm370ce.... I can get the job deck to run (and the CP MSG lines appear on cmsuser's 3270 session, but I can't figure out how to get the output to spool to the "real" printer. I am using page #236 (page 296 in the pdf) of /bitsavers/pdf/ibm/370/VM_370/Release_6/GC20-1819-2_IBM_Virtual_Machine_Facility_370_CMS_Users_Guide_Rel_6_PLC_17_Apr81.pdf.
I kick off the job by "devinit 00c test.txt trunc eof" in the operator console.
Any help would be appreciated.
-ron
here is the current job deck:
ID CMSBATCH
/JOB CMSUSER CMSUSER JOB10
CP LINK CMUSER 191 291 RR SECRET
ACCESS 291 B/A
CP MSG CMSUSER TESTING CMSBATCH
CP SPOOL A TO CMSUSER NOCONT
PRINT HELLO FORTRAN
CP CLOSE A
CP SPOOL A OFF
RELEASE 291
CP DETACH 291
CP MSG CMSUSER END JOB
/*
messages to cmsuser
16:34:46? MSG FROM CMSBATCH:? JOB 'JOB10' STARTED.
16:34:46? MSG FROM CMSBATCH:? TESTING CMSBATCH
16:34:46? MSG FROM CMSBATCH:? END JOB
16:34:46? MSG FROM CMSBATCH:? JOB 'JOB10' ENDED.
|
novice help with cmsbatch job output
Hi All:
I'm trying to figure out how to "real" card decks with vm370ce.... I can get the job deck to run (and the CP MSG lines appear on cmsuser's 3270 session, but I can't figure out how to get the output to spool to the "real" printer. I am using page #236 (page 296 in the pdf) of /bitsavers/pdf/ibm/370/VM_370/Release_6/GC20-1819-2_IBM_Virtual_Machine_Facility_370_CMS_Users_Guide_Rel_6_PLC_17_Apr81.pdf.
I kick off the job by "devinit 00c test.txt trunc eof" in the operator console.
Any help would be appreciated.
-ron
here is the current job deck:
ID CMSBATCH
/JOB CMSUSER CMSUSER JOB10
CP LINK CMUSER 191 291 RR SECRET
ACCESS 291 B/A
CP MSG CMSUSER TESTING CMSBATCH
CP SPOOL A TO CMSUSER NOCONT
PRINT HELLO FORTRAN
CP CLOSE A
CP SPOOL A OFF
RELEASE 291
CP DETACH 291
CP MSG CMSUSER END JOB
/*
messages to cmsuser
16:34:46? MSG FROM CMSBATCH:? JOB 'JOB10' STARTED.
16:34:46? MSG FROM CMSBATCH:? TESTING CMSBATCH
16:34:46? MSG FROM CMSBATCH:? END JOB
16:34:46? MSG FROM CMSBATCH:? JOB 'JOB10' ENDED.
|
Re: Looking for how to get NJE (or RSCS) with tcp on VM/370 CE
|
Re: Looking for how to get NJE (or RSCS) with tcp on VM/370 CE
On Sat, May 21, 2022 at 01:12 PM, Ron Young wrote:
Can anyone provide instructions on how to do this? Ideally something like to the NJE38_Installation_and_Usage_Guide.pdf for MVS would be great.
Hello Ron, You can ask Peter Coghlan directly for his RSCS update for TCPNJE. Write to the email address given at the bottom of this page:? Cheers, Rene FERLAND, Montreal
|
Looking for how to get NJE (or RSCS) with tcp on VM/370 CE
I am a VM & IBM novice... I would like to get some sort of network job submisson going between my hyperion VM/370 community edition 1.3 system and (for example) my dtCyber NOS 2.8.7 (control data) system. dtCyber supports NJE over tcp. In researching things I have found that MVS supports this with using NJE38v220 and I have seen many references/writeups about modifying RSCS to use tcp. But all of the specifics seem to point to a set of mods that have been removed because they weren't meant to be publicly released. (Most of them end up at )
Can anyone provide instructions on how to do this? Ideally something like to the NJE38_Installation_and_Usage_Guide.pdf for MVS would be great.
thanks
-ron
|
Re: How To Capture CP SPOOL Command Output
#VMCE
On Wed, May 18, 2022 at 07:11 AM, Bob Bolch wrote:
In the test case, STRING is followed by text which is followed by a ')'. The parenthesis is treated as part of the CP CLOSE command. The command fails and the console is not closed.
Thank you, Bob. I removed the ' )' at the end of each EXECIO, and it is now working better. I didn't guess that STRING would swallow the right parenthesis.Ready; T=0.20/0.24 17:50:14parsQUERY VIRTUAL 00CCPinfo.0? =? 1CPinfo.1? =? RDR? 00C CL A? NOCONT NOHOLD?? EOF????? READYSPOOL CONSOLE START TO * TERMCPinfo.0? =? 0Enter pattern:?File: GCC EXEC Y2.16:&ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &2022:&ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &2028:&ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &2035:?? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &2061:?? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &2088:?? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &20SPOOL CONSOLE STOP CLOSE TERMCPinfo.0? =? 1CPinfo.1? =? CON FILE 1763? TO? XMAS???? COPY 01 NOHOLDSpool ID:? 1763CHANGE RDR? 1763? CLASS ACPinfo.0? =? 1CPinfo.1? =? 0001 FILE? CHANGEDORDER RDR? 1763CPinfo.0? =? 1CPinfo.1? =? 0001 FILE? ORDERED17? lines read.Ready; T=0.07/0.09 17:50:16?Since I read 17 lines, I extended the code to print them out ...
//'EXECIO * CARD ( STEM RDRLINE.'SAY RDRLINE.0 ' lines read.'Counter = 0DO UNTIL Counter > RDRLINE.0?? SAY 'RDRLINE.'Counter ' = ' RDRLINE.Counter?? Counter = Counter + 1END///* Exit cleanly.????????????????????????????????????????????????????? *///RETURN rcWhich generates the following output. I'm not sure if the problem is with bREXX, or something else. Maybe I need to start learning TRACE, and similar commands. parsQUERY VIRTUAL 00CCPinfo.0? =? 1CPinfo.1? =? RDR? 00C CL A? NOCONT NOHOLD?? EOF????? READYSPOOL CONSOLE START TO * TERMCPinfo.0? =? 0Enter pattern:?File: GCC EXEC Y2.16:&ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &2022:&ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &2028:&ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &2035:?? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &2061:?? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &2088:?? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &20SPOOL CONSOLE STOP CLOSE TERMCPinfo.0? =? 1CPinfo.1? =? CON FILE 1767? TO? XMAS???? COPY 01 NOHOLDSpool ID:? 1767CHANGE RDR? 1767? CLASS ACPinfo.0? =? 1CPinfo.1? =? 0001 FILE? CHANGEDORDER RDR? 1767CPinfo.0? =? 1CPinfo.1? =? 0001 FILE? ORDERED17? lines read.RDRLINE.0? =? 17RDRLINE.1? =? CPinfo.0? =? 0?RDRLINE.2? =? Enter pattern:?RDRLINE.3? =?RDRLINE.4? =? File: GCC EXEC Y2.?RDRLINE.5? =? 16:?RDRLINE.6? =? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &20?RDRLINE.7? =? 22:?RDRLINE.8? =? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &20?RDRLINE.9? =? 28:?RDRLINE.10? =? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18?&19 &20?RDRLINE.11? =? 35:?RDRLINE.12? =???? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &20?RDRLINE.13? =? 61:?RDRLINE.14? =???? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &20?RDRLINE.15? =? 88:?RDRLINE.16? =???? &ARGS &2 &3 &4 &5 &6 &7 &8 &9 &10 &11 &12 &13 &14 &15 &16 &17 &18 &19 &20?RDRLINE.17? =? SPOOL CONSOLE STOP CLOSE TERM?DMSITP143T FLOATING-POINT DIVIDE EXCEPTION OCCURRED AT F3834E IN SYSTEM ROUTINE EXEC, RE-IPL CMS.CP ENTERED; DISABLED WAIT PSW '00020000 40F8B75E'
?... Mark S.
|
Re: How To Capture CP SPOOL Command Output
#VMCE
EXECIO has some non-standard characteristics in the way it processes the STRING operand:
?STRING text supplies up to 255 characters of output data or a CP command explicitly on the EXECIO command line. Any characters following the STRING keyword are treated as string data, not additional EXECIO operands. Therefore, STRING, if specified, must be the final option on the command line.
In the test case, STRING is followed by text which is followed by a ')'. The parenthesis is treated as part of the CP CLOSE command. The command fails and the console is not closed.
|
Not for VM/360 R6, but the public LCM+L VM/SP system has number of REXX Macros for XEDIT, including the * (comment) command:
- G (Get File)
- T (Title Case)? ?
- W (Wrap Paragraph)? ?
- * (Comment)
- L (Lowercase)? ?
- U (Uppercase)? ?
- Y (Put To File)? ? ? ?
- ) (Center)
Source all these are on the Y disk.
My test system actually has minor tweaks and additional functions; I really to update the files and help menu on the production LCM+L.
-ahd-
p.s. Backporting to VM/370 R6 would require support of both REXX and an editor that allowed programmed prefix commands.
|
Mark A. Stevens
Ren¨¦ Ferland