Technical Support

If you need to contact the IBM Dallas ISV Center for technical support, please post your question in the IBM Z Dallas ISV Community User Group
If you are not a member of the user group, follow the instructions to join on our Dallas support site under 'Join the IBM Z Dallas ISV Community Website'.



Expand All Collapse All

To IPL your system, issue the following command: 'SVXLOG *guestidname*' For a detailed explanation on how to IPL your system see section 4 (Page 14) of our z/OS User's Guide

Before you shutdown your system, please terminate any applications and subsystems (such as DB2, IMS, CICS, etc.) that you may have started. To display the current tasks running in your system issue: 'SEND *guestid* \CP VI VMSG D A,L'. You can also use our "System Task Termnination by Order" table on page 19 of our z/OS User's Guide for the correct commands to terminate specific tasks.

After sucessfully terminating your system tasks, you can issue 'SEND *guestid* \CP LOGOFF' to logoff from your z/OS system.

For a detailed explanation on how to properly shutdown your system, see section 5 (Page 18) of our z/OS User's Guide

To put your z/OS system to sleep, issue: 'SEND *guestid* \CP SLEEP' - this temporarily "freezes" your z/OS guest system to prevent the system from using CPU cycles when they are not needed.

To resume your z/OS system, issue: 'SEND *guestid* \CP BEGIN'

For a detailed explanation on how to sleep/resume your z/OS system see section 6 (Page 20) of our z/OS User's Guide

To view a list of your available volumes issue: `SEND *guestid* \CP VI VMSG D U,DASD,ONLINE,,254` from a CMS console. For more information about DASD volume configuration see section 9.8 (Page 31) of our z/OS Users Guide

Make sure the system is logged on. You may review the information in section How to IPL the guest z/OS system (detailed description) starting on page 16 of our z/OS User's Guide. Please also be sure the system is awake. You may reference the section Managing the guest z/OS system with SLEEP and BEGIN starting on page 29 of our User's Manual for help with sleeping and waking the system.

You are not the secondary user for the guest. Please issue "MSG SVUTIL SECUSER [guestname] [userid]" from a z/VM CMS console. Replace [guestname] with your guest name and [userid] with the personal user ID you want to be the secondary user.

Make sure to use BACKslash "\" instead of FORWARDslash "/" . If that is not the issue, and you are using a non-US English code page, then the problem is likely that the "host code page" being used in the TN3270 emulator does not properly create the "\" character required to send commands to the guest system ID. Either change the code page (1047 and 037 will work) or use the character in your code page which translates to a X'E0'.

Press the CLEAR key to clear the screen and continue normal operation.
*For 'MORE' - If no action is taken, the screen will clear automatically after 60 seconds. A beep will be issued 10 seconds before this happens.*

Wait for the NOT ACCEPTED to clear, backspace to the left margin, erase the command and reenter it.

The terminal address being DIALed to is already in use. Repeat the DIAL command with a different terminal address, or do not specify a terminal address.

You have asked to mount a tape read only on a device which was previously attached by you in read/write mode, or vice versa. Either correct the MOUNT command or detach the virtual device and reissue the MOUNT command to reallocate the virtual device.

An internal processing error has occurred in the SVUTIL service machine. Contact the Dallas ISV Center with this information by following the contact instructions at the top of the FAQ page.

The tape requested was not found in the tape library database for the user/account requesting the tape mount. Ensure the reference number was typed correctly. Use the "MSG SVUTIL LISTTAPES" command to display a list of tapes in the database.

Use the SMF dump program to dump the dataset for future processing. If SMF data does not need to be retained, clear the condition by starting task CLRMAN1 for SYS1.sysname.MAN1 or CLRMAN2 for SYS1.sysname.MAN2. The term sysname is discussed in "What happened with this IPL of z/OS..." on page 22 of our z/OS User's Guide. See Sample jobs and CLIST/REXX availability on page 65 of the User's Guide for additional details about CLRMAN1 and CLRMAN2. Please Note: Only the inactive SMF dataset may be cleared. Use the "I SMF" MVS command to switch SMF datasets if necessary.

For tape devices, this message is usually caused by putting the system to sleep without first detaching the attached tape device (Always vary offline and detach the tape device before putting the guest z/OS system to sleep). The tape device was forcibly detached without first being varied offline to MVS, resulting in the boxed condition. The device address will be unusable until the next IPL. Substitute another tape device address for the next tape mount request (e.g. if you were using address 590 and now 550 is boxed, use 551).

Reply "Y" to message $HASP454 to bypass the multi-system integrity lock and allow JES2 to continue initialization (the actual command entered would be "R nn,Y" where "nn" is the reply number to the left of message $HASP454).

Enter the "$S A,ALL" command to restart JES2 automatic command processing. This message may appear as a result of an extended period during which the system was halted (for example, put to sleep over a weekend). The JES2 automatic commands are used to periodically cleanup unwanted SPOOL output files from TCAS, etc.

The TSO application is not active. On the MVS Master Console, start the TSO application with the "START TCAS" command. After TSO has started (messages IKT005I and IKT007I appear), reenter the "TSO" command. Please note that it is not necessary to clear the screen or re-access the VTAM logo - simply type "TSO" on the same screen with the "UNABLE TO ESTABLISH SESSION" error message.

LOGOFF and then LOGON to retry the IPL (possibly several times if needed). If the problem persists, contact the Dallas ISV Center for assistance by following the contact instructions at the top of the FAQ page.

LOGOFF and then LOGON to retry the IPL (possibly several times if needed). If the problem persists, contact the Dallas ISV Center for assistance by following the contact instructions at the top of the FAQ page.

Type LOGOFF and press the ENTER key to return to the logo screen. On the logo screen, tab to the COMMAND line and type L ETPDxxx HERE and press the ENTER key.

Issue command "SEND [guestname] \CP VI VMSG D R,L" where [guestname] is the name of your guest system. Look for the $HASP454 message. Respond 'Y' to this message by issuing "SEND [guestname] \CP VI VMSG R 2,y" where [guestname] is your system's name. Please complete the remaining steps to IPL the guest z/OS system. Review the information in section How to IPL the guest z/OS system (detailed description) on page 16 of our z/OS User's Guide

You may review our list of blocked ports here: z/OS User's Guide. If you continue to experiance problems, please contact the Dallas ISV Center for further assistance by following the contact instructions at the top of the FAQ page.

To verify the problem, issue command: "$DSPL". To cleanup all spool older than seven (7) days issue command: "$POJOBQ,ALL,PROTECTED,DAYS>7". Automatic cleanup of syslog output can be done to help prevent the spool space full condition. This can be done by placing the following command at the bottom of the JES2 parameter deck: "$TA,T=00.30,I=86400,'$POJOBQ,Q=C,DAYS>7'" - This will delete any class C output every 24 hours at 0030 hours, that is greater than seven (7) days old. Class C output is the normal class specified in IEASYSLV in LVL0.PARMLIB for the syslog output class. If this class was changed, then the command will need to be modified as well.

This condition is caused by a shortage of slots in the Auxiliary storage configuration. This can be resolved by removing unneeded tasks that are currently running. If you require all tasks, contact the Dallas ISV Center by following the contact instructions on the top of the FAQ page to obtain additional storage needed. Prior to logoff and restarting the guest z/OS system for problem determination, please issue the following commands: "D ASM" "D R,L" "D A,L" "W"

Welcome to the seismic fault line between z/OS Unix System Services (USS) and the distributed platform code pages when runnings "SOME" applications in z/OS USS. Many distributed platform Linux applications will run ASIS under USS, but have caveats for using and configuring them in z/OS USS. Most do not need things like tons of memory or large heap sizes because most of the time that has been taken care of.

An important factor is how you are connecting to your z/OS USS environment. If you are using "TELNET", "PUTTY" or "SSH" then of course you can use the "VI" editor for your ASCII files, but what about the EBCIDIC files and any z/OS MVS files?

The answer is not simple and we hope the following informat helps!!!

Many applications brought to z/OS USS are from the distributed platform and are ASCII oriented which "MAY" cause problems in an EBCIDIC environment and most do not give you an option to create files in EBCIDIC. z/OS USS supports both ASCII and EBCIDIC, but its the z/OS tools like OEDIT and ISHELL (ISH) which are EBCIDIC oriented which restrict you from required modifications to run the applications. There is also z/OS JCL which can be used to run these applications which may need to know that it is an ASCII program, but also may need to build, for example, log files so that folks can edit them to see what the application is doing.

Unless you are the owner of the application and are ONLY going to use it on z/OS USS, you can determine which files will be created in ASCII or EBCIDIC. This IS NOT a good idea if your application is built to run across platforms like Linux, Unix and z/OS USS.

The safest way to handle this is to "TAG" files which are required to be in ASCII. The problem with this is that you will need to figure out which files you will need to look at or manipulate. The good thing is that you will NOT need to modify your application.

Sorry folks you cannot have everything running like in Linux or Unix or ONLY like they do in z/OS USS. Every operating system has it's PROs and CONs. z/OS USS has speed and processing power if applied correctly and using the full z/OS operating system capibilities.

The main example I want to present is this:
  • An ISV wanting to compile a large JAVA program and stated that the compile usually took 20 min on a Linux platform.
  • They tried to compile it in z/OS USS it took over 1 hour to compile.
  • We suggested the compile be done using JCL. The compile only took 1 minute.

Okay lets get back to why we have this FAQ:
By tagging the file with the code-page it came in as, (Could be UTF8, see the chgtag command for specific code pages) , you can then edit it, with OEDIT or ISH and the z/OS USS editor will convert it for you so you can modify it in EBCIDIC and then it will convert it back to ASCII, or the original code-page it was tagged.
Example:
ZOWE has some files which needed to be modified, but they were in ASCII. When we converted them to EBCIDIC the program did not run because they were required to be in ASCII, At the time, ZOWE scripts not written to entertain any file in EBCIDIC. So we TAGGED them so we could edit them with an EBCIDIC editor, (ie. OEDIT,ISPF/ISH), modified what we needed and the program ran. Now this is not gospel, some applications are written to understand EBCIDIC for some files and ASCII for others. So you will need to figure out what files may need addressing.
Here is the commands we used so we could modify the files which needed modification:
  • Add to your .profile if you are running the application in z/OS USS _BPXK_AUTOCVT=ON
  • Optional add to .profile (may not work for ALL applications)

    IBM_JAVA_OPTIONS="-Dfile.encoding=ISO8859-1"
    _CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)"

    Now Export what you need:
    export _BPXK_AUTOCVT IBM_JAVA_OPTIONS _CEE_RUNOPTS

    • Depending on what you need and running in JCL then place one or all required EXPORTS in the JCL.
    • export _BPXK_AUTOCVT=ON
    • Optional add to JCL (may not work for ALL applications)
      export IBM_JAVA_OPTIONS="-Dfile.encoding=ISO8859-1"
      export _CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)"
    Tag the files you will need to be able to read or modify using (OEDIT or ISH)
    • chtag -t -c ISO8859-1 server.xml
      chtag -t -c ISO8859-1 server.env
    • Use this command to see what is tagged in the directory
      ls -T

If you which to extract a .zip file on a z/OS USS environment and do not have an extraction product, you can use JAVA JAR to unzip the file.

Depending on your application, you will need to address the permissions of the newly created directories and files, including the owner and group.

To extract to a different directory, change to the target directory first. The SAMPLE jcl contains the same commands you would us at the z/OS USS command line.

Here is a SAMPLE jcl. 
   //UNZIPFIL JOB (FB3),'Extract .zip File',
   //         CLASS=A,MSGCLASS=X,REGION=0M,NOTIFY=&SYSUID
   /*
   //*************************************************************** */
   //*  Sample JCL To Extract a .zip file in USS                     */
   //*-------------------------------------------------------------- */
   //*************************************************************** */
   //STEP2 EXEC PGM=IKJEFT01
   //SYSPROC  DD DISP=SHR,DSN=SYS1.SBPXEXEC
   //SYSTSPRT DD  SYSOUT=*
   //BPXOUT   DD  SYSOUT=*
   //STDOUT   DD  SYSOUT=*
   //SYSTSIN  DD  *
     PROF  MSGID WTPMSG
     OSHELL -
      export JAVA_HOME=/usr/lpp/java/J8.0_64/; +
      export PATH=/bin:.:$JAVA_HOME/bin      ; +
      cd /apps/provision; -
      jar -xvf /u/ibmuser/sample.zos.provision.wlp-master.zip
   /*
   //

JDBC connections to our DB2 for z/OS configurations can be rather confusing because DB2 on distributed platforms use the "DATABASE NAME" for their connection, but DB2 for z/OS JDBC connections use the "LOCATION NAME".

All is fine and good but the biggest part of the confusion is caused by the DB2 for z/OS Subsystem Identifier (SSID) which is used by some processes to talk directly to DB2 for z/OS database The SSID is used to Start and Stop a DB2 for z/OS database. It is z/OS's way of opening a path to the DB2 for z/OS database/s for some commands.

As a result, it is confused for the DB2 for z/OS JDBC connection location name. To find the information you need to create the JDBC connection to a DB2 for z/OS database, we have provided the following command to find the information and an example of how it fits in the JDBC command.

Most users confuse the SSID with the location name because that is the first thing they become familiar with when using a DB2 for z/OS database.

  • The SSID of the DB2 for z/OS system database is: -DBCG
  • An EXAMPLE of the JDBC command to connect to a DB2 for z/OS system is: jdbc:db2://192.168.248.135:5040 DALLASC
    • Where:
    • 5040 is the connection port, TCPPORT, to use for the DB2 for z/OS system database.
    • DALLASC is the LOCATION NAME of the DB2 for z/OS system database.
  • To query the DB2 for z/OS database for the information required for the JDBC connection, use the DISPLAY DDF command on your DBS for z/OS database. Here is where you would use the SSID. The command on this system is -DBCG DISPLAY DDF and the resulting display below shows the information you will require for the JDBC connection command. See the highlighted lines of the output to recognize the information you need for the DB2 for z/OS database connection command. The command used for this display was: -DBCG DISPLAY DDF 
         DSNL004I  -DBCG DDF START COMPLETE 021
     LOCATION  DALLASC
                LU        USASDV02.DBCGLU1
                GENERICLU -NONE
                DOMAIN    S0W1.DAL-EBIS.IHOST.COM
                TCPPORT   5040
                SECPORT   5041
                RESPORT   5042
                IPNAME    -NONE
                OPTIONS:
             PKGREL = COMMIT

Please see JDBC/ODBC Connectivity to DB2 for z/OS db2jcc_license_cisuz.jar for full details.
If you are still unable to connect, please contact the Dallas ISV Center by following the contact instructions at the top of the FAQ page.