Is there a list of Special characters to be avoided in JCL/MVS Script variables

Question

I have a program that generates random pin codes. These pins are generated in Java, then stored in the mainframe, via a NATURAL program. From there, they are eventually physically printed by a batch JCL job that calls an MVS SCRIPT to print the form, with the pin code on it.

I've come across some issues with special characters before such as: |{}![]^~<>; that for one reason or another do not print properly. I've also removed 0OQ1l for OCR reasons.

Recently, an error came to my attention with another character that doesn't print properly, . but the . character only fails when it is the first character of the PIN Code.

So since I've run into this issue I thought I would see if I could find other special jcl, Natural or MVS Script characters that might interfere with my programs operation so that I can test them now and hopefully not run into this issue later or have to fallback to only using OCR'ed AlphaNumeric characters.

EDIT

• Java - Web Application Runs Under Tomcat 6.x on a Solaris Server.
• Natural - The Natural Program is called using webmethods Broker generated classes (POJOs).
  • My understanding is it uses RPC for actual communication.
  • The program verifies some data and stores the Pin in combination with a GUID on a record, in ADABAS.
• There is a batch job that runs to print the forms. The Batch job is written in JCL.
  • My Understanding from the maintainer of the Batch Job, and the Forms stuff is the actual language to describe the forms themselves and how they get printed is an outdated/unsupported language called MVS SCRIPT.
• the Bottom section of the script looks like this:

//**********************************************************************
//* PRINT SORTED FORMS TO #### USING MVS SCRIPT                      
//**********************************************************************
PRINTALL EXEC PGM=DSMSPEXEC,PARM='LIST'
//* less 'interesting' lines omitted
SYSPRINT DD SYSOUT=*
PRINT1   DD SYSOUT=A, OUTPUT=*.C####,
            RECFM=VBM,LRECL=####,BLKSIZE=####     
//* less 'interesting' lines omitted
//SYSIN  DD *
  AUTH /* redacted */
  SCRIPT FROM(MYFORMS) (MESSAGE(ID TRACE) CONT -             
                        FILE(PRINT1) PROFILE(redacted) -      
                        NOSEGLIB DEVICE(PG4A) CHARS(X0A055BC))

.C#### is an actual number and is a variable that points to the chosen printer.

NOTE: I'm a Web Programmer, I don't speak mainframe, JCL, MVS, etc.

Answer 1

I think you will find the program (pgm=) is DSMSPEXC and not DSMSPEXEC.

I am guessing (could be wrong) we are talking about Script/DCF (which later became IBM Bookmaster / Bookmanager on other platforms).

Script/DCF is basically a GML based language. It was from GML that SGML was derived (HTML and XML are prominent examples of SGML languages).

In Script : starts a tag, . ends a tag. There are also macro's which have a . in column 1

.* ".*" in column 1 starts a line comment
.* .fo off is Format off (like <pre> in html)
.fo off

.* Starting an ordered list
:ol.
  :li.Item in orded list
:eol.

i.e.

  Script   HTML
    :       <   - Starts tag
    .       >   - end of tag Script/DCF is generally pretty tolerant of .
    &       &   - Starts a variable

There are variables (&gml. = :) for most of the special characters.

---

Characters to worry about are

: - always
& - always
. - in column one or after a :.

Other characters should be ok provided there are no translation errors. There charset X0A055BC (Mainframe SONORAN SANS SERIF ??) might not have all the special chars in it.

There are manuals around for Script/DCF tags.

Answer 2

Your data is not going to affect the JCL in any way.

I don't know about ADABAS or NATURAL. If you ask here, http://www.ibmmainframeforum.com/viewforum.php?f=25, specifically about that part, with as much detail as you can provide, there is a very expert guy, RDZbrog, who can probably answer that for you.

For the SCRIPT/VS itself, as Bruce Martin has pointed out, there may be some issues. With .xx and :xx there is not a clash with normal text. But you don't have normal text. With the &, which indicates a SCRIPT variable, it is more likely to be problematic and at any location.

I would fire some test data through: Your PINs with position one being all available punctuation preceding "fo" and "ol", and the same with those sequences "embedded" in your PINs. Also include a double & and a triple &.

Your query should be resolved in your specification. It is not, but I'm sure you'll get all the documentation updated when you get a resolution.