Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
It is what it is! Deal with it or submit a requirement! snip On Fri, 25 Jan 2008 10:40:43 -0600, Paul Gilmartin wrote: On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin wrote: I HATE JCL! I invite any IBM representative participating on this list to defend such divergence of conventions; I expect a conspicuous silence, much less an apology to customers. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Fri, 25 Jan 2008 00:30:07 -0600, Bruce Hewson wrote:
normally I have seen a null parm coded as adjacent comma's.
//OUT01OUTPUT USERDATA=('A',,'C')
On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin
wrote:
snip
I HATE JCL!
Nope. Same error:
3 // SET SYMBOL=''
4 // SET SYMBOL=
5 //STEP0EXEC PGM=IEFBR14,PARM=
//*
6 //STEP EXEC PGM=IEFBR14,PARM=''
//*
7 //OUT00OUTPUT USERDATA=('A','B','C')
//*
8 //OUT01OUTPUT USERDATA=('A',,'C')
//*
9 //OUT02OUTPUT USERDATA=('A','','C')
//*
//* :w ! submit lstc3mvs
STMT NO. MESSAGE
-
8 IEF641I IMPROPER SUBPARAMETER LIST IN THE USERDATA FIELD
9 IEF641I IMPROPER SUBPARAMETER LIST IN THE USERDATA FIELD
Note that in SET and PARM (which surprised me) either nothing
or '' is accepted as a representation of the null string. One
major flaw of JCL is its inconsistency. Conway's Law. It seems
that each feature of JCL was assigned to a different coder, and
they didn't coordinate on conventions.
In fact, since:
22.70 z/OS V1R7.0 MVS JCL Reference
__
22.70 USERDATA Parameter
Purpose
The purpose and use of this keyword is defined by the installation.
... I.e. anything the user wants, there's strong reason not to impose
frivolous lexical restrictions on its values. In fact, limitation
of each subparameter value to 60 chararcters (even less than 100)
may be an imposition on some intended uses. And the prohibition
of empty strings has an unpleasant astonishment factor for users
who assign the empty string to a JCL symbol, then attempt to use
that symbol's value in USERDATA.
Would any IBM representative care to supply a rationale for
the restriction?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin On Fri, 25 Jan 2008 00:30:07 -0600, Bruce Hewson wrote: On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin wrote: snip I HATE JCL! It gets worse: 22.1.4.1 z/OS V1R7.0 MVS JCL Reference __ 22.1.4.1 Using enclosing apostrophes in OUTPUT parameters [ ... ] Symbolic Parameters: Do not enclose symbolic parameters within apostrophes . Symbolic parameters enclosed in apostrophes are not resolved for this keyword. C'mon, guys: Why! More often than not, things enclosed in apostrophes are treated as literals rather than variables. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Fri, 25 Jan 2008 00:30:07 -0600, Bruce Hewson wrote: On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin wrote: snip I HATE JCL! It gets worse: 22.1.4.1 z/OS V1R7.0 MVS JCL Reference __ 22.1.4.1 Using enclosing apostrophes in OUTPUT parameters [ ... ] Symbolic Parameters: Do not enclose symbolic parameters within apostrophes . Symbolic parameters enclosed in apostrophes are not resolved for this keyword. C'mon, guys: Why! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Fri, 25 Jan 2008 10:17:55 -0600, Chase, John wrote: On Fri, 25 Jan 2008 00:30:07 -0600, Bruce Hewson wrote: On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin wrote: snip I HATE JCL! More often than not, things enclosed in apostrophes are treated as literals rather than variables. Why, then, is it ever otherwise? Why isn't it Always, rather than More often than not? Why are not the same rules used for parsing strings in all contexts? Why are symbols within apostrophes resolved for the PATH keyword of the DD statement, but not for for the USERPATH keyword of the OUTPUT statement when the two are so notionally similar? It's not as if Development were struggling to get Release 1.0 of OS/360 out the door, as 40+ years ago. Both PATH and USERPATH are relatively recent enhancements to a mature product; designers should have had time to consider the need for uniformity. Heck, the parser code could even have been reused, saving development resource while providing such uniformity. I invite any IBM representative participating on this list to defend such divergence of conventions; I expect a conspicuous silence, much less an apology to customers. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Fri, 25 Jan 2008 10:40:43 -0600, Paul Gilmartin wrote: On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin wrote: I HATE JCL! I invite any IBM representative participating on this list to defend such divergence of conventions; I expect a conspicuous silence, much less an apology to customers. Why not end your constant ranting and submit a requirement to IBM Marketing or SHARE (or your favorite other user group, if any) so that you are using the official channels and NOT wasting everyone's bandwidth on ibm-main??? Seriously! -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
Paul, If you think IBM JCL is bad you would go completely mental over how DPS-8 systems JCL was done. As Tom mentioned, submit a requirement to IBM if the Parm length limit bugs you too much. They will not change anything based on ranting on a forum or a listserv. This isn't the gaming industry where the loudest rant gets the changes. If you want IBM to do something about it, contact them! I have a few times in the past and they are always helpful and even fixed an issue for our shop once. Darren -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
In [EMAIL PROTECTED], on 01/23/2008 at 03:22 PM, Ed Gould [EMAIL PROTECTED] said: We have discussed on IBM-MAIN plenty of times about the restriction of 100 characters in the parm field. The PSF proc is an example what IBM had to go through in order to get around the 100 character max. I see no such circumvention. This is the interesting as it shows how far IBM had to go to get around the restriction. They basically had to add fields and change the convertor/interpreter to allow for the options. The OUTPUT statement is not an extension of the EXEC statement and has nothing to do with PARM. While I am not saying increasing the length would *NOT* have necessitated the changes (its probably a tossup) it would have made implementation, IMO a LOT easier. No. IBM would still have needed to add the OUTPUT statement and nothing in the code for the extended PARM could have been pirated for us in OUTPUT. As a side issue are these new JCL parameters supported in dynamic allocation? Yes. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
I have yet to find a way to access the information on an output statement. Can you give a hint as to where to find it? curious pup IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 01/23/2008 05:11:23 PM: And you just came up with a bit of a methodology that could be used (with some difficulty) in our own application programs. In a step which wants a PARM value 100 characters, use something like: // PARM='abcd ' where abcd is the label of an // OUTPUT statement available to the application. You can then use many of the parameters on the OUTPUT statement for passing parameter information. For example, ADDRESS= can contain up to 4 subparameters, each of which can be up to 60 bytes. . . . Retrieving this data is left as an exercise for the user. But it would likely be done in an assembler subroutine. John McKown - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Jan 24, 2008, at 8:39 AM, Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 01/23/2008 at 03:22 PM, Ed Gould [EMAIL PROTECTED] said: We have discussed on IBM-MAIN plenty of times about the restriction of 100 characters in the parm field. The PSF proc is an example what IBM had to go through in order to get around the 100 character max. I see no such circumvention. This is the interesting as it shows how far IBM had to go to get around the restriction. They basically had to add fields and change the convertor/interpreter to allow for the options. The OUTPUT statement is not an extension of the EXEC statement and has nothing to do with PARM. While I am not saying increasing the length would *NOT* have necessitated the changes (its probably a tossup) it would have made implementation, IMO a LOT easier. No. IBM would still have needed to add the OUTPUT statement and nothing in the code for the extended PARM could have been pirated for us in OUTPUT. As a side issue are these new JCL parameters supported in dynamic allocation? Yes. Shmuel: I guess we differ in what you see and what I see. However its not worth disagreeing about. Yes it is simpler to do it the way (adding new JCL statements ), but from my understanding about the last re- write if there had been no rewrite, the code that would have been needed would have been quite a bit, as it was originally written it had turned into a monster to add new JCL statements. Now it was a minor addition (from what I heard). If there had been no restriction of parm length I believe the new JCL statements could have been created using dynamic allocation. But its not worth talking about have it your way. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Wed, 23 Jan 2008 16:11:23 -0600, McKown, John wrote:
And you just came up with a bit of a methodology that could be used
(with some difficulty) in our own application programs. In a step which
wants a PARM value 100 characters, use something like: // PARM='abcd '
where abcd is the label of an // OUTPUT statement available to the
application. You can then use many of the parameters on the OUTPUT
statement for passing parameter information. ...
I HATE JCL!
3 //STEP EXEC PGM=IEFBR14
//*
4 //OUT00OUTPUT USERDATA=('A','B','C')
//*
5 //OUT01OUTPUT USERDATA=('A','','C')
//*
//* :w ! submit lstc3mvs
STMT NO. MESSAGE
-
5 IEF641I IMPROPER SUBPARAMETER LIST IN THE USERDATA FIELD
Yes, it's documented that way.
No, there's no reason they had to do it that way, other
than to deprive the customer of some flexibility. (Well,
maybe in some of their processing loops they use a null
subparameter as a list terminator. But that could have
been done otherwise. Or did they want the subparameter
values to be MVC-eligible? Still, that coding shortcut
doesn't justify the abandoning of generality.)
Would any IBM representative care to supply a rationale for
the restriction?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
Hi Gil,
I wonder if your null parameter is misinterpreting your quotes...something like
the rule that to support imbedded quote, you must code two in sequence, the
first as an escape character..
normally I have seen a null parm coded as adjacent comma's.
//OUT01OUTPUT USERDATA=('A',,'C')
On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin
[EMAIL PROTECTED] wrote:
snip
I HATE JCL!
3 //STEP EXEC PGM=IEFBR14
//*
4 //OUT00OUTPUT USERDATA=('A','B','C')
//*
5 //OUT01OUTPUT USERDATA=('A','','C')
//*
//* :w ! submit lstc3mvs
STMT NO. MESSAGE
-
5 IEF641I IMPROPER SUBPARAMETER LIST IN THE USERDATA FIELD
Yes, it's documented that way.
No, there's no reason they had to do it that way, other
than to deprive the customer of some flexibility. (Well,
maybe in some of their processing loops they use a null
subparameter as a list terminator. But that could have
been done otherwise. Or did they want the subparameter
values to be MVC-eligible? Still, that coding shortcut
doesn't justify the abandoning of generality.)
Would any IBM representative care to supply a rationale for
the restriction?
-- gil
Regards
Bruce Hewson
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Using an InfoPrint 6500 with PSF
Can anyone share the FSS proc for this type of printer? I installed the IBM 6400 Line Printer so it may be similar. Here's the FSS Proc, the JES2 parms follow //FSSPSF PROC 00010010 //STEP01 EXEC PGM=APSPPIEP,REGION=4M,TIME=NOLIMIT, 0002 // PARM=(,FULL,,,TCP390SYSCLONE,UNICODE) 00030014 //JOBHDR OUTPUT PAGEDEF=L08584,/* JOB HEADER PAGE*/ 00040016 // FORMDEF=A00010,CHARS=GT12 00050016 //JOBTLR OUTPUT PAGEDEF=L08584,/* JOB TRAILER PAGE */ 00060011 // FORMDEF=A00010,CHARS=GT12 00070011 //DSHDR OUTPUT PAGEDEF=L06464,/* DATA SET SEPARATOR */ 00080011 // FORMDEF=A00010,CHARS=GT10 00090010 //MSGDS OUTPUT PAGEDEF=L06464,/* MESSAGE DATA SET */ 00100011 // FORMDEF=A00010,CHARS=GT10, 00110017 // CLASS=H,DEST=PRT129,DATACK=BLOCK,FORMS=STD,PIMSG=NO 00120017 //FONT01 DDDSN=SYS1.PSF.FONTLIBB,DISP=SHR 240 PEL FONTS 00130009 // DDDSN=SYS1.PSF.FONTLIB,DISP=SHR 00140009 //FONT02 DDDSN=SYS1.PSF.FONT300,DISP=SHR 300 PEL FONTS 00150009 // DDDSN=SYS1.PSF.FONTLIB,DISP=SHR 00160009 //PSEG01 DDDISP=SHR,DSN=SYS1.HPRF340.PSEGLIB 00170011 //OLAY01 DDDISP=SHR,DSN=SYS1.HPRF340.OVERLIB /* OVERLAY */ 00180011 //PDEF01 DDDISP=SHR,DSN=SYS1.HPRF340.PDEFLIB /* PAGE DEF,AKA FCB */ 00190021 //FDEF01 DDDISP=SHR,DSN=SYS1.HPRF340.FDEFLIB /* FORM DEFINITION */ 00200011 //AFPSTATS DD DISP=SHR,DSN=SYS3.PSF.AFPSTATS/* STATS PDSE */ 00210011 //PRTINFO DD DISP=SHR,DSN=SYS3.PSF.AFPSTATS/* PRT INFO/STATUS */ 00220012 //PRT5 DD DISP=SHR,DSN=SYS3.PSF.TRACE /* TRACE*/ 00230013 //PRT5 CNTL 0024 //PRT5 PRINTDEV OVLYDD=*.OLAY01, /* OVERLAY LIBRARY DD 00250002 // OVLY240=*.OLAY01, /* 240 PEL OVERLAY LIBRARY D 00260002 // FONTDD=*.FONT01, /* FONT LIBRARY DD 00270006 // FONT240=*.FONT01, /* 240 PEL FONT LIBRARY DD 00280008 // FONT300=*.FONT02, /* 300 PEL FONT LIBRARY DD 00290009 // PSEGDD=*.PSEG01, /* SEGMENT LIBRARY DD 0030 // PSEG240=*.PSEG01, /* 240 PEL SEGMENT LIBRARY D 0031 // PDEFDD=*.PDEF01, /* PAGEDEF LIBRARY DD - FCB 00320021 // FDEFDD=*.FDEF01, /* FORMDEF LIBRARY DD 0033 // JOBHDR=*.JOBHDR, /* JOB HEADER SEPARATOR OUTP 0034 // JOBTRLR=*.JOBTLR, /* JOB TRAILER SEPARATOR OUT 0035 // MESSAGE=*.MSGDS, /* MESSAGE DATA SET OUTPUT 0036 // PAGEDEF=L08584, /* DEVICE PAGEDEF DEFAULT 00370015 // FORMDEF=A00010, /* DEVICE FORMDEF DEFAULT 00380015 // CHARS=GT10, /* DEFAULT FONT - 10 CPI 00390020 // PIMSG=(YES,16), /* ACCUMULATE DATA SET MESSA 0040 // DATACK=BLOCK, /* BLOCK DATA CHECKS 0041 // TRACE=YES,/* BUILD INTERNAL TRACE 00420021 // PRTINFO=YES, /* PRT STATUS TO PRTINFO DD 00430012 // SETUP=FORMS, /* HAVE JES ISSUE SETUP MSG 00440012 // FAILURE=WCONNECT, /* ATTEMPT RECONNECT 0045 // CONNINTV=600, /* 10 MIN TO GET SESSION STARTED 00460020 // DISCINTV=0, /* NO TIME OUT IF NO O/P FM JES 00470020 // MGMTMODE=IMMED, /* MAINTAIN SESSION 0048 // IPADDR='111.111.1.111'/* IP ADDRESS OF PRINTER 00490003 //PRT5 ENDCNTL 0050 JES2 parms: /* DEFINE A FUNCTIONAL SUBSYSTEM FSS FOR PSF */ FSS(FSSPSF) PROC=FSSPSF, AUTOSTOP=NO, HASPFSSM=HASPFSSM PRT5 MODE=FSS, FSS=FSSPSF, PRMODE=(LINE,PAGE), START=NO, UCS=0, SEP=YES,SEPDS=NO,MARK=YES, CKPTPAGE=100, TRKCELL=YES, CLASS=A HTH Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
We have discussed on IBM-MAIN plenty of times about the restriction of 100 characters in the parm field. The PSF proc is an example what IBM had to go through in order to get around the 100 character max. I am *NOT* complaining but just showing those who have complained how IBM got around its own 100 character max length restriction. This is the interesting as it shows how far IBM had to go to get around the restriction. They basically had to add fields and change the convertor/interpreter to allow for the options. I'll bet a beer that this cost IBM a fair amount of change in order to implement these new JCL fields. While I am not saying increasing the length would *NOT* have necessitated the changes (its probably a tossup) it would have made implementation, IMO a LOT easier. Yes I know it was re-written (and probably is for the best) but in any case it would have been less costly. As a side issue are these new JCL parameters supported in dynamic allocation? If not has anyone tried putting in a Share requirement and if so what was the outcome? Ed On Jan 23, 2008, at 9:57 AM, Jack Kelly wrote: Can anyone share the FSS proc for this type of printer? I installed the IBM 6400 Line Printer so it may be similar. Here's the FSS Proc, the JES2 parms follow //FSSPSF PROC 00010010 //STEP01 EXEC PGM=APSPPIEP,REGION=4M,TIME=NOLIMIT, 0002 // PARM=(,FULL,,,TCP390SYSCLONE,UNICODE) 00030014 //JOBHDR OUTPUT PAGEDEF=L08584,/* JOB HEADER PAGE*/ 00040016 // FORMDEF=A00010,CHARS=GT12 00050016 //JOBTLR OUTPUT PAGEDEF=L08584,/* JOB TRAILER PAGE */ 00060011 // FORMDEF=A00010,CHARS=GT12 00070011 //DSHDR OUTPUT PAGEDEF=L06464,/* DATA SET SEPARATOR */ 00080011 // FORMDEF=A00010,CHARS=GT10 00090010 //MSGDS OUTPUT PAGEDEF=L06464,/* MESSAGE DATA SET */ 00100011 // FORMDEF=A00010,CHARS=GT10, 00110017 // CLASS=H,DEST=PRT129,DATACK=BLOCK,FORMS=STD,PIMSG=NO 00120017 //FONT01 DDDSN=SYS1.PSF.FONTLIBB,DISP=SHR 240 PEL FONTS 00130009 // DDDSN=SYS1.PSF.FONTLIB,DISP=SHR 00140009 //FONT02 DDDSN=SYS1.PSF.FONT300,DISP=SHR 300 PEL FONTS 00150009 // DDDSN=SYS1.PSF.FONTLIB,DISP=SHR 00160009 //PSEG01 DDDISP=SHR,DSN=SYS1.HPRF340.PSEGLIB 00170011 //OLAY01 DDDISP=SHR,DSN=SYS1.HPRF340.OVERLIB /* OVERLAY */ 00180011 //PDEF01 DDDISP=SHR,DSN=SYS1.HPRF340.PDEFLIB /* PAGE DEF,AKA FCB */ 00190021 //FDEF01 DDDISP=SHR,DSN=SYS1.HPRF340.FDEFLIB /* FORM DEFINITION */ 00200011 //AFPSTATS DD DISP=SHR,DSN=SYS3.PSF.AFPSTATS/* STATS PDSE */ 00210011 //PRTINFO DD DISP=SHR,DSN=SYS3.PSF.AFPSTATS/* PRT INFO/ STATUS */ 00220012 //PRT5 DD DISP=SHR,DSN=SYS3.PSF.TRACE /* TRACE*/ 00230013 //PRT5 CNTL 0024 //PRT5 PRINTDEV OVLYDD=*.OLAY01, /* OVERLAY LIBRARY DD 00250002 // OVLY240=*.OLAY01, /* 240 PEL OVERLAY LIBRARY D 00260002 // FONTDD=*.FONT01, /* FONT LIBRARY DD 00270006 // FONT240=*.FONT01, /* 240 PEL FONT LIBRARY DD 00280008 // FONT300=*.FONT02, /* 300 PEL FONT LIBRARY DD 00290009 // PSEGDD=*.PSEG01, /* SEGMENT LIBRARY DD 0030 // PSEG240=*.PSEG01, /* 240 PEL SEGMENT LIBRARY D 0031 // PDEFDD=*.PDEF01, /* PAGEDEF LIBRARY DD - FCB 00320021 // FDEFDD=*.FDEF01, /* FORMDEF LIBRARY DD 0033 // JOBHDR=*.JOBHDR, /* JOB HEADER SEPARATOR OUTP 0034 // JOBTRLR=*.JOBTLR, /* JOB TRAILER SEPARATOR OUT 0035 // MESSAGE=*.MSGDS, /* MESSAGE DATA SET OUTPUT 0036 // PAGEDEF=L08584, /* DEVICE PAGEDEF DEFAULT 00370015 // FORMDEF=A00010, /* DEVICE FORMDEF DEFAULT 00380015 // CHARS=GT10, /* DEFAULT FONT - 10 CPI 00390020 // PIMSG=(YES,16), /* ACCUMULATE DATA SET MESSA 0040 // DATACK=BLOCK, /* BLOCK DATA CHECKS 0041 // TRACE=YES,/* BUILD INTERNAL TRACE 00420021 // PRTINFO=YES, /* PRT STATUS TO PRTINFO DD 00430012 // SETUP=FORMS, /* HAVE JES ISSUE SETUP MSG 00440012 // FAILURE=WCONNECT, /* ATTEMPT RECONNECT 0045 // CONNINTV=600, /* 10 MIN TO GET SESSION STARTED 00460020 // DISCINTV=0, /* NO TIME OUT IF NO O/P FM JES 00470020 // MGMTMODE=IMMED, /* MAINTAIN SESSION 0048 // IPADDR='111.111.1.111'/* IP ADDRESS OF PRINTER 00490003 //PRT5 ENDCNTL 0050 JES2 parms: /* DEFINE A FUNCTIONAL SUBSYSTEM FSS FOR PSF */ FSS(FSSPSF) PROC=FSSPSF, AUTOSTOP=NO, HASPFSSM=HASPFSSM PRT5 MODE=FSS, FSS=FSSPSF,
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On 23 Jan 2008 13:22:31 -0800, [EMAIL PROTECTED] (Ed Gould) wrote: We have discussed on IBM-MAIN plenty of times about the restriction of 100 characters in the parm field. The PSF proc is an example what IBM had to go through in order to get around the 100 character max. I am *NOT* complaining but just showing those who have complained how IBM got around its own 100 character max length restriction. This is the interesting as it shows how far IBM had to go to get around the restriction. Getting around a restriction often requires more hoops to jump through than removing the restriction. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Wednesday, January 23, 2008 3:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF We have discussed on IBM-MAIN plenty of times about the restriction of 100 characters in the parm field. The PSF proc is an example what IBM had to go through in order to get around the 100 character max. I am *NOT* complaining but just showing those who have complained how IBM got around its own 100 character max length restriction. This is the interesting as it shows how far IBM had to go to get around the restriction. They basically had to add fields and change the convertor/interpreter to allow for the options. I'll bet a beer that this cost IBM a fair amount of change in order to implement these new JCL fields. While I am not saying increasing the length would *NOT* have necessitated the changes (its probably a tossup) it would have made implementation, IMO a LOT easier. Yes I know it was re-written (and probably is for the best) but in any case it would have been less costly. As a side issue are these new JCL parameters supported in dynamic allocation? If not has anyone tried putting in a Share requirement and if so what was the outcome? Ed And you just came up with a bit of a methodology that could be used (with some difficulty) in our own application programs. In a step which wants a PARM value 100 characters, use something like: // PARM='abcd ' where abcd is the label of an // OUTPUT statement available to the application. You can then use many of the parameters on the OUTPUT statement for passing parameter information. For example, ADDRESS= can contain up to 4 subparameters, each of which can be up to 60 bytes. That is 240 characters. BUILDING gives another 60 characters (300 so far). DEPT gives yet another 60 (now 360 bytes). MAILBCC can be up to 32 addresses of 60 characters each, or 1920 bytes (now at 2280 bytes). MAILCC gives the same as MAILBCC (now up to 4200 bytes). MAILFILE gives another 60 bytes (4260 total). MAILFROM another 60 (4320 bytes). MAILTO another 32 by 60 characters (1920 more for 6240 bytes). NAME= for 60 more (6300 types). PRTATTRS for 127 characters (6427 bytes). PRTOPTNS for 16 characters (6443 bytes). PRTQUEUE for 127 bytes (6570 bytes). REPLYTO for 60 bytes (6630 bytes total, so far). ROOM gives another 60 bytes (6690 bytes). TITLE, another 60 bytes (6750 bytes). USERDATA gives 16 times 60 or 960 bytes (7710 bytes). USERPATH for 8 times 254 bytes or 2032 bytes (9742 bytes). WRITER give a final 8 bytes for a grand total of 9750 bytes, assuming I haven't misadded anywhere. Retrieving this data is left as an exercise for the user. But it would likely be done in an assembler subroutine. Oh, and that 9750 bytes is per OUTPUT statement. Now, going even crazier, you could architect your main program to only accept OUTPUT statement names in the PARM=. A PARM is 100 bytes. Assuming that you'd need a space as a separator, what is the maximum number of possible labels which could be given to the main routine? The first characters must be alphabetic or national. That's 29 values. The second through 6th can also be numeric. That's 39 values. So, there are 29 single character labels, taking 2 characters (trailing blank). That's 58 characters, leaving 42. In that, you can put 14 more 2 character labels. That's a total of 43 possible labels of OUTPUT statements, each possibly having 9750 bytes of parameter information, for a super grand total of 419,250 bytes of parameter information. WOW! I exceeded the magic 64K! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Wed, 23 Jan 2008 16:11:23 -0600, McKown, John [EMAIL PROTECTED] wrote: ... And you just came up with a bit of a methodology that could be used (with some difficulty) in our own application programs. In a step which wants a PARM value 100 characters, use something like: // PARM='abcd ' where abcd is the label of an // OUTPUT statement ... Oh, and that 9750 bytes is per OUTPUT statement. Now, going even crazier, ... WOW! I exceeded the magic 64K! ... Yes, that is a clever technique. But document it very carefully if you choose to use it because it is very non-standard, and very unintuitive. People may not remember that ROOM contains a list of userids, or that the freeform text started in PRTQUEUE is continued in USERDATA, etc. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
sigh I was struggling desperately to resist contributing to this (again) thread. I lost. I suppose we all lost. On Wed, 23 Jan 2008 17:27:47 -0600, Patrick O'Keefe wrote: On Wed, 23 Jan 2008 16:11:23 -0600, McKown, John wrote: ... And you just came up with a bit of a methodology that could be used (with some difficulty) in our own application programs. In a step which wants a PARM value 100 characters, use something like: // PARM='abcd ' Or a wildcard? PARM='abcd*', representing abcd00, abcd01, ...? where abcd is the label of an // OUTPUT statement ... Oh, and that 9750 bytes is per OUTPUT statement. Now, going even crazier, ... WOW! I exceeded the magic 64K! ... Yes, that is a clever technique. But document it very carefully if you choose to use it because it is very non-standard, and very unintuitive. And it isn't conformant to the expectations of unmodified existing load modules. But a wrapper program: //STEP EXEC PGM=CATPARM,PARM='LOADMOD/ABCD*' ... that could string together the USERDATA fields, point R1 ... at the result and XCTL LOADMOD? Would there need to be both an authorized and an unauthorized version? I suppose one could force unauthorized with a STEPLIB catenation. And symbolic substitution would work, wouldn't it? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Jan 23, 2008, at 4:11 PM, McKown, John wrote: ---SNIP--- Oh, and that 9750 bytes is per OUTPUT statement. Now, going even crazier, you could architect your main program to only accept OUTPUT statement names in the PARM=. A PARM is 100 bytes. Assuming that you'd need a space as a separator, what is the maximum number of possible labels which could be given to the main routine? The first characters must be alphabetic or national. That's 29 values. The second through 6th can also be numeric. That's 39 values. So, there are 29 single character labels, taking 2 characters (trailing blank). That's 58 characters, leaving 42. In that, you can put 14 more 2 character labels. That's a total of 43 possible labels of OUTPUT statements, each possibly having 9750 bytes of parameter information, for a super grand total of 419,250 bytes of parameter information. WOW! I exceeded the magic 64K! ---SNIP-- Chuckle that is why I suggested the length be permitted up to an address space size. I did that partly in jest but so there wouldn't be any real restrictions per se in the future. Looks like the future is coming at us a lot faster than we realized. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Using an InfoPrint 6500 with PSF
Hi, I am trying to set up a new Infoprint 6500 (Line matrix printer) to work with PSF. The printer has an ethernet card and IPDS installed. Can anyone share the FSS proc for this type of printer? TIA Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
