PARM value not interpreted as expected - zos

Working in z/os mainframe, I have the following situation
1) That's my JCL, which I've submited:
//PAYMENT JOB MSGCLASS=H
//******************************************************************
//*
//* This job can be used to run an MQ application that
//* communicates with a transaction running in a CICS region.
//* The CICS transaction records a credit card payment in DB2.
//* The payment description has a maximum length of 35 characters.
//* It is enclosed within quotes below so that you may include
//* spaces to separate words.
//* The monetary values allowed by this tool must be within the
//* range 0.01 - 9999.99.
//*
//******************************************************************
//PAYMENT EXEC PGM=PAYMENT,REGION=1024K,
// PARM='CSQ1,CARD.PAYMENTS,CCD3050.REPLY,CCD3050,
// 400.05,"MY PAYMENT"'
//STEPLIB DD DSN=CCD3050.PART2.LOAD,DISP=SHR
// DD DSN=WMQ.V6R0.SCSQLOAD,DISP=SHR
// DD DSN=WMQ.V6R0.SCSQANLE,DISP=SHR
// DD DSN=WMQ.V6R0.SCSQAUTH,DISP=SHR
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
2) Looking at the job output in SDSF I see:
IRR010I USERID CCD3050 IS ASSIGNED TO THIS JOB.
$HASP373 PAYMENT STARTED - INIT 1 - CLASS A - SYS MVST
IEF403I PAYMENT - STARTED - TIME=12.06.31
- --TIMINGS (MINS.)-
-JOBNAME STEPNAME PROCSTEP RC EXCP CPU SRB CLOCK SERV PG PAGE SWAP VIO SWAPS STEPNO
-PAYMENT PAYMENT 01 39 .00 .00 .00 122 0 0 0 0 0 1
IEF404I PAYMENT - ENDED - TIME=12.06.31
-PAYMENT ENDED. NAME- TOTAL CPU TIME= .00 TOTAL ELAPSED TIME= .00
$HASP395 PAYMENT ENDED
0------ JES2 JOB STATISTICS ------
- 01 FEB 2014 JOB EXECUTION DATE
- 55 CARDS READ
- 111 SYSOUT PRINT RECORDS
- 0 SYSOUT PUNCH RECORDS
- 6 SYSOUT SPOOL KBYTES
- 0.00 MINUTES EXECUTION TIME
1 //PAYMENT JOB MSGCLASS=H
//******************************************************************
//*
//* This job can be used to run an MQ application that
//* communicates with a transaction running in a CICS region.
//* The CICS transaction records a credit card payment in DB2.
//* The payment description has a maximum length of 35 characters.
//* It is enclosed within quotes below so that you may include
//* spaces to separate words.
//* The monetary values allowed by this tool must be within the
//* range 0.01 - 9999.99.
//*
//******************************************************************
2 //PAYMENT EXEC PGM=PAYMENT,REGION=1024K,
// PARM='CSQ1,CARD.PAYMENTS,CCD3050.REPLY,CCD3050,
// 400.05,"MY PAYMENT"'
3 //STEPLIB DD DSN=CCD3050.PART2.LOAD,DISP=SHR
4 // DD DSN=WMQ.V6R0.SCSQLOAD,DISP=SHR
5 // DD DSN=WMQ.V6R0.SCSQANLE,DISP=SHR
6 // DD DSN=WMQ.V6R0.SCSQAUTH,DISP=SHR
7 //STDOUT DD SYSOUT=*
8 //STDERR DD SYSOUT=*
9 //SYSPRINT DD SYSOUT=*
ICH70001I CCD3050 LAST ACCESS AT 15:55:39 ON WEDNESDAY, JANUARY 29, 2014
IEF236I ALLOC. FOR PAYMENT PAYMENT
IGD103I SMS ALLOCATED TO DDNAME STEPLIB
IGD103I SMS ALLOCATED TO DDNAME
IGD103I SMS ALLOCATED TO DDNAME
IGD103I SMS ALLOCATED TO DDNAME
IEF237I JES2 ALLOCATED TO STDOUT
IEF237I JES2 ALLOCATED TO STDERR
IEF237I JES2 ALLOCATED TO SYSPRINT
IEF142I PAYMENT PAYMENT - STEP WAS EXECUTED - COND CODE 0001
IGD104I CCD3050.PART2.LOAD RETAINED, DDNAME=STEPLIB
IGD104I WMQ.V6R0.SCSQLOAD RETAINED, DDNAME=
IGD104I WMQ.V6R0.SCSQANLE RETAINED, DDNAME=
IGD104I WMQ.V6R0.SCSQAUTH RETAINED, DDNAME=
IEF285I CCD3050.PAYMENT.JOB03520.D0000101.? SYSOUT
IEF285I CCD3050.PAYMENT.JOB03520.D0000102.? SYSOUT
IEF285I CCD3050.PAYMENT.JOB03520.D0000103.? SYSOUT
IEF373I STEP/PAYMENT /START 2014036.1206
IEF374I STEP/PAYMENT /STOP 2014036.1206 CPU 0MIN 00.00SEC SRB 0MIN 00.00SEC VIRT 16K SYS 320K EXT 280K SYS 11012K
IEF375I JOB/PAYMENT /START 2014036.1206
IEF376I JOB/PAYMENT /STOP 2014036.1206 CPU 0MIN 00.00SEC SRB 0MIN 00.00SEC
3) And then I see these messages:
********************************************************
Credit card payment unit test tool
********************************************************
Incorrect usage!
Program Usage
-------------
PAYMENT <queue manager> <cics request queue> <reply queue> <userid> <payment value> <payment description>
The payment description has a maximum length of 35 characters.
The monetary value must be within the range 0.01 - 9999.99.
What am I doing wrong?

The program you are using is doing you no favours. It is good practice for all programs which receive a PARM to show the value that has been passed to them.
Compile and execute this program, with the PARM exactly as you have specified it:
ID DIVISION.
PROGRAM-ID. PROGNAME.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 W-WHEN-COMPILED PIC X(8)BX(8).
LINKAGE SECTION.
01 THE-PARM-FROM-THE-JCL.
05 TPFTJ-LENGTH BINARY PIC 9(4).
05 TPFTJ-VALUE.
10 FILLER OCCURS 0 TO 100 TIMES
DEPENDING ON TPFTJ-LENGTH.
15 FILLER PIC X.
PROCEDURE DIVISION USING
THE-PARM-FROM-THE-JCL
.
MOVE WHEN-COMPILED TO W-WHEN-COMPILED
DISPLAY "PROGNAME " W-WHEN-COMPILED
DISPLAY
">"
TPFTJ-VALUE
"<"
GOBACK
.
You should see this as your output:
PROGNAME followed by date-and-time-of-compile
>CSQ1,CARD.PAYMENTS,CCD3050.REPLY,CCD3050, 400.05,"MY PAYMENT"<
You will see that chunk of blanks in the middle. That is your problem.
I don't know if you actually want the double-quotes around MY PAYMENT.
Assuming not, this would be one way to code your PARM:
// PARM=('CSQ1,CARD.PAYMENTS,CCD3050.REPLY,CCD3050',
// '400.05,MY PAYMENT')
The above program will show you this value:
>CSQ1,CARD.PAYMENTS,CCD3050.REPLY,CCD3050,400.05,MY PAYMENT<
If you look at this, you'll see the problem and some resolutions described: http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ieab100/jclexs.htm. This example is for the binder (IEWL). You should also consult the JCL Reference manual for your particular release of z/OS (although any one should do, I don't think PARM processing has changed under z/OS).
Continuations of PARM are tricky, because there are certain characters which have meanings to JCL. One way of continuing is to use up to column 71 and then continue in column 16. This is not very flexible. Enclosing the PARM value in parenthesis is more flexible. You also have several full-stops/periods, and those values need to be protected by single-quote pairs. The JCL Reference will detail all, and then you experiment with the above program to achieve full clarity.

Related

OTP size for STM32F746XX

I found a strange mismatch in the reference manual for the OTP memory size:
Accordingly to the manual (RM0385, page 78) the start-address of the OTP memory begins at 0x1FF0 F000 and ends at address: 0x1FF0 F41F (in AXIM mode) and is declared as a memory area with the size of 1024 bytes:
But if I calculate 0x1FF0F41F - 0x1FF0F000 + 1 I get a total of 1056 bytes OTP memory?!
Same addresses are set in the latest CMSIS header V1.17.0 (https://raw.githubusercontent.com/STMicroelectronics/STM32CubeF7/master/Drivers/CMSIS/Device/ST/STM32F7xx/Include/stm32f746xx.h):
#define FLASH_OTP_BASE 0x1FF0F000UL
#define FLASH_OTP_END 0x1FF0F41FUL
Is this a typo in the manual or is my calculation wrong?
I don't think it's a typo, and your calculation is correct.
My explanation is as follows:
Chapter 3.6 of the same Reference Manual shows the organization of the one-time programmable (OTP) part of the OTP area, and explains:
The OTP area is divided into 16 OTP data blocks of 64 bytes and one lock OTP block of 16 bytes. The OTP data and lock blocks cannot be erased. The lock block contains 16 bytes LOCKBi (0 ≤ i ≤ 15) to lock the corresponding OTP data block (blocks 0 to 15). (...)
So it consists of 1024 data bytes and 16 lock bytes. I guess the lock bytes are implemented as special "registers" and are not considered part of the sector. It's more a matter of definition and does not really matter that much.
There probably is a 1024-byte sector to write the (one-time programmable) data to, but the address range is slightly larger because the lock bits have to be addressed as well.

Why is the value for the instruction register 1106 for the load One instruction?

For this question:
Trace the fetch-decode-execute cycle for the following program:
1 .org 100
2 Load One
3 JnS IncRoutine
4 Halt
5 IncRoutine , HEX 0
6 Add One
7 JumpI IncRoutine
8 One , DEC 1
For the load One instruction:
Step RTL PC IR MAR MBR AC M[103]
Load One (initial values) 100 - - - - -
Fetch MAR←PC 100 - 100 - - -
IR←M[MAR] 100 1106 100 - - -
PC←PC+1 101 1106 100 - - -
Decode MAR←IR[11-0] 101 1106 106 - - -
(Decode IR[15-12])
Get operand MBR←M[MAR] 101 1106 106 0001 -
Execute AC←MBR 101 1106 106 0001 0001 -
I do not understand where the 1106 came about for the instruction register as shown above. If someone could explain that would be great
1106 is the opcode for the Load One instruction. When it starts your trace, it hasn't even fetched the instruction yet. It loads the program counter into the memory register, then fetches the contents into IR. So, IR has "the instruction to be executed". The next step has to decode the instruction (1) and the address field (106).
By the way, it would have been somewhat easier if you had given us even the slightest clue where this came from. This is a fictional instruction set for some fictional computer, but without the details, we're just guessing.

CICS JCL procedure to compile and link the SIT containing updated CICS parameters

Does CICS have supplied procedure for assembling a SIT? I'm currently checking from https://www.ibm.com/docs/en/cics-ts/5.3?topic=library-cics-supplied-procedures but I can't find anything that uses EXEC PGM=DFHSIP. I'm not in that level yet to write a JCL myself so I'm really trying to find sample of how I can assemble my updated DFHSIT macro.
It usually isn't necessary to assemble a new SIT table. You can pass SIT parameters as overrides when starting your CICS region. I find that the majority of CICS systems are started with one of the supplied SIT load modules (DFHSIT or DFHSIT6$) and provide customized SIT overrides via SYSIN. See https://www.ibm.com/docs/en/cics-ts/5.3?topic=regions-specifying-system-initialization-parameters-before-startup
Note that the primary reason why people don't assemble a new SIT table is that the SIT load module must reside in an APF authorized data set. In most enterprises, write access to an APF authorized data set is rarely allowed and is severely scrutinized when an update is absolutely necessary.
DFHSIP is the main CICS program and isn't used for assembling the SIT tables. Probably best to have a look at the proc DFHEITAL that is provided with CICS. This is a good example of how to translate, compile and linkedit assembler programs.
However SIT tables should not be translated or linkedited with the CICS stub program. Below is an example of what I've used before to compile CICS tables:
//ASM EXEC PGM=ASMA90,REGION=0M,
// PARM='DECK,NOOBJECT,LIST’
//SYSLIB DD DSN=<cicshlq>.SDFHMAC,DISP=SHR
// DD DSN=<cicshlq>.SDFHSAMP,DISP=SHR
// DD DSN=SYS1.MACLIB,DISP=SHR
//SYSUT1 DD UNIT=SYSDA,SPACE=(1700,(400,400))
//SYSUT2 DD UNIT=SYSDA,SPACE=(1700,(400,400))
//SYSUT3 DD UNIT=SYSDA,SPACE=(1700,(400,400))
//SYSPUNCH DD DSN=&&LOADSET,
// UNIT=SYSDA,DISP=(,PASS),
// SPACE=(400,(100,100))
//SYSPRINT DD SYSOUT=A
//SYSIN DD DATA,DLM='<>'
<source>
<>
//LKED EXEC PGM=IEWL,REGION=0M,
// PARM='LIST,XREF',COND=(7,LT,ASM)
//SYSLIB DD DSN=<cicshlq>.SDFHLOAD,DISP=SHR
//SYSLMOD DD DSN=<output>,DISP=SHR
//SYSUT1 DD UNIT=SYSDA,DCB=BLKSIZE=1024,
// SPACE=(1024,(200,20))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=&&LOADSET,DISP=(OLD,DELETE)
// DD DDNAME=SYSIN
//SYSIN DD *
NAME <name>(R)
/*

IMS init empty DB

i've got a problem, that i can't resolve.
I want to try to work with IMS. so i make dbdlib, psblib, and now write jcl to init my db.
1://RELOAD EXEC PGM=DFSRRC00,PARM='ULU,DFSURGL0,LIBDBD,,,,,,,,,,,N'
2://STEPLIB DD DISP=SHR,DSN=DFSD10.SDFSRESL
3://DFSRESLB DD DISP=SHR,DSN=DFSD10.SDFSRESL
4://IMS DD DISP=SHR,DSN=USER19.DBDLIB
5://DFSUINPT DD DUMMY
6://DFSVSAMP DD DISP=SHR,DSN=DFSD10.PROCLIB(VSAMP01)
7://SYSPRINT DD SYSOUT=*
8://DATABASE DD DISP=OLD,DSN=USER19.LIBIMS
This is my jcl. I've got rc 16 and such msgs in sysprint:
DFS386A A PREMATURE EOF WAS ENCOUNTERED ON DDNAME DFSUINPT
DFS339I FUNCTION DR HAS COMPLETED ABNORMALLY RC=16
I think, he want me putting some data in my db, but i only want to init EMPTY db
I don't think that you should be using DFSURGL0 as that's reload/unload utility as per
The HD Reorganization Reload utility (DFSURGL0) reloads databases and HALDB partitions by using the output data sets that are created by the HD Reorganization Unload utility (DFSURGU0).
I'd suggest haveing a look at the IBM Knowledge centre. This could be a good starting point as it's the initialisation utilities. Definition and initialization utilities
I can't be of much more help as it's been around 30 years or since I last used IMS Utilities and only have access to search the web in this respect.
In brief terms what you've encountered is the utility saying it expects some data in the ddname DFSUINPT and DD DUMMY results in END of DATA (EOF) immediately the DDNAME is accessed/read. So DFSURGL0 is complaining, hence CC=16. Another way of looking at this is that you told it, perhaps by default, to load the database, so it's saying what with.

Convert Binary Data to Date

I have the following data: F0 60 5B 50 BB 27 C4 01
I am 99% certain that this represents the date: 21/04/2004 17:11:33
I cannot for the life of me work out how it is encoding it. Am I being dense? I've tried just reading it in as a binary date, but that comes back with a date way in the future. I've tried assuming it's number of ticks since some epoch, but to no avail.
Does anyone have any suggestions?
Edit: The data is from an export of an application over which I have no control. I am trying to extract data from this dump in order to make reporting of the contents of the application a little easier.
Another sample is: 90 53 EC 85 CB B2 C5 01 -> 06/09/2005 11:12:44
I'm only about 50 sure that this date is correct (which is why I didn't include it previously).
I think I'm onto something. If you reverse bytes (so that they read 01 C4 27 BB ... and feed that into DateTime.FromBinary, you'll get 21.04.0404 16:11:33, which is very close digit-wise to your date.